Yellow Bricks

by Duncan Epping

Server

Dedupe and Checksumming in VSAN beta, what about Compression? Yup!

· ·

I was talking to our engineering team a couple of weeks ago with regards to our upcoming beta. During a demo I noticed that in our UI it said “Space Efficiency” instead of deduplication. After some discussions it became clear to me why that is… It isn’t “just” deduplication which will be in the upcoming beta for Virtual SAN, but the engineering team managed to also get compression in there. Huge accomplishment if you ask me and I hope this will make the official next release.

So where does compression fit? Compression happens after deduplication and we expect to store 2KB for every unique 4KB block. Combine this with “RAID5/6” over the network, aka “erasure coding” and with deduplication and thin provisioning and I bet you will see significant space savings! Great new functionality (if and when released), which will especially make the all-flash configuration a no-brainer if you ask me. Especially with flash prices still dropping and the price being almost on the same level as SAS drives these days it will make this a very compelling solution.

SMP-FT support for Virtual SAN ROBO configurations

· ·

When we announced Virtual SAN 2-node ROBO configurations at VMworld we received a lot of great feedback and responses. A lot of people asked if SMP-FT was supported in that configuration. Apparently many of the customers using ROBO still have legacy applications which can use some form of extra protection against a host failure etc. The Virtual SAN team had not anticipated this and had not tested this explicit scenario unfortunately so our response had to be: not supported today.

We took the feedback to the engineering and QA team and these guys managed to do full end-to-end tests for SMP-FT on 2-node Virtual SAN ROBO configurations. Proud to announce that as of today this is now fully supported with Virtual SAN 6.1! I want to point out that still all SMP-FT requirements do apply, which means 10GbE for SMPT-FT! Nevertheless, if you have the need to provide that extra level of availability for certain workloads, now you can!

Dell FX2 platform certified for VSAN with storage blades!

· ·

A couple of weeks ago the Dell FX2 disk controller was added to the Virtual SAN Compatibility Guide and shortly after the Ready Node configurations were added. For those who haven’t looked at the Dell FX2 platform, it is (in my opinion)  hyper-converged on steroids. Not only can it provide you with 4 compute nodes in 2U it also packs a 10GbE switch and can hold two storage blades with each 16 disks in it. What? Yes indeed, that is a lot of horse power in a single system.

I am working with a customer right now who is designing a new cluster configuration leveraging the Dell FX2 platform. In this case they are planning on 16 hosts in total. In their case after assessing their current workloads they are going with the FC430 E5-2670 v3 series with 12 cores (dual processor). Each host will have 256GB of memory and uses SD to boot from.

From a storage perspective they are looking to use the FD332 storage blades. Two per FX2 chassis, fully maxed out with 32 drives in total, which is 8 drives per host. All-flash by the way, leveraging 1.6TB devices for the capacity tier and 400GB devices for the write cache. Yes that is 38.4TB raw capacity per FX2 chassis, times 4… ~153TB.Not a coincidence that the configuration is very similar to the “AF-6 Series – Dell FX2 Platform”, they prefer to use a certified and tested solution instead of picking their own components, which makes sense if you ask me.

One of the key reasons for them to go with all-flash is the beta which is coming up. They want to get their hands dirty with functionality like deduplication, checksumming and RAID-5/6 (aka erasure coding) as soon as possible. All 4 chassis will run in one site first for testing purposes for now and they are considering after the initial tests to deploy them across two sites in a stretched configuration. They asked me what the big benefit was of RAID-5 or RAID-6 over the network (aka erasure coding) and it definitely is the lower raw capacity requirements it will lead to. If you look at the current FTT=1 implementation it means that a 20GB disk requires an additional 20GB for availability reasons, which means 40GB in total. With an RAID-5 implementation instead of RAID-1 this 20GB disk would only require 26.6GB of disk space, that is a savings of almost 14GB immediately. And that is before any type of space efficiency (dedupe) is enabled. Anyway, back to the FX2.

So far only “all-flash” has made it to VSAN Ready Node list, and of course components are also listed as in the disk controller “FD332-PERC” (single and dual ROC) and I’ve seen the 1.8″ flash devices also on the list. Waiting to see what one of these boxes would cost in an all-flash configuration, and hoping to also see a hybrid configuration soon. I’m a fan of the Dell FX2 systems, that is for sure.

2 is the minimum number of hosts for VSAN if you ask me

· ·

In 2013 I wrote an article about the minimum number of hosts for Virtual SAN. Since then this post has started living its own life. Somehow people have misunderstood my post and used/abused it in many shapes and forms. When I look at the size of a traditional cluster (non-VSAN) the minimum size is 2. From an availability perspective I ask myself what is the risk I am willing to take. What does that mean?

In a previous life I did many projects for SMB customers. My SMB customers typically had somewhat in the range of 2-5 hosts. With the majority having 2-3. In many cases those having 2-3 hosts were running roughly a similar number of virtual machines. The difference between the two situations “2 hosts” versus “3 hosts” was whether during times of maintenance (upgrading / updating) or failure if the ability to restart the virtual machine after a secondary failure. Many customers decided to go with 2 node clusters. Key reason for it being price vs risk. At normal operations risk is low, but the price of an additional host was relatively high.

Now compare this to Virtual SAN and you will see the same applies. With Virtual SAN we have a minimum of 3 hosts, well in a ROBO configuration you can have 2 with an external witness. This means that from a support perspective the bare minimum of dedicated physical hosts required for VSAN is 2. There you go, 2 is the bare minimum for ROBO. For non-ROBO 3 is the minimum. Fully supported, offers all functionality and similar to 4 hosts.

Is having an extra host a good plan? Yes of course it is. HA / DRS / VSAN (and any other scale-out storage solution for that matter) will benefit from more hosts. You as a customer need to ask yourself what the risk is, and if the cost is justifiable.

PS1: A question just came in, want to make that it is clear. Even in a 2-host ROBO configuration you can do maintenance! A single copy of the data and the witness remains available and will have quorum.

PS2: No, you cannot host your “witness” VM on the VSAN cluster itself, this is not supported as the witness is the quorom for the cluster and it should be outside of the cluster to provide certainty of the state in the case of a failure.

VSAN made storage management a non issue for the 1st time

· ·

When ever I talk to customers about Virtual SAN the question that comes up usually is why Virtual SAN? Some of you may expect it to be performance, or the scale-out aspect, or the resiliency… None of that is the biggest differentiator in my opinion, management truly is. Or should I say the fact that you can literally forget about it after you have configured it? Yes, of course that is something you expect every vendor to say about their own product. I think the reply of one of the users during the VSAN Chat that was held last week is the biggest testimony I can provide: “VSAN made storage management a non-issue for the first time for the vSphere cluster admin”. (see tweet below)

When we released the first version of Virtual SAN I strongly believed we had a winner on our hands. It was so simple to configure, you don’t need to be a VCP to enable VSAN, it is two clicks. Of course VSAN is a bit more than just that tick box on a cluster level that says “enable”. You want to make sure it performs well, all drivers/firmware combinations are certified, the network is correctly configured etc. Fortunately we also have a solution for that, this isn’t a manual process.

No, you simply go to the VSAN healthcheck section on your VSAN cluster object and validate everything is green. Besides simply looking at those green checks, you can also run certain pro-active tests that will allow you to test for instance multicast performance, VM creation, VSAN performance etc. It all comes as part of vCenter Server as of the 6.0 U1 release. On top of that there is more planned. At VMworld we already hinted at it, advanced performance management inside vCenter based on a distributed and decentralized model. You can expect that at some point in the near future, and of course we have the vROps pack for Virtual SAN if you prefer that!

No, if you ask me, the biggest differentiator definitely is management… simplicity is the key theme, and I guarantee that things will only improve with each release.