VMware ESX Server as a foundation for HA and DR for the Microsoft ...

VMware ESX Server as afoundation for HA and DR for theMicrosoft Server PlatformRick MagoonSenior Solutions Architect, EMCMicrosoft Practice

IntroductionToo many data centers have unstable Microsoft environments becauseHigh Availability and redundancy was never architected prior to theirserver farm build-outMany companies are unaware of potential faults and lack of redundancywithin their own server environment until something happensHigh Availability and redundancy is never a one-size-fits-all solutionA major undertaking would be required to experience complete highavailability in a physical datacenter. A total automation of serverhardware, data availability and application availability would berequiredTiers must be established based on criticality of network service tosee any ROI

IntroductionA sample architecture for a highly reliable physical datacenter mayinclude the following components:Microsoft clustering for core applications like Exchange and SQLLoad balanced front-end servers like Outlook Web Access (OWA)and Sharepoint web serversSAN software to support snapshots and/or cloningSAN agents that integrate with Microsoft back-end servicesCluster aware agents that support database applications like SQLand ExchangeCold standby servers for all other applications that cannot be loadbalanced or clusteredStrict maintenance and patch management for all redundantservers to ensure successful automated failover

HA Layers: Virtual Infrastructure 3Encapsulates all guest operating systems with additional HA nototherwise obtainable in a non-virtualized datacenter.High SLAs, minimal downtime regardless of the network serviceVMotion provides guest OS level redundancy by moving running VMsbetween ESX hosts. It requires manual operation if not combined withVMware DRSVMware DRS (Distributed Resource Scheduler) will automaticallymigrate a running VM with VMotion if CPU and/or memory thresholdsare reachedVMware HA allows for automated failover in case of VMware ESX hostfailure. It provides N-to-N failover capabilities for a clusterSnapshots – Allow snapshot management for virtual machines that caneither be manually triggered or scripted. This allows for easy retrieval ofpreviously known good VM configurations

HA Layers: Application Level HASince VMware HA technologies does not have insight into the guest OS,the above problems will go unnoticed without the addition of Guest OSHA softwareVirtualCenter does not accommodate the following problems in aWindows guest operating system:Operating system failuresBad patchesBad driver upgradesViruses and spywareApplication faultsData corruption

HA Layers: Application Level HAIf additional application protection is required, there are built-in solutions in theEnterprise Edition of Windows and 3rd party vendors.All application HA solutions must meet the compatibility requirements ofWindows. Some popular solutions are:Clustering Technologies (Multiple nodes on shared disks):Microsoft Cluster ServicesVeritas Cluster ServerNSI GeoClusterEMC AutostartLoad Balancing (Front end network services):Windows NLBBigIPHost Based Replication(Hot standby):NeverFailEMC ReplistorApplicationOperating SystemHardwareSite AClustering / NLBReplicationApplicationOperating SystemHardware

DR LayersDR is your insurance for situationslike flood, fire, earthquake andcontaminated buildingsOccurs less than 1% of the timeTiers of services should be set toestablish lowest cost possible for asuite of DR solutionsConsistency between all VMs iskey to usable dataDR1%HA Unplanned13%DR solutions measured in RPOand RTOHA Planned86%

DR LayersDR solutions available on SAN,VM and WindowsOS/Application layersMultiple layers are requiredfor a complete DR solutionTo restore one or more VMsyou must use a technology thatutilizes the virtual layerTo restore application objectsor files you must use backupsoftware that recognizes theWindows guest OSVMware ConsolidatedBackup on a proxy server willmount virtual disks toseparate backup server

COOPContinuity of Operations allows for continuation of network services during thetime of disasterIt usually represents another datacenter that is triggered with a series of stepsfor manual failoverOnly critical services are typically replicated to lower overall costs associatedwith bandwidth and softwareBecause each guest OS is represented by a series of files on the SAN, entiresets of VMs can easily be replicated by technologies within the virtual layer orSAN replicationTraditional geographic clustering technologies can also be used within theWindows guest OS for a more automated failover

VMware HA LayersA – ESX Host FailureB – VM FailureC – Guest OS application failureD – VMFS3 or LUN CorruptionE – Clustered Application Failure

Summary of HA/DR/COOP OptionsESXRangerSnapshotsClonesNeverFailVCSDoubleTakeAutoStartReplistorVVRVCBApplicationOperating SystemHardwareMSCSNLBNeverFailVCSDoubleTakeAutoStartApplicationOperating SystemHardwareHA/DRSVmotionESXReplicatorApplicationOperating SystemHardwareApplicationOperating SystemHardwareSite AESXReplicatorSAN ReplicationSite B

Architectural Considerations: Virtual Disk LayoutVMFS3 VolumesKeep the size of your virtual disks to a minimum.• More fragmentation• Longer to backup / restore• Limited portability• You can always expand later.• Downtime required with native ESX commands• No downtime with products like Veritas VVM or MS Dynamic Disk)Keep the number of disks per LUN/RAID Group to a minimum. This will affectperformance and flexibility to perform SAN replicationPosition VMs so clustered and NLB nodes are on separate ESX hosts• DRS and HA should not affect positioning of clustered and NLB nodes• DRS has anti-affinity rules to prevent cluster and NLB nodes from running onthe same hostIf Microsoft Clustering will be used, architect your SAN storage with raw LUNsfor shared storage and use raw disk mappings (RDM)

Architectural Considerations: Virtual NetworkingAlways purchase the most Ethernet portsthat you can affordVI3 has a limit of 8 physical portsUse port groups if you have a limitedamount of ports or your server haslimited expandabilityIf limited expandability, consider 4-portIntel Pro/1000 adaptersTwo or more ports should be teamed orload balanced to provide redundancy forcritical virtual switchesAssign ports across separate physicaladapters if possible• Only if they’re the same typeof adapterService console only requires one portunless you are performing backups fromthe service consoleYou may wish to dedicate two ports ifservice console is considered criticalHaving a separate port for VMotion willguarantee the best performance

Architectural Considerations: Microsoft WindowsIf you are performing hot backups or snapshots, make sure theyare consistentVMware snapshots are not application awareInconsistent VMs will either not function or potentially destroy yourActive Directory environment• Domain controllers• Live Communications Server• Exchange Server• SQL Server and any connected database application serverMicrosoft clustering is a good choice for application-level HA but storagemust be configured to support clustering (RDMs)If snapshots or mirroring is used on the SAN, an application agent mustreside within Windows guest OS to maintain data consistency

Summary of HA and COOP OptionsTechnology Type Scope Applications Application AwareData consistancy(When running) Async/SyncHardware HA Broad All No No NAVMware HA HA Broad All No No NAVMware DRS HA Broad All No No NAVMware Vmotion HA Broad All No No NAVizioncore ESXRanger DR Broad All No No AsyncVizioncore ESXReplicator DR / COOP Broad All No No AsyncVMware Consolidated Backup DR Broad Depends Yes Yes AsyncMicrosoft Clustering HA Focused Cluster aware apps Yes Yes NAMicrosoft WinNLB HA Focused NLB compatible apps Yes Yes NAVeritas VCS HA / COOP Focused Compatible Apps Yes Yes NAVeritas VVR HA Focused Compatible Apps No Yes AsyncNSI Doubletake HA / COOP Focused Compatible Apps Yes Yes AsyncEMC Autostart HA / COOP Focused Compatible Apps Yes Yes AsyncEMC Replistor HA / COOP Focused Compatible Apps Yes/No Yes AsyncSAN based replication DR / COOP Broad All Yes/No Yes Async/SyncVMware snapshots DR Broad All No No NASAN snapshots DR Broad All Yes/No Yes NA

Architectural Considerations: Resource PoolsGroup VMs into resource pools thatrepresent AD servicesVMware DRS will allocate VMs toappropriate ESX host to meetresource group requirementsThis feature will optimize yourWindows AD environment by givingresources where it matters the mostAll critical VMs should belong toresource pools. Non-critical VMs willnot be guaranteed resources

Lessons LearnedHA, DR and COOP will protect you from unplanned events but preventingoperator errors can also help with unplanned downtime and potential corruptionLessons Learned:Never extend production VMFS volumesAlways zone your fabric• This is not necessary for the operation of ESX servers, but will be an issue ifWindows servers are SAN-attached to the same fabric• This is especially important when installing a Windows server connected tothe same fabric(s), because it polls all storage that it sees and will corruptanything it has access toNever attach a virtual disk file to another VM that’s not the original owner ofthat disk• VMware 3.0 uses series of flat files, delta files and snapshot disks tomaintain a full logical virtual disk. Any modification to the wrong disk willrender your virtual disk file set unusableRevert to snapshot function in VirtualCenter does not have a confirmationdialog box

Presentation DownloadPlease remember to complete yoursession evaluation formand return it to the room monitorsas you exit the sessionThe presentation for this session can be downloaded athttp://www.vmware.com/vmtn/vmworld/sessions/Enter the following to download (case-sensitive):Username: cbv_repPassword: cbvfor9v9r