CMP Georedundancy

As shown in Figure 1, georedundancy is implemented for CMP clusters by pairing a primary site CMP cluster with a secondary site cluster. The active server from the Site 1 CMP cluster will continuously replicate configuration, provisioning, and policy data, using HA, to the active server of the Site 2 cluster.

CMP Georedundancy

The secondary cluster does not have to be physically close to the primary cluster. The terms primary and secondary denote roles, or states, that the servers or clusters assume, and you can change these roles manually. If the Site 1 CMP cluster goes offline (as in a disaster scenario), you would log in to the active server of the Site 2 CMP cluster and manually promote this cluster to become the primary (Site 1) CMP cluster to manage the Policy Management network.

Promotion of a CMP cluster is always a manual operation (see Promoting a Georedundant CMP Cluster for details). The preferred sequence of operation is to first demote the active CMP server at the primary site and then promote the active CMP server at the secondary site, but this is not required. For example, in a disaster-recovery scenario in which the primary site is inaccessible, you can promote the active CMP server at the secondary site immediately. (This may trigger alarms.) The servers record the timestamp when a role is assigned. Policy Management systems recognize the CMP server with the most recent promotion timestamp as the primary cluster (that is, the recognized authority).

In a georedundant topology, c-Class servers (HP ProLiant BL460c Gen8 servers with a 1x4 mezzanine card) can communicate over a dedicated backup (BKUP) network. This network is set up using the Platform Configuration utility. See the Platform Configuration User's Guide for detailed information.

Note: CMP servers do not use the replication (REP) network or Differentiated Service Code Point (DSCP) marking.