Business continuity for virtualized workloads

No cloud solution would be workable without a viable disaster recovery solution. Virtualized workloads owned by business units in large enterprises or by customers of cloud hosting providers must be backed up regularly to prevent loss of continuity should a disaster occur on the provider’s infrastructure. This chapter ends with a look at Hyper-V Replica, a new
feature of Hyper-V in Windows Server 2012 that helps ensure that your cloud solutions can be recovered in the event of a disaster.

Hyper-V Replica

While many third-party backup solutions can be used for backing up and recovering VMs
running on Hyper-V hosts, the Hyper-V Replica feature in Windows Server 2012 provides an in-box business continuity solution for cloud environments that can efficiently, periodically, and asynchronously replicate VMs over IP-based networks, including slow WAN links and across different types of storage subsystems. The Hyper-V Replica feature does not require any shared storage or expensive storage array hardware, so it represents a low-cost solution for organizations looking to increase the availability of their virtualized workloads and ensure that these workloads can be recovered quickly in the event of a disaster.
Hyper-V, together with Failover Clustering, allows VMs to maintain service availability by moving them between nodes within the datacenter. By contrast, Hyper-V Replica allows VMs to maintain availability across a datacenter where the node hosting the replica is located at a
physically separate site. Hyper-V Replica provides host-based replication that allows for failover to a secondary datacenter in the event of a disaster. It’s an application-agnostic solution because it operates at a VM level regardless of what guest operating system or applications are installed in the VM. It’s a storage-agnostic solution because you can use any combination of SAN, direct attached storage (DAS), or SMB storage for storing your VMs. It also works in both clustered
and nonclustered environments, and you can even replicate from a host on a shared cluster to a remote, stand-alone replica host. And it works with Live Migration and Live Storage Migration.
Typical cases for using Hyper-V Replica might include:

■ Replicating VMs from head office to branch office or vice versa in large and mid-sized

business environments

■ Replication between two datacenters owned by a hosting provider to provide disaster recovery services for customers

■ Replication from the premises of small and mid-sized businesses to their hosting provider’s datacenter

Guidance on configuring the full life cycle of a replicated VM

’ve written this particular sidebar because our customers often have not done a deep enough planning for their replica scenario. Essentially, my goal is to remind them that replication one way is easy to set up and great. But once you have recovered a server on your destination, at some point, you may choose to replicate it back to the original location. It is much better to have both ends of replication enabled as replica servers.

When planning your Hyper-V Replica scenario, you should consider the configuration that properly supports the full life cycle of your replicated VM. Take into consideration that both endpoints of your replication relationship should be configured as replica servers. Your replicated VMs from your main office to your branch office is essentially a one-way configuration. If you plan on replicating VMs back to your main office, you need to ensure those Hyper-V servers are configured as replica servers as well.

Consider the step-by-step process you will need to test a replicated VM as part of a recovery effort. By testing a VM prior to failing it over, you can ensure you have chosen the appropriate recovery point. The replica server will first verify that the original VM is not available before allowing a failover copy to be brought online. Once you have recovered all your VMs, you will also need to consider the steps required to bring the services online. In complex environments, you will likely

need additional effort to coordinate the order in which you bring VMs and services online. There may be additional Domain Name System (DNS) or firewall changes required to fully return service availability.

Finally, after you have resolved the failure in the Primary datacenter that required you to bring replicated VMs online, you likely will want to replicate your VMs back to the Primary site. It makes sense to configure both endpoints of your replication to be enabled as a replica server as part of their deployment. For example, if your primary site was taken offline by blizzard-related power loss for several days, you may choose to bring online the VM’s on your replica server. When your Primary datacenter is back online, you would likely plan to replicate VMs back to it. Of course, you could enable servers as replicas fairly quickly, but proper planning will minimize disaster-related issues and mistakes, especially as you scale out your Hyper-V infrastructure.

Colin Robinson Program Manager, Enterprise Engineering Center (EEC)

Implementing Hyper-V Replica

Hyper-V Replica can be enabled, configured, and managed from either the GUI or by using Windows PowerShell. Let’s briefly look at how to enable replication of a VM by using Hyper-V Manager. Begin by selecting the Replication Configuration section in Hyper-V Settings on
the hosts that you plan on replicating VMs to or from. Select the Enable This Computer As A Replica Server check box to enable the host as a replica server and configure the authentication, authorization, and storage settings that control the replication process:

Once you’ve performed this step on both the primary and replica servers (the primary server hosts the virtualized production workloads, whereas the replica server hosts the replica VMs for the primary server), you then can enable replication on a per-VM basis. To do this, right-click a VM in Hyper-V Manager and select Enable Replication, as shown on the following page.

When the Enable Replication wizard launches, specify the name of the replica server that you want to replicate the selected production VM to:

Specify connection parameters that define the port and authentication method used for
performing replication:

Continue through the wizard until you reach the Choose Initial Replication Method page,
where you specify how and when the VM first will be copied over to the replica server:

Once you’ve completed the wizard and clicked Finish, replication will begin. You can view the replication process as it takes place by selecting the Replication tab in the bottom-central pane of Hyper-V Manager:

You also can use the Measure-VMReplication cmdlet in Windows PowerShell to view the success or failure of the replication process:

To view all the Windows PowerShell cmdlets for managing the Hyper-V Replica feature, use the Get-Command cmdlet, as shown here:

Guidance on configuring the Hyper-V Replica Broker cluster

resource

ustomers who have tested Hyper-V Replica in my Enterprise Engineering

Center (EEC) lab at Microsoft have often been confused by the following issue. Basically, they successfully install the Hyper-V Replica Broker to the cluster, but

they don’t find it obvious that they also have to configure the broker. This sidebar describes the necessary steps for that configuration.

After configuring your Hyper-V cluster as a Hyper-V Replica server, you will now have a new cluster resource displayed in your Failover Cluster Manager console. The next step is to configure this new cluster resource. If you look down near the bottom of the Failover Cluster Manager, you will see that your new cluster resource is listed and is Online.

Now we have to configure the Replication settings to be used by the cluster. Within Failover Cluster Manager, highlight the newly created broker, select Resources at the bottom, and choose Replication Settings. These settings will be configured once here, and all nodes of the cluster will share this replication configuration based on what you do here:

The options you configure for the broker (and, in turn, the whole cluster) are exactly like

setting up one server. First, select the Enable This Cluster as a Replica Server check box:

The same choices are available for the cluster, such as Authentication And Ports, as well

as Authorization And Storage. Make your desired configuration here and click OK.

You are now done with the Host configuration of settings for a Replica cluster.

Colin Robinson

Program Manager, Enterprise Engineering Center (EEC)

Learn more

For more information about Hyper-V Replica, see the article titled “Hyper-V Replica Feature
Overview” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh831716.aspx.
For more information about Hyper-V Replica scenarios, see the article titled “Maintaining Business Continuity of Virtualized Environments with Hyper-V Replica: Scenario Overview” in the TechNet Library at http://technet.microsoft.com/en-us/library/hh831783.aspx.
For a detailed look at how Hyper-V Replica works and how to implement it, see Hyper-V Replica Overview” in the TechNet Library, and the list of related resources at the end of the article, at http://technet.microsoft.com/en-us/library/jj134172.

Embedding security into your private cloud design plan

ne of the most common misconceptions seen in the industry today is to think that the private cloud obviates security concerns, and therefore, security isn’t

a critical design and planning consideration. There are many security challenges specific to cloud computing. These are based on cloud essential characteristics defined by the National Institute of Standards and Technology (NIST). According to the NIST definition of cloud computing, the core characteristics of a cloud areresource pooling, on-demanding self-service, rapid elasticity, broad network access,

and measured services.

In a private cloud environment, there are important security concerns related to each of these essential cloud characteristics, and you need to address those concerns during the design and planning phase. Otherwise, security won’t be embedded into the project from a foundational perspective. If you don’t integrate security into every aspect of your private cloud architecture, you’ll increase the chances that later on, you will find breaches that were not predicted due to the lack of due diligence planning.

Some cloud architects may think that these essential characteristics of cloud computing only apply to a public cloud infrastructure; this is not true. Large enterprises already have network segmentation and different levels of authentication and authorization according to organizational structure or business unit. When evolving from a physical datacenter to a private cloud, these core security design points need be in place: segmentation, isolation, and security across organizational and divisional boundaries.

During the private cloud design and planning phase, you need to be sure to address the following security concerns as they relate to the essential security characteristics of the private cloud.

Resource pooling

When the cloud characteristic under consideration is resource pooling, the security concern may be that the consumer (user/tenant) requires that the application is secure and that the data is safe even in catastrophic situations. Possible strategies for addressing these concerns can include:

■ Implementing data isolation between tenants

■ Applying Authentication, Authorization, and Access Control (AAA)

■ Using the Role Based Access Control (RBAC) model

On-demand self-service

When the cloud characteristic under consideration is on-demand self-service capabilities, the security concern may be control of who has the authority to demand, provision, use, and release services from and back to the shared resource pool. Possible strategies for addressing these concerns can include:

■ Implementing least privilege and RBAC

■ Implementing a well-documented cleanup process

■ Explicitly addressing how cleanup is accomplished in the SLA you have with

private-cloud tenants

Rapid elasticity

When the cloud characteristic under consideration is rapid elasticity, the security concern may be that rogue applications can execute a Denial of Service (DoS) attack that may destabilize the datacenter by requesting a large amount of resources. Possible strategies for addressing these concerns can include:

■ Monitoring resources to alert and prevent such scenarios

■ Implementing policy-based quotas

82 Chapter 2 Foundation for building your private cloud

Broad network access

When the cloud characteristic under consideration is broad network access, the security concern may be that users will have access to private cloud applications and data from anywhere, including unprotected devices. Possible strategies for addressing these concerns can include:

■ Implementing endpoint protection

■ As part of the defense in depth approach, making sure to have a security awareness training in place that covers this scenario

■ Applying AAA

It is the cloud architect’s responsibility to bring these concerns to the table during the planning and design phase of the project.

Note: for comprehensive coverage of Microsoft’s Private Cloud Security architecture, please see the article “A Solution for Private Cloud Security” on TechNet Wiki at http://social.technet.microsoft.com/wiki/contents/articles/
6642.a-solution-for-private-cloud-security.aspx.