Active Directory Domain Services has been one of those applications that, to the naked eye, seemed like it was a no brainer to virtualize. Why not? In most environments it’s a fairly low utilization workload, rarely capable of efficiently using the resources found in many of the enterprise-class servers that have been available for the past few years. Many organizations have adopted this way of thinking and have successfully virtualized all of their domain controllers. What about the hold-outs? What is it about Active Directory that has left so many AD administrators and architects keeping their infrastructure, or at least a portion of it on physical servers?

Until recently, a couple of limitations, some argued, diminished the advantages of virtualization. These limitations included support for cloning domain controllers and the inability to use features such as snapshots due to the risk of roll-back.

With the release of Windows Server 2012, Microsoft has validated the role virtualization plays in the data center by adding functionality that effectively lifts these limitations. The feature known as VM-Generation ID allows hypervisor vendors to expose a virtual machine identifier that Windows Server 2012 domain controllers can use to detect the state of a virtual machine and trigger new Active Directory safeguards. These safeguards protect the Active Directory from the dreaded USN roll-back if a virtual machine is reverted to a snapshot or rolled back by other mechanisms.

Besides protecting Active Directory from unintentional roll-back, these new safeguards and VM-Generation ID allow administrators to safely clone Windows Server 2012 domain controllers. When properly prepared, a Windows Server 2012 domain controller may be used as a source for new domain controllers. Not only does this eliminate the additional tasks of preparing a base virtual machine for becoming a domain controller, it reduces the time required for replication of a new copy of the Active Directory database.

VM-Generation ID functionality requires the hypervisor vendor to create the virtual machine identifier and expose it to the guest. VMware has provided this functionality in the following releases of vSphere:

• VMware vSphere 5.0 Update 2 (vCenter Server and ESXi must both be at 5.0 Update 2)
• VMware vSphere 5.1 (ESXi must be at least 5.0 Update 2)

More information on VM-Generation ID, supported methods for cloning domain controllers, and domain controller safeguards can be found at the following TechNet links:

Introduction to Active Directory Domain Services Virtualization (Level 100): http://technet.microsoft.com/en-us/library/hh831734.aspx

Virtualized Domain Controller Technical Reference (Level 300): http://technet.microsoft.com/en-us/library/jj574214.aspx

-alex

When we architect SAP on VMware deployments an important topic is how we design for high availability. We have options in the VMware environment from VMware HA, VMware FT and use of in-guest clustering software like Microsoft Cluster Services or Linux-HA. So can we determine a numerical availability for our design expressed as a fraction/percentage  (same metric used to define uptime Service Level Agreements like 99.9% )? Yes, there are ways to estimate this value and one method is explained in the following paper http://www.availabilitydigest.com/public_articles/0712/sap_vmware.pdf . This paper develops an equation to estimate the availability of SAP running on an ESXi cluster expressed as a fraction/percentage. The concepts are taken from other papers at http://www.availabilitydigest.com (a digest of topics on high availability)  and are based on mathematical algebra and probability theory that have been previously used in the IT industry for availability calculations. The availability metric (e.g. 99.9% or 0.999) is essentially a probability hence we use mathematical probability techniques to calculate the overall availability of a system.

The final general equation calculates the availability of an “n” node ESXi cluster sized with “s” number of spares i.e. an “n+s” cluster. It also factors in the software failover times of the single-points-of-failure (SPOF) in the SAP application architecture (database and Central Services). The failover time refers to the time taken for the SPOF to failover and restart on another ESXi host or other virtual machine in the event of an ESXi host failure – this period is important as it corresponds to downtime for the SAP system. The final equation gets a bit heavy on the algebra, but that’s because it models a generic use case. Once you replace the variables with practical “real-world” values, the equation gets easier and that’s when the algebra stops and spread sheeting takes over.

Let’s look at the following example with the following assumptions:

• A five node ESXi cluster running SAP virtual machines, sized with one spare ESXi host i.e. it’s an “n+1” cluster – in the event of one ESXi host failure all impacted virtual machines failover to the remaining four ESXi hosts and all virtual machines continue to run with no loss of performance (the whitepaper covers this example in more detail).
• A loss of two simultaneous ESXi hosts may result in serious performance degradation which we will classify conservatively as downtime for the whole cluster (not really true, but we have to start somewhere, see the whitepaper for caveats).
• The probability of a failover fault is zero i.e. if a VMware HA or in-guest cluster switch over event occurs, the impacted SAP SPOF fails over to remaining ESXi hosts or another virtual machine with no chance of error.
• The availability of a single ESXi host is in the ball park of 0.999 (i.e. “three nines”) – this simplifies the algebra in the general equation (see whitepaper section 4.3.1).

If we apply the above into the general equation from the whitepaper we get the following “simpler equation” specific to this use case.

We can use this equation along with practical values to replace the variables in order to observe how availability is impacted in different scenarios. The variables can be substituted with values obtained from: field experience; data/statistics gathered from actual implementations; reliability specifications from x-86 server vendors; proof-of-concepts / lab work evaluating failover times. The following example scenarios can then be analyzed:

• How does failover time impact the final availability?
• VMware HA adds some extra time for the OS to reboot compared to an active-passive clustering solution, how does this impact availability? VMware HA and clustering solution will have different values for mean time to failover.

At this point we can build a spreadsheet to analyze different scenarios.

It should be noted that this analysis is only considering unplanned downtime due to ESXi host/hardware failure. Other parts of the infrastructure would impact the final availability as experienced by the end-user such as network and storage (see section 3 of the whitepaper). It also does not consider downtime due to software corruptions or bugs or operational mistakes due to human error. Finally, while the formula discussed here is SAP specific the mathematical model can be applied to and adjusted for any ESXi cluster running business applications.

Partners in the above table are certified to meet learning and experience requirements virtualizing business critical apps. Working with these partners enables customers to get the best service possible from an expert in virtualization. Click here to more about VMware Consulting Services.

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]

Where to Start with BCA Design? Base the sizing of your virtual environment on physical servers. It’s critical to understand your application requirements and have a good sense of the capacity and storage you’ll need.

• VMware Capacity Planner – Helps you to gain insight into IT resource utilization and develop a virtualization roadmap for server containment and consolidation.
• VMware vCenter Application Discovery Manager – Allows you to quickly and accurately map your application dependencies so you can accelerate datacenter moves.
• Microsoft has Exchange and SQL tools for performing the migration. When you begin the migration, use VMware’s vStorage APIs for Array Integration to save time while moving, starting or creating VMs by eliminating redundant data flow. With Storage APIs, vSphere can perform faster while consuming less CPU, memory, and storage bandwidth.

For reference architectures, please see:

• vBlock
• Flexpod

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]

Learn more: Virtualizing Business Critical Applications Whitepaper [39-page PDF]