数据级灾备.doc

《数据级灾备.doc》由会员分享，可在线阅读，更多相关《数据级灾备.doc（11页珍藏版）》请在三一文库上搜索。

1、灾备介绍灾备对于数据中心建设来说， 地位十分重要， 按照业通例， 依据对数据及业务的保障程度来说， 一般可以分为三个等级： 数据级灾备、 应用级灾备和业务级灾备。我们经常听到有关灾备建设方案就是将异地应用级灾备放在首选， 但这其实是灾备建设的一个误区， 灾备虽然十分重要， 但是并不是说进行灾备建设就一定要建设应用级的， 进行灾备建设一定要从自己的实际需求出发， 找到适合自己业务系统需求的灾备建设方案，这才是灾备建设合理思路。对于灾备的级别， 可能很多人都只了解其中的一两种， 但是不能够了解的比较全面，而这几种灾备之间其实是存在联系的， 所以想要彻底的了解灾备， 就需要进行多方面的了解。 那么首

2、先我们来看三个不同等级的灾备方式的关注点在哪里：数据级灾备、应用级灾备关注点都在 IT 信息系统本身，而业务级灾备则除了充分考虑 IT 系统外也关注了其他外部业务因素诸如办公环境、系统相关人员等。下面我就介绍一下上面提到的三个不同级别的灾备方式。数据级灾备主要关注点是数据， 即在灾难发生之后， 可以确保用户原有数据不受到损坏。对于级别较低的数据级灾备来说， 可以将需要备份的数据通过人工的方式保存到异地实现： 如将备份的磁带 ( 盘或光盘 ) 定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具， 实现生产中心不同备份设备之间或是生产中心与灾备中心之间的异步 / 同

3、步的数据传输，如采用基于磁盘阵列的数据复制功能。应用级灾备是建立在数据级灾备的基础上的， 对应用系统进行复制， 以实现应用接管。而在异地灾备中心再构建一套应用支撑系统是应用级灾备经常采用的方式。支撑系统包括数据备份系统、备用数据处理系统、备用网络系统等部分。应用级灾备能提供应用系统接管能力， 即在生产中心发生故障的情况下， 灾备中心便能够接管应用，从而尽量减少系统停机时间，保障业务连续性。业务级灾备是最高级别的灾备系统。它包括除了保障 IT 系统业务连续性外也提供非 IT 系统保障，如当发生大的灾难时，用户的办公场所可能会被损坏，用户除了需要原来的数据以外， 还需要工作人员在一个备份的工作场所

4、能够正常地开展业务。 那么这时就需要业务级灾备来保障业务连续性了。 实际上，业务级容灾还关注业务接入网络的备份， 不仅考虑支撑系统的服务提供能力， 还考虑服务使用者的接入能力、甚至备份的工作人员。那么我们在进行灾备建设时，到底应如何选择呢？我们可以结合自身情况，从基础设施条件、灾备的目标、技术成熟度、投入产出比、数据及应用系统的重要性，业务关联度等多个角度进行分析。异地灾备应对的是小概率事件，需考虑投入产出比灾难的围很广，凡是可以导致数据或业务遭到破坏的计划外事件都属于灾难的畴，诸如自然灾害、业务运行所依赖的服务的中断、 IT 系统故障、运维人员误操作、恶意攻击等。下图是权威机构对灾难的分类：

5、灾难分类示意图自然灾害病毒攻击7%3%人为错误14%硬件故障32%软件故障44%从上图可以看到，无论是面对占据灾难比重 32%的硬件故障，还是占据 61% 比重的软件、人为、病毒故障，需要的都不是远程的灾备保护，需要的只是本地的数据保护；而剩下的7%的自然灾难和社会灾难，才真正需要异地远程灾备。也就是说，通过双机热备、本地备份、CDP技术等数据保护手段，就能解决93%的系统故障；而远程异地灾备，不论是数据级还是应用级，应对的都只是 7%的小概率事件。既然远程灾备的目标是应对小概率事件（同城灾备是高效率的小概率事件，异地应用级是低效率的极小概率事件） ，那么灾备的投入产出比就非常重要。 一般而言

6、，应用级灾备的投入会是数据级灾备投入的 2-3 倍，甚至更高，而且每一次从生产中心切换到异地灾备中心都需要耗费大量的人力、 物力和时间，而回切的过程也同样复杂而耗费精力巨大。 因此，相对于应用级灾备而言， 数据级灾备的投入产出比更高。 与其建设昂贵的异地应用级灾备， 不如做好本地的数据中心保护，再配合远程的数据级灾备。因此，在现实环境中，我们更常见的是“本地CDP+远程数据级灾备”这种数据保护模式。灾备建设需要考虑循序渐进，分级建设灾备建设的投入很大， 不能一蹴而就一步到位， 需要的是一个循序渐进的过程。数据级灾备和应用级灾备并不冲突， 数据级灾备是应用级灾备的基础， 异地灾备可以先做数据级的

7、。 很多的用户在建设灾备系统时， 往往就先做数据级灾备，后续再扩展成应用级灾备。这么做的原因是多方面的。原因一，与异地应用级的灾备相比， 异地数据级灾备的投入比较小， 却可以在极端情况发生时起到作用。 在出现震等大面积的自然灾害的情况下， 用户其实可以接受一个相对比较长的业务恢复时间， 外界也会有一个比较大的容忍度。 有了异地数据备份后， 就可以用几天甚至更长的时间来恢复业务， 而不至于彻底瘫痪。原因二，灾难备份建设不是一个简单的技术方案，而是一项系统工程， 灾备中心的基础建设、 IT 系统需要一个逐步建设的过程，运行维护团队、技术支持力量需要长期培养锻炼才能具备理想的应急能力。因此，先做数据

8、级灾备， 积累建设经验，培养灾备队伍， 具备相当的能力之后， 再建设应用级灾备系统就会容易很多。此外，在从数据级灾备向应用级灾备过渡的过程中， 还要根据业务系统按需划分灾备等级，不能一刀切。即使在同一个单位或者部门， 也存在多个应用系统。这些信息系统的重要性、复杂度都各不相同，对应的灾备等级也不相同。因此，我们需要根据业务系统的实际需求来逐个确定灾备等级。 一般而言，“2/8 原则”是比较常见的，也就是 20%的应用是关键和核心的，需要应用级灾备，而 80%的应用是非关键的， 需要的只是数据级灾备。 在实际的异地灾备中心建设中， 这种应用级和数据级混合的建设模式是最典型的。在应用级灾备的建设过

9、程中，还存在一些常见的误区，它们是：1. 应用级灾备就是业务自动切换2. 应用级灾备就是数据零丢失3. 应用级灾备就是通过应用层（服务器或者应用软件）来做灾备就第一个误区而言，这其实是一种追求技术的理想主义， 并不适用实际环境。灾备中心的业务接管是一个管理和决策的过程，绝不是某一项具体的技术。 技术不能替代管理， 技术也不能替代决策， 这早已成为了业界的共识。 完善的灾备预案、适时的灾备演练、专业的技术支持队伍才是保障应用级灾备发挥作用的关键。灾备切换是一系列操作的组合，不是单一的技术动作。不管生产中心还是灾备中心， 彼此的业务之间都有逻辑的联系， 服务的启动顺序也有严格的要求。 比如数据库必

10、须先启动， 之后才能启动应用程序； 应用服务器接管完成， 才能进行网络的切换。 如果应用程序先于数据库启动， 结果肯定会是出错。在实际的灾备切换时， 我们看到，操作员都会有一本完整的切换操作手册，上面说明了软件、硬件、服务的启动顺序，每一步的操作容和预期的目标等等。只有严格按照流程操作，才能确保灾备的顺利切换。因此，灾备切换是一系列技术操作的过程组合，不是单一的技术动作。灾备切换是一个决策的过程，不能依靠单一的技术实现灾难的类型多种多样， 不是每一种灾难都需要启用灾备中心。 而每一次灾备中心的启用，都需要耗费大量的人力和物力。因此，在发生灾难时，首要需要做的是快速判断灾难的类型、 可恢复性和后

11、果等容， 然后根据灾备预案来决定是否启用灾备中心。 比如，通过本地备份只需要半小时就能在本地恢复业务， 就完全不需要启用灾备中心。 此外，应用级灾备的对象往往是关键的业务， 越关键的业务，切换就越需要慎重，这不是单一的个人意愿，往往需要的是集体的决策。因此，灾备切换更是一个决策过程，而不是单一的技术实现。在实际案例中， 99% 以上的用户都不会选择自动切换。说到第二个误区“应用级灾备就是数据零丢失” ，很多 CIO 都认为难以理解。应用级灾备当然要求数据零丢失， 这一点通过磁盘阵列的同步镜像软件就能实现，技术上根本没有难度，为什么说这是误区呢？让我们从技术上做一些分析。镜像并不能保证数据的完全

12、同步磁盘阵列具备同步镜像功能， 能够实现主备磁盘阵列的完全数据同步。 但是，磁盘阵列的数据同步并不意味着应用的数据也是同步的。 这是因为为了提高性能，服务器一般都采用了写缓存， 写缓存的数据并没有实时的真正写入到磁盘阵列上，因此，磁盘阵列上的数据和应用的数据是存在差异的。 如果生产中心发生了故障，即使磁盘阵列的数据是同步的， 也无法保障应用服务器的缓存数据也同步传输到了灾备中心。镜像会降低生产中心的性能镜像的实现机制是一个写IO 要同时得到主备磁盘阵列的响应后，才能返回写 OK。也就是说，对数据的一个写操作，需要主备磁盘阵列的二次写操作确认和主备站点的来回传输，时延会是普通写操作的 3-5 倍

13、，甚至更高。因此，采用数据镜像后，会给生产中心带来比较明显的性能影响。此外，如果链路不稳定，出现闪断、抖动等情况，就会进一步加大生产中心的影响。从上述的分析可以看出， 镜像方式并不像想象的那么完美。 那么什么机制才是比较有效的呢？一些厂家采用的准实时复制技术就是一种答案， 比如 H3C的自适应复制技术。如果采用这种技术， IO 写入主磁盘阵列就返回 OK，然后复制模块 再将这个写 IO 采用异步复制的方式传输到灾备阵列。 这种方式不会降低主磁盘阵列的性能， 还能做到准实时的数据同步。 如果再把自适应复制技术和快照技术相配合，还能保证灾备中心的数据一致性， 从而实现灾备中心的数据丢失量最少，数据

14、肯定可用。第三个误区也是我们经常碰到的， 主要是把数据同步和应用接管两个概念混在了一起。应用级灾备包括两个方面： 数据同步和应用接管， 其中数据同步是应用接管的基础，但数据同步和应用接管是两种不同的技术。数据同步的技术多种多样，即可以基于存储阵列的复制软件实现，比如 EMC MirrorView 、H3CReplication 等，也可以基于服务器或者应用软件实现，比如 Veritas VVR 、 Oracle DataGuard 等。但不管采用何种技术，都只是在不同的层面实现了数据的同步， 要具备应用接管， 还需要其他组件的配合， 比如 DNS域名切换解析、备用网络启用、应用服务切换等等。在

15、现实环境中，我们最常见的应用级灾备方案是“磁盘阵列的数据复制 +备用服务器”，也就是通过磁盘阵列来实现数据同步，通过备用服务器提供业务接管能力。数据级容灾和系统级容灾都是在IT 畴之，然而对于正常业务而言，仅IT系统的保障还是不够的。 有些用户需要构建最高级别的业务级灾备。业务级灾备的包括很多非IT 系统，比如、办公地点等。当一场大的灾难发生时，用户原有的办公场所都会受到破坏， 用户除了需要原有的数据、 原有的应用系统， 更需要工作人员在一个备份的工作场所能够正常地开展业务。实际上，业务级容灾还关注业务接入网络的备份， 不仅考虑支撑系统的服务提供能力，还考虑服务使用者的接入能力、甚至备份的工作

16、人员。灾备选择的适用性原则简单来说，从数据级灾备、 应用级灾备到业务级灾备， 业务恢复等级逐步提高，而需要的投资费用也相应增长。 由于灾备所承担的是用户最关键的核心业务，其重要作用勿庸置疑。 灾备涉及到众多技术以及众多厂商的各类解决方案， 其复杂性也不言而喻。因此，在灾备建设中，不论是数据级灾备还是应用级灾备，适用性是构建灾备系统的一条基本准则。用户需要根据自身的实际需求量身打造，而在实际建设中，许多用户的灾备站点也都是经过长期积累、多次改造后形成的。无论数据级还是应用级， 都只是灾备建设的技术手段。 灾备建设作为一项系统工程，远远超出了这个技术畴。要想灾备系统在关键时刻能发挥应有的作用，完善的灾备应急预案、 定期的灾备演练、 强大的技术支持和保障机构等等都必不可少。总结而言，数据级灾备关注于数据的备份和恢复， 数据级灾备是应用级灾备的基础，业务级灾备提供比应用级灾备更高级别的业务恢复能力， 用户需要根据自身的需求选择合适的灾备技术，建设适合自己的灾备系统！