详解容灾恢复过程中跨数据中心级的关键故障切换

1.容灾设计需要进行故障切换的场景容灾设计过程当中需要考虑的故障切换的场景有很多，数据中心内部的高可用切换不在本次讨论范围之内，我们讨论的是容灾恢复过程中的关键跨数据中心级的故障切换场景，从网络层到存储层都会涉及到，其主要涉及如下几个方面：①网络层故障切换（路由、DNS、交换机、负载均衡）。②应用服务计算层故障切换（应用APP）。③数据库服务实例层故障切换（数据库Instance）。④数据副本层故障切换（数据副本）。2.网络层的故障切换策略2.1网络流量路径分析如图所示，来自客户端的流量访问会分为两个过程：1、客户端需要获取到业务系统的地址信息。通过路由交换机找到域名解析设备得到业务地址信息。2、客户端利用获取地址和应用服务端口与应用服务建立Socket连接，然后交互通讯。2.2域名解析层主中心故障场景切换策略省略掉中间的交换机设备信息，我们将通常的AA容灾架构的网络层抽象为上图所示框架。客户端保存两个DNS地址，根据网络线路的健康状况，由客户端操作系统选择第一步地址请求的DNS服务器地址，每个数据中心的DNS服务器一般会通过HA方式来避免设备的单点故障。同时DNS服务能够实现智能动态解析，也就是说它可以根据负载均衡(LB)层的健康检测信息来判断解析结果是主数据中心地址还是备数据中心地址。对于LB层与物理应用(APP)层的交互来讲，一般是以数据中心为界划分为两个不同的LB资源池，相互不能在L2网络层交互。这里大家可能有一个问题：为什么不把LB层规划为一个大的资源池，增加资源选择的灵活性（如下图）？其实从容灾的角度来看，相互独立的小集群LB资源池和跨数据中心的大集群LB在容灾切换功能都是合格的，APP节点故障无论是在大集群和小集群架构下，都可以合理切换。但是如果建立跨中心的大集群会增加对跨数据中心L2网络的过度依赖(L2的打通、横向流量的控制、ACK数据流的控制等)，增加网络架构复杂度，而且LB之间的会话同步也无法得到像小集群那样的质量。

最关键的问题，这样的架构导致DNS或者LB提供的业务地址VIP只有一个，对于同样地址的数据请求，客户端如何知道该走哪个路由？除非客户端是互联网客户端或者也是隧道技术框架的一个节点。接下如上图，来看故障场景下的切换策略。1、如果DNS层发生单边功能不可用，容灾切换机制是什么？这个故障可能是由单边入口出口路由故障、单边交换机故障、单边DNS服务设备层导致，总而言之最终的结果就是客户端到DNS地址不可达。那么这个时候就需要客户端操作系统自身的域名解析机制来进行动态切换，把DNS解析服务地址切换到备用侧，导致客户端到DNS地址请求的数据量发生切换。2、如果LB层发生单边资源池功能不可用，容灾切换机制是什么？这个故障可能是由单边LB集群服务节点、单边资源池节点等因素导致，总而言之最终的结果就是单边LB集群的业务VIP服务不可用。这个功能层故障信息会反馈给上层的DNS层（两个数据中心的DNS），无论是由谁来解析，一定能探测到下层LB资源的健康状况，那么根据这个健康状况来选择将客户端的业务请求指引到哪个数据中心，如果是LB层整体均健康，那么会有两种选择1或者是2（如图）。这时候有一个新的问题：

如果是线路故障导致左边数据中心DNS不可用的情况，虽然LB-Cluster-1资源池是健康的，如果把数据流引入的话，网络路径照样不可达，业务就中断了，如何解决？

这就要求DNS功能层不仅仅与下边的LB具有健康联动的能力，同时还要具备与上层线路的健康联动能力。综合这两类健康信息才可以做出正确的判断。这个时候可能又有新的问题了：

那DNS直接解析为自己数据中心的LB资源池就可以了，干嘛还要那么复杂，将数据流指向左边数据中心的LB资源池？

如果是左边的DNS和右边的LB发生的交叉故障，及时其他功能层都完好，那么也会面临业务中断，整体的高可用性就会大打折扣。3.应用服务层的故障切换策略我们讨论的应用服务层是不带任何业务数据、缓存、状态信息的应用节点层。如果是缓存，可以作为数据层元素单独讨论，如果是由会话数据或者状态数据需要保持的情况，可以通过应用改造或者考虑缓存架构放在数据层考虑。如果是这种前提下，那么应用服务节点的故障就没有必要讨论了，因为在LB层的切换已经解决了这个问题。接下来我们探讨如果是互联网架构下跨数据中心集群架构场景：这种环境下的容灾，在应用层就不必担心会话、状态、缓存信息的保留了。因为APP服务节点采用多个的原因在于负载的分担，容灾切换完全可以通过APP在VM集群内部进行漂移。当然这种容灾策略的可行性还需要两个前提条件：①数据中心之间的L2层的打通，目前隧道技术相对比较成熟。②数据层的双副本或者多副本技术（如分布式存储技术），毕竟状态、会话、缓存也是数据。4.数据库服务实例层的故障切换策略4.1AS数据库服务模式对于类似OracleDB模式的AS服务模式，那么一般会有两种切换方式:FailoverandSwithover。Failover是指主库发生故障暂时不能恢复的情况下，主备库进行的主备切换；Switchover一般是指计划内的维护事件所需，将主备库角色切换，数据同步方向切换。容灾故障场合下的恢复切换一般是指Failover，因此我们探讨的也是Failover的情况。如图所示，主库对外服务地址10.8.120.101，备库对外服务地址10.8.130.101；两个服务地址网络L3可达即可，客户端地址到两个服务地址也是L3可达即可，切换之后备库角色变为主库。①切换过程：备库->切换->主库->检查状态，原主库脱离DG架构；②应用场合：当主库发生严重故障不可逆转的时候可以使用Failover；③RPO：如果用最大性能模式或者最大高可用模式配置的DG，极有可能丢失数据。具体的RPO要看网络之间的传输质量和传输的重做日志多少等因素。因此建议人工干预这种操作。④网络条件：L3可达。⑤应用切换请求方法：DB域名连接方式，动态切换解析地址；数据连接客户端配置动态数据库连接（例如Oracle）。4.2HA数据库服务模式所谓HA数据库服务模式是指通过操作系统HA软件结合数据库服务实现的容灾架构，架构设计之初是为了实现各类应用服务的本地服务器高可用，但双活容灾技术兴起之后，也常常被用来作为近距离（百公里内范围）双活容灾的数据库服务架构。例如IBM的HACMP与DB2、Oracle结合、例如HPServiceGuard与Oracle结合等。如图所示，数据库服务对外提供服务的地址只有一个VIP，是跨中心组成HA的两个实例节点的虚拟地址，借助跨数据中心L2的网络环境，VIP可以漂移到任何一个物理节点上。当主中心数据库服务实例DB-instanceA侧发生故障（网卡、服务器、SAN连接）时，根据HA的集群仲裁规则，DB-instanceA可以获取到的仲裁资源（网络心跳、磁盘心跳）一定小于DB-instanceP，这个时候，集群会发生AP切换，集群执行以下动作让DB-instanceP接管数据库服务：1、将虚拟VIP绑定到DB-instance-P的物理网卡；2、将共享存储卷从DB-instanceA上卸载，并在DB-instanceP上挂载；3、将共享存储卷上的服务在DB-instanceP上启动并激活对外提供服务。注意：这3个步骤，尤其是2&3两个步骤是需要一定切换时间T的（分钟级），这意味着RTO不会为零，应用会产生一定的中断，因此整个容灾架构的RTO>T，这是需要在设计时充分考虑的。4.3AA数据库服务模式所谓AA模式的数据库服务就是以OracleRAC、DB2pureScale为代表的双活集群架构，同样它们的设计初衷也是为了解决数据库服务本地高可用的解决方案，后来衍生为ExtendedRAC之类的容灾架构。从架构本身来看，与HA架构有些类似，差异的地方在于AA模式是两边的节点都是Active状态，都可以进行读写，并发控制由缓存同步及锁机制来协调。如图所示，数据库服务对外提供服务的地址只有一个VIP，是跨中心组成集群的两个实例节点的虚拟地址，借助跨数据中心L2的网络环境，相互之间可以交换缓存信息、锁信息以，从而保障两个实例均可以激活状态进行数据的读写。当主中心数据库服务实例DB-instanceA侧发生故障（网卡、服务器、SAN连接）时，根据集群的集群仲裁规则，DB-instanceA可以获取到的仲裁资源（网络心跳、磁盘心跳）一定小于DB-instanceB，这个时候，集群不会发生任何切换，只是将DB-instanceA置为离线状态，不再接受任何读写事务。所有向DB-instanceA请求的事务均被集群分发给DB-instanceB，这个过程对应用是无感知的。因此我们基本认为RTO为零。5.存储层的故障切换策略5.1存储网关服务模式所谓存储网关模式，我们在《企业容灾选型指南-2：企业容灾的数据复制技术》当中介绍过，就是在物理存储层之上增加一层网关技术，用以形成存储资源透明抽象层，形成虚拟存储卷对外提供服务。根据物理引擎的服务方式不同，又分为HA和AA工作模式两种。但是因为他们对外提供的服务是存储服务，对数据服务层和应用层没有任何影响，存储服务连接的地址SAN环境识别的存储卷的WWN，而这个WWN是可以通过ServiceInstance-1&2上面的Port同时以多链路的方式提供给上层数据服务层，因此存储网关层的故障切换对上层是透明的。如图所示，在这个问题讨论的时候，我们不在分别说明HA和AA两种模式下的网关节点切换。因为本质上他们都一样，只是在缓存的处理和存储卷的控制权限上的策略有一些区别：HA模式：首先，服务节点上的IO缓存一般可以做到实时同步，如果不能实时同步或者同步不完全，那么缓存会有一些丢失，只是需要在ServiceInstance-2激活之后，系统需要做一些恢复工作（通过事务日志等手段）；然后，将虚拟卷的读写控制权交给ServiceInstance-2，当它成为虚拟卷的Owner之后，负责后续的IO，根据两边存储设备的健康状况选择双边落盘或者是单边落盘。AA模式：这种模式下没有任何所谓的网关节点切换，只是所有本来由ServiceInstance-1服务的IO需要重新排队到ServiceInstance-2，中间几乎没有中断，因为两个节点的缓存本来就是全局缓存，连个节点对虚拟卷的读写权限本来就是共享开放的。只是原来需要分担给ServiceInstance-1服务的部分IO，这个时候需要自己跨中心写入到主中心的