This chapter is from the book
This chapter is from the book
This chapter is from the book
Storage DRS
Storage DRS (SDRS) allows the automation of the choice of datastore to use for VMs. It makes for more balanced performance and more efficient storage space. This frees up time for administrators, who no longer have to spend time choosing which datastore to use. To function, datastores are grouped in datastore clusters.
SDRS takes care of the following operations:
- Initial placement of a VM
- Balancing the load between datastores according to the following factors:
- The use of storage space
- The I/O load based on latency
Initial placement occurs when a VM is created, moved, or cloned. Based on the space used and I/O charge of the cluster’s datastores, SDRS provides a particular datastore to store the vmdk.
Datastore Load Balancing
The load balancing is performed every 2 hours for used space and every 8 hours for the I/O load based on the history of the last 24 hours. As shown in Figure 3.17, SDRS makes migration recommendations when a datastore passes the thresholds defined by the user based on the percentage of disk space used (80% by default) and/or the I/O latency (15 ms by default).
)
Figure 3.17. SDRS interface showing load balancing information.
Several levels of automation are possible:
- Manual (default).
- Automatic.
- Planned (scheduled). The planning mode is interesting during a backup period, for example; it is not necessary to move the virtual disks. It is therefore possible to disable SDRS during the backup operations.
- Datastore maintenance mode. A datastore’s maintenance mode removes all vmdks from the datastore and distributes them to the cluster’s other datastores.
At this point, you might ask, “How does SDRS detect the datastores’ I/O load?”
SDRS uses the SIOC functionality and an injector mechanism to choose the best target datastore to use. The injector is used to determine each datastore’s characteristics by randomly “injecting” I/O. This allows it to determine the response time and latency associated with each datastore.
Affinity Rules
As illustrated in Figure 3.18, several affinity rules can be applied:
- Intra-VM vmdk affinity: All the same vmdk VMs are placed on the same datastore.
- Intra-VM vmdk anti-affinity: This rule can be applied to ensure that the vmdks are placed on different datastores. This rule is useful, for instance, to separate a database VM’s log disks from its data disks. The rule applies to all or part of the disks within a VM.
- VM-VM anti-affinity: Different VM are placed on separate datastores. This offers redundancy for VMs in the event of failure of a datastore.
)
Figure 3.18. Affinity rules.
The current limitations of SDRS are as follows:
- SDRS is not supported with SRM.
- SDRS works only with hosts using ESXi5 or later.
Profile-Driven Storage
Profile-Driven Storage preserves the compliance of VMs with the defined storage needs. This functionality eliminates initial placement errors and simplifies day-to-day management for administrators by automating these tasks. Administrators create profiles that contain the characteristics of the storage. These can be enforced using vSphere Storage storage-detection APIs (VASA) or associated with indicators defined by the user (for example, Gold, Silver, Bronze).
A VM’s profile is associated during provisioning, creation, migration, cloning, and so on. If the VM is placed in a storage space offering the capacities defined in the VM’s storage profile, such storage is deemed compliant. Profile-Driven Storage complements SDRS for initial placement and the automatic migration of vmdk.