Thanks for Excellent write up on replication process of ConfigMgr in details from Terry McKinney and to Anoop for sharing this :)
=====
NOTE: Question marks (???) in the text below indicate random character generation by SMSExcec thread processing.
SMSExec thread component on source site initiates replication request
SMSExecutive thread component that is requesting data replication places the data to be replicated in replmgr.box\outbound\low OR replmgr.box\outbound\normal OR replmgr.box\outbound\ high folder. Low (3), normal (2), and high (1) specify replication priority requested by the SMSExec thread that requests replication.
Replmgr:
Replication Manager (ReplMgr) scans the three folders listed above for incoming data. Replmgr prepares the job source files by combining data files destined for replication to a given site in the \replmgr.box\process\<destinationsitecode>_<priority> folder (i.e., XYZ_2). If there are no pending replication requests to a given site that have the same replication priority, Replmgr implements steps A and B listed below. It there are pending replication requests to that site that have the same replication priority that are already scheduled for replication, data for new request(s) is held in the Replmgr.box\process\<destinationsitecode>_<priority> folder. Data for the new request(s) will remain in the Replmgr.box\process\<destinationsitecode>_<priority> folder until the pending same-priority request completes data replication OR the new replication request(s) reaches 6 hours in age. At this time, Replmgr will implement steps A and B listed below. If a replication job of the same priority and destination site is still pending, ReplMgr implements steps A and B below to create an additional same-priority replication request for that site.
A. Data to be replicated is moved to \replmgr.box\ready\<priority>_??????.<destinationsitecode> (i.e., 2_SKEJFS.XYZ). This folder is referenced in log files as the "transfer root".
B. ReplMgr then creates a .JOB file in the \Schedule.box folder.
Scheduler:
At the top of the Scheduler process loop (except on service startup) Scheduler activates any pending jobs by completing the following steps:
A. Compresses all files in the transfer root (i.e., \replmgr.box\ready\2_SKEJFS.XYZ) into a single package file and writes this file to \schedule.box\tosend\<job id>.P??.
B. Creates a destination site despooler instruction file in \schedule.box\tosend\<job id>.I?? to be transmitted immediately after the package file created in step A is transmitted.
C. Creates a send request in the \schedule.box\requests folder (<priority>_???<originatingsite>.SRQ) (i.e., 2_5ZKABC.SRQ).
D. Determines if the package and instruction file needs to be routed through an intermediate child site. If so, a routing instruction file is created (RT??????.INS) for the send request.
E. Schedules the send request by moving it into an appropriate sender outbox. Each installed sender type creates its own folder under schedule.box\outboxes. The most common sender outbox is schedule.box\outboxes\LAN.
Sender:
1. Sender transmits the package file and then the instruction file to the remote site by completing the following steps:
A. Renames the send request (<priority>_???<originatingsite>.SRQ) to (<priority>_???<originatingsite>.SRS (changes the filename extension to .SRS)
B. Transmits the package (\schedule.box\tosend\<jobid>.P??) file to the remote site Despoolr.box\receive folder (the SMS_SITE share) and renames it to <sendrequestid>.PCK
C. Transmits the accompanying instruction file (\schedule.box\tosend\<job id>.I??) to the same location and renames it to <sendrequestid>.INS
D. Flags the <priority>_???<originatingsite>.SRS file with a "sending complete" flag.
E. Creates a \schedule.box\<sendrequestid>.DWS (done with sending) file.
Replication component processing at the destination site Despoolr.box\receive folder)
Despoolr:
The Despooler process first checks the signature on the replicated files. If signed correctly, despoolr decompresses the instruction file and implements the instructions contained within that file – to decompress the package into the \replmgr.box\incoming folder in this case.
ReplMgr:
Replication Manager analyzes incoming files and replicates the objects to appropriate inbox folders. The appropriate inbox folder is specified by the component on the source site server that began the replication process. Inbound replication jobs that use transactions must bear a transaction ID that is greater than the existing number for that object type that is contained in the sitecode.trs present on the destination site. If this condition is met, the transaction is considered valid and the inbound replication objects are passed to the destination component/inbox. If this condition is not met, the transaction is considered invalid and the replication objects are discarded by Replication Manager.
Post - replication cleanup on originating site:
Scheduler:
A. Updates the corresponding job status to "complete" when it finds the \<sendrequestid>.DWS during its
processing cycle.
B. Performs cleanup - deletes the related package and instruction files in the \schedule.box\tosend folder
C. Deletes the transfer root folder (i.e., replmgr\ready\2_SKEJFS.XYZ)
D. Marks the send request for deletion
ReplMgr:
After the transfer root has been deleted, pending replication requests with the same priority and destination site that are less than 6 hours in age can be created. Note that if there are existing jobs of the same priority and with the same destination site that are older than 6 hours, ReplMgr will request scheduling an additional replication job of the same priority for replication to that site.
Scheduler:
A. Deletes completed send requests when it finds the associated <job_id>.dws file for that job during its processing cycle.
B. Deletes the completed job files (minimum cycle: once per hour, maximum cycle: once per process loop).
No comments:
Post a Comment