vSphere Design Best Practices

Brian Bolander
Christopher Kusek








Chapter No. 6
"Business Critical Applications"
In this package, you will find:
A Biography of the authors of the book
A preview chapter from the book, Chapter NO.6 "Business Critical Applications"
A synopsis of the books content
Information on where to buy this book









About the Authors
Brian Bolander spent 13 years on active duty in the United States Air Force. A veteran
of Operation Enduring Freedom, he was honorably discharged in 2005. He immediately
returned to Afghanistan and worked on datacenter operations for the US Department
of Defense (DoD) at various locations in southwest Asia. Invited to join a select team
of internal consultants and troubleshooters responsible for operations in five
countries, he was also the project manager for what was then the largest datacentre
built in Afghanistan.
After leaving Afghanistan in 2011, he managed IT operations in a DoD datacentre in
the San Francisco Bay Area. His team was responsible for dozens of multimillion dollar
programs running on VMware and supporting users across the globe.
He scratched his adrenaline itch in 2011 when he went back "downrange", this time
directing the premier engineering and installation team for the DoD in Afghanistan.
It was his privilege to lead this talented group of engineers who were responsible for
architecting virtual datacenter installations, IT project management, infrastructure
upgrades, and technology deployments on VMware for the entire country from 2011
to 2013.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book


Selected as a vExpert in 2014, he is currently supporting Operation Enduring Freedom as
a senior virtualization and storage engineer.
He loves his family, friends, and rescue mutts. He digs science, technology, and geek
gear. He's an audiophile, a horologist, an avid collector, a woodworker, an amateur
photographer, and a virtualization nerd.
Christopher Kusek had a unique opportunity presented to him in 2013, to take the
leadership position responsible for theater-wide infrastructure operations for the war
effort in Afghanistan. Leveraging his leadership skills and expertise in virtualization,
storage, applications, and security, he's been able to provide enterprise-quality service
while operating in an environment that includes the real and regular challenges of heat,
dust, rockets, and earthquakes.
He has over 20 years' experience in the industry, with virtualization experience running
back to the pre-1.0 days of VMware. He has shared his expertise with many far and wide
through conferences, presentations, #CXIParty, and sponsoring or presenting at
community events and outings whether it is focused on storage, VMworld, or cloud.
He is the author of VMware vSphere 5 Administration Instant Reference, Sybex, 2012,
and VMware vSphere Performance: Designing CPU, Memory, Storage, and Networking
for Performance-Intensive Workloads, Sybex, 2014. He is a frequent contributor to
VMware Communities' Podcasts and vBrownbag, and has been an active blogger for
over a decade.
A proud VMware vExpert and huge supporter of the program and growth of the
virtualization community, Christopher continues to find new ways to outreach and
spread the joys of virtualization and the transformative properties it has on individuals
and businesses alike. He was named an EMC Elect in 2013, 2014, and continues to
contribute to the storage community, whether directly or indirectly, with analysis
and regular review.
He continues to update his blog with useful stories of virtualization and storage and his
adventures throughout the world, which currently include stories of his times in
Afghanistan. You can read his blog at http://pkguild.com or more likely catch him
on Twitter; his twitter handle is @cxi.
When he is not busy changing the world, one virtual machine at a time or Facetiming
with his family on the other side of the world, he's trying to find awesome vegan food in
the world at large or somewhat edible food for a vegan in a war zone.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

vSphere Design Best Practices
Welcome to vSphere Design Best Practices, an easy-to-read guide full of hands-on
examples of real-world design best practices. Each topic is explained and placed in the
context of virtual datacenter design.
This book is all about design principles. It isn't about operations or administration;
instead, we focus on designing virtual datacenters to meet business requirements and
leveraging vSphere to get us to robust and highly available solutions.
In this book, you'll learn how to utilize the features of VMware to design, architect, and
operate a virtual infrastructure using the VMware vSphere platform. Readers will walk
away with a sense of all the details and parameters there are for a design that has been
well thought out.
We'll examine how to customize your vSphere infrastructure to fi t business needs and
look at specific use cases for live production environments. Readers will become
familiar with new features in Version 5.5 of the vSphere suite and how these features
can be leveraged in design.
Readers will walk away with confidence as they will know what their next steps are
towards accomplishing their goals, whether that be a VCAP-DCD certification or a sound
design for an upcoming project.
What This Book Covers
Chapter 1, Virtual Data Center Design, gives you an insight into the design and
architecture of the overall datacenter, including the core components of vCenter
and ESXi.
Chapter 2, Hypervisor Design, dives into the critical components of the datacenter by
providing the best practices for hypervisor design.
Chapter 3, Storage Design, explains one of the most important design points of the
datacenterstorage. This chapter focuses attention on the design principles related to
the storage and storage protocols.
Chapter 4, Network Design, peels back the layers of networking by focusing on
designing flexible and scalable network architectures to support your virtual datacenter.
Chapter 5, Virtual Machine Design, covers what it takes to inspect your existing virtual
machines and provides guidance and design principles to correctly size and deploy VMs.
Chapter 6, Business Critical Applications, breaks through the barriers and concerns
associated with business critical applications, allowing business requirements to translate
into a successful and stable deployment.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book


Chapter 7, Disaster Recovery and Business Continuity, considers the many parameters
that make up a DR/BC design, providing guidance to make sound decisions to ensure a
well-documented and tested disaster recovery policy.
Appendix A, vSphere Automation Tools, briefly discusses the value of automation tools
such as vCenter Orchestrator (vCO) and vCloud Automation Center (vCAC), their
differences, and use cases for your design and implementation.
Appendix B, Certification Resources, gives guidance on the VMware certification
roadmap and lists resources for the Data Center Virtualization (DCV) track.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
Business critical applications are usually treated with a very wary and cautious
eye and your environment should be no different. We'll discuss how to architect
application solutions to ensure performance, resiliency, and high availability
for business critical applications such as SQL and Exchange. You will learn how
to gather requirements and work with business stakeholders to translate those
requirements into a successful and stable deployment.
We will be covering the following topics in this chapter:
Special considerations for tier 1 applications
Workload proles
HA, DRS, and vMotion considerations
Resource considerations regarding CPU, Storage, Memory, and Network
Ensuring high availability and application resiliency
Other business critical application resources
Special considerations for tier 1
applications
First and foremost, let us address the fact that most often people consider virtualization
as the platform for running nonessential, nonmission-critical applications. Sure this
platform is ne for a print server or running an application, but certainly not our
e-mail, let alone the core services that run our business. If you're of the opinion that tier
1 applications cannot be virtualized, allow this chapter to help dispel that belief and
guide you into the future of "virtualization rst" to support all of your applications.
When it comes to the traditional mission-critical applications people think of Exchange,
SQL, and other workloads. These are not only capable of being virtualized but also are
able to perform in ways that your traditional environment may be unable to realize
today. The rst steps of virtualizing this infrastructure need not be complex; in fact, it
should be handled with the exact opposite attitude.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
[ 70 ]
Starting simple
The inclination to deploy or architect a business critical application is for the effort to
be painful and complex. It doesn't have to be! Start simple and remember that a lot
of the work has already been done. These applications have been around for a while
and a lot of others have been virtualizing them for years, which allows us to take
advantage of those benets. The following are a few simple rules that will save you a
lot of time and complexity:
Refer to support policies, recommendations, and best practices
Architect for the application, not for the virtualization solution
Defaults are your friend until you tune and optimize
These are not the end-all and be-all, but tend to work pretty reliably in most
organizations. Refer to the specic application vendor's guidance, but remember
our discussion of when to apply best practice recommendations and make intelligent
choices about what will work for youguidance is, after all, guidance and not
requirements. If you nd that your requirements act considerably above or below
what is being recommended, then act accordingly. That is to say, just because your
vendor's best practices call for 64 GB of memory per instance does not mean you
need that much memory if it goes unused, and equally if your needs far exceed, that
you should limit your environment.
This leads directly into architecting for the application, which should have been
dened by the users and their actual requirements and not the perceived ones. Then
apply those principles into how you'd go about designing as though it were physical
and applying virtually. Avoid throwing resources at a design problemwe're
talking virtual datacenters and applications built on VMware. We don't have the
hard and fast constraints that a purely physical infrastructure imposes upon us. We
can add memory, CPU, disk and networking, as needed, easily in virtual datacenters.
The point here is to understand the application's requirements and the right size of
your resources to meet the needs and not over engineer in the hopes that 16 CPUs
and 256 GB of RAM will keep you out of trouble!
And the last and the most critical is the defaults until you tune. That is not to say
stick with defaults; quite the opposite. It implies that your architecture initially
should leverage defaults, so you can get into a pattern of dening what your baseline
is and where your environment starts to wear level. After such a time as you get a
good sense of what your peaks and valleys are, you should go in and tune aspects of
the architecture that apply to the application. Some particular areas of interest here
are tuning your application's memory and CPU utilization, so they do not conict
with the general operation of the system. Changing defaults just for the sake of
changing defaults does no one any good, so be particular about the changes that you
make for the benet of your architecture.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Chapter 6
[ 71 ]
In addition, beyond the application, this lends itself as the perfect opportunity to
resize your application based on its needs, whether that includes increasing or
decreasing resources based upon its actual use instead of its perceived use.
Workload proles
Every business critical application carries with it a function, workload, and prole;
consider a business critical application such as a unique and beautiful snowake.
Putting that analogy aside for a moment, all snowakes are ice crystals and carry
with them more common characteristics than they do unique ones, which allows us
to prole our workloads enabling a consistent architecture to design and deploy.
All applications will require CPU, memory, storage, and network resources; the
application will help to dene exactly how much of each resource is required.
Designing for Microsoft Exchange
Over time, the Exchange server has made signicant modications to its
architecture shifting which resources are required over that time. In the beginning,
Exchange was memory light and storage IOPS heavy, but as Exchange 2003 was
staged out in favor of Exchange 2007, 2010, and 2013 a fundamental shift in its
architecture moved it to being memory heavy. While at the same time that the
storage IOPS decreased, the storage consumption requirements increased with the
loss of Single Instance Storage (SIS).
With these changes in Exchange, you'll want to consider whether you'll be
building on an existing deployment or starting fresh with a brand new Exchange
infrastructure. Irrespective of which path you choose, you'll want to consider some
of the following best practices for that architecture:
Do not P2V your Exchange servers, it is cleaner and easier to build new and
move your users mailboxes
If you have existing Physical Servers, analyze their performance
characteristics before and after you migrate users to ensure your performance
stays the same or improves
Split your roles and size their CPU/Memory on a role-by-role basis and
by their actual utilization, not simply what a sizing spreadsheet says should
be allocated
If resource constrained, do not over-commit resources unless
absolutely required
Size your Exchange VMs to t within NUMA nodes for best performance


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
[ 72 ]
The Exchange server is typically one of the easiest business critical applications to
stand up and virtualize and may require the least amount of effort and conguration.
Following the best practice guidance for Exchange can save you a lot of effort and
complexity, with a wary eye kept on the resources required versus those actually
used. The scalability of virtualization may enable you to use fewer deployed servers
to handle the same workload than you had experienced physically, so be sure to take
that into account and not simply re-create one for one physical to virtual.
Considering Microsoft SQL server
SQL has actually a less contentious history with changes to its capabilities as
Exchange does, but still carries with it a little baggage of drawing the distinction
between its function and utilization. That is to say what the assumption typically is,
is that if it is a SQL server it will immediately require extensive memory, CPU, and
disk both in IOPS and storage. This is unfortunately not always the case and can
lead to an oversized SQL architecture. In the previous chapter, a generic analysis of
environments was referenced and more specically an analysis of over 100,000 SQL
workloads with the VMware capacity planner tool has identied that the average
physical SQL server used two CPUs at 6 percent utilization, 3 GB of memory at 60
percent utilization, and about 20 IOPS of storage utilization. This is not to say that
business critical SQL servers do not exist, in fact they exist in droves; this expresses
the importance to architect for your application's usage and not simply having SQL
on the label.
Using the following formulae can allow for sample SQL application deployments:
Light workloads: One vCPU with 4 GB of RAM
Medium workloads: Two vCPUs with 8 GB of RAM
Heavy workload: 4 vCPUs with 16 GB of RAM
Very heavy workload: Assign the "maximum": and analyze its peaks and
assign accordingly
With a little effort on your part and analysis over the life of the application, you'll
be able to ensure that your application environment runs better and faster. You'll
also be allocated the most appropriate resources at the right time instead of
over-assigning resources.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Chapter 6
[ 73 ]
Some special considerations that you'll want to ensure are part of your best
practices are as follows:
Database and log LUNs need enough spindles. If your application calls for
disk performance, ensure that the appropriate performance is backed by
your SAN.
Evaluate workloads for SQL-intensive operations and optimize
as appropriate.
Consider scaling out for high-end deployments, if you require more
resources than a single physical host can provide.
Refer to best practices from your storage vendor and Microsoft and assign
liberally. Remember, best practices don't always apply to your
application's needs.
If clustering, follow best practices for SQL clustering. Most applications
will not require clustering and can take advantage of VMware HA, but if an
application requires 99.999 percent uptime, apply considerations as required.
There are countless other items to reference, it is highly advised to read through
the best practices for SQL on VMware's site and Microsoft SQL server and VMware
virtual infrastructure best practices. The criticality of your application will require
special attention to ensure it provides the availability, capabilities, and services that
earn it a business critical designation.
HA, DRS, and vMotion considerations
Here's where some of the previously discussed features of vSphere really start to
shine. By nature, a well-designed vSphere implementation is highly available and
robust, but when we're talking about business critical applications, the following
are some specics to be aware of as they relate to application availability:
VMware HA: This isn't application aware! First and foremost, don't rely on
this feature for application HA. Ensure your design has sufcient capacity
for faultless vSphere HA operations. Consider the constraints of HA as they
relate to VM admission control and plan for enough overhead to prevent HA
problems, should you lose a host. In an environment where availability is
critical, consider the cost of compute resources against the loss of revenue as
multiple host failures could be costly in the long run. This is one area where
it doesn't hurt to over-engineer a bit.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
[ 74 ]
DRS and DRS rules: This can do a number of things for application
availability. You can "pin" VMs to hosts with afnity rules, ensure
loads are split with anti-afnity rules that ensure VMs run on different
hosts, and automatically balance loads across your hosts. For example, if you
were running an application with web frontends and SQL servers on the
backside, DRS rules that pin the web servers and SQL VMs to the same host
may give you increased performance by allowing the VMs to communicate
via the server backplane. But, it might hurt CPU, memory, and
inbound/outbound network bandwidth on the ESXi hosts. One potential
mistake is "required" DRS rules, it's almost always better to use a "should"
ruleset in a shared environment.
vMotion: This allows for automated migrations from overloaded or failed
hosts in conjunction with DRS and HA. Additionally, mission-critical
applications hosted on your VMs can be moved with the VM causing no
interruptions in service to users of those apps. Be aware of factors such as
storage consumption, bandwidth availability in your vSphere stack, and
any DRS rules you have in place when doing vMotion or maintenance.
Protect these critical apps and be aware that the even seemingly innocuous
migrations may impact availability.
Fault Tolerance (FT): This is a feature of vSphere that provides VM level
failure protection. There are unique planning requirements and capacity
concerns when implementing FT VMs and you must be aware that we're
talking VM fault tolerancenot application fault tolerance. FT isn't
application aware. If you implement, be aware that there is another offering
from VMware that gives you application fault tolerance.
Application HA (App HA): This is a VMware offering as part of the vCenter
operations management suite. It currently affords application HA for some
versions of Microsoft's SQL and Internet Information Server (IIS) offerings,
Apache and Apache Tomcat, and SharePoint 2007 and 2010. New for Version
5.5 is App HA's ability to host and VM monitors with service monitoring.
App HA can restart supported applications if it detects a failure. In order to
use App HA, you must deploy two appliances that run vSphere App HA and
vFabric Hyperic.
Also available is the VMware vSphere Guest SDK that allows for third-party
monitoring solutions such as Symantec and NeverFailand if you're inclined
or have the budget, you can write your own monitors! For more information,
please refer to: http://pubs.vmware.com/appha-1/topic/com.vmware.
ICbase/PDF/vsphere-app-ha-install-guide-1.pdf.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Chapter 6
[ 75 ]
Resource considerations
Every application has its own resource considerations to be aware of, and every
workload has its own needs. The following are some key areas you'll want to
consider when it comes to resource assignment in general. Special considerations
are treated on a per-application basis.
CPU: If best practices from the vendor calls for multiple vCPUs for your
application, look at the utilization rst before arbitrarily assigning them.
The note we saw earlier about overassigning to see where your environment
starts to level out in utilization applies here. Thus, only allocate vCPUs that
are being used, as idle vCPUs will compete for system resources. If your
workload is unknown, size for fewer vCPUs or intentionally overallocate
and analyze to appropriately right-size later, after running your production
loads to see their operational effectiveness. If this is a truly business critical
application, ensure that the total number of vCPUs assigned is less than
or equal to the total number of cores on the host. When you exceed that
number, you'll introduce performance problems and slow your application
down instead of speeding it up.
Memory: When it comes to your business critical workloads it has never
been more important to allocate your memory based upon your application
workload. Certain applications will have shared memory, which will be very
common, duplicate, and respectively will dedupe very well. Unfortunately,
many business critical applications that are unique will not have duplicate
operations. That being the case, you may want to consider ensuring you do
not oversubscribe your mission-critical workloads. Unique case applications
specic to your business or data warehouses typically do not dedupe very
well. So you will want to ensure that the memory allocated is available,
setting reservations if needed. Doing this helps to avoid issues of memory
contention or resource starvation when nonessential applications start to
consume your primary resources.
Storage: Business critical applications' usage of storage is best treated in two
ways. First, you focus on the IOPS required by the application; secondly, you
ensure you have adequate capacity to support those requirements. With the
evolution of ash storage and high-speed storage solutions on the market,
the ability to supply IOPS to your applications has been getting easier than
ever. However, to the points earlier about over-architecting the solution just
because you can assign an application 10,000 IOPS doesn't mean anything if
it is averaging less than 100. This is where ensuring that the right workload is
running on the right tier of storage comes into play.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
[ 76 ]
Network: We discussed this earlier in Chapter 4, Network Design, but ensure
that you separate your workloads of storage and management trafc
such as iSCSI, vMotion, and others, while leveraging VLAN tagging as
appropriate. To get the highest throughput and bandwidth you should use a
paravirtualized vNIC for high performance workloads. Each of these actions
will require effort on the part of the operating system and conguration but
certain applications do require high network load and networks do have
hard limitations in how much throughput they can handle per interface.
Lastly, if you have co-located applications that generate excessive
network load between each other, consider hosting them adjacent to each
other as network transactions, which traverse the same vSwitch operate
inline as memory operations not going at NIC speed and can improve
performance signicantly.
Ensuring high availability and application
resiliency
Once you have an established business critical application, the sole function of
your infrastructure beyond this point is not only to ensure that it operates within
the performance thresholds you designed it for; it is to ensure that it remains
up at all times. VMware has multiple features to help ensure that your service
continues to operate even when things start to fail, starting with VMware vSphere
High Availability (HA), which is a feature that protects against OS or hardware
failure. That means, should your VM fail or the ESXi host it resides on fail, the
virtual machine will be restarted on another host. This is similar to how Microsoft
Clustering is used to protect against hardware failure without all of the complex
congurations associated. To advance this further, VMware vSphere HA offers
a VM monitoring function that provides application insight if the VMware tools
application heartbeat should exceed a certain threshold. This requires integration
with a third-party product such as App-Aware or NeverFail.
If an application requires a zero-downtime mirroring instances, you can leverage
VMware vSphere FT, which has an identical instance of a virtual machine running
in tandem. Details on how to leverage VMware FT are detailed in KB1013428
and should you look to leverage this extensively, refer to VMware's Whitepaper
Protecting Mission-Critical Workloads with VMware Fault Tolerance at
http://www.vmware.com/files/pdf/resources/ft_virtualization_wp.pdf.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Chapter 6
[ 77 ]
In addition to the mentioned functions, VMware vSphere DRS will be a critical
member of ensuring availability of your business critical applications. In the past,
DRS was not supported by application vendors such as Microsoft to support
the migration of virtual machines between servers, but this is no longer an issue
plaguing environments and can be fully leveraged. With DRS leveraged, if you
should experience any resource faults with resource starvation, the virtual machines
can be relocated to other hosts to limit these challenges.
Enabling CPU Hot Add in vSphere client
One feature that is advised not to be run on noncritical applications, but can have a
signicant impact on some business and mission critical, unable to accept even the
smallest downtime is VMware vSphere Hot Add. VMware Hot Add is a capability
that lets you assign additional virtual machine memory or Hot Plug virtual CPUs
without having to incur an outage to increase the resources. There are some
considerations when using this feature such as the guest VM has to be shut down
to enable this feature, and not all guest operating systems support this feature. The
previous screenshot (Enable CPU Hot Add in vSphere Client) shows how this is
congured via the vSphere web client.
Some applications have native functions intended to be used for resiliency of
the service. These functions should be determined and architected for if their
functionality supports your business needs, especially if these capabilities exceed
those found within the native functionality of vSphere. Some examples of that
being if your organization is leveraging Microsoft Exchange DAGs to replicate a
copy of your database to a remote datacenter that provides a benet above what
HA is providing locally. In situations like that, Microsoft Exchange DAGs and
LAGs should be leveraged over implementing storage replication and using the
features of VMware Site Recovery Manager (SRM). In another circumstance, if
you're leveraging Microsoft Clustering services for Microsoft SQL, but are not using
Database Mirroring, you'll nd more value for your dollar by simply allowing HA
and DRS to handle the server in the event of a failure as you're gaining no additional
resiliency with this implementation.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Business Critical Applications
[ 78 ]
There are plenty of solutions for resiliency and capabilities native to the applications
that we've discussed in this chapter and also refer to cited in some of the links within
here that should be reviewed and determined whether your production environment
will call for these.
Lastly, the most often overlooked and quite possibly the most important aspect of
ensuring application availability and resiliency of your environment falls on what
your monitoring solutions are and how they're leveraged. There are numerous tools
to monitor your infrastructure and your application environment, two of those
are Microsoft System Center Operations Manager (SCOM) and VMware vCenter
Operations Manager (vCOPS). These tools allow you to monitor the applications,
their historical usage over time, as well as down to event-driven heartbeats and
application availability.
The vCenter operations manager dashboard
It is outside the scope of this book to detail every possible situation with which to
leverage SCOM and vCOPS. However, remember that these tools will allow you
to monitor your application and infrastructure performance and ensure that the
reliability you expect is being achieved.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Chapter 6
[ 79 ]
Other business critical application
resources
VMware has a pretty extensive and detailed white paper covering Virtualizing
Business-Critical Applications on vSphere covering Microsoft Exchange, SQL,
SharePoint, Oracle, SAP, Java, and Hadoop. This resource should be leveraged in
addition to this chapter to help address your business critical application needs as
it addresses in detail how licensing, support, and other items are handled. Refer
to http://www.vmware.com/files/pdf/solutions/VMware-Virtualizing-
Business-Critical-Apps-on-VMware_en-wp.pdf for more details.
Summary
By the end of this chapter, you should be able to identify which of your VMs
are business critical applications and ensure that their deployment meets your
architectural considerations. You should also have a better understanding of
what best practices are and when better practices apply to meet your business
critical workload.
In the next chapter, we look into what disaster recovery is and business continuance
to keep your infrastructure running even in the worst of situations.


For More Information:
www.packtpub.com/vsphere-design-best-practices/book

Where to buy this book
You can buy vSphere Design Best Practices from the Packt Publishing website:
http://www.packtpub.com/vsphere-design-best-practices/book.
Free shipping to the US, UK, Europe and selected Asian countries. For more information, please
read our shipping policy.
Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and
most internet book retailers.



















www.PacktPub.com


For More Information:
www.packtpub.com/vsphere-design-best-practices/book