2同行回答
在上面的章节中，我们已经深入探讨了基于SVC的三种主流双活数据中心架构，详细的介绍了每种架构的基本模式、特性、原理和I/O读写等方面内容，为了更方便与直观的展示三种架构的区别和特性，列表如下：
| SVC Stretched Cluster | SVC HyperSWAP | SVC Local VDM+ SVC PPRC |
硬件需求 | 只能SVC | SVC/V7000/V5000等 | 只能SVC |
配置方法 | GUI/CLI | CLI | GUI/CLI |
最小SVC节点数量 | 2 | 4 | 4 |
SVC集群数量 | 1 | 1 | 2 |
站点间距 | <300KM | <300KM | <300KM |
数据站点个数 | 2 | 2 | 2 |
一个站点失效时 缓存状态 | Disable | Enable 两个站点缓存独立 | Enable 两个站点 缓存独立 |
最大VDISK数量 | 4096 | 1024 | 4096 |
是否支持一致性卷组 | 不支持 | 支持 | 支持 |
数据副本份数 | 2 | 2-4 | 3 |
本地数据副本 份数 | 1 | 1-2（增加本地数据副本复制至两个POOL） | 2 |
两地三中心扩展 | 支持MM/GM扩展，最大能扩展至4个站点 | 不支持，无法继续扩展 | 支持MM/GM扩展，最大能扩展至4个站点 |
FLASH COPY扩展 | 支持 | 受限制，HyperSwap卷只能作为FLASH COPY源卷，而且无法跨站点做FLASH COPY | 支持 |
双活方式 | ACTIVE-ACTIVE | ACTIVE-ACTIVE | ACTIVE-STANDBY |
同步与重新 同步方式 | 自动 | 自动 | 自动 |
两个I/O GROUP 间切换方式 | 如果配置了两套I/O GROUP，他们间无法自动切换，需手动切换 | 灾难时，本地I/O GROUP自动切换至灾备同一集群的I/O GROUP | 灾难时，本地I/O GROUP自动切换至灾备另一集群的I/O GROUP |
许可 | 包含在基础产品中 | 需要远程镜像许可 | 需要远程镜像许可 |
SVC版本需求 | SVC 7.2以上 | SVC 7.5以上 | SVC 6.4以上 |
主机多路径 技术需求 | 标准的主机多路径驱动 | 标准的主机多路径驱动 | 标准的主机多路径驱动 |
第三站点仲裁 | 需要 | 需要 | 不需要 |
读操作 | 站点各自读 | 站点各自读，连续10分钟，75%以上的读写I/O存在另外站点，则改变读方向 | 本地站点读，灾备站点无读操作 |
写操作 | 站点各自写 | 站点各自写，连续10分钟，75%以上的读写I/O存在另外站点，则改变写方向 | 本地站点读，灾备站点无写操作 |
读写路径优化 | 单一站点优化 | 双站点优化 | 无 |
第三站点 仲裁失效 | 无影响，根据配置节点归属、与第三站点距离等因素投票产生新仲裁 | 无影响，根据配置节点归属、与第三站点距离等因素投票产生新仲裁 | 无 |
单一站点失效 | 无影响，另一站点主机将从同一站点读写 | 无影响，另一站点主机将从同一站点读写 | 灾备站点失效，生产站点无影响；生产站点失效，将引起HA跨站点切换 |
单一站点失效后读写性能 | 单一站点失效后，造成缓存被DISABLE，进入读写直通模式，将可能造成读写性能影响 | 单一站点失效后，另一站点的读写性能和失效前完全一致 | 灾备站点失效，生产站点无影响；生产站点失效，将引起HA跨站点切换，切换期间无法读写；切换后读写性能完全恢复一致 |
两站点间 线路中断 | 发生脑裂，需要第三站点仲裁，仲裁完成前，两个站点的主机都将无法读写；仲裁完成后，赢得仲裁的站点继续读写，没有赢得仲裁的站点将关闭。仲裁完成时间不确定，将根据线路时延、距离仲裁站点距离和配置节点归属等共同决定 | 发生脑裂，需要第三站点仲裁，仲裁完成前，两个站点的主机都将无法读写；仲裁完成后，赢得仲裁的站点继续读写，没有赢得仲裁的站点将关闭。仲裁完成时间不确定，将根据线路时延、距离仲裁站点距离和配置节点归属等共同决定 | 发生脑裂，但生产站点无任何影响，并自动关闭灾备站点主机 |
两站点间线路中断并且第三站点仲裁失效 | 发生脑裂，根据配置节点归属、与第三站点距离等因素投票产生新仲裁，仲裁完成前，两个站点的主机都将无法读写；仲裁完成后，赢得仲裁的站点继续读写，没有赢得仲裁的站点将关闭。 | 发生脑裂，根据配置节点归属、与第三站点距离等因素投票产生新仲裁，仲裁完成前，两个站点的主机都将无法读写；仲裁完成后，赢得仲裁的站点继续读写，没有赢得仲裁的站点将关闭。 | 发生脑裂，但生产站点无任何影响，并自动关闭灾备站点主机 |
上面的列表很直观的展示了三种SVC架构的区别和共同点，可以看到，三种架构在不同的场景和不同的高可用要求下，均有用武之地。SVC Stretched Cluster和SVC HyperSWAP架构实现了双站点ACTIVE模式，但这两种模式有两个弊端，一是对数据库双活的实现，依旧需要配合数据库软件层的方案解决。二是对两个站点间的线路要求非常高，一旦线路中断（这种情况并非不可能，尤其在当下各种修路、修地铁，多家运营商的裸光纤都在同一弱电井，同时断的可能性大增），将对两个站点的所有主机均造成一段时间的影响，所有业务被中断，影响时间取决于仲裁时间和两站点间距离。而且还需要忍受站点间线路的时延和抖动的可能造成的影响，站点间距离越大，这种影响会被不断放大，影响读写性能，甚至造成线路中断。这种情况下反而不如用SVC Local VDM+SVC PPRC架构，从分保护了本地资源，排除了可能的不可抗拒的影响，而且如果采用了SVC Local VDM+SVC PPRC架构，虽然存储架构层作为ACTIVE-STANDBY方式，但仍旧可以配合软件层实现双活数据中心建设；另外SVC HyperSWAP架构看似很高级，无论从双站点的读写性能优化、单一站点失效后的全面保护能力方面还是双活架构后的高可用方面均优于Stretched Cluster，但却无法继续进行两地三中心扩展，实施复杂性也更高，运维成本也提高，而且总的VDISK数量较少等等；SVC Local VDM+SVC PPRC充分保护了本地，但是灾备的实施却又局限于AIX系统下的HACMP，6.1之前的AIX版本和linux、windows系统均无法实现跨站点高可用，只能从数据层同步，并利用软件层的方式实现高可用和双活。而且SVC Local VDM+SVC PPRC的一套SVC集群下的两个IO Group间无法自动切换，这点SVC Stretched Cluster也是如此，也就是说如果SVC Stretched Cluster配置为2个I/O Group，I/O Group间是无法实现自动切换的，需要人为手动切换；SVC Stretched Cluster实现了ACTIVE-ACTIVE，又可以扩展两地三中心，但是读写性能优化方面做得又不如SVC HyperSWAP，而且本地冗余度做得也不大好，本地一个SVC节点故障，本地就没有冗余保护，只能利用灾备站点的SVC节点，这点在SVC Local VDM+SVC PPRC和SVC HyperSWAP都得到了冗余度提升；另外还有一点共同点得我们关注，我们知道SVC Stretched Cluster、SVC Local VDM+SVC PPRC和SVC HyperSWAP均使用了同步复制技术，但有没有想过如果真的因为站点间距离长，时延比较大，导致两个SVC节点同步缓慢，以致最后影响双数据中心整个业务系统的写I/O缓慢。SVC还考虑到了这一点的，在SVC节点同步的参数中有mirrowritepriority属性，可以设置为latency，当同步响应时间大于5秒时，放弃同步，保证主站点/主存储的写I/O性能。基于此，三种方案针对不同的企业需求，不能说哪种方案通吃，也不能说哪种方案一定不行，都有使用优势和劣势。
收起