Home > Storage > PowerVault > White Papers > Dell PowerVault with Metro Node and Microsoft > SQL Server with metro node
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 separate 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 SQL Server 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.
Microsoft SQL Server high availability features can be enhanced by adding Metro node Local. Whether SQL Server is deployed as a stand-alone instance, a Failover Cluster Instance (FCI), or Always On Availability Group (AG), each deployment model can benefit from added storage resiliency.
A simple architecture diagram illustrates how a basic SQL Server configuration is enhanced with Metro node Local.
Adding metro node to the SQL Server FCI storage architecture adds resiliency and can prevent cluster failover due to storage-related events, both planned and unplanned. In this architecture, the shared storage requirement of an FCI is provided by metro node and enhanced with nondisruptive array failover.
Always On Availability Group architectures can benefit from metro node as well. Adding metro node to the storage architecture allows nondisruptive storage failover to a secondary array to occur without initiating an AG failover that would occur with a single array.
Metro node Metro enables metro node capabilities over distance. By adding a second metro node cluster in another location, storage resiliency can be stretched between data centers or multiple buildings. This provides an alternative for product-specific data replication mechanisms for extended cluster or geo-cluster applications.
For example, in a metro node Metro configuration, one metro node cluster is placed at Site A and another is placed at Site B, as shown in Figure 6.
In a metro node Metro configuration, storage network traffic is local to the site and cross-site communication is handled by the Ethernet network. In this example, if there is a local storage failure at Site A, IO traffic would flow across the Ethernet network between metro node clusters and access storage at Site B. At this point an administrator could decide whether to fail over the compute to Site B as a planned event, or to wait until the storage issue at Site B is resolved. Metro node performs automatic resynchronization, and all IO traffic is returned to normal at Site A.
If the optional metro node Metro witness is configured as shown in Figure 6, recovery time objective (RTO), recovery point objective (RPO), and decision time objective (DTO) are zero.
The same architecture pattern can be applied to SQL Server Always On Availability Groups (AG). In this way, additional protection against site failure is added while maintaining persistent storage connectivity to the applications if there is a single site storage failure that would otherwise introduce a SQL Server instance failover and likely an unplanned outage.
It is recommended that distance between metro node Metro clusters be less than 100 km and the Round Trip Time (RTT) over the intercluster link be no more than 10 ms. See the Dell Metro Node Product Guide for more information.