小型业务系统和standby备份

Standby技术在小型业务系统上的应用
商彦明
摘要：以往，大家一提到数据备份，就想到磁带机，一提到高可用性解决方案，就想到cluster。其实近几年，数据安全受到了大家越来越多的重视，新的冗灾及高可用性解决方案层出不穷，本文就详细介绍了oracle提供的一个解决方案：standby技术。文中先比较了数据安全方面几种主流的备份冗灾及高可用性策略，之后着重阐述了oracle standby技术的特点以及其在小业务系统中的应用前景，最后归结了standby备份的几种IT架构模型。

关键词：冗灾 ，standby备份

正文
随着数据业务的发展，许多业务系统已经不再满足于数据不丢失这一基本要求上，更多的是希望当灾难发生后系统能尽快地恢复工作。Standby技术就是oracle 提供的一套数据库级高可用性解决方案，相对于其他系统级、存储级的高可用性解决方案来说，硬件投资少，但是恢复起来快速方便。对于一些小型业务系统来说，硬件费用往往不多，没有过多的资金用于系统冗灾和高可用性上，这时，standby技术是一个不错的解决方案。
几种常见冗灾、高可用性方案的比较
传统意义上的备份手段是磁带备份，近两年来，随着sata硬盘的出现，硬盘性价比有所提升，基于磁盘备份的虚拟带库概念也开始流行起来。此外，数据库备份方面，逻辑备份使用的也非常多，比如oracle 的exp工具。高可用性方面，使用最为广泛的就是系统级cluster技术，数据库级别上有standby和rac，高端的还包括存储级的复制。
各种方案都有自己的长处和限制，在这里把这些流行的冗灾、高可用性方案作一个简单的比较。
磁带备份。适用于各种备份场所，文件备份、裸设备备份、数据库备份都适用。结合各种成熟的备份软件，可以实现增量备份以及数据的零损失，使用范围广。但受限于磁带的速度，备份、恢复速度慢，当灾难发生时，恢复系统需要几小时甚至几天。硬件投资方面，需要购置一台磁带机，成本在10万朝上，不过在实际使用时，往往是多个系统共用1台大磁带机，因此冗灾成本并不算太高。总的来说，磁带备份是一个性价比高的备份手段，但不是好的高可用性解决手段。
虚拟带库。顾名思义，用磁盘来模仿磁带工作，其功能和磁带机近似，却弥补了磁带速度慢的缺陷，备份、恢复速度比磁带机快上几倍。尽管如此，当灾难发生后，恢复数据仍然需要几十分钟到几小时不等。硬件投资方面，由于硬盘比磁带仍然贵上许多，虚拟带库比磁带机要贵上几倍。总体来说，虚拟带库是一个中高端的备份设备，适合用于对数据安全和备份速度要求都很高，但是不一定要即时恢复的系统。
数据库逻辑备份。只是针对数据库中逻辑对象的备份，可以是数据和程序。逻辑备份操作灵活，实施方便，硬件投资方面没有过多的要求，只要有足够大的硬盘都可以实行。但是由于它只是备份了数据库某个时刻的镜像，因此它不能保证数据零损失。此外，通过逻辑备份恢复系统也不是一个省时间的方法。因此，综合来说，逻辑备份适合用于开发环境、测试环境以及系统有明显闲置期而且对恢复时间要求不高的系统上。
系统级cluster。最常见的双机系统级高可用性解决方案，通过监控应用进程来判断应用是否正常，当灾难发生后可实现快速自动切换或手工切换，恢复时间以分钟计甚至更短。Cluster是对应用的冗灾，但是不能防止存储的物理损坏，因此通常情况下还需要结合磁带备份来保障数据安全。实施cluster的基础费用相对较高，cluster软件费用之外，需要两台配置基本相当的服务器，另外必须共用的独立存储。
数据库standby备份。数据库级的双机冗灾方案，备用库实时和主用库同步以保证数据安全，主用库故障后，备用库可以接替主库提供数据库服务，恢复时间分钟计甚至更短。硬件投入上，实施standby需要有两台配置相当的服务器，并不要求有独立的存储设备。
RAC(real application cluster)。目前为止唯一的数据库不间断高可用性方案。双实例（服务器）或者多实例（服务器）共用一个数据库，任一实例（服务器）故障都不会导致数据库应用中断。当然，RAC也只是对数据库应用的保护，一般会结合standby备份或者磁带备份来保障数据安全。RAC的硬件要求也比较高，多台服务器，共用的独立存储设备都是必须的。
存储级复制。中高端存储设备可实现存储间复制，通过block级别的复制实现数据同步，主用存储故障后，可以使用备用存储来接替工作。由于同步可以是实时的，所以恢复速度非常快。不过这种方案的硬件价格非常昂贵，中高端的存储两台，配套的还要给每个存储配置服务器，另外网络要求也异常高，多是光纤连接，一套方案做下来，硬件费用动辄数十万上百万不稀奇。
小型业务系统和standby备份
多数小型业务系统的特点如下：
并发进程不多，但逻辑处理相对复杂。
业务系统数据量不大，但数据重要，多数系统不允许数据丢失。
多数系统有明显的忙闲时段分布，比如白天忙，晚上空，在忙时希望业务不间断运行，当故障出现时希望能尽快恢复应用。
硬件费用不多，一般不会为冗灾单独投资。
资金的不充裕限制了冗灾方面不可能选用一些昂贵的方案，与之相反的是冗灾要求却不低，数据零丢失，还要在故障发生后尽快恢复应用。所以可选的冗灾策略并不多，对于冗灾重点为数据库应用的小业务系统，standby备份是一个不错的选择。
Standby备份的优点：
可实现数据零丢失。
同步速度快，对系统造成的压力小。每次同步的只是一段时间内数据库的增量变化。
故障发生后，恢复应用速度快，故障后业务停顿时间可控制在半小时以内。
实施硬件要求低，可在无独立存储的IT环境中实施。
实施所需的软硬件费用相对便宜，一台配置相当的服务器做standby数据库服务器即可。
Standby备份的限制和缺陷：
Standby备份只是针对数据库的安全备份策略，并不能对其他诸如文件、操作系统进行防护。
作为物理备份的形式之一，standby备份能有效防止物理损坏，但不防止用户误操作。可以结合逻辑备份对用户错误进行防护。
Standby服务器要和主用数据库服务器操作系统及版本相同，数据库版本也要相同。
Standby数据库要独占一台备用数据库服务器，相对来说比较浪费。
由此可见，standby备份方案可以做到比磁带备份恢复速度快，可以比cluster更省钱，需求的硬件条件更低，做为一个冗灾和高可用性的解决方案，其综合性能还是很好的。
实施standby备份的障碍主要就是寻找一台备用服务器做standby数据库，这对于许多小业务系统来说仍然是个难题。
Standby备份IT架构模型
独立模式。
对于资金富余的小业务系统，可以采用最为常规的standby备份IT架构模型。即单独购置一台数据库服务器作为standby服务器。这样做的好处是，各服务器功能明确，各功能模块之间不会存在抢占资源的情况，缺点是需要单独投资一台数据库服务器的硬件开销。

合用模式
对于没足够资金单独购置standby服务器、但是有独立应用服务器的小业务系统，可以考虑将standby数据库建在应用服务器上。这样可以利用现成设备完成对数据库的standby备份，但是由于standby数据库势必要和app server共抢系统资源，因此不适合用于app server自身压力非常重的业务系统。

集中模式。
独立模式下，备份服务器是一种资源的浪费，而合用模式又会影响业务系统的性能。因此，可以考虑将standby备份集中起来，用专用的standby服务器和专用standby存储，将几个系统的standby备份集中起来。这样既降低了单个业务系统的备份成本，也不会影响各业务系统的性能，同时，集中化的standby模式运维起来更加方便。

集中模式下standby 服务器的要求：
操作系统及版本和各小业务系统的操作系统及版本一致。
由于要承担多个业务系统的standby备份工作，因此配置要比主用库的配置稍好一些，特别是内存要大些。
存储设备的容量要足够大，如果各业务系统的数据量都不大的话，也可以考虑用大些的服务器本地硬盘，不过这样扩展性不强。
例：有三个业务系统，主数据库配置为sun v480 2cpu 4g内存 ，则合用standby服务器可以选用高配的4cpu 、8G 内存的sun v480或sun v490。
理论上说，一台合用standby备份服务器足够支撑4-6个压力不大的小业务系统。将该架构的硬件费用平摊到每个业务系统上，每个业务系统的备份成本并不高。

集中模式的升级。
今后如果又有新的业务系统需要实施standby备份，而现有standby备份服务器已经满负载的话，可以再购置新的standby服务器以满足需要，而standby存储仍可合用。

Standby存储设备扩容方面，优先扩硬盘，其次再考虑添加新存储设备。
　发表时间：2006-04-29