Planning & Best Practice for Microsoft Virtualization
•Télécharger en tant que PPTX, PDF•
0 j'aime•662 vues
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.
![Objective and Takeaways ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Planning & Best Practice for Microsoft Virtualization
Similaire à Planning & Best Practice for Microsoft Virtualization (20)
Plus de Lai Yoong Seng
Plus de Lai Yoong Seng (20)
Dernier
Dernier (20)
Planning & Best Practice for Microsoft Virtualization
- 1. Planning & Best Practice for Microsoft Virtualization Lai YoongSeng MVP : Virtual Machine ericlaiys@hotmail.com | www.ms4u.info
- 6. SQL Server
- 10. Follow Microsoft Best Practice on Virtualization
- 11. Understand Hyper V Feature and Requirement
- 12. Understand Support Policy on Virtualizationor
- 14. Low MemoryUnsuitable candidate High processor High memory High network use External peripheral VM 4- 4 GB VM 1- 14 GB VM 3- 4 GB VM 2- 4 GB VS VM 1- 2 GB Parent partition (2 GB) Parent partition (2 GB) Physical Server (16 GB RAM) Physical Server (16 GB RAM)
- 15. Microsoft Assessment & Planning Toolkit (MAP) 5.5 Powerful inventory, assessment and reporting tool to assess IT environment. Latest enhancement for virtualization: Updated hardware library Data collection and store every 5 minute Significant usability enhancements
- 16. Planning for Hyper V Host Minimize risk to the parent partition Use server core Just Hyper V Roles Two physical network adapter at a minimum 1 for management 1 for VM 1 for iSCSI 1 for Live Migration Processor Microsoft Support – 8 virtual processor per physical processor core.8 : 1 ratio Memory Allocate 2 GB RAM for parent partition. VM 4- 4 GB VM 3- 4 GB VM 2- 4 GB VM 1- 2 GB Parent partition (2 GB) Physical Server (16 GB RAM)
- 17. Best Practice for Hyper V Host Avoid Overloading the Server No other roles install Ensure 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 – RVI Intel - EPT
- 18. Best Practice for Virtual Machine Processor Virtual 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. Network Install with Integration Component “Enlightenments” Use Synthetic network card
- 20. Fixed Disk or Pass Through Disk
- 23. Database has high I/O on Storage
- 24. Recommended to use Fixed Disk or Pass Through Disk.
- 25. RAID level – Operating system – RAID 1,Log File – RAID 1,Database – RAID 5.
- 26. OS – Fixed Disk, Log and Database use pass through disk
- 27. Processor
- 30. Exchange 2007 with SP 1 and Exchange 2010
- 31. Guest VM must be Windows Server 2008 SP2 or R2
- 32. Exchange 2003 (with SP 2 and later) supported in Virtual Server 2005 R2 and SP1.
- 33. Exchange Mailbox (not in 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. Not Supported
- 36. Not supported to run in clustered cluster configuration – Exchange DAG and Exchange 2007 SP1 using CCR.
- 39. Should configured up to 4 virtual processor
- 40. Virtual Memory
- 41. 1GB allocated for each virtual processor.
- 42. That’s mean 4vcpu = 4 GB of RAM
- 43. Ratio
- 44. 1 Hub Transport for every 5 Mailbox server.
- 46. Should be allocated to 4 virtual processor
- 47. Virtual Memory
- 48. For each processor, should be allocated 2GB of RAM
- 49. That’s mean 4 vCPU = 8 GB of RAM
- 50. Ratio
- 51. Recommended ratio 3 CAS VM for every 4 Mailbox server VM
- 53. Maximum 4vCPU
- 54. Virtual Memory
- 55. 2GB per processor Core
- 56. Example:- 4vcpu, then (2 X 4)= 8 GB of RAM
- 57. Ratio
- 60. Virtual Memory
- 61. 4GB + 3-30MB per mailbox.
- 62. Example:- 500 Mailbox with 30MB per mailbox = 14.6 GB
- 63. 14.6 + 4GB
- 64. 18.6 GBGuidelines – Mailbox Roles
- 65. Best Practice for SharePoint Processor Ratio of 1:1of virtual to logical processor Reserved : 2 cores for the parent partition For Example: 2 Processor with 6 cores each. 2 X 6 cores = 12 cores 12 cores – 2 cores (parent partition) = 10 cores 10 cores = 10 virtual processor. Storage Fixed disk or pass through disk SCSI disk more efficient than IDE. Recommended SAS.
- 66. Best Practice for SharePoint Network Install Integration Services Don’t use Emulation Device . Use IPv4 on guest VM. Disable IPv6. Memory Provide Adequate Memory Don’t use a lot of paging. Memory is faster than Disk Understand NUMA. Resource utilization can vary Disable Time synchronization integration services
- 67. Understand NUMA Stand for Non-Uniform Memory Access Boundaries. Exist at the hardware level Problem in today environment: Virtual guest that are allocated more memory within a single NUMA memory boundary. NUMA boundary vary by processor and motherboard vendor NUMA Boundary = Total amount of memory / Total number of cores Example:- Two Quad Core processor with 48GB of RAM 2 X 4core = 8 cores NUMA Boundary = 48 GB of RAM / 8 cores NUMA Boundary = 6 GB Allocating more than 6GB for a single guest VM would result in performance drop.
- 70. Especially on Dynamic Compression and Optimization
- 71. Storage
- 73. Make no difference if running on pass through disk but good for STSADM backup, IIS Logging, Usage Processing and Diagnostic.
- 74. Redundancy
- 76. High processing
- 79. Are I/O intensive and memory intensive.
- 80. Use pass through disk
- 81. Should separate Index & Query Server to avoid I/O Contention. Or put Query and Index Content on separate disk
- 82. Network
- 84. Redundancy
- 86. Not memory and I/O intensive
- 88. High Intensive
- 90. Provide as much RAM and CPU as possible
- 91. Redundancy
- 92. Distribute across two or more physical host
- 93. Recommendation
- 95. Use the recommended best practice for Hyper V Virtual Machine SQL Server Active Directory Exchange Server Sharepoint
- 96. Resources Lai’s Blog www.ms4u.info Support Policy on Microsoft Application SharePoint- http://technet.microsoft.com/en-my/library/ff621103(en-us).aspx Exchange http://technet.microsoft.com/en-my/library/cc794548(en-us,EXCHG.80).aspx Active Directory http://support.microsoft.com/kb/888794 SQL Server http://support.microsoft.com/kb/956893 Guest operating system support http://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx
Notes de l'éditeur
- Plan for future and the current utilization
- 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.
- 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.
- 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.
- http://technet.microsoft.com/en-my/library/cc794548(en-us,EXCHG.80).aspx
- 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.