Last week’s blog focused on storage design decisions when deploying XenDesktop 7.1 on Hyper-V 2012 R2. This week I will cover System Center 2012 R2 Virtual Machine Manager; why it’s needed for XenDesktop deployments on Hyper-V and some important design decisions to consider.
The title of this blog series is “XenDesktop 7.1 Planning on Hyper-V 2012 R2” but to be technically accurate it could be “XenDesktop 7.1 Planning on Hyper-V 2012 R2 and System Center 2012 R2 Virtual Machine Manager”. The reason why is because System Center Virtual Machine Manager (VMM) is required when deploying XenDesktop on Hyper-V. VMM is the key integration point between XenDesktop 7 and Hyper-V 2012 R2. XenDesktop communicates directly with VMM, which in turn creates, manages, and operates the virtual machines on Hyper-V.
There are four key components which make up the VMM role:
- VMM management server – Responsible for processing commands and controls communication with the VMM database, VMM library, and virtual machine hosts.
- VMM database – A Microsoft SQL 2008 R2 or higher database that stores the VMM configuration information such as virtual machine, service templates, and VMM profiles.
- VMM administrative console – The program that connects to the VMM management server to view and manage physical and virtual resources, such as virtual machine hosts, virtual machines, services, and library resources.
- VMM library – A catalog of resources used to deploy virtual machines and services. The templates used by XenDesktop to create virtual machines are stored here.
The VMM components must be in place before installing the XenDesktop components. The VMM components can be installed on physical or virtual servers, but to simplify management, I typically recommend virtual servers. For small environments, it’s possible to run all components on a single server, but for optimal performance I recommend separating the roles out across different servers. For example, run the VMM database on a separate SQL installation, and store the VMM library on a file server accessible by the XenDesktop controllers.
Some important considerations when deploying XenDesktop and VMM:
- Best performance was observed when the VMM management server is limited to managing up to 8000 virtual desktops. There is no limit placed on the number of virtual servers also managed by the VMM management server. This is because the status of virtual desktops tend to change constantly (powered on, powered off, rebooting, etc.) whereas servers tend to remain static.
- The VMM administrator console must be installed on each XenDesktop controller within the site, since any controller can manage communications and administer the site. If Provisioning Services will be used, the VMM administrator console must also be installed on the Provisioning Services servers so that the Setup Wizards function correctly.
- The VMM administrator console must be the same version everywhere it is installed. Therefore Windows Updates should not be set to automatic on the servers where the VMM administrator console is installed.
- Running multiple VMM administrator consoles at the same time adds overhead to the management system, therefore keep unnecessary administrative consoles closed.
- While it’s possible to run other applications on the VMM management server, it is not recommended, especially other System Center 2012 R2 applications because they tend to have heavy resource demands and could impact VMM performance.
As with other services supporting the XenDesktop environment, the VMM solution should be highly available. The failure of a VMM management server will not prevent users from connecting to their virtual desktops or applications, however, a VMM server failure will prevent the XenDesktop controllers from starting or provisioning new desktops. When designing a highly available VMM solution the following considerations should be taken into account:
- There can only be one implementation of a highly available VMM management server on a given failover cluster.
- The management server can be installed on as many as sixteen nodes in a failover cluster, but only one node can be active at a time.
- Use a highly available installation of SQL server. SQL Server 2012 supports AlwaysOn Failover Cluster Instances, AlwaysOn Availability Groups, Database Mirroring, and Log Shipping. Microsoft recommends AlwaysOn Availability Groups since Database Mirroring will be removed from a future release of SQL server. For more information, please refer to the Microsoft TechNet article – High Availability Solutions (SQL Server).
- If hosting the VMM database on a SQL server failover cluster, the cluster must be separate from the failover cluster on which the VMM management server is installed.
- Place the VMM Library on a highly available file server. A clustered group of file servers is recommended.
Next week I will finish out the blog series by covering some Hyper-V and VMM 2012 R2 optimizations and tips for improving performance.