数据容灾
数据备份系统只能保证实际上被安全复制了一份，如果生产系统故障，必须将备份数据尽快的恢复到生产系统中继续生产，就叫
容灾。
容灾可以分为四个级别：
-
数据级容灾：只是将生产站点的数据同步到远端。
-
与应用结合的数据级容灾：保证对应应用数据一致性。
-
应用级容灾：需要保证灾难发生以后，需要保证原生成系统中的应用系统在灾备站点可用。
-
业务级容灾：除了保证数据、应用系统在灾备站点可用，还要保证整个企业的业务系统仍对外可用，是最终层次的容灾。
概述
如果要充分保证数据的安全，只是在本地做备份是不够的，所以需要在远程建另一个系统，并包含当前生产系统的全部数据，这个系统须
-
要保证主生产系统的数据实时的传输到远程备份系统上。
-
主故障后，必须将应用程序切换到远程备份系统上。
那么备份和容灾有什么区别呢？生产系统就好比手机，备份就是把手机上的数据备份到电脑上，但是如果这个手机坏了呢？要恢复数据需要大量的时间。
那么容灾就是我们有两部手机，而且他们的数据是使用云实时同步的，所以可以无缝切换。
如果我们预算充足，可以使用一直两台手机，那还需要备份吗？当然需要，比如某个时刻，我们把手机里面的某个联系人给误删了，因为容灾的手机是实时同步的，很难说能通过另一部手机找回来。但是如果之前有备份过数据，完全可以通过之前的备份进行恢复。
下面继续谈容灾。对于一个企业IT生产系统，主要有4个组件：
-
生产资料：原始数据
-
生产工具：服务器等基础架构
-
生产者：业务应用程序
-
产品：对外提供的服务信息
下面将对这四大组件的容灾进行讲解
生产资料容灾
生产资源容灾指的就是对原始数据进行容灾。这最重要的，因为没有生产资料一切等于从头再来。
要设计这样一套生产资料容灾，需要注意的是
-
要把变化的实时同步到备用系统，方法是
-
将某时刻的数据传送到备用系统
-
将此时候后变化数据同步到备用系统
-
这样就做了一次同步了，之后只需要在数据变化以后才把变化的数据传送到备用系统。
-
-
数据必须至少保留额外一份。在容灾的同时还需要数据备份（避免误删等逻辑错误）
如下为相应的拓扑：
主备站点都有相同的生产工具，使用网络相连。可以通过两种方式来进行同步：
-
通过前端网络进行同步
-
通过后端SAN网络进行同步。
通过前端网络同步
-
通过路由器连接到专线或者Internet
-
变化的数据通过路由器传送到备站点的路由器上。
-
通过交换机传到备服务器上，写入磁盘阵列
那么到底选择专线还是Internet呢？专线可以保证数据同步的实时性，但是不适合大数量的传输。如果实时性要求不高，而且数据量大的时候，可以将主备站点接入100Mbps的Internet。
可以看出这种方式经过了前端网络，所以必须在每台需要备份的服务器上安装软件进行同步，这种软件可以监视目录中的数据变化，然后与远端的软件进行通信，写入相同的文件目录中。
这种方式的同步一般都是文件级的同步，对底层卷的数据块变化不做同步。
案例：DB2数据的HADR组件容灾
DB2数据库利用主备上的数据库软件模块（HADR）来实现两端的数据同步。而且同步的是不卷上的原始数据，而是对数据操作的描述，也就是日志。这样的好处是，不需要传输数据，备份机收到日志以后，在备机的磁盘上重做操作即可。
HADR:High Availability Disaster Recovery，是数据库级别的高可用性数据复制机制。需要两台数据库服务器：primary , standby
-
当
主数据库发生事务性操作，将日志通过TCP/IP传送到备数据库，然后备机对日志文件进行重放Replay，从而保持数据的一致性。 -
当
主数据库故障，备机可以接管主数据库，而客户端应用程序的数据库连接可以通过自动客户端重新路由（Automatic Client Reroute）转移到新的主服务器。 -
当原来的主数据库服务器修复了，作为新的备用数据库加入HADR。
需要注意的是处于备用角色的数据库不能被访问。
通过后端网络实现同步
通过后端网络进行同步，数据不会流经前端网络，而全部通过后端网络传输到备份的存储上。所以需要将主站点和备站点的后端网络设施连接起来。要么直接拉光纤，要么用专线。
如果用专线的话，需要增加额外的协议转换设备，现在电信部门的光纤专线一般为SDH传输方式，接入到用户端的时候，一般将信号调制成E1、OC3等编码方式。
上图中，FC协议，经过FCIP网关，变成基于以太网的IP协议，（FC over IP over ETH）。经过E1/以太网转换器，承载到了E1协议上，然后多路E1信号汇聚到光端机，通过一条或者多条光纤，传输给电信部门的SDH交换设施进行传输。
这样我们就将主站点和备站点的后端网络打通了，此时主服务器就可以访问到备份的磁盘阵列，也就是说主站点的服务器可以同时操作本地磁盘和备站点的磁盘阵列了。
我们来看一下这种方式的路径：
本地磁盘+SAN交换——本地服务器内存——SAN网络交换——电信部门网络——远端SAN网络交换——远端磁盘阵列
数据到了远端SAN不需要再经过服务器，因为有了对方存储设备的直接访问权。但是整个过程中，仍然至少需要一台服务器，服务器上需要安装一个软件，可以将数据从本地卷A提取出来，然后直接通过SAN网络写到位于备份站点的卷B上。
但是试想一下，如果数据直接在内存中生成的，那么同时在A和B上各写一份，速度岂不是更快，这种方式又叫“卷镜像”，因为可以时时刻刻保持两个卷完全相同，它能保证数据同步的实时性，但是不适合大规模远距离的数据同步。
同时还需要注意的是，卷镜像的的同步软件工作在卷这一层，可以感知数据块的变化，而不是文件的变化。缺点在于对网络速度要求更高，所以成本也更高。
通过数据存储设备实现同步
之前讲的通过前端网络和通过后端网络的方式，都使用了一个泵来提供动力。而如果将数据同步软件安装在存储设备上，岂不是更省事。而且这样彻底解放了服务器，所有工作都由磁盘阵列完成。
这种方式的同步，不会识别卷上的文件系统，所以同步的是块。而且要求主和备的存储设备型号一致。因为不同厂家的产品无法实现直接同步。
这种方法的缺点是不能保证数据对应用程序的可用性。
因为存储设备与应用程序之间还有操作系统这一层，操作系统也有自己的缓存机制，所有有可能造成数据的不一致性。
总结：
-
使用前端网络进行同步，路径最长，但是成本也最低。
-
使用后端网络进行同步，实时性强，但是对后端链路要求也高。不适合于数据量多的时候。
-
使用存储设备直接进行同步，路径最短，不占用服务器。但是仍然不适合于远距离低速链路环境。而且还不能数据对应用程序的可用性。
容灾中数据的同步复制和异步复制
同步复制
下图是基于存储设备的自主同步环境。
-
主向磁盘发出IO请求，向某LBA写入数据，待写数据入缓存，此时控制器不会给主的HBA驱动程序发送成功
-
主磁盘阵列将变化的数据从缓存中写入LUN A，此时主的数据同步引擎感知，将变化的数据块从缓存中通过SAN交换机发送到备的缓存中。
-
备磁盘阵列运行的同步引擎接收到数据后，在FC协议隐式的发一个ACK或者通过上层显试的发给主站点
-
主收到应答，向服务器发一个FC协议的隐式ACK。服务器上的FC HBA驱动程序探测成功。
若备站点迟迟未收到数据，则不会返回成功，应用程序会等待。如果此时应用程序使用的是同步IO，则相关进程会挂起，称为
IO等待。所以同步复制的特点是主站点必须等待备份站点的成功信号，保持严格的同步，一荣俱荣，一损俱损。
异步复制
相对于同步复制，两边的步调不需要一致，要保证重要的事情先做完，所以会存在一定的数据不一致。
-
主向磁盘发出IO请求，待写数据进入控制器缓存，如果此时
-
主控制器设置为Write Back模式：则立刻返回应答。
-
主控制器设置为Write Through模式，则先写入LUN A以后，再返回ACK。
-
-
主站点将数据通过SAN网络发送到备站点的缓存。
-
备站点磁盘成功接收，则返回成功。
生产者容灾——应用程序容灾
之前讲的都是生产资料的容灾，也就是整个系统最重要的数据的容灾。而对于生产者，无疑就是服务器上的应用程序，如果主发生故障，需要在备站点重新运行这些应用程序。最直观的想法是，在备站点预备应用程序的安装文件，一定主出现故障，在备上配置这些应用程序，但是实际上应用程序安装和配置需要大量的时间。所以可以将备份站点预装应用程序，但是不工作，这样就可保证同一时刻整个IT系统只有一个站点的生产者处理一份数据
既要求处理同一份数据，又要求发生事故的时候，备份站点的生产者立即启动，要做到这点，需要让备份站点的应用程序感知到主站点的应用程序状态，一旦发现故障，立即启动开始生产。
在之前的章节中，我们说到了高可用群集，在容灾系统领域，群集的范围扩大到了异地，主备可能相隔很远，交换运行状态的数据量很小，最好使用专线，这样可以很好的保证QoS。
传统的HA软件是使用共享存储的方式来作用的，即在HA系统中，共享一份物理存储，不管谁来操作这份数据，最终只有一份，而且是一致，有上下文逻辑关系的。
所以HA软件是基于资源切换的，把组件看作是资源，比如应用、IP地址、存储卷等。
当故障时，
-
备份机HA软件会检测到对方的故障，
-
然后强行将资源迁移到本地，比如在备份机上修改网卡的IP地址，并发出ARP广播来刷新所有广播域的客户端以及网关的ARP记录
-
挂载共享存储设备上的卷，
-
最后启动备份应用系统。
这样应用系统可以访问共享卷，客户端也可以使用原来的IP地址来访问服务器，这样生产就可以继续下去。
但是在异地容灾系统中，主备站点各有一份数据，所以必须保证数据的同步。这也是为什么两个站点同时只有一个在工作，这样的话才能以一边数据为准，另一边与之同步。
本地容灾
本地HA系统中，多个节点如果共同拥有同一个卷，但是同一时刻只有一个节点能挂载它，这种模式叫共享存储模式
与之对应的是Share-Nothing模式，每个节点都有自己独占的存储卷，怎么进行数据共享呢？可以通过同步复制技术同步到所有节点上。若某节点发生故障，这个节点对应的备份节点启动应用程序。因为之前的数据已经同步过了，所以数据一定是一致的。
在Share-Nothing模式下，不存在任何的接管问题，所以客户端需要感知服务端群集这种切换动作，通过客户端进行配置的切换即可。
可以对共享存储和Share-Nothing两种存储模式进行对比。
| 共享存储 | Share-Nothing | |
|---|---|---|
| 数据本身是否容灾 | × | √ |
| 软硬件成本 | 高 | 低 |
| 前端网络资源消耗 | 低 | 高 |
| 管理难度 | 高 | 低 |
| 维护数据是否需要停机 | √ | × |
| 实现的复杂度 | 高 | 低 |
| 是否需要第三方软件 | √ | × |
| 故障因素数量 | 3个 | 2个 |
-
数据本身是否容灾
-
共享存储：数据损坏，必须使用镜像进行还原。而且要停机。
-
Share-Nothing：每个节点都有自己的数据拷贝，若损坏，可切换到另外的节点，不影响应用，不停机。修复后的节点可以重新加入容灾系统。
-
-
软硬成本
-
共享：需要外接磁盘阵列，为了保证数据访问速度，必须自身实现RAID，主机也需要安装适配器。成本高。需要HA软件
-
Share-Nothing:各个节点各自保存数据，不需要外接存储系统，不需要额外的HA软件
-
-
前端网络耗费
-
共享存储：前端只需要交互控制信息，资源耗费较小。
-
Share-Nothing:数据同步靠前端，对资源消耗很大。
-
-
管理难度：
-
共享：需要管理节点间的交互配置，还需要管理外部存储，增加了管理难度
-
Share-Nothing:只需要管理节点配置。
-
-
是否停机
-
共享：需要将数据从单机转移到共享存储供其他节点使用，需要停机来保证一致性。
-
Share-Nothing：数据同步是动态的，不需要停机。
-
-
实现复杂度
-
共享存储：有三种基本元素：节点、节点间的交互、共享数据。如果使用共享存储模式做容灾，需要将数据移动到共享存储上，增加额外的工作量和不可控因素
-
Share-Nothing：只有两种元素 节点&节点交互
-
-
第三方
-
共享存储：备份节点需要通过HA软件来监控主节点的状态，发生故障的时候自动接管，如MSCS
-
share-Nothing：不需要第三方软件参与
-
-
故障因素
-
共享存储：OS、应用程序、HA软件
-
Share-nothing：OS、应用程序
-
异地容灾
如果主站点和备站点不在同一个机房中，这样备份应用程序需要跨越很远的距离来与主程序交互状态。只是说这种交互包很小，不需要担心延时的问题。
IP切换
在异地容灾系统，主服务器和备服务器不大可能在同一个广播域，所以需要通过网关来转发IP包，正因为此不能用资源切换的方式来切换IP地址。
如果想故障后，客户端继续使用原来的IP地址连接备份服务器，那么可以在路由上做文章。动态修改路由器上的路由表，将IP包路由到备份站点而不是主站点。如果利用域名来访问服务器，那么可以直接在DNS设备上修改IP指向记录来实现。
卷切换
异地容灾系统在主站点和备站点各有卷，两个卷通过前端或者后端网络进行同步。
如果备的HA软件检测到主站点通信失败，通过某种方式，断开同步关系（若不断开，卷会被锁定而不可访问）。然后就是重新挂载备站点的卷
此时同步引擎可以是运行在存储设备上，也可以由HA来执行。
-
如果同步引擎是运行在存储设备上的，必须由管理员手动利用存储设备的配置工具来断开同步关系。断开了以后，本地的卷才可以被访问，然后HA软件可以在备份机上调用操作系统相关功能来挂载这个卷。
-
如果同步引擎本来就是HA来执行的，那么HA软件可以自动断开同步关系，在备份机上挂载对应的卷。
异地容灾的应用切换
应用，也就是生产者的切换，是所有HA容灾系统在故障发生后所执行的最后一步。与共享存储式的HA容灾一样，异地容灾的应用切换，是有备机的HA软件来执行脚本，或者调用相应的接口来启动备份机的应用的。
