关于数据级灾备与应用级灾备之间的区别和联系

关于数据级灾备与应用级灾备之间的区别和联系灾备的应用对于企业来说是一项重要的技术应用，对于企业数据安全起到了很大的作用。谈到灾备这个话题，很多CIO就会把异地应用级灾备放在首位，还特别强调建设一个数据零丢失、应用自动切换的最高级别的异地灾备系统。这其实是一个认识上的误区。灾备的重要性是毋容置疑的，但这并不是说灾备就一定要建应用级，从实际需求出发，“选择适合自己的”才最重要。按照行业通俗的说法，灾难备份从保障的程度上一般分为三个级别：数据级、应用级和业务级。其中数据级、应用级都是在IT系统的范畴之内而言，业务级则考虑到IT系统之外的业务因素，包括备用办公场所、办公人员等。数据级灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。较低等级的数据级灾备可通过备份的数据人工方式保存到异地实现，比如将备份的磁带定时运送到异地保存就是方法之一。而较高级的数据灾备方案则依靠基于网络的数据复制工具，实现生产中心和灾备中心之间的异步/同步的数据传输，比如采用基于磁盘阵列的数据复制功能。应用级灾备是在数据级灾备的基础上，把应用处理能力再复制一份，也就是在异地灾备中心再构建一套支撑系统。支撑系统包括数据备份系统、备用数据处理系统、备用网络系统等部分。应用级灾备能提供应用接管能力，即在生产中心发生故障的情况下，能够在灾备中心接管应用，从而尽量减少系统停机时间，提高业务连续性。灾备建设中，如何选择数据级，还是应用级呢？我们可以从灾备的目标、投入产出比等多个角度进行分析。异地灾备应对的是小概率事件，需考虑投入产出比灾难的范畴很广，可能导致数据遭到破坏的计划外事件都属于灾难的范畴，其中包括自然灾害、业务运行所依赖的服务的中断、IT系统故障、人员错误操作、恶意攻击以及恐怖袭击等。下图是业界权威机构对灾难的分类：从图上可以看到，无论是面对占据灾难比重44%的硬件故障，还是占据49%比重的软件、人为、病毒故障，需要的都不是远程的灾备保护，需要的只是本地的数据保护;而剩下的7%的自然灾难和社会灾难，才真正需要异地远程灾备。也就是说，通过双机热备、本地备份、CDP这些在线/近线的数据保护手段，就能解决93%的系统故障;而远程异地灾备，不论是数据级还是应用级，应对的都只是7%的小概率事件。既然远程灾备的目标是应对小概率事件(同城灾备是高效率的小概率事件，异地应用级是低效率的极小概率事件)，那么，灾备的投入产出比就非常重要。一般而言，应用级灾备的投入会是数据级灾备投入的2-3倍，甚至更高，而且每一次从生产中心切换到异地灾备中心都需要耗费的大量人力、物力和时间，而回切的过程也同样复杂而耗费精力巨大。因此，相对于应用级灾备而言，数据级灾备的投入产出比更高。与其建设昂贵的异地应用级灾备，不如做好本地的数据中心保护，再配合远程的数据级灾备。因此，在现实环境中，我们更常见的是“本地CDP+远程数据级灾备”这种数据保护模式。灾备建设需要考虑循序渐进，分级建设灾备建设的投入很大，不能一蹴而就一步到位，需要的是一个循序渐进的过程。数据级灾备和应用级灾备并不冲突，数据级灾备是应用级灾备的基础，异地灾备可以先做数据级的。很多的用户在建设灾备系统时，往往就先做数据级灾备，后续再扩展成应用级灾备。这么做的原因是多方面的。原因一，与异地应用级的灾备相比，异地数据级灾备的投入比较小，却可以在极端情况发生时起到作用。在出现大地震等大面积的自然灾害的情况下，用户其实可以接受一个相对比较长的业务恢复时间，外界也会有一个比较大的容忍度。有了异地数据备份后，就可以用几天甚至更长的时间来恢复业务，而不至于彻底瘫痪。原因二，灾难备份建设不是一个简单的技术方案，而是一项系统工程，灾备中心的基础建设、IT系统需要一个逐步建设的过程，运行维护团队、技术支持力量需要长期培养锻炼才能具备理想的应急能力。因此，先做数据级灾备，积累建设经验，培养灾备队伍，具备相当的能力之后，再建设应用级灾备系统就会容易很多。此外，在从数据级灾备向应用级灾备过渡的过程中，还要根据业务系统按需划分灾备等级，不能一刀切。即使在同一个单位或者部门内，也存在多个应用系统。这些信息系统的重要性、复杂度都各不相同，对应的灾备等级也不相同。因此，我们需要根据业务系统的实际需求来逐个确定灾备等级。一般而言，“2/8原则”是比较常见的，也就是20%的应用是关键和核心的，需要应用级灾备，而80%的应用是非关键的，需要的只是数据级灾备。在实际的异地灾备中心建设中，这种应用级和数据级混合的建设模式是最典型的。在应用级灾备的建设过程中，还存在一些常见的误区，它们是：(1)应用级灾备就是业务自动切换(2)应用级灾备就是数据零丢失(3)应用级灾备就是通过应用层(服务器或者应用软件)来做灾备就第一个误区而言，这其实是一种追求技术的理想主义，并不适用实际环境。灾备中心的业务接管是一个管理和决策的过程，绝不是某一项具体的技术。技术不能替代管理，技术也不能替代决策，这早已成为了业界的共识。完善的灾备预案、适时的灾备演练、专业的技术支持队伍才是保障应用级灾备发挥作用的关键。灾备切换是一系列操作的组合，不是单一的技术动作不管生产中心还是灾备中心，彼此的业务之间都有逻辑的联系，服务的启动顺序也有严格的要求。比如数据库必须先启动，之后才能启动应用程序;应用服务器接管完成，才能进行网络的切换。如果应用程序先于数据库启动，结果肯定会是出错。在实际的灾备切换时，我们看到，操作员都会有一本完整的切换操作手册，上面说明了软件、硬件、服务的启动顺序，每一步的操作内容和预期的目标等等。只有严格按照流程操作，才能确保灾备的顺利切换。因此，灾备切换是一系列技术操作的过程组合，不是单一的技术动作。灾备切换是一个决策的过程，不能依靠单一的技术实现灾难的类型多种多样，不是每一种灾难都需要启用灾备中心。而每一次灾备中心的启用，都需要耗费大量的人力和物力。因此，在发生灾难时，首要的是快速判断灾难的类型、可恢复性和后果等内容，然后根据灾备预案来决定是否启用灾备中心。比如，通过本地备份只需要半小时就能在本地恢复业务，就完全不需要启用灾备中心。此外，应用级灾备的对象往往是关键的业务，越关键的业务，切换就越需要慎重，这不是单一的个人意愿，往往需要的是集体的决策。因此，灾备切换更是一个决策过程，而不是单一的技术实现。在实际案例中，99%以上的用户都不会选择自动切换。说到第二个误区“应用级灾备就是数据零丢失”，很多CIO都认为难以理解。应用级灾备当然要求数据零丢失，这一点通过磁盘阵列的同步镜像软件就能实现，技术上根本没有难度，为什么说这是误区呢？让我们从技术上做一些分析。镜像并不能保证数据的完全同步磁盘阵列具备同步镜像功能，能够实现主备磁盘阵列的完全数据同步。但是，磁盘阵列的数据同步并不意味着应用的数据也是同步的。为了提高性能，服务器一般都采用了写缓存，写缓存的数据并没有实时的真正写入到磁盘阵列上，因此，磁盘阵列上的数据和应用的数据是存在差异的。如果生产中心发生了故障，即使磁盘阵列的数据是同步的，也无法保障应用服务器的缓存数据也同步传输到了灾备中心。镜像会降低生产中心的性能镜像的实现机制是一个写IO要同时得到主备磁盘阵列的响应后，才能返回写OK。也就是说，对数据的一个写操作，需要主备磁盘阵列的二次写操作确认和主备站点的来回传输，时延会是普通写操作的3-5倍，甚至更高。因此，采用数据镜像后，会给生产中心带来比较明显的性能影响。此外，如果链路不稳定，出现闪断、抖动等情况，就会进一步加大生产中心的影响。从上述的分析可以看出，镜像方式并不像想象的那么完美。那么什么机制才是比较有效的呢？一些厂家采用的准实时复制技术就是一种答案，比如H3C的自适应复制技术。如果采用这种技术，IO写入主磁盘阵列就返回OK，然后复制模块再将这个写IO采用异步复制的方式传输到灾备阵列。这种方式不会降低主磁盘阵列的性能，还能做到准实时的数据同步。如果再把自适应复制技术和快照技术相配合，还能保证灾备中心的数据一致性，从而实现灾备中心的数据丢失量最少，数据肯定可用。第三个误区也是我们经常碰到的，主要是把数据同步和应用接管两个概念混在了一起。应用级灾备包括两个方面：数据同步和应用接管，其中数据同步是应用接管的基础，但数据同步和应用接管是两种不同的技术。数据同步的技术多种多样，即可以基于存储阵列的复制软件实现，比如EMCMirrorView、H3CReplication等，也可以基于服务器或者应用软件实现，比如VeritasVVR、OracleDataGuard等。但不管采用何种技术，都只是在不同的层面实现了数据的同步，要具备应用接管，还需要其他组件的配合，比如DNS域名切换解析、备用网络启用、应用服务切换等等。在现实环境中，我们最常见的应用级灾备方案是“磁盘阵列的数据复制+备用服务器”，也就是通过磁盘阵列来实现数据同步，通过备用服务器提供业务接管能力。数据级容灾和系统级容灾都是在IT范畴之内，然而对于正常业务而言，仅IT系统的保障还是不够的。有些用户需要构建最高级别的业务级别容灾。业务级容灾的包括很多非IT系统，比如电话、办公地点等。当一场大的灾难发生时，用户原有的办公场所都会受到破坏，用户除了需要原有的数据、原有的应用系统，更需要工作人员在一个备份的工作场所能够正常地开展业务。实际上，业务级容灾还关注业务接入网络的备份，不仅考虑支撑系统的服务提供能力，还考虑服务使用者的接入能力、甚至备份的工作人员。简单来说，灾难备份的等级可以用三个嵌套的同心圆表示，从数据级灾备、应用级灾备到业务级灾备，业务恢复等级逐步提高，而需要的投资费用也相应增长。由于灾备所承担的是用户最关键的核心业务，其重要作用勿庸置疑。灾备涉及到众多技术以及众多厂商的各类解决方案，其复杂性也不言而喻。因此，在灾备建设中，不论是数据级灾备还是应用级灾备，“选择适合自己的”是构建灾备系统的一条基本准则。用户需要根据自身的实际需求量身打造，而在实际建设中，许多用户的灾备站点也都是经过长期积累、多次改造后形成的。