• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

5.5

Building a hyper-converged platform using VMware technology part 1

Duncan Epping · Jan 22, 2014 ·

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. [Read more…] about Building a hyper-converged platform using VMware technology part 1

Virtual SAN Datastore Calculator

Duncan Epping · Jan 17, 2014 ·

Over a week ago I wrote an article around how to size your Virtual SAN Datastore. I included an equation to help everyone who is going through the same exercise. I figured I should be able to make life even easier by creating a simple Virtual SAN Datastore calculator based on this equation.

<EDIT> VMware has launched a great calculator. My tool served as a temporary solution as there was no calculator available, now that there is I highly recommend using the official tool: http://virtualsansizing.vmware.com/ </EDIT>

Virtual SAN Read IO – cache / buffer / spindles

Duncan Epping · Jan 15, 2014 ·

I had a question around how Virtual SAN read IO is handled when data can be anywhere: read cache, write buffer, disks. On VMTN one of the engineers recently explained this. I figured I would create a quick diagram to illustrate it. Basically how it works is that VSAN will check the read cache, if the block that needs to be read is not available in the read cache it will check whether the block is in the write buffer or on disk. Simple right?

In the scenario I drew below two blocks needs to be read. Block 1 is actively served by ESXi-01 and Block 2 is actively served by ESXi-03. In the case of ESXi-01 the block resides in the read cache so it is read from the cache. In the case of ESXi-03 it is not in the read cache and neither in the write buffer, hence it is read from the magnetic disks. Do note that this is 1 virtual machine, so reads are being served from 2 hosts and depending who is actively serving IO for that block the block can reside on that host in the read cache. The host which is not actively serving IO for that block will also not place the block in the read cache! (Of course if the host which is actively serving IO for a block fails the other host will take over.)

I hope that helps.

How to remove a host from your Virtual SAN cluster

Duncan Epping · Jan 14, 2014 ·

The question “How to remove a host from your Virtual SAN cluster” has now popped up various times, so I figured I would write a short article around what the current procedure is. It is fairly straight forward to be honest, here we go:

  1. Place host in maintenance mode
  2. Delete disk group when “maintenance mode” is completed
  3. Move host out of the cluster
  4. Remove the VSAN VMkernel (not a requirement, but I prefer to clean things up)

That is it, now you can re-purpose the host for anything else.

How to calculate what your Virtual SAN datastore size should be

Duncan Epping · Jan 8, 2014 ·

I have had this question so many times I figured I would write an article about it, how to calculate what your Virtual SAN datastore size should be? Ultimate this determines which kind of server hardware you can use, which disk controller you need and which disks… So it is important that you get it right. I know the VMware Technical Marketing team is developing collateral around this topic, when that has been published I will add a link here. Lets start with a quote by Christian Dickmann one of our engineers as it is the foundation of this article:

In Virtual SAN your whole cluster acts as a hot-spare

Personally I like to work top-down, meaning that I start with an average for virtual machines or a total combined number. Lets take an example to go through the exercise, makes it a bit easier to digest.

Lets assume the average VM disk size is 50GB. On average the VMs have 4GB of memory provisioned. And we have 100 virtual machines in total that we want to run on a 4 host cluster. Based on that info the formula would look something like this:

(total number of VMs * average VM size) + (total number of VMs * average VM memory size) = total capacity required

In our case that would be:

(100 * 50GB) + (100 * 4GB) = 5400 GB

So that is it? Well not really, like every storage / file system there is some overhead and we will need to take the “failures to tolerate” in to account. If I set my “failures to tolerate” to 1 than I would have 2 copies of my VMs, this means I need 5400 GB * 2 = . Personally I also add an additional 10% in disk capacity to ensure we have room for things like: meta data, log files, vmx files and some small snapshots when required. Note that VSAN by default provisions all VMDKs as thin objects (note that swap files are thick, Cormac explained that here), so there should be room available regardless. Better safe than sorry though. This means that 10800 GB actually becomes 11880 GB. I prefer to round this up to 12TB. The formula I have been using thus looks as follows:

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

Now the next step is to see how you divide that across your hosts. I mentioned we would have 4 hosts in our cluster. We have two options, we create a cluster that can re-protect itself after a full host failure or we create cluster that cannot. Just to clarify, in order to have 1 host of spare capacity available we will need to divide the total capacity by 3 instead of 4. Lets look at those two options, and what the impact is:

  • 12TB / 3 hosts = 4TB per host (for each of the 4 hosts)
    • Allows you re-protect (sync/mirror) all virtual machine objects even when you lose a full host
    • All virtual machines will maintain availability levels when doing maintenance
    • Requires an additional 1TB per host!
  • 12TB / 4 hosts = 3TB per host (for each of the 4 hosts)
    • If all disk space is consumed, when a host fails virtual machines cannot be “re-protected” as there would be no capacity to sync/mirror the objects again
    • When entering maintenance mode data availability cannot be maintained as there would be no room to sync/mirror the objects to another disk

Now if you look at the numbers, we are talking about an additional 1TB per host. With 4 hosts, and lets assume we are using 2.5″ SAS 900GB Hitachi drives that would be 4 additional drives, at a cost of around 1000 per drive. When using 3.5″ SATA drives the cost would be a lot lower even. Although this is just a number I found on the internet it does illustrate that the cost of providing additional availability could be small. Prices could differ though depending on the server brand used. But even at double the cost, I would go for the additional drive and as such additional “hot spare capacity”.

To make life a bit easier I created a calculator. I hope this helps everyone who is looking at configuring hosts for their Virtual SAN based infrastructure.

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 7
  • Page 8
  • Page 9
  • Page 10
  • Page 11
  • Interim pages omitted …
  • Page 16
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Advertisements




Copyright Yellow-Bricks.com © 2025 · Log in