Architecting Storage for the Internal Cloud: One Step at a Time

Bottom Line: IT organizations face many integration challenges while transitioning to the internal cloud. The internal cloud requires a different storage model than traditional data centers. Clouds are more than compute services alone. They also require storage services to be part of a viable infrastructure as a service (IaaS) cloud offering. For organizations to build an efficient internal cloud, storage must transform to support a service-oriented infrastructure. To accomplish this, storage must transform from traditional silos of technologies to a tightly integrated set of storage services that can meet the demanding, self-service, automated, mobile-workload nature of cloud computing.

Context: IT professionals are under increasing pressure to deliver IT services more efficiently while reducing costs. Many would like to be more flexible and efficient in how they deliver infrastructure services, but they question how to get there. When complete, internal IaaS cloud will be a core infrastructure technology critical to the automation of IT service delivery. It is critical for the IT decision maker to understand how to design storage for the internal cloud. Investment choices and missteps that lead to instability, security breaches, or poor service levels, for example, could have a disastrous and costly impact on the IT organization. Transforming the traditional data center to an internal cloud is essential for enabling the IT organization to make intelligent use of external and hybrid cloud alternatives in the future.

Take-Aways: IT organizations that are considering storage for the internal cloud should consider the following key points:

• Storage for the internal cloud requires extensive pre-work to gather the business and technical requirements for developing a sound storage strategy for the internal cloud.
• Storage transformation begins with consolidation and virtualization. Once mastered, process automation and service integration will enable automation of IT service delivery.
• Building out storage services and infrastructure is a repetitive and tenuous process. Defining application affinity to storage workload will ensure delivery of recovery point objective/recovery time objective (RPO/RTO) expectations.
• Building out storage services and storage infrastructures ensures that storage for the internal cloud can service application requests as new business requirements emerge and the IaaS cloud matures over time.

The steps required to transform existing storage or to integrate new storage into the private cloud include:

1. Pre-work (think like a provider): The pre-work step is the most important step in the guidance framework. It also requires extensive planning to formulate a solid storage transformation strategy. To accomplish this, IT organizations must first understand the IaaS model and the role storage plays within each layer of the IaaS cloud model. IT organizations must:
   • Understand the IaaS model and begin to think like a provider
   • Define business and cloud requirements
   • Determine the storage integration point of the IaaS cloud
   • Perform a storage assessment (Use existing storage, modify or add additional capabilities to the existing storage infrastructure, or buy new storage)
   • Develop a phased storage-transformation strategy
2. Storage transformation (it's a journey): To prepare storage to service the individual layers of the IaaS cloud model, IT organizations must begin by consolidating storage and implementing storage virtualization. The pre-work accomplished in Step 1 will be instrumental in accomplishing this step. IT organizations must begin with:
   • Storage consolidation
   • Storage virtualization
   • Enable virtual machine (VM) mobility
3. Storage integration: Critical to integrating storage for use within the IaaS cloud is to begin to automate many of the manual storage functions typically found in traditional data center environments. The purpose of this step is to remove as much of the human element as possible from the day-to-day storage operations. To accomplish this step organizations should define and implement:
   • Process automation
   • Storage service integration
4. Build out storage services and infrastructures: Building out storage services and storage infrastructures ensures that storage for the internal cloud can service application requests as new business requirements emerge and the IaaS cloud matures. Organizations must:
   • Define application affinity to storage workloads
   • Define and verify RPO/RTO requirements
   • Implement storage services

Conclusion: Storage for the internal cloud is about storage transformation and integration with the IaaS cloud. It must be a well thought out, pragmatic journey and requires an extensive amount pre-work prior to designing storage for the internal cloud. This three- to five-year journey will transform traditional silos of storage into service-oriented, virtualized, elastic, scalable, shared storage infrastructures that will be capable of on-demand provisioning and transparently servicing the storage requirements of the internal cloud.

IT organizations are under increasing pressure to deliver IT services more efficiently while reducing costs. Many would like to be more flexible and efficient in how they deliver storage infrastructure services, but they question how to get there. When complete, storage for the internal cloud will be a core infrastructure component critical to the automation of IT service delivery. It is critical for the IT decision maker to understand how to design storage for the internal cloud. Investment choices in storage and missteps that lead to lock-in, instability, security breaches, or poor service levels, for example, could have a disastrous and costly impact on the IT organization. Transforming storage from a traditional data center model to storage specifically designed to meet the needs of the internal cloud is essential for enabling the IT organization to make intelligent use of external and hybrid cloud alternatives in the future.

As organizations seek to deploy internal clouds, many do not consider storage until they are well into the deployment phase. Faced with the prospect of leveraging legacy storage hardware, software, and processes into sophisticated internal cloud infrastructures, these organizations will struggle to gain operational agility and the storage efficiency that the IaaS model can deliver.

Storage for the internal cloud must be a well-thought-out and pragmatic journey and requires cross-functional planning and a keen understanding of the storage requirements needed to support the internal cloud. Without a clear understanding of the IaaS internal cloud model, storage workload requirements, storage capabilities, and required storage services, organizations will struggle to realize the full potential of the internal cloud.

Problem Statement

What are the steps necessary to transform and integrate storage for the internal cloud?

Guidance Applicability

This guidance document applies to organizations that have implemented or are about to implement, either in part or holistically, storage for the internal cloud. It applies to IT organizations experiencing operational inefficiencies. It also applies to IT organizations that are looking to create or improve storage infrastructures, storage services, and storage efficiencies within the internal cloud.

The problem many organizations face when considering storage for the internal cloud is determining where to begin. Lack of information and competitive threats from outside cloud alternatives are driving IT organizations to implement internal clouds before they have the proper storage infrastructure in place. This will cause missteps, inefficient utilization of storage resources, and failure to deliver service-level objectives.

This Gartner guidance framework will assist organizations in a methodical approach to transforming and integrating storage for use with the internal cloud. To build a solid storage foundation, which is critical to IT service delivery, organizations must accomplish three key objectives:

1. Perform the pre-work necessary to gather the business and technical requirements of developing a sound storage strategy for the internal cloud. These include:
   • Understand the IaaS model and begin to think like a cloud provider
   • Define business and cloud requirements
   • Define the storage requirements for each of the IaaS layers/categories
   • Perform a storage assessment (use existing, modify, or buy new)
   • Develop a phased storage-transformation strategy
2. Begin the storage transformation and integration process. This includes:
   • Consolidate storage and implement storage virtualization
   • Optimize the storage for data mobility
   • Integrate storage process automation and storage service integration
3. Build out storage services as the storage infrastructure matures. IT organizations should:
   • Define the application affinity to the storage workloads
   • Define and verify RPO/RTO requirements
   • Implement storage services such as backup and replication services

The Gartner guidance framework enables IT organizations to transform and integrate storage for use within the internal cloud. There are four steps (see Figure 1) to the Gartner guidance framework. These are:

1. Pre-work (think like a provider): This step contains five sub-steps that will build the foundation required to transform storage for use within the internal cloud. If the IT organization decides to buy all new storage for the internal cloud, the pre-work steps are still applicable because they will help identify key storage and business requirements and application and cloud dependencies. IT organizations must plan, architect, and implement storage to support the core IaaS cloud service characteristics.
2. Storage transformation (it's a journey): This step is an evolutionary journey. To prepare storage to service the individual layers of the IaaS cloud model, IT organizations must begin by consolidating storage and implementing storage virtualization. The pre-work accomplished in step 1 will be instrumental in accomplishing this step.
3. Storage integration: This is a critical step toward transparent process automation. The purpose of this step is to remove as much of the human element from the day-to-day storage operations as possible. Storage service integration takes storage to the next level by integrating many of the storage characteristics and capabilities into the layers of the IaaS cloud.
4. Build out storage services and infrastructures: This step defines what application affinity is in relation to the storage workload and associated services. This step ensures that the storage for the application is resilient, protected, and replicated and that RPO/RTO requirements are achievable. Once this is accomplished, IT organizations can provide storage services such as backup and archive to the IT service catalog for consumption by the self-service provisioning portal (SSPP).

Source: Gartner (November 2011)

Pre-work (Think Like a Provider)

The pre-work step is the most important step in the Gartner guidance framework. This step will assist IT organizations with the foundations required to make sound storage decisions for the internal cloud. Successful organizations will take the time to understand the individual layers of the IaaS cloud model. This will provide them with the foundation needed to apply business and application requirements to the internal cloud. Armed with a detailed understanding of the IaaS model and business and cloud requirements, the IT organization can now focus on the storage integration details required to service the individual layers of the IaaS cloud.

Next, the IT organization must perform a storage maturity assessment. The assessment will determine if the existing storage infrastructure, holistically or in part, can meet the specific requirements of the internal cloud. If not, the organization should consider purchasing new storage for its internal cloud deployment. Based on all the information gathered, the organization is now ready to develop a comprehensive storage strategy for the internal cloud. Below are the milestones required to complete Step 1 of the Gartner guidance framework:

• Understand the IaaS model and begin to think like a provider
• Define business and cloud requirements
• Determine key storage integration points within the IaaS cloud
• Perform a storage assessment
• Develop a phased storage-transformation strategy

Understand the IaaS Model and Begin to Think Like a Provider

IT organizations should begin to think like cloud providers. This requires storage professionals to think of storage in terms of a set of services and or capabilities called upon by the individual component layers of the IaaS model instead of thinking that they should design storage to meet a specific business or application requirement.

For example, it may be sufficient in a traditional IT environment for the storage administrator to manually provision storage for a given VM. The logical unit number (LUN) or pool of storage may require a nightly backup, or it may have specific replication requirements to meet a specific SLA. The storage administrator may spend hours or days servicing this single request. This process simply does not scale. In a cloud environment, storage resources are allocated from a shared or dedicated storage infrastructure. Storage provisioning occurs within minutes of the service request through dynamic, automated, and transparent operations. This standardized approach to storage provisioning improves overall efficiency and reduces possible missteps caused by human intervention.

It is important to understand the components of the IaaS model as it relates to storage. As optional (preferred) components of the model come online, they may place different architectural demands on the storage infrastructure. It is critical to plan for this transition to ensure that the storage infrastructure is capable of servicing the IaaS components needed to fulfill the business requirements as the cloud matures. If the IT organization does not plan accordingly, it may be difficult to redesign the storage infrastructure to meet the needs of a particular IaaS component once the storage infrastructure is in place.

Figure 2 highlights the required and preferred components of an internal cloud.

Source: Gartner (November 2011)

Storage for the internal cloud intersects every layer of the IaaS cloud model. Starting at the bottom of the model, physical storage resides in the physical infrastructure layer. This can be in the form of traditional storage arrays, unified storage arrays, storage appliances, virtual storage appliances, and even tape technologies. Storage arrays and appliances that are specifically designed for cloud use have built in storage APIs and features designed to offload, automate, and make transparent many of the traditional storage features that require storage administration intervention. Many of these features perform demand, delivery, and supply functions. Data mobility, security, availability, and flexibility are core to storage interoperability within the IaaS model.

For details on each of the IaaS component layers, refer to the upcoming "IaaS Reference Architecture."

Define Business and Cloud Requirements

Successful organizations will invest the time, money, and resources needed to understand business and application requirements prior to making any cloud or storage infrastructure decision. By breaking down the business requirements by functional areas and translating them into key IaaS layer decision points, IT organizations can begin to define the cloud requirements. Many organizations overlook this critical step in the rush to deploy an internal cloud. Organizations that skip this step will find it difficult to implement, keep in compliance, and scale the cloud as the business grows. Organization should break down the discovery process into five functional areas. Table 1 details the functional areas, key decision points, and associated components of IaaS.

Source: Gartner (November 2011)

Cloud Requirements

After defining the business requirements, IT organizations can determine the cloud storage requirements. IT organizations should define the storage cloud requirements based on the business needs of the organization and not based on the current storage infrastructure. By defining the cloud requirements first and then performing a storage assessment, the IT organization will be able to ensure that the cloud meets the needs of the business and is not based on the current storage capabilities. Storage must evolve to support the internal cloud.

The cloud storage requirements should be defined holistically and then broken down into "must have" and "nice to have" requirements. Leveraging the list of IaaS components will help organizations define the IaaS components that are required and optional for the internal cloud. Each cloud will be slightly different based on the business requirements of the organization. IT organizations should examine each layer of the IaaS cloud to determine the storage needs and requirements to service each layer of the cloud.

For example, the capacity management layer determines efficient resource allocation and optimal workload placement across the IaaS cloud. Storage, as one of the resources called upon by this layer, must have the capability to provision, de-provision, report on capacity, provide multi-tenancy capabilities (through zoning, multipathing, or other means), and ensure application affinity regardless of data mobility. Application affinity is the ability to match and bind storage workload requirements to a set of storage or storage services. This ensures that the application has the storage requirements — input/output operations per second (IOPS), latency, and capacity, needed to satisfy the application requirements, regardless of the application or storage location.

Determine Key Storage Integration Points Within the IaaS Cloud

Now that the organization understands the IaaS model, business, and cloud requirements, the next sub-step in the pre-work section is to determine where the storage integration points are in the IaaS cloud. One of the best ways to determine the storage integration points within the IaaS cloud is to create a flow diagram. IT organizations can model just the required cloud components or the entire cloud stack. Gartner recommends phasing in the preferred cloud components as the organization's processes and infrastructure mature to support additional business requirements.

Starting at the top of the process, with the self-service provisioning portal (SSPP), organizations can walk through each of the required cloud layers such as the IT service catalog, identity and access management (IAM) layer, and so on — until the service request is completed.

Figure 3, a high-level flowchart, outlines the storage provisioning process for a service request requiring the gold level of service. Note that, in this case, the model requires manual ticketing intervention and is not automated or transparent. There could be many reasons for this, such as existing IT processes or implementing a cloud with only the required components. This is an inefficient implementation of the internal cloud, but it demonstrates the importance of a phased approach and the need to aspire toward a fully implemented cloud offering.

Source: Gartner (November 2011)

In this configuration, the user authenticates through the IAM layer. If approved, the IAM will authorize only a subset of the SSPP offerings specific to the requesting user experience. In this case, the user selects the gold storage offering. The IT service catalog will have the storage requirements predefined for gold. For gold-level service, business requirements such as business strategies, governance, security, serviceability, and management objectives define the functional storage requirements of security, resiliency, scalability, performance, and efficiency. The next step in the process is the creation of a service ticket. Ticketing systems are often scripted or as simple as an email detailing the specific request. Unfortunately, in many instances, the ticketing process is a manual entry into a tracking database. The storage administrator now has to perform the manual operations of configuring the storage, sizing the requirements, setting up a LUN or pool of storage, defining the data protection schemes, and finally communicating back to the requester that the storage pool is ready for access.

By implementing only the required components of the IaaS model, IT organizations can reduce deployment and configuration errors. With fewer and repeatable configurations supported in the SSPP, IT organizations can benefit from a limited and standard storage provisioning process. Organizations that do not implement the preferred IaaS layers cannot achieve the level of transparent automation required to realize the potential cost and operational savings that the internal cloud can deliver. Below are the required and preferred layers of the IaaS model.

Figure 4, a high-level flowchart, highlights the same storage-provisioning request but with a fully implemented IaaS cloud. The most noticeable difference is the lack of human intervention. In this case, the ticketing system is only used for non-standard configurations. Instead, the Enterprise Service management layer works in conjunction with the Orchestration/IT Process Automation layer to execute the request. Vendor-specific storage extensions, provided by the hypervisor, storage, or cloud vendor, will provide specific information regarding the storage asset and capabilities to the orchestrator. The orchestration layer will then coordinate with the preferred modules and perform the storage-provisioning task. The vendor-specific storage plug-ins (APIs) are installed in the virtual infrastructure (VI) layer and on the physical storage arrays. Vendors design these storage APIs to offload many of the storage functions from the hypervisors, thereby providing greater storage efficiency and performance gains for many storage-specific functions.

Source: Gartner (November 2011)

Perform a Storage Assessment

IT organizations should compare existing storage infrastructure capabilities against the business and cloud requirements created in the pre-work step. They should document any gaps in functionalities or capabilities. A gap assessment must be performed to determine the risk associated by not closing the gap and whether new storage is required for the cloud environment.

After completing the storage assessment, organizations will have only three options to choose:

1. Use the existing storage infrastructure
2. Modify or add additional capabilities to the existing infrastructure
3. Buy new storage for the internal cloud

Most organizations will try to leverage existing equipment for the internal cloud. In general, if the storage is older than three to five years it is probably best not to redeploy the storage into the cloud. One exception will be to place the storage array under the control of a storage virtualization appliance such as NetApp's V-series or EMC's VPlex. These storage virtualization appliances will add required capabilities such as data deduplication and storage virtualization and can extend the life of the storage array. Many of the storage virtualization appliances will federate heterogeneous storage into a single large pool of storage that requesting hypervisors can consume.

In some cases, it makes sense to purchase new storage for the cloud as a packaged solution. Most storage vendors have integrated solutions through partnerships with the switch and hypervisor vendors to offer a bundled cloud solution. The advantage of this approach is that the storage vendor has tested the solution for interoperability and functionality. Support is often simplified with a single point of contact for the entire cloud solution.

Key IaaS storage purchasing criteria include:

• Transparency: Easy to use and integrate with little or no manual intervention; seamless installation and decommissioning of the storage resource
• Scalability: On-demand scaling of capacity, performance, and availability
• Storage efficiency: Built-in efficiency at every layer of the IaaS cloud
• Intelligent caching: Transparent automation that is optimized for cost-performance by application affinity and workload
• Unified architecture: Unified architecture for different workload requirements to reduce management complexity
• Integrated data protection: Transparent and seamless data protection for disaster recovery (DR), backup, and archive
• Continuous operations: Non-stop data availability with all layers of the IaaS cloud; transparent physical infrastructure life cycle management
• Secure multi-tenancy: Multi-tenant for shared storage resources
• Service automation and analytics: Accelerated troubleshooting tasks, improved response time, improved time to resolution

Develop a Phased Storage-Transformation Strategy

Building an internal cloud is a journey that will take most organizations three to five years. During this time, organizations will have two distinct architectural approaches — the traditional IT data center and the internal cloud. The traditional IT data center will continue to service specific applications deemed too risky or mission-critical for internal cloud. This practice will continue until the IT organization feels confident that the internal cloud is as battle-hardened as the rest of the data center.

Gartner recommends that organizations develop a phase-in approach to their storage transformation strategies. Storage specifically designed to service the needs of the internal cloud are maturing at an amazing rate. Storage is transforming from a single function device to an integrated component of the internal cloud infrastructure. For example, storage arrays with features such as hypervisor offloading capabilities, data deduplication, data tiering, and corporative cache coherency with solid-state drive (SSD) capable virtual servers are key features to support the internal cloud. Organizations should leverage existing storage assets in the early phases of a cloud deployment if and only if the storage can service the needs of the internal cloud.

As additional capabilities of the IaaS cloud come on line, it will be more and more difficult to leverage the existing assets without the use of a storage virtualization appliance or new storage arrays with integrated cloud feature sets. A phase-in approach to storage transformation and implementation will ensure that organizations get the most out of their current storage assets. It will provide time for the storage market to mature, thereby offering greater value to the organization over time.

Step 2: Storage Transformation (It's a Journey)

For many organizations, storage transformation is a difficult journey. It is fraught with technical challenges, from server host bus adapter (HBA) and converged network adapter (CNA) choices to protocol selection to hypervisor integration to storage management and serviceability options. Budgets play a pinnacle role as to transformation methods and to what extent the transformation can take place.

Storage Consolidation

Many believe consolidation and virtualization is a textbook case of which came first, the chicken or the egg. Many believe that you first must consolidate storage in order to have efficient storage virtualization. Others believe that storage virtualization is the means toward storage consolidation. In either case, both must occur in order to build a core storage infrastructure, which is critical to the automation of IT service delivery within the internal cloud.

Storage consolidation can take place at the physical layer. Consolidating storage could be as simple as migrating to unified storage arrays, eliminating inefficient storage arrays, or removing storage arrays with limited capabilities. Storage consolidation could also take place with the storage interconnect. Storage devices that support slower Fibre Channel speeds (i.e., 1 Gigabit Fibre Channel [1GFC] or 2GFC) may not be good candidates for the internal cloud. For IT organizations considering network consolidation, protocol selection will be critical. Protocols that support 10GbE (e.g., Internet SCSI [iSCSI] or Fibre Channel over Ethernet [FCoE]) are excellent candidates for the cloud because of their flexibility and performance.

This is an opportunity to consolidate SANs. However, caution is urged because planning will be critical. As SANs consolidate into a larger pool of storage for the cloud, the management of worldwide names (WWNs), switches, directors, and even protocol consolidation will become difficult to manage. Limitations on the number of WWNs that switches and storage controllers can support, especially for older equipment, can quickly become an issue.

Security zoning is a big concern. Security at a more granular level may be required. Many customers had segregated their storage area networks (SANs) according to the security domains of the applications storing data on them. They will need the capability to build those same security boundaries inside the consolidated SAN — and to prove to regulators (where required) that the boundaries exist.

Storage Virtualization

Many organizations use storage virtualization as a form of storage consolidation. However, virtualization is an excellent method to transform traditional — legacy — storage into storage for the IaaS cloud.

To separate data from the physical constraints of traditional storage architectures, organizations implement storage virtualization. Many confuse storage federation with storage virtualization or virtual storage. Storage virtualization enables nondisruptive, transparent data mobility and single–pane-of-glass management, typically within a storage frame. Virtual storage separates information from physical media and location, whereas federated storage is a collection of autonomous storage resources managed by a common management system.

Storage virtualization can occur at many levels within the cloud and often incorporates multiple techniques. Storage virtualization can occur within the hypervisor, x86 servers with storage software, intelligent switches, storage arrays, or with a storage virtualization appliance. Storage virtualization appliances and/or software can perform capacity pooling by aggregating multiple storage arrays into a single pool of storage. They can perform copy services such as synchronous and asynchronous array-to-array replication, mirroring, and snapshot services. They can also improve performance with caching algorithms such as cache coherence over distances or by striping volumes across spindles or federated storage arrays, vertically or horizontally. Storage virtualization provides many of the automation and data mobility features required of the IaaS categories, including Orchestration, Performance Management, and most notably the Virtual Infrastructure layer. Figure 5 depicts how a virtualization appliance can stripe, pool, and abstract storage as presented to the hypervisor and transport it to the application. This is critical for data mobility.

Source: Gartner (November 2011)

Appliance-based implementations are not all created equal. For example, products such as the DataCore SANsymphony-V solution can stripe storage pools across heterogeneous storage arrays. Products such as NetApp's V-Series and others do not support this feature at this time.

Virtual appliances can be a single point of failure. Gartner recommends that IT organizations deploy them in clustered configurations. With a software-based approach, scaling can be performed with N+1 servers, thus avoiding vendor hardware lock-in and reducing cost by leveraging commodity servers.

For block aggregation and virtualization, the symmetric in-band appliance enables storage federation and abstraction. Positioned within the data path, this approach acts as both the target and initiator. Storage redirection occurs by issuing new input/output (I/O) requests, which are abstracted completely from the application. This enables heterogeneous interoperability within a federated storage environment, thereby extending the life of legacy storage. Refer to Table 2 for a comparison of storage virtualization approaches.

Source: Gartner (November 2011)

Key features when considering a storage virtualization appliance are:

• Resource pooling: Support for heterogeneous storage arrays within a single or multiple data centers and for synchronous or asynchronous replication will enable IaaS clouds to support high availability and workload relocation in the event of a data center outage.
• Scale-out clustering: This enables fault tolerance and enables storage for the IaaS to scale as the cloud scales. Clustering should provide automatic sharing, balancing, and failover of I/O across the storage cluster in order to eliminate any single point of failure.
• Data caching: Data caching utilizing techniques such as synchronous dynamic RAM (SDRAM) will improve performance and help reduce I/O latency and array contention. Caching will extend legacy storage by improving performance.
• Advanced storage functionality: Functionality such as data deduplication, thin provisioning, storage tiering, and other storage efficiency features will augment legacy storage for use with the internal cloud. This can reduce the spend rate for legacy storage by reducing the number of new drives required to support the internal cloud.

Gartner recommends leveraging virtualization appliances for internal cloud deployments. They can be an excellent choice for IT organizations to extend the life of legacy heterogeneous storage arrays. They can abstract the application from the physical storage array to allow the storage administrator to take the storage arrays offline for maintenance or decommissioning or to bring new arrays online. Application workloads can be transparently migrated from one array to another without the need to take the application down or affect performance. For more information on storage virtualization, refer to the Recommended Reading section.

Enable VM Mobility

VM mobility for the internal cloud is critical for data migration, load balancing, and failover scenarios. Maintaining the storage relationships between the VM and the physical storage can be a daunting task. Transforming storage to enable VM mobility requires planning and coordination between the Virtual Infrastructure (VI) layer of the IaaS cloud and the storage infrastructure. Virtualization appliances play a critical role in VM mobility by abstracting the storage pool location from one array to another or from one data center to another. Another way to enable VM mobility is through hypervisor and storage software integration. Hypervisor-based APIs offload storage functions from the host onto the storage array. This enables efficient use of server and network resources during a mobility event, thereby resulting in greater performance, scalability, and consolidation density. According to VMware, the VMware Aware Storage APIs (VASA) feature can reduce the time it takes to perform storage related tasks by as much as 25%, reduce hypervisor CPU overhead by 50%, reduce network overhead by 99% for storage mobility operations, and reduce resource utilization by 95%. For example, three key VMware vStorage APIs for Array Integration (VAAI) are:

• Write same/hardware-accelerated zero: This API will move one large block of zeroes to the storage array and then instruct the array to repeat the operation as often as needed. As a security precaution, virtual machine file system (VMFS) write operations such as formatting and reallocation, for example, require zero fill operations. By placing the burden on the array, this will dramatically reduce I/O related traffic.
• Full copy/hardware-accelerated copy: This API instructs the storage array to use the array copy capability for array-to-array data transfers. This prevents data from traveling up to the host and back down to the array during a VM mobility event such as vMotion, cloning, or creating VMs from a template.
• Hardware locking offload/hardware-accelerated locking: This API will perform the VMFS lock management on the storage array instead of the host. The advantage is that the array will lock only the required blocks on a LUN and not the entire VMFS file system. VMFS operations such as vMotion will lock the LUN(s) during write operations, which may prevent other hosts from accessing the same LUN(s). This can cause performance issues for applications with I/O intensive requirements.

VMware is not the only product with integrated storage APIs. Citrix and other vendors have similar capabilities. IT organizations should evaluate hypervisor storage capabilities and assess the overall value to the organization.

For example, with VMware's Site Recovery Manager, storage administrators must determine — based on cost, type of data, and application criticality — how or if to implement this type of solution. IT organizations can choose to have the hypervisor perform the data replication or they can choose to have the storage array replicate the data instead. For example, VMware vSphere replication, using vCenter server and Site Recovery Manager, can replicate data for Tier 2 applications and small data centers. High-performance, business-critical solutions perform better with storage-based replications solutions but are typically more expensive to implement. The cost delta between a hypervisor software-based approaches and a hardware-based approach, per VM, according to VMware, can range from $600 to $2,000 per VM. The decision point for many organizations is the size of the dataset, performance, and criticality of the application. See Figure 6.

Source: Adapted from VMware (November 2011)

Another consideration for VM mobility is the SAN protocol selection. Fibre Channel can be complex and difficult to manage in a virtualized environment as compared to iSCSI. For example, with traditional Fibre Channel, VMs must configure and share an HBA's WWN on the SAN. With iSCSI, the initiator and the target have unique iSCSI Qualified Names (IQNs), which enables the VM to directly map the storage resource independently from the physical host. This gives the hypervisor greater VM mobility with less hypervisor configuration for simplified operations.

Fibre Channel supporting N_Port ID Virtualization (NPIV) addresses this configuration challenge by sharing a single physical N_Port as multiple N_Port IDs. Each N_Port has a unique WWN port and WWN node similar in concept to the iSCSI approach. NPIV enables VM migration with zones and LUN masking for simplified VM mobility. For more information on NPIV, refer to the Recommended Reading section of this document.

Step 3: Storage Integration

Critical to integrating storage for use within the IaaS cloud is to begin to automate many of the manual storage functions, typically found in traditional data center environments. The purpose of this step is to remove as much of the human element out of the day-to-day storage operations as possible. To accomplish this step, organizations should define and implement:

• Process automation
• Storage service integration

Process Automation

One of the key considerations for storage integration is process automation. IT organizations must review internal storage processes and look for areas within the IaaS model to automate storage operations. The goal of process automation is the elimination of manual intervention. Process automation can include storage provisioning and storage efficiency such as data deduplication and storage tiering. The capacity management layer of the IaaS cloud will examine and determine resource allocation and perform optimal workload placement across the IaaS cloud. The storage infrastructure must be capable of moving LUNs, or storage pools, to the appropriate storage array, zone, or even data center, transparently and without manual intervention to service the application needs defined in the IT service catalog. Automation occurs throughout the entire storage, networking, and compute environments. Automation often crosses technology boundaries. Process automation often works hand in hand with the orchestration layer. This layer will coordinate and automate IT processes across IT silos. It is critical for storage to coordinate with this layer to ensure cooperation throughout the IaaS stack. Inefficiencies or gaps in storage functionalities will have a negative impact throughout the entire cloud infrastructure. Any manual intervention in this process will reduce the operational efficiency of the cloud. The goal is to make storage resources a ubiquitous black box that is mobile, transparent, automated, and requires no human intervention with the exception of rack and stack and decommissioning.

Storage Service Integration

As IT organizations consolidate storage into larger storage resource pools, defining storage services will be instrumental in providing standardized quality of service for the IT service catalog and subsequent SSPP. This is required to reduce complexity and to ensure the same level of service for applications and services leveraging the storage resources. Individual storage requests or levels of service cannot scale and require manual intervention, which is contrary to the IaaS cloud model.

The IT service catalog exposes storage objects that consumers will order directly, or as part of another IT service offering, through the self-service provisioning portal. To support the IT service catalog, storage stewards must define storage capabilities consumed by the requesting service. Organizations are not limited to just three service categories. However, the number of service categories should remain low and easy to manage and serve the need of the business. Below is an example of how gold, silver, or bronze categories might look.

Source: Gartner (November 2011)

To define the storage capabilities for the service catalog, organizations leverage the work performed in the pre-work step of the guidance framework. A misstep or misalignment of capabilities will cause a collapse of the internal cloud value proposition and result in manual operations or service-level failures. IT organizations should resist the temptation to allow one-off service levels for individual service or application requests. By doing so, IT runs the risk of providing non-standard cloud offerings, thereby leading to complexity, missteps, errors, and inefficient utilization of storage resources.

Step 4: Build Out Storage Services and Infrastructures

The next step in the Gartner guidance framework is to build out the IaaS cloud storage services and storage infrastructure. This will improve the operational efficiency of the internal cloud while reducing the dependency of manual intervention as the business grows and cloud matures. To build out storage services, IT organizations must define application affinity to storage workloads, regardless of application or storage locality. This ensures that applications receive the right level of service as provided by the IT Service Catalog, managed through the Enterprise Service Management layer, and coordinated and executed by the orchestrator/IT process automation layer. Organizations must:

• Define application affinity to storage workloads
• Define and verify RPO/RTO services
• Design and implement backup services

Define Application Affinity to Storage Workloads

Defining application affinity to storage workloads is an important element of building out storage services. As IT organizations migrate additional applications to the internal cloud, pairing application requirements such as capacity, performance, availability, and cost will require an understanding of the IaaS cloud model and the capabilities of the storage infrastructure. As organizations move applications into the cloud over time, workload capabilities, network capacities, and performance may need updates or modifications. Savvy organizations will plan for growth by integrating new technologies or planning for an infrastructure update. Growth can occur in scale, functionality, optimization, and performance. Planning for these inevitable events in the beginning phase of a cloud deployment will set the stage for success in the future.

Storage plays a critical role in this natural evolution. IT organizations should plan now for scale-out storage infrastructures, federated storage topologies, and additional features such as primary-based data deduplication, flattening of the data center network, and incorporating 10GbE or even 1TbE networks when available. By matching application affinity to storage workloads, organizations will ensure efficient use of the storage and cloud infrastructures. Successful organizations will create a matrix of planned applications by storage workload requirements. This will identify storage placement, gaps, and opportunities for growth when designing storage for the internal cloud.

For example, in a SQL environment, deploying a storage array with internal tiering capabilities such as Tier 1 Flash storage to address heavy I/O and latency sensitive requests could improve an application's overall performance. As an alternative, PCIe-based SSD cache-coherent-storage capabilities can be added to the hypervisor server to address I/O and latency requirements. The industry is even considering placing hypervisors with selected VMs on the actual storage controller to eliminate any storage network latency.

Regardless of the approach, the 80/20 rule applies for most applications. The 80/20 rule states that 20% of the data for any given application is accessed more often than the remaining 80% of the data. Storage tiering, caching, or VM/storage placement makes use of this rule to improve performance and storage efficiency. By understanding the application affinity to storage workloads, organizations are poised for success as the storage services and the cloud infrastructure mature.

Define and Verify RPO/RTO Services

RPOs and RTOs are critical to building storage services and infrastructures. Organizations should define and verify RPO and RTO goals and objectives regularly. Gartner recommends that the organization read "Building a Business Impact Analysis: The Keystone to Effective Business Continuity Planning," which will assist them in building a Business Impact Analysis document.

RPO and RTO expectations have changed within the organization because of virtualization and cloud computing. The RPO and RTO windows are shrinking. It is no longer acceptable for an application to be down hours or days while a storage administrator recovers a server or application from tape. The expectation today ranges from continuously available to minutes in the event of an outage. This applies to specific applications, servers, and even entire data centers.

Traditional IT would match a specific application's RTO/RPO objectives to a specific storage architecture or storage strategy. Within the IaaS model, RTOs/RPOs are defined as part of a service-level offering within the IT Service Catalog. The individual application dependencies have transformed in favor of service-oriented RTO/RPO levels. Organizations can now focus the most efficient methods for RTO/RPO per service level. For example, gold may warrant hourly snapshots with synchronous replication with an RPO/RTO expectation of minutes. A bronze service level may warrant only daily backups with an RPO/RTO of four hours. The RTO/RPO expectations are now set by service level, not by application. This helps set a standard level of service throughout the cloud infrastructure, reduces complexity and cost, and sets a standard level of expectation. Because of this, the verification process is simplified and easier to monitor, thereby ensuring the IaaS cloud remains in compliance.

For more information, refer to the Recommended Reading section.

Design and Implement Backup Services

Data is the organization's gold. Protecting it is job one. Never underestimate the importance of backup. Traditional backup and recovery solutions will have to transform into integrated multi-tenant services for the cloud. Data protection and capacity optimization strategies will have to transform to keep up with the service transformation of the cloud. Like it or not, organizations will have to create, in part or holistically, a data life cycle management (DLM) plan. Understanding information about the data — such as risk profile, litigation constraints, business impact, and RTO/RPO goals — is critical when designing storage for the internal cloud. All of the layers within the IaaS model will use some or all of the DLM information to perform their specific functions. For example, the Enterprise Service Management layer will have to know where and how to associate the data for a specific service level to a specific service or physical infrastructure location. Backup services must have tight integration with many of the IaaS cloud layers to execute the appropriate services. For example, NetApp and CommVault have collaborated to offer an integrated backup solution that integrates NetApp's snapshot and replication features into CommVault Simpana's backup application.

Backup services must take into account VM and data mobility. Organizations should consider hypervisor-based backup schemes versus proxy-based approaches versus array-level backups. Traditionally, organizations would select one of these backup methods; however, with a service-oriented architecture, many organizations will implement multiple approaches to service the different SLA requirements and data mobility of the internal cloud. For example, smaller organizations may implement a VM-only approach where the backup software would reside on a backup VM. Larger organizations may choose to implement a storage-only approach to move massive amounts of data and offload the I/O burden away from the hypervisor server. Implementation details are dependent on service-level requirements, storage-infrastructure maturity, and size of the organization and associated data.

Seamless, automated, and transparent operation — offering single pane of glass management with simplified operation — is the key to a well-designed backup service. Backup services must support traditional backup methodologies as well as snapshots, replication, disk-to-disk (D2D), and data deduplication targets automatically migrating data to tape. Backup for the cloud is not only mobile; it is often dispersed, with many intermediary staging areas. This data mobility and distributed model would add complexity if it were not automated, standardized, and integrated into the IaaS cloud. Organizations must determine the best approach for their environments. Backup services for the internal cloud must address the following key challenges:

• Risk mitigation: Continuous availability, legal compliance, guaranteed recovery
• Data mobility: Storage and VM mobility, tiers of storage, D2D, disk-to-disk-to-any (D2D2x)
• Multi-tenant: Data placement to match RPO/RTO SLA expectations, separation of datasets
• Capacity optimization: Data reduction, data deduplication, compression
• Scalability and flexibility: Flexibility to grow or shrink resources automatically
• Business agility: Service-oriented SLAs following VM or storage migration

There are many risks and pitfalls when considering transforming traditional storage to storage for the internal cloud. Executive management sponsorship will be critical to ensuring that the entire organization is behind the transformation effort. This includes financial budgets needed, time to execute the project, and retraining of personal. Monitoring savings associate with the program and staying within budget is important to ensure that the internal cloud transformation is on track.

Understanding how, where, and when storage applies to the IaaS model will aid organizations in the transformation process. A storage assessment is a critical step in the process to determine if the existing infrastructure is sufficient, if modifications are required, or if the cloud requires new storage hardware and software. The biggest risks and pitfalls to the organization can be broken down into two categories: business and technology:

Business risks include:

• Not gaining executive sponsorship prior to the internal cloud planning phase
• Underestimating the time to complete the transformation and setting executive management expectations
• Underestimating the complexity associate with building the internal cloud
• Not breaking the project down into smaller achievable milestones
• Cost
• Training
• User acceptance
• Maturity of the storage market

Technology risks include:

• Missing key storage integration points
• SLA mismatch with storage architecture, design, and strategy
• Improper storage assessment (existing/new) and remaining life cycle of existing storage assets
• Partial or incomplete integration
• Time, testing, (in some cases) vendor lock-in
• Required API integration, scripting needed
• Storage infrastructure and automation software may be difficult to integrate
• Storage maturity
• Vendors exiting from the market

Storage for the internal cloud is all about storage transformation and integration within the IaaS cloud. It must be a well thought out and pragmatic journey, and it requires cross-functional planning, storage assessments, and integration with many components of the IaaS cloud. Without storage transformation and tight integration, organizations will struggle to reach the potential the internal cloud has to offer.

November 2011

• First edition.