Building a hyper-converged platform using VMware technology part 1

I have been working on a slidedeck lately that explains how to build a hyper-converged platform using VMware technology. Of course it is heavily focusing on Virtual SAN as that is one of the core components in the stack. I created the slidedeck based on discussions I have had with various customers and partners who were looking to architect a platform for their datacenters that they could easily repeat. A platform which had a nice form factor and allowed them to scale out and up. Something that could be used in a full size datacenter, but also in smaller SMB type environments or ROBO deployments even.

I guess it makes sense to start with explaining what hyper-converged means to me, although I already wrote various articles on this topic a while back. I explicitly say “to me” as I am sure many folks will have a different opinion on this. A hyper-converged platform is an appliance type of solution where a single box provides a platform for virtual machines. This box typically contains multiple generic x86 hosts (trying to avoid using the word commodity) on which a hypervisor is installed, local storage which is aggregated in to a large shared pool, and network ports. Note that typically network switching is not included in the box itself, well except for virtual switches. In order to aggregate storage in to a large shared pool an additional piece of software is required. Typical examples of hyper-converged platforms which are out there today are Nutanix, SimpliVity and Pivot .

The question than arises if these are “just” x86 boxes with hypervisors installed and storage software, what are the benefits over a regular environment? Those benefits in my opinion are:

• Time to market is short, < 4hrs to install / deploy (probably much faster for the majority)
• Easy of management and integration
• Scale out, both capacity and performance wise
• Typically more affordable (results will vary)

Sounds like a done deal right? Easier, cheaper and faster… It is fair to say that these are great solutions for many companies as they provide you with one throat to choke. With that meaning it is a single SKU offering and which includes a single point of contact for support in most cases. Only downside I have heard from some partners and customers is that these solutions are typically tied to hardware and specific configurations, which is not always the same as your preferred supplier and probably not the exact configuration you prefer. This could lead to operational challenges when it comes to updating / patching, which probably doesn’t make the operational team happy. On top of that there is the “trust” issue. Some people swear by HP and would never ever want to touch any other brand, while others won’t come close to it. That is a matter of experience and personal taste I guess. Where is all of this leading to? Well here is, in my opinion, where Virtual SAN / VSAN comes in.

Virtual SAN / VSAN as available in beta today allows you to pick and choose your own hardware vendor, your own components and size it so that it meets your requirements and also your budget. (Before anyone asks, pricing and packaging of VSAN has not been announced yet.) So where do you start if you want to build a hyper-converged platform for your customers as a partner or as a customer for your own consumption? Well lets start with which VMware products and features one can leverage!

• ESXi 5.5
• vCenter Server 5.5
  • vSphere HA
  • vSphere DRS + vMotion
  • VASA + VM Storage Policies
  • Distributed Switch + Network IO Control
• Virtual SAN

That would be the core of your stack from a software point of view, but you can include things like vCenter Orchestrator, VC Ops, vSphere Replication, vSphere Data Protection and so on but lets focus on the core and how to build a solution. I am hoping all of you are familiar by now with the components listed so I am not going to explain them in-depth. I will however briefly touch on why I feel these are recommended. vSphere HA is a no-brainer, availability is key in the majority of environments out there. vSphere DRS and vMotion will be used to ensure that virtual machines will receive the resources they are demanding and will allow us to do things like placing a host in maintenance mode without any disruption to the workload. The Distributed Switch and Network IO Control will provide us an easy to manage virtual switching solution that includes Quality of Service based on shares assigned to traffic streams. This can be useful with Virtual SAN as we want to make sure VSAN receives the resources it requires from a networking perspective. VSAN itself would be needed to aggregate the various local disk resources in to one large pool.

But how does all of that relate to hardware? I posted an article a week ago that explains how to get from an average VM disk size to the number of disks required for VSAN per host. For an in-depth explanation I would like to refer to that. Lets take a random scenario and look at our options.

• 1.5 vCPU on average per VM
• 5 GB of memory per VM
• 50 GB of disk per VM
• Failures to tolerate = 1

We would like to run 100 VMs. This means we require a total of:

• 100 x 1.5 vCPUs = 30 cores
• 500GB of memory
• 11.8 TB of disk space

How did I get there? From a vCPU perspective I want to have 5 vCPUs per core at most. This means that I divide 150 by 5 and the result is a minimum of 30 cores. From a memory perspective the 500GB is straight forward, I am not going to take TPS in to account in this case just to keep the calculation easy. And there is the 11.8 TB disk capacity requirement.  How did I get there? I used the equation I developed in my sizing blog post:

(((Number of VMs * Avg VM size) + (Number of VMs * Avg mem size)) * FTT+1) + 10%

In my case that results in: (((100 * 50) + (100 * 5)) * 2) = (5000 + 500) * 2 = 12100 GB + 10% / 1024 = 11.8TB

(I used this VSAN Datastore Calculator)

Now that we know what we roughly need in terms of capacity, how do we tie things together? I will discuss that in Part 2 of this series!