Vsphere design best practices pdf free download

Start your free trial. Book description Apply industry-accepted best practices to design reliable high-performance datacenters for your business needs In Detail vSphere allows you to transform your IT infrastructure into a private cloud, then bridge it to public clouds on-demand, delivering an IT infrastructure as an easily accessible service.

Table of contents Product information. Virtual Machine Design Virtual machine resources and templates Best practices for virtual machines and templates Over-allocation can be a painful proposition Physical to virtual migrations Multi-vCPU considerations Shares, limits, and reservations Configuring shares Limits Reservations Causes of virtual machine performance problems CPU performance issues Memory performance issues Storage performance issues Network performance issues Summary 6.

Latest Books. Articulate Storyline Essentials 18 June Beginning SharePoint Development 18 June Beginning SharePoint 18 June Popular Categories. Readers will learn design principles related to storage and storage protocols.

Moving on to networking, readers will learn to design flexible and reliable networks for their virtual datacenters. After this, Virtual Machine design considerations are reviewed in depth and readers are guided through inspecting existing VMs and design principles for correctly resourced and configured virtual machines.

What you will learn from this book Examine virtual datacenter design scenarios and understand the basics of vSphere clustering, HA, and DRS Compare and contrast scale-out versus scale-up designs Learn to map the storage Service Level Agreements SLAs to business requirements Get to know how to design flexible and reliable networks for virtual datacenters Inspect existing VMs and design principles to correctly resource and configure virtual machines Design different RPO and RTO requirements to plan and test the DR strategy Approach An easy-to-follow guide full of hands-on examples of real-world design best practices.

Each topic is explained and placed in context, and for the more inquisitive, there are more details on the concepts used. These interfaces are critical, a solid hardware design married with adaptive firmware can access all the capabilities of an application and overcome limitations caused by poor communication.

In order to scale higher, you need to use an external Oracle database server. It is also a much simpler deployment. If you are running Horizon View, then you'll need a Windows server for the View Composer service and a similar situation exists if you are running vCloud Director.

The general idea, though, is that the vCSA is easier to manage and is a purpose-built appliance. While vCSA may not be for everyone, but I would encourage you to at least consider it for your designs. If you're using the vCSA, this is less of an issue but there are still guidelines for disk space and memory as shown in the following table.

Note that this only applies to vCSA 5. The vCenter Server Appliance can be deployed with thin-provisioned virtual disks that can grow to the maximum size of 80 GB.

If the host machine does not have enough free disk space to accommodate the growth of the vCenter Server Appliance virtual disks, vCenter Server might cease operation, and you will not be able to manage your vSphere environment. Small hosts or virtual machines : This has a size of at least 8 GB. Medium hosts or virtual machines : This has a size of at least 16 GB.

If you are choosing a Windows-based vCenter, you need to size your machine appropriately based on the size of your environment. The number of clusters and VMs within a vCenter can absolutely affect performance. This is due to DRS calculations that must be made and more objects mean more calculations. Take this into account when estimating resource requirements for your vCenter to ensure performance and reliability.

Note that this only affects vCenter 5. The following VMware KB articles have up-to-date information for your specific vCenter version and should be referenced for vCenter sizing:. The vCenter database is the location where all configuration information, along with some performance, task, and event data, is stored.

As you might imagine, the vCenter DB can be a critical component to your virtual infrastructure. But it also can be disposable—although this is becoming a much less adopted strategy than it was a couple of years ago.

In some environments that weren't utilizing features like the Virtual Distributed Switch VDS and didn't have a high reliance on the stored event data, we saw that vCenter could be quickly and easily reinstalled from scratch without much of an impact. SSO is a new component introduced in vSphere 5.

If you haven't deployed 5. In vSphere 5. Again, sometimes in smaller deployments, it is OK to install the SQL DB on the vCenter server, but the general best practice is to have that dedicated database server for better protection, flexibility, and availability.

With vCenter 5. These two options are common for organizations that already have these databases in use for other applications.

Each database type has its own benefits and features. Choose the database that will be the easiest to manage while providing the features that are required. In general, any of the database choices are completely capable of providing the features and performance of vCenter.

This combination of automatic failover and workload balancing result in more effective and efficient use of resources. Providing high availability to your vSphere environment means making every reasonable effort to eliminate any single point of failure SPoF.

We can also distribute our hosts across multiple racks or blade chassis to guard against the failure of a rack or chassis bringing down an entire cluster. So not only is component redundancy important, but it is also important to look at the physical location. Some other items related to our hosts are using identical hardware. Although not always possible, such as hosts that have different lifecycles, we should make an effort to be consistent in our host hardware within a cluster.

Aside from simplifying configuration and management, hardware consistency reduces resource fragmentation. HA prepares for a worst-case scenario and plans for the largest host in a cluster to fail resulting in more resources being reserved for that HA event. This results in a lower efficiency in resource utilization. The next consideration with HA is the number of hosts in your design.

Some describe this as having a "hot spare", but in the case of vSphere, we're typically using all of the hosts to actively serve workload. In some cases, it can be acceptable to actually reserve a host or hosts for failover. This is truly a hot spare scenario where those designated hosts sit idle and are used only in the case of an HA event. This is an acceptable practice, but it isn't the most efficient use of resources. VMware vSphere 5. HA essentially reserves an entire hosts' worth of resources and then spreads that reservation across all hosts in the cluster.

For example, if you have two hosts in a cluster, 50 percent of the total cluster resources are reserved for HA. To put it another way, if one host fails, the other host needs to have enough resource capacity to service the entire workload. If you have three hosts in a cluster, then 33 percent of the resources are reserved in the cluster for HA. You may have picked up on the pattern that HA reserves resources for the cluster where N is equal to the number of hosts in the cluster.

As we increase the number of hosts in a cluster, we see a smaller percentage of resources reserved for HA that result in higher resource utilization. One could argue that larger clusters increase complexity but that is negated by the benefits of higher utilization.

The important takeaway here is to remember that these reserved resources need to be available to the hosts. If they are being used up by VMs and an HA event occurs, it is possible that VMs will not be restarted automatically and you'll experience downtime. Last, with respect to hosts, is versioning. It is absolutely recommended to have all hosts within a cluster at the same major and minor versions of ESXi, along with the same patch level. Mixed-host clusters are supported but because there are differences in HA, DRS, and other features, functional and performance issues can result.

If different host versions are required, it is recommended to separate those hosts into different clusters, that is, a cluster for 5. Specific to HA, there are several design considerations regarding the network. Also, Spanning Tree Protocol STP on network switches can take a significant amount of time to start passing traffic on a port. For example, if a host is rebooted, STP takes approximately 50 seconds to recalculate the topology on its connected switch ports, and while that calculation is occurring the host does not have network connectivity.

This can cause HA to report the host as dead and VMs will not start up on that host. This can also trigger an isolation response due to the datastore heartbeat. In either case, this can be prevented by enabling PortFast on those ports on the connected switches. Some switch vendors may call the feature something different, but the idea of PortFast is that STP will allow traffic to pass on those ports while it completes its calculations. HA relies on the management network of the hosts.

This brings with it several design considerations. Each host should be able to communicate with all other hosts' management interfaces within a cluster. Most of the time, this is not an issue because our network designs typically have all of our hosts' management VMkernel ports on the same layer 2 subnet, but there are scenarios where this is not the case. Therefore, it is important to make sure all hosts within a cluster can communicate properly to ensure proper HA functionality and prevent network partitions.

Along these same lines, we should be designing our networks so that we have the fewest possible number of hops between hosts. Additional hops, or hardware segments, can cause higher latency and increase points of failure.