A cluster relationship synchronizes, or replicates, HTTP Federation (HFED) application sign-in credentials stored in keychain data on the source cluster, with keychain data stored on the target cluster. This enables users with credentials from the source cluster to access the same credentials on the target cluster. After synchronization, users with sign-in credentials in the source cluster have the same credentials in the target cluster.
High Availability with Source and Target Clusters
- In the event of an unplanned outage on the source cluster, service is restored automatically by switching to the target cluster. Users with identity router sessions on the source cluster are automatically prompted to sign in again, using the same credentials on the target cluster. The location of the cluster storing credentials is transparent to users.
- With geographically distributed clusters, users traveling between two locations can seamlessly access their HFED applications with the same credentials stored in both cluster locations.
- In the event of disaster, you can restore service to a source cluster by overwriting keychain data with a backup copy of user keychain data from the target cluster.
Bidirectional Synchronization Between Clusters
Unidirectional Synchronization Between Clusters
- Two peer clusters are defined—New York and London.
- Each cluster has a single identity router.
- User keychains are replicated in only one direction; New York (source cluster) to London (target cluster).
- All users can access the London cluster should the New York cluster fail.
- If the London cluster fails, however, not all users might be able to access their credentials from the New York cluster.
We want your feedback! Tell us what you think of this page.