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

Integration Guide for Disaster Recovery for Dell

Introduction

Disaster Recovery (DR) for Dell PowerScale integrates with external systems in several ways: forwarding DR alarms to SIEM and syslog platforms, exposing failover status and control through a REST API for automation and orchestration, and supporting application-tier failover patterns built on that API. This guide summarizes the currently documented DR-specific integration points.

Alarm Forwarding and SIEM Integration

DR alarms (alarm code prefix SCA) can be forwarded to an external syslog server or SIEM using Eyeglass's syslog-ng based alarm forwarding, with filtering by severity, alarm code, or application prefix.

note

SNMP alarm forwarding has been deprecated as of release 2.5.8.1. Syslog and the REST API are the supported forwarding/integration methods for DR alarms.

For full configuration steps, filtering examples, and a sample forwarded DR failover alarm, see Monitoring and Alerts.

Application Failover Integration (DR API)

Eyeglass exposes DR failover status and control through a REST API, allowing application-tier automation to check readiness and initiate or monitor a failover without using the Failover Wizard UI. Documented DR API capabilities include:

  • Path-based failover initiation via secure remote command execution.
  • Readiness status retrieval for Access Zones, IP Pools, DFS type, and SyncIQ policies (using a readiness flag on policy, pool, and zone API calls).
  • Initiating and monitoring failover tasks programmatically.

This is the basis for autonomous, application-driven failover patterns, where an application or load-balancer tier (for example, a web server behind a load balancer) uses the DR API together with email notifications to detect a storage-access failure, confirm DR readiness, and trigger failover automatically without manual intervention.

info

For the complete DR REST API reference, see the API Guide. For the full application-tier autonomous failover walkthrough, see Autonomous Failover Patterns.

Automation and Orchestration

DR administrative and failover operations can be scripted using the igls CLI over SSH (for example, enabling/disabling configuration replication schedules, running readiness or inventory reports on demand, and triggering test alarms), in addition to the REST API described above. This allows DR operational tasks to be incorporated into external automation/orchestration tooling rather than performed only through the Eyeglass Web UI.

Related igls CLI usage is documented alongside the specific operations it supports — see Appliance Check and Cluster Check for reporting and diagnostic commands, and Script Engine for scripting pre-failover, unified, and post-failover automation tasks.

External orchestration platforms can also drive a DR failover through the REST API — for example, VMware Site Recovery Manager (SRM) can call the Eyeglass API from a recovery plan step. See VMware SRM Integrated Failover Example in the API Guide.

ServiceNow CMDB Integration for DR Protection Status

Eyeglass inventory data for PowerScale SMB shares and NFS exports can be imported into a ServiceNow Configuration Management Database (CMDB) on a schedule, and used to build ServiceNow Application Services that display the DR protection status of each share and export.

note

This integration involves third-party software (ServiceNow) and is documented on a best-effort basis without a service level agreement on response time. Support for the ServiceNow platform itself requires a separate support contract with that vendor.

Protection Status Values

Each SMB share or NFS export Configuration Item (CI) exposes a protection status property with one of three values:

StatusDescription
UnprotectedThe share/export is not protected — its data is not replicated by a SyncIQ policy, or its configuration is not replicated by an Eyeglass Configuration Replication job.
ActiveThe share/export is protected and is the active (read/write) copy of the data.
BackupThe share/export is protected and is the backup, replicated (read-only) copy of the data.

The status updates automatically as DR-relevant events occur:

  • When a SyncIQ policy and its Eyeglass Configuration Replication job are configured to protect a share/export, its status changes from Unprotected to Active, and a corresponding CI with a Backup status is created for the target cluster.
  • When a failover moves the active copy from the source to the target cluster, the source share/export status changes from Active to Backup, and the target share/export status changes from Backup to Active.

Status changes are reflected in ServiceNow after the scheduled Eyeglass inventory job runs and the corresponding ServiceNow transform job processes the updated inventory.

Configuration Overview

Setting up the Application Service dashboard involves:

  1. Creating CMDB groups in ServiceNow for the SMB share and NFS export CIs of each PowerScale cluster, using encoded queries to select the relevant CIs.
  2. Creating an Application Service per PowerScale cluster CI.
  3. Creating an Application Service for SMB shares from the corresponding dynamic CI group.
  4. Creating an Application Service for NFS exports from the corresponding dynamic CI group.
  5. Adding the SMB share and NFS export Application Services to the PowerScale cluster's Application Service map, and approving the resulting service map.

Once configured, the Application Service map view for a PowerScale cluster displays the current protection status (Unprotected, Active, or Backup) for each share and export, and updates automatically as failovers occur.

External Monitoring

External monitoring systems can consume DR health and readiness information in two ways:

  • Syslog/SIEM — by subscribing to forwarded DR alarms as described above.
  • REST API polling — by querying the DR API's readiness endpoints to build external dashboards that monitor the readiness of policies, Access Zones, or entire clusters, in any language that supports REST calls.

See Also