Datasheet

12
|
CHAPTER 1 AN INTRODUCTION TO DESIGNING VMWARE ENVIRONMENTS
We’ll discuss some of these tools in Chapter 10, “Monitoring and Capacity Planning.” Because
part of capacity planning involves previrtualization assessment, these tools are also useful in
assessing an organization’s existing environment in preparation for completing a design.
At this point, you’re armed with some functional requirements, the information necessary to
defi ne other functional requirements, and knowledge of the existing environment. You’re ready
to assemble the design.
Assembling the Design
Assembling the design is the iterative process we described earlier and depicted in Figure 1.3.
While assembling the design, you’ll make decisions within each of the three facets. Those deci-
sions, focused on the what/who/how theme, will be based on the functional requirements that
you’ve been given or have defi ned. Each decision has a cascading effect, forcing a series of what
we call downstream decisions, as shown in Figure 1.8.
Fig ure 1.8
Each decision
forces other deci-
sions in a complex
decision tree. The
results of each
decision must be
compared against
the functional
requirements.
Use blade
servers instead
of rack-
mounted
servers
Servers are
limited to 4
NICs and 2
HBAs
Blade chassis
is potential
single point of
failure
Multiple blade
chassis
required for
redundancy
VMware
cluster size
affected to
ensure correct
HA
functionality
Maximum of 2
vSwitches
possible with
redundant
uplinks
...
...
...
When you make a decision in the design, you then need to compare the result of that deci-
sion — and all the downstream decisions resulting from that decision — to ensure that you’re
still meeting all the functional requirements. If so, you continue; if not, you need to change that
decision or violate one or more of the functional requirements.
Violating Functional Requirements Might Be Necessary
Sometimes, organizations have an unrealistic view of the functional requirements. In situations
like this, it may be necessary to violate a functional requirement. As long as you can show why the
functional requirement is violated and can provide a potential remediation for the violation, it’s
up to the organization to determine whether that functional requirement really is a requirement
or if the design can be accepted and implemented as described.
c01.indd 12c01.indd 12 2/1/2011 1:51:16 PM2/1/2011 1:51:16 PM