Tuesday, August 19, 2014

VMware Virtual SAN

VMware is trying to change the operational model of storage. VMware is introducing a virtual data plane to abstract and pool the physical storage resources to make things easier from an operational standpoint, and much simpler for the IT professional. From Virtual Data Services perspective, VMware is trying to make things more VM centric and provide services like data protection, performance, and mobility.

One of the big keys to software-define storage is the Policy-driven Control Plane, the capability of provisioning storage based on VM business requirements and orchestrating the entire process.

VMware Virtual SAN is pretty unique in the marketplace; it allows you to aggregate locally attached storage from each ESXi host in a cluster, with a flash optimized storage layer. VSAN was designed for resiliency with a Distributed RAID Architecture to help ensure no single points of failure. I will discuss this further, later in the post.

Virtual SAN is not a traditional virtual storage appliance (VSA); it is fully integrated into vSphere, with drivers embedded in ESXi 5.5 that contain the Virtual SAN smarts.

Lowering TCO with Virtual SAN comes down to hardware. For VSAN, there is a requirement for magnetic devices, flash devices, network cards, storage controllers that support pass-through mode or RAID0 mode, and it is recommended to install ESXi on a 4 GB to 8 GB USB, SD card, or SATADOM. The minimum amount of hosts is 3, which are contributing storage; this is an important consideration when thinking about VSAN for remote and branch offices, and small business with just a few virtual instances. Virtual SAN may not meet those specific use cases.

All of the read and write operations go directly to the flash tier. The magnetic tier is to retain persistent data. The way VSAN utilizes the flash devices is as a write buffer and a read cache. 30% of the flash device is used as the write buffer, which reduces latency for writes. 70% is used for Read Cache, which helps reduce the read latency. If there is a cache miss, the data is then retrieved from the magnetic disks. The better quality of the components used, the better performance you will get out of Virtual SAN. For example, it is recommended to use NL SAS drives if choosing between SATA and NL SAS. NL SAS will provide higher HDD controller queue depth at same drive rotational speed and similar price point. The same holds true with storage controller queue depth, higher storage controller queue depth will increase performance.

When thinking about the networking, 1 Gb and 10 Gb networking is supported, but if you have the option select 10 Gb. Depending on the size of the environment and the number of virtual machines, you can easily saturate a 1 Gb link. The network bandwidth performance has a greater impact on host evacuations, than on workload performance.

With a 10 Gb shared connection, you should leverage NIOC for QoS. The below example shows shares allocated to the Management, Virtual Machine, vMotion, and Virtual SAN port groups.

Like mentioned previously, Virtual SAN uses a Storage Policy-based Management framework, which is built into vSphere to enable virtual machine policy-driven provisioning. It leverages this framework in conjunction with VASA API's to expose storage characteristics to vCenter.

Virtual SAN currently surfaces five unique storage capabilities.
  • Number of disk stripes per object
  • Flash read cache reservation (%)
  • Number of failures to tolerate
  • Force provisioning
  • Object space reservations (%)

A Distributed RAID Architecture is utilized to distribute data across the cluster. Components are distributed by using two primary techniques, mirroring (RAID1) and stripping (RAID0). The number of component replicas and copies created is based on the object policy definition.

The Number of failures to tolerate translates to an availability factor. It defines the number of hosts, disks, or network failures a storage object can tolerate. For "n" failures tolerated, "n+1" copies of the object are created and "2n+1" host contributing storage are copied. That is part of the reason why the minimum requirement of hosts is 3. By default, the Number of failures to tolerate is 1, which creates replica copies and a witness.

The other major policy is the Number of disk stripes per object, which amounts to the number of magnetic drives across which each replica of a storage object is distributed. Higher values should result in better performance. This makes up for performance, once you have run out at the flash layer.

If Force provisioning is set yes, the object will be provisioned even if the policy specified is not satisfiable with the resources currently available.

Flash read cache reservation (%) is capacity reserved as read cache for the storage object. Specified as a percentage of logical size of the object. You want to be very carefully about the amount of Flash read cache reservation (%) you allocate, when allocating a large part of the flash to a read cache reservation it is taking that part of the flash allocation out the shared pool, which will affect overall performance. It is recommend not to allocate a Flash read cache reservation (%) unless their is a specific application requirement.

And last, Object space reservation (%) is the percentage of the logical size of the storage object that will be reserved (thick provisioned) up VM provisioning. The rest of the storage object is thin provisioned.

This is my last post before VMworld! If you are going to the event, I hope I see you out there.
News: Top vBlog 2016 Trending: DRS Advanced Settings