vSphere Design 101: Back to Basics
This year, I was able to attend VMware Partner Exchange 2014 in San Francisco and took one of the boot camps that comes before the actual PEX event. This particular boot camp is the vSphere Design Boot Camp. There are a lot of things that go into designing a vSphere implementation properly to get the best bang for your buck. In this article I’ll only be able to include some of them, but enough to get people thinking about any new implementations or how to improve existing ones.
Let’s dive into the first things we need be concerned about:
Availability Includes redundancy and access to the necessary applications and servers within your environment. This can include high availability (HA) and redundancy.
For example, if you’re working in an SMB this might mean having enough hosts available if you have an entire host go down. You would want to make sure your HA is set up properly with Admission Controls that are appropriate for your environment.
If you’re in a larger environment you might want to consider Active/Active sites using solutions like VPLEX or some other stretched clustering solution.
This answers the question whether your implementation is easy to administer and possibly easy to use for junior admins and/or end users.
Can we back it up and restore it properly in a sufficient amount of time? Consider Recovery Point Objective (RPO) and Recovery Time Ojective (RTO). It would be great if we could recover everything immediately with no data loss, but that often costs a lot of money. So you need to decide what is good for your business.
- RPO – How much data loss is acceptable? For example if you have an RPO of one hour and your site goes down at 4pm, it would be acceptable to recover the data from 3pm. This would mean an hour’s worth of data loss
- RTO – How much down time is acceptable? Again, if your site goes down at 4pm and you have a four hour RTO, your site would need to be accessible by 8pm.
Are we meeting the security standards for our company? This could be very important to companies that need to be in compliance with standards like PCI or ISO270001, for example. We would want to consider what kind of firewalls we’re using and if we want to use something like vCNS or vShield along with traditional hardware firewall appliances.
We would do anything we wanted if budget wasn’t a consideration. How can we optimize our implementation while maintaining our budget. We may also need to consider Return On Investment (ROI).
After the Basics Comes the Harder Elements…
The next things we need to consider are Assumptions, Constraints, and Risks.
Assumptions can be obvious, but often times are not. Assumptions are things we need to be aware of from the beginning of a project, but often may not be answered immediately. Some examples of assumptions we might have are:
- We have proper networking gear that will allow us to create new VLANs and/or subnets
- We have expertise available in-house to use any new software or hardware with or without training
- We’re able to get the proper power for our servers, storage, and other hardware
Constraints can include:
- Budget. This is often one of the biggest constraints
- Unable to use Fibre Channel
- Previously purchased hardware that must be used
Risks are things we may have to accept due to our constraints and may or may not be acceptable. Examples of risk are:
- Single points of failure in storage, servers, networking, or even personnel
- Lower/longer SLAs
- Bandwidth utilization (or rather over-utilization)
While keeping all of these things in mind, how do we design a new or improved infrastructure for our environment? Chris Wahl recently wrote a post, which I highly recommend reading, called Leveraging Tools on the Go. It includes many of the tools that consultants regularly use to size and design an environment, but he talks about tools that are universally available to customers, partners, and vendors alike. Some of these tools include RV Tools. We can also use tools within our OS such as Perfmon in Windows. These tools will give us a good idea of what our environment looks like. Another VMware tool available to the masses, at least in eval mode, would be vCenter Operations Manager. Specifically using the vCops capacity planning tools we can even model what growth might look like using the What-if Scenarios and trending.
The What-if scenarios let us show what it would look like to add or remove a particular number of VMs within our current environment. We can then also model what it looks like to add or remove hosts or datastores as well.
A very basic example would be if we had physical and virtual machines using 10TB of SAS disks on our current SAN. We can then find out how many vCPUs and memory we’re using in our current virtual environment by using RV Tools. We can either just count this in our physical environment or use the OS tools to get a more accurate number. Once we’ve figured all that out and added it together, we’re able to figure out the hardware we need to accommodate our current environment and any future growth.
Something else to keep in mind is CPU contention. We generally don’t want more than a 4-6:1 ratio when it comes to VMs to CPU cores in a vSphere 5.1 and up environment. For example, if we have 10 vCPUs residing on one host with only 4 cores, we have a 2.5:1 CPU ratio which is pretty good. SCSI reservation contention in the storage would also be a concern. If we’re considering something like Horizon View we could probably even get away with a 10:1 ratio in more recent versions.
This is obviously a very simplistic example of how to size an environment, but will definitely get you started. There’s a lot that goes into sizing a VMware and hardware infrastructure implementation properly. Check out this Performance Best Practices guide from VMware for more information, but keep in mind you may have constraints or risks to take into consideration.