Planning for Branch Offices or Remote Sites
Updated: October 21, 2008
Applies To: Virtual Machine Manager 2008, Virtual Machine Manager 2008 R2, Virtual Machine Manager 2008 R2 SP1
If your environment extends beyond a central data center to include branch offices or other remote sites where you want to create, run, and manage virtual machines, there are additional topology considerations for implementing System Center Virtual Machine Manager (VMM) 2008 or VMM 2008 R2.
Depending on your needs, you might choose to deploy a single, centralized VMM implementation or to deploy separate VMM implementations at each location.
|VMM 2008 does not provide a method for replicating physical files in the VMM library or metadata for objects that are stored in the VMM database. Physical files must be replicated outside of VMM and metadata must be transferred by using scripts or other means. VMM does not support DFS Namespaces (DFSN), formerly known as Distributed File System (DFS), or DFS Replication (DFSR).|
Centralized VMM Implementation
The primary advantage of having a single, centralized VMM implementation is the ability to manage your primary data center and all remote locations with only one VMM implementation. Another advantage of a centralized VMM implementation is that you only need to maintain a single VMM database, which contains data about your entire virtual environment.
The files that are used to create virtual machines are quite large. Therefore, if you choose to have a centralized VMM server and database, it is a best practice not to have a centralized VMM library, but instead to deploy a library server and one or more hosts at each remote site. Users in those locations can then create virtual machines by using resources from a local library server instead of copying multi-gigabyte files from a centralized library server over a wide area network (WAN). This ability to use resources from a local library server can also help ensure the availability of files during WAN outages or server failures.
Decentralized VMM Implementations
The primary advantages of having separate VMM implementations at each location are:
Each location has the ability to configure and manage its VMM implementation in a way that best meets the needs of its environment.
Virtual operations at remote locations are not disrupted if a centralized VMM implementation becomes unavailable due to a WAN outage or server failure.
Host and Library Server Configuration
In either scenario, if you are using a local area network (LAN) instead of a storage area network (SAN) to perform virtual machine transfers, it is a best practice to locate your hosts as closely as possible to the library servers that the hosts will use to create virtual machines, and to have them as highly connected as possible. It is also a best practice to connect all computers in a VMM configuration with at least a 100-MB Ethernet connection. You may want to consider isolating the library server and the hosts that use it on their own subnet.
As noted earlier, it is a best practice not to have a centralized VMM library if you choose to have a centralized VMM implementation. In either case, you might consider installing a host and a library server on the same computer. This configuration is well-suited when you have 150 or less images (templates, ISOs, vhds) stored on the library server.
The primary advantages of having a host and library server on the same computer are rapid virtual machine deployments because the files for building virtual machines are not transferred across the network, and reduced equipment costs because you use one computer rather than two.
The primary disadvantage of having a host and library server on the same computer is that it can require more overall hard disk space. Maintaining multiple copies of the same files, rather than using a single, central library server at each location requires more hard space.