Technical Advisories





Technical Advisory #1

For customers where the total number of objects (SMB Shares, NFS Exports, NFS Alias, Quotas) being managed by Superna Eyeglass exceeds 10,000, tasks being performed against the cluster for a large number of objects (such as creating quotas during a failover) may overwhelm the cluster such that not all tasks are completed. An adjustment to the Superna Eyeglass parallel task limit is required. Contact support.superna.net for assistance in updating Eyeglass.


Technical Advisory #2

In some environments, the memory allocated for the Superna Eyeglass database is not sufficient.  In this case Superna Eyeglass no longer functions and the Superna Eyeglass web page windows appear empty.  If you experience this issue, contact support.superna.net for assistance in updating Eyeglass to adjust the memory allocated to the database.

Update April 6, 2016:  This issue has been addressed in Eyeglass 1.5.1


Technical Advisory #3 - reissued April 20

An issue in Eyeglass Release 1.5.0 and 1.5.1 results in duplicate exports being created on the target cluster under certain conditions such as poor connectivity between Eyeglass and the Isilon cluster.  This issue will be addressed in Eyeglass 1.5.2.  This issue does not exist in Eyeglass 1.4.8.  Eyeglass installations using exports should not upgrade to Eyeglass 1.5.0 or 1.5.1.

Update April 25, 2016:  This issue has been addressed in Eyeglass 1.5.2


Technical Advisory #4 - End of Support for 1.2, 1.3, 1.4 and 1.4.x Releases

All customers running the above releases should upgrade to the latest release using upgrade guide located here.  Numerous failover and performance improvements exist in the latest  release with all new cases requiring an upgrade.


Technical Advisory #5 - Incomplete response from Isilon PAPI may result in deletion of Configuration Objects

Please be advised that we have observed instances where the Isilon Cluster PAPI used by Eyeglass to collect information becomes unresponsive such that Eyeglass requests for configuration objects are unanswered (for example 503 Service Unavailable).  This results in empty Eyeglass inventory for objects that are not retrieved.

Should this happen during scheduled Eyeglass Configuration Replication, it may result in deletion of configuration objects (such as NFS export or SMB shares) from the target cluster.  Subsequent cycle with correct response will resolve this situation by creating the configuration objects again.

Should this happen during Eyeglass assisted failover, it may result in deletion of missing configuration objects from both clusters as after the failover the target cluster with missing objects becomes the master active cluster.

The Eyeglass next release will contain defensive code to guard against deletion of configuration objects when the Isilon PAPI response is incomplete. If you are planning a controlled failover, we ask that you wait and upgrade to 1.5.4 release that blocks Isilon PAPI errors from impacting a successful failover.
Update May 13, 2016: This issue has been addressed in Eyeglass 1.5.3

Technical Advisory #6 - Set SyncIQ policies to manual schedule or longer schedule with 1.6 release or risk scheduled jobs running during failover and failing overall Eyeglass failover steps

Following EMC best practices to set SyncIQ policies to manual before any failover KB Article  as reference "NOTE: A sync job and failover job cannot run simultaneously by design and will cause the failover attempt to fail.  To avoid this condition, set all policies to manual."

Issue: Failover behaviour in 1.6 was changed that exposes the window where scheduled policies do not have their scheduled removed in time to prevent them from running in 1.6 release.  

This has been addressed in 1.6.3 by having schedules removed and cached at the beginning of the failover and reapplied at the end of the failover.  

Technical Advisory #7 - OneFS 8 BMC firmware bug API call

Please be advised that we have found new case where the BMC firmware bug API call is made under Eyeglass1.6.1 code. This issue has been observed to manifest itself after several days in operation and affects Eyeglass installations where both Isilon clusters are running OneFS 8.  We have switched to a ssh call previously reviewed by EMC and confirmed to not query any BMC APIs in 1.6.x but a left over call in some cases still called this unused API in 1.6.1.

This has been addressed in the 1.6.2 patch such that the BMC firmware bug API is removed.  We recommend this new patch release for all Eyeglass patch deployments managing OneFS 8 clusters.


Technical Advisory #8 -  End of Support for 1.5.4 Release 

Effective November 1st, 2016 release 1.5.4All customers running the above releases should upgrade to the latest release using upgrade guide located here.  Numerous failover and performance improvements exist in the latest  release with all new cases with this release requiring an upgrade as first resolution step.

Technical Advisory #9 -  Open files Detection on Isilon  

A OneFS issue with open file detection used by Eyeglass in the DR assistant to show open files, only lists files open in system access zone.  Other access zones that have open files are not returned by the ISI open files for array command.  This means customers can not rely on the open file list in DR assistant to determine open files in none system access zones.    No known fix available in any OneFS at this time. 

As of release 1.8.1 this feature has been removed with no update or planned availability of a fixed API from Dell EMC.

Technical Advisory #10 -  Uncontrolled Failover Issue when Isilon Cluster added to Eyeglass with FQDN  

Applies to release < 1.8.1 For the case where Isilon clusters have been added to Eyeglass using FQDN, uncontrolled failover for case where source cluster is not reachable does not start and gives the error ""Error performing zone failover: Cannot find associated source network element for zone".

This issue is addressed in a 1.8.1 patch.  Eyeglass installations using FQDN to add clusters must upgrade to this patch once available.

Workaround: 
Before an uncontrolled failover where the source cluster is not available, edit the /etc/hosts file on the Eyeglass appliance following the steps below:

1. ssh to the Eyeglass appliance.
2. Assume root user - when prompted for password use the admin user password
    sudo su -
3. edit the /etc/hosts file
    vi /etc/hosts
4. insert a line below the last line for the FQDN of your source cluster.  The syntax is:

Syntax: IP-Address Full-Qualified-Hostname Short-Hostname
Example: 172.16.89.45 sourcecluster.prod.superna.net source cluster

where 
  IP-Address is a node IP from the subnet pool where the source cluster FQDN is provisioned
  Full-Qualified-Hostname is the FQDN that was used to add the Source cluster to Eyeglass  

Technical Advisory #11 -  End of Support for 1.6.x Release Notice as of May 31, 2017

Effective July 30th, 2017 release 1.6.xAll customers running the above releases should upgrade to the latest release using upgrade guide located here.  Numerous failover and performance improvements exist in the latest  release with all new opened cases with this release will be asked  to upgrade before issues are addressed as a first resolution step.

Technical Advisory #12 -  DR Dashboard/Zone Readiness display issue for Failed Over Status - no loss of failover functionality

Applies to Release 1.9, 1.9.1. The DR Dashboard Zone Readiness status may not show the Failed Over status for the Cluster which is currently inactive.  This does not affect the ability to failover from the active cluster nor is it possible to initiate a failover from the inactive cluster.

Workaround:  Policy Readiness and DFS Readiness correctly display the FAILED OVER Failover Status
To determine which cluster Eyeglass considers active:
1. Login the the Eyeglass web page.
2. Open the DR Dashboard.
3. Use the Policy Readiness or DFS Readiness view to determine which cluster is active for a specific policy.
4. Then the Zone Readiness vies can be used to confirm which Access Zone that policy falls under by opening the DR Failover Status window for an Access Zone and opening the OneFS SyncIQ Readiness folder.  Here all of the SyncIQ Policies that are associated with Access Zone are listed.

This issue has been addressed in Release 1.9.2.