Downloaded 22 times
Uploaded byLai Yoong Seng
Planning & Best Practice for Microsoft Virtualization
This document provides best practices for planning and configuring Microsoft virtualization. It discusses guidelines for Hyper-V hosts, virtual machines, SQL Server, Active Directory, Exchange Server, and SharePoint. It recommends using tools like MAP for assessment and following Microsoft's support policies. Key guidelines include processor and memory allocation, storage configuration, network optimization, and redundancy. The document aims to help users understand and apply Microsoft's virtualization best practices.
More Related Content
Similar to Planning & Best Practice for Microsoft Virtualization
More from Lai Yoong Seng
Planning & Best Practice for Microsoft Virtualization
- 1. Planning & BestPractice for Microsoft VirtualizationLai YoongSengMVP : Virtual Machineericlaiys@hotmail.com | www.ms4u.info
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. SharePointArgumentRunning server roleseither as Virtual machine or a Physical machine ?Rules of Thumb:-It’s Depend !Use MAP
- 10. Follow Microsoft BestPractice on Virtualization
- 11. Understand Hyper VFeature and Requirement
- 12. Understand Support Policyon Virtualizationor
- 13. Virtualize or NotVirtualize?Suitable candidateLow processor
- 14. Low MemoryUnsuitable candidateHighprocessorHigh memoryHigh network useExternal peripheralVM 4- 4 GBVM 1- 14 GBVM 3- 4 GBVM 2- 4 GBVSVM 1- 2 GBParent partition (2 GB)Parent partition (2 GB)Physical Server (16 GB RAM)Physical Server (16 GB RAM)
- 15. Microsoft Assessment &Planning Toolkit (MAP) 5.5Powerful inventory, assessment and reporting tool to assess IT environment.Latest enhancement for virtualization:Updated hardware libraryData collection and store every 5 minuteSignificant usability enhancements
- 16. Planning for HyperV HostMinimize risk to the parent partitionUse server coreJust Hyper V RolesTwo physical network adapter at a minimum1 for management1 for VM1 for iSCSI1 for Live MigrationProcessorMicrosoft Support – 8 virtual processor per physical processor core.8 : 1 ratioMemoryAllocate 2 GB RAM for parent partition.VM 4- 4 GBVM 3- 4 GBVM 2- 4 GBVM 1- 2 GBParent partition (2 GB)Physical Server (16 GB RAM)
- 17. Best Practice forHyper V HostAvoid Overloading the Server No other roles installEnsure High Speed Access to Storage Avoid Mixing Virtual Machines that can and cannot use Integration Services Configure Anti-Virus to Bypass Hyper-V Processes and Directories Use Processor that has SLAT (Second Level Address Translation)AMD – RVIIntel - EPT
- 18. Best Practice forVirtual MachineProcessorVirtual CPU consideration ( 4 , 2 or 1 vCPU)For example, given a dual core physical server, you are limited to configuring two virtual processors for a VM. Performance will be degraded if assign more.NetworkInstall with Integration Component “Enlightenments”Use Synthetic network card
- 19. Comparison of VirtualHard DiskStorage
- 20. Fixed Disk orPass Through Disk
- 21. Virtual SCSI thanIDEDifferent Types of Disk
- 22. Best Practice forSQL ServerSupportedSQL Server 2005, SQL Server 2008, and SQL Server 2008 R2Virtualization Snapshot not supported High AvailabilityGuest Failover Clustering is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 if the install operating system is running Windows Server 2008 or higher. Storage
- 23. Database has highI/O on Storage
- 24. Recommended to useFixed Disk or Pass Through Disk.
- 25. RAID level –Operating system – RAID 1,Log File – RAID 1,Database – RAID 5.
- 26. OS – FixedDisk, Log and Database use pass through disk
- 27.
- 28. Use SLAT processor– reduce processor overhead for VM memory mapping to physical memory.Best Practice for Active DirectoryBackup system state regularly. By default tombstone is 60 or 180 daysDo not pause DC for a long period.Avoid single point of failure. Deploy multiple DC on multiple host.
- 29. Best Practice forExchange ServerSupported
- 30. Exchange 2007 withSP 1 and Exchange 2010
- 31. Guest VM mustbe Windows Server 2008 SP2 or R2
- 32. Exchange 2003 (withSP 2 and later) supported in Virtual Server 2005 R2 and SP1.
- 33. Exchange Mailbox (notin DAG) – can be placed on a clustered Hyper V and moved using Live Migration
- 34. Other roles –Client Access Server, Hub Transport -> supported but with consideration.
- 35.
- 36. Not supported torun in clustered cluster configuration – Exchange DAG and Exchange 2007 SP1 using CCR.
- 37. Unified Messaging runningin Virtual machine. Best Practice for Exchange ServerProcessorRatio is 2:1. Two virtual processor for each coreReserved 2 cores for parent partition. For Example: 2 X 6 cores processor = 12 cores.12 cores – 2 cores (for parent partition ) = 10 cores10 cores X 2 = 20 virtual processor available for allocation.If every vm is allocated 4 vcpu, then you can create 5 Virtual machine. StorageSupported disk – Fixed Disk & Pass through disk. Virtual SCSI (pass through/fixed disk)
- 38. Guidelines – Edgeand Hub TransportVirtual Processor
- 39. Should configured upto 4 virtual processor
- 40.
- 41. 1GB allocated foreach virtual processor.
- 42. That’s mean 4vcpu= 4 GB of RAM
- 43.
- 44. 1 Hub Transportfor every 5 Mailbox server.
- 45. 1 Hub VM:5 MBX VMGuidelines – Client Access Server (CAS)Virtual Processor
- 46. Should be allocatedto 4 virtual processor
- 47.
- 48. For each processor,should be allocated 2GB of RAM
- 49. That’s mean 4vCPU = 8 GB of RAM
- 50.
- 51. Recommended ratio 3CAS VM for every 4 Mailbox server VM
- 52. 3 CAS VM:4 Mailbox VMGuidelines – Client Access Server /HubVirtual Processor
- 53.
- 54.
- 55.
- 56. Example:- 4vcpu, then(2 X 4)= 8 GB of RAM
- 57.
- 58. 1 CAS/Hub VM: 1 MBX VMVirtual Processor
- 59.
- 60.
- 61. 4GB + 3-30MBper mailbox.
- 62. Example:- 500 Mailboxwith 30MB per mailbox = 14.6 GB
- 63.
- 64. 18.6 GBGuidelines –Mailbox Roles
- 65. Best Practice forSharePointProcessorRatio of 1:1of virtual to logical processorReserved : 2 cores for the parent partitionFor Example: 2 Processor with 6 cores each.2 X 6 cores = 12 cores12 cores – 2 cores (parent partition) = 10 cores10 cores = 10 virtual processor.StorageFixed disk or pass through diskSCSI disk more efficient than IDE. Recommended SAS.
- 66. Best Practice forSharePointNetworkInstall Integration ServicesDon’t use Emulation Device . Use IPv4 on guest VM. Disable IPv6.MemoryProvide Adequate MemoryDon’t use a lot of paging. Memory is faster than DiskUnderstand NUMA.Resource utilization can varyDisable Time synchronization integration services
- 67. Understand NUMAStand forNon-Uniform Memory Access Boundaries.Exist at the hardware levelProblem in today environment:Virtual guest that are allocated more memory within a single NUMA memory boundary.NUMA boundary vary by processor and motherboard vendorNUMA Boundary = Total amount of memory / Total number of coresExample:-Two Quad Core processor with 48GB of RAM2 X 4core = 8 coresNUMA Boundary = 48 GB of RAM / 8 coresNUMA Boundary = 6 GBAllocating more than 6GB for a single guest VM would result in performance drop.
- 68. Guidelines- Web ServerRole in SharePointMemory
- 69.
- 70. Especially on DynamicCompression and Optimization
- 71.
- 72.
- 73. Make no differenceif running on pass through disk but good for STSADM backup, IIS Logging, Usage Processing and Diagnostic.
- 74.
- 75. Distribute two ormore hostsGuidelines-Query & Index Server in SharePointProcessor
- 76.
- 77.
- 78.
- 79. Are I/O intensiveand memory intensive.
- 80. Use pass throughdisk
- 81. Should separate Index& Query Server to avoid I/O Contention. Or put Query and Index Content on separate disk
- 82.
- 83.
- 84.
- 85. Deploy on twoor more hostsGuidelines- Application Server in SharePointMemory and Storage
- 86. Not memory andI/O intensive
- 87. Use Fixed DiskGuidelines-Database Server in SharePointMemory, Processor, Storage, Network
- 88.
- 89.
- 90. Provide as muchRAM and CPU as possible
- 91.
- 92. Distribute across twoor more physical host
- 93.
- 94. Avoid Virtualization. Runin Physical ServerWhat We Covered?After watching this webcast, you should be able toPlanning on Virtualization
- 95. Use the recommendedbest practice for Hyper VVirtual MachineSQL ServerActive DirectoryExchange ServerSharepoint
- 96. ResourcesLai’s Blogwww.ms4u.infoSupport Policyon Microsoft ApplicationSharePoint- http://technet.microsoft.com/en-my/library/ff621103(en-us).aspxExchange http://technet.microsoft.com/en-my/library/cc794548(en-us,EXCHG.80).aspxActive Directory http://support.microsoft.com/kb/888794SQL Server http://support.microsoft.com/kb/956893Guest operating system supporthttp://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx
Editor's Notes
- #7 Plan for future and the current utilization
- #9 Best Practices for Configuring Virtual MachinesIn continuation to my first post on best practices, I'm back with some more.This post discusses best practices that should be considered when configuring virtual machines in Hyper-V. Virtual machine performance is not only impacted by how the physical server is configured but also by the selections made when configuring the virtual machine itself. Install Integration ServicesThe first, and probably the most important, best practice for virtual machines is to install the Integration Services (IS) that come with Hyper-V as soon as possible provided the operating system running in the virtual machine is supported (refer to the Integration Services section for information on supported Guests). Then, update the IS as needed.Uninstall VMAdditions and Compact VHDsWhen migrating virtual machines from Virtual PC or Virtual Server 2005 R2, uninstall the VMAdditions and compact the virtual hard disk before moving the disk to the Hyper-V server.Set Display for Best Performance For the best display in a virtual machine ensure the display interface is set for Best Performance. This will ensure the hardware acceleration is set to Full.Configure Fixed-Size VHDsChoose to configure fixed-size virtual hard disks as opposed to dynamically expanding. Performance is faster, the file system is less likely to fragment and managing space on the physical disk is easier. Always defragment a physical disk before creating a virtual hard disk.Use SCSI Virtual Adapters for Data DrivesHyper-V requires the virtual machine to boot from a virtual IDE Controller, however, SCSI virtual adapters can be used after that for mounting additional virtual hard disks. While performance differences between a virtual IDE and a virtual SCSI controller in Hyper-V is almost negligible (with Integration Services installed), the fact is more and larger capacity virtual hard disks can be attached to a virtual SCSI controller (4 controllers with 64 virtual disks each for a total of 256). So, if you need more than four virtual hard disks attached to a virtual machine, use a virtual SCSI controller.Allocate CPU Resources Based on Anticipated Usage It is also important to determine virtual machine performance to ensure CPU resource allocation on the physical server is adequate to support the workload inside the virtual machine.Consider Using Pass-Through Disks It is best practice to use virtual hard disks when creating virtual machine. However it is no always possible due to circumstances. Using pass-through disks the performance is slightly better versus using VHD's. It allows you leverage greater than 2TB. Very important, when using pass-through disks, virtual machine configuration files should be relocated to another hard disk or share. Here we loose the snapshot and portability of like in VHD's. Ensure File Share High Availability If a file share is being used to store virtual machine configuration data, it is best practice to ensure the file share is highly available.Configure Domain Controllers to Optimize Performance Domain Controllers are supported in Hyper-V when running in a virtual machine. The following best practices are recommended for these configurations: Never save state in a domain controller as this may cause synchronization issues in the domain. Never Pause a domain controller virtual machine for long periods of time as this may adversely impact replication. Always shutdown a domain controller. Do not take snapshots of a domain controller. Make a determination regarding time synchronization. The decision is either to use the Hyper-V Integration Service for Time Synchronization or not. If the decision is to treat the virtualized DCs like hardware based DCs, then disable the Time Synchronization capability in the Settings for each virtual machine and point the PDC Emulator to an external time source and allow all the other DCs to synchronize with the PDC Emulator. If the decision is to synchronize with the Parent partition, only enable the Time Synchronization capability for the DC holding the PDC Emulator FSMO Role.
- #12 http://support.microsoft.com/kb/956893Recommended to use Fixed Disk rather than Dynamic Disk. Due to fragmentation and latency introduce when writes to disk. Extreme storage performance – pass through disk. Based on testing, 5% better performance than fixed disk.
- #13 http://support.microsoft.com/kb/888794http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspxDo not pause, stop, or store the saved state of a domain controller in a virtual machine for time periods longer than the tombstone lifetime of the forest and then resume from the paused or saved state. Doing this can interfere with replication. To learn how to determine the tombstone lifetime for the forest, see Determine the Tombstone Lifetime for the Forest (http://go.microsoft.com/fwlink/?LinkId=137177). Do not copy or clone virtual hard disks (VHDs).Do not take or use a Snapshot of a virtual domain controller. Do not use a differencing disk VHD on a virtual machine that is configured as a domain controller. This makes reverting to a previous version too easy, and it also decreases performance. Do not use the Export feature on a virtual machine that is running a domain controller. Do not restore a domain controller or attempt to roll back the contents of an Active Directory database by any means other than using a supported backup. For more information, see Backup and Restore Considerations for Virtualized Domain Controllers. All these recommendations are made to help avoid the possibility of an update sequence number (USN) rollbackYou should perform P2V conversion using offline mode so that the directory data is consistent when the domain controller is turned back on. The offline mode option is offered and recommended in the Convert Physical Server WizardFor virtual machines that are configured as domain controllers, disable time synchronization with the host through Integration Services. Instead, accept the default Windows Time service (W32time) domain hierarchy time synchronization. Host time synchronization makes it possible for guest operating systems to synchronize their system clocks with the system clock of the host operating system. Because domain controllers have their own time synchronization mechanism, host time synchronization must be disabled on virtual machines that are configured as domain controllers. If domain controllers synchronize time from their own source and also synchronize time from the host, the domain controller time can change frequently. Because many domain controller tasks are tied to the system time, a jump in the system time could cause lingering objects to be left in the directory and replication to be stopped. You can disable host time synchronization in the virtual machine settings in the Integration Services section of the Hyper-V Manager by clearing the Time Synchronization check box. StorageTo optimize the performance of the domain controller virtual machine, use the following recommendations for storing operating system, Active Directory, and VHD files: Guest storage. Store the Active Directory database file (Ntds.dit), log files, and SYSVOL files on a separate virtual disk from the operating system files. Integration Components must be installed so that synthetic drivers can be used for Integrated Drive Electronics (IDE) instead of emulation. Virtual SCSI and IDE disks perform at the same speed when they use synthetic drivers.Host storage of VHD files. Recommendations: Host storage recommendations address storage of VHD files. For maximum performance, do not store VHD files on a disk that is used frequently by other services or applications, such as the system disk on which the host Windows operating system is installed. Store each VHD file on a separate partition from the host operating system and any other VHD files. The ideal configuration is to store each VHD file on a separate physical drive. Fixed VHD versus pass-through disks. There are many ways to configure storage for virtual machines. When VHD files are used, fixed-size VHDs are more efficient than dynamic VHDs because the memory for fixed-size VHDs is allocated when they are created. Pass-through disks, which virtual machines can use to access physical storage media, are even more optimized for performance. Pass-through disks are essentially physical disks or logical unit numbers (LUNs) that are attached to a virtual machine. Pass-through disks do not support the snapshot feature. Therefore, pass-through disks are the preferred hard disk configuration, because the use of snapshots with domain controllers is not recommended. To reduce the chance of corruption of Active Directory data, use SCSI controllers or disable write caching on ATA/IDE drives: Use SCSI physical drives (as opposed to IDE/ATA drives) on Hyper-V servers that host virtual domain controllers. If you cannot use SCSI drives, ensure that write caching is disabled on the ATA/IDE drives that host virtual domain controllers. For more information, see Event ID 1539 – Database Integrity (http://go.microsoft.com/fwlink/?LinkId=162419).Use virtual SCSI controllers for any virtual machine that runs as a domain controller. If you cannot use virtual SCSI controllers, ensure that write caching is disabled on the virtual IDE drives of virtual machines that run as domain controllers. You can see the type of disk controllers that are installed in the Virtual Machine Manager Settings dialog box. For more information, see Configuring Virtual Machines (http://goAvoid creating single points of failureYou should attempt to avoid creating potential single points of failure when you plan your virtual domain controller deployment. You can avoid introducing potential single points of failure by implementing system redundancy. For example, consider the following recommendations while keeping in mind the potential for increases in the cost of administration:Run at least two virtualized domain controllers per domain on different virtualization hosts, which reduces the risk of losing all domain controllers if a single virtualization host fails.As recommended for other technologies, diversify the hardware (using different CPUs, motherboards, network adapters, or other hardware) on which the domain controllers are running. Hardware diversification limits the damage that might be caused by a malfunction that is specific to a vendor configuration, a driver, or a single piece or type of hardware.If possible, domain controllers should be running on hardware that is located in different regions of the world. This helps to reduce the impact of a disaster or failure that affects a site at which the domain controllers are hosted.Maintain physical domain controllers in each of your domains. This mitigates the risk of a virtualization platform malfunction that affects all host systems that use that platform.
- #14 http://technet.microsoft.com/en-my/library/cc794548(en-us,EXCHG.80).aspx
- #20 http://technet.microsoft.com/en-my/library/ff621103(en-us).aspxhttp://blogs.msdn.com/b/uksharepoint/archive/2009/03/04/topic-1-recommendations-for-optimizing-the-performance-of-a-virtualized-sharepoint-environment.aspxa SharePoint Server virtual machine, do not configure the virtual machine to save state. Virtual machines that come up from saved state will be out of synchronization with the other servers in the farm. We recommend that you configure the virtual machine to use a shutdown because it provides the cleanest method to minimize virtual machine corruption. When a shutdown occurs any timer jobs that are running are allowed to finish and there will not be any synchronization issues when the VM restarts.Disable the time synchronization for each SharePoint Server virtual machine. SharePoint Server 2010 implements timer jobs extensively and the latency during time synchronization will cause unpredictable results in the SharePoint Server environment. As a best practice, we recommend that you do not use the snapshot feature on virtual machines in a production environment for the following reasons:Clock synchronization: When you take a snapshot of a running virtual machine, there is latency between the time the snapshot is started and the time the snapshot is finished. This latency affects SharePoint Server timer jobs and, as a result, time synchronization between farm servers.Performance: When you create a snapshot for a virtual machine you have, in effect, created a differencing disk. There is a continuous exchange of configuration data between the virtual machine and the snapshot, which affects performance.