This chapter covers four use cases for IBM Spectrum Virtualize for Public Cloud.

In this chapter, the following topics are described:

Companies are approaching and using public cloud services from multiple angles. Users that are rewriting and modernizing applications for cloud complement those users that are looking to move to cloud-only new services or to extend existing IT into a hybrid model to address quickly changing capacity and scalability requirements. There are different delivery models for public cloud, such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). The workload deployment is composed of two major use cases, as shown in Figure 2-1:

Cloud-native implementations (that is, whole IT services that are deployed in the public cloud) are composed of several use cases, all with the lowest common denominator of having a full application deployment in the public cloud data centers. The technical details, final architecture, and roles and responsibilities depend on SaaS, PaaS, or IaaS usage. Within the IaaS domain, the transparency of cloud services is the highest because the user’s visibility (and responsibility) into the application stack is much deeper compared to the other delivery models. Conversely, the burden for its deployment is higher because all the components must be designed from the server up. At the time of writing, IBM Spectrum Virtualize for Public Cloud is framed only within the IaaS cloud delivery model so that the user can interact with their storage environment as they did on-premises, which provides more granular control over performance.

A workload or an application that is stand-alone, with few on-premises dependencies, relatively undemanding of I/O performance (low-latency and low response time and high IOPS), and that is not processing highly regulated data, represents a good fit for a cloud-native deployment. The drivers that motivate businesses towards cloud-native deployment span from capital expenditure and operating expenditure reduction, better resource management and controls against hidden or shadow IT resources, more flexibility and scalability, and improved flow in delivering IT service due to the global footprint of the cloud data centers.

At its core, the cloud environment is highly focused on standardization and automation. Therefore, the full spectrum of features and customization that are available in a typical on-premises or outsourcing deployment might not be natively available in the cloud catalog.

Nevertheless, the client does not lose performance and capabilities when deploying a cloud-native application. In this context, the storage virtualization with IBM Spectrum Virtualize for Public Cloud enables the IT staff to maintain the existing technical capabilities and skills to deploy, run, and manage highly available and highly reliable cloud-native applications in a public cloud. In this context, the IBM Spectrum Virtualize for Public Cloud acts as a bridge between the standardized cloud delivery model and the enterprise assets that the client uses in their traditional IT environment.

In a hybrid multicloud environment, the orchestration of the infrastructure requires multiple entities that are tightly integrated with each other and smartly respond to administrator or user needs, and that is where a software-defined environment (SDE) has an important role in the overall orchestration. Integration between service delivery, management, orchestration, automation, and hardware systems is becoming a requirement to support the emergence of SDEs. For SDEs to provide their benefits, they must understand and manage all the components of the infrastructure, including storage, and that makes software-defined storage (SDS) more relevant and important.

The capability of collecting the information from storage systems and providing a simplified multicloud deployment across IBM Storage systems is provided by IBM Spectrum Connect. IBM Spectrum Virtualize for Public Cloud on Amazon Web Services (AWS) and IBM Spectrum Connect integrate vRealize Orchestrator with vRealize Automation, which takes the service around infrastructure beyond orchestration. By integrating the Advanced Service Designer feature of vRealize Automation with vRealize Orchestrator, an organization can offer anything as a service (XaaS) to its users. Using the XaaS feature of vRealize Automation, IBM Spectrum Virtualize Storage System and IBM Spectrum Virtualize for Public Cloud on AWS can be delivered as SaaS in a multicloud environment, whether it is deployed in private cloud or a public cloud multicloud environment.

The architecture is directly responsible for an application’s reliability and availability if there is component failure (either hardware and software). When an application is fully hosted on cloud, the cloud data center becomes the primary site (production site). Cloud deployment does not guarantee 100% uptime, that the backups are available by default, or that the application is automatically replicated between different sites. These security, availability, and recovery features are often not the client’s responsibility if the service is delivered by the SaaS model, are partially the user’s responsibility in the PaaS model, and are entirely the client’s responsibility in the IaaS model.

Having reliable cloud deployments means that the service provider must meet the required service level agreement (SLA), which guarantees service availability and uptime. Companies that use a public cloud IaaS can meet required SLAs either by implementing highly available solutions and duplicating the infrastructure in the same data center or in two data centers to maintain business continuity in case of failures. If business continuity is not enough to reach the requirements of the SLA, then disaster recovery (DR) implementations, which split the application among multiple cloud data centers (usually with a distance of at least 300 Km) prevent failure in a major disaster in the organization’s main campus.

The highly available deployment models for an application that is fully deployed on public cloud are summarized as follows:

When fully moving an application to a cloud IaaS that is the primary site for service delivery, a reasonable approach is implementing at least a highly available architecture. Each component (servers, network components, and storage) is redundant to avoid SPOF.

Within the single primary site deployment, storage is usually deployed as native cloud storage. Using the public cloud catalog storage, users can take advantage of the intrinsic availability (and SLAs) of the storage service, which is Amazon Elastic Block Store (EBS) volumes types in this case.

When IBM Spectrum Virtualize for Public Cloud is deployed as clustered pair of Elastic Compute Cloud (EC2) instances, it mediates between the cloud block storage and the workload hosts. In the specific context of single-site deployment, IBM Spectrum Virtualize for Public Cloud supports extra features that enhance the public cloud block-storage offering. At the storage level, IBM Spectrum Virtualize for Public Cloud resolves some limitations due to the standardized model of public cloud providers: a maximum number of LUNs per host, a maximum volume size, and poor granularity in the choice of tiers for storage snapshots.

IBM Spectrum Virtualize for Public Cloud also provides a new view for the storage management other than the cloud portal. It is a high-level view of the storage infrastructure and some limited specific operations at the volume level (such as volume size, IOPS tuning, and snapshot space increase). What is not provided is a holistic view of the storage from the application perspective.

For more information about the benefits of an IBM Spectrum Virtualize for Public Cloud single site deployment, see Table 2-1.

When the application architecture spans over multiple data centers, it can tolerate the failure of the entire primary data center by switching to the secondary data center. The primary and secondary data centers can be deployed as:

The active-passive configuration is usually the best fit for many cloud use cases, including DR, as shown in 2.2, “Disaster recovery” on page 14. The ability to provision compute resources on demand in a few minutes with just the storage that is provisioned and aligned with a specific RPO is a huge driver for a cost-effective DR infrastructure, and lowers the total cost of ownership (TCO).

The replication among multiple cloud data centers is no different from the traditional approach except for the number of available tools in the cloud. Although existing solutions based on hypervisor or application-layer replication such as VMware, Veeam, and Zerto are available in the public cloud, if the environment is heterogeneous (virtual servers, bare metal servers, multiple hypervisors, and so on), storage-based replication is still the preferable approach.

Active-passive asynchronous mirroring that uses Global Mirror with Change Volumes (GMCV) provides a minimum RPO of 2 minutes (the Change Volume (CV) cycle period ranges is 1 minute - 1 day, and a best practice is setting the cycle period to be half of the RPO), and can replicate a heterogeneous environment.

Since 2018, customers have been harnessing and securing proliferating data in their environment and infrastructure workloads have the highest increase in the adoption of DR.

Technology is just one crucial piece of a DR solution, and not the one that dictates the overall approach.

The section describes DR approach and benefits of IBM Spectrum Virtualize for Public Cloud on AWS.

A DR strategy is the predominant aspect of an overall resiliency solution because it determines what classes of physical events the solution can address, sets the requirements in terms of distance, and sets constraints on technology.

Table 2-2 shows the drivers and the challenges of having a DR solution on cloud and what capabilities IBM Spectrum Virtualize for Public Cloud provides in these areas.

At the time of writing, IBM Spectrum Virtualize for Public Cloud has the following features that are related to DR:

Here are two of the most common scenarios that can be implemented with IBM Spectrum Virtualize for Public Cloud:

As shown in Figure 2-2, a customer can deploy a storage replication infrastructure in a public cloud by using IBM Spectrum Virtualize for Public Cloud.

Here are the details of this scenario:

A replication partnership that uses GMCVs is established between an on-premises IBM Spectrum Virtualize cluster or FlashSystem solution and the virtual IBM Spectrum Virtualize cluster to provide DR.

When talking about DR, understand that IBM Spectrum Virtualize for Public Cloud is an important piece of a more complex solution that has some prerequisites considerations and best practices that must be applied.

The IBM FlashCopy function in IBM Spectrum Virtualize can perform a point-in-time (PiT) copy of one or more volumes. You can use FlashCopy to help you solve critical and challenging business needs that require duplication of data of your source volume. Volumes can remain online and active while you create consistent copies of the data sets. Because the copy is performed at the block level, it operates below the host operating system and its cache. Therefore, the copy is not apparent to the host unless it is mapped.

The business applications for FlashCopy are wide-ranging. Common use cases for FlashCopy include, but are not limited to, the following examples:

Regardless of your business needs, FlashCopy with IBM Spectrum Virtualize is flexible and offers a broad feature set, which makes it applicable to many scenarios.

The association between the source volume and the target volume is defined by a FlashCopy mapping. The FlashCopy mapping can have three different types, four attributes, and seven different states.

FlashCopy in the GUI can be one of the three types:

The FlashCopy mapping has four property attributes (clean rate, copy rate, autodelete, and incremental) and seven different states. The actions users can perform on a FlashCopy mapping are:

The source and target volumes must be the same size. The minimum granularity that
IBM Spectrum Virtualize supports for FlashCopy is an entire volume. It is not possible to use FlashCopy to copy only part of a volume.

The source and target volumes must belong to the same IBM Spectrum Virtualize system, but they do not have to be in the same I/O group or storage pool.

Volumes that are members of a FlashCopy mapping cannot have their sizes increased or decreased while they are members of the FlashCopy mapping.

All FlashCopy operations occur on FlashCopy mappings. FlashCopy does not alter source volumes. Multiple operations can occur at the same time on multiple FlashCopy mappings by using consistency groups.

To overcome the issue of dependent writes across volumes and create a consistent image of the client data, perform a FlashCopy operation on multiple volumes as an atomic operation. To accomplish this task, IBM Spectrum Virtualize supports the concept of consistency groups. Consistency groups preserve PiT data consistency across multiple volumes for applications that include related data that spans multiple volumes. For these volumes, consistency groups maintain the integrity of the FlashCopy by ensuring that dependent writes are run in the application’s intended sequence.

FlashCopy mappings can be part of a consistency group even if there is only one mapping in the consistency group. If a FlashCopy mapping is not part of any consistency group, it is referred to as stand-alone.

FlashCopy consistency groups do not provide application consistency. They only ensure volume points-in-time are consistent between volumes.

Because FlashCopy is at the block level, you must understand the interaction between your application and the host operating system. From a logical standpoint, it is easiest to think of these objects as “layers” that sit on top of one another. The application is the topmost layer, and beneath it is the operating system layer.

Both of these layers have various levels and methods of caching data to provide better speed. Because the IBM SAN Volume Controller and FlashCopy sit below these layers, they are unaware of the cache at the application or operating system layers.

To ensure the integrity of the copy that is made, it is necessary to flush the host operating system and application cache for any outstanding reads or writes before the FlashCopy operation is performed. Failing to flush the host operating system and application cache produces what is referred to as a crash-consistent copy.

The resulting copy requires the same type of recovery procedure, such as log replay and file system checks, that is required following a host crash. FlashCopy copies that are crash-consistent often can be used after the file system and application recovery procedures.

Various operating systems and applications provide facilities to stop I/O operations and ensure that all data is flushed from the host cache. If these facilities are available, they can be used to prepare a FlashCopy operation. When this type of facility is unavailable, the host cache must be flushed manually by quiescing the application and unmounting the file system or drives.

The target volumes are overwritten with a complete image of the source volumes. Before the FlashCopy mappings are started, it is important that any data that is held on the host operating system (or application) caches for the target volumes is discarded. The easiest way to ensure that no data is held in these caches is to unmount the target volumes before the FlashCopy operation starts.

In this section, a use case for IBM Spectrum Virtualize for Public Cloud is illustrated where an entire workload segment is migrated from a client’s enterprise into the cloud. Although the process for relocating a workload into the cloud by using IBM Spectrum Virtualize can use only Remote Copy, there are other mechanisms that can accomplish this task.

All the drivers that motivate businesses to use virtualization technologies makes deploying services into the cloud even more compelling because the cost of idle resources is further absorbed by the cloud provider. However, certain limitations in regulatory or process controls may prevent a business from moving all workloads and application services into the cloud.

An ideal case with regards to a hybrid cloud solution is the relocation of a specific segment of the environment that is well suited, such as development. Another might be a specific application group that does not require either the regulatory isolation or low response time integration with on-premises applications.

Although performance might be a factor, it should not be assumed that cloud deployments automatically create a diminished performance. Depending on the location of the cloud service data center and the intended audience for the migrated service, the performance can conceivably be superior to on-premises pre-migration.

In summary, moving a workload into the cloud might provide similar functions with better economies due to scaling of physical resources in the cloud provider. Moreover, the cost of services in the cloud is structured, measurable, and predictable.

There are multiple methods for performing data migrations to the cloud. Here are three general approaches:

The first method was described in 2.3, “IBM FlashCopy in the public cloud” on page 17, and is essentially the same process as DR. The only difference is that instead of a persistent replication, after the initial synchronization is complete, the goal is to schedule the cutover of the application onto the compute nodes in the cloud environment that is attached to the
IBM Spectrum Virtualize storage.

Host-side mirroring requires the server to have concurrent access to both local and remote storage, which is not feasible. Also, because the object is to relocate the workload (both compute and storage) into the cloud environment, that task is more easily accomplished by replicating the storage and, after it is synchronized, bringing up the server in the cloud environment and making the appropriate adjustments to the server for use in the cloud.

The second method is largely impractical because it requires the host to access both source and target simultaneously, and the practical impediments to creating an iSCSI (the only connection method currently available for IBM Spectrum Virtualize in the Public Cloud) connection from on-premises host systems into the cloud are beyond the scope of this use case. Traditional VMware Storage vMotion is similar, but again requires the target storage to be visible through iSCSI to the existing host.

The third method entails the use of third-party software and or hardware to move the data from one environment to another one. The general idea is that the target system has an operating system and some empty storage that is provisioned to it that acts as a landing pad for data that is on the source system. Going into detail about these methods is also outside the scope of this document, but the process is no different between an on-premises to cloud migration as it is to an on-premises to on-premises migration.

Table 2-3 shows the migration methods.

In addition to the replication of data, it is necessary for compute nodes and networking to be provisioned within the cloud provider upon which to run the relocated workload. Currently, in the AWS Cloud the EC2 compute nodes are available with storage that is provisioned to the EC2 compute instance by using an iSCSI connection.

The following list describes implementation considerations for the workload relocation into the public cloud use case: