Datasheet

THE PROCESS OF DESIGN
|
9
The Process of Design
Now that we’ve discussed the facets of design, it’s time to discuss the process of design. In this
section, we’ll cover how you go about creating a VMware vSphere design, some of the tasks
involved, and some of the tools you can use to complete those tasks.
We’ll start with what is, as we’ve said before, one of the most important areas: functional
requirements.
Gathering and Defi ning Functional Requirements
Functional requirements form the basis, the driver, for almost everything in the design. Most
other decisions in the design are based on or affected by the functional requirements, so it’s
incredibly important to be as thorough and complete as possible during the process of gathering
and defi ning the functional requirements.
In many situations, some of the functional requirements are provided to you. For example, if
an organization is adopting VMware vSphere in order to support a consolidation initiative, the
business might clearly specify a functional requirement in a statement like this: “The virtualiza-
tion environment must support the consolidation of 250 physical server workloads.” No addi-
tional effort is required on your part to defi ne this requirement. (But additional effort is clearly
required to implement that functional requirement in the design.)
It’s uncommon, in our experience, to have situations where all the functional requirements
are provided to you. In these cases, you’ll have to gather information to defi ne the functional
requirement. There are two primary ways to gather the information necessary to defi ne the
design’s functional requirements:
u Reviewing documentation
u Performing interviews
REV IEWING DOCUMENTATION
In some cases, the customer or organization implementing VMware vSphere has documenta-
tion that outlines the functional requirements. Remembering that virtualization is implemented
in order to accomplish a goal (to “do something”), documentation is often created that outlines
what the organization is attempting to achieve. For example, perhaps the organization is imple-
menting virtualization as part of a desktop virtualization initiative. In that case, some of the
functional requirements of the VMware vSphere environment can be derived directly from the
documentation prepared for the desktop virtualization project. If the desktop virtualization
documentation specifi es that the VMware vSphere environment will automatically restart desk-
top VMs in the event of a host failure, that should immediately sound a mental alarm — your
vSphere environment will need to use VMware HA in order to meet that functional require-
ment. And because you’ll use VMware HA, you’ll also need to use clusters, which means you’ll
require redundant management connections, which affects the networking design … and so on.
In another example, suppose the organization is migrating into a new data center and has
compiled a list of all the applications that will be migrated. You can use that documentation to
understand the applications’ needs and determine the functional requirements necessary to
support those needs. Perhaps the application documentation indicates that the I/O profi le is
primarily writes instead of reads and that the application needs to sustain a specifi c number
c01.indd 9c01.indd 9 2/1/2011 1:51:16 PM2/1/2011 1:51:16 PM