As we saw earlier, Distributed Resource Scheduler
(DRS) is one of the key VMware features that optimize the performance
and resources of your vSphere cluster. With vSphere 5.0, VMware
introduced “Storage DRS” which uses Storage vMotion to move Virtual
Machine Disk files (VMDKs) between datastores in a Datastore Cluster.
This advanced capability is only available with the Enterprise Plus license of vSphere, which is normal, as only the upper class of enterprise customers will have a significant number of datastores that need easier management.
A graph from VMware showing Storage DRS
As with host DRS, Storage DRS provides effective initial placement of virtual machine disks as it tries to put the disks on the datastore with the least average I/O latency and highest free disk space in the cluster. But unlike DRS, initial placement is always manual with SDRS.
After initial placement, SDRS keeps an eye on datastores to avoid out-of-space conditions. If the utilization of a datastore reaches a preconfigured value, DRS may recommend moving virtual disks off this storage to another less utilized datastore. It even looks at the history of space utilization growth and extrapolates that pattern into the next 30 hours before deciding which datastore is attractive.
It also keeps an eye on I/O latency and evaluates the last 24 hours, on average every 8 hours, to consider if it is a good idea to recommend moving virtual disks off heavily loaded datastores, as lower overall latency means higher throughput.
Like host DRS, Storage DRS does not recommend any moves that provide marginal benefits. It also considers and calculates that during storage migration there is an I/O cost on both the source and destination datastore.
You can also put a datastore in maintenance mode to make SDRS move virtual disks off the datastore to clear for decommission or a scheduled maintenance.
This makes the lives of both the SAN admin and the virtualization admin much easier while also reducing imbalances and service degradations that can be caused by choices that were not made after considering the data for important performance and utilization patterns.
Give your datastore cluster a name and keep the “Turn ON Storage DRS” cluster box checked (after all that is why we are creating this cluster). Datastore Clusters can be used without SDRS to group datastores as a folder, but there is little value in that.
On the following step, you can chose whether you want a “Fully Automated” cluster that migrates files as it sees fit in order to optimize the datastore cluster’s performance and utilization, or, if you prefer, you can chose for it to ask you to approve reccomendations. In contrast with host DRS where most admins trust it to run in automatic mode, most admins prefer to run SDRS in “Manual Mode.” Maybe because it is still a relatively new feature, but I believe that it is largely due to the fact that moving virtual disks takes significantly more time and resources than moving the running state of a virtual machine.
Here you can decide what utilization levels or I/O Latency will trigger SDRS action. To benefit from I/O metric, all your hosts that will be using this datastore cluster must be version 5.0 or later. Here you can also access some advanced and very important settings like defining what is considered a marginal benefit for migration, how often does SDRS check for imbalance and how aggressive should the algorithm be.
Then you pick what standalone hosts and/or host clusters will have access to the new Datastore Cluster.
According to your choice of hosts and/or host clusters above, you will be presented with a list of datastores that can be included in the cluster. You can list datastores that are connected to all hosts, some hosts or all datastores that are connected to any of the hosts and/or clusters you have chosen in the previous step.
At this point you will review your choices and conclude the wizard.
In no time you will have your datastore cluster ready and operational.
To make things easier, we will add a LUN to our datastore cluster that is already utilized above the threshold required to kickoff Storage DRS recommendations. One way to do this is to “move datastore into” the cluster from its “Getting Started” screen.
The only other datastore that is connected to all hosts in the DRS cluster is the relatively small 570GB LUN, so we pick it as this LUN is already filled above the currently configured 80% “Utilized Space Threshold.”
Notice that SDRS recommendations are well supported with information about the expected impact on space utilization and/or latency. This will help the admin understand the value of the recommendation before applying it.
Change what you see fit. In this case, we deselected the “Enable I/O metric” option.
We also need to set a time for the schedule to run, in addition to giving it a proper descriptive name.
Keep in mind to create another scheduled task to turn I/O metric back after backups. To check, edit, delete or even run your scheduled Storage DRS tasks you can go to the “Scheduled Tasks” sub-tab.
Storage DRS can run in automatic mode, but most admins are using it in manual mode. This is understandable as we must keep in mind that Storage vMotion is not as light as vMotion, and hence should not be taken lightly.
Storage DRS does use other storage management technologies like Storage I/O Control (SIOC), and can benefit from others like Profile-Driven Storage and vSphere API for Storage Awareness (VASA).
This advanced capability is only available with the Enterprise Plus license of vSphere, which is normal, as only the upper class of enterprise customers will have a significant number of datastores that need easier management.
A graph from VMware showing Storage DRS
As with host DRS, Storage DRS provides effective initial placement of virtual machine disks as it tries to put the disks on the datastore with the least average I/O latency and highest free disk space in the cluster. But unlike DRS, initial placement is always manual with SDRS.
After initial placement, SDRS keeps an eye on datastores to avoid out-of-space conditions. If the utilization of a datastore reaches a preconfigured value, DRS may recommend moving virtual disks off this storage to another less utilized datastore. It even looks at the history of space utilization growth and extrapolates that pattern into the next 30 hours before deciding which datastore is attractive.
It also keeps an eye on I/O latency and evaluates the last 24 hours, on average every 8 hours, to consider if it is a good idea to recommend moving virtual disks off heavily loaded datastores, as lower overall latency means higher throughput.
Like host DRS, Storage DRS does not recommend any moves that provide marginal benefits. It also considers and calculates that during storage migration there is an I/O cost on both the source and destination datastore.
You can also put a datastore in maintenance mode to make SDRS move virtual disks off the datastore to clear for decommission or a scheduled maintenance.
This makes the lives of both the SAN admin and the virtualization admin much easier while also reducing imbalances and service degradations that can be caused by choices that were not made after considering the data for important performance and utilization patterns.
Creating a New Datastore Cluster
The first step is to go to the Storage Inventory Tree, right click on a Data Center object and choose the “New Datastore Cluster” Option.
Give your datastore cluster a name and keep the “Turn ON Storage DRS” cluster box checked (after all that is why we are creating this cluster). Datastore Clusters can be used without SDRS to group datastores as a folder, but there is little value in that.
On the following step, you can chose whether you want a “Fully Automated” cluster that migrates files as it sees fit in order to optimize the datastore cluster’s performance and utilization, or, if you prefer, you can chose for it to ask you to approve reccomendations. In contrast with host DRS where most admins trust it to run in automatic mode, most admins prefer to run SDRS in “Manual Mode.” Maybe because it is still a relatively new feature, but I believe that it is largely due to the fact that moving virtual disks takes significantly more time and resources than moving the running state of a virtual machine.
Here you can decide what utilization levels or I/O Latency will trigger SDRS action. To benefit from I/O metric, all your hosts that will be using this datastore cluster must be version 5.0 or later. Here you can also access some advanced and very important settings like defining what is considered a marginal benefit for migration, how often does SDRS check for imbalance and how aggressive should the algorithm be.
Then you pick what standalone hosts and/or host clusters will have access to the new Datastore Cluster.
According to your choice of hosts and/or host clusters above, you will be presented with a list of datastores that can be included in the cluster. You can list datastores that are connected to all hosts, some hosts or all datastores that are connected to any of the hosts and/or clusters you have chosen in the previous step.
At this point you will review your choices and conclude the wizard.
In no time you will have your datastore cluster ready and operational.
Testing Storage DRS
In addition to the scheduled checks, Storage DRS runs each time a datastore crosses the space threshold. You change the configuration of the cluster by adding a datastore or defining a new rule, or if we push that button that says “Run Storage DRS Now.”
To make things easier, we will add a LUN to our datastore cluster that is already utilized above the threshold required to kickoff Storage DRS recommendations. One way to do this is to “move datastore into” the cluster from its “Getting Started” screen.
The only other datastore that is connected to all hosts in the DRS cluster is the relatively small 570GB LUN, so we pick it as this LUN is already filled above the currently configured 80% “Utilized Space Threshold.”
Notice that SDRS recommendations are well supported with information about the expected impact on space utilization and/or latency. This will help the admin understand the value of the recommendation before applying it.
Scheduling Storage DRS Configuration Changes
One good example for the need to schedule a change in SDRS configuration is to cope with high I/O that may result from a backup process. This can be done using the “Schedule Storage DRS” button on the Settings sub-tab of the Datastore Cluster.
Change what you see fit. In this case, we deselected the “Enable I/O metric” option.
We also need to set a time for the schedule to run, in addition to giving it a proper descriptive name.
Keep in mind to create another scheduled task to turn I/O metric back after backups. To check, edit, delete or even run your scheduled Storage DRS tasks you can go to the “Scheduled Tasks” sub-tab.
Conclusion
Storage DRS to datastores is like DRS to hosts. It moves VMDKs from heavily utilized to less utilized datastores according to preset space and I/O metrics, making efficient storage management more achievable.Storage DRS can run in automatic mode, but most admins are using it in manual mode. This is understandable as we must keep in mind that Storage vMotion is not as light as vMotion, and hence should not be taken lightly.
Storage DRS does use other storage management technologies like Storage I/O Control (SIOC), and can benefit from others like Profile-Driven Storage and vSphere API for Storage Awareness (VASA).
Nice blog has been shared by you. before i read this blog i didn't have any knowledge about this but now i got some knowledge.
ReplyDeleteso keep on sharing such kind of an interesting blogs. VMware Institute in Delhi