VMware's Virtual Volumes - Can't I Deploy?
VMware has completed a long and painstaking work on a new storage concept for vSphere 6.0 with the support of software repositories and the structure of Virtual Volumes (VVols), which will be my today's post. I’ll start with the official definition from the manufacturer: “Virtual Volumes is a new integration and management structure that provides for virtualization of SAN and NAS arrays by creating an effective operational model that is optimized for virtualized environments and is focused on application features, not infrastructure.”
It seems that in the future, Virtual Volumes will replace VMFS, because VMware never sprays support for two different options for key infrastructure components, that is, double work. First, they abolished ESX several years after the release of ESXi, then VSA, replacing VSAN, and now they are trying to transfer users from the vSphere Client to the Web Client; I admit that at some point they may decide to switch from vCenter Server to Windows to VCSA. Therefore, we can assume that a similar fate awaits VMFS, which will be abandoned in favor of VVols - of course, after they reach a certain stage of “maturity” and are accepted for use by the majority of the user audience. This is confirmed by the fact that VVols support is included in all vSphere editions.
Let us find out, however, for a start, why experts advise not to rush into the implementation of Virtual Volumes.
')
This is quite a serious reason, especially for large organizations whose replication of storage arrays is fundamental in their data protection and recovery strategy. Storage replication support for today is not stated in the VASA 2.0 specification, so SRM and vMSC do not work with VVols - for some it will be enough to not read further. I note, however, that although VMware does not support replication of storage arrays, some manufacturers plan or already provide such support, so some workaround exists (but it still cannot be used with SRM or vMSC until VMware includes it in the specification). VASA).
Yes, despite the years spent on development, this is only version 1.0, and, like the first version of any product, it is subject to “growing pains”, which can make users wait for a while. In addition, there is a certain lack of support for interoperability (namely, replication); As for the support from the storage array itself (which also required considerable labor costs on the part of manufacturers) - it also comes out in the initial version. Among the manufacturers involved in the development of architecture are all distinguished HP, NetApp and Dell, who have been doing this for several years, so their solutions are likely to be the most mature in terms of readiness for use.
Currently, there are four manufacturers that have Day 1 support for VVols in the VMware Hardware Compatibility Guide. This list will, of course, expand as other manufacturing companies complete the development and pass VMware certification for VVols; Now manufacturers are also busy expanding the range of supported capabilities for VVols.
Remember how it was when you first told the network administrator about the vSwitch and voiced the network requirements for vSphere? Without a doubt, the man felt the power slipping from his hands. Perhaps you did not even manage to disperse the world :). A similar scenario is quite likely today, when you start talking about VVols in a conversation with the storage system administrator. However, as history has shown, “resistance is useless!” - and then the vSphere administrators won the battle against network administrators, and now they are likely to win and the storage administrators. In order to do without a fight, we advise you to engage them in cooperation, explaining what VVols is, how it works and how it will simplify their lives because the relationship between the virtual infrastructure and the storage system will significantly improve.
There are not yet sufficient performance statistics to see how well VVols is scalable compared to VMFS, i.e. will they be better in this respect, worse or the same. I assume that this solution is approximately the same as VMFS in terms of scalability, or even slightly better. Strictly speaking, VVols was developed not as a means of increasing performance relative to VMFS, but as a completely new software storage architecture, a new approach oriented to a virtual machine as a storage unit in the storage array. The same can be said about the comparison of RDM and VMFS - it was not about improving performance, and VMware proved that their performance is equally high, so I fully admit that this will happen with VVols. There is evidence that VMware is currently performing performance comparison tests, and I hope the results will be available soon.
VMware tried to mimic this functionality inside vSphere for a long time, offering “thin disks”, virtual machine snapshots, Storage vMotion, Storage I / O Control, etc., etc. The life of many of these features will cease in the future, since the implementation of VVols will again lead to the use of the storage array. That is, the process of removing the virtual machine snapshot will automatically turn into creating a snapshot of the storage system; similarly, if “thin disks” are now used to dynamically allocate storage resources, then in the future, storage arrays will deal with them. This is even better, because they allow you to perform these operations faster and more efficiently. However, in order to use these functions, the corresponding storage licenses will be required for the storage array. Some manufacturers may include this functionality in the main set of supported operations, while others will not, therefore you should clarify the cost of supporting the specified functionality in your particular case.
The implementation of VVols will affect the “Direct to SAN” backup process architecture, since it now deals with the Protocol Endpoint and VASA storage provider. At the moment, there is still no information about the mass support of this approach by backup solution providers, but in the near future they will, of course, appear. Ask your vendor how soon your backup solution will support VVol. For example, Veeam supported vVol in the recently released release of Veeam Availability Suite 8.0 Update 2 (read more here ).
Now about the positive.
Although the list of reasons for not rushing to implement VVols looks serious enough, in all other respects, VVols are the best architectural solution for storage in the vSphere environment and provide many advantages. So, just as VSAN allows you to implement Storage Policy Based Management (SPBM) at the virtual machine level, VVols provide the same opportunity for shared storage - and the benefits are, of course, not limited to this.
Therefore, now I propose to consider the list of arguments “For the earliest possible introduction of Virtual Volumes” :
It is not necessary to completely and permanently switch to VVols — virtual volumes can also be used along with VMFS or NFS. VVols is just another option for your architecture. You can easily move virtual machines from VMFS / NFS to VVols and back using Storage vMotion, so you can configure the Storage Container for a virtual volume and create or migrate machines as you like.
Switched from ESX to ESXi later than others and belatedly studied the differences and nuances of work? How long could not get used to the vSphere Web Client? Let's leave in the past these “rakes” and we will not expect that VVols will have to be mastered in a “voluntary-compulsory” mode. The sooner you start exploring the new product, the more confident you will feel when others have just begun their first tentative steps in this direction. And acting as an expert is an honor and a pleasure, because it's great when the knowledge that you gave them came in handy to the people.
Remember, in vSphere 5.0, when VMware implemented the automatic return of unused disk space by the UNMAP team, this led to errors, and as a result, we had to abandon the automation of this operation and do it manually until now, but now the automation is with us again - thanks to VVols. The storage array, having a complete understanding of the removal or movement of a virtual machine, can immediately return to a more unused space. You no longer need to manually run esxcli - everything happens automatically with VVols. If you need to return a place with an even higher level of granularity, then you can still run the UNMAP command on the guest OS. This approach will improve the efficiency of the storage array.
If your storage array supports VVols, there is no need to switch to another vSphere edition — all editions work with VVols. Setting up VVols is easy, so this should not be a deterrent, just the opposite.
Keep up with VSAN users who are already using Storage Policy Based Management. This approach to infrastructure management allows you to customize storage management policies in accordance with the functionality of the storage array — so that the use of the resources and capabilities of your storage becomes oriented directly to virtual machines. Policy-based management allows you to assign resources exactly according to the needs of the virtual machine, as well as monitor compliance with these assignments. VMware has spent a lot of manpower and resources to create this control mechanism - and all in order to ensure maximum efficiency and flexibility in allocating storage resources for virtual machines.
The storage array is, in fact, a mechanism for performing read / write operations, as well as software designed to work with this mechanism. Together they are a powerful tool for working with data. Using VMFS and vSphere storage systems assumes that there is still some kind of “middleman” that tells the actual storage array what to do and when. Of course, such a chain is not the most effective method of work. Having got rid of such a “middleman” and having given the possibility of self-control to the storage array, we obtained the system with the greatest efficiency and optimal result. Note also that the capabilities of the storage array are much broader than comparable vSphere storage systems, plus the fact that the array is much more transparent with respect to storage resources than vSphere. Naturally, such things as dynamic resource allocation (thin provisioning), snapshots and QoS itself in the implementation using storage arrays are much more efficient.
In order to work with VVols, there is no need to retrain as a storage administrator. The average IT administrator can do the administration tasks for VVols, and if you are a VMware administrator, then you don’t even need to open the storage management console once again, since the integration of SPBM and VVols with vCenter provides you with a single management tool (you can control policies and virtual volumes from VMware interface).
Files or blocks? NFS, iSCSI or Fiber Channel? Now it is completely indifferent, for VVols embody a single software repository architecture for all storage protocols and implement, so to speak, a single “level of communication with vSphere”. If you use VVols, you no longer care what was there - VMFS and blocks or NFS and files, now you just have VVols and a number of universal components used with any storage protocol. Of course, each protocol has its own characteristics, but VVols allows “combing one size fits all”, because it uses not unique, but identical properties of all protocols.
And for dessert, the most, perhaps, “tasty” reason: now the storage arrays can work with each individual virtual machine. Using VMFS, “transparency” spreads to the LUN level, and not one level below — because of this, we had no idea what machines were on a particular VMFS volume. With the introduction of VVols, the paradigm is changing: the virtual machine has now become the storage unit. For example, if we want to do an array snapshot for one machine, this is quite feasible (whereas with VMFS we had to do snapshots for the whole LUN). If you need to assign QoS policies to specific Tier-1 virtual machines, this can also be done, since this functionality now works at the virtual machine level. Thus, we are moving away from the concept of VMFS, which was not efficient enough in terms of the use of storage arrays. Now we can allocate resources for storage as needed, without having to reserve huge spaces for VMFS. This was the main idea that VMware embodied in Virtual Volumes.
Of course, each will decide on the use of Virtual Volumes, based on their own understanding of the situation. (Still, remember that the moment will come, and they will no longer say “if you switch to VVols,” but “when you switch to VVols.”) Without a doubt, the new approach has significant advantages — in particular, this is the most efficient allocation of resources. for virtual machines - but before making a decision, you should carefully analyze how the implementation of VVols is consistent with the current work of your infrastructure and the prospects for its development. Since the transition to the new architecture can be done gradually, as already mentioned, using Virtual Volumes along with NFS or VMFS (I mean “there is an elephant in parts”), I can only welcome it.
It seems that in the future, Virtual Volumes will replace VMFS, because VMware never sprays support for two different options for key infrastructure components, that is, double work. First, they abolished ESX several years after the release of ESXi, then VSA, replacing VSAN, and now they are trying to transfer users from the vSphere Client to the Web Client; I admit that at some point they may decide to switch from vCenter Server to Windows to VCSA. Therefore, we can assume that a similar fate awaits VMFS, which will be abandoned in favor of VVols - of course, after they reach a certain stage of “maturity” and are accepted for use by the majority of the user audience. This is confirmed by the fact that VVols support is included in all vSphere editions.
Let us find out, however, for a start, why experts advise not to rush into the implementation of Virtual Volumes.
')
Reason number 1. Storage Array Replication Not Supported
This is quite a serious reason, especially for large organizations whose replication of storage arrays is fundamental in their data protection and recovery strategy. Storage replication support for today is not stated in the VASA 2.0 specification, so SRM and vMSC do not work with VVols - for some it will be enough to not read further. I note, however, that although VMware does not support replication of storage arrays, some manufacturers plan or already provide such support, so some workaround exists (but it still cannot be used with SRM or vMSC until VMware includes it in the specification). VASA).
Reason number 2. This is the first version of the new software storage architecture.
Yes, despite the years spent on development, this is only version 1.0, and, like the first version of any product, it is subject to “growing pains”, which can make users wait for a while. In addition, there is a certain lack of support for interoperability (namely, replication); As for the support from the storage array itself (which also required considerable labor costs on the part of manufacturers) - it also comes out in the initial version. Among the manufacturers involved in the development of architecture are all distinguished HP, NetApp and Dell, who have been doing this for several years, so their solutions are likely to be the most mature in terms of readiness for use.
Reason number 3. Not all storage vendors provide full support for VVols.
Currently, there are four manufacturers that have Day 1 support for VVols in the VMware Hardware Compatibility Guide. This list will, of course, expand as other manufacturing companies complete the development and pass VMware certification for VVols; Now manufacturers are also busy expanding the range of supported capabilities for VVols.
Reason number 4. Who will be the winner in the fight for spheres of influence on the data center?
Remember how it was when you first told the network administrator about the vSwitch and voiced the network requirements for vSphere? Without a doubt, the man felt the power slipping from his hands. Perhaps you did not even manage to disperse the world :). A similar scenario is quite likely today, when you start talking about VVols in a conversation with the storage system administrator. However, as history has shown, “resistance is useless!” - and then the vSphere administrators won the battle against network administrators, and now they are likely to win and the storage administrators. In order to do without a fight, we advise you to engage them in cooperation, explaining what VVols is, how it works and how it will simplify their lives because the relationship between the virtual infrastructure and the storage system will significantly improve.
Reason number 5. How scalable is this architecture?
There are not yet sufficient performance statistics to see how well VVols is scalable compared to VMFS, i.e. will they be better in this respect, worse or the same. I assume that this solution is approximately the same as VMFS in terms of scalability, or even slightly better. Strictly speaking, VVols was developed not as a means of increasing performance relative to VMFS, but as a completely new software storage architecture, a new approach oriented to a virtual machine as a storage unit in the storage array. The same can be said about the comparison of RDM and VMFS - it was not about improving performance, and VMware proved that their performance is equally high, so I fully admit that this will happen with VVols. There is evidence that VMware is currently performing performance comparison tests, and I hope the results will be available soon.
Reason # 6. The functionality of working with storage arrays requires separate licenses
VMware tried to mimic this functionality inside vSphere for a long time, offering “thin disks”, virtual machine snapshots, Storage vMotion, Storage I / O Control, etc., etc. The life of many of these features will cease in the future, since the implementation of VVols will again lead to the use of the storage array. That is, the process of removing the virtual machine snapshot will automatically turn into creating a snapshot of the storage system; similarly, if “thin disks” are now used to dynamically allocate storage resources, then in the future, storage arrays will deal with them. This is even better, because they allow you to perform these operations faster and more efficiently. However, in order to use these functions, the corresponding storage licenses will be required for the storage array. Some manufacturers may include this functionality in the main set of supported operations, while others will not, therefore you should clarify the cost of supporting the specified functionality in your particular case.
Reason # 7. When will backup solution providers catch up?
The implementation of VVols will affect the “Direct to SAN” backup process architecture, since it now deals with the Protocol Endpoint and VASA storage provider. At the moment, there is still no information about the mass support of this approach by backup solution providers, but in the near future they will, of course, appear. Ask your vendor how soon your backup solution will support VVol. For example, Veeam supported vVol in the recently released release of Veeam Availability Suite 8.0 Update 2 (read more here ).
Now about the positive.
Although the list of reasons for not rushing to implement VVols looks serious enough, in all other respects, VVols are the best architectural solution for storage in the vSphere environment and provide many advantages. So, just as VSAN allows you to implement Storage Policy Based Management (SPBM) at the virtual machine level, VVols provide the same opportunity for shared storage - and the benefits are, of course, not limited to this.
Therefore, now I propose to consider the list of arguments “For the earliest possible introduction of Virtual Volumes” :
Reason number 1. There is always a choice and flexible options.
It is not necessary to completely and permanently switch to VVols — virtual volumes can also be used along with VMFS or NFS. VVols is just another option for your architecture. You can easily move virtual machines from VMFS / NFS to VVols and back using Storage vMotion, so you can configure the Storage Container for a virtual volume and create or migrate machines as you like.
Reason number 2. Join enthusiasts in mastering new technologies
Switched from ESX to ESXi later than others and belatedly studied the differences and nuances of work? How long could not get used to the vSphere Web Client? Let's leave in the past these “rakes” and we will not expect that VVols will have to be mastered in a “voluntary-compulsory” mode. The sooner you start exploring the new product, the more confident you will feel when others have just begun their first tentative steps in this direction. And acting as an expert is an honor and a pleasure, because it's great when the knowledge that you gave them came in handy to the people.
Reason number 3. Disk space is free again!
Remember, in vSphere 5.0, when VMware implemented the automatic return of unused disk space by the UNMAP team, this led to errors, and as a result, we had to abandon the automation of this operation and do it manually until now, but now the automation is with us again - thanks to VVols. The storage array, having a complete understanding of the removal or movement of a virtual machine, can immediately return to a more unused space. You no longer need to manually run esxcli - everything happens automatically with VVols. If you need to return a place with an even higher level of granularity, then you can still run the UNMAP command on the guest OS. This approach will improve the efficiency of the storage array.
Reason number 4. Availability in all vSphere editions
If your storage array supports VVols, there is no need to switch to another vSphere edition — all editions work with VVols. Setting up VVols is easy, so this should not be a deterrent, just the opposite.
Reason number 5. Facilitates the move to Storage Policy Based Management
Keep up with VSAN users who are already using Storage Policy Based Management. This approach to infrastructure management allows you to customize storage management policies in accordance with the functionality of the storage array — so that the use of the resources and capabilities of your storage becomes oriented directly to virtual machines. Policy-based management allows you to assign resources exactly according to the needs of the virtual machine, as well as monitor compliance with these assignments. VMware has spent a lot of manpower and resources to create this control mechanism - and all in order to ensure maximum efficiency and flexibility in allocating storage resources for virtual machines.
Reason number 6. Optimal use of storage array features
The storage array is, in fact, a mechanism for performing read / write operations, as well as software designed to work with this mechanism. Together they are a powerful tool for working with data. Using VMFS and vSphere storage systems assumes that there is still some kind of “middleman” that tells the actual storage array what to do and when. Of course, such a chain is not the most effective method of work. Having got rid of such a “middleman” and having given the possibility of self-control to the storage array, we obtained the system with the greatest efficiency and optimal result. Note also that the capabilities of the storage array are much broader than comparable vSphere storage systems, plus the fact that the array is much more transparent with respect to storage resources than vSphere. Naturally, such things as dynamic resource allocation (thin provisioning), snapshots and QoS itself in the implementation using storage arrays are much more efficient.
Reason number 7. VVols management does not require special skills.
In order to work with VVols, there is no need to retrain as a storage administrator. The average IT administrator can do the administration tasks for VVols, and if you are a VMware administrator, then you don’t even need to open the storage management console once again, since the integration of SPBM and VVols with vCenter provides you with a single management tool (you can control policies and virtual volumes from VMware interface).
Reason number 8. One architecture for all
Files or blocks? NFS, iSCSI or Fiber Channel? Now it is completely indifferent, for VVols embody a single software repository architecture for all storage protocols and implement, so to speak, a single “level of communication with vSphere”. If you use VVols, you no longer care what was there - VMFS and blocks or NFS and files, now you just have VVols and a number of universal components used with any storage protocol. Of course, each protocol has its own characteristics, but VVols allows “combing one size fits all”, because it uses not unique, but identical properties of all protocols.
Reason number 9. Storage Unit - Virtual Machine
And for dessert, the most, perhaps, “tasty” reason: now the storage arrays can work with each individual virtual machine. Using VMFS, “transparency” spreads to the LUN level, and not one level below — because of this, we had no idea what machines were on a particular VMFS volume. With the introduction of VVols, the paradigm is changing: the virtual machine has now become the storage unit. For example, if we want to do an array snapshot for one machine, this is quite feasible (whereas with VMFS we had to do snapshots for the whole LUN). If you need to assign QoS policies to specific Tier-1 virtual machines, this can also be done, since this functionality now works at the virtual machine level. Thus, we are moving away from the concept of VMFS, which was not efficient enough in terms of the use of storage arrays. Now we can allocate resources for storage as needed, without having to reserve huge spaces for VMFS. This was the main idea that VMware embodied in Virtual Volumes.
Of course, each will decide on the use of Virtual Volumes, based on their own understanding of the situation. (Still, remember that the moment will come, and they will no longer say “if you switch to VVols,” but “when you switch to VVols.”) Without a doubt, the new approach has significant advantages — in particular, this is the most efficient allocation of resources. for virtual machines - but before making a decision, you should carefully analyze how the implementation of VVols is consistent with the current work of your infrastructure and the prospects for its development. Since the transition to the new architecture can be done gradually, as already mentioned, using Virtual Volumes along with NFS or VMFS (I mean “there is an elephant in parts”), I can only welcome it.
Additional Information:
- VMware Virtual Volumes Review (in Russian): http://www.vmware.com/en/products/vsphere/features/virtual-volumes.html
- VMware Storage Policy-Based Management Review (in Russian): http://www.vmware.com/en/products/vsphere/features/storage-policy-based-management.html
- Release Notes for Veeam Backup & Replication 8.0 Update 2 (in English): http://www.veeam.com/kb2024
Source: https://habr.com/ru/post/257259/
All Articles