Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 4.4.0

Configure Replication Relationship Failover

Introduction​

A Replication Relationship pairs a source path on one Qumulo cluster with a target path on another, and is the atomic unit Eyeglass uses for both configuration replication and failover (see Qumulo Failover Overview). This guide covers verifying failover readiness, executing a failover of a Replication Relationship, and the steps required after failover completes.

Verify Failover Readiness​

Eyeglass runs a readiness check against your Qumulo replication relationships approximately every 5 minutes. Open the DR Dashboard and go to the Replication Relationship Readiness tab to review current status.

For each relationship, the dashboard lists the source and target clusters, the time of the last successful readiness check, and a DR Failover Status of OK or a warning/error state.

Execute a Failover​

Failover of a Replication Relationship follows the same guided workflow as any other platform — see Execute Failover with DR Assistant for the full walkthrough (failover options, support policy acknowledgment, and monitoring). For Qumulo, the object-selection step lists your Replication Relationships (with source, destination, last readiness check, and status) so you can pick which one(s) to fail over.

Post-Failover Checklist​

Once a failover completes, work through the following before considering the target cluster ready to serve data.

Replication Relationship Status​

  • On the source cluster, check the replication status of the relationship.
  • On the target cluster, confirm a Replication Relationship has been created with the original replication schedule.

DNS​

  • Update any DNS A records that pointed to the source cluster so they point to the target cluster instead.
  • CNAMEs that point to those A records do not need to be updated, as long as the underlying A record has been updated.

Active Directory​

If your environment relies on DNS names (rather than direct IPs) for client access, HOST Service Principal Names (SPNs) must be moved manually:

  • Move the HOST SPNs from the source cluster's computer object to the target cluster's computer object. This can be done using the Windows ADSIEdit tool.
  • Move both the short-form SPN (for example, HOST/cluster-name) and the long-form SPN (for example, HOST/cluster-name.domain.com).

Data Access Testing​

  • Ping and nslookup the DNS name to confirm it now resolves to an IP on the target cluster.
  • NFS exports: clients must unmount and remount the export.
  • SMB shares: clients can regain access by rebooting the client machine, logging out and back in, or unmounting and remounting the share.

If data access testing surfaces issues, raise them through your open failover support ticket.

Core Agent Appliance (Eyeglass) Verification​

  • In the Jobs window, go to Job Definitions and confirm the target cluster's Replication Relationships are present with a green OK status.
  • In the DR Dashboard, go to Replication Relationship Readiness and confirm the same relationships are present and green on the target cluster.

See Also​