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

Technical Advisories for Disaster Recovery for Dell

Introduction​

This page summarizes currently relevant technical advisories for Superna Disaster Recovery (DR) Edition for Dell PowerScale. Advisories tied to product releases that are no longer supported are not reproduced here; contact Superna Support if you need historical advisory detail for an end-of-support release.

note

Advisories for the shared Eyeglass appliance OS, Log4j, and ECA/Vault Agent components — which also apply to Data Security and AirGap — are documented centrally on Appliance & Security Advisories rather than repeated here.

Failover and Replication Advisories​

Duplicate Exports Created on Target Cluster (1.5.0/1.5.1)​

An issue in releases 1.5.0 and 1.5.1 could create duplicate exports on the target cluster under certain conditions, such as poor connectivity between Eyeglass and the PowerScale cluster. This did not affect release 1.4.8. Installations using exports should not run 1.5.0 or 1.5.1. Resolved in 1.5.2.

Incomplete PowerScale PAPI Response May Delete Configuration Objects​

If the PowerScale PAPI becomes unresponsive while Eyeglass is collecting configuration data (for example, returning 503 Service Unavailable), Eyeglass may see an empty inventory for the objects it could not retrieve. If this occurs during a scheduled Configuration Replication cycle, it can result in deletion of configuration objects (such as NFS exports or SMB shares) on the target cluster — a subsequent cycle with a correct PAPI response recreates them. If it occurs during an assisted failover, it can result in deletion of missing configuration objects on both clusters, since the target cluster becomes the active cluster after failover. Current releases include defensive code that guards against this condition; if you are planning a controlled failover on an older release, confirm you are running at least 1.5.4 or later, which blocks PowerScale PAPI errors from impacting a successful failover.

Set SyncIQ Policies to Manual Schedule Before Failover​

Follow Dell best practice and set SyncIQ policies to manual schedule before any failover: a sync job and a failover job cannot run simultaneously, and a scheduled sync running during failover will cause the failover attempt to fail. In release 1.6, a window existed where scheduled policies did not have their schedule removed in time to prevent this; this was resolved in 1.6.3, which caches and removes schedules at the start of a failover and reapplies them at the end.

Open Files Detection Limited to the System Access Zone​

The OneFS open-files API used by DR Assistant (the pre-2.15.0 name for today's Failover Wizard) to display open files only returns files open in the System Access Zone. Other Access Zones with open files are not returned, so the open-files list in DR Assistant cannot be relied on to determine open files in non-System Access Zones. No OneFS fix is available for this limitation; the feature was removed as of release 1.8.1 with no planned replacement.

PowerScale CSRF Authentication Requires SSIP Instead of FQDN/SmartConnect​

PowerScale does not support multi-node cluster-aware CSRF sessions for authentication and is not compatible with a cluster added to Eyeglass by SmartConnect FQDN — this is a known limitation of PowerScale's CSRF implementation, not a Superna defect. Supporting CSRF on PowerScale requires settings that disable basic HTTPS authentication in favor of session-token authentication, which in turn requires Eyeglass to reach the cluster using the SSIP (the static per-node IP in the management/system Access Zone) rather than an FQDN. There is no functional impact if a cluster was already added by SSIP — this only affects clusters still added by FQDN.

If a cluster was added to Eyeglass by FQDN (check via Inventory → right-click the cluster → Edit), migrate it to SSIP:

  1. Open the Jobs window and record the current state (enabled/disabled) of every job for the affected cluster in every section — you'll need this to restore configuration afterward.
  2. Right-click the cluster in Inventory and select Delete.
  3. Re-add the cluster using its SSIP (not FQDN) in the system Access Zone, with the same Eyeglass service account credentials. If migrating multiple clusters, add them all before submitting the inventory job.
  4. Open Jobs → Running Jobs and wait for the initial inventory job to complete.
  5. On the Job Definition tab, re-enable all jobs to match the state you recorded in step 1 — including re-enabling DFS mode if it was in use. Use bulk actions to re-enable multiple jobs at once.
  6. Wait 5 minutes, then confirm all jobs show green. Open a support case if any job shows an error.

Uncontrolled Failover Fails When a Cluster Is Added by FQDN​

Affects releases earlier than 1.8.1. If a PowerScale cluster was added to Eyeglass using its FQDN, an uncontrolled failover attempted while the source cluster is unreachable fails with an error similar to "Cannot find associated source network element for zone." Upgrade to 1.8.1 or later, which resolves this. As a workaround on earlier releases, edit /etc/hosts on the Eyeglass appliance before the uncontrolled failover to add a static entry resolving the source cluster's FQDN to a node IP from the subnet where that FQDN is provisioned.

DR Dashboard Failed Over Status Display Issue (1.9, 1.9.1)​

On releases 1.9 and 1.9.1, the DR Dashboard's Zone Readiness view may not show the Failed Over status for the currently inactive cluster. This is a display issue only — it does not affect the ability to fail over from the active cluster, and it is not possible to initiate a failover from the inactive cluster regardless. Policy Readiness and DFS Readiness views correctly display the Failed Over status in the interim; you can also confirm the active cluster for a given policy from those views. Resolved in release 1.9.2.

Config Sync May Skip Steps on Error​

Affects releases newer than 1.9.4. If an object cannot be synced during Configuration Replication, remaining objects in that sync cycle are not attempted, which can leave SMB shares and exports unsynced to the DR cluster. Clearing the underlying error allows all pending changes to sync successfully on the next cycle. Resolved in release 2.5.3; a patch was also made available for 2.5.2.

SMB Data Integrity Corner Case Can Leave Deny-Everyone Permission on Shares​

Normal configuration sync runs every 5 minutes and, in a rare corner case, may detect and replicate the Deny-Everyone permission used by the SMB Data Integrity failover feature to the DR cluster before that deny is removed by the failover process. If this occurs, some SMB shares may be left with a Deny-Everyone permission blocking access after failover — remove the permission manually on the affected shares to resolve it. To avoid the corner case when using SMB Data Integrity, disable the Configuration Replication job before failover (igls admin schedules set --id Replication --enabled false) and re-enable it after failover completes. Resolved in build 2.5.4-18275 and later.

Failover Scenarios That Can Delay Step Execution (2.5.6 Patch 1)​

Certain scenarios can cause a timeout-related delay before a failover job begins executing its steps. Addressed in the 2.5.6 Patch 1 release — upgrade using the standard offline upgrade procedure, or open a support case for assistance.

Config Only Migration Job Deletes Shares and Exports on the Destination Access Zone​

In release 2.5.6 build 84 and earlier, a Config Only Migration job runs in mirror mode by default, which removes any configuration data on the destination path that overlaps or does not match the source — including shares or exports you may have manually recreated to work around this. A later patch changes the default to merge mode, which preserves existing destination configuration and copies only new configuration from the source. Because a Config Only Migration job runs on the regular Configuration Replication cycle, delete the job if you are affected by this issue rather than leaving it enabled, since it will re-delete recreated shares/exports on its next run.

OneFS Fails to Create Quotas With Corrupt Source Configuration​

During failover, a quota with corrupt or invalid configuration on the source cluster (for example, a quota with both Advisory and Advisory Threshold percentage set) is blocked by OneFS from being created on the target cluster, and appears as a quota error in the Eyeglass failover log. Contact Dell for troubleshooting the corrupt quota configuration on the source cluster. OneFS RUP 9.2.1.22 or OneFS 9.4.0.13 and later include a disabled-by-default workaround: after applying the patch or upgrading, run isi_gconfig -t quota-config pscale_135273_chicken_switch=true as root and restart the PAPI process on all nodes.

OneFS isi status Command May Fail to Release RAM​

Eyeglass periodically runs the OneFS isi status CLI command on a schedule to collect per-node usage data. A OneFS bug can cause this command to fail to exit and release memory cleanly, which — because Eyeglass calls it repeatedly — can progressively consume additional RAM on PowerScale nodes over time. There is no loss of DR functionality if you apply the workaround below; you may see an alarm about incomplete CLI data in the interim, which can be ignored.

To prevent this, disable the two isi status sudoers entries used by Eyeglass:

  1. SSH to the PowerScale cluster as an administrative user.

  2. Edit the sudoers file: isi_visudo.

  3. Comment out (prefix with #) these two lines:

    eyeglass ALL=(ALL) NOPASSWD: /usr/bin/isi_for_array isi status*
    eyeglass ALL=(ALL) NOPASSWD: /usr/bin/isi status*

  4. Save and exit (:wq).

Wait for Quota Scan Jobs Before Failover or Failback​

PowerScale starts a quota scan job as soon as a quota is created, and this cannot be disabled. The Resync Prep step of a failover or failback fails while a quota scan job is active on a path on the target cluster, because the scan holds a domain lock. Eyeglass also creates quotas on the target cluster during failover, which starts a quota scan. If you attempt a failback immediately after a failover (typically only in testing), Resync Prep is blocked until the scan completes. Quotas with snapshot overhead enabled can also trigger a scan when a snapshot is deleted.

  • Do not add or edit quotas before or during a failover.
  • Before you start a failover or failback, verify in the PowerScale running jobs list that no quota scan job is active, and wait for any active scan to complete.

Partial Share Rename Failures During DFS Failover​

DFS type failover renames the SMB shares for all policies in the failover by using parallel threads. The failover result depends on how many renames fail:

  • If the share rename fails for all of the shares from a cluster, the failover status is Error. The failover stops, users are not redirected to the target cluster, Make Writable and Resync Prep do not run, and the data remains active on the source cluster.
  • If the share rename fails for only some of the shares from the source cluster, the failover status is Warning and the failover continues to run Make Writable and Resync Prep.

If only some renames fail, let the failover continue and correct the failed shares afterward. If all renames fail, stop and resolve the cause before you retry the failover.

Access Zone Failover Networking Rollback​

During the Make Writable step of an Access Zone failover, Eyeglass has already failed over SmartConnect networking and SPNs, so dual delegation means the target cluster now handles new mount requests and SPN authentication. What happens next depends on how many policies in the Access Zone succeed at Make Writable:

  • If at least one policy succeeds, the failover continues. You are partially failed over: some of the data in the Access Zone is writable on the target cluster, and all networking and SPNs are failed over. Resolve the policies that failed Make Writable so their file systems become writable. This often requires a Dell support request to resolve the root cause on the target cluster.
  • If none of the policies succeed, Eyeglass automatically rolls back SmartConnect networking and SPNs to the source cluster, the failover is aborted, and all data remains writable on the source cluster.

To confirm a rollback, look for a Networking Updates Rollback step in the failover log, such as INFO Starting Step: "Networking Updates Rollback". Then validate access to the source cluster:

  1. Run nslookup against each SmartConnect name involved in the failover (the failover log lists them). The IP address returned must belong to the source cluster.
  2. Mount a share and an NFS export from the source cluster and verify that you can write to them. This also validates SPN authentication for the shares.
  3. Determine the root cause, which might require a Dell support request, before you reschedule the failover.

User Quota Creation Fails With Multiple Unjoined AD Domains​

If the PowerScale cluster uses multiple Active Directory domains that are not joined to each other, user quota creation fails during failover for quotas that belong to the non-default AD domain. The error is Requested persona was not of user or group type. There is no workaround in Eyeglass. See Run Quota Jobs Now — Failover Recovery Steps for how to recover quotas that did not fail over.

Time to Complete Make Writable and Resync Prep Is Not Predictable​

The time needed for the failover steps that make data writable and prepare for failback (Resync Prep) can be long in some environments, depending on the number of files and directories and other factors. The duration is not predictable or deterministic, so plan the failover window accordingly.

SyncIQ File Filters Are Not Synced​

File pattern filters are not synced on failover. These pattern filters can result in unprotected data during failover and failback. Failover and failback workflows require customer testing for their own use case. All file filter scenarios are untested, and custom workflows related to file filters are not supported; the failover and failback issue is not present under the normal failover and failback workflow.

Snapshot Schedule Expiration Offset Adds Extra Time (Release 1.6.3 and Later)​

The OneFS API has a bug in the snapshot schedule expiration offset that adds extra time when the snapshot schedule is created. This results in an expiration on the DR cluster that can be greater than the value entered on the source cluster. For example, a snapshot set to expire in 20 days expires in 22 days on the target cluster. Different units of offset all result in a value greater than the one entered. After failover, the DR (target) cluster value is synced back to the source (production) cluster, so the original expiration offset is lost and the expiration time is extended by a new offset from the API error.

Workaround:

  • Before failover, make sure a cluster report has been generated (see RPO Trending and Reporting), or that an existing emailed cluster report exists. After failover, re-enter the original values on the DR snapshot schedules, using the cluster report values from the source cluster as a reference.
  • Alternatively, if this workaround does not meet your needs to preserve the expiration of snapshot settings, disable the Snapshot Sync jobs in the Jobs window.

SPNs Not Updated During Failover for a Non-Default Groupnet AD Provider (T3848)​

When OneFS 8 is configured with more than one groupnet and a different AD provider in each groupnet, the SPN update during failover does not succeed for non-default groupnet AD providers. The SPNs are not deleted for the source cluster and are not created for the target cluster, yet the failover log indicates success. This is caused by a OneFS 8 defect with multiple AD providers. SPN delete and create for the AD provider defined in groupnet0 is successful.

Workaround: Manually delete and create the SPN for the SmartConnect zones that were moved, using the AD ADSI Edit interface.

SPN Validations for Zone Readiness and Pool Readiness Do Not Check Case​

The Zone Readiness and Pool Readiness SPN validations do not check for the following conditions, which cause SPN delete and create to fail during a failover:

  • The SPN was created in AD with a lower case host (for example, host/SPN_name) instead of upper case HOST (for example, HOST/SPN_name).
  • The SPN was created in AD with an SPN name whose case differs from the associated SmartConnect zone name (for example, for the SmartConnect zone prod.example.com, the SPN is configured as HOST/Prod.Example.com).

Workaround: Modify any SPN in AD that has these issues so that all SPNs use upper case HOST in the SPN definition (HOST/SPN_name) and the SPN name matches the case of the SmartConnect zone name.

Support Entitlement and N-2 Releases​

Not upgrading to the latest release affects your entitlement to support for a planned failover event. This excludes real DR failovers. If you plan a failover and want an Eyeglass DR readiness assessment, 7 days of advance notice and submitted support logs are required.

If your Eyeglass installation is N-2 releases behind, where N is the currently published GA release, you may stay on an N-2 release without affecting support only if you complete the following steps:

  1. Open a case with Superna Support and upload support logs.
  2. State in the case that the planned failover will use a release that is within N-2.
  3. State in the case that the failover features of release N have been reviewed.
  4. Confirm in the case that the failover section of the release notes for N, N-1, and N-2 has been reviewed, and that you accept the risk in your environment.

Failure to complete these steps affects your support entitlement for using an N-2 release for a planned failover. See Upgrade Guide for the related planned-failover support policy.

Security Advisories​

Eyeglass REST API Unauthenticated Access​

Affected an API token authentication check on Eyeglass DR, Ransomware Defender, Easy Auditor, and Performance Auditor builds from 2.5.9-22219 through 2.5.11-23110: a request using a token that did not match any authorized token could still reach REST API routes. There was no risk to data on PowerScale or to any Eyeglass product configuration. The issue is resolved in build 2.5.11-23111 and later. If you are running an affected build, upgrade to a current release.

Vulnerable OpenSSH Version (CVE-2024-6409)​

A vulnerable OpenSSH package has been identified on appliance OpenSUSE versions older than 15.4. If your Eyeglass appliance OS is older than 15.5, upgrade the appliance OS to 15.5 or later.

Docker AuthZ Plugin Regression (CVE-2024-41110)​

This vulnerability applies only to environments using the Docker AuthZ plugin. Superna DR Edition does not use this plugin and is not affected.

Grafana Vulnerabilities (CVE-2024-1442, CVE-2024-1313)​

Per Grafana's own advisories, these vulnerabilities do not affect Grafana version 11, which is the version used in current Superna products.

xz/liblzma Supply Chain Vulnerability (CVE-2024-3094)​

Superna appliances use packages from the openSUSE Leap distribution, which was not affected by this supply-chain compromise.

openSUSE Security Vulnerabilities (CVE-2024-21626, CVE-2024-23651, CVE-2024-23652, CVE-2024-23653)​

These vulnerabilities affect openSUSE 15.4 and earlier. Upgrade the appliance OS to 15.5 or later and apply current OS patches.

tip

The appliance defaults to weekly automatic critical patches and security updates when it has internet access. Confirm your appliance OS version and patch level regularly, and prioritize the OS upgrade recommendations above if your appliance is running an older openSUSE release.

See Also​

  • Release Notes – Version history, compatibility matrices, and upgrade-relevant known issues.
  • Upgrade Guide – Upgrade considerations for Superna DR Edition.