ConfigMgr 101: MP Replica

In this latest installment of my ConfigMgr 101 series I am looking at the management point replica feature within Configuration Manager 2012. Some people I speak to have never heard of MP replica’s, some have and don’t use them, so what are they all about?

You can configure management points within a primary site to use a replica of the site database. At the primary site, you can configure servers which run SQL to host a database replica, from here a management point (or multiple ones) at that site can use the same database replica. When this configuration is in place, the management point requests data from the SQL Server that hosts the replica. This configuration can be especially useful in the largest hierarchies for both performance and redundancy.

With Configuration Manager 2012 SP1 you can also use native SQL replication to perform the replication, another big benefit as this isn’t as easy to setup in previous versions.

Performance

One of the long standing recommendations is to have the database server standing co-located with the primary site. I’m going to go into the reasons why this is, everything on that subject is very well documented. This configuration does give us some performance benefits but think of the largest hierarchies, when we manage 100,000 clients or more. Even 50,000 or more would be considered a large deployment of Configuration Manager.

Consider the following scenario, Monday morning all our users turn up in the office, we have around 70,380 users assigned to one primary site. Every week we hit massive performance problems and lots of Operations Manager alerts from high CPU usage on our primary site, which has SQL in a remote location by the way. The idea here is we rock up and place database replica and configure the management points to use these replica.

cpu_high

Check out our high CPU usage here from all these clients hitting the primary. Once we configure replicas this usage drops below 20%. With this configuration you can even remove the need for that remote SQL and host that on the primary site. What we are doing here is removing the processing load from the primary site and moving it down to replica.

Configuring Replica

At a high level you need to complete the following to be able to configure a database replica:

  • Configure publishing of the site database to the database replica
  • Configure the database replica server
  • Configure management points to use database replica
  • Configure a self-signed certificate for the database replica

The full configuration guide for all this can be found on TechNet. It’s a great resource and a good documentation page for getting this configured and up and running.

Overview

If you are supporting the largest hierarchies you will know that your Configuration Manager servers need to have some beef, by introducing replica you can reduce these costs slightly by introducing new servers to manage and distribute the load more. This increases performance on your primary site.

Advertisements

Tags: , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: