This is a guest post from Adam Sweetser, Senior Technical Support Engineer, vSAN GSS. Adam provides vSAN support to, and speaks with real customers day in and day out, about real-world issues.
vSphere is the enterprise-grade hypervisor that has been used to run business-critical workloads by more than 500,000 VMware customers for years. It is commonly used with external SAN and NAS arrays and, in many cases, it is separate teams that manage the compute resources and storage. Compute and storage frequently belonged to different teams, each with their own responsibilities of configuration, management, reporting, and troubleshooting.
The Hyperconverged Infrastructure (HCI) approach of VMware vSAN is different than traditional shared storage architectures. HCI combines both compute and storage within each host in a vSphere cluster. Storage services are then presented to virtual workloads from storage devices local to each host in a vSAN enabled vSphere cluster.
Today’s topic is one of several pitfalls that customers sometimes slip into, notably the lack of applying device updates.
Are traditional storage systems really commodity based?
In a traditional 2-Tier configuration, vSphere hosts and shared storage are mostly patched separately. Updates for external storage are typically infrequent when compared to vSphere updates.
External storage is typically delivered in the form of a dedicated, version controlled, general purpose appliance, that is compatible with various types of compute. Alternatively, vSAN was built for virtual machine workloads. While the underlying configuration could be using commodity hardware, there are typically specific configurations that are available with limited deviation.
A smaller combination of approved hardware and software may result in fewer updates, but also limits the available selection of approved devices. This typically drives the price of a solution up, with a potential risk of devices not being available from supply chain disruption.
The commodity approach of vSAN
VMware works diligently with many manufacturers to ensure compatibility with an extensive variety of x86 based solutions. Close collaboration with OEM’s allows for a larger selection of devices and gives vSAN the ability to have better x86 server economics than traditional storage platforms.
In any storage system, data integrity is of the utmost importance. A business owner or administrator is not going to select a storage solution that cannot ensure data integrity. Storage solutions are not going to be selected if they cannot meet the requirements for an organization’s workloads.
For storage solutions to operate properly, they must be configured properly. Proper configuration could include items such as controller settings, firmware version, or other settings. The commodity device approach of vSAN means that a large number of controllers, driver, firmware, or drive configurations can be used in a vSAN cluster. Each of these items may have their own distinct combination for the best results.
Over the lifecycle of a piece of hardware, changes can be made by an item’s manufacturer to enhance, correct, or improve efficiency. In traditional storage systems, updates to a platform are provided infrequently.
The vSphere product is provided updates very frequently. Updates to vSAN are often included with these vSphere updates. Product enhancements, more efficient operations, as well as fixes are delivered in the form of updates.
Misconception: Drivers and firmware don’t matter
Routine updates to vSphere and vSAN are only going to update the VMware portion of the stack. Storage controllers and storage devices are just as important in the HCI stack.
A properly configured storage system is a healthy storage system. Consider that VMware routinely updates vSphere and vSAN. Storage controller and media manufacturers also routinely update the firmware and drivers for their hardware.
“What if I use a firmware, driver, or combination of both that is not approved for use with vSAN?”
Driver and firmware misconfiguration is a common source of support cases. Some of the behaviors that could result from an improper driver or firmware being used could include unnecessary latency caused by IO retransmits, misreporting of drive health, or even degradation of host responsiveness.
“How do I know which firmware and driver I should use with vSAN?”
VMware has done a significant amount of work to make this easier to determine with tools such as the vSAN Health Check, and VMware Cloud Analytics. These integrated tools take the guesswork out of upgrades and patching. VMware Cloud Analytics correlate the VMware Release Catalog, VMware Compatibility Guide, and the specific hardware in use to determine the best versions of vSphere and vSAN for that cluster.
The vSAN Health Check can report firmware or driver inconsistencies, directing an administrator to update their environment.
The vSAN Compatibility Guide can also provide guidance for specific devices.
The VCG can be found here: http://vmware.com/go/vsanvcg
VMware Update Manager Baselines that are automatically generated using the VMware Release Catalog, can determine the best combination of firmware for the version of vSAN in use. Some controller firmware can even be updated natively with VMware Update Manager, making the task of lifecycle management even easier.
A list of controllers that vSAN supports updating firmware can be found here: https://kb.vmware.com/kb/60382
A healthy configuration
A properly configured solution is a healthy solution. Properly updating vSphere, vSAN, and the underlying hardware will provide the highest levels of performance and availability.
Stay tuned as Adam shares more vSAN Misconceptions.
