I had a very interesting question recently about how vSAN handles a failure in an object that is running with an erasure coding configuration. In the case of vSAN this is either a RAID-5 or a RAID-6. On vSAN, a RAID-5 is implemented with 3 data segments and 1 parity segment (3+1), with parity striped across all four components. RAID-6 is implemented as 4 data segments and 2 parity segments (4+2), again with the parity striped across all of the six components. Now, on vSAN, RAID-5 requires 4 physical ESXi hosts for implementation, with each host backing one set of…
Some time ago, I wrote about which policy changes can trigger a rebuild of an object. This came up again recently, as it was something that Duncan and I covered in our VMworld 2017 session on top 10 vSAN considerations. In the original post (which is over 3 years old now), I highlighted items like increasing the stripe width, growing the read cache reservation (relevant only to hybrid vSAN) and changing FTT when the read cache reservation is non-zero (again only relevant to hybrid vSAN) which led to a rebuild of the object (or components within the object). The other…
I was looking at the layout of RAID-5 object configuration the other day, and while these objects were deployed on vSAN with 4 components, something caught my eye. It wasn’t the fact that there were 4 components, which is what one would expect since we implement RAID-5 as a 3+1, i.e. 3 data segments and 1 parity segment. No, what caught my eye was that one of the components had a different vote count. Now, RAID-5 and RAID-6 erasure coding configurations are not the same as RAID-1. With RAID-1, we deploy multiple copies of the data depending on how many…
I’ve recently been involved in some design and sizing for very large VMDKs on vSAN. There are a couple of things to keep in mind when doing this, not just the overhead when deciding to go with RAID1, RAID5 or RAID6, but also what this means for component counts. In the following post, I have done a few tests with some rather large RAID-5 and RAID-6 VMDKs, just to show you how we deal with it in vSAN. If you are involved in designing and sizing vSANs for large virtual machines, you might find this interesting.
Those of you familiar with VSAN will be aware that when it comes to virtual machine deployments, historically, objects on the VSAN datastore were deployed either as a RAID-0 (stripe) or a RAID-1 (mirror) or a combination of both. From a capacity perspective, this was quite an overhead. For instance, if I wanted my VM to tolerate 1 failure, I need two copies of the data. If I wanted my VM to tolerate 2 failures, I needed three copies of the data and if I wanted my VM to tolerate the maximum number of failures, which is 3, then I…
If you were wondering why my blogging has dropped off in recent months, wonder no more. I’ve been fully immersed in the next release of VSAN. Today VMware has just announced the launch of VSAN 6.2, the next version of VMware’s Virtual SAN product. It is almost 2.5 years since we launched the VSAN beta at VMworld 2013, and almost 2 years to the day since we officially GA’ed our first release of VSAN way back in March 2014. A lot has happened since then, with 3 distinct releases in that 2 year period (6.0, 6.1 and now 6.2). For…
Before Virtual SAN was generally available last year, the preceding VSAN beta program was one of the largest beta programs ever to take place at VMware. Today, a new beta program for VSAN was announced for 2015! This week, we’ve already announced a bunch of enhancements in VSAN 6.1 at VMworld 2015, including VSAN stretched cluster for high availability across data centers, a new 2-node VSAN model for remote-office/branch-office (ROBO), new hardware support for Intel NVMe and Diablo Ultra DIMM, and the additional features added to the health check plugin. You can read more about these announcements here. VMware has…