System Center contains a suite of products for Enterprises which enables them to deploy and manage Windows (Wintel) datacenter environments. The suite of upper growth include the following:
- CONFIGURATION MANAGER: Used for Software deployments, data protection, and health monitoring.
- OPERATIONS MANAGER: Manage and analyze server usage, monitoring, and health diagnostics. Also, supports Linux based systems.
- VIRTUAL MACHINE MANAGER: Manage Hyper-V based virtual machines and their networking, security, compute and deployments.
- DATA PROTECTION MANAGER: Cloud backup solutions for the entire datacenter.
- ORCHESTRATOR: Datacenter Automation with PowerShell scripts and workflows.
- SERVICE MANAGER: IT ticket management for Incident Management, change management, and performance management. Based on the Microsoft Operations Framework similar to ITIL.
All of these products uses various SQL Server Services for running day-to-day operations. However, there are restrictions in SQL Server when it comes to deployment. Individual System Center products have different systems requirements, especially from the SQL Server perspective. Read below to know more about System Center Deployment restrictions for SQL Server.
System Center Deployment Requirements and Restrictions for SQL Server
- A minimum of four Servers is required to deploy all the System Center components. Not only due to performance reasons, but not all System Center components can also coexist on the same Server or instance. To know more, Go to Component Coexistence for System Center 2012 R2.
- Only use one SQL Server Database Server instance for testing of all the System Center components. It is not recommended for production environments due to performance and other concerns.
- You need dedicating Reporting Services instances for individual System Center components. You cannot share SSRS across System Center components.
- Currently, “SQL_*” collations are being deprecated for their Windows equivalent collations.
- Always limit the memory of each SQL Server instance. Set the “Max Memory Setting” such that the Total Memory setting is less than the physical memory. It allows a minimum of 2GB (4GB preferred) of free memory for Windows to comfortably run all services without paging.
- System Center components are IO intensive and require a lot of disk resources. Mainly, Service Manager, Operations Manager, and Configuration Manager have high disk usage.
- Ensure that the disks are formatted with 64K allocation unit size. See my post on SQL Server performance tuning.
- Ensure that Disks have more than 2-% of free space post deployment. Provide monitoring of DB Size and growth. The growth upper limits should not exceed the free space limit.
- Ensure sizing of disks. Disable “auto-grow” and preferably use fixed file sizes.
System Center Deployment Requirements and Key Considerations
- The Virtual Machine Manager (SCVMM) and the Service Manager does not require any particular SQL Server Services other than the regular SQL Server DB’s. Even though they are shown with different instance name recommendations, you can safely store them on the same SQL Server instance.
- In the case of SCOM (Operations Manager), it requires Full-Text Index, SQL Server Analysis Services (For Data-Warehouse & Reporting) and a regular Database Engine. Having a dedicated SQL Server deployment gives more room to scale out when needed.
- Using a dedicated SQL Server Instance allows you to have dedicated resources for databases rather than having each database competing for system resources. Although you can use Resource Governor with custom resource pools to manage separate resource pools at the instance level, it is better to have those instances separated out.
- You can patch and restart each SQL instances separately without any downtime for SC or SCOM.
- For Service Manager Databases, splitting the CMDB from the data warehouse is a recommended best practice. There is a similar best practice for SCOM as well. For Operations Manager splitting the Operations Manager database from the data warehouse is a recommended best practice.
- Putting SCOM and SCCM on different instances with dedicated report servers is also recommended since SCOM reporting services can cause issues for SCCM reports.
Quick Note:
For System Center Service Manager (SCSM) and the Operations Manager (SCOM) databases, the following are the Collation requirements:
- SCOM Databases – The Data Warehouse and Operational Databases will require SQL_Latin1_General_CP1_CI_AS
- System Center Data Protection Manager does not support “SQL Server Always On Availability Groups.”
- Build 1602 onwards, SCCM supports “Always On Availability Groups“.
- SCSM Databases – The Service Manager DB collation settings will need to be SQL_Latin1_General_CP1_CI_AS (Service Manager DB, DWRepository, DWDAtaMart, DWASDatabase, OMDWDataMArt, CMDWDataMart)
- The DWStaging and Config, however, need Latin_General_100_CI_AS as its collation setting.
Please refer to the official documentation here.