The PCA application makes use of several different types of Server Groups, as defined in Table 1.
| Server Type | Server Group Function Name | Level |
|---|---|---|
| Diameter MP servers | DSR (multi-active cluster) | MP |
| SBR(S) and SBR(B) servers | SBR | MP |
| IPFE | IP Front End | MP |
| OAM server | DSR (active/standby pair) | NOAM, SOAM |
Server Groups with the “SBR” function type host either or both of the Policy Binding and Policy and Charging Session databases. The type of database hosted by a given Server Group depends on the Resource Domain or Domains with which the Server Group is associated.
Each SBR Server Group consists of one to four servers, depending on the type of deployment. Table 2 describes the supported configurations for SBR Server Groups. See Redundancy for details on policy data redundancy.
| # of Servers | Redundancy | Typical Use |
|---|---|---|
| 1 | Active only. No Redundancy. | Labs and demos only. |
| 2 | Active/Standby. Server redundancy within a Site. | Single-site deployments or deployments not requiring Site redundancy. |
| 3 | Active/Standby/Spare | Mated Pair deployments to avoid a single-server failure from causing Session access requests to be routed to the mate Site. This is the target for large deployments. New sessions are equally distributed across all Session SBR Server Groups in the mated pair, meaning that ~50% of the Session accesses will be routed across the WAN. Note: SBR Server Groups must be configured with two WAN replication
channels.
|
| 4 | Active/Standby/Spare/Spare | Mated Triplet deployments where service is kept alive even two of the three sites with the service are down. |
Because only the active server in a SBR Server Group is actually processing Stack Events, a SBR Server Group can be engineered to run at 80% of maximum capacity. This holds for Site failure as well since the Spare server at the mate site will take over.
For PCA, all of the DA-MPs at a Site (even if there is only one) must be included in one Server Group with the DSR (multi-active cluster) function type. This eliminates the need to have all clients and PCRFs/OCSs connected to every DA-MP.
The DA-MP servers in the Server Group will be treated as a cluster of active servers. There should be at least two DA- MP servers in the Server Group in order to support in-service maintenance or upgrade. The DA- MP servers in a Server Group should be engineered such that loss of a single server will not cause the remaining servers to go into overload.
If the PCA is being deployed in mated pairs, the DA- MP servers at one site need to be configured to handle the entire load of the other site (in case of a site failure) without causing the surviving DA-MPs to go into overload – typically 40% of engineered capacity.