存储双活架构设计规范.docx

《存储双活架构设计规范.docx》由会员分享，可在线阅读，更多相关《存储双活架构设计规范.docx（25页珍藏版）》请在第一文库网上搜索。

1、存储双活架构设计规范我们知道，对于容灾架构来讲，脑裂是灾难性的事件。如果从一个统一集群的调度变成两个相互独立的集群调度，意味着双方的写操作相互也是独立的，但是他们的存储空间是共享的，AA模式下通过锁机制控制并发，HA模式下通过存储卷的OWner控制写的权限。但是独立之后意味着两个集群可以随时写入同样的存储地址，必然会造成脏写脏读等一系列数据不一致事件，这对业务来讲是灾难性的。那么存储双活架构的设计当中，应该采用什么样的设计思路或者是方法才能避免这种情况的发生？四：为避免脑裂，存储双活架构设计应遵循哪些思想和方法？本次议题将由本人以及江西农信运维技术经理邓毓、哈尔滨银行系统专家团队存储管理员张鹏

2、分别主张议题下的相关关键点，几位专家的主张在某农信资深技术经理雷智、宁夏银行技术经理陈明福的复议后，最终形成一定的共识供同行参考。社区专家主张赵海某金融系统高级主管：每一种集群都会有相应的解决方法，通常可以通过节点优先级及仲裁的方式来解决，但是我们在利用这些策略进行架构设计的时候必须知道其原理以及最佳实践的方法。容灾设计过程中避免脑裂问题的思路-默认优先级解决方案以两个节点的OraC1eRAC为例来讲，Orac1eRACASM管理模式下，磁盘组通常有三个(+DATA,+FR,+OCR),在OCR磁盘组当中所有的磁盘中存储的数据包括两部分,一部分是VOteFi1e,另夕I部分就是OCR(Orac

3、1eC1usterRegistry)oVoteFi1e是用来记录集群节点的磁盘心跳信息,而OCR是保存集群配置信息的数据。VoteFi1e,以整个文件的方式存储在OCR磁盘上，不做任何条带。表1是其信息记录的一个说明。表1Orac1e仲裁逻辑信息表1是一个三节点的OraC1eRAC集群的VOteFiIe的一个示意矩阵，每一行是一个节点的写入的信息，例如第一行，InStanCe1分别把其对集群中的三个成员（1、2、3）进行私网检测的结果写入到仲裁文件当中，InStanCe2、Instance3同样把其检测结果写入仲裁文件，最终组成了三个节点的仲裁矩阵。当私网发生故障导致网络上导致集群分割为几个孤

4、岛子集的时候，在网络心跳同票数情况下，仲裁算法有两个非常重要的规则：一、保障隔离后的集群子集中节点数目最多的子集存活。二、当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。当两个节点的OraC1eRAC集群面临私网故障的时候，必然会遵循以上规则，从规则内容上可以看出，第一条规则基本没有什么意义，双方的资源是对等的；但是第二条规则直接决定了集群的最终状态，那就是实例号小的节点成为新的集群，这就避免了脑裂的存在。所谓资源失衡配置解决方案，就是要在容灾设计之初就保障主数据中心的资源配置要多于灾备中心，从而使得两个数据中心节点可以获取到的仲裁资源处于不平衡状态。图1资源失衡架构如图1所示，容

5、灾设计的时候可以将主备数据中心的节点分布数量或者仲裁文件分布数量按照2:1的非平衡策略设置。那么按照集群仲裁的一般规则：发生集群分裂故障的时候，可以获得更多仲裁资源的子集将成为新的集群。当发生数据中心之间的网络故障的时候：1）主数据中心内部两个节点可以获取到更多的网络心跳，自然会接管集群。2）主数据中心的节点可以获取到更多的磁盘心跳，同样会接管集群。这也符合我们设计之初衷。但是，这种方法只适合于AA模式的多节点集群，不适合HA模式的架构。自定义优先级的解决方案，其实本质上与OraCIeRAC的仲裁算法第二条“当隔离后的集群子集获得的仲裁票数相等时，保障实例号小者存活。”是一样的。只不过对于Or

6、aC1eRAC,当通过第一条规则无法判断的时候（节点获取的仲裁资源矩阵是平衡的），它默认采用了实例号定义其优先级。图2自定义优先级架构而其他的一些容灾方案，这个优先级定义的灵活性留给了客户。例如图2当中的VP1EX产品，尤其是在双活架构的设计当中，有可能因为地域、设备新旧、运营管理等方面的差异，导致灾备中心的运行能力会稍差，那么发生数据中心之间隔离的这种故障时，大家往往希望保留主数据中心的运行。这个时候客户就可以根据主数据中心的节点标识来固定其仲裁优先级。仲裁解决方案O网络仲裁网络资源是集群仲裁当中非常重要的一种心跳资源，因此通过第三方网络资源的可达性心跳信息来判断对称集群分裂后的新秩序也是一

7、种非常有效的方法。一般在以存储网关实现数据双写的容灾架构当中比较常见，比如VP1EX、SVC.MCC等。具体原理如图3所示:图3三方网络仲裁架构第三方仲裁点需要满足的条件：与主备两个数据中心13可达，并且网络质量稳定。仲裁点一般需要安装具备网络探测功能的虚拟服务器或者物理服务器，具备运行条件。如图3所示，仲裁点服务器上的软件会与组成集群的存储器网关两个节点分别发送PING/ACK来确认双方的健康情况，集群会把两个节点与第三方仲裁点的网络仲裁心跳看做是最终的裁判。Vp1exWitness通过管理IP网络连接至两个集群节点，通过将其自身的观察与集群定期报告的信息进行协调，让集群可区分是集群内故障还

8、是集群间链路故障，并在这些情况下自动继续相应站点上的I/O服务。Vp1exWitness仅当分离规则没有定义时才会生效。当然细心的读者可能产生了一个新的问题：如果数据中心与第三仲裁站点的网络发生故障，那会不会影响集群本身的运行？什么是仲裁？仲裁是只有发生集群隔离故障的时候才会起作用，如果没有发生数据中心之间的隔离故障的时候，即使他们的一方或者双方于第三方仲裁站点发生网络暂时中断的事件，也不会对既有集群造成任何健康影响。我们需要做的是保障第三方仲裁资源在发生故障的时候有效就可以了（监控&及时修复）。O存储仲裁存储一般是数据库集群当中非常关键的仲裁资源，数据库集群的节点负载比较重，不像存储网关模式

9、的集群，可以再设计与WitneSSNOc1e的通讯接口。所以在这类技术方案的容灾设计当中，通常会用第三方存储阵列来作为集群的第三方仲裁点。例如OraC1eExtendedRAC、HA&Orac1e.HA&DB2等。具体原理如图4所示：图4三方存储仲裁架构1）第三方站点放置一个存储阵列、并且与两个数据中心网络稳定可达。2）存储阵列以NFS或者ISCS1方式提供共享存储卷或文件服务给两个中心的集群节点。3）集群配置的时候，将这个共享存储卷或者文件作为集群的磁盘仲裁之一。当双中心的集群发生隔离故障的时候，集群通过第三方的仲裁磁盘或者文件来判断集群的新秩序。O对称隔离场景集群发生的故障场景有很多，有可

10、能是网卡故障导致节点隔离，也有可能是链路问题导致节点隔离。链路问题本身又分很多种，有一种场景即使存在第三仲裁的场景下，依然有可能是对称平衡的状态。如图5所示：图5对称隔离架构如图5所示，当两个中心之间的链路中断，但是其他各条线路都完好无损的情况下，及时存在第三方仲裁，那么集群分裂后的仲裁资源分布依然是平衡对称的，这又该如何解决呢？一般认为有两种解决方式:1）优先级定义解决方案，也就是说我们在第二节提到的解决方案必须成为容灾设计的必选项。2）仲裁争夺方案，无论是三方的网络仲裁还是存储仲裁，假设出现集群隔离故障后各个节点开始争夺这个资源，那么必然有先后顺序之分，以先到先得的规则来重新定义集群新秩序

11、。这种方案尤其适用于以HA模式的容灾架构。当然具体如何争夺，如何确认争夺维度及结果就需要根据不同产品架构来探讨了。仲裁冲突解决方案o什么是仲裁冲突？我们知道在容灾整体设计当中，需要有网络层、计算层、数据库服务层、存储服务层等各方面的设计。他们在纵向上是叠加的形态，如图6所示。图6仲裁冲突示意图图6是我们将容灾设计当中纵向抽象出来的几个功能层，其中数据跨中心复制是实现双活容灾的前提条件，它是支撑网络及计算层具备容灾意义的基础，那么如何实现数据复制，我们在企业容灾选型指南-2：数据复制技术当中介绍了很多方法，基本上集中在数据库层和存储层去实现。假设我们采用了存储层的数据复制技术，存储层提供的虚拟分

12、布式卷对于数据库集群来讲是透明的。当数据中心之间发生线路故障的时候，数据库集群和存储网关组成的集群是两个不同的集群，他们的仲裁结果会不会不一致？集群的仲裁是瞬间完成的，其触发条件有可能有片刻的先后顺序之差。数据库层的仲裁先于存储层的仲裁，那么虽然概率小，但是这个冲突是完全有可能的。但是如果存储的仲裁发生在数据库之前，理论上这个冲突是可以避免的，因为存储卷是数据库集群健康运行的前提。如何解决仲裁冲突问题？以OraC1eRAC和VP1EX结合的架构为例，我们探讨它的解决方法。风险发生的引发点有两个：1）集群的仲裁触发条件导致的仲裁顺序发生紊乱；2）对称平衡状态下的仲裁规则冲突。资源被1:1割裂之后

13、的默认仲裁策略不一致。也就是说，只要控制这两个引发点，这个问题从理论上也就避免了。对于第一个引发点来讲，实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以我们只要将misscount这个参数调整到15秒之后，也就是说理论上绝对保障存储集群仲裁在前，数据库仲裁在后，那么第1个引发点就没有了。对于第二个引发点来讲，假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Wirmer策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么第2个引发点也就不存在

14、了。邓毓江西农信运维技术经理：为防止脑裂发生给企业生产业务带来重大影响，存储跨中心双活方案设计的架构设计和解决思路必须两面抓，一面是“防”，一面是“解”。存储双活模式下，脑裂问题简单说就是两个数据中心间的网络和存储链路同时发生中断，导致两个数据中心内的应用、数据库或者操作系统同时抢占和利用共享的资源，造成资源的数据不一致，产生重大影响。这个问题是在存储跨中心双活方案设计、实施阶段不可避免要遇到的。遇到该类问题时，通常的架构设计和解决思路有两个方面，一方面是“防”，另一方面是“解o“防”主要是防止脑裂问题的发生，防止两个数据中心间链路全部中断，将产生脑裂问题的根源掐断。在故障场景下，只要两个数据

15、中心间能够存在链路通讯，就不会有进一步的脑裂问题产生。“解”主要是解决脑裂问题的发生，利用合理、充分的仲裁机制，以极短的故障恢复时间和几乎为零的故障恢复目标，解决脑裂故障灾难。“防”方面：1）增加链路冗余度：存储双活模式通常是企业自己购买波分设备，然后租用运营商的裸光纤作为通讯的链路。所以波分设备需要冗余，裸光纤也要冗余。对于波分设备购买即可。裸光纤通常租用两家或两家以上的运营商线路，比如电信和联通。电信的裸光纤也需要冗余，联通的裸光纤也需要冗余，防止单根裸光纤意外割断或者损坏。然而单家运营商的裸纤都通常在一个弱点井中，一起意外割断的事情常有，所以需要两家运营商互相冗余。这两家运营商裸纤的路线

16、还不能一致，弱电井需要在不同的街道，并且分别走不同的路线到达目的地。2）增强链路监测：对于链路的监测机制一定要在建设存储双活之前建立。由于通常是租用运营商的链路，链路经过了多少中继、多少设备企业是不得知的，企业只能在波分端建立有效的监测机制，有些波分设备也有专门的监控软件支持。而且也要求和运营商建立监测联动机制，运营商监测到链路质量有问题，需要第一时间告知企业，再做出合理的决策。“解”方面：在存储双活方案中，防范脑裂通用的做法就是使用仲裁机制，在第三站点放置仲裁服务器或者仲裁存储阵列。通常有以下四种方式：1）优先级站点方式。这种方式最简单，在没有第三方站点的情况下使用，在发生链路中断脑裂现象时，从两个站点中选一个优先站点，发生脑裂后优先站点仲裁成