Understanding Dell EMC SVC Stretch Cluster Architecture and vDisk Mirror Features
The article explains Dell EMC SVC's gateway‑style storage architecture, its 2‑8 node clusters, I/O groups, vDisk Mirror functionality, local and stretched cluster configurations, arbitration mechanisms, and performance improvements in Enhanced Stretched Cluster, providing a comprehensive guide to high‑availability storage design.
SVC is a gateway‑style storage product that supports clusters of 2‑8 nodes, where each node is a server. Two nodes that mirror each other's cache form an I/O Group, and each volume belongs to a specific I/O Group; moving a volume to another group usually requires interrupting host access.
SVC's vDisk Mirror feature creates mirrored volumes across two backend storage arrays, presenting a highly available volume to hosts. When the mirrors are consistent, one copy can be designated as Primary; writes are duplicated to both copies, while reads are served from one copy.
If one copy becomes unavailable, the other continues to provide read/write access, and a bitmap records data differences so that when the failed vDisk returns, it can automatically resynchronize.
In a standard Local Cluster, all nodes reside in the same data center. A cluster must have at least 2 and at most 8 nodes, forming up to 4 I/O Groups (each group consists of two nodes).
Each storage LUN is assigned to an I/O Group, and can be manually moved to another group if needed. Because each I/O Group consists of two SVC nodes, every LUN has a preferred node and a non‑preferred node.
Read I/O requests are sent to the preferred node, while write I/O is synchronized between the two nodes of the same I/O Group. The write path consists of five steps:
1. Host sends write I/O to the SVC I/O Group.
2. Preferred node A writes the I/O to its cache and forwards it to node B.
3. Node B writes the I/O to its cache and acknowledges node A.
4. Node A returns the response to the host.
5. Node A flushes the cached I/O to the LUN.
If power is lost before the cache is written to the LUN, each SVC node is equipped with a UPS to ensure the cached data can still be flushed. When the primary node fails, the secondary node takes over, enters write‑through mode, and disables caching.
Starting with SVC 5.1, the Split/Stretch Cluster configuration allows nodes of an I/O Group to be placed in two separate data centers, connected by fiber links and a third‑site arbitration device.
Using vDisk Mirror, the two cache‑mirrored nodes of an I/O Group can be deployed at different sites, creating a geographically dispersed, dual‑active storage solution.
Each vDisk belongs to a single I/O Group; only the two nodes of that group provide cache services. Writes are double‑written to both site arrays, while reads can be served from the local cache or array.
In a Stretch Cluster, the same I/O Group is split across two sites, each with its own storage array, and the volume presented to the host remains the same.
To avoid split‑brain scenarios, a Configuration Node (arbitration node) is required. The node order for arbitration is: Configuration Node, the node closest to the arbitration site, then the farthest node.
If the fiber link between the two sites fails, the third‑site arbitration node activates, elects a winning site based on the arbitration rules, and restores normal storage access.
When the third‑site node is unavailable, the remaining site can still serve hosts, but a split‑brain condition occurs; the Configuration Node (node 2) becomes the Active Quorum and wins arbitration.
Version 7.2 introduced Enhanced Stretched Cluster, which resolves the limitations of earlier stretched clusters by providing true active‑active read/write across both sites. Each node, host, and storage receives a Site attribute, allowing hosts to access the local site’s SVC node and storage, optimizing I/O paths.
In this Site‑aware mode, the concept of a Preferred node is no longer relevant; hosts automatically use the active node in their own site.
When a site’s storage fails, the I/O flow switches to the surviving site, as shown by the red arrows in the diagrams.
During write operations, caches on both sites stay synchronized, but unlike Local Clusters, the write response is returned to the host after the local node writes to its cache, without waiting for the remote node, thereby improving write performance.
1. Host sends write I/O to SVC.
2. The local‑site node writes to cache, replies to the host, and forwards the write to the remote‑site node.
3. The remote‑site node writes to its cache and replies; both nodes later flush their caches to their respective storage.
By reducing inter‑site interactions, data transfer efficiency is greatly increased and I/O latency is cut roughly in half, as the standard SCSI write flow (which normally requires two exchanges) is streamlined to a single exchange.
SVC merges the I/O flow to achieve a single‑exchange write operation between sites, reducing latency and allowing the same code path for dual‑active and local mirroring. However, issues remain such as cache‑through on single‑controller failure, manual LUN migration requiring host downtime, and the need for third‑site arbitration.
温馨提示: 请搜索 “ICT_Architect” 或 “扫一扫” 下面二维码关注公众号,获取更多精彩内容。
听说点赞和分享的朋友都已走上人生巅峰
Architects' Tech Alliance
Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.