DR Automation

DR Product Specification

• Use of this document
• Overview
• Terms
• Functional Specification Description

Use of this document

This document is the functional specification definition of the product's functionality, including what the product can do, what it cannot do,  operating instructions and functional use cases describing how it works.

Overview

The DR product automates failover steps, reports on replication, cluster configuration,  syncs critical configuration between clusters to smb, nfs shares, quotas, snapshot schedules, access zones, nfs aliases, and dedupe settings.      Automated failover testing features,  closed network DR testing features, data migration, controlled and unplanned failover modes.   4 failover modes access zonem ip pool, DFS based, or synciq policy failover.    Each offers automation and granularity of data to failover.  Advanced options on how to sync configuration and scheduling of sync and DR readiness analysis jobs and cluster inventory.   A report engine also has scheduled jobs along with AD SId to user and group collection tasks.  

Terms

1. Eyeglass GUI - User monitoring, alarms and user interface to interact with product configuration and threats raised.

2. ECA VM’s  -  These are VM that process audit data and determine threats to production data.

Functional Specification Description

1. Dependencies 

   1. Cluster REST API

   2. SSH access to cluster CLI

   3. NTP

   4. AD is responsible by the cluster

   5. DNS

   6. VMware , hyper-v, RHEL (extra license required not included in base license)

2. Installation

   1. This product is recommended to be configured by professional services for complex DR requirements.

3. Functional Description

   1. Sync critical configuration data

      1. Shares

      2. Exports

      3. Nfs aliases

      4. Quotas

      5. Snapshot schedules

      6. Dedupe settings

      7. Access zone user mappings

      8. Access zones

   2. Automates the following failover steps

      1. AD spn’s

      2. Smartconnect and aliases

      3. DNS redirection

      4. Shares, exports

      5. Quotas

      6. DFS shares

      7. Synciq steps

         1. Run policy

         2. Allow writes

         3. Resync prep

         4. Run mirror

      8. Customer host scripts pre, post or unified scripts

      9. Logging and retry of key steps

      10. Phased failover log

      11. Parallel failover 

      12. Failover modes

          1. Zone

          2. Policy

          3. Dfs

          4. Ip pool

      13. Types of failover

          1. Full failover

          2. Rehearsal partial failover production stays online

      14. Options for failovers

          1. Data synchronization

          2. Config replication

          3. Data integrity on source 

          4. Disable resync step

          5. Disable policy post failover

          6. Quota optional

          7. Warning override

      15. Automation

          1. Automated failover mode on schedule with data create validation step

          2. 3rd copy access zone cloned data testing mode

      16. Reporting

          1. Cluster report of configuration including diff feature to compare

          2. RPO report synciq 24 hour 30 and 60 day trending

          3. Ondemand reporting

          4. Automated reports

      17. Alarms

          1. Email

          2. Webhook

          3. Syslog

          4. Snmp

          5. Twitter

      18. Data migration

          1. Data plus configuration between access zones or clusters for data migration to new clusters or between zones

      19. Sync options for config

          1. Sync always

          2. Skip configuration

          3. Hide shares

          4. Change prefix on shares

          5. Change pool mapping prefix name

      20. Diagnostics

          1. Builtin log parsing

          2. Lights out logs

      21. Patching

          1. Auto matching OS

      22. Security

          1. Encrypted all credentials with aes256

          2. Allow signed certificates

          3. No root process ownership

          4. Sudo only to root

          5. Random root password per appliance

          6. Random encryption keys

          7. RBAC

          8. Hardening options for TLS and http headers

          9. OS firewall

          10. Os proxy support

      23. Remote support

          1. Phonehome option with opt in

          2. Outbound ports only over 443 https

          3. Encrypt in flight and at rest 

          4. Auto purge support data

      24. 
          

4. Operational Expectations for all deployments

   1. Run the latest release for all planned failovers.  Recent releases address known issues in failover and prevent more scenarios

   2. Follow all operating procedures or you can risk data loss scenarios, understand data loss is possible in all failover modes

   3. Ensure all sizing guidelines are for memory cpu and disk are at or above published requirements, if not followed product functionality will be impaired 

   4. Understand that data loss is expected when not stopping user application IO before starting a failover

   5. Review all release notes

   6. Follow all operational and planning guides

   7. Deploy warm standby eyeglass appliance to create off site backup of appliance backup

   8. Practice failover with runbook robot feature

   9. Train any new staff with free hands on training on supernaeyeglass.com

   10. Read all pre failover planning guides, checklists and practise data access guides for windows and links

   11. Always have SME for AD, DNS, OS, networking/firewall, cluster administrator and application teams available during failover

   12. Remaining logged into the support site for rapid support

   13. Monitor alarms daily and act on them to resolution for DR readiness

   14. Local users are not synced by design due to passwords (affects ACL’s and SMB shares with local users,  DR requiures AD security in place.

   15. No failover time is guaranteed due to external factors to the product

   16. Data access is a mandatory requirement post failover to be carried out by application or NAS administrator.

   17. Failover errors may require manual steps to be executed by customers,  if api calls fail it is design intent for manual steps to recover as provided by support.  Customers must have the required administrative access to complete these steps.

   18. If an uncontrolled failover is executed, recovery back to a normal working state is expected to be a manual custom procedure demanding on the nature of the failure.  Not all recovery options are documented.

   19. The product attempts to detect many pre-failover conditions. It is expected that many more conditions exist that will or could affect failover operations and this is expected.  Customers should plan on a recovery plan if failover does not execute as planned.

   20. After failover successful data access has many external dependencies some of which are AD, vmware, hosts, networking, firewalls, DNS, NTP.  If all post failover access dependencies are not available data access outage will occur. This is external to the product and is a customer planning requirement.