容灾方案.doc

广东电信结算系统容灾方案维尔软件有限公司广州办事处创建日期：2006年2月21日最后修改：2006年2月23日版 本：1.0 广东电信结算系统容灾方案目 录一、项目综述11.1项目概述11.2 项目整体建设思想1二、系统容灾方案32.1容灾系统的整体思想32.1.1广东电信容灾系统实现功能目标52.1.2广东电信容灾实施服务内容62.1.3恢复演习日常工作中不可缺少的准备92.1.4广东电信容灾方案实施阶段与步骤92.2容灾系统的影响因素及数据量的估算132.3数据复制技术的选择142.3.1. 同城容灾142.3.1.1 同城容灾方案 Volume Manager镜像142.3.1.2 Volume Manager说明152.3.1.2 Volume Manager镜像的性能192.3.2 远程容灾202.3.2.1 采用同步复制方式的分析212.3.2.2 采用异步复制方式的分析222.4系统容灾方案的设计262.4.1 容灾软件262.4.2 网络系统272.4.2.1用于数据传输的TCP/IP网络282.4.2.2基于数据远程同步的SAN网络282.4.3 数据库容灾方式设计312.4.3.1 全数据库复制312.4.3.2 只复制log312.5系统切换描述332.5.1东山口机房生产中心单服务器发生故障时的系统切换342.5.2东山口机房生产中心磁盘发生故障时的处理342.5.3灾难发生时的异地系统切换352.5.4接管后的数据从深圳向广州同步问题362.5.5 应用切回过程362.5.6 系统维护时的系统切换372.5.7 RTO和RPO的分析382.5.7.1 计划内停机382.5.7.1 计划外停机392.6网络切换描述422.6.1网络切换的原则422.6.2网络切换方案422.6.2.1 DNS方式422.6.2.2 IP方式452.6.3具体切换的步骤452.6.4切换时间分析462.7应急方案制定462.7.1应急方案简介462.7.2为什么要制定应急方案462.7.3应急和灾难恢复计划的区别472.7.4如何制定应急方案47三、采用VERITAS 容灾方案的几点补充讨论513.1 本地Cluster、同城Cluster及广域Cluster513.1.1 本地Cluster523.1.2 同城Cluster543.1.3 广域Cluster553.2 容灾数据的使用553.3 容灾数据的一致性573.4 系统升级583.5 VxVM及VVR复制对系统的性能影响59四、复制技术实现讨论614.1 同步数据容灾614.1.1基于主机逻辑卷的同步数据复制方式614.1.2基于磁盘系统的同步数据复制功能634.1.3基于主机逻辑卷磁盘镜像功能的异地磁盘镜像方式644.1.4同步数据容灾的性能分析664.2 异步数据容灾69VERITAS Software Corporation. ii 中国银联新系统容灾方案一、项目综述1.1项目概述“数据源是一切关键性业务系统的生命源泉”，随着美国911事件的发生已经使越来越多的企业管理者认识到了数据信息对自己的企业生存的影响能力，对广东电信而言，同样存在上述问题：随着企业的逐步发展，行业竞争的不断加剧，用户数量的不断增多，新业务需求的不断扩展，现有广东电信业务系统的相关数据信息的安全性和可靠性也需要在原有基础上得到进一步扩充及改进，以保证在灾难情况发生时，相关业务也能正常运行。在目前的广东电信业务系统中，系统的安全性主要是通过下面一些措施或方式来得到保证：主机通过采用双机容错方式保证系统工作的可靠性和可用性；存储设备通过冗余的RAID技术保证数据的可靠性；本地的数据脱机备份技术，从而增加一份数据副本；以及相应的网络安全技术（如防火墙技术等）。但综合上述内容，以上的系统安全方式并不能保证系统在灾难情况发生时，系统的可靠性和可用性。因此，在本期系统中，我们将总体目标定为实现对广东电信现有业务系统中核心数据和核心应用结算系统的容灾备份，并确保灾难情况下业务数据的可恢复性和可用性，从而保证结算系统能够得到及时恢复。1.2 项目整体建设思想整个系统应按以下目标进行建设：1. 灾难恢复。当生产系统发生灾难事件时，能在短时间内由容灾中心接管生产中心的业务。2.可进行两级容灾（在广州本地建立同城同步容灾，在深圳建立远程异步容灾）。当数据中心系统出现故障时，本地容灾中心保证数据不丢失，继续向深圳容灾中心复制；复制结束后，由深圳的远程容灾中心接管所有广州的业务。二、系统容灾方案 随着信息使用环境的日渐普及，人类对于计算机系统的依赖也日益加重。俗语说天有不测风云，人有旦夕祸福，计算机系统很有可能因为天灾或人为因素等意外事故导致系统毁坏而长期无法运行，造成整个组织或企业在营运上的重大损失以至倒闭的风险。随着网络互联方式日趋复杂，各电信运营商在网络互联及其技术实现上相互依存，使得综合结算系统变得更加复杂。各运营商之间的话务量越来越大，网间话费结算系统在电信经营服务中的地位也越来越重要。结算数据的准确性和实时性，直接关系到与其他运营商的互联互通效果，关系到整个公司的收入。在服务与竞争的两大主题下，理顺与各运营商之间的结算关系，正确合理地进行企业间的费用结算，加速电信业务费用的回收是企业进行良好运营的一大重要标志。因此，针对广东电信综合结算系统这样的多业务集成在一体的业务系统，由于本系统的实时性强、影响大，其系统运行环境的好坏，运行的是否稳定、可靠、安全，对于广东电信的如此大的用户是致关重要的，他将直接影响到广大人民群众的日常生活。一旦出现无法避免的灾难而导致系统长时间不能运行，将给广东电信业务带来极大损失，并对广大电信用户带来极大影响。因此高可靠的系统运行对电信来说极其重要的。在本方案中提出了可靠性较为完善的灾难恢复方案，以有效保障系统及业务遭受重大灾难后的持续运营。2.1容灾系统的整体思想广东电信是中国电信的形象门户，其业务系统的安全性直接关系到中国电信和用户的切身利益，也关系到广东电信的形象。所以尽可能地保证系统的绝对安全是必须予以考虑的。为了防范地震、火灾、水灾等自然灾害、电力中断、以及人为破坏而导致系统遭到严重损坏、失效的异常情况，我们也提出了对现有系统进行容灾备份的需求。上面提到的灾害现实发生的概率毕竟非常小，所以一律对现有系统进行简单复制的容灾方案也是不可取的。在具体研究、选择容灾方案时，不仅要在资金投入和具体容灾功能之间进行平衡，而且还应充分考量相关方面的利益（实质上最终都应是保障电信自身的利益），包括用户的所有权益、电信运营商的所有权益、客户使用业务的权利、客户享受相关服务的权利等。本期工程的总体目标是实现对现有结算业务系统中核心数据和核心应用系统的容灾备份，并确保灾难情况下业务数据的可恢复性和可用性，从而进行相关应用系统的及时恢复。容灾系统的建设还包括相关条件的具备、以及管理维护机构设置和人员组织、管理维护制度和操作规程的制定等。根据上述描述，在建设广东电信结算系统的容灾系统时，需按如下原则进行规划和建设：一、在日常系统正常进行生产的时候：（1）确保日常的的关键性数据的安全的备份和存储（包括日志和数据）；（2）确保灾难发生后数据库和应用系统的及时恢复，包括数据在线存储的恢复；在进行数据容灾的同时，也建立数据离线备份系统（3）做好计划内切换（如系统升级和管理）和计划外切换的计划和实施方案。（4）坚持容灾备份容灾系统建设投资经济合理性的原则；（5）确保系统的可扩充性、可维护性、可操作性；（6）建立健全相应严密的管理制度和操作流程。（7）恢复演习。二、在灾难发生的时候：1.可进行两级容灾（在广州本地建立同城同步容灾，在深圳建立远程异步容灾）。当电信中心系统出现故障时，本地容灾中心保证数据不丢失，继续向深圳容灾中心复制；复制结束后由，由深圳的远程容灾中心接管所有广州的业务。2.在进行数据容灾的同时，也建立数据离线备份系统。（1） 灾难恢复。当生产系统发生灾难事件时，能在短时间内由容灾中心接管生产中心的业务。确保灾难发生后主要业务运行的及时恢复，包括数据在线存储的恢复；（2）进行两级容灾（在广州本地建立同城同步容灾，在深圳建立远程异步容灾）。当电信中心系统出现故障时，本地容灾中心保证数据不丢失，继续向深圳容灾中心复制；复制结束后由，由深圳的远程容灾中心接管所有广州的业务。（3）将整个电信因灾害而导致的利益损失降低到最小程度；（4）尽量确保客户利益不受损失；（5）做好系统切换的实施方案以及出现异常情况的应急方案。另外在建设容灾系统时必须考虑以下问题：1 容灾系统应具有开放性不依赖特定硬件系统；2 应支持广泛的传输介质支持TCP/IP 网络更佳；3 考虑到容灾能力和对应用系统性能的影响容灾方案不仅要支持近距的同步的数据容灾还必须能支持远程的异步的数据容灾；4 对于异步数据容灾数据复制不仅仅要求在异地有一份数据拷贝同时必须保证异地数据的完整性可用性；5 容灾系统本身应具备各种容错考虑；6 应支持灵活多样的容灾结构；7 完善容灾系统应考虑实用的灾难恢复手段。2.1.1广东电信容灾系统实现功能目标对于广东电信而言，目前的数据容灾系统是整个业务系统中的核心业务，如何保证该系统的最大可靠性和可用性，将是本期容灾系统主要解决的问题，因此我们可以将本期系统的建设目标定为：建立数据容灾备份系统，以保障灾难情况下最大程度地保护所有核心系统数据的安全，同时尽量保证客户的利益不受损失。能及时恢复所有外界与系统主机的连接并正常运作；另外在平时为了保证对容灾中心的所有设备进行充分利用，在规划本期容灾系统时，必须考虑容灾中心具备承担部分业务工作的能力，如作为新应用系统的测试平台，在主生产系统进行例行维护时临时接管业务等。另外，结合广东电信现有的系统结构，我们也将在本期系统中实现以下目标：1灾难恢复。当生产系统发生灾难事件时，能在短时间内由容灾中心接管生产中心的业务。2可进行两级容灾（在广州本地建立同城同步容灾，在深圳建立远程异步容灾）。当电信中心系统出现故障时，本地容灾中心保证数据不丢失，继续向深圳容灾中心复制；复制结束后由，由深圳的远程容灾中心接管所有广州的业务。3对现有系统中的不同业务系统对应的存储孤岛，统一整合网络存储资源，构架出一个存储网络平台，使广东电信真正将存储网络的概念引入到实际的系统体系中,使每个主机都有可能去访问每一个磁盘柜的空间，使应用系统能够很灵活地分配资源，并有效地使用存储，减少企业投资成本, 实现企业投资保护。将来当需要增加应用主机时，象连接以太网那样便利；当需要扩充存储时，可以在线地增加磁盘柜或磁盘，并在线地划分、配置物理卷；4采用业界先进的可扩展式企业级交换机作为网络的核心交换，提高存储系统的高可用性， 从而保证了数据信息的高可访问性；5SAN网络化结构, 提供远距离数据的保护能力和快速备份、恢复数据的能力。6集中管理企业整个SAN存储网络和存储资源, 减少管理员的工作负担，减低企业的管理成本和维护成本。7提供系统在线维护的可能性，即便将一个网络停下来在线维护，也不会影响整个系统的正常运行。8建立完善的容灾策略机制和操作流程。2.1.2广东电信容灾实施服务内容基于电信总部本次容灾项目的建设目标，结合广东电信的具体情况，本方案提出下面的项目建设目标：在现有的容灾系统框架下，优化网络；扩充系统容量，对广东电信业务支持系统当中最核心的业务系统提供全面的容灾保护。整合目前的存储网络，构建能够对核心业务系统提供强有力支持的“存储基础架构”。同时部署针对这一架构的管理平台。使得存储基础设施如同网络基础设施一样，十分方便灵活地适应业务需求的变化，同时最大限度地保护用户投资，提高资源利用水平，优化资源配置，提高系统的可靠性和可维护性。最大限度地消除造成业务中断，或系统性能下降的“非故障”因素。除灾难（环境因素）和系统故障（硬件故障）之外，在业务运行期间，系统维护、软件测试、数据备份、报表生成、数据仓库加载等等均会造成业务中断，或业务运行性能降低。本次容灾建设应该能够尽量消除这些因素，进一步提高业务持续能力。在本期系统的容灾方案中，我们为用户提供了由VERITAS的容灾方案由数据复制方案和广域Cluster方案组成，可以为广东电信提供完整的高可靠容灾。该解决方案具有以下优势：同城容灾采用Volume Manager远程镜像技术，提高业务连续性VERITAS Volume Manager是大型系统存储管理的事实行业标准，可大大提高存储系统的性能和可管理性。另外，采用Volume Manager对东山口机房和天河大厦机房的磁盘进行远程镜像，可以实现最为简便和安全的同城容灾。利用这种容灾方法，数据同步镜像到天河大厦机房数据中心。并且，当东山口机房生产中心的磁盘故障时，对业务系统不产生影响。异城容灾采用Volume Replicator复制镜像技术，提高复制性能Volume Replicator与Volume Manager结合，可以只复制改变过的数据块，大大减少了复制数据量，因此提高了复制性能。同时，Volume Replicator对系统CPU的占用也很少，基本小于3。对于容灾技术性能的评估，应从复制技术对应用的影响来计算。经过多次测试，采用VERITAS Volume Replicator的复制速度在同步和异步复制模式下都比磁盘硬件复制方式性能高出许多。可扩充性好，不局限于某一品牌磁盘产品VERITAS的数据复制方案是基于操作系统的复制方案，对磁盘阵没有任何品牌或型号上的特殊要求，也不要求复制的数据全部在共享磁盘阵列上。异城容灾使用标准IP网络，不需要专用硬件设备，大大节约实施成本VERITAS的数据复制技术使用IP网络，对底层的网络设备没有任何特殊要求。对复制数据的定义非常灵活，易于扩充VERITAS的数据复制是以数据逻辑卷为单位的，因些用户可以非常灵活地设定哪些数据进行复制，而不像大多硬件方式进行数据复制的技术，可复制的数据范围在设备出厂时就必需设定好。高可用，灾难事件的自动监控和快速切换VERITAS的容灾技术是一个完整的容灾方案，与VERITAS Cluster Server（VCS）及Global Cluster Manager（GCM）结合，可以对生产系统和容灾中心的异常事件进行监控。当灾难事件发生时，GCM可以自动或提示管理员进行切换。集中管理GCM提供WEB方式对生产中心和容灾中心的系统状况、应用状况、复制状况进行监控和切换管理。管理员可以在WEB管理界面进行单键（one-button）控制的主动切换或灾难接管。复制数据的高可靠性，保证数据一致的异步复制VERITAS的复制技术使用复制日志（Storage Replication Log，SRL），保存了I/O的顺序。异步复制情况下，不能及时复制的数据可以存放在复制日志中。由于保存了I/O顺序，复制到容灾节点的数据一定是按照原有I/O顺序写入的，数据的一致性可以得到保护。方便进行复制数据的检查无论在天河大厦机房容灾中心还是在深圳容灾中心，需要对容灾数据进行检查时，可采用VERITAS的Snapshot技术方便地实现。Snapshot技术将某一时间点的数据复制一份，可用检验、备份等操作。2.1.3恢复演习日常工作中不可缺少的准备无论采取何种方式，数据容灾的最终目的都是在于灾难发生后能够在企业可以接受的时间内快速恢复系统的正常运行。那么企业建立的系统在灾后能不能快速恢复呢？这就需要企业系统在正常运行时能够进行灾难恢复演习。只有这样才能保证容灾系统确实可行。一般来说要按照以下几个步骤进行：首先，制定计划灾难恢复演习不能以停机为代价，更不能够演习之后系统无法正常运行。造成生产量的降低和客户形象的损失，制定灾难恢复计划从预算和时间方面来考虑。电信可以请设备供应商协助制定。VERITAS 为客户提供的容灾解决方案可以轻易自动实施备份中心和主机中心的切换，即使如此，应该定时进行恢复演习看备份中心究竟能否恢复系统二、要明确问题。建立实际的灾难恢复计划时一个非常复杂的过程，所以用户一定要分析清楚什么是最大的风险？系统对那些灾难最为敏感？系统停机时对每个部门的影响是个什么样子？同时要进人员分工：当发生灾难时谁将负责数据恢复？谁负责监控设备？谁负责与设备供应商联系？这些都必须在演习中明且分工并且按照计划执行。三、要定时不定时进行演习。仅仅制定出一个计划是不够的。不论计划多么严密，必须对其进行测试不是一次而是经常测试。电信是否开办了新的业务？是否有新的部门加入到了系统之中？系统恢复小组成员是否变化？这些都是企业在演习中应该考虑的重要因素。2.1.4广东电信容灾方案实施阶段与步骤应用系统容灾方案应该采用方法论的形式帮助客户建立业务连续规划，实现业务连续性。规划的建立和设施包括六个阶段。第一阶段是风险与业务影响分析阶段，包括业务连续风险分析、连续业务影响分析、企业当前IT环境分析。第二阶段是开发流程阶段，包括业务连续恢复流程、业务连续紧急应对流程、业务连续替代流程、业务连续管理流程。第三阶段是业务连续计划阶段，包括业务连续策略开发、容灾备份系统方案设计、业务连续架构设计、业务连续计划制定。第四阶段是实现阶段，包括业务连续实现、容灾备份系统实现。第五阶段是预演阶段，对业务连续计划预演。第六阶段是交接验收，包括业务连续计划评审、业务连续培训与知识转移。 方案实施阶段1：分析与计划目标将广东电信数据等系统的业务目标、需求与其应用和业务环境协调一致；主中心和备份中心场地环境和网络连接准备；评估硬件，软件及应用的兼容性；关键成果经广东电信用户方和集成商共同确认的项目实施计划；经广东电信用户方和集成商共同确认的项目评估验收标准；硬件、软件及应用兼容性的确认；任务描述项目开工会议 / 介绍；实施客户环境评估；完成客户环境评估报告；分析远程节点间的硬件基础设施；分析硬件单点故障；分析软件及应用环境；完成项目实施计划,并和用户讨论确定；方案实施阶段2：配置与集成目标主中心和备份中心存储区域网的构建；主中心和备份数据中心的阵列配置；在主数据中心和异地备份数据中心存储设备之间实现数据复制；配置及检验远程数据复制功能；优化远程数据复制性能；数据系统、ORACLE数据库性能优化；关键成果阵列正确配置完毕；完成单模光纤链路的连通性测试及SAN的构建与配置；完成数据库和应用软件的配置；ORACLE数据库的性能调优报告；相关资料存档；任务描述数据等系统的数据迁移；安装相关主机及存储、容灾系统软件SAN的构建，光纤交换机的安装配置与单模光纤链路测试；实施相关逻辑卷,文件系统及应用数据库的配置；进行远程数据复制性能调优；进行业务系统数据库性能优化；建立配置文档；方案实施阶段3：测试及知识移交目标将异地数据切换过程集成到灾难备份/恢复操作流程中；建立、检验及执行各局点本地故障切换机制；建立、检验及执行异地故障切换机制；规划设计灾难恢复操作流程；对系统配置及操作流程进行归档；灾难预演；实现知识移交；关键成果综合测试及灾难预演测试计划；测试验收报告；知识移交；灾难恢复操作流程；项目文档；任务描述建立、检验及执行各局点本地故障切换机制；建立、检验及执行异地故障切换机制；对系统配置及操作流程进行归档；灾难预演测试；实现知识移交；项目验收；项目正式结束；实施服务总结通过以上专业化的容灾项目实施流程和方法，可以使广东电信数据系统远程容灾方案在对现有业务系统的运行不造成较大影响的前提下，高质量，零风险地实现；并在系统投产后，能够高效，可靠的运转；从而使广东电信的关键业务系统具备防灾，抗灾的能力，为实现24*7*365全天候的业务运行创造条件，为广东电信更大规模的业务发展奠定基础。2.2容灾系统的影响因素及数据量的估算在建立容灾中心时，主要需考虑以下一些关键因素：1）容灾中心与生产中心在距离上要足够远，使得当生产中心遭受灾害破坏时，不会影响到容灾中心2）必须保证容灾中心与生产中心的数据同步及数据的一致性3）容灾中心的所有应用系统必须经过严格的测试，确保业务系统能够正常运行；任何对生产中心应用的改变，都需要对整个容灾系统进行测试4）容灾中心与生产中心间为保持数据同步而需传输的数据量，以及两地间的网络带宽，也即网络带宽必须能够保证两地间数据的顺畅同步5）容灾中心的计算机系统有足够的处理能力来接管业务中心的业务6）生产中心与容灾中心的应用切换快速可靠，并可进行自动和手工切换另外，还需要考虑到投资和成本，尽量利用到原有的硬件设备。假设将电信的数据将分为5个数据库、一个文件共享空间和一个应用数据目录，这些数据是电信结算系统的核心数据，需要进行容灾和备份考虑。数据的两个指标对容灾系统的规划至关重要：一、每个库的空间大小；二、业务产生的峰值写I/O速度。数据库操作时，会由于数据本身、日志、数据库data block大小、改变数据的分布情况等多种因素影响。例如，数据库在写入磁盘时，是以data block为单位完成的，而不是以每笔交易为单位，再加上索引、数据块中的空余空间、数据碎片等因素，计算容量时，保守估计可以以3倍的写入数据量来计算；计算I/O量时，由于写数据的同时需要写日志，可以以6倍的I/O量来计算。这样的计算方法只有一定的参考价值。实际环境的每秒的写I/O量只能通过测试取得，如通过系统命令iostat、sar等其它命令来取得更有意义的数据。复制带宽的选择，与I/O量和关系密切。由于在提交方案时，未得到电信的相关信息的回复，因此无法对所有系统所需要的复制带宽进行估算。其它数据库和文件共享空间的写I/O数据没有得到，因此无法估算所需的复制带宽。建议采用应用实测的方法，对一定负载的每个数据库进行写I/O的测试统计，才可能正确估算出所需的复制带宽。2.3数据复制技术的选择2.3.1. 同城容灾由于电信计划的同城数据保护距离可以比较近，可以采用Volume镜像的方式来进行中距离的数据复制。即在生产中心的主机和本地磁盘阵列及同城容灾中心的磁盘阵列都同过光纤交换机相连，无需进行任何专用的数据复制技术，利用Volume Manager的镜像功能就可以完成同步数据同步。2.3.1.1 同城容灾方案 Volume Manager镜像由逻辑卷实现的磁盘镜像，相信大家已经相当熟悉，在以前，这种磁盘镜像的距离受到SCSI协议的距离限制，磁盘镜像只能在机房内实现。而现在，随着FC光纤通道技术的成熟和普及，我们发现，原有的距离限制已经不存在，完全可以利用操作系统级的Volume Manager软件对本地和远程磁盘进行镜像。连接方式可采用长波黑光纤的方式直接，或加入DWDM设备。电信的同城容灾距离超过10公里，超过黑光纤方式直连的极限，建议采用DWDM方式。短波（850 mm，多模） GBIC使用50u 的光缆，终端设备之间的最大距离为500米。 长波（1300 mm，单模，也称为黑光纤） GBIC使用9u的光缆，终端设备之间的最大距离为10公里，无需扩展器或者转发器。 通过在黑光纤（9u 光缆）上使用DWDM，终端设备之间的最大距离可以延伸到为100公里。 东山口机房存储光纤交换机提供短波GBIC连接主机和磁盘柜，同时使用短波光纤连接DWDM设备；东山口机房DWDM设备与天河大厦机房DWDM终端设备通过单模黑光纤连接（租用电信设备，则无需考虑DWDM设备之间的连接）；天河大厦机房容灾点的光纤交换机通过多模光纤连接DWDM终端，并连接主机和磁盘柜。采用这种方式，生产中心的磁盘阵列与同城容灾中心的磁盘阵列对于两地的主机而言是完全同等的。当生产中心的磁盘阵列故障后，由于同城容灾中心的磁盘是它的镜像，所以操作系统会自动隔离生产中心的磁盘，转而对容灾中心的数据进行访问，对应用不产生任何影响。如果采用数据复制的方式（无论是硬件方式还是软件方式），都需要在生产中心故障时对数据系统进行切换操作，反而造成业务的停顿。从性能上来分析，在操作系统一级进行镜像，数据会在同一时间写入到两地的磁盘，而数据复制技术需要a.先写本地盘b.复制c.远地写完成信号返回，才算写操作完成，并且需要SCSI到复制协议的转换过程，无论在流程上和反应时间上都会比直接镜像造成更多的延时，对应用系统有更大的影响。另外，对需要进行镜像的数据可以灵活设置，不需将所有磁盘进行镜像，而只需镜像需要的逻辑卷（Volume）。2.3.1.2 Volume Manager说明使用逻辑卷管理软件（Volume Manager）不仅仅是以同城容灾镜像为目的，其实逻辑卷管理软件已经非常广泛地被使用，而远程逻辑卷镜像是逻辑卷管理软件了一个功能。广泛使用逻辑卷管理软件的原因，是因为传统的方式管理在线数据系统，存在着许多令人不能十分满意的地方，具体表现在： 可管理性差首先，操作系统没有很好的磁盘空间管理工具，当文件系统或分区的空间不能满足要求时，空间的增大或缩小非常困难；而对于数据库应用，当数据文件建立在裸设备上时，很难动态在线扩大数据文件的大小，虽然我们的技术专家利用自己的努力和才智，在实践中积累了一些较实用的技术手段和技巧，但是，系统本身存在的弱点，使得我们的系统和技术人员始终面对一个复杂的系统环境，无法彻底避免意外的发生（如：意外的数据库空间溢出）；同时，其管理手段也较为复杂，不灵活，数据库的数据文件也不能用一般的文件系统命令进行操作和管理，大大提高了对系统管理员和数据库管理员的要求，不容任何失误。 可用性差传统磁盘分区和文件系统管理的可用性相对较差，主要表现在不能动态在线维护（如：扩充）、修复时间长、不能避免意外溢出错误等方面。比如：1. 假设某个应用系统所分配的空间在运行时不够了，此时应用系统或操作系统将可能会被终止，需要对应用系统所使用的某些磁盘分区或文件系统进行空间缩放。其处理过程包括：1.停止所有应用对该分区或文件系统的访问；2.对上面的数据做备份；3.进行分区的扩展（包括重新分配磁盘分区）和文件系统的格式化；4.将数据恢复到新的分区；5.最后才能重新启动应用。对于大数据库或文件系统而言，中间这个周期可能非常长，因而大大降低了应用系统的可服务性2. 当文件系统遇到错误时，系统会产生崩溃，如果文件系统非正常卸载，则系统重启时，需要对文件系统进行修复，对于大文件系统，这个时间可能非常长，从而影响了可用性。3. 即使在系统初始化设计时，针对相应的应用系统，如数据库系统，做相应的规划设计，尽量避免停应用，也很难完全避免意外的发生。同时，这些方式复杂，系统资源（如磁盘空间）利用率低。 性能差传统的文件系统，使用不连续的数据块分配空间，因而，一个大文件的所分配到的数据块，可能分散在磁盘空间的各个角落，大大增加了磁盘访问的寻道时间；而对于基于文件系统的数据库文件，由于文件系统的缓存和文件锁机制，将使数据库的性能大大降低。 扩展性差由于传统文件系统和磁盘管理工具不能实现在线的空间缩放和文件系统或分区不能跨硬盘的限制，当系统增加新的磁盘设备时，新的硬盘空间很难与原有的空间进行有机的结合。因此，逻辑卷管理软件在电信结算系统中一定是要使用的。而逻辑卷管理软件中最优秀的产品当属VERITAS Volume Manager（VxVM）。IBM服务器本身也有Volume Manager软件，称为LVM。VxVM与LVM相比，存在许多技术上的优势，例如DMP功能、动态识别硬盘功能、online管理功能、快速镜像同步功能等。鉴于VxVM的众多技术优点，IBM在AIX5版本中也开始OEM VERITAS的VxVM技术。VERITAS Volume Manager的主要功能特点如下: 业界的事实标准已被SUN， HP， IBM， SGI，Windows，NCR，Sequent，EMC等系统厂商所OEM，占存储虚拟化管理全球市场的80。 自动识别磁盘位置能力当由于磁盘与主机的连接地址发生变化（在SAN的结构中经常遇到，例如交换机连接的端口位置发生变化），VxVM可以自动识别出其新的设备名与是原有某一磁盘，避免出现原有磁盘找不到的错误。 增强了系统和应用的性能，提高SAN管理能力VERITAS Volume Manager具有多数据通路（DMP）功能，自动识别同一物理存储的多条通路，提供自动负载均衡和确保数据传输的连续能力。数据镜像(mirror)功能将数据镜像到快速存储设备，可以加速对关键信息的访问，确保关键数据的高可用性。DRL(Dirty Region Logging)日志管理保证了系统故障时的快速恢复。VERITAS Volume Manager提供了多种RAID机制，同时通过在线监测和在线RAID调整功能，具有在不中断应用的情况下，识别和消除性能瓶颈的能力。 特有的I/O平衡能力： 例如, 当一个Volume上的数据访问太密集时, 可以将其数据转移到另外的Volume上去。 增强了系统可用性和数据完整性Volume Manager利用冗余技术提高数据可用性, 在磁盘与硬件出现故障时，可以保护数据不致丢失和破坏。VolumeManager支持RAID 0、RAID 1、RAID 1+0、RAID 0+1和RAID-5等先进的软件RAID技术。Volume Manager允许对磁盘进行在线的管理和配置更改，包括从一种RAID的模式到另一种模式，例如, 5个Disk的Raid可以在线改为6个 Disk的Raid5。因此减少了对系统产生极大影响的停机时间。Volume Manager的RAID功能在Volume一级实现，可以跨磁盘阵列实现数据镜像，从而实现中距离的数据容灾。 强大的系统可扩展性突破了OS对分区的限制, 任何一个卷可以从自由硬盘缓冲池里扩充容量。Volume Manager支持多厂家（EMC、Compaq、SUN、HP、IBM等）的多种不同类型（RAID 5，RAID 1、RAID 0、JBOD）的存储设备；卷的大小不受磁盘空间的限制，可以跨多个不同的硬盘，允许在线地扩展，并可将新增的空间与原有的空间进行无缝地结合；Volume Manager所支持的设备数量与空间大小基本上没有限制。 方便美观的图形管理界面Volume Manager提供了一个基于Java的能在任何操作系统上运行的图形用户界面。在使用图形界面管理的同时，Volume Manager提供命令行管理工具，管理灵活。 在线数据管理功能Volume Manager基本上所有的管理都是online的，例如online对RAID结构进行重新定义、online将数据从一个磁盘转移动另一磁盘、online识别和重新分配故障磁盘（Hot-Relocating）、online改变volume及文件系统大小。在进行这些online操作时，其上的数据可以继续被应用访问。 与其它扩展功能的结合Volume Manager提供了许多非常有用的选项功能，例如FlashSnap可以进行快速的镜像同步；也可实现镜像数据拆分，然后挂接到其它服务器上进行数据分析、备份等；Volume Replicator可以将所有写入本地的数据复制到远程的服务器上，实现容灾数据复制。2.3.1.2 Volume Manager镜像的性能采用Volume Manager方式并不会降低应用的性能。相反，镜像方式比复制方式效率更高。东山口机房和天河大厦机房采用同步方式，那么每一个I/O从开始到完成都经由以下几个步骤：本地写 传输到异地写 异地写完成信号返回 本地写完成信号完成因此，同步方式时，写操作需要远端系统写完成信号返回后才算完成，应用的I/O速度，完全取决于写远端磁盘的速度有多快。无论用镜像还是复制，东山口机房和天河大厦机房的物理链路（DWDM）都是需要的，距离也是相同的，所以在DWDM上造成的时延（包括数据传输时间、协议转换时间）也是相同，但镜像方式比复制方式还有以下优点：1. 镜像方式从应用主机将数据传到同城容灾直接使用的是SCSI协议，不需要再进行本地SCSI-复制协议、远端复制协议-SCSI的转换。2. 镜像方式从应用主机传向远端磁盘的是最少的data block数据块，没有overhead，也没有因为一个bitmap标志多个data block而传送未修改的数据块。例如，操作系统以2K作为一个block向磁盘写，但如果复制采用bitmap方式，可能一个bitmap标志32K数据，那么复制时就写了无用的block到远端磁盘。3. 镜像方式不在本地磁盘上记录任何与data本身无关的数据，例如bitmap、timestamp或是log，因此也减小了I/O。系统的CPU在写I/O时，I/O写完成信号没有返回前，CPU的状态是wait I/O, 不是ideal，是不可用的。因此，镜像或复制对应用的性能影响大小，在于写I/O返回的速度，而不在于CPU的使用。根据以上分析，镜像方式比复制有更快的I/O效率，在东山口机房生产中心和天河大厦机房容灾中心之间，利用Volume Manager进行镜像是最有效的手段。2.3.2 远程容灾由于远程容灾考虑从广州到深圳，距离一千公里，无法采用镜像方式，因此只能考虑数据复制的技术来实现。电信的数据变化数据量可估算如下：秒级峰值变化数据量：假如广东电信业务系统的峰值秒级业务量为3000笔/秒，每笔交易2KBytes，则写峰值为每秒6MBbytes业务数据。每秒6MBytes是业务数据本身的变化，在数据库中需定数据和日志，可估算实际数据库的写入量为6MB * 2 = 12MB。数据库操作时，会由于数据本身、日志、数据库data block大小、改变数据的分布情况等多种因素影响。例如，数据库在写入磁盘时，是以data block为单位完成的，而不是以每笔交易为单位，再加上索引、数据块中的空余空间、数据碎片等因素，保守估计可以以3倍的写入数据量来计算，即每秒钟的I/O量为12MB * 3 = 36MB。每天变化数据量：假如应用系统每天（24小时内）的交易量为17,000,000笔（17M笔/天 * 2K/笔 = 34GBytes/天），按照以上的计算方式，每天实际写入数据量为34G*2*3 = 204G。以上数据只有一定的参考价值。实际环境的每秒的写I/O量只能通过测试取得，如通过系统命令iostat、sar等其它命令来取得更有意义的数据。一般来说，复制有两种模式：同步或异步。2.3.2.1 采用同步复制方式的分析东山口机房与天河大厦机房采用镜像方式，不采用复制方式。以广州与深圳采用复制方式，但不适合采用同步方式。因为要采用同步方式，至少网络带宽要大于本地写I/O的峰值。如果网络带宽小于本地峰值写I/O，则对本地影响I/O性能将有极大影响。因此，要实现同步复制，转接数据库（根据前面分析，转接数据库的秒级写I/O为36MB/秒）至少需要以下复制带宽：36MBytes/秒 * 8bits/byte / 60% = 480Mbits/秒（60%为TCP/IP的overhead）但是，并非采用了超过了480M带宽的复制网络就可以对转接数据库进行同步复制。同步方式时，写操作需要远端系统写完成信号返回后才算完成，因此会影响生产中心的性能。影响的程度与峰值写操作的多少、本地写操作的速度、远地写操作的速度、复制链路的带宽、复制距离都有关系。例如，本地写峰值为36MBytes/秒，即不进行复制时36M数据可以1秒内写完。但这36M数据不是在一个I/O中完成的，而同步复制时每次I/O都需要远端系统写完成信号返回。以一个I/O为10K数据计算（一般来说，一个I/O写速度可以达到0.1ms），采用480M带宽的同步复制后，1个I/O数据需要（单位：毫秒）：0.1 (本地写) + 0.1(远地写) + 10*8/(480*1024*1000*60%) (10KB在480Mbits/s网络上传输速度) + 2*1000公里/(300公里/毫秒)= 0.1 + 0.1 + 0 + 6.6= 6.8 毫秒因此，同步复制模式下，单个I/O的写性能下降35倍。在非并行I/O下，36MBytes的数据（秒级写峰值）需要36 * 1024 / 10 * 0.0035 = 12.9秒，对应用的影响极大。根据以上的分析计算，广州与深圳之间的容灾数据复制不适合采用同步方式。2.3.2.2 采用异步复制方式的分析与同步传输方式相比，异步传输方式对带宽和距离的要求低很多，它只要求在某个时间段内能将数据全部复制到异地即可，同时异步传输方式也不会明显影响应用系统的性能。其缺点是在本地生产数据发生灾难时，异地系统上的数据可能是几秒钟或几分钟以前的数据，即最近几秒钟或几分钟内的交易会丢失。（注：丢失数据的多少，与写I/O量和复制带宽有直接关系）如果采用异步方式进行过程数据容灾复制，对生产系统影响会较小。可以采用VERITAS的Volume Replicator进行数据异步复制。VERITAS VVR （Volume Replicator）采用的是基于主机逻辑卷（Volume）的数据复制方式。通过基于Volume和Log的复制技术，保证在任何时刻本地系统发生自然灾难时，在异地的数据仍是可用的。VERITAS VVR在异步模式下采用了Log技术来跟踪未及时复制的数据块，这个Log是一个先到先服务的堆栈，每一笔I/O处理都会首先被放进这个Log，并按到达先后顺序被复制到异地服务器系统。下图是其工作的结构原理。从上图，我们可以看到整个I/O和复制的过程如下：1.本地主机系统发出第一个I/O请求A到逻辑卷；2.逻辑卷对本地磁盘系统发出I/O请求；2. 在往本地磁盘系统I/O的同时，逻辑卷向本地磁盘系统上的VVR Log发出相同的写请求；3.本地磁盘系统完成I/O操作；并通知逻辑卷“I/O完成”；3. VVR完成针对这个I/O的有关操作，并通知逻辑卷；4.逻辑卷向主机确认“I/O完成”，然后，主机系统发出第二个I/O请求B。服务器的另一个进程：VVR的进程，负责将Log队列中的I/O复制到异地服务器。这个过程和上面的I/O过程在时间上无关。如上图中的标记：“i”和“ii”。i: 本地VVR进程从Log队列中取出最先到达的I/O，复制到异地服务器ii: 异地服务器接收到本地服务器VVR发出的I/O请求，将相应数据写到异地磁盘系统，然后，通知本地系统VVR进程，要求下一个I/O。这里，跟踪未及时复制的数据块的Log技术是保证异地数据可用的必要条件。一个数据库的I/O是有严格顺序的，这个顺序是保证数据库完整性的必要条件，一个完整性被破坏的数据库一般是不可用的，比如根本无法启动、打开该数据库，且是无法修复的。那么，复制时数据库的完整性是怎么保证的呢？我们知道，本地数据库的完整性是由数据库本身来维护的。例如，当一个ORACLE数据库正在写数据时突然发生断电或服务器故障，下次数据库重新启动时，ORACLE数据库会自动进行recover，利用redo log将未写进datafile的数据进行redo，利用数据库的rollback功能将未commit的数据进行回滚，把数据库recover到一个一致的状态。这是数据库本身进行完整性维护的功能。当一个数据库被实时复制到异地时，要保证异地数据库的完整性，必然保证在异地磁盘I/O上的I/O顺序和本地I/O顺序完全相同，否则，异地数据库的完整性就无法保证。VERITAS VVR采用的I/O控制机制是支持先到先服务的Log技术，因此，不管异地数据比本地数据落后多少时间，都能保证异地数据库数据的一致性。比如：本地系统在12：00时发生自然灾难，由于部分数据未被及时复制到异地，如有10分钟的数据未完成复制，那么在异地系统上存在11：50分钟以前的所有数据，数据库启动时会自动做recover，这个11：50分的数据库是可用的。采用异步复制时，远程容灾中心的数据可能会比生产中心滞后，滞后的数据量与生产系统写I/O量和网络带宽有关。例如，广东电信转接数据库每天变化的数据量为204G，采用480M复制网络，则同步可以在204*1024/(480/8*60%) = 5800秒 = 1.7小时内完成，完全可以满足每天的变化要求。而广东电信生产转接数据库的每秒写I/O小于36Mbyte/s，480M复制网络传输的速度为480Mb/8*60%=36MB，所以正常情况下异步复制可以保证数据的丢失量小于1秒。因为复制带宽是以每1秒的峰值写I/O建立的，因此每个I/O所产生的数据，都在1秒内被复制完成了。再次说明：其它数据库和文件共享空间的写I/O数据没有得到，因此无法估算所需的复制带宽。建议采用应用实测的方法，对一定负载的每个数据库进行写I/O的测试统计，才可能正确估算出所需的复制带宽。2.4系统容灾方案的设计2.4.1 容灾软件对于广东电信的容灾系统功能的实现，VERITAS对软件配置有以下建议：同城容灾采用DWDM连接，通过Volume镜像实现；异地采用Volume Replicator进