Failure Tolerance

The Special Role of Central Management Point and Central Depot

The Central Management Point occupies a special role in many regards:

The central Configuration Management Database resides here; this is where all settings of the organizational tree and the software library are stored.
The Central Management Point is source and target for all configuration data of the DSM organizational data.
Management Points with applications such as the Business Logic Server and directly assigned managed computers access the Central Management Point.

The Management Point’s components may be distributed to two physical servers: The Management Point server and the database server.

The central depot occupies a special role in many regards:

This is the only point where the ICDB can be edited - settings, site structure objects, creation of repositories, etc..
The central depot serves as the source for distributing the ICDB and all repositories on ORG level.
Each Distribution Service accesses the ICDB of the central depot when it is started.
Each update to DSM binaries must emanate from the central depot.

In case the Central Management Point fails:

You can no longer open most of the DSMC’s views because the Central Management Point’s DSMDB is required!
No more changes can be made to the DSMDB in instances of the DSMC which are already running (assignments, settings, package modifications, etc.).
Managed computers that are directly assigned to the Central Management Point continue working with locally stored data.

After the failure of the central depot:

The DSMC can still be started from any other depot, but the starting procedure is very lengthy since the DSMC makes repeated attempts to access the central depot.
No more changes can be made to the infrastructure (ICDB) in instances of the DSMC which are already running.
Data which emanates from the central depot is not distributed to the subordinate depots until the central depot becomes available again.
Distribution Services that are already running when the central depot becomes unavailable will keep on running.
However, if you try to (re-) start a Distribution Service, it will not start distributing until the central depot is available again.

Like the other depots, the central depot is merely a file server. Thus, the following possibilities can be utilized:

Mirroring. The only requirement is that the two mirrored depot computers appear as a single depot computer from the “viewpoint” of the network (same name, same IP address)
Clustering
File synchronization with a non-productive standby server (e.g. with the help of Robocopy and the Windows Scheduler Service). If the “proper” ORG Master Server fails, the standby server only needs to be started under the name of the “proper” ORG Master Server.

The Central Management Point can be re-activated by re-installing and re-using the same settings.
You only have to restore the DSM Database:

Please note the vendor’s recommendations when storing and restoring the Configuration Management Database.

Failure of a Management Point:

A Management Point does not need to be backuped because it can be restored easily using the DSM infrastructure.

Failure of a depot on which the master copy of a repository is located:

Changes to packages are no longer possible until the depot becomes available again.
Please back up a depot of this type regularly and restore it, if necessary.

Failure of another depot:

If the depot is a site or region master depot, data is not distributed to the subordinate depots until the depot becomes available again.
If the depot is (also) used as a local depot within a site, managed computers can no longer execute packages from this depot. If no further depot is available within the site, managed computers in this site can no longer be used to execute packages without staging (unless a neighboring site has been defined and this site is available).
You do not necessarily have to back up a depot of this type because you can easily restore it with the help of DSM infrastructure.