A key principle in achieving continuous availability is reducing single points of failure and ensuring that redundant components complete failover in a nondisruptive fashion. As discussed above, SQL Server failover can be disruptive to applications and interrupt business continuity. Therefore, providing a consistent, resilient storage connection across redundant storage appliances to SQL Server and data external to SQL Server can reduce failover events and increase availability.
Dell PowerStore metro node adds a storage virtualization layer to the storage infrastructure. Once the metro node cluster is in place, storage is presented from one or more underlying arrays. From this pool of storage, virtual volumes are created in metro node. These virtual volumes have their own Logical Unit (LUN ID) and World Wide Name (WWN), which gives them their own identity and makes them unique from a host or server perspective. The virtual volume is then presented to the host and appears like any other volume. The key benefit of a virtual volume is that it provides a consistent identity and connectivity, regardless of the storage appliance on which the data resides. This allows data to move between arrays, and the creation and deletion of mirrored volumes across two arrays, without requiring any outage from an application point of view. The virtual volume can be configured for true active-active synchronous replication either locally or over metro distances with multi-site dual access. This provides zero RPO and RTO for storage.
Virtualizing the storage details behind the PowerStore metro node cluster ensures that SQL Server, or any storage consumer, has a consistent, reliable storage connection across one or more arrays. This includes PowerStore appliances, Dell arrays, or any array type supported by metro node, in one or more locations. This eliminates downtime due to data migrations, storage appliance upgrades, and unplanned failures.
Each metro node cluster consists of two hardware nodes based on the Dell R640 PowerEdge server platform. The dual node architecture provides resiliency within the metro node architecture by providing redundancy of every metro node hardware component.
In addition to resiliency and virtualization, another key component to reducing or eliminating downtime is the time required to make a decision when an event occurs. This is known as the decision time objective (DTO). Other architectures may not support automated failover or resynchronization and therefore require key decisions to be made by business stakeholders, weighing the effort required to failover and then to resynchronize the data and failback. These decisions and approvals take time and increase down time. PowerStore Metro node handles this decision automatically allowing for a zero DTO and therefore reducing or eliminating downtime.
Metro node can also be configured as one or more appliances in either a local or metro configuration. Metro node Local is the term used in a local configuration, such as the same local data center. Metro node Metro is used when multiple appliances are deployed in different locations. A metro node Metro configuration fulfills the storage replication requirement when building SQL Server Multi-Subnet (stretched) clusters. A metro node Metro configuration greatly simplifies the storage configuration of Always On failover cluster instances. When FCIs are configured using metro node, the storage configuration on the host is the same, regardless of the number, type, or the location of the arrays, because the SQL Server hosts are mapped to metro node rather than to the underlying storage appliance. This also allows FCIs to be expanded without disruption.
Metro node is independent of SQL Server features. Therefore, older versions of SQL Server can benefit from increased resiliency. It is not necessary to upgrade to the latest version of SQL Server to benefit from metro node.
