System Center 2012 Virtual Machine Manager offers new capabilities for a new computing age
I say this in many articles, talks, and books: We really are in a third age, as far as thinking about our IT infrastructures is concerned. Originally, administrators focused on each physical server on which an OS was installed. You walked around the data center and pointed to each server: "That's my domain controller; that's my Microsoft SQL Server machine," and so on. Management was performed on a per-box basis because each box ran a single OS with a single application. With virtualization, OSs were consolidated onto fewer physical boxes hosting multiple virtual machines (VMs), and we entered the virtualization age. We focused on each OS instance: "That system is running a bunch of VMs; that one's running a bunch of VMs, too." Unsurprisingly, tours of data centers weren't as popular as they had been. The management effort was similar, provisioning became a bit easier, but there were extra hypervisor pieces to manage. Each OS was still managed individually. As an administrator, you connected via RDP to a server -- if you were very advanced, you connected remotely, via System Center Service Manager -- but still managed and focused on one OS at a time.
Learn more by visiting "Enabling the Private Cloud with System Center Virtual Machine Manager 2012" and "Q: What are logical networks in System Center Virtual Machine Manager 2012?"
With the private cloud, we enter the third age of management. The focus shifts to the service that's being provided. The management infrastructure should manage and provision the OS as a collective, behind the scenes, allowing the focus to be on the service rather than on the underlying OS. To enable this shift to application-centric thinking, two things are needed:
Not surprisingly, Microsoft System Center 2012 Virtual Machine Manager addresses both these needs.
Readers who are familiar with desktop technologies probably know that Microsoft acquired a company called Softricity several years ago, renaming Softricity's Softgrid application-virtualization solution as Microsoft Application Virtualization. App-V allows an application to run locally on an OS, without being installed on the OS, through the use of a virtual environment. This environment has virtual layers, such as file system and registry, in which application artifacts (e.g., files, settings) reside. This application virtualization allows applications to be delivered very quickly. No application installation takes place. Because applications each run in their own virtual environment, a major application problem is solved -- namely, application-to-application compatibility challenges, such as when application A can't exist on the same OS instance as application B. Because the applications are virtualized and run in their own sandboxed environments, they don't see one another.
The goals for server virtualization are different than those of desktop virtualization. Server application isolation is rarely required or even desirable. Likewise, real-time streaming of server applications is an uncommon requirement. What's wanted is the ability to simplify the deployment of server applications, which can have primarily manual, 100-page installation processes. Also desirable is the ability to enable server-application mobility between OS instances, so that OSs can be serviced without lengthy application downtime, by moving an application instance from one OS instance to another.
Now, the App-V technology has been enhanced to support server requirements, via Microsoft Server Application Virtualization (Server App-V), a specific version of App-V that's part of Virtual Machine Manager 2012. The major differences from the desktop App-V features are as follows:
This technology means that a server application is installed once in the Server App-V sequencer environment, which creates the Server App-V packaged version of the application. There, the entire installation process is performed, and any machine-specific configurations (e.g., service credentials, hostnames, port numbers) are extracted. This packaged Server App-V application can then be quickly deployed in a consistent way, simply by passing these instance-specific settings to all the required environments (e.g., development, testing, production). This approach solves many problems that are common when deploying complex applications between environments. In addition, the deployed Server App-V application instance and all its data can easily be backed up and deployed to another OS instance, maintaining all application states. Not only is the server application virtualized, but any related configurations and data are connected to the packaged application and can easily be backed up and restored through Server App-V Windows PowerShell cmdlets, providing easy portability between OS instances.
During the creation of a Server App-V sequenced server application, the sequencer process automatically identifies many instance-specific parameters, such as the hostname and credentials. However, you can also modify the packaged application after sequencing. The person who performs the sequencing can specify additional properties from the registry, services, and XML configuration files to be considered instance-specific; these properties will then prompt for a value during the deployment of the virtualized server application. In future versions of Server App-V, I expect to see even more flexibility for extracting instance-specific values from regular text files instead of from XML files only.
Server App-V is designed to be combined with service templates, another new Virtual Machine Manager 2012 feature. Although you can use PowerShell cmdlets to deploy and use Server App-V packaged applications, Server App-V is designed to be used as part of a service template, which can take advantage of its easy deployment and mobility.
Few applications today are islands. Applications connect to services on other OSs, use databases, and so on. Service templates allow you to model a full service in the new Virtual Machine Manager Service Template Designer tool. With this tool, you can create application tiers on a canvas. You can then define the attributes of each required tier, along with VM templates and the applications that need to run on those VMs to allow the tier to function. You then make connections between the tiers and to other resources, such as networks and storage. For each tier of a service, you can configure the initial, minimum, and maximum number of instances of each VM that makes up the tier. Doing so enables scalability because VM instances can be added and removed as required.
The various logical networks and storage tiers can be defined or left as options, to be configured as instances of the full service are deployed. Figure 1 shows a basic three-tier service that also uses a hardware load balancer to provide balancing for the web tier, which uses a Server App-V version of Apache. This shows another powerful capability of service templates and the overall new ability of Virtual Machine Manager 2012 to manage more than just the compute fabric. If the network and storage fabric have been configured in Virtual Machine Manager (e.g., via a hardware load balancer), then those resources can automatically be used as part of a service template. When an instance of this service template is deployed, Virtual Machine Manager automatically creates all the required VMs, based on the initial count of VM instances for each tier. Virtual Machine Manager then automatically connects to the hardware load balancer, creates a new pool that contains the IP addresses of the VMs that make up the web tier, and creates a new service on the load balancer, matching the configuration that's defined in the selected virtual IP template. You can go from zero to running a full multi-tiered service in about 5 minutes.
Figure 1: Three-Tiered Service
Diving into a little more detail on the options available for each tier, the configurations will seem very familiar if you've used Virtual Machine Manager VM templates. Essentially, each tier just uses a template, which can have additional configurations that can be made as part of a normal template definition. Essentially, the service template just gives you the opportunity to make further customizations to existing VM templates, if necessary. Initially, when you drag a VM template onto a tier definition on the service template canvas, the configurations match the source template exactly. However, you can open the tier properties and make changes. Such changes can include modifications to the virtual hardware specification, but they will most likely relate to the application configuration or SQL Server configuration, as shown in Figure 2. It is through these configurations that applications can be added to a tier: The configurations give the tier its functionality and bring value to the overall service. Applications can be Server App-V virtualized applications, a SQL Server or web application, or any application that can be deployed via a script -- which for enterprise applications should cover just about anything.
Figure 2: Application Configuration
Service templates offer another great capability. Typically, after a VM is deployed from a template, it loses its connection to that template. If the template is updated, there's no way to refresh the deployed VM with the new details. But services that are deployed from a service template maintain their link to the template. You can update a service template, perhaps with a new OS Virtual Hard Disk (VHD). Or you can change the VM specifications and then point to a deployed instance of the service and tell it to update. If the actual OS VHD has been updated, the running Server App-V applications are backed up with all data and state, the new OS VHD is deployed and configured with the same settings as the VM that it's replacing, and the Server App-V applications are put back. The OS image is refreshed but none of the application configuration or information is lost. This is just one use case of updating deployed services by updating the template. The example shows the power of focusing on the service rather than on the underlying OS instances. See my video for a quick overview of service templates.
Update domains are also supported with Virtual Machine Manager templates. Suppose that I select an instance of a deployed service template and request an update to a newer version of the template. The deployed service would be unavailable because the existing VMs that make up the deployed service instance are deleted and re-created per the new service template definition. With update domains, the deployed service can be divided into multiple domains, which are basically groups of servers within the deployed service. When an update is performed, one update domain at a time is updated, leaving the servers in the other update domains available to carry on offering services and eliminating service downtime. This is key for keeping services available and is similar to a model offered by many public cloud services, including Windows Azure.
During the initial service template creation, each tier is configured with a default minimum and initial instance count of 1 and a maximum instance count of 5. However, these values can be changed as part of the tier configuration. Although the default initial and minimum instance count is 1, this value shouldn't be used in a production environment. A single instance of a tier means that the tier will be unavailable if a VM fails, likely rendering the entire service unavailable. In addition, at least two instances of a tier are required to service the tier without downtime, allowing one instance to be updated, restarted, and even re-created while the other instance continues to service user requests. I recommend using 2 as the minimum value; to maintain availability during maintenance, use a value of at least 3. These values specify only the scalability options for a tier; there's no automatic scaling of a service by Virtual Machine Manager, based on the load that a tier is experiencing. If a tier is becoming very busy, then additional instances should be added, but this doesn't happen automatically. Both the Virtual Machine Manager management console and the web-based System Center App Controller allow additional instances of a tier to be added or removed, but this is a manual action. The good news is that this scaling of tiers can also be accomplished through PowerShell and other interfaces. It's a fairly simple task to create your own processes to monitor the utilization of tier instances and to perform automatic scaling, if required -- including System Center 2012 Operations Manager and System Center 2012 Orchestrator.
Few organizations take full advantage of the Server App-V and service templates technologies. This isn't surprising, given how new they are; it will take time for organizations to understand and adopt Server App-V and even longer to start thinking about deploying services by using service templates instead of individual VMs. But the change will happen.
Deploying multi-tiered services isn't always appropriate. There will always be one-off applications that might not be good candidates as offered services for an organization. But taking advantage of Server App-V and service modeling will still simplify the deployment and management of even single VM services. Over time, these technologies can be a huge benefit to organizations. And as the private cloud is truly embraced and the focus shifts to the application, Virtual Machine Manager is likely to become the center point of your IT infrastructure.