In the last part of this six part series on System Center 2012 Service Manager we covered the context for Service Manager and the installation experience, in this second part we’ll learn some terms and concepts to understand how SM works, along with some guidelines for scaling an implementation for larger environments.
System Center Service Manager 2012 components
A full-fledged implementation of SCSM contains several servers and components. The following pieces are required; the Management Server that runs workflows in management packs and hosts the Data Access Service that provides access to the server from consoles and connectors as well as the Management Configuration service that controls the configuration on multiple management servers if present.
The management server is housed in one Management Group which can scale up to 50,000 users or computers. In the backend a SQL Server database is also required that stores Configuration Items (CIs) and all the data about IT in the business; this is Service Manager’s implementation of a configuration management database (CMDB).
The Console is used by administrators and engineers to work with Incidents, Service Requests, Change Requests and Problems; these are stored in administrator controlled queues that controls access. The console is installed on the server by default and should also be installed on analyst’s client computers.
The difference between a problem and an incident is that a problem is ongoing, has one or more incidents linked to it, has an action log and related information attached to it and is treated more like a change request. Templates are used to control self-service and data entry into SCSM whilst Workflows are used to automate processes.
Remember that a full SCSM installation requires two servers, unlike all the other SC 2012 components.
Optional components that extend SCSM is the Portal that integrates with SharePoint (including the free Foundation version), this provides a Silverlight experience for users to request services and track progress. There’s also a Data Warehouse SQL database that provide long term data storage of information that’s groomed from the main Service Manager database and is used as the source for reports.
This database is controlled by the Data Warehouse Management Server that manages the grooming from the CMDB, as well as the management of the database. Getting the best value out of SCSM also involves using Connectors to Active Directory Domain Services (AD DS), Configuration Manager, Operations Manager, Orchestrator and Virtual Machine Manager.
SCSM 2012 scaling
Large environments with a full implementation and reliance on SCSM will need to look at High Availability (HA) options; which includes log shipping, clustering or mirroring for the SQL server databases. While each management group can scale to 50,000 users or computers there may be discreet administrative groups within IT that may require separate management groups for less nodes than this.
Each management group require its own backend database but up to five management groups can store their data in a data warehouse management group / database for consolidated reporting. In really large environments the individual databases that make up the DW can be split up on separate servers as can SQL Server Reporting Services.
Each management server can handle about 80-100 concurrent analyst consoles so scale the number of management servers accordingly and load balance using software or hardware load balancing options. If you also have a lot of workflows running on a management server you can consider breaking out one management server just for running workflows, instead of handling console connections as well.
If it’s expected that the portal integrated into SharePoint is going to receive a lot of traffic, the normal SharePoint scaling out rules apply, including separating the website on one or more servers, and the web content server(s) on other dedicated services.
Oddly enough you can’t install the Operations Manager agent on SCSM servers, you have to monitor these servers with agentless monitoring, something that will hopefully be fixed in a future release.
The second part of this six part series covered terms and components used in System Center Service Manager 2012 along with how to design a Service Manager implementation in larger businesses. The third part will cover connectors in System Center Service Manager 2012 along with SLA and Release management.