Windows Server 2012 : Deploying and configuring Hyper-V hosts (part 3) - Planning Hyper-V deployment - Security, Disaster recovery

It’s important to consider the security of your Hyper-V hosts as you prepare your host deployment plan. To begin with, you should apply the same principles, processes, and practices for securing Hyper-V hosts that you would apply to any other Windows Server components within your environment. In addition to adhering to such best practices, you should also do the following:

Scalability is the ability of a system or technology to expand to meet business needs, and it is therefore an important consideration when planning the deployment of Hyper-V hosts.

Availability is another important consideration for deployment planning and is related to scalability. Availability is the degree to which a system or technology is perceived by clients to be available so that they can access it. Systems that are available are considered resilient for two reasons. First, they minimize the occurrence of service-affecting incidents that can interrupt access by clients. Second, they allow effective actions to be performed when a service-affecting incident does happen.

The Failover Clustering feature of Windows Server 2012 can provide both high availability and increased scalability for Hyper-V hosts and also the virtualized workloads that run on such hosts. A failover cluster is a group of servers that work together to increase the availability of applications and services running on those servers. The clustered servers, also called nodes, are connected by both physical cables and software such that if one of the cluster nodes fails, another node can begin providing service by using a process known as failover.

Failover Clustering has been enhanced in a number of ways in Windows Server 2012:

Besides improving availability, implementing Failover Clustering with Hyper-V hosts also provides mobility by allowing the migration of running virtual machines from one node to another in a host cluster. Live migration can help organizations create a dynamic and flexible IT environment that responds to changing business needs, so understanding and planning for virtual machine mobility is also an important aspect of host-deployment planning.

Live migration improvements in Windows Server 2012 include the following:

Preparing for the eventuality of a disaster to ensure business continuity is a critical component of any deployment plan. Essential to any disaster-recovery planning is the ability to create and restore from reliable backups. With Hyper-V, you have to consider backing up the following:

Performing backups of disk volumes on Windows servers makes use of the Volume Shadow Copy Service (VSS), which is a set of COM interfaces that implements a framework to enable volume backups to be performed while applications and services running on the server continue to write to the volumes being backed up. VSS provides an underlying framework that is used by the following Windows features and applications:

In addition, VSS is used by System Center Data Protection Manager (DPM), which enables disk-based and tape-based data protection and recovery for Windows servers, including Hyper-V hosts and the virtualized workloads running on such hosts. In addition, you also can use DPM to centrally manage system state and Bare Metal Recovery (BMR).

A new feature of VSS in Windows Server 2012 is VSS for SMB File Shares, which allows VSS-aware backup applications such as System Center DPM to create shadow copies of VSS-aware server applications that store their data on SMB 3.0 file shares, such as file shares on a Scale-Out File Server. On previous versions of Windows Server, VSS only supported creating shadow copies of data stored on local volumes. Because Windows Server 2012 Hyper-V hosts can now use SMB 3.0 shared storage for storing virtual machine files, VSS for SMB File Shares is needed to ensure that virtual machines running on hosts using SMB 3.0 shared storage can reliably back up such virtual machine files.

Windows Server Backup does not support VSS for SMB File Shares functionality, but the Diskshadow.exe command-line utility included in Windows Server 2012 that exposes the functionality offered by VSS does support it.

Whether you are using Windows Server Backup, System Center DPM, or a third-party backup product, the recommended approach for backing up Hyper-V hosts is to perform full backups from the host operating system itself. Such backups will include all virtual machine files, including virtual hard disks, snapshot files, and virtual machine configuration files. Virtual switches are not included in such backups, however, and after a host has been restored, you need to re-create the host’s virtual switches and reconnect the virtual network adapters in each virtual machine to the appropriate virtual switch. Because of this, you should make sure that you carefully document the configuration of all virtual switches on your Hyper-V hosts as part of your disaster-recovery plan.

The preceding approach to backing up Hyper-V hosts will not work, however, in scenarios where the host storage does not support the Hyper-V VSS writer. An example of this is when virtual machine files are being stored on a SMB 3.0 file share on a Scale-Out File Server. In such scenarios, you should augment the preceding approach by also running the backup program from within the guest operating system of each virtual machine.

A new feature of Hyper-V in Windows Server 2012 that can provide additional options for disaster-continuity scenarios is Hyper-V Replica, which can be used to replicate all changes on a virtual machine to a counterpart virtual machine running on a different host. For example, for an organization whose IT infrastructure has been implemented in a hub-and-spoke topology, where there is a single head office and multiple branch offices, Hyper-V Replica can be used to replicate virtual machines running on hosts deployed at headquarters to standby hosts deployed at each branch office. This way, if wide area network (WAN) connectivity is lost between a branch office and headquarters, the standby host at that branch office can take over the workload from the host at the head office.