...building hybrid clouds that can support any device from anywhere
The Building Blocks of Service Templates within Virtual Machine Manager by David Stoker
Having worked with customers early in the System Center 2012 Virtual Machine Manager Technology Adoption Program (TAP), I’ve been asked several times how does one effectively build Service Templates? The goal is to first create standardized “building blocks” which can then be used to quickly build Service Templates by selecting the various components from an existing menu. Think of it as ordering from a restaurant menu:
“I’ll take the medium hardware profile, Windows Server 2008 R2 Enterprise, the Contoso.com domain, the Web Server role and the Stock Trader Shopping Cart Web Deploy application package…and I’ll take four of these please…”
In the past, the basic OS Image wasn’t so basic. Just about every application and OS setting desired had to be included in the OS Image. With System Center 2012, this all changes…
First, you start with as basic an OS Image as possible. Only include core OS settings and security patches. I’d only recommend deploying a third-party application within the OS Image if it is common to every VM AND it requires very infrequent updates. For environments standardized on Windows Server 2008 R2, we typically start with two fully patched OS Images in the Virtual Hard Disk (VHD) format:
1) Windows Server 2008 R2 (choose your edition)
2) Windows Server 2008 R2 with SQL Server 2008 R2 sysprepped following this guide (http://technet.microsoft.com/en-us/library/ee210664.aspx).
Once built, simply upload the VHD files to the VMM Library. For VMware environments, import the vCenter VM Template into VMM.
Next, we want to create a set of reusable Hardware Profiles. These define cloud capability settings such as Hyper-V, ESX Server or XenServer as well as hardware settings such as virtual CPU, memory, video adapter (including Microsoft’s RemoteFX 3D adapters for your VDI solution), SCSI adapters, availability, etc. Additionally, we identify how many network adapters are needed for each Hardware Profile but don’t connect the network just yet.
I usually start with 3-4 Hardware Profiles: Small, Medium, Large and SQL. Since SQL usually requires a unique memory configuration, I find a dedicated SQL Hardware Profile works well in most environments.
Note that we don’t actually attach any virtual hard disks to the Hardware Profile; that will come later.
We also want to create a set of reusable OS Profiles. As with VMM 2008 R2, OS Profiles define the computer naming conventions, local admin account, product key, time zone, domain/workgroup settings, etc… New to System Center 2012 VMM, the OS Profile now includes the ability to add Roles and Features to Windows Server 2008 R2 and newer guest operating systems.
I recommend creating OS Profiles for common deployment scenarios such as File Servers, Application Servers and Web Servers. It’s usually a good idea to create a generic OS Profile to handle one-off scenarios as well.
New to VMM, Application Profiles are designed specifically to enable the deployment of SQL Server Data-tier applications, Virtual applications and Web applications along with supporting application scripts. However, you can deploy just about any application via a generic Pre-Install script. If it can be silently installed without a reboot, I’ve found that it can usually be installed via an Application Profile.
I usually create “starter” Application profiles which deploy the Server App-V and Web Deploy clients. These allow easy updates when creating Service Templates as the prep work to deploy the Server App-V or Web Deploy package can be consistently applied to all Service Templates. I additionally recommend creating Application profiles for commonly deployed applications.
Also new to VMM, SQL Server Profiles complete the two-step SQL Server sysprep process. This includes SQL Server instance name, security settings, remote connectivity settings and service account settings just to name a few. At a minimum, I recommend creating one SQL Server Profile.
The OS Image, Hardware Profile and OS Profiles are combined to create VM Templates, which in turn are used to create Service Templates. You can optionally add Application Profiles and SQL Server Profiles to VM Templates. I find this valuable if I frequently create different Service Templates with a common Application Profile, but these profiles can be selected directly in the Service Template Designer as well.
The goal here is to create multiple options including hardware and core OS settings that take a basic OS Image and deploy a variety of standard VM configurations thus minimizing the OS Image creation and management process.
Now that all of the building blocks are in place, we can quickly create Service Templates. It is recommended to deploy every VM from a Service Template (even single-tier, single VM deployments) as this enables updates to the Service to take advantage of the release management capabilities built into System Center 2012.
In the Service Template Designer, you can name your Service Template, select the number of tiers and simply drag those previously created VM Templates over top of a tier as need to set the proper OS Image, Hardware Profile and OS Profile settings. You can also easily add Application Profiles and SQL Server Profiles at this time in addition to any other applications in the VMM Library. The goal here is to make the final Service Template creation process very simple by selecting various components from a list of previously created items.
Finally, remember how we never connected the virtual network adapter to a logical network in the Hardware Profile? In most Private Cloud deployments several logical networks exist, which makes it an inefficient choice to create one or more Hardware Profiles for every logical network. One of my favorite “quick” features in VMM is the Connector tool within the Service Template Designer. Simply add a Logical Network to the Service Template and use the Connector tool in the ribbon to connect these two objects. In a four-tier Service Template I recently created, this little feature took only 6 steps to connect all of the virtual network adapters (and saved me 14 repetitive steps)…
David Stoker US Private Cloud Center of Excellence Lead Microsoft Services | firstname.lastname@example.org
Go Social with Private Cloud Architecture! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki
Excellent structured recipe for service templates.
Our dc naming conventions typically include a reference to the app (tenant) abbreviation and tier of service (web/app/db). This is creating quite a bit of sprawl within the environment with respect to templates. Is there anyway to dynamically assign this or should we go back to the drawing board?