存储跨中心双活方案设计指南：如何攻克十大难点？
存储跨数据中心双活的方案是双活数据中心架构方案中最重要且最艰难的一项。为了帮助企业IT架构师理清和解决存储跨中心双活方案架构的难点，twt社区专门邀请了企业IT架构师和存储专家整理出十个方案设计中较为典型的难点，逐一解析和解答，以帮助大家顺利地解决和尽量规避这些难点问题。并整理为存储跨中心双活方案设计的一篇指南，方便大家收藏转发。
存储跨中心双活方案设计阶段该如何尽量避免脑裂？
如何避免脑裂是每个双机系统都要重视的问题，存储双活系统尤其如此，脑裂会带来长时间的存储读写IO HANG住，轻则导致业务性能下降，重则因磁盘IO超时，导致数据库挂起甚至宕机，对生产业务系统造成重大影响。所以在存储跨中心双活架构设计时，究竟应该如何尽量避免脑裂？
解析和解答
▼▼▼
■ 邓毓 某农信
数据中心脑裂简单说就是两个数据中心间的网络和存储链路同时发生中断，导致两个数据中心内的应用、数据库或者操作系统同时抢占和利用共享的资源，造成资源的数据不一致，产生重大影响。
这个问题是存储跨中心双活方案设计、实施阶段不可避免要遇到的问题。各个存储厂商、存储虚拟化产品厂商都有自己的避免脑裂的方式：
（1）IBM SVC ESC/HYPERSWAP 或者IBM V9000/V7000/V5000 HYPERSWAP
对于上述存储双活方案架构来说，呈现的是一种对称式的整体架构，为了防范脑裂，仲裁站点是必需的。在仲裁站点中，基于IP的quorum节点和物理quorum磁盘都可以提供脑裂的仲裁服务，存储双活集群最多能够拥有3个物理quorum磁盘，也可以选择最多5个基于IP的quorum节点，这个基于IP的quorum节点可以是任何站点的任何服务器，或者公有云的一个虚拟机，在这个服务器内运行一个简单的仲裁JAVA程序即可。所以可以看到，基于IP的仲裁服务其实大大提高了仲裁站点的选择空间，节省了企业双活建设成本，只要求IP可达，延时在80MS内即可。
但是，只有物理quorum磁盘的仲裁方式才能够被用来做T3 Recovery，所有的SVC节点都会将节点的相关信息同步至该物理quorum磁盘，当节点或者集群出现故障时，可以通过该物理quorum磁盘进行T3 Recovery
在SVC集群中有一个概念configuration node---配置节点，是配置SVC集群后，系统自动产生的保存着所有系统配置行为的节点，不能人工更改配置节点，当配置节点失效后，系统会自动选择新的配置节点，配置节点十分重要，它对SVC节点仲裁胜利起着决定性作用，仲裁胜利的排序规则通常如下：
1.配置节点（配置节点获得仲裁胜利的概率最高）
2.距离仲裁站点近的节点（探测延时较低的SVC节点获得仲裁胜利的概率次之）
3.距离仲裁站点远的节点（探测延时较低的SVC节点获得仲裁胜利的概率最低）
举例：
当两站点间光纤链路中断，第三站点仲裁节点活动时，脑裂发生，将通过投票仲裁选举获胜的站点，按照上述的仲裁胜利规则，configuration node位于节点2，选举站点2优先赢得仲裁，通过站点2恢复业务的正常存储访问。
当第三站点仲裁节点不活动时，不影响主机的正常存储访问，但是此时，两站点间光纤链路也中断了，发生脑裂，这时因为节点2为configuration node，它所拥有候选的Quorum将变为active Quorum，该Quorum选举站点2为仲裁胜利站点，通过站点2恢复业务的正常存储访问。
（2）EMC VPLEX Metro
VPLEX有着自己专属的防脑裂规则：
1.分离规则
分离规则是在与远程群集的连接中断（例如，网络分区或远程群集故障）时，确定一致性组 I/O 处理语义的预定义规则。在这些情况下，在恢复通信之前，大多数工作负载需要特定虚拟卷集，才能在一个群集上继续 I/O 并在另一个群集上暂停I/O。在 VPLEX Metro 配置中，分离规则可以描述静态首选群集，方法是设置：winner:cluster-1、winner:cluster-2或 No Automatic Winner（无自动优胜者）（其中，最后一项指定无首选群集）。如果部署的系统没有 VPLEX Witness，一致性组设备 I/O 将在首选群集中继续，并在非首选群集中暂停。
2.VPLEX Witness
VPLEX Witness 通过管理 IP 网络连接至两个 VPLEX Metro 群集。VPLEX Witness通过将其自身的观察与群集定期报告的信息进行协调，让群集可区分群集内网络分区故障和群集故障，并在这些情况下自动继续相应站点上的 I/O。VPLEX Witness 仅影响属于 VPLEX Metro 配置中同步一致性组成员的虚拟卷，并且仅当分离规则指明群集1或群集 2 是一致性组首选群集时才会影响（也就是说，“无自动优胜者”规则未生效时，VPLEX Witness 不影响一致性组）。没有 VPLEX Witness 时，如果两个VPLEX 群集失去联系，生效中的一致性组分离规则将定义哪个群集继续操作以及哪个暂停 I/O，如上所述。仅使用分离规则来控制哪个站点是优胜者时，可能会在出现站点故障时增加不必要的复杂性，因为可能需要手动干预才能恢复仍正常运行的站点 I/O。VPLEX Witness会动态地自动处理此类事件，这也是它成为扩展 Oracle RAC 部署绝对必要项的原因。它提供了以下几项内容：
a.在数据中心之间自动实现负载平衡
b.主动/主动使用两个数据中心
c.存储层的完全自动故障处理
为了让 VPLEX Witness 能够正确区分各种故障情况，必须使用互不相同的网络接口在独立于任意群集的故障域中安装它。这将消除单个故障同时影响群集和 VPLEX Witness 的可能性。例如，如果将 VPLEX Metro 配置的两个群集部署在同一数据中心的两个不同楼层，请在不同楼层部署 VPLEX Witness。另一方面，如果将 VPLEX Metro 配置的两个群集部署在两个不同的数据中心，请在第三个数据中心部署VPLEX Witness。
（3）HDS HAM/GAD
HDS的HAM/GAD存储双活方案是建立在VSP TrueCopy同步复制技术之上的，整个架构也需要仲裁机制防止脑裂，能保证心跳故障后，整个集群系统能对外提供数据一致性存储服务。目前，HAM/GAD仲裁的实现方式有下面几种：
1、优先级站点方式。这种方式最简单，在没有第三方站点的情况下使用，从两个站点中选一个优先站点，发生脑裂后优先站点仲裁成功。但如集群果发生脑裂后，优先站点也发生故障，就是导致业务中断，因此这种方案并非推荐的方案。
2、软件仲裁方式。这种方式应用比较普遍，采用专门的仲裁软件来实现，仲裁软件放在第三站点，可以跑在物理服务器或VM上，甚至可以部署到公有云上，PureStorage的ActiveCluster就把仲裁软件以OVF文件部署在公有云上。
3、阵列仲裁盘方式。这种方式是在第三站点采用另外一台阵列创建仲裁盘。这种方式稳定性，可靠性比较高。GAD的仲裁机制原理是采用仲裁盘的方式实现。
（4）NETAPP Clustered Metro Cluster（MCC）
MCC的MetroCluster的仲裁软件TieBreak支持装在第三站点的linux的主机上，通过检查对节点Ssh的session对HA pair和集群进行状态监控。TieBreak软件能够在3到5秒内检查到ssh session的故障，重试的时间间隔为3秒。所以这种方式也很灵活，第三站点可以选择两个数据中心中的一个，也可以选择公有云中的一个虚拟机，保证SSH网络可达，还可以选择其他建筑内的任意一台Linux虚拟机。
（5）IBM DS8800系列HYPERSWAP
DS8800 HYPERSWAP架构下的存储为ACTIVE-STANDBY模式，整体是对称式的架构，但是却没有第三仲裁站点，在双数据中心间链路全部中断时，要恢复业务需要人为关闭非存活站点的集群服务，并且修复链路，如下红皮书原文：
Unplanned HyperSwap: Site partition
In the scenario of Site parttion, the workload continues to run on Site_A.Because both sites are partitioned, each site thinks it is the only surviving site, as such, the nodes in each site try to start the workload on each site.
Running the workload at the same time on both nodes results in data corruption. To maintain data integrity, PowerHA SystemMirror supports recovery mode for HyperSwap through manual workload activation. This option indicates that when the link between the sites is down (both sites are down), user intervention for manual recovery is needed, therefore
maintaining data integrity.
When the site is down, because Auto Recovery Action is not supported, the resource groups(RGs) will remain in the ERROR state. User intervention is needed to correct the problem.
The user has to shut down the cluster services on Site_B and fix the connectivity issues. When done, the user can start the cluster services on Site_B.
▼▼▼
■ 赵海 某商业银行
其实这个问题，我觉得还是要看整体的架构是什么样的？
假设定位到存储双活，那么是不是就割裂了数据库层的仲裁问题。实际上存储最终是为上层数据库及应用服务，如果这个夸中心的架构涉及到数据库、存储两层的组合，比如说存储双活之上是oracle rac，那么就比较复杂了。
首先对于存储本身的仲裁，应该有自己的算法，例如：
1）仲裁中心
2）最坏情况下，默认的算法。
对于夸中心的rac集群，同样有自己的规则：
1）仲裁盘
2）通过网络和磁盘心跳保证获得票数最多的子集活着。
3）实例小的节点存活。
但是当二者结合的时候，就有更复杂的场景可能会出现，尤其是出现两层架构仲裁的结果不一致。
为了避免这个结果出现，那么我们需要攻克以下问题：
1. 如何保障仲裁触发的时间序列一致。
2. 极端情况下的仲裁算法一致性。
例如，你可以通过oracle的仲裁参数misscount结合vplex的仲裁timeout参数来保障时间序列的一致性。
例如，你也可以调整各自默认算法的最终结果落到一边。
例如，你也可以通过二次开发来实现二者的联动。
最后，所有的前提条件和策略都需要得到模拟实践的检验。
存储跨中心双活方案设计阶段如何尽量降低对整体性能的影响？
性能影响问题：因为双活系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。在选型设计阶段该如何解决该难点？尽量降低对整体性能的影响？
解析和解答
▼▼▼
■ 邓毓 某农信
这个问题实际上存储双活不可避免要遇到的问题，相比单存储直接提供读写来说，存储双活一定会增加读写响应时间，更别说存储还是跨两个不同数据中心的，随着距离的增加，理论上每增加100KM，会增加1ms的RTT（往返延迟时间）,通常单个IO总耗时在1-3ms左右，就会认为单个存储I/O处理处于比较高性能的模式，如果加上其他因素，如“数据头处理”和“并发”，1ms的“理论”延时增加的影响会成倍增加，将原本处于高性能模式的IO响应时间拉高，对应用或者数据库来说，“变慢”了。所以存储双活的初衷是只是为了高可用性和提高总体并发、吞吐量，并不是为了降低读写响应时间。那么我们在设计、选型存储双活方案时，就需要考虑如何尽量降低双活的存储所带来的性能降低影响。
我们先来看看一些存储双活方案的读写流程：
（1）IBM SVC Enhanced Stretch Cluster(ESC)和HDS GAD等
IBM SVC ESC和HDS GAD的读写方式都很类似，这里就放在一起来看。
SVC ESC：
HDS GAD：
读：
ESC和GAD在两个存储拉开到两个数据中心，形成AA模式的架构，对于读来说，是两个数据中心分别对各自中心的存储本地读，这样读来说不存在跨站点的RTT，读性能跟单存储是一样的。
写：
某数据中心的写操作会先写到本地控制节点缓存，然后再跨站点同步至另一控制节点缓存中，并原路返回，告诉主机写操作完成，等到缓存达到一定的水位时，再刷入各自底层存储当中，这时的写操作存在1倍的跨站点RTT。当两个数据中心都要对某一数据块写操作时，会先在缓存表对应的数据块中加锁，并同步锁信息至对端缓存表，实现双活存储的写并发。所以写也是本地写的方式，性能跟单存储比是降低的。
（2）SVC HyperSwap
SVC HyperSwap的HyperSwap卷有master和aux之分，读写复杂度也高很多，master卷所在站点的主机读写是本地读本地写，而aux卷所在站点的主机读写方式是转发模式。
假设初始化后，Site1的卷为Master卷，Site2的卷为Aux卷
读：
Site1读I/O
1.主机向SVC I/O Group1的任意一个节点发送读请求
2.SVC I/O Group1将该请求传至Storage Pool1
3.Storage Pool1响应请求，并将数据传至SVC I/O Group1
4.SVC I/O Group1将数据结果传至主机
Site2读I/O
1.主机向SVC I/O Group2的任意一个节点发送读请求
2.SVC I/O Group2将该请求转发至SVC I/O Group1
3.SVC I/O Group1将请求传至Storage Pool1
4.Storage Pool1响应请求，并将数据传至SVC I/O Group1
5.SVC I/O Group1将数据回传给SVC I/O Group2
6.SVC I/O Group2将数据结果传至主机
所以可以看到AUX卷所在站点的主机需要跨站点读对端存储，存在1倍的RTT，而MASTER卷所在的主机读IO和单存储性能相差无几。
写：
Site1写I/O
1.主机向Site1的其中一个SVC节点2发送写I/O请求
2.该SVC节点2将写I/O写入缓存
3.该SVC节点2将写I/O同步至节点1缓存，并同时通过MM发送写I/O至站点2的节点3和节点4
4.SVC节点1、3、4陆续回复节点2的写响应
5.SVC节点2回复主机写响应
6.两个站点的SVC节点分别将缓存写入各自站点的存储当中
Site2写I/O
1.主机向Site2的其中一个SVC节点3发送写I/O请求
2.该SVC节点3将写I/O转发至Site1的任意SVC节点2
3.SVC节点2将写I/O写入缓存
4.该SVC节点2将写I/O同步至节点1缓存，并同时通过MM发送写I/O至站点2的节点3和节点4
5.SVC节点1、3、4陆续回复节点2的写响应
6.SVC节点2回复SVC节点3的转发响应
7.SVC节点3回复主机的写响应
8.两个站点的SVC节点分别将缓存写入各自站点的存储当中
同理，AUX卷所在站点的主机需要跨站点写对端存储，并且回写AUX卷底层存储，总共存在2倍的RTT，而MASTER卷所在的主机写IO和单存储性能相差无几。
所以很明显，SVC HYPERSWAP的SVC节点是跨站点双活，而存储则为ACTIVE-STANDBY。
(3)NetApp MCC
MCC的双活方式实际上是两个数据中心的存储互为镜像，各自提供不同的存储服务。
对于AGGX来说，为站点A的主机提供本地读和本地写，并通过集群节点的NVRAM写日志同步至站点B，维持数据一致性，也是等到日志达到水位线，刷入底层存储当中。
对于AGGY来说，也是类似，为站点B的主机提供本地读和本地写，并同步NVRAM的写日志至站点A。MCC通过这种方式实现两个站点存储的双活，MCC集群节点也是双活，但对于某一应用主机来说，实则只在一个站点活动。
性能方面，MCC的读性能和单存储类似，写性能存在1倍的RTT。
(4)SVC Vplex Metro
Vplex Metro和其他三种方式都不一样，是一种分布式的存储双活/多活架构。Vplex没有写缓存，有了分布式缓存，标榜为access anywhere
没有写缓存就意味了，主机对VPLEX的写是透写模式，主机的写IO只是经过VPLEX的虚拟化直接落入到底层存储，并在分布式缓存目录表中记录这个写IO是通过哪个VPLEX引擎写入的。当需要对该数据块进行读操作时，先是在分布式缓存目录中查找数据块是通过哪个VPLEX引擎写入的，然后再通过本地的VPLEX引擎转发该读请求至上一次写入该数据块的VPLEX引擎，通过它来读取它后端的存储，最终原路返回。另外，对于写入的IO，透穿过VPLEX写底层存储时，还将同步一份IO副本至另一VPLEX引擎的底层存储。
所以可以看到，对于某数据中心VPLEX的读操作来说，如果刚好上次该数据块的写操作时也是发在该VPLEX中，那么读是本地读，亲和性好。如果刚好上次该数据块的的写操作不是在该VPLEX，那么就需要跨站点进行读操作，亲和性弱，存在1倍的跨站点RTT；对于写，都是本地写，只不过需要将该写IO同步至另一站点的底层存储，也存在1倍的跨站点RTT。
好了，写了这么多，将几种主流的存储双活架构的读写操作流程写清楚了。简单对比如下：
归根到底，我们最想要的存储跨中心双活，就是为了让两个数据中心的主机对存储的读写，尽量本地读和本地写，或者本地读，减少跨中心写。这是“尽量降低对整体性能的影响”的最直接的方法！
首先是读写比例问题，不能将读写比例过小的应用放到双活存储系统中。
再是距离对读写RTT的放大问题，读写响应时间越敏感，距离越不能过远。
最后是想尽办法，减少跨中心写，这里有很多办法，比如通过数据库的分库分表，将应用分割至两个站点，热点数据分离；增大缓冲池，尽量减少直接的写存储操作等。
跨中心的双活存储数据一致性如何保障？
一方面，当写入数据时，在复制过程中，数据传递是在缓存中进行的，这样做的好处是提升了性能，问题是当出现控制器节点异常宕机事件时，就会导致缓存内的数据不能写入存储中，从而造成数据的不一致，这时有没有保障单个存储数据一致性的措施？另外一方面，两个站点的存储之间的数据一致性，从缓存层、底层数据层又是如何保障的？
解析和解答
▼▼▼
■ 邓毓 某农信
第一个问题：前端节点写缓存与后端存储间的数据一致性如何保障？
存储跨中心双活中的单个存储架构分为三种：
1.物理存储的内部双控制器
比如V5000/V7000/V9000 HYPERSWAP，写存储的操作也就是写缓存的过程，写了一个控制器，控制器也会将缓存数据同步至另一控制器的缓存，只有当真正同步完，这次的写操作才算完成，当写缓存达到水位线后，会将写缓存刷入到磁盘组中，当一个控制器异常宕机时，IO HANG住一小段时间，另一控制器将接管，缓存数据也不会因此丢失，一致性得到保障；单控制器时，写缓存被禁止，之前的缓存被刷入后端存储，即使这时这个控制器也异常宕机，后端磁盘的数据完整性和一致性也得到了保障；如果不幸两个控制器的电源同时断电了，这时写缓存数据还未及时刷入磁盘组，不用怕，几乎所有存储都会考虑到这一点，都有专门的电池模块维持供电几分钟，保证缓存数据能够顺利落到磁盘组当中。
2.物理存储+存储虚拟化网关（有写缓存）
比如SVC ESC/HYPERSWAP，NETAPP MCC（叫写日志），这种架构也就是相当于在物理存储前端又加了一道控制器，也存在写缓存，相当于扩大了后端物理存储的缓存容量，写操作要先写入SVC节点，再同步至另一SVC节点，只有完全同步成功，才算做是一个完整的写周期，后面的操作也是等待写缓存达到水位线刷后端存储。佑了这种机制的保障，存储虚拟化网关的缓存与后端物理存储的数据完整性和一致性得到保障，无论是单SVC节点故障，另一节点缓存数据冗余，写缓存被禁止，所有缓存刷入后端存储，还是SVC的电源断电，SVC有专门的UPS供电模块保障写缓存及时刷入后端存储，都能完整的保障数据的完整性和一致性。这里不再赘述。
3.物理存储+存储虚拟化网关（无写缓存）
比如EMC VPLEX METRO，它只有读缓存，写缓存还是由后端的物理存储提供，所以该问题还是和前面说的类似的保障机制。
第二个问题：两个站点的双活存储间的数据一致性如何保障？
这里分两种方式来阐述这个问题：
1.一种是两个站点的主机识别的是相同的VOLUME
比如：SVC ESC、EMC VPLEX、HDS GAD等，两个站点的主机对这一个VOLUME写操作时，数据被刷入两个镜像的后端存储，这有两个存储都写完成返回，才算一个完整的缓存刷后端存储的写周期，这时两个存储从数据块角度来说，是一致的，一个站点或者存储故障，另一个站点的存储是可以接管，而不会造成数据丢失。
2.另一种是两个站点的主机识别的是不同的VOLUME
比如：SVC V7000/V5000 HYPERSWAP、NET APP MCC等，由于两个站点的主机识别的不是同一个VOLUME，必然存在存储或者存储虚拟化网关的VOLUME与VOLUME的同步复制技术，HYPERSWAP有METRO MIRROR，MCC有Syncmirror，它们的技术共同点是复制技术的一致性校验机制，更高级的有以多个卷为单位的卷组一致性校验机制，来保障跨站点的两个卷/卷组的一致性，在某站点所有控制器或者站点完全故障时，另一站点有完整的、一致的存储可以接管。
存储跨中心双活是块存储的同步，无法避免逻辑错误被同步，出现该问题又该如何防范？
数据同步逻辑错误问题：存储层面的复制技术基本以存储块为单位进行的数据复制，假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。
解析和解答
▼▼▼
■ 邓毓 某农信
这是一个很典型的问题，块存储如何防范逻辑错误。做了存储的跨中心的双活或者做了存储的镜像，同步复制，很容易就会觉得数据有两份甚至多份一致性的副本，就会觉得万事大吉，甚至觉得不需要备份系统了。
数据备份系统是企业数据安全的最后一道防线，无论做了什么同步、异步、双活还是连续性数据保护，数据备份系统都应该作为一个最稳固可靠的基础的存在，地位无法替代。
回到问题来，基于存储的复制技术，无论复制方式是同步、异步、双活还是连续性数据保护，都是基于存储数据块级别的复制技术，复制源端在可读时，会将块中的数据原样的拷贝一份至目标端，当源端数据出现误删、误改、磁区退化数据异变、数据库事物层逻辑错误等数据逻辑性错误时，复制目标端无法检测到这些错误，依旧复制“错误”的数据，导致两份副本都无法正常使用的灾难。
所以我们要有多层次的防范机制，来保障数据的可靠性和安全性，存储双活技术只是其中的一个层次，要辅以备份技术、数据库复制技术，连续性数据保护，建立了完善的数据保障体系。
（1）备份系统按照一定的时间频率对数据库做全量和增量备份，在遇到数据逻辑错误时，通过恢复将数据回退到最后一个备份版本。如TSM、NBU、COMMVAULT。
（2）数据库复制技术有实时同步、准同步、异步等方式，保障主数据库逻辑错误无法正常运行时，切至备数据库，回退到备库前一个日志COMMIT后的版本。如DB2 HADR、ORACLE ADG、MYSQL主从复制等。
（3）连续性数据保护技术也是准/实时对存储数据块做快照，源端数据无法继续使用时，通过快照回退至前一个数据可用版本。如CDP。
通常为了考虑不影响源端数据的访问性能或者单个系统无法满足需求时，可以考虑多种方式结合，比如备份系统在备份超大数据库时，没有充足的带宽或者备份时间窗口，可以用数据库的异步复制方式来做为备份方式的补充；连续性数据保护技术需要通过LVM镜像源端数据，增加了写延迟，可以通过数据库准实时同步或者异步的方式复制数据到备库节点，备库节点的后端存储为连续性数据保护的存储节点，如DB2 HADR+CDP的组合。
所以总结来看，存储跨中心双活并不是万能的，依旧需要传统的数据保障技术辅助，建立常态高效的数据保障体系，才能应对万难。
存储跨中心双活最关键、最难点就是链路质量，如何把控该风险？
双中心间通讯不可控问题：一是链路稳定状况不可控；二是IO延时指标不可控。这些不可控因素非常容易造成灾难性影响，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。
解析和解答
▼▼▼
■ 邓毓 某农信
无论什么双活，只要上升到了跨中心的层面，就必然需要跨中心的链路作为双活的通讯介质。这个通讯不但要求高可用性和冗余度，而且又对通讯质量要求又很高。并且链路所带来的风险隐患又是巨大的，中断或者响应时间高都将可能导致双活集群发生脑裂仲裁，出于保护的目的，将IO HANG住一段时间，将所有没有落入磁盘的数据全部刷盘，才继续在某个存活的站点继续恢复读写访问。所以阻碍存储跨中心双活技术发展的最直接的因素就是双中心间链路不可控。尤其对风险、稳定性要求苛刻的金融机构来说，更加不敢轻易做跨中心的双活。所以链路成为了存储双活的最难点，如何既提高链路稳定性，又保证链路的性能，还又有合理的故障保障机制，是每一个存储厂商和企业用户都要深思的关键点。
在这里我也不刻意去解决该难题，而是提出些许我的想法。
1.链路冗余度
通常我们企业做双活，都是自己购买波分设备，然后租用运营商的裸光纤，作为通讯的链路。所以波分设备需要冗余，裸光纤也要冗余，波分设备好办，购买即可。裸光纤通常租用两家或两家以上的运营商线路，比如电信和联通，电信的裸光纤也需要冗余，联通的裸光纤也需要冗余，防止单根裸光纤意外割断或者损坏。然而单家运营商的裸纤都通常在一个弱点井中，一起意外割断的事情常有，所以需要两家运营商互相冗余。这两家运营商裸纤的路线还不能一致，弱电井需要在不同的街道，并且分别走不同的路线到达目的地。所以可以看到，由于我们是租用，根本不可能要求运营商完全达到你的要求，最好的方式只能自建，成本太高，好像根本不现实。
示意图：
2.链路质量
链路质量包括光衰、抖动和带宽等。一方面，光衰和抖动无法控制，只能靠波分设备去探测，发现光衰和抖动，立即中断该链路，切向备链路，这对后端的SAN网络无感知，但对波分设备的要求很高，需要购买和建设时注意。至于带宽，可以监测，达到带宽预警阈值后，可向运营商申请提升带宽。另一方面，对于链路质量的监测机制一定要在建设存储双活或者其他双活之前建立，由于是运营商的链路，链路经过了多少中继、多少设备我们是不得知的，我们只能在波分端建立有效的监测机制，有些波分设备也有专门的监控软件支持。而且也要要求和运营商建立监测联动机制，运营商监测到链路质量（是质量而不是中断）有问题，也需要第一时间告知，做出合理的决策。
3.存储双活控制器的机制
由于跨中心的双活控制器间的通讯是实时的，完整写周期必须两个站点的控制器都完成写操作。他们间的通讯又是靠链路完成的，链路质量和链路中断都将导致性能波动甚至超时，对于中断，控制器的处理机制都还不错，对于质量，控制器的处理机制往往不够，需要长时间的尝试，才会做出合理的决策，甚至没有决策，导致上层数据库或者应用磁盘IO超时，而异常挂起甚至宕机。所以这个机制是决定好的双活体系的重要因素，有时候宁可立即放弃一边，也要保住RTO，但目前为止我还未发现双活存储控制器有好的链路质量处理机制。知道的也请分享。
4.双活存储上端的OS、应用和数据库合理的超时参数
OS识别磁盘、应用访问文件系统、数据库访问裸设备或者文件系统，存储IO HANG住，将导致层层超时，尤其是数据库，超时将彻底中断宕机，甚至出现逻辑损坏等莫名奇妙的问题。有时候超时响应慢是可以等，而不是中止，所以需要OS、数据库层进行合理的超时联动设置。
5.尽量避免跨站点读，减少跨站点写频率
没有跨站点读，就意味着本地可读，对链路质量没有要求；减少跨站点写频率，就意味着，性能影响弱化，被控制器、数据库、操作系统等层层缓存暂存的写数据，会减少跨站点写的次数，进一步弱化链路质量所会带来的影响。
存储跨中心双活带来的双中心SAN网络级联打通，是否会因局部SAN节点故障而影响整条路径？
存储网络故障泛滥问题：两个数据中心的SAN网络打通，整合为一张大的SAN网络，可能会因为局部的存储网络故障而波及到整个存储网络，造成重大影响。
解析和解答
▼▼▼
■ 赵海 某商业银行
靠ZONE隔离。
如果是IBM SVC或者是NETAPP MCC，必然要求存储虚拟化设备要和另外一个数据中心的物理存储想通。跨中心的大ZONE也就是必须的了。这种情况下，我们只能横向将ZONE划分到更细的粒度。
如果是VPLEX，那么它不需要虚拟化网关和另外一个数据中心的存储想通，而是靠两中心的VPLEX机头之间的内部连接实现交互。这种场合下双中心的SAN网络相对独立。
■ 邓毓 某农信
总结起来就是：
1.大的SAN网络用细粒度的zone隔离
2.存储双活的控制节点的通讯SAN网络和其他SAN网络隔离，建立PUBLIC SAN和PRIVATE SAN两种网络
3.核心SAN网络采用“环形”拓扑取代星形拓扑或者线型拓扑
如图：
核心SAN网络中的每个SAN节点都和其他SAN节点打通，任何一个SAN节点故障，不会影响其他核心SAN节点的通讯。外围SAN网络联通核心SAN网络中的一个节点，其故障也不会影响核心SAN节点的通讯。
■ crystalwmagic 浙商银行
可以考虑FC Routing，使用Integrated Routing License配合LSAN 使得数据中心的FC网络相对隔离，对需要打通的ZONE配置LSAN ZONE
■ zamora 系统集成公司
同意前面专家的观点引入FC Routing，使用LSAN进行隔离。与此同时引入一组边缘交换机用于两个中心之间的连接。
使用LSAN后生产中心和灾备中心的配置不会进行融合，既方便配置管理，又能隔离故障。边缘交换机还能对多个运营商的线路进行管理，故障切换，链路聚合。
■ willow 某银行
除了通过光纤交换机划分zone进行san网络的逻辑隔离外，还应该按照系统分层结构，对部分san网络做好物理隔离，防止某些前置网络故障影响整个san网络。
■ wildhorse git
通常设计上，不会将两个站点的SAN进行融合，形成两个大的跨站点Fabric。
在做设计时，会要求存储网关节点间，用于传输Cache Mirror和心跳的数据端口，连接到特定的SW或VF/VSAN，然后这些SW或VF/VSAN在两个站点实现连通。
对应大的SAN网络，跨站点的级联，中间的链路故障会导致SAN Reconfiguration，进而引起全网IO pending。
主机对跨中心的双活存储多路径访问与控制策略是怎样的？
存储多路径控制的策略问题：倘若采用存储厂商自己的多路径，可能存在兼容性问题。同时多路径策略中，对路径的选择策略是否正确是存储双活的关键点；发生存储故障切换时，主机又如何快速切换到其他存储路径。
解析和解答
▼▼▼
■ 张文正
主机对存储的控制访问策略一般就几种策略，建议还是采用存储厂商的多路径软件，再主机访问存储上设置一下，一般是主备方式，这种方式是两个hba卡，类似两条路径方式，只有这个hba卡出现问题，切换到另外一个hba卡上;另外一种就是负载均衡模拟，两条路径同时工作，一条出现问题后另外一条正常工程，现在多半采用这种模式。
■ 邓毓 某农信
目前而言最佳的多路径选择还是存储厂商自带的多路径软件，尤其是在存储双活领域，每个存储厂商的双活技术不一，厂商自带的多路径软件具备更好的、更兼容的针对其下两个跨中心的双活存储控制器的访问控制和策略切换的能力，通常所有主机都建议具有访问两个数据中心两个存储的路径，这样当其中一个存储故障时，多路径软件能够迅速识别本站点存储状态，将路径切换至另一个存储，对上层主机无感应。由于主机具备所有存储路径，但是主机只允许访问那个可以提供ACCESS的存储控制器，只有当切换时，原先不能提供ACCESS的存储控制器，具备了提供给这台主机ACCESS能力时，IO才能被转移过来。当然每家存储厂商的实现技术不一样，技术细节也不一样。也有的存储厂商能够提供针对同一主机的双活控制器，另一控制器将多路径过来的IO转发给主控制器等等。
存储跨中心双活集群的仲裁如何和上层数据库集群的仲裁结果保持一致？
集群仲裁一致性问题：所谓的仲裁一致性问题，是指双中心之间的双活存储集群和数据库集群的仲裁结果是否能保证一致性。当不一致时，对业务系统将造成灾难性影响。
解析和解答
▼▼▼
■ 邓毓 某农信
跨中心的集群仲裁也就是当两个数据中心间的所有链路都中断时，双活集群的仲裁机制，这里的双活集群可能不只是存储双活集群，也有可能包含了数据库的双活集群、并行文件系统的双活集群，甚至一些特殊应用的双活集群等。这多类双活集群在链路发生中断时，都将按照各自的集群的仲裁算法，投票选举出存活节点，倘若这多个集群的仲裁结果不是一致的，将可能会给业务系统带来灾难性的影响。这里拿存储和数据库双活举例：
存储双活集群的仲裁通常规则有两种：
1.偏好模式
偏好模式的意思就是说，按照系统或者用户的偏好，特定选择一个优先存活的站点，在发生链路中断（脑裂）时，这个站点继续存活，并拥有接管IO读写的优先权。比如说SVC的配置节点、VPLEX的分离规则或者SRDF/METRO的ACTIVE BIAS配置选项等。
2.第三仲裁站点仲裁模式
第三仲裁站点，顾名思义，也就是在除了两个双活的数据中心之外的另一个站点，来对这两个数据中心进行仲裁和选举，防范脑裂。
详细可见：脑裂风险防范
这两种模式通常都是配合起作用的，优先第二种模式。
数据库双活集群的仲裁规则有：
1.磁盘仲裁，拥有磁盘心跳的节点存活
2.节点数仲裁，站点节点数多的存活
3.磁盘和节点的共同仲裁，获得磁盘心跳，并且存活站点节点数+磁盘心跳数大于非存活站点节点数
4.IP地址最大或者最小者存活
5.实例号最小或者最大者存活
因数据库的不同，仲裁规则的算法也不同，但是大多数都会选择磁盘和节点的共同仲裁的方式作为优先的方式。
那么数据库双活和存储双活集群的仲裁一致性是如何做到的呢？
这里以EXTEND ORACLE RAC数据库跨中心双活集群和VPLEX METRO存储跨中心双活集群举例说明：
EXTEND Oracle RAC的部署重点介绍OracleClusterware仲裁文件和Witness第三个站点。也就是说，在采用VPLEX Metro的远距离群集中，Oracle RAC仍需使用Oracle Clusterware仲裁磁盘。但是，群集仲裁磁盘本身驻留在VPLEX虚拟卷上。这可以保证Oracle仲裁磁盘访问Oracle RAC的行为和 VPLEX Metro故障切换行为一致。借助VPLEX，仅VPLEX Witness部署在第三个站点
1.如果只有Oracle互连链路中断（不是真正的站点故障，且不影响 VPLEX 互连），则 Oracle Clusterware将根据多数节点及仲裁磁盘访问进行重新配置。
2.如果是VPLEX互连链路中断（或真正的站点故障），VPLEX将根据站点分离规则的首选项和Cluster Witness指导，立即允许IO在一个群集恢复。因此，仅当VPLEX恢复仲裁磁盘上的I/O时，这些 Oracle 群集节点才有权访问这些仲裁磁盘；而且Oracle Clusterware将相应地重新配置群集。尽管仍需要仲裁磁盘，但无需部署在独立的第3个站点中，因为VPLEX Witness可提供Split-Brain保护并保证Metro 和Oracle Clusterware的行为一致。此外，由于VPLEX Witness控制仲裁文件的访问，因此可跨独立Oracle RAC部署和相关上游用户应用程序保证一致的确定性行为。
■ ytskfzj 天宝合力
1、没有做过跨中心，包含业务和存储双活的实际案例
2、愚见：存储双活出现问题主要故障场景是网络/硬件，业务双活主要故障场景应该是网络/硬件/软件，针对网络故障，把2个仲裁放在一台设备上就可以解决，比如HyperSwap的JAR和Oracle的iSCSI vote；存储硬件/业务软硬件因为内部结构的不开放性，暂时未听说有比较全面集成解决方案，这个时候或许可以考虑只用一个仲裁，比如Oracle RAC，底层不做存储双活改用fg来做冗余，配置FG的优先本地读取来提高性能。边缘应用也可以考虑使用VMWare Metro Storage Cluster 来做容灾，存储只需要做复制即可。
■ wildhorse git
双活的站点存活，从技术角度看，要根据当时谁抢占到第3站点仲裁来决定谁能存活。即，每个站点都有50%的机会。
但结合数据库，尤其是Extended RAC，要结合Oracle脑裂规则来进行相应设计。通俗的说，就是要跟Oracle RAC的脑裂机制保持一致性，确认大家都押宝在同一个方向上。在中间链路故障导致脑裂出现时，RAC选择在实例ID小的一边活。此时，押宝在ID小的站点即可。风险就是ID小的站点挂了，另外一个站点需要人为的做恢复。
存储双活通常是作为一个集群的存储，如何对这个双活集群进一步保护？
存储双活后的集群保护问题：通常存储双活的所有存储节点都在一个双活集群当中，倘若这个集群软件出现重大故障或者BUG，两个站点的存储都将无法访问，所以这个双活集群的保护也是个难点，如何结合其他灾备技术实现双活集群的灾备保护，实现两地三中心甚至多地多中心的灾备架构。
解析和解答
▼▼▼
■ 邓毓 某农信
有些存储跨中心双活方案是通过镜像复制技术（VDM、MetroSync、SyncMirror、TrueCopy等）将底层两个存储虚拟成一个虚拟卷，再挂载给上层的主机，由于这个卷是虚拟的卷，底层存储有可能无法脱离这个虚拟化（集群）而单独挂载给主机使用，所以这个虚拟化（集群）软件的可靠性和稳定性就变得非常重要了，如果出现重大软件BUG或者这个集群的所有节点先后故障，就将造成数据丢失的重大风险。当然这种问题出现十分罕见，但对于数据的安全性，是企业最为重要的资产，是企业的生命，所以我们也不能大意，依旧需要一套完善的集群保障体系和数据保障体系。
通常可以把这种双活集群的保护分为三种：
一种是虚拟化网关+底层存储的复制技术
通过虚拟化网关实现的存储双活，虚拟化网关的集群保护就需要靠虚拟化网关自身自带的数据保护体系，或者底层存储的数据保护体系，比如说SVC ESC是基于VDM的复制技术实现的双活，再配备SVC METRO MIRRO或者GLOBAL MIRROR实现两地三种的数据级容灾，当SVC ESC的双活集群完全不可用时，可以将SVC切至容灾端就行数据的恢复，保障数据的安全。又如VPLEX METRO或者VPLEX GEO双活，由于这套架构本身就是两套集群，两套集群同时故障的可能性更小，几乎不需要再对VPLEX METRO再做集群的保护，如果要做异地的话，可以通过VPLEX底层的存储，比如EMC VMAX的SRDF再做一份数据至同城或者异地容灾端，或者DS8000系列的MM或者GM再做一份数据至同城或者异地。前面SVC ESC的容灾保护体系适合所有的高中低端存储，直接通过SVC的容灾技术就实现了两地三中心+存储同城双活，而后面的VPLEX要实现集群的进一步保护，需要底层高端存储的同步复制技术的支持。
第二种是底层存储复制技术
直接通过底层存储控制器实现的双活，是需要专有存储或者高端存储的支持，再进一步实现两地三中心整体架构，也是需要在原有双活复制技术之上，将数据异步扩展至异地，或者支持多份数据同步技术。
第三种是上层应用/数据库的复制技术
对于这种方式的保护也是非常多案例的，既起到从数据库事物层方式起到数据逻辑性保护的目的，又达到了对双活集群的容灾目的，像DB2 HADR和ORACLE ADG超异步，ORACLE的far sync复制已经支持跨超远距离的异步复制了。
■ willow 某银行系统工程师
这类集群软件重大故障，大多由数据中心之间通讯链路不稳定、第三方仲裁站点失效、存储上层数据同步逻辑错误等问题引发。因此，可以考虑如何通过相关手段防范这几点隐患。如对通讯链路进行实施监控，做好主备管理，防止链路抖动等
■ chengzuqiao 某农信
一般来说，集群出现问题，不会影响数据的安全，但是会影响业务。如果你想对数据在存储双活的层面再保护一次，那要看你采用了系统层、存储虚拟化层、存储底层等那种双活技术，每种技术都有缺陷，没有完美的技术，如果是那样，技术就不会发展，所以这要看你采用了何种层面技术，然后综合评估性能、成本，最后考虑数据保护技术，技术永远都不是问题，问题是money 和必要性。
■ wildhorse git
比较好的办法是双活数据中心上的应用或数据库做应用层的复制到远端数据中心。通常双活方案+异步容灾，只能保证底层数据块层的一致性，无法确保应用数据是否可用，数据库是否可回滚。
对于双活的方案，带来的好处是显而易见的。但是微码故障，不会因为是一个集群模式或两个集群模式而降低微码风险。远有北美大型客户的Metro集群同样由于微码原因一起趴下，近也有国内南方某银行非核心系统同样出现类似问题。
存储跨中心双活方案如何和私有云的存储方案相结合？
存储双活方案如何有效和私有云存储解决方案相互结合，是个需要考量的问题。
解析和解答
▼▼▼
■ 王天恩 电信
1、存储跨中心双活方案，此意指基于存储层面的灾备；
2、私有云的存储方案，此意是指私有云数据中心建设中底层数据存储的建设方案；二者结合可以从这样的角度考虑，一是私有云数据中心中存储一般是要进行统一的池化，后期可以进行统一分配和管理，而存储跨数据中心双活泛指的含义相对较多，如可以进行云灾备，如私有云与公有云之间的底层存储的灾备，也可以是某行业垂直机构中私有云基地对其下属企业间数据中心之间的业务底层数据灾备等等吧！
■ willow 某银行
私有云存储大都采用了集群分离方式部署的高可用架构，而跨数据中心的云存储双活，要在两端有效部署私有云存储的双活，需要注意的问题也要复杂很多，比如：如何保证在实施了双活后，私有云存储中数据可以足够分散；如何实现存储数据的容量均衡，使每个存储设备数据达到另一个相对平等的水平。
■ 邓毓 某农信
当今是云时代，各种私有、公有和混合云，所以传统的存储跨中心双活方案如何和私有云方案相结合是个需要考虑的点，也是个难点问题。
当前最火的私有云基础框架当OPENSTACK莫属，OPENSTACK通过CINDER-VOLUME组件实现对VOLUME PROVIDER的调度和管理，当然这个VOLUME PROVIDER是有要求的，必须能够支持被CINDER-VOLUME DRIVER。而不同的基于OPENSTACK架构的开源私有云或者商用私有云都集成了不同的DRIVER，所以他们所能够支持存储也是不一样的。通常而言分为三种结合方式：
1.通过CINDER DRIVER直接驱动的
如POWERVC目前支持VMAX、VNX、SVC、V7000、V3700、DS8000系列等，公版OPENSTACK必须集成不同存储VOLUME PROVIDER的DRIVER才能调度它们。这种方式下，如果底层存储能够实现双活，比如VMAX SRDF/METRO，或者SVC、V7000和DS8000 HYPERSWAP等，必须针对这些特性，针对性的调用DRIVER API，来实现IAAS私有云管理平台对双活存储特性的接管。比如POWERVC自1.3.0版本，已经支持SVC VDM技术了，可以在部署SVC VOLUME的同时，做VOLUME DISK MIRROR，实现SVC ESC，当然这也需要提前搭建好SVC ESC架构，并将相应的MDISK POOL被POWERVC管理。公版OPENSTACK为了实现这些双活存储特性，也是类似，只是针对性开发调用这些DRIVER API即可。当然如果底层存储是SVC的话，SVC下层的存储无需具备双活特性，也可以通过SVC实现存储的双活，并很好的纳入到POWERVC私有云体系当中。
2.间接使用双活存储的
比如POWERVM的SSP，或者VMWARE的STORAGE POOL，都是预先将存储资源分配给主机，并且所有主机共享这些存储资源，然后上层的POWERVC或者VCENTER直接利用这些划好的存储卷去创建虚拟机或者挂载给虚拟机。如果要和底层双活存储资源结合的话，必须要求是两个跨中心的存储通过存储网关或者自身控制器虚拟化成一个VOLUME，这个VOLUME再挂载给两个数据中心的POWERVM VIOS或者EXSI主机，如果这两个双活存储分别创建了资源池，经过虚拟化后，并映射给所有POWERVM VIOS集群的主机或者EXSI集群的主机，实现所双活存储资源池的共享。这种方式下的POWER IAAS私有云和VMWARE X86私有云无需实现对底层存储双活特性的DRIVER API，直接像使用单个存储一样即可，因为底层双活存储已经事先做好了整个双活存储资源池，并完成了卷的分配和挂载。
3.通过OPENSTACK HEAT组件实现存储的编排的
这种方式，不像前两种方式，要么通过特定的存储DRIVER API实现双活功能的调用，要么间接使用已经搭建好双活架构的存储卷。通过OPENSTACK HEAT的编排，实则为调用存储的双活卷创建脚本来完成对双活存储特性的接管，但是有一个前提是，必须存储双活必须支持CLI命令行的方式，或者能够间接通过像类似TPC的存储管理工具，实现双活卷的创建和挂载。这种方式下，只需主机与底层存储建立好FC连接，其他的工作，全部交给OPENSTACK HEAT组件和其他OPENSTACK的核心组件。
以上三种方式，各有利弊，第二种方式是最简单的，但对双活存储的机制是有要求的，只能是两个双活存储虚拟成一个VOLUME；第一种方式是最合理的，因为是否创建双活卷可以在用户的掌控下，但是公版OPENSTACK需要专门定制化开发，商用OPENSTACK即使具有该功能，也只是针对特性存储；第三种方式是最灵活的，可以灵活运用存储CLI去搭建底层存储，但是需要存储双活能够支持CLI命令搭建，并且实现难度可能很大，OPENSTACK HEAT编排不一定能够完成。
长按二维码关注公众号