Shared VHDX in Windows Server 2012 R2
In a previous post on Windows Server 2012 R2 , I mentioned a new feature in Hyper-V — the use of shared VHDX files (Shared VHDX) to create guest clusters. Today I would like to dwell on this topic and discuss the features of setting up and applying Shared VHDX.
First of all, briefly about why guest clustering is needed at all. Most of the applications and services used in modern IT infrastructure can be run inside virtual machines (VMs). Virtualization gives a number of obvious and not very advantages, the listing of which goes beyond the post. The more critical an application for a company is spinning inside a VM, the more important the task of ensuring high availability of such a VM becomes.
You can provide high availability of VMs by placing it on a physical (host) cluster, in this context - Hyper-V cluster. Failure of the physical node of the cluster on which the VM was running results in automatic recovery of the VM on another node of the cluster. This failover procedure can lead to a short-term, but loss of communication with the VM and the application inside it.
')
Another method of increasing accessibility is to combine two or more VMs in a failover cluster, that is, creating a guest cluster in the sense that the cluster is created based on the guest OS. In this case, we are already talking about high availability not of the VM as such, but of the application (or applications) within the guest cluster.
Of course, for greater reliability, you can combine host and guest clustering.
Guest clustering, as well as host clustering, assumes the presence of some common storage. With regard to virtual machines, such storage before the release of Windows Server 2012 could be iSCSI-storage.
In Windows Server 2012, thanks to Virtual Fiber Channel, it became possible to connect VMs via the host HBA adapter directly to FC storage.
However, in any case, in order to build a guest cluster, it was necessary to provide the VM with direct access to the storage. In many scenarios, for example for hosting providers, this option is very inconvenient. General VHDX files just allow you to solve this problem, because they abstract VMs from the features of the storage implementation. To create a guest cluster, the necessary number of Shared VHDX is connected to the virtual machines, which represent the shared cluster storage. And where physically, in what specific storage and LUN-e these files are located - this is the provider's business.
From the point of view of the implementation of the described approach, we can distinguish two main configurations of using Shared VHDX. In the first configuration, the common VHDX files are located on the CSV volume of the physical cluster. The CSV volume, in turn, can be implemented on any block storage supported by the Windows Server Clustering service (Fiber Channel, iSCSI, Shared SAS).
In the second configuration, the VHDX files are located in the shared folder of the Scale-Out File Server file cluster. The latter, I note, also suggests the presence of a CSV-volume. As you can see, both configurations ultimately lead to a combination of host and guest clustering. Host clustering increases the availability of shared VHDX, then created on top of the guest cluster provides high availability of services and applications within the VM.
To configure Shared VHDX, first of all, of course, you need to create one or more VHDX files and arrange them using one of the above configurations. You can then connect the Shared VHDX in the Hyper-V console, using PowerShell cmdlets or using the service template in the System Center 2012 R2 Virtual Machine Manager.
In the Hyper-V console, this is done by adding a new SCSI disk: select the SCSI Controller in the VM properties, then Hard Drive , click the Add button, specify the path to the VHDX file, then select Advanced Features and check the corresponding checkbox.
Repeat the procedure for all VMs that are planned to be clustered.
You can do the same in PowerShell with the following cmdlets:
In VMM 2012 R2, in the service template, in the Hardware Configuration section, you must also add a SCSI disk, specify the path to the VHDX file, and check the Share the disk across the service tier checkbox. When deploying a VM based on such a template, VMM will attach the specified file as Shared VHDX.
Whichever option you choose, inside a VM the connected VHDX will look like a regular SAS disk.
It is necessary to remember the following requirements for Shared VHDX:
To diagnose possible problems in Performance Monitor, a new Hyper-V Shared VHDX object has been added with a set of various counters that you can analyze on Hyper-V hosts.
In addition, new logs have been added, which can be viewed, as usual, using the Event Viewer,
or PowerShell:
Finally, for the purposes of testing, studying, developing, it is possible to use the “special” configuration of Shared VHDX. For this configuration, a single physical host with Windows Server 2012 R2 and the raised Hyper-V role is enough, on which you can place common VHDX files without creating clusters with CSV volumes, etc. To implement this option, you need:
But remember that this is an unsupported configuration and should not be used in a real environment.
Thus, the shared VHDX file mechanism helps to implement a more efficient guest clustering scheme and, ultimately, increase the availability of critical applications and services of your infrastructure. This technology can be especially useful for private clouds and hosting scenarios.
Hope the material was helpful.
Thank!
Guest Clustering
First of all, briefly about why guest clustering is needed at all. Most of the applications and services used in modern IT infrastructure can be run inside virtual machines (VMs). Virtualization gives a number of obvious and not very advantages, the listing of which goes beyond the post. The more critical an application for a company is spinning inside a VM, the more important the task of ensuring high availability of such a VM becomes.
You can provide high availability of VMs by placing it on a physical (host) cluster, in this context - Hyper-V cluster. Failure of the physical node of the cluster on which the VM was running results in automatic recovery of the VM on another node of the cluster. This failover procedure can lead to a short-term, but loss of communication with the VM and the application inside it.
')
Another method of increasing accessibility is to combine two or more VMs in a failover cluster, that is, creating a guest cluster in the sense that the cluster is created based on the guest OS. In this case, we are already talking about high availability not of the VM as such, but of the application (or applications) within the guest cluster.
Of course, for greater reliability, you can combine host and guest clustering.
Guest clustering, as well as host clustering, assumes the presence of some common storage. With regard to virtual machines, such storage before the release of Windows Server 2012 could be iSCSI-storage.
In Windows Server 2012, thanks to Virtual Fiber Channel, it became possible to connect VMs via the host HBA adapter directly to FC storage.
However, in any case, in order to build a guest cluster, it was necessary to provide the VM with direct access to the storage. In many scenarios, for example for hosting providers, this option is very inconvenient. General VHDX files just allow you to solve this problem, because they abstract VMs from the features of the storage implementation. To create a guest cluster, the necessary number of Shared VHDX is connected to the virtual machines, which represent the shared cluster storage. And where physically, in what specific storage and LUN-e these files are located - this is the provider's business.
Supported configurations and configuration of Shared VHDX
From the point of view of the implementation of the described approach, we can distinguish two main configurations of using Shared VHDX. In the first configuration, the common VHDX files are located on the CSV volume of the physical cluster. The CSV volume, in turn, can be implemented on any block storage supported by the Windows Server Clustering service (Fiber Channel, iSCSI, Shared SAS).
In the second configuration, the VHDX files are located in the shared folder of the Scale-Out File Server file cluster. The latter, I note, also suggests the presence of a CSV-volume. As you can see, both configurations ultimately lead to a combination of host and guest clustering. Host clustering increases the availability of shared VHDX, then created on top of the guest cluster provides high availability of services and applications within the VM.
To configure Shared VHDX, first of all, of course, you need to create one or more VHDX files and arrange them using one of the above configurations. You can then connect the Shared VHDX in the Hyper-V console, using PowerShell cmdlets or using the service template in the System Center 2012 R2 Virtual Machine Manager.
In the Hyper-V console, this is done by adding a new SCSI disk: select the SCSI Controller in the VM properties, then Hard Drive , click the Add button, specify the path to the VHDX file, then select Advanced Features and check the corresponding checkbox.
Repeat the procedure for all VMs that are planned to be clustered.
You can do the same in PowerShell with the following cmdlets:
New-VHD -Path C:\ClusterStorage\Volume1\Shared.VHDX -Fixed -SizeBytes 30GB Add-VMHardDiskDrive -VMName Node1 -Path C:\ClusterStorage\Volume1\Shared.VHDX -ShareVirtualDisk Add-VMHardDiskDrive -VMName Node2 -Path C:\ClusterStorage\Volume1\Shared.VHDX –ShareVirtualDisk In VMM 2012 R2, in the service template, in the Hardware Configuration section, you must also add a SCSI disk, specify the path to the VHDX file, and check the Share the disk across the service tier checkbox. When deploying a VM based on such a template, VMM will attach the specified file as Shared VHDX.
Whichever option you choose, inside a VM the connected VHDX will look like a regular SAS disk.
Shared VHDX Requirements
It is necessary to remember the following requirements for Shared VHDX:
- The files must be VHDX, the VHD format for the shared configuration is not supported. At the same time, the guest OS itself may well be installed on a VHD disk.
- On Hyper-V hosts, and if using the Scale-Out File Server and on the nodes of the file cluster, a version of Windows Server 2012 R2 must be installed.
- Guest OS can be Windows Server 2012 R2 or Windows Server 2012 with the latest version of integration components.
- Both the first generation VM (Generation 1) and the second (Generation 2) are supported.
Diagnostics and Testing
To diagnose possible problems in Performance Monitor, a new Hyper-V Shared VHDX object has been added with a set of various counters that you can analyze on Hyper-V hosts.
In addition, new logs have been added, which can be viewed, as usual, using the Event Viewer,
or PowerShell:
Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/Operational Get-WinEvent -LogName Microsoft-Windows-Hyper-V-Shared-VHDX/Reservation Finally, for the purposes of testing, studying, developing, it is possible to use the “special” configuration of Shared VHDX. For this configuration, a single physical host with Windows Server 2012 R2 and the raised Hyper-V role is enough, on which you can place common VHDX files without creating clusters with CSV volumes, etc. To implement this option, you need:
- Install Failover Clustering Service
Install-WindowsFeature Failover-Clustering - Manually connect the Shared Virtual Disk filter for the partition where the shared VHDX files will be located, for example, for the D drive: it will look like
FLTMC.EXE attach svhdxflt D:
But remember that this is an unsupported configuration and should not be used in a real environment.
Thus, the shared VHDX file mechanism helps to implement a more efficient guest clustering scheme and, ultimately, increase the availability of critical applications and services of your infrastructure. This technology can be especially useful for private clouds and hosting scenarios.
Hope the material was helpful.
Thank!
Source: https://habr.com/ru/post/191666/
All Articles