《详解容灾恢复过程中跨数据中心级的关键故障切换.docx》由会员分享，可在线阅读，更多相关《详解容灾恢复过程中跨数据中心级的关键故障切换.docx（9页珍藏版）》请在第壹文秘上搜索。
1、1 .容灾设计需要迸行故障切换的场景容灾设计过程当中需要考虑的故障切换的场景有很多，数据中心内部的高可用切换不在本次讨论范围之内，我们讨论的是容灾恢复过程中的关犍跨数据中心级的故障切换场景，从网络层到存储层都会涉及到，其主要涉及如下几个方面：网络层故障切换（路由、DNS,交换机、负载均衡）应用服务计算展故障切换（应用APP）.数据库服务实例层故障切换（数据库InStanCe）.数据副本层故障切换（数据副本）2.网络层的故障切换策略2.1 网络流路径分析如图所示，来自客户端的流量访问会分为两个过程：1.客户端需要获取到业务系统的地址信息.通过路由交换机找到域名解析设备得到业务地址信息.2.客户端
2、利用获取地址和应用服务端口与应用服务建立S。Cket连接，然后交互2.2域名解析层主中心故障场景切换策Bg省略掉中间的交换机设备信息，我们将通常的AA容灾架构的网络层抽象为上图所示框架.客户端保存两个DNS地址，根据网络线路的健康状况，由客户端操作系统选择第一步地址请求的DNS服务器地址,每个数据中心的DNS服务器一般会通过HA方式来避免设备的单点故障.同时DNS服务能够实现智能动态解析，也就是说它可以根据负载均衡(1.B)层的健原检测信息来判断解析结果是主数据中心地址还是备数据中心地址.对于1.B展与物理应用(APP)孱的交互来讲，一股是以数据中心为界划分为两个不同的1.B资源池，相互不能在
3、1.2网络层交互。这里大家可能有一个问题：为什么不把1.B层规划为一个大的资源池，增加资源选择的灵活性(如下图)？alOlTD9-1.2-UHOmwH-j(rhl)(r)(F)(r*1(p*3)I*HA4这种环境下的容灾，在应用展就不必担心会话、状态、缓存信息的保留了,因为APP服务节点采用多个的原因在于负载的分担，容灾切换完全可以通过APP在VM集群内部进行漂移.当然这种容灾策略的可行性还需要两个前提条件：数据中心之间的1.2层的打通，目前随道技术相对比较成熟.数据层的双副本或者多副本技术(如分布式存储技术)，毕竟状态、会话、缓存也是数据.4 .数据库服务实例层的故障切换策略4.1 AS数据
4、库服务模式对于类似OraCIeDB模式的AS服务模式，那么一般会有两种切换方式:FailoverandSwithover.Failover是指主席发生故障暂时不能饮豆的情况下，主备库进行的主备切换；SWitCh。Ver一股是指计划内的维护事件所需，将主备库角色切换，数据同步方向切换.容灾故障场合下的恢且切换一般是指Failover,因此我们探如图所示，主阵对外服务地址10.8.120.101,备库对外服务地址10.8.130.101;两个服务地址网络1.3可达即可，客户端地址到两个服务地址也是1.3可达即可,切换之后备库角色变为主库. 切换过程：笛库-切换-主庵-检查状态，原主库脱离DG架构;
5、 应用场合：当主库发生严正故障不可逆转的时候可以使用Failover;RPO:如果用慑大性能模式或者最大高可用模式配置的DG,极有可能丢失数据.具体的RPO要看网络之间的传输质量和传输的至做日志多少等因素.因此建议人工干预这种操作.网络条件：1.3可达。 应用切换请求方法：DB域名连接方式，动态切换解析地址；数据连接客户端配置动态数据库连接（例如Orade）.4.2 HA数据库服务模式所谓HA数据库服务模式是指通过操作系统HA软件结合数据库服务实现的容灾架构，架构设计之初是为了实现各类应用服务的本地服务器高可用，但双活容灾技术兴起之后，也常常被用来作为近距离（百公里内范围）双活容灾的数据库服务
6、架构.例如IBM的HACMP与DB2、OraCle结合、例如HPSerViCeGUard与Orade结合等.如图所示，数据库服务对外提供服务的地址只有一个VIP1是跨中心组成HA的两个实例节点的虚拟地址，借助跨数据中心1.2的网络环境，VIP可以漂移到任何一个物理节点上.当主中心数据库服务实例DB-instanceA测发生故障（网卡、服务器、SAN连接）时,根据HA的集群仲裁规则QB-instanceA可以获取到的仲裁资源（网络心跳、磁稔心跳）一定小于DB-instanceP,这个时候，集群会发生AP切换，集群执行以下动作让DB-instanceP接管数据库服务：1.将虚拟VIP绑定到DB-i
7、nstance-P的物理网卡；2、将共享存储卷从DB-instanceA上卸载，并在DB-instanceP上挂载；3、将共享存储卷上的服务在DB-instanceP上启动并激活对外提供服务.注意：这3个步骤,尤其是2&3两个步骤是需要一定切换时间T的（分钟级）这意味着RTO不会为零，应用会产生一定的中断，因此整个容灾架构的RT0T,这是益要在设计时充分考虑的。4.3 AA数据库服务模式所谓AA模式的数据库服务就是以OraCleRAUDB2PUreSCaIe为代表的双活集群架构，同样它们的设计初衷也是为了解决数据库服务本地高可用的解决方案.后来衍生为EXtendedRAC之类的容灾架构.从架构
8、本身来看，与HA架构有些类似，差异的地方在于AA模式是两边的节点都是Active状态，都可以进行读写，并发控制由缓存同步及锁机制来切调.如图所示，数据库服务对外提供服务的地址只有一个VIP,是跨中心组成集群的两个实例节点的虚拟地址，借助跨数据中心1.2的网络环境，相互之间可以交换缓存信息.、锁信息以，从而保障两个实例均可以激活状态进行数据的读写。当主中心数据库服务实例DB-instanceA侧发生故障（网卡、服务器、SAN连接）时，根据集群的集舞仲裁规则，DB-instanceA可以获取到的仲裁资源（网络心跳、磁盘心跳）一定小于DB-instanceB,这个时候，集群不会发生任何切换，只是将D
9、B-instanceA餐为离线状态，不再接受任何读写事务.所有向DB-instanceA请求的事务均被集群分发给DB-instanceB,这个过程对应用是无感知的.因此我们基本认为RTO为零.5 .存储层的故障切换策略5.1 存储网关服务模式所谓存储网关模式，我们在企业容灾选型指南-2:企业容灾的数据宜制技术当中介绍过，就是在物理存储层之上增加一层网关技术，用以形成存储资源透明抽象层,形成虚拟存慵卷对外提供服务.根据物理引擎的服务方式不同，又分为HA和AA工作模式两种.但是因为他们对外提供的服务是存储服务，对数据服务层和应用层没有任何影响.存储服务连接的地址SAN环境识别的存储卷的WWN,而这
10、个WWN是可以通过ServiceInstance-1&2上面的Port同时以多道路的方式提供给上层数据服务层，因此存储网关层的故障切换对上层是透明的。如图所示，在这个问题讨论的时候，我们不在分别说明HA和AA两种模式下的网关节点切换.因为本质上他们都一样，只是在缓存的处理和存储卷的控制权限上的策略有一些区别：HA模式：首先，服务节点上的IO缓存一般可以做到实时同步，如果不能实时同步或者同步不完全，那么缓存会有一些丢失，只是需要在Serviceinstance-2激活之后，系统需要做一些恢豆工作（通过事务日志等手段）；然后，将虚拟卷的读写控制权交给Serviceinstance-2,当它成为虚拟
11、卷的OWner之后，负责后续的IO,根据两边存睹设备的健康状况选择双边落盘或者是单边落盘.AA模式：这种模式下没有任何所谓的网关节点切换，只是所有本来由ServiceInstance-I服务的IO需要重新排队到SerViCelnStanCe-2,中间几乎没有中断，因为两个节点的缓存本来就是全局缓存，连个节点对虚拟卷的读写权限本来就是共享开放的.只是原来需要分担给ServiceInstance-I服务的部分IO,这个时候需要自己跨中心写入到主中心的物理存储上，当然如果主中心的物理存储也发生了故障，那么就只好单边落盘了.5.2 通过存储介质块复制实现数据豆制对于存储存储底层的块儿豆制技术来说，它的数据豆制是完全脱离了上层的应用层、系统层、数据库层。主要是依虎存储层两个物理存储设备来完成源到目标设备的Block复制。适合远距离的传输模式，一般用来做异地的数据级别容灾，因此一旦发生主数据中心灾难后，那么需要网络屣、应用属、数据展等一系列人工干预之后，才能启用灾备中心的存储卷，这里就不再详述.
