A lot of folks talk about wanting a SaaS solution for Service Management (no hardware spin-up costs). They also talk about wanting great on-premise integration. I recently set out to solve this problem by implementing a scenario which provides a best-of-both-worlds solution by implementing System Center 2012 in Azure IaaS. In this scenario we have highly available, site independent, and on-premise integrated Systems Management, deployed quickly, easily, and without heavy initial investment. In my scenario we started with the idea that we wanted to put as many of our components in the cloud as possible. In this case we found that we were able to implement most of our solution, as a production scenario, without deploying it on premise. This provided us with an excellent model for serving our internal environment. The environment looked as follows:
- System Center Service Manager: Azure IaaS Virtual Machines
- System Center Operations Manager: Azure IaaS Virtual Machines
- System Center Orchestrator: Azure IaaS Virtual Machines
- System Center Configuration Manager: On-Premise Primary and Azure IaaS DP and Intune
- System Center Virtual Machine Manager: On-Premise for Private Cloud
This allocation falls in line with the official System Center and Azure support policy here. This allows me to position most of my management environment in the cloud, able to manage my sites without an on-premise dependency. In this scenario I was able to deploy System Center reliably and had good Service Manager, Operations Manager, and Orchestrator performance. What made this so much better than competitive SaaS solutions was that I had control over the environment and tight integration through the other System Center components. So many other companies are selling SaaS solutions that essentially sit by themselves, without the plumbing to bring the necessary data into the system. In an Azure deployment we found we could get a customer online quickly and also integrate on-premise reliably. A few key tips for deploying this scenario are:
- Servers positioned in the cloud should have similar specifications to what is on premise.
- Ensure you allocate data drives for your application installations. All of my System Center instances have data drives for the actual binaries for each component.
- Ensure you have multiple data drives for the SQL servers striped in dynamic disks
- Ensure you have adequate backup for the virtual machines running in Azure. You still need to configure SQL backups and have recovery plans.
- Remember that you will need to configure the on-premise network connection once for Azure, for which there are several guides available. This will provide the inter-site connectivity that allows your virtual machines to be part of the domain. Here is a handy guide for setting the virtual network up using Windows Server 2012.
- Remember that the temp drive is for temp files. Do not install anything there.
- Remember that the IP addresses in Azure are dynamic. Do not allocate a static IP address.
- If you're putting Orchestrator in Azure, you may want to think about data transfer scenarios to on-premise servers. I've found that in that case it might be helpful to have an on-premise runbook server. However, if much of your datacenter in moving to Azure, or you're essentially executing remote commands, Orchestrator runbook servers in Azure makes a lot of sense.
- Do performance testing of your web console and portal from the on-premise environment to ensure you have the experience you want. If you skimp on bandwidth between Azure and your primary site you'll see negative results.
- Follow the standard deployment guides for most products, with exception where there is a specific configuration, such as the SCCM DP, for which a guide exists here.
- My general assumption was that I was going to use web consoles from GridPro (really nice web, mobile, and Lync products) or Cireson (asset management, add-ins, and web console) for these types of deployments for anything but administration.
- Just because it is a cloud solution doesn't mean you should just "start using it". The most important part of a project around IT Service Management is the process, not the tool. The tool is important in execution, but you don't simply want to move your broken processes into a new tool. A broken process is still a broken process.
- If you own the System Center licensing do not spin up a SQL server using the Azure template, as you are charged for the SQL license! Use a Azure IaaS template for Windows Server 2012, add the data drives, then install SQL yourself. In many cases the integrated SQL licensing is great, but in this case it is not necessary, unless you like paying twice.
Here is a quick good snapshot of part of the Azure topology: Here is the server statistics you see on an individual server in the topology: On the management server you can see the two disks associated with the data warehouse at the bottom, those are striped in the next image: Inside the management server you can see how we've striped two disks into one volume. If you need to improve SQL IOPS, you can add additional hard disks to the stripe: To learn more about disk allocation, check this out: I'll be further detailing this solution in following posts and webinars. Stay tuned for more! Nathan Lasnoski