7同行回答
SVC Stretch Cluster也就是SVC拉伸式集群架构，就是把同一SVC集群中的SVC节点分散在不同的两个数据中心，它们之间通过光纤链路连接，并且需要第三地的仲裁设备。为了帮助大家深入理解SVC Stretch Cluster，先来理解下SVC Local Cluster：一套SVC集群最少包含2个节点，最大8个节点，两...SVC Stretch Cluster也就是SVC拉伸式集群架构，就是把同一SVC集群中的SVC节点分散在不同的两个数据中心，它们之间通过光纤链路连接，并且需要第三地的仲裁设备。为了帮助大家深入理解SVC Stretch Cluster，先来理解下SVC Local Cluster：
一套SVC集群最少包含2个节点，最大8个节点，两两节点组成一个I/O group，因此一套SVC集群最大可以包含4个I/O group，如下图所示：
每一个存储LUN都分配给一个I/O group，你也可以手动转换存储LUN的I/O group，比如说LUN1属于I/O group0，当I/O group完全不可用时，需要手动转换至I/O group1，因为每一个I/O group均由两个SVC节点组成，所以每个存储LUN均分配给一个优先的节点和一个非优先节点，如下图所示：不同的存储LUN的优先节点可以不一样，这是SVC集群系统自动负载和分配的，同一SVC I/O group节点均衡负载着存储LUN，对于读I/O请求来说，来自于优先的SVC节点，而写I/O请求在同一I/O group的两个节点间同步，一次SVC I/O写请求，分解为以下5个步骤：
1.主机发送写I/O请求至SVC I/O group
2.优先的SVC节点A写入I/O至缓存，并发送I/O至同一I/O group的另一SVC节点B
3.节点B将写入I/O至缓存后，并回响应至节点A
4.节点A收到节点B的回响应后，向主机回响应
5.节点A将缓存写I/O写入LUN当中
写I/O流转图如图所示：
有人会说了，第5步最后才将缓存数据写入LUN当中，那么当还没有写LUN时，SVC节点突然断电了怎么办？这种情况SVC也是考虑了，每个SVC节点均配备了UPS电源，可以维持供电，可以保证缓存数据正常写入LUN当中。
基于以上这种机制，同一I/O group的两个SVC节点是实时同步的，当I/O group中的主节点故障时，另一SVC节点将接管，并进入写直通模式，并禁止写缓存，也就是说只有1、5、4三个步骤。
以上是SVC的I/O group在一个数据中心的情况，而SVC Stretch Cluster则是将一套SVC集群下的同一I/O group的两个节点拉开，分别放在两个数据中心，之前连接SVC的一套存储，拉开后各放置一套存储，通过SVC做vdisk镜像同步。说白了还是同一套SVC集群，同一个I/O group，SVC Local VDM(vdisk mirror)拉开成SVC Stretch VDM，映射给主机的volume还是同一个，这样一来就不难理解了。SVC、存储、主机及第三站点光纤连线下图所示：
对于SVC Stretch Cluster来说，为了防范脑裂，仲裁站点是必需的。首先是configuration node，配置节点，是配置SVC集群后，系统自动产生的保存着所有系统配置行为的节点，不能人工更改配置节点，当配置节点失效后，系统会自动选择新的配置节点，配置节点十分重要，它对SVC节点仲裁胜利起着决定性作用，仲裁胜利的排序规则如下：
1.配置节点
2.距离仲裁站点近的节点
3.距离仲裁站点远的节点
下图为SVC Stretch Cluster两个站点的仲裁配置示意图：
当两站点间光纤链路中断，第三站点仲裁节点活动时，脑裂发生，将通过投票仲裁选举获胜的站点，按照上述的仲裁胜利规则，configuration node位于节点2，选举站点2优先赢得仲裁，通过站点2恢复业务的正常存储访问。当第三站点仲裁节点不活动时，不影响主机的正常存储访问，但是此时，两站点间光纤链路也中断了，发生脑裂，这时因为节点2为configuration node，它所拥有候选的Quorum将变为active Quorum，该Quorum选举站点2为仲裁胜利站点，通过站点2恢复业务的正常存储访问。
另外，SVC版本到了7.2时，又出了一个新功能， 叫做Enhanced Stretched Cluster，这又是什么呢？增强版拉伸集群增强点在哪？之前的Stretched Cluster看似实现了双活，实则只为数据级双活(SVC VDM)，主机访问SVC实则只访问了一个I/O group优先节点，另一非优先节点则只是完成了写缓存同步的任务而已，无论是local cluster还是Stretched cluster，实际的读写卷操作并未通过非优先节点进行，通俗的说就是主备模式（ACTIVE-PASSIVE），由于优先节点是 SVC系统自动分配的，可能会出现一种情况是，主机在站点A，但是存储卷的优先节点却在站点B，主拷贝的存储却在站点A，主机一直访问了站点B的SVC节点，再访问站点A的存储，这样的存储路径完全不是最优的，对主机I/O性能造成影响，但是这些在Enhanced Stretched Cluster中均得到改善，实现了SVC双节点双站点读写双活，在该版本，元素均赋予site属性，如SVC节点、主机、存储等，不同站点的主机对各自站点的SVC节点和存储进行读写操作，对同一volume来说，站点A的主机访问站点A的SVC节点，站点A的存储，站点B的主机访问站点B的SVC节点，站点B的存储，存储访问路径最优，两个站点的SVC节点、主机、存储都同时活动，实现应用级双活（ACTIVE-ACTIVE）,在site模式中，SVC优先节点概念不起作用了，配置了site模式的主机，优先访问活动的同site的SVC节点和同site的存储。如下图所示为读写模式下的Enhanced Stretched Cluster 流转图：
绿色的箭头为优先的读I/O流转，红色箭头为站点2的存储失效后的读I/O流转。
绿色的箭头为优先的写I/O流转，红色箭头为站点1/2的存储失效后的写I/O流转。
需要注意是，在写操作时，两个站点的SVC节点的缓存是保持同步的，但是不同于SVC LOCAL CLUSTER，整个写操作的过程中，SVC节点的写操作响应在写入缓存后就发生了，而不需要等待另一SVC节点写缓存完成并回复响应，这样一来，优化了整个写性能，具体过程如下：
1.主机向SVC写I/O请求。
2.同站点的SVC节点将写I/O写入缓存，并向主机回复响应，同时将写I/O同步至另一站点的SVC节点。
3.另一站点的SVC节点将写I/O写入缓存，并回复响应。
两个站点的SVC节点陆续将缓存写入各自站点的存储当中。
收起上面这个问题来说，如果仅仅从后端挂载的存储容量扩容，SVC是会不出现性能瓶颈的，SVC最大支持4096个VDISK，如果后端存储扩容，划分出来的卷的数量也越来越多，甚至需要超过4096个VDISK，那么SVC仅仅是不再支持划分而已，性能不会出现问题。如果从SVC映射的主机数量角度来说，如果SVC映射的主机数量越来越多，那么均分至每一个SVC I/O Group优先节点的主机数量也越来越多，这时就需要考虑SVC节点的性能瓶颈，因为SVC节点的缓存容量有限，主机数量的增加意味着所有主机平均每次需要写入的IO量增多，假如增大至单个SVC节点缓存不足够容纳时，这时就会开始出现性能瓶颈，就需要开始新增SVC I/O Group了。
其实SVC的性能很不错，借用一下前人测试的结果：
“”单论SVC的节点性能，在前两代的CF8节点上做过SPC-1测试，16个V7000在8个CF8节点管理下，SPC-1性能达到50多万IOPS。现在最新的DH8节点，性能是CF8的3-4倍，那么性能可达到150-200万IOPS，每个I/O Group可达到50万IOPS。“”
我们可以利用监控来判断SVC节点是否已饱和，如TPC软件，也可以用SVC自身WEB界面上的监控来初步判断。
收起楼上有些点写得很对，指出的不错
1.两个IO Group之间是支持卷在线手动转换的，如果一个IO Group完全不可用时，假如这时该IO Group中的写缓存还没来得及写入存储，该IO Group中的两个节点就同时故障了，这时将丢失一部分写数据，遇到这种情况，需要利用SVC容灾来避免该问题的出现，在灾备搭另一套集群，通过SVC PPRC来实现不同数据中心间不同SVC IO Group节点的缓存同步，避免数据丢失。
2.这点补充得不错，相信以后随着SVC版本更迭，会越来越淡化Preferred与非Preferred的概念，在跨中心的存储A-A方案中，SVC Stretched Cluster和SVC HyperSwap方案都渐渐淡化了该概念。
3.configuration node是SVC集群配置好之后，系统自动决定哪个节点作为configuration node，其中保留了SVC的配置信息，configuration node还有一个功能就是实时监控仲裁节点的工作状况，比如SVC LOCAL VDM本地的两个存储仲裁盘的状态或者SVC Stretched Cluster两个站点和第三站点仲裁盘的状态，基于configuration node经常性与第三站点仲裁通信的存在，一个必然的结果就是包含configuration node的站点有更大的机会去赢得仲裁，因为该站点与仲裁站点通信链路响应时间有很大机会更快;另外一个就是两个站点与仲裁站点的距离，距离更近，通信链路响应时间有很大机会更快，距离越远，通信链路响应时间有很大机会更慢，所以距离更近，有更大的机会去获取仲裁的胜利。所以仲裁胜利优先顺序如下：
1.配置节点
2.距离仲裁站点近的节点
3.距离仲裁站点远的节点
当然这也是建立在通讯链路响应时间的基础上，除非一些非常特殊的情况，基本都是1、2优先获得仲裁胜利，3是最后的优先级。
收起感谢分享，有个问题想咨询下，目前的环境下面一套svc有一个IO GROUP，下面挂载了不同的存储，现在相对下面的挂载的存储扩容，担心随着后面存储容量的扩大，SVC会不会出现瓶颈？怎么判断？
楼主写的很赞，对SVC的理解已经很全面了，但有些地方可能存在点小问题。
1.一个IOG0的节点都不可用时，其上的卷不能手工转换至IOG1。因为卷的写数据和控制数据都还在IOG0里面，不在IOG1上。除非容忍数据的丢失，否则没办法切换到IOG1。IOG0在线时，支持将其上的卷在线迁移到IOG1上，这个功能叫NDVM。
2.Volume有Preferred和Non-Preferred的结构，但存储控制器可以同时接收IO，即通常所说的Active-Active访问模式。但AIX/Win上的SDDPCM/SDDSM多路径软件在识别Volume的路径时，自动将来自两个控制器的的path进行优先区分，因此IO在主机端就会被自动发给Preferred node。对于Linux主机而言，可以将Volume的path路径优先等级标记为相同，即一视同仁，那么此时每条路径都会有IO到两个nodes，形成A-A访问模式。但在SVC内部，Non-Preferred Node会转发IO给Preferred Node，消耗一些资源。国内某著名大厂的高端存储号称A-A访问，用的也是这种机制。在更高级的ESC模式中，即使发给Non-Preferred节点，IO照样被处理，且不用被转发给Preffered节点。
3.在脑裂时，哪个节点第一时刻抢到仲裁，哪个节点存活，这个是符合对等设计要求。没有config节点先抢到，距离短的节点先抢到的说法，距离长一点的，链路响应时间也可能比链路端的快。
收起