Planning, designing and organizing a virtualization deployment is a difficult task. There are enough technical hurdles for administrators to jump, but often it's the challenge of getting everyone to pull in the same direction that ultimately slows a project. In this Q&A, we talk with author and virtualization expert Scott Lowe about what to expect when planning a VMware vSphere design project and how to prepare for these challenges. Lowe, along with Forbes Guthrie, is co-author of the new book, VMware vSphere Design, Second Edition. Like the first edition of the book, this edition explains design decisions such as hardware selection and network design, but also includes updates for vSphere 5. You can download a chapter except (PDF) from VMware vSphere Design, Second Edition, courtesy of publisher Sybex, which is part of John Wiley and Sons Inc.
Where should someone start when designing a vSphere infrastructure?
Scott Lowe: The best place to start is, naturally, at the beginning. For a vSphere design project, the beginning includes the reasons why the organization is seeking to deploy VMware vSphere. What applications does the organization plan to deploy? What goals does the organization hope to reach with the help of a vSphere implementation? What are the problems -- business or technical -- that the organization is trying to solve? Understanding -- and documenting -- the business drivers, goals, problems and needs of the organization should be the first task one undertakes. This is the beginning, and this work translates into what I've called the design factors: requirements, constraints, risks and assumptions. The design factors are crucial to the success of any vSphere design.
What kinds of challenges or decisions should a company expect to encounter when designing a vSphere infrastructure?
Lowe: The challenges, in my experience, don't usually come from designing the vSphere environment. Instead, organizations typically face challenges in properly understanding the reasons for implementing vSphere. The applications that the environment needs to support may be unknown; the resource requirements of these applications are likely to be unclear and not documented; and there may be organizational challenges that arise.
What part of designing the infrastructure do admins often have trouble with? Can you offer some general advice that might help ease these challenges?
Lowe: The No. 1 piece of advice that I can give an admin -- of any discipline, be it vSphere, networking or storage -- is to branch out and start learning about the other technology disciplines in the data center. An admin who is only familiar with one particular area won't be effective in designing infrastructures that touch on multiple areas. To be able to effectively design vSphere environments, one must be knowledgeable about vSphere, yes -- but one must also have some knowledge in networking, security, storage, operating systems and applications. A broad-based, multidisciplinary view is, I think, a very important view to build and maintain.
Are there any common misconceptions about designing a vSphere infrastructure?
Lowe: If I had to pick one misconception, I would say that it's the mistaken belief that the storage and networking teams don't really need to be involved in a vSphere design. I think that it's far too common for the "vSphere team" -- which is typically former server administrators now managing a vSphere environment -- to think that vSphere eliminates the need for careful consideration of the storage and networking portions of the design. Nothing could be further from the truth. A poor storage design or a poor networking design resulting from a failure to properly involve the necessary teams within an organization is a surefire way to ensure that this project isn't successful.
How has the process of designing a vSphere infrastructure changed over the last several years with vSphere 5.1 and vCloud Director?
Lowe: The vSphere design process, overall, has remained largely constant as VMware vSphere and related cloud infrastructure products have grown and evolved. What's changed is the number of products and the breadth of the products. The impact of this growth on the design process is that the architect has more to consider and more to evaluate -- which products are best suited to fit the design requirements, what are the interdependencies (sometimes very complex interdependencies) between the various products or the product features, and what is the best combination of products and features to use? These sorts of questions and decisions become more difficult and more involved as the products and features continue to grow, expand and mature.