Advanced concepts, operations, and functions in the Virtual Volumes environment
This chapter contains information about the internal storage system mechanisms that are required to support the Virtual Volumes (VVols) environment. Strictly speaking, the storage administrator does not need to be aware of all of the details contained within this chapter, because the entire environment is maintained automatically by the system after the initial configuration has been performed. However, there are a few items described here that are pivotal to understanding VVols within the context of your storage system:
For interested readers, we also consider how the storage system responds to the following vSphere tasks in the VVols environment:
8.1 Types of VVols
From the perspective of the vSphere infrastructure, there are five different types of VVol. Each of them provides a specific function depending on their role within the vSphere environment:
•Config VVol
 – Contains VM configuration files, logs, and so on.
 – Created on the storage system as a thin-provisioned VVol with 4 gigabyte (GB) capacity.
•Data VVol
 – Equivalent to a conventional virtual machine disk (VMDK), holds a VM’s system data.
 – Created on the storage system per the selected storage policy. Capacity corresponds to size of the virtual machine’s (VM’s) hard disk.
•Swap VVol
 – Virtual machine memory swap file.
 – Created on the storage system as a thick-provisioned VVol. The capacity correlates to the amount of memory allocated to the VM.
•Memory VVol
 – Captured as part of some snapshot operations.
 – Created on the storage system as a thick-provisioned VVol. Capacity directly correlates to the amount of memory allocated to the VM.
•Other VVol
 – vSphere solution-specific object.
All virtual machines are created with a Config VVol and a Data VVol. When powered on, a Swap VVol is created for a virtual machine. This means that any running VM consists of at least three VVols. Because each of a virtual machine’s disks corresponds to an individual VVol, adding another hard drive to a VM creates a unique Data VVol on the storage system.
The usage for a Memory VVol is described in the following sections, when we consider virtual machine snapshots. Other VVols are rarely seen in the conventional environment. Therefore, a description of such objects is not covered in this IBM Redbooks publication.
8.2 Number of VVols
It is important to remember that, from the point of view of the storage system, a VVol is just a special type of volume, with certain unique properties. Consequently, you should note that the total number of volumes provisioned on the storage system is inclusive of the number of VVols. This means that VVols should be factored into any metrics concerning maximum limits with regards to volumes.
Because the storage administrator does not need to interact with individual VVols, they are filtered out of the Volumes panel on the management graphical user interface (GUI), for convenience. However, you can use the GUI to monitor the overall number of VVols in a child pool by navigating to Pools → Volumes by Pool.
Figure 8-1 shows the volume count for a child pool allocated to the VVols environment.
Figure 8-1 Monitoring the number of VVols in a child pool
8.3 IBM FlashCopy functionality in a VVols environment
The capability to take a snapshot or clone of a virtual machine has been available in the vSphere environment for several years. Before the introduction of Virtual Volumes, the disks generated by these operations were contained within a VMFS datastore, and the relationships between them were managed entirely by the vSphere infrastructure.
By making virtual machine disks (individual VVols) available at the storage level, the Virtual Volumes feature enables the storage system to handle snapshot and clone operations using IBM FlashCopy.
 
Important: As the use of clone and snapshot operations is ubiquitous in vSphere environments, we stipulate that the appropriate IBM FlashCopy license for your system is configured before implementing Virtual Volumes.
There are several benefits that can be derived from offloading these tasks to the storage system, including the following benefits:
•Processor (CPU) use required for snapshot and clone tasks is transferred to the storage system, freeing up VMware ESXi host resources.
•Rapid availability of clones, regardless of data disk size.
•Increased recommended lifecycle and length of chain for snapshots: No requirement to remove a snapshot after 72 hours or keep chains to 2 - 3 snapshots.
Later in this chapter, we consider how FlashCopy achieves the last two benefits by analyzing some specific use-cases.
8.3.1 A basic introduction to IBM FlashCopy
Before considering specific VVols-related tasks, it is important to understand the basic function that FlashCopy provides. By enabling users to take a point-in-time copy of a volume, FlashCopy offers a powerful solution for several critical and challenging business requirements. With FlashCopy, both the source and target volumes involved in the operation are available for host input/output (I/O) as soon as the relationship is started. Crucially, both volumes remain accessible throughout the copy process.
In the Virtual Volumes environment, the source volume in a FlashCopy relationship could be the Data VVol, for example, the guest operating system (OS) for a VM. This entails that a VVols-enabled ESXi host can have access to a full, independent image of this Data VVol (the FlashCopy target) almost instantaneously, without affecting I/O operations to the source.
Consequently, we can immediately envision scenarios where FlashCopy can provide benefits in the VVols environment. For a further explanation of particular VVols use-cases, see the following examples.
 
Additional information: FlashCopy delivers these powerful capabilities by implementing a bitmap to track the differences between the source and target volumes involved in a FlashCopy relationship. This bitmap is used to record whether each grain (64 kilobyte (KB) or 256 KB unit of data) is common to the source and target volumes.
On starting a FlashCopy mapping, this bitmap is initialized. In the majority of cases, every grain in the bitmap is marked as unsplit, meaning that both volumes contain an identical set of data (from the host point of view).
An incoming host write to either the source or target volume, results in updates to the bitmap, indicating that the data for the corresponding grain is now split. That is, the data on the source and target is non-identical for a particular unit of data. An incoming read operation to the target results in the system consulting the bitmap to establish whether the relevant grain should be read from the source (in the case of an unsplit grain) or the target (for a split grain).
When required, an indirection layer enables read operations to be redirected to the source without disrupting the host or application. From the host point of view, this enables us to create the impression that the target volume presents a complete version of the data almost instantaneously, without quiescing the I/O for a long time, or taking the source volume offline. For further information about IBM FlashCopy, see IBM System Storage SAN Volume Controller and Storwize V7000 Replication Family Services, SG24-7574.
8.4 Clone operations
In the vSphere environment, a virtual machine can be cloned while it is running or powered-off. It is also possible to clone a virtual machine from a template. FlashCopy is used to perform these tasks if the virtual machine is on a VVol datastore. For the purposes of this example, we consider a simple clone operation of a powered-off virtual machine.
 
Note: These steps vary slightly if the virtual machine is running, but the core FlashCopy function is unchanged by this factor.
We start with the following VVols:
•Source_Config_VVol (containing virtual machine metadata)
•Source_Data_VVol (containing the OS)
When the user initiates a clone operation from within the vSphere Web Client, IBM Spectrum Control Base Edition (SCB) runs several commands on the storage system in rapid succession.
SCB runs the following commands:
1. Create a Config VVol for the clone target. This stores metadata for the new VM.
2. Create a Data VVol for the clone target (Target_Data_VVol). This contains the OS for the new VM.
3. Create bindings between the VVols and a protocol endpoint (PE). This enables an ESXi host to access the newly created VVols for I/O operations.
4. Create a FlashCopy mapping of type clone between Source_Data_VVol and Target_Data_VVol.
5. Prepare and start the FlashCopy mapping.
At this point, IBM Spectrum Control Base Edition can inform vSphere that the new virtual machine is available for use. Because the target of a clone operation is available to the host upon the FlashCopy relationship starting (rather than on completion). The new virtual machine is available almost instantaneously. Figure 8-2 provides an overview of the clone operation for a virtual machine’s Data VVol.
Figure 8-2 FlashCopy clones the Data VVol for a source virtual machine. Note that the ESXi host has full read/write access to both Data VVols as soon as the mapping is started.
As far as the vSphere administrator is concerned, he has a new stand-alone virtual machine as soon as the FlashCopy relationship has been started. Because of this, the required resource use (in terms of the speed of the availability of the target) is not increased significantly by the size of our Source_Data_VVol. Consequently, a VM with very large additional disks can be cloned extremely rapidly when using FlashCopy.
Additional information
Behind the scenes, triggering a clone operation causes the storage system to begin transferring data from Source_Data_VVol to Target_Data_VVol using a process known as background copy. Setting a background copy rate of greater than zero results in a complete copy of the source volume being created on the storage system.
Because the clone command triggered by SCB also specifies the -autodelete flag, the FlashCopy mapping is deleted after the background copy process is complete. This results in a stand-alone copy of the data and, in this case, a stand-alone virtual machine.
8.5 Snapshot operations
In the vSphere environment, users can take a snapshot of a virtual machine. They can revert to this point-in-time image on demand. For virtual machines based on VVol datastores, these tasks are again offloaded to the storage system, where FlashCopy is used to meet the requirements of the vSphere environment.
8.5.1 Taking a snapshot
The process for taking a snapshot of a virtual machine is almost identical for a powered-on or powered-off virtual machine. We indicate the differences for a live VM where relevant.
We start with the following VVols:
•Base_Config_VVol (containing virtual machine metadata)
•Base_Data_VVol (containing the OS)
•Swap_VVol (only present if the VM is powered on)
When the user takes a virtual machine snapshot using the vSphere Web Client, SCB runs several commands on the storage system in rapid succession:
1. Create a Data VVol, from now on called Snapshot_Data_VVol. This serves as the point-in-time image of Base_Data_VVol.
2. Create a FlashCopy mapping of type snapshot between Base_Data_VVol and Snapshot_Data_VVol.
3. Prepare and start the FlashCopy mapping.
 
Note: If the user chooses to snapshot the virtual machine’s memory, SCB also performs the following actions:
1. Creates a new Memory VVol.
2. Creates a binding between the Memory VVol and a protocol endpoint. This enables an ESXi host to write the snapshot memory-state to this VVol.
Taking a snapshot of a virtual machine does not result in any downtime of the VM. When the relationship is started, the source volume is briefly “frozen” to initialize the FlashCopy bitmap, and then the I/O on the source volume is enabled to resume. The target volume (Snapshot_Data_VVol) serves as a point-in-time image of the Base_Data_VVol, and is never directly accessed for I/O operations by the ESXi host, as shown in Figure 8-3.
Figure 8-3 In a snapshot operation, the ESXi host only requires access to the Base_Data_VVol for I/O operations
Additional information
The storage system does not create a full copy of the Base_Data_VVol if the FlashCopy mapping is a snapshot. Unlike a clone, a snapshot FlashCopy relationship is created with a background copy rate of zero. Data is only copied onto the target (Snapshot_Data_VVol) if changes are made to the source (Base_Data_VVol).
For example, we might update the OS hosted on Base_Data_VVol after the snapshot is taken. For each host write associated with this update, FlashCopy checks the bitmap to see whether the corresponding grain has already been copied to the target.
Assuming that it has not (as is the case in our snapshot example), the original data for this grain is copied onto Snapshot_Data_VVol. The incoming data can then be written to Base_Data_VVol.
This approach ensures that a snapshot volume only ever contains the changes and never occupies more space than it needs to. See Figure 8-4.
Figure 8-4 Movement of data in a snapshot FlashCopy relationship
Note here that the new data is always written to the source, and only original data (the data as it was when the snapshot was created) is copied onto the target. This contrasts with the current VMware file system (VMFS) model, where the new disk created upon taking a snapshot always becomes the running point for the virtual machine.
A snapshot disk (for example, Snapshot_Data_VVol) is created as a thin-provisioned VVol with a very small real size. This ensures that the snapshot VVol contains the smallest amount of storage possible when first created (t0 in Figure 8-4). Setting the autoexpand parameter to on ensures that the snapshot can grow as required (when changes are made to the source), if there is capacity available in the child pool.
8.5.2 Reverting to a snapshot
Outside of the context of the Virtual Volumes environment, it is already possible to use FlashCopy to restore a volume to an earlier state, using a technology known as Reverse FlashCopy. For more information about this, see the section about using Reverse FlashCopy to restore a volume in IBM System Storage SAN Volume Controller and Storwize V7000 Replication Family Services, SG24-7574.
In the Virtual Volumes environment, a revert to snapshot operation run by the vSphere administrator uses similar FlashCopy functionality.
Consider a simple example of a VM with a single snapshot. We start with the following VVols:
•Base_Data_VVol (containing the OS). This is the live version of the data disk, which is accessible to the host.
•Snapshot_Data_VVol. This is the point-in-time image of Base_Data_VVol, taken at a known good state (for example, before applying an update).
The FlashCopy relationship is Base_Data_VVol to Snapshot_Data_VVol.
Suppose we apply an update to the VM’s guest OS and this causes an issue with an important application. Consequently, we decide that we want to roll back to our snapshot. Initiating the revert to snapshot operation from the vSphere Web Client causes IBM Spectrum Control Base Edition to start a Reverse FlashCopy relationship from Snapshot_Data_VVol to Base_Data_VVol.
This gives the host the impression that the Base_Data_VVol is identical to Snapshot_Data_VVol. The ESXi host can resume I/O operations to Base_Data_VVol as soon as the FlashCopy restore operation is initiated.. VM operations can resume from our known good state with minimal delay.
 
Important: The vSphere infrastructure also triggers the creation of a temporary snapshot as part of a revert to snapshot operation. This is a protective measure specific to the ESXi task, and is not pertinent to the FlashCopy functionality used to restore the VM. For simplicity, we omit these steps from the example described here.
Importantly, FlashCopy restore functionality enables the storage system to ensure that the ESXi only ever needs to perform I/O operations to the Base_Data_VVol. The ESXi host never directly accesses Snapshot_Data_VVol. This enables us to maintain a consistent point-in-time image, so that the vSphere administrator can revert to the same snapshot again later. A snapshot can be reverted to as many times as required.
Additional information
To understand how a FlashCopy restore works, it is essential to grasp the concept of a dependency chain.
Because the full copy of data in a FlashCopy relationship only exists on the source volume when the mapping is started, it can be said that the target depends on the source. In the previous example, starting the snapshot mapping (Base_Data_VVol to Snapshot_Data_VVol) gives us the dependency chain Base_Data_VVol(p) to Snapshot_Data_VVol(p).
Starting the restore operation (Snapshot_Data_VVol to Base_Data_VVol), introduces a secondary instantiation of Base_Data_VVol and gives us the following chain:
Base_Data_VVol(s) → Snapshot_Data_VVol(p) → Base_Data_VVol(p)
Base_Data_VVol(s) must remain at the base of the dependency chain, because the base image of the data is here and Snapshot_Data_VVol depends on it. The primary instance, Base_Data_VVol(p), services host I/O directed at Base_Data_VVol. The indirection layer ensures that a host read to a grain that has not yet been restored is redirected to Snapshot_Data_VVol, giving the impression that the restore is immediate.
In the background, the system copies grains from Snapshot_Data_VVol onto Base_Data_VVol, until the restore is complete. The restore operation only copies the grains that are needed to restore Base_Data_VVol to the state that it was in when our snapshot was taken (only the changes that have occurred since taking the snapshot are copied).
After this operation completes, we return to our original FlashCopy dependency chain:
Base_Data_VVol(p) → Snapshot_Data_VVol(p)
This means that we can give the host the impression of an immediate restore, while preserving the consistency of Snapshot_Data_VVol for future restore operations.
At the time of writing, the FlashCopy restore functionality used for Virtual Volumes is not available to the general user. In addition to the simple scenario described previously, the new FlashCopy restore functionality is unique in its ability to deal with the following use cases:
•Request to perform a new restore when another restore is already in progress
•Request to perform a restore when the VVol to be restored is also the target in a FlashCopy relationship
This ensures that the vSphere administrator can perform a revert to snapshot operation on demand, on any VM. The functionality required to perform a FlashCopy restore in the complex use cases mentioned previously is beyond the intended scope of this IBM Redbooks publication.
8.5.3 Deleting snapshots
In the Virtual Volumes environment, each snapshot (delta) is maintained as a unique VVol. A FlashCopy relationship is used to track the differences between the base VVol and a snapshot. It is important to remember that the host only ever reads from the base VVol, which always contains the latest data and serves as the running point for the virtual machine. The snapshot VVol only contains the original data for the grains that have been changed on the base VVol. The host never directly performs I/O operations to the snapshot disk.
Consequently, a delete snapshot operation simply causes IBM Spectrum Control Base Edition to delete the snapshot VVols from the storage system. This process is completely nondisruptive for I/O operations.
Additional information
In the VMFS environment, taking a snapshot causes the creation of a delta file. This delta file always becomes the running point for VM. That is, after we’ve taken a snapshot, write I/O is serviced by the delta disk (snapshot disk), although the base disk services read I/O. Consequently, in the VMFS environment, deleting a snapshot (or snapshot chain) results in the data contained on the delta disks being rolled back into the base disk.
These operations can be time-consuming if the delta disk becomes too large, or if the chain of snapshots is too long. Consequently, VMware’s official preferred practice for VMFS snapshot management states that no single snapshot should be used for more than 24 - 72 hours, and that only 2 - 3 snapshots should be used in a single chain.
Deleting very large snapshots (or large chains of snapshots) is non-problematic in the VVols environment. Because the running point of the VM remains constant (the base VVol), deleting the snapshots simply discards the unused VVols. This entails that the leading practices for snapshots, regarding lifecycle and length of chain, do not apply in the VVols environment.
Although this leading practice is no longer applicable, you might still want to delete snapshots that are no longer required to free up system resources. VVols that serve as managed snapshots only occupy a tiny amount of space when first created. However, each new write to the running point of the VM (the base VVol) causes the original data to be copied onto the managed snapshot VVol. Consequently, deleting old snapshots can be economical, because the amount of data contained by these VVols is likely to be more substantial.
8.6 Cold migration and storage vMotion in a Virtual Volumes environment
The vSphere administrator can transfer the storage resources for a virtual machine between datastores. If the virtual machine is powered-off, this operation is known as a cold migration. If the virtual machine is running, the operation is known as a Storage vMotion. The Virtual Volumes environment introduces support for the following migration paths for both operations:
•VVol Datastore → VVol Datastore
•VMFS Datastore → VVol Datastore
•VVol Datastore → VMFS Datastore
 
Tip: The ability to migrate VMs between VVol and VMFS datastores (bidirectionally) ensures that a mixed VVol and VMFS environment is possible.
As far as the storage system is concerned, the basic process for each of these operations is the same:
1. Create new VVols (or .vmdks) on the destination datastore.
2. Establish a data path between the new VVols and the ESXi host, by creating new subsidiary volume mappings.
3. Copy the data from the source VVols (or .vmdks) to the target VVols (or .vmdks).
4. When the copy is complete and the VM is solely dependent on the target VVols
(or .vmdks), remove the source VVols (or .vmdks) from the storage system.
Although the fundamental principles of all of these storage migrations are the same, the copy method selected by the ESXi host in step 3 differs, depending on the specifics of the operation (for example, the type and location of the source and destination datastores).
Where possible, the ESXi host uses vSphere APIs for Storage Awareness (VASA) or vStorage APIs for Array Integration (VAAI) to perform the copy operation to optimize performance. These primitives translate into FlashCopy and XCOPY operations on the storage system. If these optimized copy methods are not available (for example, when the source and target datastores are on separate storage systems), the ESXi host automatically falls back to traditional methods.
8.7 vMotion in a Virtual Volumes environment
A vMotion operation is used to transfer a running virtual machine from one compute resource (ESXi host) to another. Because a vMotion operation only changes the compute resource (and not the storage resource), the effect on the storage system is relatively minimal. To complete the operation, the following operations are run by IBM Spectrum Control Base Edition:
1. Create a new Swap VVol.
2. Create a subsidiary volume mapping between the new Swap VVol and the target ESXi host.
3. Create subsidiary volume mappings between the config and data VVols and the target ESXi host. This establishes the data path between the VVols and the new compute resource.
4. After the vSphere infrastructure has transferred the compute resource, remove the redundant subsidiary volume mappings (the mappings between the source ESXi host and the VVols).
5. Remove the additional Swap VVol, because this is no longer required.
At this point, the VVols on the storage system are identical to those that existed before the vMotion operation was initiated. Only the data path has been altered.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.105.84