论文部分内容阅读
随着网络技术的快速发展和信息化整合力度的不断加强，企业信息化建设已从单点应用逐步迈向综合化、集成化、协同化，各类业务数据也趋于集中。在此背景下，用户对关键系统不间断稳定运行的要求越来越高。虽然可通过硬件冗余、系统集群等传统技术手段提升本地高可用性，但仍无法抵御地震、水灾等自然灾难以及断电、病毒爆发、网络瘫痪和误操作等人为灾难。灾难性事件一旦发生，不仅将导致应用系统服务中断，甚至危及企业核心数据，造成不可挽回的后果。为有效应对可能的风险，大型企业往往选择开展容灾系统建设，利用资源冗余和地理分散等因素充分确保业务系统和企业数据对灾难性事件的抵御能力。
容灾按距离划分可分为同城容灾与异地容灾。同城容灾可防范除地震之外的常见灾难，双中心距离不超过100公里，通过光纤直连实现数据完全同步。而异地容灾受距离过长及跨省限制，一般没有条件铺设裸光纤，通常租用电信运营商IP线路进行数据传输，每月线路租赁费用与其带宽直接挂钩，缩减带宽能显著降低运维费用。依据国家《信息系统灾难恢复规范》(GB/T 20988-2007) ，参照灾难恢复第五级(实时数据传输及完整设备支持)与第六级(数据零丢失和远程集群支持)要求建设的异地容灾系统必须具备将本地业务数据实时传输至异地备份系统的能力，提高数据复制链路带宽能减少潜在的数据丢失。
因此，在异地容灾系统建设过程中把握好数据复制链路带宽设计平衡就显得尤为重要，既要满足现有需求并适当留有余量，又不盲目扩容，确保投资经济性。
选择恰当
数据复制方式
业务数据的远程实时复制是实现容灾的前提，数据复制将生产端数据变化(包括新增、修改、删除)不断传输至容灾端，从而实现数据实时冗余。确保灾难发生和生产端系统数据被毁坏时，容灾端数据立即可用，且数据丢失量符合设计值。在异地容灾建设过程中，备选的数据复制方案有基于智能存储、基于数据交换设备、基于逻辑磁盘卷、基于数据库的数据复制。不同的技术方案对容灾链路带宽要求存在一定差异。
1. 基于智能存储的数据复制
由存储设备内嵌功能实现数据的远程复制和同步，即生产端存储设备将记录了本地写入操作的日志实时复制到容灾端存储系统并执行，可以保证数据的一致性。目前主流存储厂商都提供了相应的解决方案，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等。
该方式通过智能存储上的处理器实现数据复制和一致性控制，不占用生产端主机资源，对生产系统主机性能无影响；支持所有数据类型的容灾，无论是数据库数据还是文件数据；可以不修改应用直接实现容灾功能，部署实施较简便；实现底层数据的透明传输，生产端的运维操作全部透明地传输到容灾中心，容灾端无需过多干预，系统整体可靠性和可维护性较高，运维成本较低；可以通过在容灾中心存储阵列上划分多个磁盘区域的方法，灵活实现多点、多个不同应用系统的复制或镜像。
该方式不足之处在于最底层的数据透明传输对网络带宽和稳定性的要求非常高；要求两端的存储必须为同一厂家同一档次的产品，在产品选型时有很大限制；对生产端和容灾端存储容量要求较高，需要增加额外存储空间来满足容灾需求；还有就是容灾端数据不能直接读写。
2. 基于数据交换设备的数据复制
利用高端SAN交换机特殊功能，将生产端写入请求分离出来发送给本地专用设备，并由该设备负责记录数据变化日志并将日志发送至容灾端，容灾端部署相应的设备负责接收日志并将数据修改同步到指定的存储系统。基于该方案的产品有EMC Recover Point等。
该方式与基于智能存储的数据复制相比有类似之处，只是将原本由存储负责的远程复制功能转移到了SAN交换机与专用设备之上，从而实现了良好的开放性，支持在异构存储设备之间进行数据复制，便于产品选型；也保留了基于智能存储的数据复制的优点，能够在不占用主机资源的情况下实现高效的数据复制，其部署与运维成本也较低，但对网络带宽的要求仍较高。
3. 基于逻辑磁盘卷的数据复制
通过每台主机上安装独立的卷(LVM)复制软件，同时打开生产卷和容灾端对应的备份卷，并通过网络建立数据传输通道，生产端主机将每个数据块写到生产卷的同时，记录额外的数据修改日志并将其传输到容灾端，容灾端卷管理软件负责接收日志并将其同步至备份卷，从而实现两地业务数据的实时复制。基于该方案的产品有Veritas Volume Replicator等。
该方式通过操作系统逻辑卷管理软件来实现复制，对存储进行逻辑虚拟化，支持异构存储，同时支持所有数据类型的容灾。
该方式不足之处在于对带宽要求较高，容灾端逻辑卷的响应速度必须有高速可靠的网络加以保证；生产端主机承载了额外的数据复制任务，对生产端性能影响较大；要求特殊格式的文件系统；无法对根卷进行容灾。
4. 基于数据库的数据复制
由数据库系统软件本身提供的容灾功能来实现远程复制和同步，生产端数据库将重做日志或归档日志发送至远端，容灾端数据库接收日志后进行前滚操作实现数据同步。相关产品有Oracle DataGuard、IBM DB2 HADR等，第三方软件厂商也提供了GoldenGate、SharePlex等类似的解决方案。在生产端解析日志，通过网络把解析出的SQL语句传输到容灾端回放。
这种方式最大的特点是数据复制链路仅传输重做日志或SQL语句，网络资源占用最小；高版本数据库软件甚至允许在容灾端以只读方式打开数据库，方便了报表统计等商业智能应用，有利于容灾端硬件资源复用，提升投资经济性；对存储容量要求较低且支持异构存储设备；容灾端数据库时刻处于激活状态，容灾切换时间相对较短。不足之处是生产端主机需要启动额外进程捕获、传输重做日志，一定程度上影响了生产端数据库主机性能；只支持数据库容灾，不支持文件系统容灾；容灾系统的实施部署、管理相对程序复杂。
上述四种数据复制方案在容灾应用中具有各自的优势，也存在各自的不足，在实际应用中完全可根据实际需求择优使用。基于数据库的数据复制方案对网络资源占用最小，以Oracle数据库DataGuard容灾方案为例，当一笔业务交易处理完毕时，只需传输该交易涉及的重做日志条目即可确保容灾功能实现。而使用另三种方案都需将重做日志，数据表、索引、归档日志、控制文件、临时表、回滚段中所有与该交易相关的数据修改以块的形式发送至容灾端，网络带宽占用成倍增长。据统计，在不考虑网络加速设备的前提下，基于智能存储、数据交换设备、逻辑磁盘卷的数据复制对带宽要求大致相当，都约为基于数据库的数据复制方案的7倍。
考虑到针对智能存储、光纤交换机、操作系统逻辑卷的写入长期历史统计存在较大技术障碍，而数据库重做日志增量统计手段多样，简单易行。在明确各方案带宽需求换算关系后，可将各类I/O统计需求转化为各业务系统数据库重做日志增量，为准确估算链路带宽奠定基础。
业务现状统计
生产端业务数据修改量统计一直是异地容灾系统设计的难点问题。统计时缺乏有效的技术工具支撑，难以精确的回顾数周前、数月前甚至数年前曾出现的写入峰值及持续时间，往往只能选择粗略估算。依据失真的现状指标建设的异地容灾数据复制链路要么链路带宽过小无法满足传输需求反复出现数据堵塞，要么安全余量预留过多造成资源闲置。
如常用的以表空间增长量代替数据修改量的方法就缺乏科学依据。插入操作可能带来表空间的扩张，也可能因留有空闲的数据块而无需立即分配空间。修改与删除操作一般不会造成表空间增长，但数据变化仍需同步至容灾端。
应将业务现状统计的重点放在调研现有各数据库日志增长情况之上，然后不同数据复制方案之间带宽需求换算关系推导出数周前、数月前甚至数年前生产端写入操作的峰值及持续时间、均值等关键指标。
1.数据变化实时统计
容灾需求调研时往往可借助专业的数据库监控软件获得短时期内单个数据库实时的重做日志增长分布。从实际工作调查可发现，异地容灾系统建设重点关注的业务实时数据修改量通常呈不均匀分布，波峰波谷交替出现。实际工作中，某DB2数据库一周内日志更新高峰值为每分钟450MB，持续时间为数分钟，一般发生在凌晨，其余时间重做日志增长均值为每分钟30MB。
2.数据变化历史统计
依据实时统计得出的结论仅建立在较少的样本之上，是否能够完全反映真实情况，是否在此之前还出现过更大的数据日志增长高峰，要解答这些疑问必须依靠更长的采样周期和更多的采集样本。此时监控工具已无法发挥作用，只能在数据库历史备份中寻找线索。以Oracle为例，RMAN目录的RC_LOG_HISTORY视图就详细记录了每个重做日志的开始时间，可按其切换频率及日志文件大小间接推导出日志增长分布。DB2也提供了类似命令。
3. 多系统叠加统计
准确掌握单个应用数据库日志增长情况特别是数据变化峰值、出现频次(概率)、高峰时段、高峰持续时间可以为容灾链路网络带宽估算提供了基础数据，之后应将生产端所有应用系统后台数据库写负荷叠加起来综合统计。
数据变化高峰作为大量试验样本中的稀有事件，近似满足泊松分布。如生产端应用较少或高峰时段相互错开，可认为各系统同时发生数据修改高峰的机率很小，最终需求为样本最大值；如生产端应用较多，但各系统应用负荷不平衡，某项应用经常出现特大峰值，可将该值作为最终需求；如生产端应用较多、出现时段不固定，且峰值大致相当，应充分考虑数据修改高峰重合的可能，依据概率拟合最终需求。
链路带宽估算
链路带宽估算需要数据支持，一是容灾技术指标，可通过风险分析及业务影响分析科学制定；二是业务数据变化现状，可通过数据库日志增量调研及换算获得。
当RPO设计值较高时(N分钟级)，通信链路必须确保在N分钟内将波峰量数据传输至容灾端的能力，允许的数据堆积量很小，带宽大小取决于波峰时写入负荷。当RPO设计值适中(N小时级)，可充分利用负荷波谷时链路的空闲能力延时传输负荷波峰时来不及发送的数据，达到“削峰填谷”的效果，此时带宽大小可取波峰波谷间的写入负荷的平均值。
异地容灾系统建设是一个复杂的系统工程，技术方案的选择涉及很多因素，数据复制链路带宽设计作为其中的难点和关键环节，需要开展深入调研与合理匡算，不能简单盲目的就高或就低配置。
容灾按距离划分可分为同城容灾与异地容灾。同城容灾可防范除地震之外的常见灾难，双中心距离不超过100公里，通过光纤直连实现数据完全同步。而异地容灾受距离过长及跨省限制，一般没有条件铺设裸光纤，通常租用电信运营商IP线路进行数据传输，每月线路租赁费用与其带宽直接挂钩，缩减带宽能显著降低运维费用。依据国家《信息系统灾难恢复规范》(GB/T 20988-2007) ，参照灾难恢复第五级(实时数据传输及完整设备支持)与第六级(数据零丢失和远程集群支持)要求建设的异地容灾系统必须具备将本地业务数据实时传输至异地备份系统的能力，提高数据复制链路带宽能减少潜在的数据丢失。
因此，在异地容灾系统建设过程中把握好数据复制链路带宽设计平衡就显得尤为重要，既要满足现有需求并适当留有余量，又不盲目扩容，确保投资经济性。
选择恰当
数据复制方式
业务数据的远程实时复制是实现容灾的前提，数据复制将生产端数据变化(包括新增、修改、删除)不断传输至容灾端，从而实现数据实时冗余。确保灾难发生和生产端系统数据被毁坏时，容灾端数据立即可用，且数据丢失量符合设计值。在异地容灾建设过程中，备选的数据复制方案有基于智能存储、基于数据交换设备、基于逻辑磁盘卷、基于数据库的数据复制。不同的技术方案对容灾链路带宽要求存在一定差异。
1. 基于智能存储的数据复制
由存储设备内嵌功能实现数据的远程复制和同步，即生产端存储设备将记录了本地写入操作的日志实时复制到容灾端存储系统并执行，可以保证数据的一致性。目前主流存储厂商都提供了相应的解决方案，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等。
该方式通过智能存储上的处理器实现数据复制和一致性控制，不占用生产端主机资源，对生产系统主机性能无影响；支持所有数据类型的容灾，无论是数据库数据还是文件数据；可以不修改应用直接实现容灾功能，部署实施较简便；实现底层数据的透明传输，生产端的运维操作全部透明地传输到容灾中心，容灾端无需过多干预，系统整体可靠性和可维护性较高，运维成本较低；可以通过在容灾中心存储阵列上划分多个磁盘区域的方法，灵活实现多点、多个不同应用系统的复制或镜像。
该方式不足之处在于最底层的数据透明传输对网络带宽和稳定性的要求非常高；要求两端的存储必须为同一厂家同一档次的产品，在产品选型时有很大限制；对生产端和容灾端存储容量要求较高，需要增加额外存储空间来满足容灾需求；还有就是容灾端数据不能直接读写。
2. 基于数据交换设备的数据复制
利用高端SAN交换机特殊功能，将生产端写入请求分离出来发送给本地专用设备，并由该设备负责记录数据变化日志并将日志发送至容灾端，容灾端部署相应的设备负责接收日志并将数据修改同步到指定的存储系统。基于该方案的产品有EMC Recover Point等。
该方式与基于智能存储的数据复制相比有类似之处，只是将原本由存储负责的远程复制功能转移到了SAN交换机与专用设备之上，从而实现了良好的开放性，支持在异构存储设备之间进行数据复制，便于产品选型；也保留了基于智能存储的数据复制的优点，能够在不占用主机资源的情况下实现高效的数据复制，其部署与运维成本也较低，但对网络带宽的要求仍较高。
3. 基于逻辑磁盘卷的数据复制
通过每台主机上安装独立的卷(LVM)复制软件，同时打开生产卷和容灾端对应的备份卷，并通过网络建立数据传输通道，生产端主机将每个数据块写到生产卷的同时，记录额外的数据修改日志并将其传输到容灾端，容灾端卷管理软件负责接收日志并将其同步至备份卷，从而实现两地业务数据的实时复制。基于该方案的产品有Veritas Volume Replicator等。
该方式通过操作系统逻辑卷管理软件来实现复制，对存储进行逻辑虚拟化，支持异构存储，同时支持所有数据类型的容灾。
该方式不足之处在于对带宽要求较高，容灾端逻辑卷的响应速度必须有高速可靠的网络加以保证；生产端主机承载了额外的数据复制任务，对生产端性能影响较大；要求特殊格式的文件系统；无法对根卷进行容灾。
4. 基于数据库的数据复制
由数据库系统软件本身提供的容灾功能来实现远程复制和同步，生产端数据库将重做日志或归档日志发送至远端，容灾端数据库接收日志后进行前滚操作实现数据同步。相关产品有Oracle DataGuard、IBM DB2 HADR等，第三方软件厂商也提供了GoldenGate、SharePlex等类似的解决方案。在生产端解析日志，通过网络把解析出的SQL语句传输到容灾端回放。
这种方式最大的特点是数据复制链路仅传输重做日志或SQL语句，网络资源占用最小；高版本数据库软件甚至允许在容灾端以只读方式打开数据库，方便了报表统计等商业智能应用，有利于容灾端硬件资源复用，提升投资经济性；对存储容量要求较低且支持异构存储设备；容灾端数据库时刻处于激活状态，容灾切换时间相对较短。不足之处是生产端主机需要启动额外进程捕获、传输重做日志，一定程度上影响了生产端数据库主机性能；只支持数据库容灾，不支持文件系统容灾；容灾系统的实施部署、管理相对程序复杂。
上述四种数据复制方案在容灾应用中具有各自的优势，也存在各自的不足，在实际应用中完全可根据实际需求择优使用。基于数据库的数据复制方案对网络资源占用最小，以Oracle数据库DataGuard容灾方案为例，当一笔业务交易处理完毕时，只需传输该交易涉及的重做日志条目即可确保容灾功能实现。而使用另三种方案都需将重做日志，数据表、索引、归档日志、控制文件、临时表、回滚段中所有与该交易相关的数据修改以块的形式发送至容灾端，网络带宽占用成倍增长。据统计，在不考虑网络加速设备的前提下，基于智能存储、数据交换设备、逻辑磁盘卷的数据复制对带宽要求大致相当，都约为基于数据库的数据复制方案的7倍。
考虑到针对智能存储、光纤交换机、操作系统逻辑卷的写入长期历史统计存在较大技术障碍，而数据库重做日志增量统计手段多样，简单易行。在明确各方案带宽需求换算关系后，可将各类I/O统计需求转化为各业务系统数据库重做日志增量，为准确估算链路带宽奠定基础。
业务现状统计
生产端业务数据修改量统计一直是异地容灾系统设计的难点问题。统计时缺乏有效的技术工具支撑，难以精确的回顾数周前、数月前甚至数年前曾出现的写入峰值及持续时间，往往只能选择粗略估算。依据失真的现状指标建设的异地容灾数据复制链路要么链路带宽过小无法满足传输需求反复出现数据堵塞，要么安全余量预留过多造成资源闲置。
如常用的以表空间增长量代替数据修改量的方法就缺乏科学依据。插入操作可能带来表空间的扩张，也可能因留有空闲的数据块而无需立即分配空间。修改与删除操作一般不会造成表空间增长，但数据变化仍需同步至容灾端。
应将业务现状统计的重点放在调研现有各数据库日志增长情况之上，然后不同数据复制方案之间带宽需求换算关系推导出数周前、数月前甚至数年前生产端写入操作的峰值及持续时间、均值等关键指标。
1.数据变化实时统计
容灾需求调研时往往可借助专业的数据库监控软件获得短时期内单个数据库实时的重做日志增长分布。从实际工作调查可发现，异地容灾系统建设重点关注的业务实时数据修改量通常呈不均匀分布，波峰波谷交替出现。实际工作中，某DB2数据库一周内日志更新高峰值为每分钟450MB，持续时间为数分钟，一般发生在凌晨，其余时间重做日志增长均值为每分钟30MB。
2.数据变化历史统计
依据实时统计得出的结论仅建立在较少的样本之上，是否能够完全反映真实情况，是否在此之前还出现过更大的数据日志增长高峰，要解答这些疑问必须依靠更长的采样周期和更多的采集样本。此时监控工具已无法发挥作用，只能在数据库历史备份中寻找线索。以Oracle为例，RMAN目录的RC_LOG_HISTORY视图就详细记录了每个重做日志的开始时间，可按其切换频率及日志文件大小间接推导出日志增长分布。DB2也提供了类似命令。
3. 多系统叠加统计
准确掌握单个应用数据库日志增长情况特别是数据变化峰值、出现频次(概率)、高峰时段、高峰持续时间可以为容灾链路网络带宽估算提供了基础数据，之后应将生产端所有应用系统后台数据库写负荷叠加起来综合统计。
数据变化高峰作为大量试验样本中的稀有事件，近似满足泊松分布。如生产端应用较少或高峰时段相互错开，可认为各系统同时发生数据修改高峰的机率很小，最终需求为样本最大值；如生产端应用较多，但各系统应用负荷不平衡，某项应用经常出现特大峰值，可将该值作为最终需求；如生产端应用较多、出现时段不固定，且峰值大致相当，应充分考虑数据修改高峰重合的可能，依据概率拟合最终需求。
链路带宽估算
链路带宽估算需要数据支持，一是容灾技术指标，可通过风险分析及业务影响分析科学制定；二是业务数据变化现状，可通过数据库日志增量调研及换算获得。
当RPO设计值较高时(N分钟级)，通信链路必须确保在N分钟内将波峰量数据传输至容灾端的能力，允许的数据堆积量很小，带宽大小取决于波峰时写入负荷。当RPO设计值适中(N小时级)，可充分利用负荷波谷时链路的空闲能力延时传输负荷波峰时来不及发送的数据，达到“削峰填谷”的效果，此时带宽大小可取波峰波谷间的写入负荷的平均值。
异地容灾系统建设是一个复杂的系统工程，技术方案的选择涉及很多因素，数据复制链路带宽设计作为其中的难点和关键环节，需要开展深入调研与合理匡算，不能简单盲目的就高或就低配置。