NRF supports Geographical Redundancy (GR) using the CDL data replication functionality between two sites. NRF deploys the Active—Standby deployment model for GR.

The Geo Redundancy feature supports the following functionality:

• The NRF pods are stateless and CDL stores all data. There is no application impact for NFProfiles or Subscription replication.

• CDL replicates NFProfiles and NF subscriptions across both sites. The NRF procedures work seamlessly in GR scenarios as CDL continuously replicates NFProfiles and Subscription Records on updation of every record. The NRF procedures include NF Registration, NF Deregistration, NF Update, NF Heartbeat, Create Subscription, Delete Subscription, Update Subscription, and Update Notification.

• NRF GR supports multi-NRF (Hierarchy) deployments, where both NRFs act as parent and child.

Note	The recommended round trip time between two CDLs must not be more than 50 msec.

For more information on CDL Data replication, see Ultra Cloud Core Common Data Layer Configuration and Administration Guide.

This section describes how this feature works.

To achieve geographical redundancy, Cisco NFs using the NRFLib component apply the configuration for Primary NRF and Secondary NRF. Non-Cisco NFs and NFs that do not use the NRFLib component should use similar mechanism to configure the NRFs in GR mode.

• If a Primary NRF is down, the consumer NFs communicate with the standby NRF to consume services.

• After the Primary NRF recovers from failure, it synchronizes data automatically from the Secondary NRF (data consistency) and vice-versa.

• Once the Primary site is up (after site recovery), the client detects the same and starts sending messages to the Primary site.

The following is an example of the CDL configuration for two sites (Site 1 and Site 2) with GR enabled between sites. In this example, the GR-specific configuration is highlighted in bold.

Site 1:

cdl system-id 1
cdl node-type session-mgr
cdl enable-geo-replication true
cdl deployment-model small
cdl zookeeper replica 1
cdl remote-site 2
 db-endpoint host 10.84.102.218
 db-endpoint port 8882
 kafka-server 10.84.102.218 10092
 exit
exit
cdl datastore session
 geo-remote-site [ 2 ]
 slice-names [ slice1 ]
 endpoint replica 1
 endpoint external-ip 10.84.17.73
 endpoint external-port 8882
 index replica 1
 index map 1
 index write-factor 1
 slot replica 1
 slot map 1
 slot write-factor 1
exit
cdl kafka replica 1
cdl kafka external-ip 10.84.17.73 10092
exit

Site 2:

cdl system-id 2
cdl enable-geo-replication true
cdl deployment-model small
cdl zookeeper replica 2
cdl remote-site 1
 db-endpoint host 10.84.17.73
 db-endpoint port 8882
 kafka-server 10.84.17.73 10092
 exit
exit
cdl datastore session
 geo-remote-site [ 1 ]
 slice-names [ slice1 ]
 endpoint replica 1
 endpoint external-ip 10.84.102.218
 endpoint external-port 8882
 index replica 1
 index map 1
 index write-factor 1
 slot replica 1
 slot map 1
 slot write-factor 1
exit
cdl kafka replica 1
cdl kafka external-ip 10.84.102.218 10092
exit

NOTES:

• If NRF receives messages from the NF consumer, it handles the message irrespective of the Active or Standby state. For example, in certain cases where NRF does not have control with the consumer NFs sending messages to NRF1 or NRF2, and if the NFs continue to send messages to NRF2 even after NRF1 is back to service, then NRF2 will continue to process the messages.

• GR supports the scenario when NRF is completely down (complete NF or site is down) or when NRF is not reachable from NF consumers.