“浅”谈容灾和双活数据中心--冬瓜哥

“浅”谈容灾和双活数据中心

第一部分：复制链路

1.1 链路类型

链路，来根线连接起来，不就可以了么？没问题，裸光纤连起来，这就是链路，如果是一座楼内，甚至一个园区内，管井你可以随便用，铺设一根光缆，没多少钱。问题是本地和远端相隔太远，出了园区，你就不能随便在两个楼之间飞一根线了，必须租用电信部门提供的各种线路了，当然，点对点无线传输也是个可以考虑的路子，如果两楼之间相隔不太远且视觉直达，到可以考虑这种方式。电信部门有各种专用链路或者共享链路提供出租，最原始的一种就是裸光纤，两地之间直接通过电信部门部署好的光缆，其中分出两根纤芯给你，当然，电信部门会有中继站，负责对光信号的路径交叉及信号增强中继。因为不可能任意两点间都恰好有光纤直连，必须通过中继和交叉。有了裸光纤，你两端跑什么信号什么协议什么速率就随你了，只要光模块的波长功率合适，两端就可以连通。裸光纤不能走太远距离，一个是价格太贵另一个是电信部门也不可能租给你用，因为距离太远的时候，光缆资源越来越稀缺，不可能让你独占一根，要知道，电信部门使用DWDM设备是可以在一路光纤上目前复用高达80路光波的。实际上近距离传输也很少有人用裸光纤了，尤其是大城市，因为资源太稀缺，除非互联网这种体量的用户，其他基本都是租用与别人贡献的某种虚拟链路。比如使用ADSL、EPON/GPON、E1等最后一公里接入方式，上到电信部门的IP网，或者直接上到SDH同步环网，不同的方式和速率，价格也不同。

存储设备一般都支持iSCSI协议复制，那么此时可以接入使用以太网作为最终连接方式的比如ADSL、GPON等，如果仅支持FC协议复制，要么增加一个FC 转IP路由器再接入IP网，要么使用局端提供的专用FC协议转换设备直接上SDH同步网。

1.2 长肥管道效应

链路的时延除了与距离有关之外，还与链路上的各个局端中继和转换设备数量有关。光在光纤中传播靠的是全反射，等效速度为每秒20万千米，而更多时延则是由信号转换和中继设备引入的，电信运营商的网络可分为接入网和骨干网，本地的信号比如以太网或者FC，先被封装成接入设备所允许的信号，比如GPON 等，再视专线类型，上传到以太网交换机、路由器或者直接到局端骨干网入口设备比如OTN。在这种高时延链路之下，每发送一个数据包，要等待较长时间才能得到ack，此时如果源端使用同步复制，性能将非常差，链路带宽根本无法利用起来，太高时延的链路必须使用异步复制。应用端同步IO模式+同步复制，

这种场景是吞吐量最差的场景，异步IO+同步复制，效果其实尚可，最好的还是异步复制（不管同步还是异步IO）。

不管是异步复制还是同步复制，如果使用了FCP或者TCP这种有滑动窗口的传输协议，那么难免会遇到传输卡壳，TCP有个最大可容忍未ACK的buffer量，传输的数据达到这个buffer，就必须停止发送，而必须等待ack返回，只要一卡壳，链路上这段时间内就不会有数据传送，严重降低了传输带宽，为此，专业一点的存储设备都要支持多链接复制，向对端发起多个tcp链接，在一条链接卡壳的时候，另一条正在传输数据，这个与数字通信领域常用的多VC/队列/缓冲道理是一样的，一个VC由于某种策略导致卡壳的时候，其他VC流量一样会利用起底层链路的带宽。

第二部分：双活数据中心

2.1 双活并发访问的底层机制

从存储系统的视角来看双活数据中心，怎么个双活法？应用首先得双活，应用不双活，就无所谓双活数据中心。也就是多个实例可以共同处理同一份数据，而不是各处理各的（互备，或者说非对称双活）谁坏了对方接管，支持多活的应用典型比如Oracle RAC、各类集群文件系统等，这些应用的每个实例之间是可以相互沟通的，相互传递各种锁信息及元数据信息，从而实现多活。一般来讲，这类多活应用，其多个实例一定要看到同一份数据，如果这同一份数据有多个副本，那么一定要保证着多个副本之间是时刻一样的（有些互联网应用除外，不要求实时一致性），这与多核心多路CPU的Cache Coherency思想是一样的（具体可以看本公众号最早的一篇文章”聊聊CAPI“，所以冬瓜哥一直认为底层通了，一通百通）。所以，要么让这多个应用实例所在的主机通过网络的方式共享访问同一个数据卷，比如使用SAN（多活数据库比如Oracle RAC，或者共享式集群文件系统，这两类多活应用需要访问块设备）或者NAS（有些非线编集群应用可以使用NAS目录），用这种方式，数据卷或者目录只有唯一的一份而且天生支持多主机同时访问。在这个基础上，如果将这份数据卷镜像一份放到远端数据中心的话，而且保持源卷和镜像卷时刻完全一致（同步复制），那么多活应用就可以跨数据中心部署了，多活应用看到的还是同一份数据，只不过本地实例看到本地的数据卷，远端实例看到远端的数据卷，数据卷在底层用同步复制实现完全一致，这与在本地多个应用实例看到唯一一份数据卷副本的效果是一模一样的，这也就做到了多活，能够在整个数据中心全部当掉时，短时间内几乎无缝业务接管。

但是，实现这种双活，也就是让存储系统在底层实现“源卷和镜像卷时刻一致”，并不是那么简单的事情。首先，传统容灾数据复制技术里，业务是冷启动（灾备端应用主机不开机）或者暖启动（灾备端应用主机开机但是应用实例不启动，比如Windows下对应的服务设置为“手动”启动），这个极大节省了开发难度，灾

备端存储系统所掌管的镜像卷，不需要挂起给上层应用提供数据IO，而只需要接收源卷复制过来的数据即可。而多活场景下，应用实例在灾备端也是启动而且有业务IO的，那就意味着，源卷和镜像卷都要支持同时被写入，而且每一笔写入都要同步到对端之后才能ACK，这种方式称之为“双写”，以及“双向同步”，只有这样，才能做到两边的实例看到的底层数据卷是一模一样的，而不是其中某个实例看到的是历史状态，而其他实例看到了最新状态，后者是绝对不能发生的，否则应用轻则数据不一致，重则直接崩溃。这种双写双向同步，看似简单，同步不就行了么？其实，不了解底层的人可能也就到这一步了，然后就去出去装逼去了，殊不知，很多坑你都没有填，说不定哪天就把自己给装死了。

存储端实现双写双向同步的第一个难点在于，如何保障数据的时序一致性。与单副本本地多活应用系统相比，双副本多活，也就是双活数据中心，两边的应用实例各自往各自的副本写入数据，如果A实例像A卷某目标地址写入了数据，那么当这份更新数据还没来得及同步到B卷之前，B实例如果发起针对同一个目标地址的读操作，B卷不能响应该IO，因为B卷该目标地址的数据是旧数据。B 卷如何知道A实例已经在A卷写入了数据呢？这就需要复杂的加锁机制来解决，A端的存储系统收到A实例写入A卷的IO之后，不能够ACK给A卷，它需要先向B端的存储系统发起一个针对该目标地址的Exclusive排他锁，让B端存储系统知道有人要在A端写数据了，然后才能向A卷中写入数据，如果B端的B 卷针对此目标地址正在执行写入操作（由B实例发起，但是通常不会出现这种情况，应用实例之间不会出现两个以上实例同时写入某目标地址的操作，因为多活应用实例之间自身也会相互加锁，但是存储系统依然要考虑这种情况的发生），则此次加锁不成功，A端存储系统会挂住A实例的写操作，直到能够加锁成功为止，这里可以定期探寻也可以spin lock，不过在这么远距离上去spin lock恐怕性能会很差，所以不会使用spin lock的模式。加锁之后，B端如果收到B实例针对该目标地址的读或者写IO，都不能够响应，而是要挂住，此时B端存储系统要等待A端存储系统将刚才那笔针对A卷的写IO发送过来之后，才能够返回给B实例，这样，存储系统任何时刻都能保证对A实例和B实例展现同样的数据副本。同理，B卷被B实例写入时，也需要执行相同的过程，对A存储的A 卷对应地址加锁，然后后台异步的将数据同步到A端。

第二个难点，就是如何克服高时延链路导致的IO性能降低。通过上面的描述，大家可以看到上文中有个坑没被填，也就是A存储在何时给A实例发送写成功ACK？是在向B端加锁成功后，还是在A实例写入的数据被完全同步到的B端之后？如果是后者，那就是传统的同步复制技术了，把这块数据同步到B端，是需要一定时间的，如果使用的是TCPIP方式传输，根据上文中的分析，还会出现卡壳，等待传输层ACK等，时延大增，性能当然差。但是如果A端在向B 端加锁成功后立即给A发送写ACK，那么时延就可以降低，此时虽然数据还没

有同步到B，但是B端已经获知A端有了最新数据这件事情，如果B实例要访问B端的这份数据，B存储会挂住这个IO，一直等到A将数据复制过来之后才会返回给B实例，所以不会导致数据一致性问题。也就是说，这种方式，拥有异步IO的性能效果，以及同步IO的数据一致性效果，两者兼得。而代价，则是丢失数据的风险，一旦数据还没有同步到B端之前，链路或者整个A端故障，那么B端的数据就是不完整且不一致的，要性能就注定要牺牲一致性和RPO。第三个难点：解决死锁问题。如果某个应用不按照规律来，该应用的两个实例在两边分别同时发出针对同一个目标地址的写IO操作给两边的存储控制器，两边会同时向对方发起加锁请求，这个过程中由于链路时延总是存在的，锁ack总会延时收到，导致两边同时对该地址加了锁，结果谁都无法写入，这便是死锁。解决这个问题就得找一个单一集中地点来管理锁请求，也就是让其中一个存储控制器来管理全部锁请求，那么无疑该存储控制器一定会比对端更快的抢到锁，不过这也不是什么大问题，本地访问永远先于对端访问，这无可厚非。

综上所述，双活或者多活数据中心方案里，存储系统的实现难点在于锁机制。与多CPU体系（也是一种多活体系结构）相比，多CPU在针对某个进程写入数据到Cache时，是不向其它节点加锁的，而只是广播，如果多个进程同一时刻并发写入同一个目标地址，那么就发送多个广播，谁先后到，覆盖先到的，此时CPU不保证数据一致性，数据或被撕裂或被循环覆盖，这个场景需要程序遵守规则，写前必须抢到锁，而这个锁就是放在某个目标地址的一个集中式的锁，程序写前使用举例来讲spin lock来不断测试这把锁是否有人抢到，没抢到就写个1到这个地址，而spin lock本身也必须是原子操作，spin lock对应的底层机器码中其实包含一条lock指令，也就是让cpu会在内部的Ring以及QPI总线上广播一个锁信号，锁住所有针对这个地址的访问，以协助该进程抢到锁，保证抢锁期间不会有其他访问乱入。存储系统其实也可以不加锁，如果上层应用真的两边并发同时访问同一个地址，证明这个应用实现的有问题，但是存储系统为了保证数据的一致性，不得不底层加锁，因为谁知道哪个应用靠不靠谱，多线程应用很多，程序员们已经驾轻就熟，但是多实例应用，非常少，出问题的几率也是存在的。

冬瓜哥很少提及具体产品，因为冬瓜哥认为底层通一通百通，不需要了解具体产品实现，所有实现都逃不出那套框架。但是为了迎合大家口味，冬瓜哥还是提一提产品比较好。可以肯定的是，HDS的双活，是确保将数据完全同步到对端之后（同时向对端加锁），才返回本端应用写ACK信号；而EMC Vplex所谓的“基于目录的缓存一致性”，则是使用了加锁完便ACK方式，这也就是其号称“5ms 时延做双活”的底层机制。至于其他家的双活，逃不出这两种模式，爱是谁是谁，爱抄谁抄谁，冬瓜哥就不操心了。不过，“基于目录的缓存一致性”其实是出自CPU体系结构里的学术名词，EMC很善于包装各种市场和技术概念，连学术名

词都不放过。不过，双活的这种一致性机制，与多核或者多CPU实现机制的确是同样思想，在MESI协议中，某个节点更新了数据，会转为M态（Modify），并向其他所有节点发起Probe操作作废掉其他节点中对应的cache line，这一点和上述思想是一致的，只不过M态的数据一般不用写回到主存，而是呆在原地，其他节点入有访问，则M态cache的owner节点返回最新数据，而不是将数据同步到所有其他节点上（早期某些基于共享总线的CPU体系结构的确是这样做的）。

2.2 双活与Server-SAN

能从双活扯到ServerSAN？是的，ServerSAN本身也是多活的，其实现机制类似于传统存储系统的双活方案，只不过其有分布式的成分夹杂在里面。目前主流ServerSAN实现方式是将一个块设备切片比如切成几个MB大小的块，然后用Hash算法来均衡放置到所有节点中，每个切片在其他节点保存一到两份镜像，主副本和镜像副本保持完全同步，不复制完不发送ack。由于时刻同步，所以ServerSAN可以承载多活应用，每个节点上都可以跑一个应用实例，所有实例看到时刻相同的存储空间，可以并发写入多个镜像副本，为了防止某些不守规矩的应用，多节点间也要实现分布式锁，也要解决死锁，所以一般使用集中式锁管理，比如zookeeper之类。如果把ServerSAN多个节点拆开放到多个数据中心，这就是多活数据中心了。所以你能看到，ServerSAN本身与双活数据中心都是同样的思想。

第三部分：双活，看上去很美。

3.1 装逼是要付出代价的

看这标题，想必瓜哥是要开始吐槽双活了。没错。传统灾备模式下，一主一备，灾备端冷启动或者暖启动，这种方式虽然有资源浪费和RTO较大等缺点，但是其最大一个优点就是保险。那么说双活不保险喽？瓜哥认为是的。世上没有无代价的交换。双活的不保险，体现在灾备端对生产端是有严重影响的，或者说双活场景下，已经没有主和备的角色分别了，是对称式的，也就是两边会相互影响。这种影响，很有可能导致两边一损俱损，多活应用的多个实例之间耦合较紧，诸如“单节点无法启动”、“无法加入新节点”等类似耦合性问题，时有发生，带来了很大的运维复杂度，尤其是异地多实例的场景下，出现问题，你咋弄？登陆到远端机器调试，甚至需要重装、重启，有时候还不得不在异地放个人配合你，俩人水平不一样沟通或许也有问题，你就得亲自来回跑，这些想想都头疼。这就好像很多单一应用主机做了HA双机热备一样，结果发现本来屁事没有的单机环境，自从部署了HA之后，反而多了很多屁事。

双活也一样，只会增加运维难度，而不会降低。双活就得预防脑裂，而“预防脑裂”本身就可能会出各种问题，徒增成本不说，远距离链路上会发生什么谁也无法预知，一旦软件做的有问题不够健壮，反而会导致更大问题甚至脑裂，也就是根本没防止脑裂而增加脑裂概率了。还有就是一旦两边、仲裁，都失去联系，那么系统只能停机，而这种情况在传统灾备架构里是不会发生的，从这一点上说，双活的可用性概率反而是下降的，因为链路闪断、故障的几率，比整个数据中心大灾难的几率那是高多了。

传统双活，一主一备，或者至少是互备，容灾端是不会影响源端的。而双活，“备份”的意思更少了一些，这与传统的观念就背离的越来越远了。双活两边各自影响，搞不好一端出问题，另一端跟着遭殃，甚至两边直接全挂掉，比如一旦某个地方不一致，或者经过链路闪断之后出现了状态机混乱，全崩。其实这个已经是有前车之鉴的了。据说某用户使用了某品牌的双活之后，出现脑裂问题，导致停机数小时，高层直接被下课。从这一点上来讲，双活既可以是个略显逼格的奇葩装备，但也有可能成为一个定时炸弹。再一个例子，支付宝光纤被挖断，愣是停业务两小时，至于其到底是否部署了双活甚至多活，谁也不知道，瓜哥也不能妄加揣测，但是至少说明一点，所谓双活，可能并没有你想象中的那么健壮，虽然它看上去很美。

3.2 另一种双活，不中看但或许很适合你

业界有几个厂商也宣称自己支持双活，但机制并不是上述那样。同样A和B两个站点，A实例访问本地数据副本，B实例也访问A站点的数据副本，而A存储与B存储之间保持复制关系，在B站点维护一份镜像副本，镜像副本平时不能挂起给业务主机，仅当出了问题之后，比如A存储宕机，镜像副本才可以挂起给业务。这些厂商的这种双活方案，各自也都包装了一套名词出来，比如“Stretched Cluster”，意即将本来耦合在本地的主备容灾系统拓展到异地，平时备份端的主机也可以访问源端的数据，只不过要跨广域网，数据是集中访问源端副本，不需要考虑一致性问题。出现问题需要切换时，靠主机上的多路径软件将路径切换到备份端，继续业务。

下面这个拓扑是利用虚拟化网关组成的的Stretch Cluster结构，两台主机运行双活应用，当A主机当掉之后，B主机可以继续访问A站点的A存储，路径不

影响很小，切换之后B对A反向同步。

其是互联网类业务，或者无人值守业务，人为因素介入较少，都是机器全自动化操作，只要机器活着，业务就活着。对于传统业务，一旦灾难发生，就算双活系统在对端立即处于可用状态，那么最终的操作者要切到访问对端，还得经过全面的训练演练，以及网络路径的切换，最终才能访问对端数据中心，如果是大型灾难，传统企业一般是人+机器处在同一位置，此时人和机器都被灾难了，对端的业务即使立即可用，也毫无意义，从这一点上来看，传统业务是否真的迫不及待需要双活，还得根据场景来考量。而对于机器自动化处理的业务系统，双活是有一定意义的。

所以，部署双活，一定要考虑清楚其到底是不是自己真正想要的东西，没那个精工钻，最好别揽瓷器活，缺乏驾驭双活的本领，就得随时承担被下课的风险，决不能为了没思考清楚的一时的风光，埋下个大坑。厂商们的sales和售前，都是无底限的，这一点切记，为了推广某个东西，他才不管你要的是什么或者你有多大本领来驾驭双活，很少有人会为你设身处地的着想，就算是top sales/presales，你所能做的，只有加强自己的功底和防忽悠能力，自己判断，才是正路。

第四部分：数据复制及一致性

4.1 存储端同步复制一定RPO=0？

两个结果，业务起得来，RPO≈0，业务起不来，RPO=RTO=∞（无穷大），也就是再也别想起来了。为什么呢？难道连同步复制都丢数据？同步复制是可以不丢数据（其实同步复制不仅不丢数据，而且有几率可能会超前于本地站点，因为一般同步复制的实现都是先写远端，成功后在写本端，如果写完远端，远端ack 了，结果ack没来得及传递到本端，链路或者本端当了，那么远端的数据反而超前于本端），但是同步复制不保证数据的一致性。说到数据一致性，需要理解IO 路径上好几层的东西才能理解，首先应用层自己有buffer空间，有些东西写到这里就返回了，其次OS内核的Page Cache，如果应用打开设备/符号/文件时候

没有显式指明DirectIO，默认也写到这里就返回了，再往下就是块层、设备驱动、Host驱动，但是这几层都是没有write back缓存的，问题不大。此时，数据并

没有被刷到存储系统里，在page cache中留有脏数据，这些数据是没有复制到远端的，一旦系统掉电，重启就极有可能出现各种问题比如LVM/ASM卷挂不起来，文件系统挂不起来或者FSCK。可已看到，存储层的同步复制仅仅解决的是底层存储层的时序一致性问题，它能保证凡是已经下刷到存储系统里的IO，两

边几乎是时刻一致的。但保证不了卷层、FS层以及应用层的一致性。

一旦卷挂不起来，或者应用起不来，很难恢复数据，这可不是数据恢复公司所能恢复的。所以，同步复制并不能保证RPO，需要在目标端对目标卷做多份快照，一旦发生灾难，首先尝试最新数据启动，起不来，回滚快照，再起不来，再回滚，如果都不行，那就玩完。同步复制保证两端数据几乎时刻相同，那也就意味着，灾难发生时，源端数据什么状态，灾备端的数据也是什么状态，灾难发生时，源端数据就相当于咔嚓一下子停了电，那么灾备端的数据也相当于咔嚓停了电。停电之后再启动，大家都清楚会发生什么，那就是个梦魇，一堆错误，甚者硬件都再也起不来了，重者卷挂不起来提示错误，或者数据库起不来提示数据不一致，轻者FSCK丢数据，所以，同步复制+远端快照才能降低风险。

4.2 存储端异步复制的时序一致性

再来看看异步复制如何保证数据一致性。异步复制分两种，一种是周期性异步复制，一种是连续异步复制。周期性异步复制是最常用也最简单的一种方式，在初始化同步的基础上，源端做一份快照，一段时间之后，再做一份快照，通过比对两份快照之间的数据差异，将所有差异全部传送到远端，这次差异的数据，会被分为多份小IO包发送到远端，只要有一份没有成功传送，那么远端就不会将这些数据真正落地到远端的卷，远端会回滚到上一个快照点，等待下次继续触发复制，这样可以保证数据的时序一致性。这样，一次差异复制的所有IO数据形成了一个原子IO组，有人又称之为“一致性组”。而连续异步复制是不断的向对端复制，而不是定期做快照比对差异然后批量复制。

连续异步复制又分为两种，一种是无序复制，实现起来最简单，直接在源端记录一个bitmap，数据直接写入源卷的同时，将对应bitmap中的bit置1，后台不断读取bitmap中置1的块，读出来复制到远端，这种复制过程完全不顾IO发生的时序，是没有时序一致性的，远端的数据几乎是不可用的，除了早期有些厂商使用这种方式之外，现在已经没人这么干了。另一种是基于日志的有序连续复制，就是在源端，更新IO除了写入源卷之外，还会被复制一份写入到一个RAM 里的buffer区域或者磁盘上的日志空间，按照顺序把所有更新操作IO数据记录下来，形成一个FIFO日志链，然后不断的从队首提取出IO复制到远端，当遇到链路阻塞或者闪断的时候，如果系统压力很大，则buffer或者日志空间可能会被迅速充满，此时不得不借助bitmap来缓解对空间的消耗，也就是转成第一种模式，当链路恢复时，远端和源端将打一个快照，然后确保要将所有未被复制过

去的数据全部复制过去，才能达到同步状态，然后恢复第二种模式的连续赋值过程，因为bitmap中是不记录IO时序的。

4.3 另一种概念的“一致性组”

源端的多个Lun之间可能是存在关联关系的，典型的比如数据库的online redo log卷和数据卷，这两个/组卷之间，就是有先后时序关联性的，数据库commit 的时候，一定是先写入online日志，然后实体数据在后台异步的刷入到数据卷。对于异步复制来说，不但要保证单个卷写IO的复制时序，还必须保证多个卷之间的时序不能错乱，比如基于快照的周期异步复制场景，存储系统必须保证这多个Lun在同一个时刻做快照，所有已经应答的写IO，都必须纳入这份快照中，将多个Lun一刀切平，同时每次触发复制，必须将这多个Lun的差异都复制过去，才可以保证多个Lun之间的时序一致性，出了一点差错，则远端这多个Lun 统一回滚到上一个快照一致点。这多个Lun，组成了一个“一致性组”，这是目前“一致性组”的通用理解。

4.4 专业容灾厂商如何解决数据一致性问题

如上所说，在存储系统层进行复制，无法保证数据的应用层一致性，究其原因是系统IO路径上的缓存未下刷导致。所以一些专业点的存储厂商就开发了应用Agent，装在应用主机上，在做快照之前，Agent会将应用至于特殊状态，然后通知阵列做快照，完成后再将应用置回正常状态，这样做出来的快照是一致的。举例来讲，数据库应用，有一种特殊的运行状态叫做“backup mode”，当要对数据库做备份的时候，要将对应的数据文件拷贝出来而且还不能影响在线业务，数据一边往数据文件中写入，一边还得拷贝出文件来，此时如果不加处理，拷出来的文件就是新旧数据交织在一起的一份不一致数据，而如果将数据置于“backup mode”的时候，数据库会在数据文件中将当前的SCN锁住不再更新，同时在redo 日志中记录标记，后续的所有更新操作依然更新到数据文件中，但是同时会保留在redo日志中，数据checkpoint SCN被锁住，但是hot backup SCN依然不断更新。此时，备份出来的文件自身虽然是不一致的，但是加上redo日志之后，这份数据就是可以恢复而且一致的，在恢复之后，数据库会将redo日志中自从hot backup开始之后的所有更新重新redo到数据文件中并将checkpoint SCN 与hot backup SCN追到一致。

各种快照Agent for Oracle，就是利用了个这么简单的原理，alter database begin backup，无非就是执行这样一条命令而已，这条命令除了会将数据库置于backup mode之外，还会主动出发一次checkpoint，意味着其会调用sync接口将数据库应用层buffer内脏数据刷入底层存储，然后这条命令才会执行返回。Agent

调用了这条命令返回之后，通知阵列对数据卷和日志卷同时做快照（基于一致性组保障），做出来的快照就可以保证一致性，所以，这种场景下，必须是数据+日志才能保证一致性，数据文件本身不具有一致性。对于基于快照差异复制的异步复制，也要使用这种方式来做快照。快照做完之后，Agent再解除数据库的backup mode，数据库便会自动重做redo日志来将数据文件追赶到最新状态。所以，快照代理并不是多数人认为的“hang住io”，hang不住的，没有这种接口让你去hang住io的。

然而，看上去再保险的做法，有时候也不保险，多少数据库、文件系统号称保证一致性，掉电不fsck等等，现实中呢，掉电崩溃的概率其实依然比较高，IO路径上的所有模块必须都做到强一致性，包括实现端到端的DIF，才有可能真的实现绝对一致性，可惜目前这只是幻想。某个部件宣称自己能保证强一致性，也白搭，最简单的例子，LVM在一致性方面做得就欠火候，不管linux还是unix，突然拔电，lvm首先就有很大概率不一致，重则卷都认不到了，如果数据库部署在lvm卷之上，本身做得在可靠也是白搭。那咋个整法？

有些看似野路子但是却很有效的方法。举个例子，如果系统可以在主机IO压力为0或者非常低的时候来做快照，那么就会有更大几率来保证一致性，主机IO 压力为0，要么证明缓存里几乎没有脏数据，要么就是位于两次checkpoint之间，此时做快照一致性保障几率增高。说到这里冬瓜哥不得不贴个图了，下图是飞康CDP（连续数据保护）产品配置时的一幅图样，这张图是让用户在CDP录像日志中选择需要提取的历史时间点，图中明确给出了每个历史时刻的IO压力统计，以协助用户选择那些压力小的时间点用于回滚。

点击zoom in按钮之后，可以放大到该时刻附近5分钟内的IO压力图式窗口（还可以继续zoom in），在窗口中看到，这5分钟内系统发生了两波IO压力，比如可能是分两次写入了两个大文件，选择IO压力为0的时间点，点击确定，系统便会生成一份该历史时刻的快照卷，可以挂起给主机用于数据恢复或者回滚。

可以在第一张图上看到另外一个按钮叫做”Select Tag“，这个也是为了增加数据

一致性的几率而设置的，用户可以在任意时刻，通知CDP系统在日志中生成一个标签，并为此标签任意取名，比如，某时刻用户做了一次手动sync（sync命令），或者手动触发一次checkpoint，或者拷贝完某重要文件并sync，此时用

户可以手动通知CDP系统”帮我记录一下这个时间点“，后续回滚的时候，在界

面中使用”Select Tag“按钮弹出的tag列表便可以明确知道某历史时刻发生过什

么事情，自己要回滚到哪个时间点处。飞康这个设计里除了使用传统快照Agent 之外，还提供了系统IO压力参考、用户手工标签参考这两种方式来一定程度上提升数据一致性的概率。

4.5 应用层复制，强有力的一致性保障

数据库日志级的复制，可以从源头上保障数据的一致性。底层存储端实现复制，有它的通用性，但是数据不一致是个很大问题。应用层直接发两份IO或者事务给本地和远端，两边分别执行这次事务，产生的IO从源头上自上而下执行，是不会有一致性问题的。比如Dataguard，GoldenGate等等。

双活状态下，一样要以保证数据一致性为前提，双活不意味着数据一致，所以，灾备端一样要保留好多份快照以备不时之需。

第五部分：业务容灾

不谈业务的容灾都是耍流氓，这种流氓气尤其在当前的传统存储厂商里尤为严重。几大存储厂商的ppt里，无时无刻不再吹嘘各种复制技术，有些还搞了多个亚版本什么这个mirror，那个copy的，在冬瓜哥看来，全是鬼扯。这些ppt里丝毫

没有提及一件事，那就是容灾来容灾去，业务到底能不能启动？这些ppt仿佛给人一种错觉，那就是只要数据复制过去了，容灾就高枕无忧了。容灾最关键的一步，其实是如何将业务在灾备端启动起来而且能提供服务。在数据一致性的前提下，业务容灾考虑的是如下几个方面：

5.1 业务耦合关系的梳理

传统的HA双机暖切换，只是个把应用，没什么大问题。但是，如果整个数据中心里的所有业务都要切换到灾备中心的话，这就是个大问题了。哦？难道不是直接在灾备中心啪啪啪（接连打开所有应用服务器开关，其实现在都是远程开机

了。。）就行了么？大错特错。多个业务之间是有耦合关系的，很简单，和硬件一样，先起网络也就是交换机，再起存储系统，最后起主机，为什么？因为先得把路铺好，然后把地基打好，然后楼房才能起来，如果主机先启动，结果认不到存储，就会出问题，主机和存储起来，网络不通，主机照样认不到存储。业务之间，也是这种关系，中间件先起，包括MQ之类，这是业务之间的通路，然后再按照依赖关系，被依赖的一定要先启动。如果依赖别人的业务先启动，也不是不可以，比如，这个业务有可能会不断尝试连接被依赖的业务，如果这个业务程序有足够的健壮性，那么是没问题的，但是谁知道哪个业务有当初是外包给谁写的？不排除某些没有底限的外包公司比如某软之流，什么人都敢用的那种，给你弄几个坑进去，比如重连一千次内存溢出了，重启应用起得来算你走运，如果一旦由于这次崩溃，导致该业务关键元数据遭到破坏，再也起不来了，得重装应用，那就等着哭吧。尤其是对于金融、电商这种业务繁多，关系复杂的业务系统，梳理业务关系成了容灾规划中最重要的一环。

5.2 演练和切换

所谓容灾演练，有两种模式，一种是假练，一种是真练。前者就是对灾备端镜像卷做一份快照，然后把快照挂给主机，启动主机，看看业务能不能在这份快照上起得起来，起得来，演练结束。真练也分多种，比如其中一种是把源端业务停掉，然后底层对应Lun的复制关系做计划性切换，从备份站点，然后从备份站点启动业务主机，客户端连接灾备站点的业务主机，业务跑得起来，则演练成功，这是完全计划性的；还有一种是真拔光纤，包括前端客户端连接业务主机所用的光纤和存储之间复制所使用的光纤，远端主动探测故障发生，然后将Lun复制关系分裂开，远端启动主机考察能否启动。真练一般人没敢练的，因为绝对会影响业务，在业务繁忙时期，谁想真练，那是需要极大勇气的，得抱着必死的决心。因为当你决定切换复制关系之后，就已经没有退路了，这期间，一旦切换出现什么问题导致两端状态机错乱，或者卡在中间卡死，进退两难，那就哭吧。就算切过去，还有下一道考验，也就是起业务，就算业务都起来了，还有下一道考验，客户端成功重定向到新的业务服务器地址，最终业务跑起来。还有，演练完了你还得回切，又来一遍。这些动作，真不敢在白天业务忙的时候搞，要搞也是夜深人静跑完批量清算之后。

正因如此，真的发生故障之后，很少有人敢真的切到灾备中心去，都是尽力尝试把本地问题解决，重新在本地启动业务，宁肯拖半天或者一天。

5.3 半自动化业务容灾辅助工具

容灾真是个头疼的话题，灾难发生之后，流程最为重要，先干什么，后干什么，要将所有的东西串起来。当然，几乎所有案例都表明，灾难发生后，能在本地把问题解决的，宁愿等待，但是如果真的是极大的灾难，不得不切换的时候，这时候就真的靠平时演练时候获取的经验了。一般来讲，容灾管理人员会制作一张详尽的流程图和表，来规范切换步骤。然而，对于一个拥有复杂业务数量和关系的系统，在灾备端启动起来，挑战较大的就是必须得按照步骤来，靠人工极容易出错，尤其是在执行一些繁琐重复的步骤的时候，此时，如果能够有某种工具来辅助人们完成这个任务，就比较理想了。然而，在容灾体系里，机器只能起到辅助作用，如果让机器来实现全自动化容灾切换，这只能是个幻想，技术上可以做到，但是风险极大，除非你只有一个应用，做个双机HA，完全可以全自动化，对于复杂的耦合业务，是不敢交给机器来做全自动切换的，因为一旦出现不可预知问题，你连此时的状态卡在哪一步可能都不知道，就会处于进退两难的境地。

半自动化容灾辅助工具，其相当于先将底层一些太过繁琐的动作，封装起来，比如“切换复制关系”，这个动作，可能对应底层存储系统的多项检查和配置。这些过程，完全可以靠机器来辅助实现，并且将封装之后的对象、流程，展现在界面里，发生问题的时候，靠人工手动的从界面中来控制将哪些资源、按照什么顺序、切换到哪里去。对于一些大型金融、电力等企业，其容灾管理工具都是定制的。而市面上也鲜有通用场景下的商用的容灾管理工具，早期的一些双机HA管理工具也可以算是一种最原始的容灾工具，但其产品设计出发点仍然是少数主机少数应用的局部切换管理。目前搞范围较大的容灾管理工具的厂商比较少，因为这牵扯到太多因素。

H3C之前有个容灾管理的产品，但是却太过注重流程步骤本土化管理方面的辅助，而在技术上没有下什么功夫。飞康有个产品叫做RecoverTrac，则是在技术上狠下了功夫，而流程步骤的管控上则欠缺。RecoverTrac是个套件，其中包含不少组件，其支持V2P，P2V，V2V，P2P四种本地恢复方式，以及可以配合飞康自身的NSS/CDP产品实现异地容灾管理，并且支持VMware和Hyper-V虚拟化环境容灾和物理机容灾融合管理。RecoverTrac做容灾管理的主要思路就是先把所有的东西描述成对象，比如，所有参与容灾的物理机、虚拟机、存储系统、逻辑卷资源、虚拟机资源等，都统一在管理界面中被创建为对象，然后创建容灾

任务，任务中会把对应的对象包含进来，用任务来管理在什么时间，把什么对象，做什么样的操作，比如，当发生何种灾难时，把哪个或者哪几个卷挂给哪个或者哪几个主机，然后在对端起哪台或者哪几台机器，按照什么顺序启动，物理机还是虚拟机，等等诸如此类的策略。RecoverTrac支持IPMI，HP的iLO等远程管理协议，可以直接无人值守启动物理机。

可以看到，在配置Failover机的时候，可以设置该主机拖延多长时间启动，以应对对业务启动顺序有严格要求的场景。

RecoverTrac在容灾的技术层面做得非常细致，其中很多更强大的功能冬瓜哥很多也不甚了解，还有待发掘。

波分双活系统容灾链路架构设计

波分双活系统容灾链路架构设计

目录 1.容灾通信链路的选择 (3) 2.容灾链路连接方式 (4) 3.链路复用方式选择 (5) 4.同步数字系列 (6) 5.波分多路复用 (7)

容灾通信链路设计是保障用户在合理的通信成本下成功实现容灾系统建设的重要步骤。不同的通信链路有不同的属性，如距离支持、带宽能力等，而不同的容灾技术和容灾应用对通信链路的要求并不相同。 1.容灾通信链路的选择 对于容灾方案，无论采用哪种容灾通信链路，都需要从信息系统灾备的实际需求出发，确定风险的类型，分析各业务系统不同的容灾要求，明确灾备系统的RTO和RPO的目标。用户还需要根据应用数据特点、可以承受的成本来选择合适的数据传输方式。容灾通信链路的选择需要解答以下问题: ?容灾通信链路距离(即生产中心到容灾中心的距离)，需要根据抵御的风险类型确定，如区域性灾难需要选择异地灾备，站点灾难可选择同城灾备，系统或设备故障可选择同机房灾备。 ?容灾通信链路带宽，需要根据业务应用分析，明确RTO和RPO需求，从而确定需要哪种带宽链路和需要多少条。 ?容灾通信链路选择后，还需要根据应用系统的数据变化量、数据传输的可靠性，进行验证确认设计的链路是否满足预期的目标。目前数据远程传输的主要方式、优缺点、适合的传输距离如表所示。

2.容灾链路连接方式 当前业界容灾方案的通信链路基本采用“裸光纤直连交换机方式、通过DWDM设备连接裸光纤方式、IP网络方式”等，每种方式各有利弊，基于应用的容灾技术建设容灾系统，主要采用标准的IP网络连接，通信链路可以是ATM、E1/E3、IP等，如果采用基于存储或虚拟存储的技术来建设容灾方案，则可以采用裸光纤、DWDM、SONET、SDH等通信链路，也可以通过FCIP设备利用ATM、E1/E3、IP等通信链路。 目前主要传输介质是光纤，按照数据在光纤中的传输模式可分为单模光纤和多模光纤。其中多模光纤由于存在模式色散，在长距离传输时会使光纤的带宽变窄，降低其传输容量，其有效传输距离为2~4km。因此在远距离(大于等于100KM)的传输中一般采用单模光纤进行传输。

数据中心容灾备份方案完整版

数据中心容灾备份方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于 30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。 备份介质层（内置虚拟带库）：主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等，一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质，用于近期的备份数据存放，将物理磁带库或者光盘库作为二级备份介质，用于长期的备份数据存放。

数据中心容灾备份方案

数据保护系统 医院备份、容灾及归档数据容灾 解决方案

1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化HIS、LIS 和PACS 等系统是目前各个医院的核心业务系统，承担了 病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 2.1 数据备份解决方案 针对于医院的HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的LAN 或LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。

数据中心项目建设方案介绍

数据中心项目建设 可行性研究报告 目录 1概述 1.1项目背景 1.2项目意义 2建设目标与任务 数据中心的建设是为了解决政府部门间信息共享，实现业务部门之间的数据交换与数据共享，促进太原市电子政务的发展。具体目标如下：建立数据中心的系统平台。完成相应的应用软件和数据管理系统建设，实现数据的交换、保存、更新、共享、备份、分发和存证等功能，并扩展容灾、备份、挖掘、分析等功能。 (一)建立数据中心的系统平台。完成相应的应用软件和数据管理系统建设，实现社会保障数据的交换、保存、更新、共享、备份、分发和存证等功能，并扩展容灾、备份、挖掘、分析等功能。 (二)建立全市自然人、法人、公共信息库等共享数据库，为宏观决策提供数据支持。对基础数据进行集中管理，保证基础数据的一致性、准确性和完整性，为各业务部门提供基础数据支持； (三)建立数据交换共享和更新维护机制。实现社会保障各业务部门之间的数据交换与共享，以及基础数据的标准化、一致化，保证相关数据的及时更新和安全管理，方便业务部门开展工作；

(四)建立数据共享和交换技术标准和相关管理规范，实现各部门业务应用系统的规范建设和业务协同； （五）为公共服务中心提供数据服务支持，实现面向社会公众的一站式服务； (六）根据统计数据标准汇集各业务部门的原始个案或统计数据，根据决策支持的需要，整理相关数据，并提供统计分析功能，为领导决策提供数据支持； （七）为监督部门提供提供必要的数据通道，方便实现对业务部门以及业务对象的监管，逐步实现有效的业务监管支持； （八）为业务数据库的备份提供存储和备份手段支持，提高业务应用系统的可靠性。 3需求分析 3.1用户需求 从与数据中心交互的组织机构、人员方面进行说明。

XXX数据中心升级及容灾改造项目招标文件(原方案)

XXX数据中心升级及容灾项目 采购招标文件. 招标内容及技术要求 一、本项目工程建设的背景和现状 随着我院信息系统的不断发展，业务系统的数据量、数据处理量和数据存储量越来越大。因此，业务系统的稳定与否，系统的保护和数据的保护是否健全，已成为本系统是否正常运行的关键。随着数据集中处理的实施，可以预计，我院信息系统的业务运作、管理模式将越来越依赖于计算机系统的可靠运行。我院所提供服务的连续性以及业务数据的完整性、正确性、有效性，会直接关系到业务的生产、管理与决策活动。这就要求我们对网络、通信线路、服务器主机等关键硬件设备以及数据库，应用服务器等软硬件进行相应的故障保护和容灾备份部署。一旦某一环节出现异常情况，如火灾、爆炸、地震、水灾、雷击或某个方向通信线路故障等自然原因以及电源机器故障、人为破坏等非自然原因引起的灾难，我们可以快速及时的进行灾难恢复，将损失降到最低点。如果没有全面的考虑容错、容灾设计，那么在任何一个环节上发生故障和灾难，都会导致业务无法正常进行，造成重要数据的丢失、破坏，造成相关的部门的系统中断，不仅不能社会大众提供正常的医疗服务，甚至在极大程度上会影响医院的形象和声誉，使日后的工作无法正常开展下去。因此，根据本系统的特点，必须充分考虑各种灾难情况，建立灾难备份系统。另外我院于2008年对整个信息系统平台的软硬件设备进行升级和改造，至目前为止已经使用将近7年时间，目前的系统平台设备已经慢慢出现故障增多、性能下降等问题，也急需要对整个系统平台进行升级。

二、采购内容及招标需求 1. 采购原则及规范： 本次公开招标采购XXX数据中心升级及容灾项目的有关设备，投标人所投设备必须按招标文件规定的配置要求提供，并满足招标文件中提出的相关性能指标参数，同时应能满足XXX局信息化系统的当前以及今后3-5年内业务发展的需求。 投标人应对所提供的设备性能、质量负责，并提供相应的安装、服务、质保及技术培训。采购的设备所涉及的产品标准、规范，验收标准等，应符合国家有关条例及标准的规定。 2. 采购设备清单（预算：140万元）

数据中心灾备系统的分类

数据中心灾备系统的分类 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术 正常情况下系统的各种应用在数据中心运行，数据存放在数据中心和灾难备份中心两地保存。当灾难发生时，使用备份数据对工作系统进行恢复或将应用切换到备份中心。灾难备份系统中数据备份技术的选择应符合数据恢复时间或系统切换时间满足业务连续性的要求。目前数据备份技术主要有如下几种: (1)磁带备份。 (2)基于应用程序的备份。通过应用程序或者中间件产品，将数据中心的数据复制到灾难备份中心。在正常情况下，数据中心的应用程序在将数据写入本地存储系统的同时将数据发送到灾难备份中心，灾难备份中心只在后台处理数据，当数据中心瘫痪时，由于灾难备份中心也存有生产数据，所以可以迅速接管业务。这种备份方式往往需要应用程序的修改，工作量比较大。另外，

(完整版)适合云化数据中心的备份容灾系统

a t i m e a n d A l l t h i n g s i n t h e i r b e i n g a r e g o o d f o r s o 适合云化数据中心备份容灾系统 以虚拟化、超融合、云平台等为形态的云化数据中心已经成为越来越多的企业机构数据中心升级方案。据权威媒体统计，云每年以25%的速度增加，其中虚拟化渗透率大于80%。云在按需交付、资源池化等方面有先天的优势，但随之也带来更多的数据和业务安全风险。无论是自建的云还是公有云，每年都频繁 发生大量的数据安全和业务中断事故。 在备份容灾管理领域，一方面IT 基础架构的云化变化速度已经大大超出了现有的数据保护技术的变化速度，而另一方面不少厂商又都声称自家的产品可以备

a t i m e a n d A l l t h i n g s i n t h e i r b e i n g a r e g o o d f o r s o 份云。那么到底该如何选择真正适合云化数据中心的备份容灾系统，本文重点从以下几个方面展开讨论。 什么是云化数据中心？ 简单讲，就是当业务需要，数据中心可以在数分钟内增加或减少业务所需要的计算、存储、网络等资源。再简单讲，就是随时增加或减少可以安装部署业务应用软件的服务器。 自建云化数据中心的方案有多种思路，如下：1、虚拟化为中心的经典架构 这种方案是目前最主流的云化数据中心方案，主要采用的方案就是虚拟化操作系统、服务器与企业级集中式存储，该方案成熟度最高。这种方案，随着虚拟

a t i m e a n d A l l t h i n g s i n t h e i r b e i n g a r e g o o d f o r s 机规模增加，底层的集中存储会越来越感觉到不够用。这时候需要增加新的存储或服务器部署，重新迁移或分布虚拟机系统。2、以OpenStack 为代表的开源大集成架构 这套体系接近公有云平台的体系，主要的3个核心服务都采用高度弹性的方案来构成。随着引入的服务越多，运维管理复杂度也大幅度提升。目前开源体系最大的问题在于企业级运维管理的能力较弱，可靠性不能很好保障，可管理性差，易用性方面门槛很高，需要高度依赖商业发行版企业来保障持续的运行。这类平台通常是从几千到上万个虚拟机规模，是一些大型企业在重点升级的云 架构方案。 3、各类公有云的企业部署版本 国内的云计算公司，都相应推出了企业内部部署的版本，与OpenStack 的架 构类似，核心也包含3大核心服务，以及各类上层应用服务。第2、第3这类

数据中心容灾备份方案

数据中心容灾备份方案 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】

数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于 15 年；住院电子病历保存时间自患者最后一次出院之日起不少于30 年。

2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。

“双活”容灾引领现代备份技术

“双活”容灾引领现代备份技术虽然每周全量夜间增量备份仍是常态，但很多组织机构逐渐发现他们的数据（以及恢复那些数据所需的条件）打破了长久以来传统备份所依赖的模型。存储管理人员备份操作不当，意味着困难并关键的备份现代化任务迎面而来。 备份现代化将是一个有点痛苦的过程，不仅需要选择一项备份技术，还需要考虑这种转变对关键业务处理和需求的影响。 备份替代技术考量 就备份现代化来讲，有各种各样的解决方案，无论经济实用型方案，还是舶来品。不过，当今有三类主要的数据保护策略： ·持续数据保护 ·快照 ·基于镜像的备份 CDP技术对数据进行近乎连续不断地保护。并非在夜间进行大型备份，CDP产品的备份全天候执行，每隔几分钟就进行一次。CDP产品首先将数据以块的方式复制到磁盘备份介质中。当某个块被创建或更改时，该块被备份。CDP有对版本信息进行跟踪的索引，而数据重删技术能够保证只有不重复的块会被存储到备份介质中。 快照与备份有所不同，前者并不创建数据的拷贝，而是提供将虚拟机、文件或应用回滚到先前某点状态的方法。快照是使用磁盘差分或指针的技术。由于快照并不进行实际备份，一些备份厂商将快照作为一种提高自身产品恢复能力的方式，而不是将其用作单独的数据保护策略。 基于镜像的备份代表着备份领域一种新的策略，并应用于虚拟机备份中。此类备份源于这样一种思想即备份处理对虚拟机进行整体数据捕获。如果需要进行恢复操作，将虚拟机的拷贝挂载至沙盒环境中用以承载数据。沙盒挂载能力有时也用来提供本地恢复测试甚至模拟实验能力。只要你受保护的资源全部部署在虚拟服务器上，基于镜像的备份就能够提供显著的灵活性。

重大业务考量。不管你选择使用哪种备份技术，都有一些与公司业务需求相关的重要因素需要考虑。一些因素在购买一个新的备份系统前就需要考虑，另外一些在新的备份系统安装完毕时，就需要立即考虑。 保留需求。选择一个现代备份系统时你最先需要考虑的你的备份保留要求，换句话说，你在多长的时间之内会需要检索数据。 这样的考虑很是重要，因为大多数现代备份方案都是基于磁盘或云服务，或者两者都是。以磁带为基础的备份能够提供近乎无限的保留跨度，因为你能备份到磁带上，而你想将磁带保留多久都可以，而基于磁盘的备份却并非如此。磁盘的容量是有限的，而容量会影响能够保留在备份中历史数据的总量。 快照的回滚可能引起数据库崩溃，除非该快照产品经过特殊设计，能够与你服务器上运行的应用一起工作。 即使磁盘的容量不是一个问题，一些现代备份应用也会有各种限制。比如，一些CDP 产品区分短期保存（磁盘）和长期保存（磁带），并对前者存储介质上的恢复点数量有十分严格的限制。 代理软件兼容性。如果你正在考虑的备份方案是基于代理的，那么就必须在购买之前把代理软件的兼容性当做一个首要考虑因素。尽管大部分备份软件提供商都会提供适用于大多数流行的操作系统的代理软件，你仍需要核实在你自己的环境下运行的操作系统中，该软件是否能正常使用。 业务识别性。在选择一个备份业务时，业务识别性是最重要的一个标准之一。如果你的备份不仅仅是文件数据，那么你的备份软件都必须支持你所运行的业务。 对于CDP或基于镜像的备份产品，业务识别性的确认通常意味着验证某备份产品是否包含一个Microsoft卷影复制服务（VSS），服务器上你所备份业务的运行需要它。对于快照产品，你则需要找寻细粒度应用回滚功能。 尽管大多数快照应用支持整个服务器的回滚，但可能会对数据库应用造成很严重的后果。因为在获取快照时，快照并不能捕捉储存在服务器内存中的处理状态。因此，快照回滚可能引发数据库崩溃，除非某快照产品对你服务器上的应用进行了定制化设计。 初始备份。在你付费并部署了现代备份解决方案之后，关于你的首次备份，有些事情需

数据中心机房容灾方案

数据中心机房容灾方案

前言： 数据中心全年不休地运行，一旦发生不可预知的灾难，如果对数据中心机房造成设备损坏将是一笔不小的损失，设备损坏至少还能弥补修复，但如果是宝贵的数据丢失，造成的损失则是无法计算的。 所以建设数据中心机房容灾方案，把有效的数据备份系统尤为重要，万一发生一些故障造成了数据丢失，还可以从备份系统中将数据还原回来，这就要使用数据备份技术，数据备份技术是将整个数据中心的数据或状态保存下来，以挽回硬件设备损坏带来的损失，还有逻辑错误和任务恶意拨号带来的损失，是将数据从在线状态剥离到离线状态的过程，这样做的根本目的是数据恢复，能够快速、正确、方便地恢复数据。 数据备份技术在存储系统中的意义不仅在于防范意外事件的破坏，而且还是历史数据保存归档的主要方式，机房的数据备份服务如日中天，大多数数据中心机房都提供数据备份的增值服务，但基本都是通过手工备份或免费的软件提供一些最简单的功能，得不到用户的认可，同时也限制了数据备份业务的快速增长，那有没有一种专业的备份软件，既拥有强大的功能，成本又比较低廉的数据备份服务平台。

零成本容灾方案让数据中心运营商轻松架设自己的增值备份服务平台，像卖虚拟主机一样卖数据备份服务，用户通过帐号自主管理，按空间大小和时间长短随时随地的管理数据备份服务。 1、服务模式：按需部署，按时服务，按空间大小和时间的方式提供数据备份服务； 2、低启动成本：按需投入硬件和带宽，服务启动时，只需将现有的容灾备份硬件安装上软件就可按空间大小和时间卖数据备份的增值服务。

3、容灾备份硬件不仅提供基于数据中心机房的合作，在下一步将会提供更多的在数据备份服务市场上更多的合作机会。 4、灵活的产品包装：根据容灾软件提供的强大的功能，灵活包装产品： （1）按容灾级别：本地备份，远程备份； （2）按空间大小：10G，20G，50G，100G等。。。 （3）按数据类型：文件备份，数据库备份，操作系统备份。。。 （4）按时间长短：1月，3月，1年，3年，5年等。。。。

数据中心灾备系统建设方案

数据中心灾备系统的分类 来源：机房360 作者：林小村更新时间：2010/11/19 11:50:11 摘要：本文为大家讲述数据中心的一些技术知识，具体为您讲述数据 中心灾备系统的分类情况。 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程

数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术 正常情况下系统的各种应用在数据中心运行，数据存放在数据中

浪擎——理解应用系统的“双活”可靠容灾

浪擎——理解应用系统的“双活”可靠容灾 容灾系统，对于IT而言，就是为计算机信息系统提供的一个能应付各种灾难的环境。当计算机系统在遭受如火灾、水灾、地震、战争等不可抗拒的自然灾难以及计算机犯罪、计算机病毒、掉电、网络/通信失败、硬件/软件错误和人为操作错误等人为灾难时，容灾系统将保证用户数据的安全性（数据容灾），甚至，一个更加完善的容灾系统，还能提供不间断的应用服务（应用容灾）。 可以说，容灾系统是数据存储备份的最高层次，容灾系统包括两个层面的问题，数据容灾和应用容灾。 数据容灾就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。在本地数据及整个应用系统出现灾难时，系统至少在异地保存一份可用的关键业务的数据。应用容灾是在容灾的基础上，在异地建立一套完整的与本地系统相当的备份应用系统，在灾难情况下，远程系统迅速接管业务运行，数据容灾是容灾系统的基本要求，而应用容灾是系统建设目标，应用容灾必须建立在数据容灾的基础之上，通过整合应用系统、网络系统等各种资源来实现。 我们知道，基础的数据容灾可以保护用户数据的安全性。而一个高端完善的“双活”容灾却可以提供不间断的应用服务，能够保护数据的安全性，以及业务应用的一致性和可靠性。 浪擎A系镜像系统采用ACA引擎，实时捕获源端生产系统的数据，然后还原成应用系统的数据库记录，再通过目标端保存到目标数据库中，实现完整的复制过程。 A镜像系统基于应用层面的数据库事务复制，能够深刻理解应用系统，提供最可靠的容灾，这是和其他同行最本质的技术区别。备用端数据库在线运行，可以直接使用，ACA引擎复制原理决定了备用端数据库处于在线运行状态，可以直接验证容灾效果，整个复制过程通过WEB实现监控完全可视化。 当其他同行的复制技术还停留在I/O层面时，浪擎早已站在了应用层，复制数据库事务。

浪潮双活存储解决方案

浪潮双活存储解决方案 Prepared on 22 November 2020

浪潮数据中心存储双活解决方案 【需求分析】 大数据时代，数据已经成为各行业至关重要的核心资产。传统的灾备方案中存在着资源利用率低、可用性差、出现故障时停机时间长、数据恢复慢、风险高等问题。数据是否安全、业务是否连续运行无中断成为用户衡量一个灾备方案的关键。 传统数据中心存储灾备一般采用主备模式，只有当生产数据中心存储故障后，灾备中心存储才会接管数据访问业务，并且此过程需要手动执行，将灾备中心对应的业务Lun手动激活读写服务；此外，主备数据中心的模式，在正常业务运转情况下，只有主中心发挥作用，备中心的资源一直处于“待命”模式，无法最大程度发挥所有资源的效率。 双活数据中心将是未来数据中心发展的趋势，而存储双活又是数据中心双活的重要基础。 【浪潮存储双活方案设计】 浪潮AS8000-M3使用虚拟卷镜像与节点分离两个核心功能实现数据存储的双活构建： ?AS8000-M3虚拟卷镜像功能实现： 浪潮AS8000-M3作为异构存储整合的专业设备，可以实现在两台存储设备之间实现逻辑卷的镜像。保障单个磁盘的故障或单台存储的故障都不造成对前端服务器性能的影响，实现业务连续性。 上图是通过AS8000-M3实现两台阵列之间存储镜像的示意图，对于底层的磁盘阵列来说，其使用方式与现在相同，对其内部的磁盘先进行RAID，然后在RAID组上进行逻辑磁盘（LUN）的划分。如上图的例子中，首先对两个阵列的磁盘做RAID5，然后在左边阵列中再作成LUNa和LUNb两个逻辑磁盘，同样在右边阵列中可以作成LUN1和LUN2两个逻辑磁盘。AS8000-M3将从左边磁盘阵列获得的管理磁盘a和从右边阵列获得的管理磁盘1进行镜像后，形成了虚拟卷为虚拟卷1，然后再将虚拟卷1映射给服务器。服务器就像使用本地磁盘一样的使用虚拟卷1。使用AS8000-M3进行跨阵列镜像后，对于服务器获得的虚拟卷来说，不会因为任何一个后端磁盘存储系统的故障而出现问题。 ?AS8000-M3节点分离功能实现： 浪潮AS8000-M3拥有节点分离功能，可以把AS8000-M3一个节点组中的两个控制器节点分开放置，两个节点间最远距离可以达到100KM，AS8000-M3节点分离功能只是物理节点的分开放置，但是在用户对于数据的访问以及在 AS8000-M3对于后挂存储空间的管理上与一个节点组处理方式相同，如果一个

HDS三数据中心容灾解决方案

HDS三数据中心容灾解决方案 国内灾备业的发展 随着国内各行业信息系统的快速发展，特别是银行、证券、保险和政府等行业业务大集中速度的加快，企业的技术风险也相对集中。一旦发生灾难，则将导致政府和企业所有分支机构、营业网点和全部的业务处理停顿，或造成企业客户数据的丢失。如何防范技术风险,确保数据安全和业务连续性，已成为企业急需面对的课题。 国家相关部门对加强信息安全保障工作十分重视，先后出台了多项有关信息安全保障措施。如中国人民银行于2002年8月下发了《关于加强银行数据集中安全工作的指导意见》，指出："为保障银行业务的连续性，确保银行稳健运行，实施数据集中的银行必须建立相应的灾难备份中心。" "业务连续性计划应报中国人民银行备案。"。 2003年9月，中共中央办公厅、国务院办公厅转发了《国家信息化领导小组关 于加强信息安全保障工作的意见》，明确提出要重点保障重要信息系统的安全，强调重要信息系统的建设要充分考虑灾难发生后的抗毁性与灾难恢复能力。 从以上资料可以看出，信息系统安全和灾难备份已经引起了国家、社会、企业的高度重视，灾难备份业务的发展是客户保持业务连续运作的需要，同时也是社会的需要和政策法规的要求，是市场发展的必然。 中国国际电子商务中心的数据容灾要求及选择 隶属于中国商务部、成立于1996年的中国国际电子商务中心（China International Electronic Commerce Center，简称CIECC），肩负着国家信息化建设重点工程（金关工程）主干网的建设、维护和运营，是中国国际电子商务权威、稳定、安全的第三方服务平台。近几年，随着业务电子化平台的逐步建立和完善，CIECC服务的企业不断增加，数量近百万家，同时提供的服务种类也日益丰富。为了提升对数据的保护水平并确保业务连续性，CIECC从2005年初开 始酝酿建设一套安全可靠以及高效的容灾系统：以北京亦庄的数据中心为主生产中心，在同城的东单建立同城容灾系统，并在广州建立异地容灾系统，以此构成三数据中心容灾备份系统来实现最高级别的灾难恢复能力和业务连续性。 经过对多家主流厂商容灾方案进行谨慎和严格的评估，CIECC最终于2006年底 选择了由日立数据系统公司（HDS）提供的采用了Delta Resync技术的三数据中心容灾解决方案来为其核心业务应用提供最强大的数据保护。 事实上，CIECC的核心业务系统早在三年前就采用了HDS公司的存储产品（9980V），双方从此开始了良好的合作。从2005年初一直到2006年底的前后约一年半时间。HDS团队全程参与了为CIECC进行业务影响分析、容灾计划定制、容灾架构设计、SAN架构设计、数据迁移、同城容灾实施、异地容灾实施、容灾演练和培训等容

双活容灾,大势使然

“双活”容灾，大势使然 在信息化日渐普及的今天，各种业务对信息系统的依赖性也在逐步提升，政府、金融、电信等行业的关键业务系统已经高度信息化，并且应用数据和系统在一定程度上完成了集中，与此同时也对数据安全性提出了更高的要求，尤其是在应对各种自然和人为灾难方面，对数据的灾难备份提出了更复杂的需求。 面对需求的不断变化，同质化的灾备解决方案显然已经无法满足实际应用，事实上，用户不同，对于灾备的需求程度、投资预算等各方面都不同，用户需要差异化的产品来满足自身的需求。那么，灾备解决方案究竟应该朝哪个方向演变，才能跟上需求变化的脚步，发挥出更多的作用呢？ 有两个方法可以有效验证备份数据的正确性，一是灾备演练，二是备端数据实时查询。 灾备演练可以证明容灾系统的可靠性，验证当真正发生灾难时容灾系统能够正常使用，但演练过程同样隐含了较多的风险，稍有失误轻则演练失败，重则造成业务宕机或数据丢失事故，灾备演练技术要求极高，系统稳定性极好才可以尝试使用。 一位灾备外包服务商抱怨说：“我们每次都很积极地帮助客户进行灾备演练，但是有些用户对演练根本不重视，总以人员不齐等为由拒绝进行演练。”灾备系统如果不经过演练，很难保证在发生灾难或事故时真正发挥作用。在美国，一些银行通常每个季度都会进行两次容灾演练。在国内，我们接触到的50%以上的银行客户，平均每年会做2～3次演练。银行通常会做真枪实弹的容灾演练，也就是每次演练时都会进行实际的灾备系统切换。 另一种可靠的技术就是备端数据实时查询，浪擎独有的双活容灾，已在浙江大学医学院附属邵逸夫医院成功实施，这是浙江省最大的集医疗、教学、科研、保健、康复、急救为一体的综合性三级甲等医院，其数据之大可想而知。 随着医院信息化更深化建设与应用，信息化系统已经成为医院的核心，保存着每个患者的门诊、急诊、各种病例、治疗情况、检查报告医嘱等重要信息，这些信息关乎到了很多人

系统容灾技术方案大全

系统容灾技术方案大全

目录 一、数据中心灾备系统的分类 (3) 二、数据库远程复制和异地容灾方案相关分析 (11) 三、数据备份与数据容灾 (14) 四、重复数据删除成就异地容灾 (15) 五、金税工程三期背景下省级容灾备份建设探索 (22) 六、安徽中烟数据集中容灾系统建设实践与探索 (36) 七、推荐九个容灾解决方案 (42) 八、推荐九个容灾解决方案 (42) 九、GDS灾难恢复解决方案 (62) 十、多级企业数据容灾解决方案对比 (65)

一、数据中心灾备系统的分类 摘要：本文为大家讲述数据中心的一些技术知识，具体为您讲述数据中心灾备系统的 分类情况。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。

数据中心灾备系统建设案例

数据中心灾备系统建设案例 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术

双活容灾简介

浪擎AgileMirror镜像系统 ——应用级双活容灾 1.双活容灾──在线式应用级容灾 浪擎AgileMirror镜像系统（简称镜像系统）采用基于应用系统的复制技术，将主服务器上的数据实时复制到备用(目标)服务器上，保持两端数据实时相同，以实现容错。此外，镜像系统还可恢复数据到某一历史状态，以实现容错。镜像系统无需主备端硬件规格、配置相同，且占用资源少、应用灵活。 镜像系统实现备端在线的、双活的应用级容灾，践行在线式应用级容灾理念。在线式是指备用服务器上的数据库是在线的，处于可读可查询的状态，确保容灾是可靠的、稳定的；应用级是指镜像系统复制的数据是数据库事务，是属于应用层的。 镜像系统支持SQLServer数据库、Oracle数据库、文件系统等应用系统的容灾。 2.双活容灾原理概述 镜像系统不依赖DataGaurd、LogMinor、DBCC LOG等数据库自带的日志工具来实现数据复制，完全依靠自身研发的数据库实时捕获引擎ACA和数据组装两大核心技术来实现全量复制和实时增量复制。其实时增量复制过程为：生产端代理进程实时捕捉数据库在线或归档日志的变化数据，然后传输到容灾数据库端；容灾端的装载进程按照数据库标准格式组装这些变化数据块，然后提交给数据库的存储引擎保存到容灾数据库。 容灾端数据库处于在线运行状态，具备最高的可靠性，且用户可以随时查询业务数据来检验容灾结果。这是双活容灾最大的优势。 3.主要功能 1）追逐式全量复制 在第一次部署时，且在不停止生产业务的要求下，自动的将生产端业务系统的存量数据和活动数据全部复制到备用端的数据库。 无需停止生产数据库和无需停止业务系统；无需改变生产数据库的现有配置。

IDC容灾方案建议

IDC 容灾方案建议 1 IDC 容灾方案建议 ... 错误！未定义书签。 ........................ ... 错误！未定义书签。 一、负载均衡需求分析(1) 二、负载均衡方案建议(2) 三、实现方法介绍(4) 1.定义数据中心(4) 2.启动服务器的健康状态检查 (4) 3.针对db2 的容错应用逻辑规定服务优先级别(5) 4.行政命令下达后的IDC 和服务器切换方法(5) 四、相关技术介绍(6) 1.3DNS 处理多数据中心的并行工作和冗灾处理(6) 2.服务器负载均衡(7) 3.Stateful Fail Over 技术(9) 4.F5 i - Control 开放的API 接口介绍(9) 五、所选产品简介(12)

1. 3DNS 分布式高可用性智能负载平衡(12) 2. Big IP 2400/5100/5110 系列应用交换机(18) 六、产品报价与服务(25) 七、附录(25) 1. iControl 用于创建应用型网络的先进互联网控制体系结构(25) 一、负载均衡需求分析 根据客户的行业特点要求,我们总结出来网络的流量管理的具体要求如下: 1．服务站点的负载均衡和异地容灾, 为保证客户在任何时刻都能够访问到内容, 要求解决国际网络接入链路和单个IDC 的单点故障, 保证在ISP 服务提供商出现 不可抗拒因素而中断服务时可以及时监控发现, 并且报警显示; 也保证任何一个 IDC 机房出现不可抗拒因素而中断服务时也可以及时监控发现并且报警显示, 在得到行政命令后可以非常迅速的切换到可用的站点. 2．服务器的应用状态监控, 准确的根据服务器的实际服务状况提供报警信息, 并提供服务器的负载均衡，要求在正常情况下两台或多台服务器的负载基本相同， 在某台服务器停机的情况下透明的容错，保证关键服务的持续,提供特别的会话