“Can I use System Center to provision SQL Server components?”… “Can I provide database as a service to my business users or application owners?”…
The ability to automate SQL Server provisioning is probably one of the top customer requests I’ve heard about over the last 12 months!
The goal of this post is not only to confirm that System Center can indeed provide this capability, but also to provide a downloadable sample solution – the “SQL Server Self-Service Kit” - that you can reuse and adapt to your own needs.
Overview and Scenarios
A typical SQL Server component request might consist of a combination of these:
- SQL Server database or SQL Server instance
- Dedicated or not (i.e. do you want this to run on your own isolated machine/VM, or on a “shared” environment)
- Highly available or not (i.e. should the component be deployed on a cluster)
Alternatively, someone may also be interested in getting a multi-machine environment including SQL Server, where an application could be dropped.
Taking into account all the combinations, this leaves us with a certain number of deployment types, 9 of them actually!
The downloadable solution associated to this blog post covers these scenarios, and we’ll now explain how they work, and the prerequisites to use them in your own environment.
Beyond automating the deployments themselves, you might also be interested in the self-service functionality, and the solution also provides an optional example in that area.
Get the sample solution!
Make sure you go through the 2 deep-dive posts, including “Gimme the details (part 2)”, which covers the installation and configuration instructions for this sample solution.
What do you get, and how is each deployment type handled?
The package you will download includes different components:
At the fabric level, 18 Orchestrator Runbooks cover 7 different deployment scenarios:
4 “Shared” scenarios |
|
2 “Dedicated” scenarios |
|
1 “SQL Server-enabled environment” scenario |
|
At the process level, an optional Service Manager management pack showcases the following scenarios:
•Service catalog webparts for self-service
•An approval process for “dedicated” scenarios (Runbooks automatically approve “shared” requests)
•Automatic discovery of user executing the request, for notifications and granting user rights to deployed DB/instances
Alternatively, you can choose to just use the fabric components (Runbooks and service template), and integrate them with your own self-service. We will see that the Service Manager integration has been crafted so that it has no hard dependencies : Should you wish to use them, the SM-enabled Runbooks monitor service requests of a specific type and in a specific condition, update these requests and/or call Orchestrator Runbooks. You can read more details on what the SM integration adds into the solution, in the deep dive posts (see links below).
Note : As a careful reader, you may have noticed that I mentioned 9 deployment scenarios, and 7 are covered in the solution. The 2 deployment types not handled today by the solution are deploying deploying a DB or instance on a new cluster. We plan to add these 2 scenarios in a refresh of the solution by the time Windows Server 2012 R2 and System Center 2012 R2 are generally available, as it will be the opportunity to leverage new service template features in Virtual Machine Manager, as well as other automation scenarios. For now, the current solution sends an email to the requesting user, redirecting him/her to an operations team handling very custom installations. It also highlights how you can adapt the Runbooks to map your processes, since you may elect to support only some of these deployment types, depending on your uses cases.
I want to learn more!
Fear not! Here are two additional posts going over more details regarding the SQL Server Self-Service Kit:
- Sample execution #1 : Requesting a new dedicated instance without high availability
- Sample execution #2 : Requesting a new highly-available database on a shared environment
- Sample execution #3 : Requesting a “SQL Server-enabled” environment
- Gimme the details (part 2)
- What do I get if I use the Service Manager integration?
- Using the package : Installation and configuration
- Some tips and tricks worth highlighting
Supported versions
These deployment scenarios were tested with Windows Server 2012 and SQL Server 2012.
System Center 2012 SP1 was used, including the Orchestrator, Virtual Machine Manager and Service Manager components.
Note that similar principles should apply to earlier versions of SQL Server too, with a different set of unattended (INI) files for examples.
Wrap-up / Looking ahead
Feel free to share your experience using this sample solution!
As mentioned earlier in this post, I am planning a refresh of this solution in a couple weeks when System Center 2012 R2 and Windows Server 2012 R2 become generally available, to include feedback/updates, new scenarios (deploying an instance or DB on a new cluster, possibly AlwaysOn additions), and ideally some Windows Azure Pack (WAP) and Service Management Automation (SMA) support.