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

Autonomous Application Failover Patterns

Introduction​

Beyond direct API calls, the Eyeglass DR API can serve as the automation backbone for autonomous application failover solutions, where an external monitoring component detects a storage access failure and triggers a failover without manual intervention. This article describes the DR-specific capabilities exposed through the API and two solution patterns that build on them: a basic pattern using external path monitoring, and an advanced pattern that also detects application-tier failures.

DR API Capability Overview​

The Eyeglass DR API provides the following DR-specific capabilities, in addition to the general REST mechanics described in the API Guide:

  • Path-based failover initiation: Failovers can be initiated through secure remote command execution, allowing automation to request a failover for a specific storage path.
  • DR readiness status: The API can retrieve the current DR readiness status for managed clusters and access zones.
  • Failover monitoring and reversion: The API can be used to monitor the progress of an in-flight failover task and to initiate a reversion (failback) once the primary path is restored.
note

For the specific endpoint paths, parameters, and response formats that implement these capabilities, see Endpoints.

Basic Autonomous Failover Pattern​

In this pattern, a lightweight monitoring script runs alongside the application server. The script continuously checks read/write access to the application's storage path. If it detects a loss of access, it sends a failover request to Eyeglass through the DR API.

Eyeglass then computes the required failover steps and autonomously executes the failover from the primary storage path to the synchronized failover path. Administrators and other stakeholders are notified of the event so that the primary storage path can be remediated and, when ready, failed back.

This pattern relies on two components working together:

  • An external, continuously running monitoring process that watches storage path accessibility.
  • The Eyeglass DR API, which receives the failover request and carries out the failover.

Advanced Autonomous Failover Pattern​

The advanced pattern extends the basic pattern with dual failure-plane detection: it monitors both the application front end and the storage path, and fails over both together as a single unit whenever either plane fails. Keeping the application and its storage on the same side of the failover avoids a stretched I/O pattern between an application server and storage in different data centers, which is harder to troubleshoot, degrades performance under failure, and introduces additional failure scenarios to account for.

Solution Components​

  • Eyeglass DR
  • Eyeglass API
  • A third-party load balancer
  • An email server for alarm notifications

Solution Capabilities​

  • Storage failover of NFS or SMB shares
  • IP Pool failover type (recommended)
  • Dual failure-plane detection with combined application and storage failover
  • Failover and failback logic
  • Email alarm notifications for failover decisions, status, and errors

Example: Web Server with Load Balancer​

info

Example only, not a product requirement. This scenario illustrates one way to combine a load balancer with DR API-driven storage failover; it is not the only supported configuration.

In this scenario, a third-party load balancer is configured with a globally balanced FQDN that directs traffic to a primary web server and a secondary web server, with the primary server weighted higher under normal conditions. Users access the application through the load-balanced FQDN, which is normally directed to the primary server.

A monitoring process on the primary web server continuously verifies that it can read a small checker file located on a share mounted from the primary PowerScale cluster. When the process detects repeated failures to read the checker file, it:

  1. Sends an alert email.
  2. Triggers an autonomous failover through the DR API, which fails over storage (including the SmartConnect zone) from the primary to the secondary PowerScale cluster.
  3. Triggers pre- and post-failover scripts that unmount the SMB share on both web servers before failover and remount it from the now-active cluster afterward.
  4. Disables the primary web server in the load balancer's FQDN configuration, so that traffic is directed to the secondary web server.

Once the secondary web server becomes primary, the same monitoring process runs against it, watching the checker file on the share now mounted from the secondary cluster. If a subsequent failure is detected there, the same sequence runs in reverse: storage and the SmartConnect zone fail back to the original cluster, shares are unmounted and remounted on both web servers, and the original primary web server is re-enabled in the load balancer configuration.

See Also​

Endpoints

Reference for available Eyeglass API endpoints, including job management, health checks, and disaster recovery operations.

See More