Freely subscribe to our NEWSLETTER

Enterprise Strategy Group estimates the median capacity for active virtualisation users is 2 Terabytes . This capacity requirement is easily served by the internal storage capacity of a typical server. In fact 59% of SMB customers interviewed were using Direct Attached Storage (DAS) in their virtual server infrastructure. Until now, however, customers needed an expensive and complex external SAN to enable high-value features such as VMotion and Dynamic Resource Scheduler (DRS). This server based storage typically costs a fraction of what an external SAN costs and is much easier to manage.

VMware DRS and VMotion are integral tools which allow Virtual Machines (VMs) to be dynamically moved between ESX servers to balance physical server loading and optimise performance. However, a VM can only be moved if the datastores it uses are being shared by all of the ESX servers in the cluster. Most ESX users are looking for ways to maximise their investment and want to leverage advanced features available in ESX, but can’t do so without making a significant investment in a shared storage system. Until recently, the only way of getting shared storage was to purchase a SAN or NAS system typically costing thousands of dollars.

A Storage Virtual Appliance (SVA) unlocks the processor and data storage resources of the ESX server and provides a virtual SAN that enables datastores to be shared in the same way as an external shared storage system. By using the internal disk drives of the ESX server to create a virtual SAN, SVAs provide a cost effective shared storage environment without having to install a complex external SAN.

A SVA provides a set of storage services, but instead of running them on an external storage controller it runs them in a virtual machine running under ESX. This enables it to take control of a VMware® ESX server’s Direct Attached Storage (DAS) and virtualise it as part of a virtual SAN. The DAS can be either the ESX server’s internal disk drives and/or externally attached arrays. The SVA uses the server’s DAS storage to create datastores which can be made available to and shared by any ESX server on the network. The SVA runs in a standard VM, typically needing 2 GHz of CPU and 1 GB of memory, and communicates directly with RAID hardware via an agent.

High Availability for Business Continuance

In many cases virtual servers are implemented as part of a server consolidation strategy. Frequently the servers are critical to the business of the organisation, and downtime, especially unplanned downtime is unacceptable. The failure of a physical component on a virtual server platform could result in many VMs and virtualised servers becoming unavailable. To prevent this downtime, it is essential that the entire virtualised environment is built to provide High Availability, with no single point of failure.
This could be a major shortcoming of an SVA; if the server or server storage it is using goes down, then all of its datastores become unavailable and all of the VMs using them will go offline. To prevent this, the SVA should offer some form of storage redundancy and High Availability, so that even if an ESX server and its SVA goes down, its datastores can still be accessed.
Most SVAs meet this requirement by allowing datastores to be mirrored between them. Each SVA maintains an identical copy of the datastore, and presents it to ESX as a single logical datastore, with multiple access paths. Some of these paths go to one side of the mirror, some to the other. The mirror itself is an Active-Active mirror, which means that each ESX server can choose which path it uses to access the mirrored datastore.

If one SVA or its storage becomes unavailable, ESX simply sees a path failure and fails over to another path, which is actually a path to the other side of the mirror. When the failed SVA or storage comes back online, the surviving SVA will detect it and initiate a fast resynchronisation. This will only transfer data which was changed while the failed side of the mirror was offline. With this architecture in place, the virtual environment can withstand a server or storage failure without disruption to the user.

Integrated Management Provides Greatest Value

IDC Research reports that management of data storage can be as much as 59% of the Total Cost of Ownership (TCO). With IT budgets being stretched and the proverbial “more with less” approach to managing IT infrastructures pervasive, management tools need to be integrated and provide automation of common tasks.

Storage Virtual Appliances, server RAID controllers and VMware ESX all have their own management applications. In many cases these are proprietary and act independently of the other management tools. Operations such as creating a datastore typically involve using an Appliance GUI to create a new iSCSI target volume, usually requiring some knowledge of low level iSCSI protocol information such as iSCSI Qualified Names (IQN). ESX then needs to be told to rescan its iSCSI bus to discover the new target, and the target has to be formatted with VMFS. Other ESX servers in the cluster then need to be told to do re-scans to discover the new datastore.

One approach is to the management challenge is to integrate management of internal RAID and the SVA into management of the virtual infrastructure, using a vCenter plug-in. This means that the virtual SAN can be managed from the same management console as VMware.

The management interface simply appears as an additional tab in vCenter.

RAID management is done by the SVA itself. You simply create a virtual SAN storage pool, and the SVA will automatically configure the internal RAID controller in the server , using whatever RAID level and RAID parameters you choose. If any events occur on the RAID controller, for example a disk failure in a RAID array, this will be detected by the SVA and reported using the event management system. The SVA can easily be configured to forward events by email to selected administrators.

Creating datastores using the virtual SAN couldn’t be simpler. Integrated management of the SVA with VMware storage configuration allows the user to create a datastore from within vCenter. Datastore creation and provisioning can be automated in some SVAs. By conducting a single operation you can easily create and/or provision a datastore. To create a new datastore, you simply select the SVA(s) to use, the datastore size and the ESX servers to which it is to be assigned, and the SVA can do the rest. The new datastore will be created on the SVAs, access control set up to limit access to the selected servers, and the ESX servers will then be configured to format the datastore with a VMFS and assign it to the servers. You ask to create a new datastore and in a few minutes it has been created and is ready to use.
The Bottom Line

Storage Virtual Appliances take the cost and complexity out of shared storage in VMware ESX environments. With Storage Virtual Appliances you can:

–  Implement shared storage without the cost and complexity of external SANs
–  Leverage the internal disk drives of the ESX server
–  Enables highly available ESX environments without requiring external shared storage
–  Unlocks the power of ESX – leverage the benefits of VMotion, DRS and VCB
–  Share datastores across clustered ESX servers

1 Enterprise Strategy Group “The Impact of Server Virtualisation on Storage” December 2007

2 Requires a supported RAID controller.

About the Author
Chris Farey, co-founder and CTO
Chris is co-founder and CTO of StorMagic®; as such he is chief architect of the Company’s product line, is responsible for designing the solutions and manages the StorMagic development team.
Chris has over 25 years experience in software development. Prior to co-founding StorMagic he was Director of Software Architecture at Adaptec, where he was charged with the vendor’s iSCSI / IP SAN product roadmap. Chris was responsible for architecting iSCSI storage systems for leading storage providers, such as IBM.
Before this position Chris co-founded and took the role of CTO at Elipsan, where he was architect and designer of the IP SAN storage solution. Elipsan was sold to Adaptec in 2004.
Prior to this Chris was CTO of Eurologic’s SAN software division, where he developed one of the world’s first iSCSI storage sub-systems. Before that Chris was founder, CEO and CTO of K-Par Systems, where he designed and implemented file systems for data storage on optical media. Chris holds a Bachelor of Science in Physics from the University of Bristol in the UK.