Since the onset of Virtual Volumes the goal has been for storage providers to bring to life capabilities, automation and an evolution of storage consumption. Now it’s time for vVols Done Right.
Today during the company’s analyst day event, SolidFire announced their official support for Virtual Volumes with the release of their ElementOS (Version 9.0.0 Fluorine).
While working closely with some of the members of the SolidFire team such Keith Norbie, Josh Atwell, Andy Banta, Aaron Patten, Jeramiah Dooley and others, I got a chance to learn about the details of the SolidFire Virtual Volumes implementation.
From an implementation perspective, I think SolidFire has done a great job by not only by complying with all of the core implementation requirements of the Virtual Volumes framework. SolidFire is able to expand beyond the traditional capabilities used and found in the framework today and introduce a set of unique functions that has not been seen in current Virtual Volumes implementations until now!
SolidFire brings support for Virtual Volumes to vSphere customers with their Fluorine release:
Control Plane Compliance – Compliance with vSphere’s universal storage control plane and policy management framework. SolidFire/vSphere customers have the opportunity to transform their adverse storage management operations. Through the use of vSphere’s Storage Policy Based Management (SPBM), SolidFire allows customers to take legacy storage operating procedures and transform them into standardized and systematic procedures that are dynamically defined by the storage administrator for vSphere administrators.
These types of procedures can be used by vSphere administrators and application owners to consume storage resources selectively by dictating performance attributes and security services as mandated by application requirements, down to VM or Virtual Volume granularity.
As an additional value add, this also increases the manageability of the storage infrastructure and at the same time relieves storage administrators from performing mundane tasks such as creating and configuring storage volumes/LUNs.
Capabilities – IOPS driven capabilities implemented per object (Virtual Volume) in the form of Maximum IOPS, Minimum IOPS, Burst IOPS. Here is where SolidFire introduces a new and unique feature, the ability set and controls the allocation and consumption of IOPS based on the Virtual Volumes. With Virtual Volumes, traditional Virtual Machine files are now represented in arrays as native objects (config, data, snapshot, memory, other). Each Virtual Volume plays a different role and satisfies a different requirement for a virtual machine.
In the SolidFire model, each virtual volume role gets its own performance profile. This model provides administrators with the ability to define unique performance configurations. Also provides the ability to set the IOPS limits for virtual volumes with lower IOPS requirements such as the config-VVol. This prevents the system from assigning unnecessary resources, but regardless of this behavior all virtual volumes remain protected on the system by SolidFire QoS minimum IOPs just as the core data virtual volumes receive, and all of this is managed seamlessly via SPBM.
SolidFire’s architecture allows a fully policy driven implementation of Virtual Volumes; it is a fully realized software-defined storage model driven by SPBM policies created by the vSphere administrator. This enables simple, repeatable operational workflows that can be simply invoked for routine operations.
Storage Containers – Storage Containers are logical constructs used to group Virtual Volumes. With SolidFire storage containers are strictly utilized as management constructs and not to carve out storage capacity or enable array features or capabilities. SolidFire features and array capabilities are applied granularity on a per Virtual Volume basis by default as they are already part of the core architecture.
All storage containers are created equal from a capacity perspective, they all see the total capacity of the array. SolidFire currently provides support for up to 1000 storage containers.
Scalability – This initial release provides supports of up to 2000 virtual volumes per node. SolidFire node based architecture is based on the support of multiple nodes per cluster. This means that the number of supported virtual volumes is linearly increased based on the size of the SolidFire cluster. SolidFire supports different models of nodes and to assist customers and partners to easily right-size their clusters they have created a Virtual Volumes sizing calculator. The calculations are based on the model of the nodes and the virtual machine semantics as it pertains to the number of disks, snapshots, etc. The number of virtual volumes supported is expected to increase through different release cycles.
Protocol Endpoints – With the new ElementOS (Version 9.0.0 Fluorine) release SolidFire provides support for at least one Protocol Endpoint per node. According to the SolidFire team, their testing and evaluations have proven that they can deliver their guaranteed QoS values with a single Protocol Endpoint per node. From a connection availability and single point of failure concerns, from a SolidFire cluster design perspective, recommended configurations are based on a minimum of 4 nodes.
VASA Provider – The VASA provider for SolidFire has been implemented as part of the core SolidFire services that run on each node runs and not the Virtual Appliance form. This makes things a lot easier to configure, manage, and maintain. At the same time, it removes potential contention, management, and dependency risks from the solution. The VASA Provider service can leverage its proprietary High Availability (HA) service in the same way high availability is provided for all of the SolidFire services which are based on redundant services running on each node.
The value Virtual Volumes delivers from a technology and management perspective is absolutely undeniable. There is a whole lot more coming to Virtual Volumes this was only a glimpse to one of the latest and greatest partner implementations.
We’re going pedal to the medal with virtual volumes and more proof on that will be released later this summer. Stay Tuned!!!
-Enjoy
For future updates on Virtual SAN (VSAN), vSphere Virtual Volumes (vVols) and other Storage and Availability technologies, as well as vSphere Integrated OpenStack (VIO), and Cloud-Native Applications (CNA) be sure to follow me on Twitter: @PunchingClouds.
