The software-defined datacentre represents the current phase in the evolution of IT delivery to the business. It is an approach largely driven by virtualisation and the rise of VMware -- and to a lesser extent, Microsoft Hyper-V -- in the datacentre.
Those platforms, VMware in particular, have attained an air of unassailability as virtualisation has swept the world's datacentres. But there is another virtualisation environment beginning to gain significant attention -- the open-source, modular cloud platform OpenStack.
VMware's vSphere and OpenStack form extensive ecosystems, built up to deliver, operate and manage virtualised compute, storage and networking, as well as the systems management tools that deliver resource management, monitoring and alerting.
And while OpenStack feels like it is hardly out of the blocks compared with the incumbent virtualisation platforms, the question is begged: to what extent is OpenStack a potential replacement for VMware?
The relevance of that question is reinforced by the example of PayPal, which has -- in part -- replaced vSphere with OpenStack.
It's a question that has to be answered by looking at the opportunities and challenges for IT organisations inherent in the two platforms. A key aspect of this is how they implement and manage storage in the two environments.
Here we look at VMware vs OpenStack, and assess their keys strengths and weaknesses in storage.
VMware vSphere
In a vSphere configuration, storage is mapped to the VMware hypervisor ESXi using a number of standard protocols. Today, these include Fibre Channel, iSCSI, Fibre Channel over Ethernet (FCoE) and Network File Sytem (NFS). Fibre Channel connectivity follows a pretty standard configuration, with each ESXi host accessing storage through a logical unit number (LUN) or volume, which are then mapped to datastores, the storage container for a VMware virtual machine (VM).
Although vSphere provides a rich range of connectivity options, historically it has taken a fairly traditional approach to storage management.
At first in the vSphere platform, storage was managed externally to the vSphere environment, typically by storage administrators who provided LUNs preconfigured to application performance and availability requirements. This configuration work was manual in nature, with a significant amount of pre-planning required.
In successive releases, vSphere evolved to provide a degree of automation to the functions of storage management. VMs could be rebalanced for capacity and input/output (I/O) load across a vSphere cluster using policies within Storage DRS. Meanwhile, Storage I/O Control allowed the prioritisation of application I/O that implements a basic quality of service.
But VMware has been on a journey to provide more intelligence between the storage and the hypervisor, and has incorporated a series of application programming interfaces (APIs) against which storage suppliers can develop their platforms.
Read more about OpenStack and storage
OpenStack is a rising star in private cloud infrastructures. But what about OpenStack storage? We run the rule over OpenStack Cinder and Swift
OpenStack and its Swift and Cinder object and block storage lead the way, but are not the only options for building open-source cloud platforms
These include vStorage APIs for Array Integration (VAAI), vStorage APIs for Storage Awareness (VASA) and vStorage API for Data Protection (VADP). These APIs allow the hypervisor to direct storage to manage virtual machines more effectively.
VAAI provides I/O offload capabilities; VASA provides the hypervisor with information on the capabilities of the storage platform; and VADP provides the ability to take application consistent backups and snapshots.
Probably the least developed area in the vSphere storage ecosystem is that of storage provisioning.
Pretty much every storage array supplier chooses to implement the layout and provisioning of its storage in a different way. There is little or no consistency available, outside of what can be achieved with the Storage Management Initiative Specification (SMI-S) standard. This makes it very difficult for VMware to develop a standard API within the platform for storage provisioning. Solutions up to now have been to implement plugins in the vSphere management interface that allow a call-out to the storage array for provisioning, which is still a manual process.
However, in vSphere 6 we have seen the release of Virtual Volumes (VVOLs), a technology that will vastly simplify the provisioning process. A VVOL is a logical representation of part of a virtual machine. A minimum of three VVOLs are needed to represent a single VM, each one mapping to the configuration data, VM swap space and at least one virtual machine disk.
VMware has worked with storage array suppliers to enable the creation and deletion of VVOLs from within the vSphere ecosystem, removing the need for a significant amount of storage administrator work and laying the foundation for implementing policy-based VM management at the storage layer.
OpenStack
The OpenStack project is focused on developing an ecosystem that allows customers to deploy applications in a software-defined datacentre. The platform is divided into a number of projects, each of which delivers part of the infrastructure.
Compute is delivered through Nova, networking through Neutron, with OpenStack storage delivered by two components called Swift (object) and Cinder (block).
Cinder provides persistent block storage to OpenStack environments. The persistent feature is important because vanilla OpenStack virtual machines are transient and are destroyed on shutdown, but Cinder allows local server storage to be used for persistent VMs.
External storage suppliers can provide block storage to Cinder through the use of a Cinder driver. This is typically implemented as a piece of middleware that translates Cinder API calls into commands on the underlying storage platform.
Over time, successive releases of OpenStack have introduced new functionality and suppliers support this in specific releases. Protocol support is also supplier and release-specific, and includes iSCSI, Fibre Channel, FCoE, NFS, plus a range of bespoke implementations such as Rados Block Device for Ceph and GlusterFS.
Object storage support is provided through the Swift component. Like Cinder, Swift can be deployed natively in the platform using commodity servers and storage, or it can be delivered by external storage suppliers.
There are a number of other OpenStack components still in early development. Backup support is being developed through Raksha and a shared-file system through Manila. These projects will complement the existing Cinder and Swift components by providing the ability to share data between virtual machines and to integrate a VM-consistent backup function.
VMware vSphere vs OpenStack
So, if an organisation contemplated replacing an existing vSphere platform with OpenStack, how would that impact upon storage?
From a persistent storage perspective, external arrays already deployed could be repurposed for use with OpenStack, subject to the availability of a Cinder driver.
But at this stage in the evolution the two platforms, vSphere offers more mature features and is pushing towards a higher degree of integration with external storage platforms through the use of features such as VASA and VAAI.
This means OpenStack deployments could require additional management overhead compared with vSphere. But of course many organisations may look at OpenStack as a way to reduce hardware costs and eliminate the need for external storage altogether.
IT organisations looking to move to OpenStack will find a very different operational model, with potential savings in infrastructure costs replaced by an increased amount of operational management and application redesign.
VMware's vSphere has no direct object storage support, but within the infrastructure there is not necessarily any need for an object platform, unless demanded by individual VMs and applications. If it was, this could be implemented quite easily through the deployment of SwiftStack or another object store compatible with Amazon Simple Storage Service.
Today the major difference in the two infrastructures is in the area of data protection. While vSphere provides native capabilities to manage virtual machine backups with application consistency, OpenStack at this stage in development pretty much leaves backup to the customer.
There's a good reason for this -- vSphere is still focused on the monolithic deployment of a single VM for a single application, compared with OpenStack, where a virtual machine is simply one of potentially many servers in a scale-out application. These OpenStack deployments assume that data is stored separately from the VM and more readily backed up outside the virtual machine.
Disaster recovery is another area in data protection that customers will have to implement themselves. There is no equivalent in OpenStack of vSphere Site Recovery Manager -- the VMware component that manages the failover of storage at the array level. Again, the assumption is that disaster recovery can be provided by the application.
In summary, IT organisations looking to move to OpenStack will find a very different operational model, with potential savings in infrastructure costs replaced by an increased amount of operational management and application redesign.
This means that for most, rip-and-replace is not a viable option. Companies such as PayPal have the developer resources in place to manage a transition to OpenStack and the latest news indicates this is the case.
PayPal developed its own OpenStack deployment and has started a transition away from VMware, in part because of the benefits of being able to customise its own platform -- something that is out of reach for the majority of IT organisations.
