Resilient Package Deployment

Starting 4.0.0, the resilient package is introduced in DSG for a fault-tolerant approach to deploying data protection policies and configurations. It ensures policies and configurations are reliably delivered across systems and networks.

The following are the some parts in the Resilient Package architecture for DSG.

• Policy and the DSG configurations that are combined to form a Resilient Package.

• Resilient Package Proxy (RPP) on DSG and ESA that acts a single point of communication. This caches the resilient package.

• Resilient Package Service (RPS) on ESA that is responsible for communicating updates related to policy and DSG configuration.

The following figure illustrates the flow of communication that occurs between DSG and ESA to check for the policy and DSG configuration updates.

1 - The gateway processes in the DSG reach out to RPP on DSG to check for updates related to the policy or DSG configuration.

2 - Through the RPP, DSG periodically connects with ESA to check for the updated resilient package.

3 - The RPP on ESA in turn checks with the RPS for updates.

4 - The RPS connects for resilient package updates.

The following figure illustrates the flow of information after the policy or DSG configuration is updated.

1 - The policy is deployed and ready to be utilized.

2 - The DSG configurations are ready.

3 - The RPS pulls the updated policy and CoP that are ready to be utilized. It then creates a package in a JSON format that contains both the policy and DSG configuration information. The package is then pulled by the RPP on ESA.

4 - The RPP on ESA caches this package, which is then pulled by the RPP on DSG after a scheduled time interval.

5 - The RPP on DSG caches this package. The package is extracted such that the policy is loaded in the memory of the processes and the DSG configuration is stored on the disk.

If the DSG configuration is updated, the gateway processes restart for the changes to take effect.