This session focused on the brand new services template module in VMM 2012. Service templates are a method to rapidly, consistently deploy, and maintain applications regardless of what hypervisor (Hyper-V, ESX or XenServer) that you use. So this entire session applies to customers even if you are a VMware shop, or a mixed environment.
Session highlights include:
- A services template is the starting point for services and source of truth. It specifies machine and connectivity requirements. Deployed services are always linked to their templates. This enables servicing of instances, not just individual VMs.
- An instance is a group of VMs working together, it includes machine specific definitions as well as applications. Native application support for web applications (WebDeploy), virtual applications (server App-V package), and database applications (SQL DAC). Future versions of VMM will likely support more types of applications (.e.g. Exchange, etc.).
- Why use service templates? You can manage multi-tier applications across multiple servers as a single unit. This allows you to scale out on demand. It also allows you to manage fewer OS images, since you can customize the OS deployment at provisioning time.
- The lifecycle includes creating a template, customize the deployment, deploy a service, then update template and apply to a service.
- The service templates are authored in a new Service Designer. This defines the tiers, VM hardware, logical networks, OS, applications, load balancer configuration, etc.
- The Service Designer is a really slick application with a ribbon interface that let’s you graphically construct your application, link to networks, define instance counts, deployment order, upgrade domains, and servicing order.
- A customized deployment of a template lets you define OS settings (computer name, admin password, etc.), application settings (SQL connection string, service account names, passwords, etc.), and lets you use the same template in various environments (dev, staging, production, etc.).
- The deployment has several integration points where you can inject scripts to even further customize the deployment, which run in the guest OS.
- There are two update types. The first is a regular update where the template changes are applied without replacing the OS image. Changes can include increasing memory, application updates, etc. The second method is an image based update. This replaces an old OS image with a new OS image. This re-installs the application, while preserving state. For example, you could migrate your webapp from Server 2008 to Server 2008 R2, with little to no downtime.
- Regular updating and image updating both have extensive integration points where you can inject custom scripts to change the update process.
- Service templates can be imported and exported and use a XML file. This lets you share templates between different environments, backup templates, or synchronize them in a multi-VMM environment. Like a GPO import, you can map resources to the template during the import process. For example, you can map network names or storage tier levels, even if they don’t have the same name in the different environments. Very slick!
What was really slick about this session was the demos. While all of the information above is great, you could easily gloss over the potential impact of VMM. One compelling demo was updating a web app.
In the demo the original template was defined with v1.0 of the app, and used a scale out approach with a hardware load balancer. This created multiple instances of the web app, in a HA (high-availability) configuration (let’s say four web servers). Now let’s say you have v2.0 of the application you want to roll out but maintain HA. You open the service template and update the application to v2.0. Nothing has happened in production, since you’ve only updated the template. You now click a button to deploy v2.0 of the template. The template has defined service domains, which in this case, takes down two of the four web servers, pulls them out of the HLB, updates the web app, then adds them back into the HLB. After the first two are done, it takes down the next two, using the same process. 100% automated and no downtime!
Now let’s say v2.0 of the WebApp has some bugs, and you need to revert back to v1.0 until you can fix the issues. No problem! Click on the service template, and you see the full version history. With a single click you revert to v1.0, and it repeats the same deployment process of removing the VMs from the HLB, down-rev the app, and add them back to the HLB. Completely automated roll-back, without service interruption.
And remember…service templates are hypervisor agnostic, so VMware shops get all of these service template features. Since this is an automated process, it minimizes human errors, limits configuration drift, and orchestrates the updates in a HA manner. What will be really exciting is when more products are supported, such as Exchange, so you can roll out service updates in a similarly automated fashion. Very slick indeed.
Service Templates support Windows Server 2003 R2 SP2 and later VMs, and SQL 2008 R2 (not SQL 2008 since it’s not sysprep aware). As Microsoft gets onboard with Server App-V, those applications will be fully supported as well.
