Increasing Storage Performance & Provisioning Flexibility In Apache CloudStack

cloudmonkey-fp

This post is co-authored with Mike Tutkowski, Senior Software Engineer at SolidFire and Apache CloudStack PMC Member.

With the recent release of Apache CloudStack 4.4, CloudStack has taken another step forward. Version 4.4 fixes 130+ bugs and introduces 20+ new features and improvements. Here are some highlights of new and improved features in this release:

  • Root Disk Resize: Previous to 4.4, if a root disk attached to a compute offering needed to be a different size, a separate compute offering was required. This could become cumbersome in large environments that had many compute offerings only differentiated on root disk size.
  • Root Disks on Managed Storage: The primary storage plug-in model for data disks has been extended to include root disks as well. The storage plug-in now allows creation of a one-to-one dedicated volume/LUN to virtual disk mapping. This allows for pass through of storage-specific features such as deduplication, thin provisioning, better usage reporting, as well as SolidFire-specific IOPS performance guarantees that were exclusive to data disks prior to CloudStack 4.4 (more on that in a bit).
  • Hypervisor Improvements: VMware DRS is now fully supported, Hyper-V improvements (Storage Live-Migration, Zone-Wide Primary Storage, VPC Support).
  • Virtual Router Service Failure Alerting: Introduced in CloudStack 4.3, the monitoring VR services now notify admins in the case of a virtual-router failure.

Since the initial redesign of CloudStack’s storage infrastructure in 4.2, SolidFire has steadily enhanced CloudStack capabilities so that it can fully leverage fine-grain storage Quality of ServiceGet more information about SolidFire with Apache CloudStack.

The fundamental issue we’ve needed to overcome in CloudStack is that it was built from the ground up to expect storage to be preallocated by an admin and then “handed” over to CloudStack, where multiple root and data disks would then share a given storage volume. This is a simple model and easy enough to use. Unfortunately, it does not lend itself well to storage automation and quality of service.

In a large-scale cloud infrastructure, it is all too easy for one application to consume a disproportionate amount of storage resources. This creates a scenario whereby many applications suffer performance degradation at unpredictable intervals. In fact, this deficiency in so many multi-tenant environments is what holds enterprises back from trusting them with their most mission-critical applications.

Even if performance is guaranteed to a given volume on the SAN (such is uniquely the case for SolidFire), multiple CloudStack volumes (root and/or data disks) sharing that SAN volume is like having multiple tenants sharing a certain number of IOPS. Performance to the SAN volume is guaranteed, but not to individual CloudStack volumes that reside on the SAN volume.

The solution SolidFire has been bringing to CloudStack in a phased approach is for each CloudStack volume to have its own SAN volume. If the SAN volume in question has guaranteed IOPS, then so does the CloudStack volume. To make this a little more concrete, let me illustrate the process using XenServer as an example:

  1. The user creates a CloudStack volume (this information is simply recorded in the CloudStack database).
  2. The user attaches the volume to a VM for the first time.
  3. CloudStack determines that the SolidFire plug-in should be utilized (typically due to storage tagging).
  4. The SolidFire plug-in creates a volume on its SAN with the specified number of IOPS.
  5. CloudStack instructs XenServer to create a new storage repository (SR) on the new SAN volume.
  6. In addition to creating a new SR on the new SAN volume, XenServer creates a single virtual disk image (VDI) inside of the SR. This VDI represents the CloudStack volume that is to be attached to the VM in question. The only time you would see multiple VDIs in this SR is if hypervisor snapshots of the VDI were taken.

In 4.2 SolidFire introduced support for dedicated IOPS for CloudStack data disks leveraged from VMs run on XenServer or ESX.

In 4.3 SolidFire extended support for dedicated IOPS for CloudStack data disks on KVM (while adding support for hypervisor snapshots on XenServer and ESX to this model).

With CloudStack 4.4, we focus on bringing support for dedicated IOPS to root disks. CloudStack now offers the ability for VM root disks to have guaranteed IOPS (regardless of whether the root disk was created from a template or installed from scratch via an ISO).

As we look toward version 4.5, CloudStack and SolidFire will tackle the LUN limits in modern hypervisors. Today most hypervisors have a limitation of 256 LUNs/volumes per host. Since all LUNs need to be seen by all hosts in the cluster, this means a limitation of 256 LUNs/volumes per cluster. This limitation can prevent scaling of clusters in large environments. Due to this, dedicated root and data disks should be used for those workloads that specifically require performance controls today.

SolidFire will need to work around this as we transition to a one-to-one disk-to-volume model in order to guarantee performance across all workloads and tenants. We look forward to a continuation of our partnership with the Apache CloudStack Community to help our customers better serve their needs and applications.

For more information or to download Apache CloudStack, please visit the Apache CloudStack website

 

 

4595 views 2 views Today
4595 views

 | 1 comments



Posted in CloudStack.