This chapter is from the book
This chapter is from the book
This chapter is from the book
Site-to-Site Replication
The following sections cover the two primary methods of site-to-site replication in ConfigMgr: database replication (handled by DRS) and content replication (or file replication). These replication methods have been the cornerstone of ConfigMgr since the 2012 release.
About Configuration Manager Database Replication
Database replication replaces the file-based replication methods previously used. It removes the need to reprocess these files at each site in the hierarchy.
These files contained client data (status and state messages along with inventory and discovery) and server data (status messages and discovery data). These were processed at each site, which had an impact on the scalability of the site as the messages had to be processed at each site they traversed to ensure that each site’s database contained the correct information. This lack of scalability led to bloated hierarchies with additional sites just to distribute (scale out) processing load.
This method was inefficient because information was processed at least twice in a hierarchy—once at the primary site and again at the central site. In complex and large hierarchies with multiple tiers of primary sites (which was possible with ConfigMgr 2007 and earlier versions), this could cause the same file to be processed numerous times. Each processing incurred write costs into the site database for each site, along with inbox processing by ConfigMgr components. The event of a flood of data to process at any one site resulted in a flood of data to every site above that flooded site.
ConfigMgr 2012 removed this issue by introducing database replication. Database replication is a slightly confusing term as transactional database replication is one of the most common methods of database replication used by SQL Server database administrators. This term was also used in early beta versions of ConfigMgr 2012. For this reason, this book refers to it as DRS from here on, as DRS has nothing to do with transactional database replication in SQL Server.
DRS uses SQL Server change tracking to monitor for table changes and store them. With each activation of DRS by SMSExec’s Replication Control Manager (RCM), changes since the last activation are reviewed and bundled into compressed XML messages and passed to the SSB. The SSB provides a guaranteed transmission method between SQL Server database engine instances for an SQL Server-based application, in this case ConfigMgr. The term guaranteed is used from a developer point of view to refer to a transmission method that the developer is not responsible for maintaining; rather, the SSB provides a resilient transmission method for atomic messages where the developer can fire messages and assume that they were delivered.
As part of creating a ConfigMgr site in a hierarchy, asymmetric keys are exchanged for authentication of each SQL Server database engine instance for use with the SSB. Setup also initializes the database on each end of the replication. The initialization extracts from the database information that is authoritative for that type of data. The CAS is authoritative for global data, which includes all console objects. Primary sites are authoritative for site data, which includes client data (inventory, state/status, and discovery) along with site-specific information (state and status messages). In addition, some types of data could be conceptually viewed as being shared—in the sense that the CAS and its child primary sites both write different information to the same table. For the purposes of DRS, authority is defined at the table layer and not within a table. This is an important distinction, as DRS is used to recover a site outside its change-tracking interval.
For these reasons, if you implement a hierarchy, it is important to monitor DRS replication between your ConfigMgr sites to ensure that any outage is resolved as quickly as possible. Furthermore, while it is possible to increase the data retention value to 14 days, doing so has an impact on the performance of the site database and SQL Server because almost three times the amount of data for the changes must be stored in the site database.
DRS CRASH COURSE
As discussed earlier in this section, change tracking detects changes within a site database for the purposes of DRS. These changes must be stored somewhere for subsequent use. There are scenarios where a transmission outage between two sites could occur: There could be a transitory network issue, or one of the site servers (or a site database server) could be down. Change tracking has a rolling buffer to cater for these sorts of outages. By default, this rolling buffer is configured to store 5 days’ worth of data. You can configure the data retention value from 1 to 14 days via the Database properties for the site database in the ConfigMgr console under Monitoring -> Database Replication -> Parent Database Properties (or Child Database Properties, depending on the server you are changing). Figure 3.17 shows the default configuration for a CAS database.
)
FIGURE 3.17 Data retention setting on a CAS’s database properties in the ConfigMgr console.
Notice the lengthy text describing this setting in Figure 3.17. By default, there is potential data loss in scenarios where an outage lasts longer than 5 days. Changes that occurred more than 5 days ago are lost, as SQL Server change tracking has a default retention of 5 days. DRS therefore knows it has some missing data (that occurred after the 5-day mark) and cannot trust any of the data sent or received since that truncation occurred (even if only a single day). When this occurs, the site goes through a process of reinitialization. Much as with initial setup, data is extracted from the parent and child database, sent via the file replication (SMB) method to each site, and inserted in bulk into the receiving database. Replication can continue from there via DRS.
As each site is authoritative for its own data and the CAS is authoritative for global data, there is minimal potential for overlap. There is a potential for data loss in scenarios where administrators begin editing global data or objects (applications, client settings, software update deployments, and so on) at the child primary site. In practice, administrators may unknowingly do this to allow client operations to continue to function during a replication outage. It is necessary to do so only when you are sure you can restore communication via the two sites within the data retention period. If this is not possible and the replication between the two sites is down for over 5 days, any changes to global data made at the primary site are overwritten by changes from the CAS. This overwriting occurs because ConfigMgr reinitialized DRS between the two sites, and the CAS’s export overwrites all global data at the primary site, regardless of who modified the data (because the CAS is authoritative for global data).
About Content Replication
To enable content replication, ConfigMgr uses SMB to copy files from one site server to another site server. This is generally from the CAS to its child primary sites. You could create content directly on a child primary site and have it replicate up, although using this method causes additional replication lag and is less efficient due to replication up to the CAS and back down again to the other child primary sites in the hierarchy. Chapter 5, “Network Design,” and Chapter 14 cover content replication in more detail.