Yellow Bricks

by Duncan Epping

hyperconverged

What if the disk controller driver included in my vendor’s ESXi image is not on the vSAN HCL?

· ·

Sometimes unfortunately there are situations where a vendor’s ESXi image includes a disk controller driver that is not on the vSAN HCL/VCG (VMware Compatibility Guide). Typically it is a new version of the driver which is supported for vSphere, but not yet for vSAN. In that situation, what should you do? So far there are two approaches I have seen customers take:

  1. Keep running with the included driver and wait for the driver to be supported and listed on the vSAN HCL/VCG
  2. Downgrade the driver to the version which is listed on the vSAN HCL/VCG

Personally, I feel that option 2 is the correct way to go. The reason is simple, vSphere and vSAN have different certification requirements for disk controllers and the vSAN certification criteria are just more stringent than vSphere’s. Hence, sometimes you see vSAN skipping certain versions of drivers, this usually means a version did not pass the tests. Now, of course, you could keep running the driver and wait for it to appear on the vSAN HCL/VC. If however, you hit a problem, VMware Support will always ask you first to bring the environment to a fully supported state. Personally, I would not want the extra stress while troubleshooting. But that is my experience and preference. Just to be clear, from a VMware stance, there’s only one option, and that is option two, downgrade to the supported version!

Does a vSAN IO Limit impact resync traffic?

· ·

A question just came in, and I figured other people may have the same question so I would share it. The question was if a vSAN IO limit would impact resync traffic or for instance SvMotion? In this case the customer defines limits within each policy to ensure VMs do not interfere with other VMs or excessively uses IO resources. Especially in cloud environments this can be useful, or when running production and test/dev on the same cluster. The concern, of course, was if this limit would impact for instance recovery times after a failure. Because you can imagine that a limit of 50 IOPS would be devastating when a VM (or multiple VMs) need to have objects resynced.

The answer is simple: no, the IO limit specified within a policy does not impact resync traffic (or SvMotion for that matter). It only applies to Guest IO to a VMDK, namespace or swap object. Which means that it is safe to set limits when it comes to recovery times.

Virtual SAN Ready Nodes taking charge!

· ·

Yes that is right, Virtual SAN Ready Nodes are taking charge! As of today when you visit the VMware Compatibility Guide for Virtual SAN it will all revolve around Virtual SAN Ready Nodes instead of individual components. You may ask yourself why that is, well basically because we want to make it easier for you to purchase the hardware needed while removing the complexity of selecting components. This means that if you are a Dell customer and want to run Virtual SAN you can simply select Dell in the VMware Compatibility Guide and then look at the different models there are of the different sizes. It is very easy as can be seen in the screenshot below.

virtual san ready nodes

Traditionally there were 3 different sizes for “Server Virtualization”, but with the full overhaul of the VSAN VCG a new size was added. The naming of the sizing has also changed. Let me explain what it looks like now, note that these “sizing profiles” are the same across all vendors so comparing HP to Dell or IBM (etc) was never easier!

New NameOld Name
HY-2Hybrid Server Low
HY-4** new **
HY-6Hybrid Server Medium
HY-8Hybrid Server High
HY-8Hybrid VDI Linked Clones
Hybrid VDI Full Clones
AF-6All Flash Server Medium
AF-8All Flash Server High
AF VDI Linked Clones
AF VDI Full Clones

The new model introduced is HY-4 Series, the reason this model was introduced is because some customers felt that the price difference between HY-2 and H&-6 was too big. By introducing a model in between we now cover all price ranges. Note that it is still possible when selecting the models to make changes to the configuration. If you want model HY-2 with an additional 2 disks, or with 128GB of memory instead of 32GB then you can simply request this.

So what are we talking about in terms of capacity etc? Of course this is all documented and listed on the VCG as well, but let me share it with you here also for your convenience. Note that performance and VM numbers may be different for your scenario, this of course will depend on your workload and the size of your VMs etc.

ModelCPU / MemStorage CapStorage PerfVMs per node
HY-21 x 6 core / 32GB2TB4000 IOPSUp to 20
HY-42 x 8 core / 128GB4TB10K IOPSUp to 30
HY-62 x 10 core / 256GB8TB20K IOPSUp to 50
HY-82 x 12 core / 348GB12TB40K IOPSUp to 100
AF-62x12 core / 256GB8TB50K IOPSUp to 60
AF-82x12 core / 348GB12TB80K IOPSUp to 120

In my opinion, this new “Ready Node” driven VMware Compatibility Guide driven approach is definitely 10 times easier then focusing on individual components. You pick the ready node that comes close to what you are looking for, provide your OEM with the SKU listed and tell them about any modifications needed in terms of CPU/Mem or Disk Capacity. PS: If you want to access the “old school HCL” then just click on the “Build Your Own based on Certified Components” link on the VCG page.

Extending your vSphere platform with Virtual SAN

· ·

Over the last couple of months I’ve spoken to many customers about Virtual SAN. What struck me during these conversations is how these customers spoke about Virtual SAN. In all cases when we start the conversation it starts with a conversation about what their environment used to looked like. What kind of storage they had. How it was configured, number of disks etc you name it. Of course we would discuss what kind of challenges they had with their legacy environment. Thinking back to these conversations there is one thing that really stood out, although never explicitly mentioned, the big difference between Virtual SAN and traditional storage systems is that Virtual SAN is not a storage system but rather an extension of the VMware vSphere Platform.

Source: Wiki
Software extension, a file containing programming that serves to extend the capabilities of or data available to a more basic program

I believe this statement is spot on. What is great about Virtual SAN is that it does the extension of the capabilities of vSphere in an extremely easy way. Virtual SAN achieves this simply by abstracting layers of complexity and pooling the resources and allow these to be assigned to workloads in an automated fashion whether through the use of policies and a simple UI or through the vSphere APIs. Keywords here are definitely: abstract, pool and automate.

Maybe I should have used the word “converging” instead of “abstracting”. That is essentially what is happening, and although many other vendors claim the same, I truly believe that Virtual SAN is one of the few solutions which is truly hyper-converged as it seamlessly converges layers instead of adding a layer on top of another layer. Hyper-convergence is more than just stacking layers in a single box.

With Virtual SAN storage is just there. Not bolted on, layered on top or mounted to the side, an integral part of your environment, an extension of your platform. Virtual SAN does for storage what vSphere does for CPU and Memory, it becomes a fundamental component of your cluster.

EVO:RAIL now also available through HP and HDS!

· ·

It is going to be a really short blog post, but as many folks have asked about this I figured it was worth a quick article. In the VMworld Europe 2014 keynote Pat Gelsinger today announced that both HP and Hitachi Data Systems have joined the VMware EVO:RAIL program. This is great news if you ask me for customers all throughout the world as it provides more options for procuring an EVO:RAIL hyper-converged infrastructure appliance through your preferred server vendor!

The family is growing: Dell, Fujitsy, Hitachi Data Systems, HP, Inspur, NetOne Systems and SuperMicro… who would you like to see next?