Freigeben über

VMM Service Deployments in Depth: Deploying System Center Orchestrator as a Service Part 4 – Service Template Configuration and Deployment

  • Artikel

During this post, I will be wrapping up this in-depth look at VMM service deployments. Over the last three postings we have examined the following items:

In this post I will be using all previously discussed topics, prerequisites and the detailed SQL Server / Application profiles to create and deploy a multi-tiered instance of System Center Orchestrator R2.

Create the Service Template:

To create the service template, right click on the appropriate node in the VMM Library node and select ‘Create Service Template’.

Give your service template a name, a release name or version, and select the service pattern. I generally leave the version at ‘new’, modifying this once completed and tested. I also generally start by selecting the blank pattern. As we will see, with all of the prep work completed across the previous few posts in this blog series, creating our service from scratch (blank pattern) is not a complex task.

At this point our Service Template will look like the following. Notice that in my demo environment I only have two Virtual Machine Templates, these are the two that were created during post two of this blog series. The first is configured to deploy a VHD which contains only the OS image and a few other prerequisites such as .Net 3.5 and current software updates. The second is configured to deploy a VHD which in addition to OS and prerequisites also contains a prepared SQL Server image. In this example I will be using both of these templates, thus will drag an instance of each onto the designer pane of the Service Template designer.

Once the VM Templates have been placed into the service pattern, the service template will look thusly.

At this point we have defined that the service being deployed will consisted of two tires, and have defined the VM templates that will be used to deploy the VM’s for each of these tiers. To keep in mind, these VM Templates contain the rules on how each VM will be deployed, such as network settings, VHD settings, and weather on not to be created as highly available. I will not detail each setting for each of these templates as these will be unique to your environment. For the most part, the core configuration of these templates will differ very little from that of just deploying a ‘standalone’ VM. Where we will see significant difference between a standard VM deployment and a service deployment is in the Application and SQL Server Configuration features.

That said, in the following section I will be detailing the configuration of the VM Template for Tier 1 of this example service.

Configure Tier 1: To recap, Tier 1 of the multi-tiered deployment of System Center Orchestrator will consist of a single VM which contains all components of the Orchestrator application (Management Server, DB Server, Web Components, and a Runbook Server). To begin configuration, right click on the VM Template intended for Tier 1 (with SQL Server) and click properties.

Give the Template / Tier a name, I’ve used ‘Tier 1 – Management Server / DB / Web Components / Runbook Server’ .

Next, while we will not make any modifications, observe that this Tier will both be deployed and serviced first. It is important that this Tier is completely deployed before Tier 2 begins as Tier 2 will rely on the existence of the Tier 1 SQL Server instance. Also note that this Tier will not scale. Whereas this service instance may contain many Orchestrator Runbook Servers (Tier 2), we will only have one Management / DB / Web Components Server (Tier 1).

Tier 1 OS Configuration: Next we need to make a very minor yet key change to the OS Configuration of the VM Template. Under the Identity Information / Computer name: I have entered ‘ @COMP@ ’. The @@ identifiers essentially create a variable that can be used throughout the service template. By creating this variable in the Tier 1 computer name position, we can dynamically specify the computer name of the Orchestrator Management / SQL Server at several different positions within the service template. This allowing us to both dynamically deploy the service, but also to deploy multiple instance of the service using unique computer names across all deployments without having to make adjustments to the service template.

Because we have created a Service Template variable @COMP@, when deploying this service we will be asked to provide a value which is ultimately that value that will be given to our Tier 1 VM’s Computer Name.

While potentially not necessary, we can also take this opportunity to add any additional Roles or Features that may not already exists on our captured VHDs. For instance the Orchestrator Orchestration Console requires HTTP Activation; as can be seen below I have configured the VM template to deploy this feature at deployment time.

Tier 2 Application Configuration: No need to go into depth here as the work behind the application deployment has been completed in the form of an application profile. So at this point we simply need to select the application profile that will deploy all Orchestrator components and also SQL Server Management Studio – this profile was detailed in post 3 of this series.

While there is nothing to detail in terms of configuration, I will point out below an example of where we are using the @COMP@ variable to dynamically specify the location of the Orchestrator database.

SQL Server Configuration: Again, nothing to configure here, we simply need to select the SQL Server profile created in post 3. To reiterate, the purpose of this profile is to complete the deployment of the SYSPREPED SQL instance contained on the Tier 1 VHD.

This completes the necessary configuration for Tier 1 in this example.

Tier 2 Configuration: to recap, Tier 2 of this service will contain multiple VM’s each containing only the System Center Orchestrator Runook Server component. Additionally this Tier will be scalable such that additional Runbook Server can be added at will. To begin the configuration right click on the VM Template or Service Tier for Tier 2 and select ‘properties’.

On the General tab give the Tier a name, I have chosen ‘Tier 2 – Runbook Server’ .

I have then modified the deployment and servicing order so that this Tier is deployed and services after Tier 1.

Finally I have configured the tier for scale out. In this case I have started with a default instance count of 4 and max instance count of 8.

Tier 2 OS Configuration: Once again I am going to modify the Computer name field in the template for my Tier 2 VM template, however instead of creating variable like what was done for Tier 1, I have specified RBS0## . The ## indicates that VMM will increment values here starting with 01. So each Tier 2 system will be named similarly, however with incremented computer names (RBS001, RBS002, RBS003, etc.).

Tier 2 Application Configuration: Once again no configuration necessary, select the Application Profile created that will deploy only the Orchestrator Runbook Server component. Again pictured below is another use of the Tier 1 computer name variable. In this case we are using the variable to reference the database server during the Runbook Server deployment.

Because the Tier 2 VM’s do not require SQL Server we do not need to add a SQL Server profile, in fact this Tier configuration is now complete, click ok.

Once the Service Template has been completely configured it will appear similar to the following.

At this point we can validate the Service Templates configuration and save the template using the Save and Validate button found at the upper left hand side of the designer. Once completed the designer can be closed.

Deploying the Service Template: Now we reap the rewards of four blog posts worth of content. To deploy the Service Template, right click on the template and select ‘Configure Deployment’, Select a name and destination for the service.

On the Deploy Service window, we can observe a few items. First notice that we can see a visual representation of the service as it will be deployed, in this case 1 VM for Tier 1, and 4 VM’s for Tier 2. On the left hand pane we can see the current VM computer names for the VM’s of each Tier, and finally we see the ‘prompt’ or text box in which we provide the value to be used in the @COMP@ variable.

We could click the Refresh Preview which would engage the fabric placement algorithm ensuring that our service will ‘fit’ on the destination, or we can just click on the Deploy Service button. If there is going to be a pre-detectable placement issue, the Deploy Service wizard will let you know.

After selecting Deploy Service, confirm that you would like to deploy the service and VMM will take care of the rest. Once this process has completed you service will be baked and ready for use.

Conclusion: If you read all four post of this blog series or simply flipped though, I hope that this has been helpful in your pursuit to service deployment.

Happy Hydration..

neilp