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: 2.15.0

ECA Cluster Disaster Recovery and Failover Supported Configurations

Introduction​

If you also run Ransomware Defender, Easy Auditor, or Performance Auditor, those products depend on an Eyeglass Clustered Agent (ECA) cluster to ingest audit data from the PowerScale cluster they protect. This article covers how the ECA cluster relates to a PowerScale Disaster Recovery failover — what configurations are supported, and what to reconfigure on the ECA cluster after a failover so audit ingestion continues against the newly-active cluster.

note

This is a cross-product topic: the PowerScale failover itself is a Disaster Recovery function, but the ECA cluster and the products built on it (Ransomware Defender, Easy Auditor, Performance Auditor) are documented in Data Security. This article covers only the DR-relevant reconfiguration steps.

Unsupported ECA High-Availability Configurations​

  • Two different ECA clusters cannot share the same Eyeglass appliance.
  • An ECA cluster cannot be stretched across two data centers. An ECA cluster is designed as a local cluster with load balancing and local node failover, not as a stretched cluster tolerating a full site failure. Warm Standby (below) is the only supported approach for ECA high availability across sites.

Prerequisites for Both Scenarios​

Before either scenario below can work, complete the following on the DR cluster and DR site (see the Data Security ECA installation guide for full steps):

  • If using a Warm Standby ECA cluster, it must have the same VM count as the production-site ECA cluster.
  • The audit database has been synchronized to the DR site's Access Zone (protect it with SyncIQ, following the audit database DR protection guide).
  • An IP pool with at least three nodes exists in the Access Zone to receive HDFS I/O from the ECA cluster, with a SmartConnect name created for HDFS access.
  • SmartConnect DNS delegation is configured for the HDFS Access Zone in your DNS infrastructure.
  • The OneFS HDFS license is applied to the failover target cluster for the audit database.
  • All required firewall ports are open between the ECA cluster and the failover target cluster.
  • A System Zone NFS export exists with the Warm Standby ECA cluster's IP addresses, for the ECA cluster to mount and ingest audit data.
  • SmartConnect DNS delegation is configured for NFS access in the System Zone.
  • The ECA mount path is prepared using the target cluster's name (case-sensitive) and cluster GUID.
  • The DR cluster's local Hadoop user for the HDFS database uses the same UID as the production cluster's HDFS user, and the HDFS data folder permissions and ownership are set to match.

Scenario 1: ECA Cluster Stays at the Production Site (Longer RTO)​

In this scenario, the PowerScale cluster fails over to the DR site, but the ECA cluster itself remains at the production site and is reconfigured to ingest audit data from the (now-active) DR cluster instead. This takes longer to complete than Scenario 2's Warm Standby approach.

tip

Reconfiguration assistance for this scenario can be scheduled through Superna Professional Services; it is not covered under the standard support contract.

Post-Failover Reconfiguration Steps​

  1. Enable protocol auditing on the DR cluster (OneFS Cluster Management > Auditing) and add all relevant Access Zones.

  2. Create an NFS export on the DR cluster for audit data ingestion, with a SmartConnect name and DNS delegation to the IP pool used for the NFS mount in the System Zone.

  3. Create the mount path on each ECA node using the DR cluster's name and GUID.

  4. Edit /opt/superna/eca/data/audit-nfs/auto.nfs on ECA node 1: comment out the previous mount entry and add the new SmartConnect name and mount point for the DR cluster.

  5. Push the updated configuration to all ECA nodes:

    ecactl cluster push-config

  6. Unmount the previous cluster's audit NFS export:

    ecactl cluster exec "sudo umount -a -t autofs"

  7. Remount the new cluster's audit export and restart autofs:

    ecactl cluster exec "sudo systemctl restart autofs"

    Verify the mount succeeded on each node:

    ecactl cluster exec mount | grep "ifsvar"

  8. Restart the audit ingestion service:

    ecactl cluster services restart --container turboaudit --all

  9. Reassign the Eyeglass license from the production cluster to the DR cluster in the License Manager (set the production cluster to unlicensed, then set the DR cluster to licensed).

  10. Reconfigure Security Guard and Robo Audit to test the new (DR) cluster: create a local account on the target cluster if needed, and update the automation configuration to point at the new cluster. The license reassignment in the previous step must be complete before you can select the new target cluster.

  11. Confirm SMB port access is open between Eyeglass and the new target cluster, then run Security Guard and Robo Audit from Jobs → Job Definitions and monitor them under Jobs → Runs.

Scenario 2: ECA Cluster Fails Over to a Warm Standby (Lower RTO)​

In this scenario, the production-site ECA cluster is also affected, and a pre-deployed Warm Standby ECA cluster at the DR site becomes active. This assumes the Eyeglass appliance is already at the DR site (recommended) or that its own Warm Standby has been activated.

Prerequisites to Complete Before a Failover​

  • Deploy a Warm Standby Eyeglass appliance and, if it is not already the active appliance, follow the Warm Standby procedure to activate it at the DR site.
  • Deploy a second, Warm Standby ECA cluster at the DR site, configured to use the DR-site Eyeglass appliance, following the same installation guide used for the production ECA cluster. When customizing this deployment:
    • Use the DR cluster's name and GUID for the audit data NFS mount points.
    • Edit /opt/superna/eca/eca-env-common.conf to reference the DR-site Eyeglass appliance (EYEGLASS_LOCATION) and the same API token used by the production ECA cluster (EYEGLASS_API_TOKEN).
    • Confirm the HDFS database URL (ISILON_HDFS_ROOT) uses the correct DR-site SmartConnect name and matches the production ECA cluster's path — a mismatch prevents the ECA cluster from locating the database on startup.
    • Follow the audit database DR protection guide to synchronize the audit database to the DR cluster.
    • Keep the Warm Standby ECA cluster down (ecactl cluster down) until it is actually needed.
    • Keep the Warm Standby Eyeglass and ECA appliances on the same release version as the production site.

Post-Failover Reconfiguration Steps​

  1. Shut down the production-site ECA cluster:

    ecactl cluster down

  2. Follow the audit database protection guide to make the DR cluster's database writable, running the SyncIQ policy manually first to sync any final changes. Do not proceed until the database reports healthy.

  3. Confirm in the Eyeglass Managed Services widget that all ECA VMs show green with no warnings.

  4. Reassign the Eyeglass license from the production cluster to the DR cluster in the License Manager.

  5. Reconfigure Security Guard and Robo Audit to test the new cluster, as in Scenario 1 (confirm SMB port access, update the target cluster in the automation configuration, then run and monitor both from Jobs → Job Definitions and Jobs → Runs).

See Also​

  • Failover Recovery – General failover recovery steps for the PowerScale side of a Disaster Recovery failover.
  • Post Failover Steps – Post-failover verification for DNS, SPN, SmartConnect, and client access.