System Center contains a suite of products and enterprises who have investments in them deploy them together. However, there are restrictions when it comes to settings. 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, not all System Center components can 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. This 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. Ensure 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 preferable use fixed file sizes.
System Center Deployment Requirements and Key Considerations
- The Virtual Machine manager (SCVMM) and the Service Manager does not require any special 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.
- 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.