省级政务云平台-两地三中心容灾技术方案

('省级政务云两地三中心容灾技术方案目录第1章建设目标、范围、任务.....................................................................................................11.1建设目标....................................................................................................................11.2建设范围....................................................................................................................11.3建设任务....................................................................................................................2第2章省级云计算中心方案.........................................................................................................42.1整体架构....................................................................................................................42.2容灾备份建设方案......................................................................................................52.2.1两地三中心容灾技术方案...................................................................................5第1章建设目标、范围、任务1.1建设目标以《国务院办公厅关于促进电子政务协调发展的指导意见》为指导，统筹推进省电子政务基础设施提升、电子政务业务系统协同发展、信息资源共享共用和数据开放利用；按照湘府阅[2015]53号文件要求，以资源整合、集约建设、稳步推进为原则，建成安全可靠、统一高效、国内领先的云计算平台并开展示范应用，为全省各级部门提供弹性的云计算和云存储能力、政务外网承载服务与应用能力，基本满足省直部门“十三五”期间非涉密业务的统一网络、计算资源、存储资源、数据库服务、备份服务、安全服务等需求，提升政府效能，促进政府管理创新，达到简政、兴业、惠民的目标。1.2建设范围省级电子政务外网主要满足各级政府部门社会管理、公共服务等方面的需求，为各省直部门的非涉密电子政务业务提供承载服务。本次建设省级电子政务外网统一云平台，总体框架为“1+2+N”，即“1网、2中心、N多应用云”，省本级政务大数据中心，初步形成“8+3+5”的基本框架。具体业务目标主要包括：“一个网络”——优化升级电子政务外网平台，满足省直部门间以及省到市、市到县网络传输和承载的需求；“两个中心”——建设云计算中心、大数据中心，满足省直部门十三五期间非涉密业务需求，为政府领导提供科学、合理的决策支持。“N朵应用云”——建设基于云平台的N个全省性应用系统，包括政务服务、政务管理、政务行业、政务决策和政务办公等领域。“8大基础数据库、主题数据库”——完成人口、法人、宏观、地理空间、1政务服务信息、工商企业、信用信息、电子证照等8大基础数据库、主题数据库的建设、迁移、备份共享；“3大平台”——完成大数据智能分析平台、数据交换和共享平台、数据开放平台3大平台；“5大示范工程”——完成全省旅游大数据分析、12345服务平台、区域经济脸谱大数据分析、省互联网产业发展状况分析、省政府网站群智能监测分析5大示范工程；建设建设统一的安全体系；建设统一运维管理机制；设计迁移策略，完成部分系统的迁移；明确云平台建设、管理、运营模式，节约投资，提升服务质量。1.3建设任务充分考虑省级电子政务外网统一云平台计算、存储资源需求的阶段性和应用系统建设的复杂性，为了保证投资的有效使用，采用分期建设的原则。（一）第一期——2016年1．完成省电子政务外网的升级改造；2．建设40%的计算、存储资源；3．启动大数据中心建设；4．启动N朵云建设。（二）第二期——2017年1．建设60%的计算、存储资源；2．完成灾备中心建设；3．完成大数据中心建设；4．完成N朵应用云的部分建设。（三）第三期——2018年-2020年1．全面完成N应用朵云建设。其中，本期云平台基础设施部分的建设任务具体包括以下：完成省电子政务外网升级改造（含安全平台）；2建设主数据中心、同城双活数据中心40%的计算、存储资源，数据交换和共享平台；建设政府协同办公平台、政务安全邮箱；提供省政府门户网站群五年的运维服务；提供统一的运维管理服务（五年），确保本期建设的政务外网、安全体系、云计算中心安全稳定运行。3第2章省级云计算中心方案2.1整体架构同城双活数据中机房主数据中心机房广域网市-县网络城域网厅-局网络互联网虚拟化计算资源池物理机资源池数据库计算资源池FC存储网络IP存储网络FC存储资源池分布式存储资源池核心交换机TOR交换机TOR交换机TOR交换机全局、应用负载均衡全局、应用负载均衡内部数据中心虚拟化计算资源池物理机资源池数据库计算资源池FC存储网络IP存储网络FC存储资源池分布式存储资源池核心交换机TOR交换机TOR交换机TOR交换机全局、应用负载均衡全局、应用负载均衡内部数据中心Hadoop服务器资源池外部数据中心虚拟化计算资源池物理机资源池数据库计算资源池FC存储网络IP存储网络FC存储资源池分布式存储资源池核心交换机TOR交换机TOR交换机TOR交换机全局、应用负载均衡全局、应用负载均衡防火墙IPS防毒墙WAF互联网出口区外部数据中心虚拟化计算资源池物理机资源池数据库计算资源池FC存储网络IP存储网络FC存储资源池分布式存储资源池核心交换机TOR交换机TOR交换机TOR交换机全局、应用负载均衡全局、应用负载均衡防火墙IPS防毒墙WAF互联网出口区城域网核心交换机-1城域网核心交换机-2互联网异地灾备中心裸光纤裸光纤DWDM波分设备DWDM波分设备（图示：数据中心架构设计）湖南政务云数据中心采用标准化、开放和高扩展的云计算架构，支撑省政府各部门的政务外网、互联网等多种不同业务服务。（1）网络资源设计：网络采用扁平化二层架构，分为核心层和接入层，提高性能，减少时延；网络大二层部署，保证虚拟机在资源池内部的热迁移能力；核心交换机旁挂负载均衡器，提供负载均衡增值服务；防火墙支持虚拟防火墙能力，实现业务系统之间的安全隔离。外网服务区与互联网服务区之间网络通过部署数据交换平台实现不同业务域之间的安全隔离。（2）计算资源设计：采用标准化的X86物理服务器，构建计算资源池。采用OpenStack开放架构，支持Xen、KVM等主流虚拟化平台。X86服务器根据业务系统对资源的不同需求，配置不同的产品型号及物理配置，划分高性能计算区、通用性能计算区，分别作为虚拟化资源和物理机资源。（3）存储资源设计：多样化存储部署，满足不同业务系统的需求，降低存4储的投资成本。对于数据库、VM文件系统采用FCSAN进行承载；对于非结构化数据、虚拟化镜像等数据存储，建议采用分布式文件系统存储承载，保障存储性能和扩容能力。（4）业务云化设计：根据各政府部门业务对云资源的不同需求，以及业务云化的难度，分批逐步的将现网业务系统迁移至云服务商政务云，实现更多政务业务的云化。（5）云管理平台设计：构建统一云管理平台，通过对政务云基础资源的抽象和资源池化，提供自助式的IaaS、PaaS、SaaS服务。政府客户可通过云管理平台统一门户自助申请云服务，并进行灵活的管理。同时，云管理平台也负责对政务云所有基础资源进行统一的运维管理。2.2容灾备份建设方案2.2.1两地三中心容灾技术方案2.2.1.1演进路线基于目前的情况及省级电子政务外网的发展规划，我们为省级电子政务外网设计一个整体的备份中心解决方案。租用电信运营商机房新建云计算中心，省政府机关二院省电子政务外网机房改建成为同城关键业务双活中心和数据备份中心，在异地（某市州）构建一个灾备数据中心。备份中心全部建成后，在备份中心配置相应基础设施和容灾系统，能够防范各种硬件物理故障：构建存储冗余系统防范存储单点故障，确保存储故障或局部灾难时业务不停顿，数据不丢失（RPO=0，RTO=0），地区性灾难发生时，异地有冗余数据（RPO≈0），可用于快速恢复业务；构建高可用性的主机HA集群、虚拟化群集来防范主机单点故障和主数据中心灾难故障；构建DNS系统、全局负载均衡、本地负载均衡5群集来防范应用主机的单点故障和数据中心灾难，确保应用访问路径的双活；构建冗余的网络出口链路；确保当生产中心出现重大或灾难故障时，系统自动或半自动切换到灾备中心继续运行，保证业务系统的高可用性运转，实现整个业务系统的业务连续性。基于省级电子政务外网建设的总体建设目标,结合目前的实际环境与现状，我们按照”整体规划，逐步演进，分阶段实施”的建设原则，规划以下几个建设阶段:一期工程建设：完成主数据中心和同城双活数据中心建设，实现同城双活容灾备份系统。在主数据中心和同城双活数据中心（省政府机关二院省电子政务外网机房改造）构建双活存储系统、数据库群集、虚拟化群集、负载均衡群集及必要的基础条件，通过数据级备份（容灾）系统，将主生产中心（新建主生产中心，租用电信运营商机房）的关键业务数据全部实时同步到备份中心，确保主生产中心重大故障或灾难情况下关键业务数据不丢失（RPO=0)。在存储复制同步的基础上，在备份中心构建关键应用（业务）处理（主机）设备，在备份中心部署主生产中心的相同处理能力的应用（业务）系统，在ORACLE数据库RAC群集以及应用负载均衡系统的前提下，通过应用级备份（容灾）系统，6实现主生产中心（新建主生产中心，租用电信运营商机房）和备份中心（省政府机关二院省电子政务外网机房改造）的双活双中心容灾架构，即两个中心运行同一个业务系统,提高系统的负载能力,同时当两个中心任意一个故障或灾难时候,关键业务系统在应用架构能够支持的前提下能够完全不中断无缝切换到另一个中心继续运行（RPO=0,RTO=0)。二期工程建设：建立两地三中心容灾备份系统；在第1阶段双活双中心备份系统建设基础上，建设异地备份中心，在异地备份中心构建备份存储系统及必要的基础条件，通过数据级备份（容灾）系统，将双活生产中心（新建云计算中心和省政府机关二院电子政务外网机房）的业务数据全部复制到备份中心，确保主生产中心重大故障或灾难情况下业务数据不丢失（RPO=0)。上述两个不同设计阶段，按照建设的先后顺序，同城双活容灾可以平滑的过渡迁移到两地三中心阶段。通过两地三中心的建设，省级电子政务外网数据中心的灾难恢复能力达到“信息系统灾难恢复规范”国家标准GB/T20988-2007的6级，即RTO为数分钟，RPO为0，部分关键业务RTO可以达到0的水平。2.2.1.2技术架构2.2.1.2.1同城双活技术架构7双活数据中心解决方案是指两个数据中心同时处于运行状态，同时承担业务，提高数据中心的整体服务能力和系统资源利用率。两个数据中心的数据实时保持一致，当单设备故障甚至一个数据中心故障时，业务自动切换，数据零丢失，业务零中断。双活数据中心解决方案是端到端的4层双活方案，分别为：存储层、数据库层、应用层、和网络层，消除单点故障，保证业务连续性。\uf0b2存储双活：双活中心采用冗余光纤互联，并采用DWDM进行环形保护，实现FCSAN的互联。存储虚拟化采用专用的虚拟化引擎或者主机卷管理软件对本地核心存储中的卷与远端核心存储中的卷实现卷级别上的RAID1，即双活分布虚拟卷，实现两个数据中心不同存储上的不同的物理卷的数据层面双活。双活数据中心的数据复制采用同步复制技术，实现RPO=0、即数据零丢失。\uf0b2数据库双活：对于采用Active-Active群集部署的数据库系统，比如OracleRAC，在网络大二层技术和存储数据镜像共享技术的支持下，实现跨站点数据库节点双活和事务并行处理。对于Active-Standby群集部署的数据库系统，跨站点数据库群集实现故障切换。\uf0b2应用双活：基于B/S三层架构的应用采用全局负载均衡及服务器负载8均衡，并结合中间件的软件集群技术实现应用双活及负载均衡；基于C/S架构的应用可采用云资源池的跨站点迁移并结合网络大二层技术，实现应用的在线冗余保护和快速切换。\uf0b2网络双活：主数据中心和同城双活中心采用双链路分别和电子政务网、互联网连接，同时双活中心采用冗余光纤互联，并采用DWDM进行环形保护，实现链路级的双活。INTERNET及内网终端接入采用全局负载均衡、链路负载均衡、本地服务器负载均衡，同时结合DNS域名解析技术实现终端接入的网络双活。双活中心的网络通过大二层局域网延展的方式，在数据中心间扩展局域网（VLAN）的连接，支持应用集群跨地域部署和灵活迁移，支持双活数据中心部署，提供更大范围的资源整合和灵活调配。2.2.1.2.2两地三中心技术架构在同城双活的基础上，另外再异地建设一个容灾备份中心，通过存储远程复制技术和数据备份技术，实现双中心业务数据的异地备份，当双中心出现区域灾难，可确保业务数据不丢失。92.2.1.3容灾设计与实施方法论从整个计算机系统的发展来看，灾难备份经过了一个很长时间的发展过程，在上个世纪60年代，通常进行的都是集中式处理系统，每个系统具备一些简单的灾难恢复计划，通常恢复时间也很长，都以周为单位计算，进行的数据备份和恢复也都处于被动式的模式。到了70年代，随着计算机系统的逐渐普及，应用逐渐有集中式系统转到分散式系统，这个时候，系统开始考虑一些简单的业务恢复计划，恢复的时间也开始以天为单位。到了90年代，网络的飞速发展，系统有开始走向集中，这个时候，对业务的连续性要求就更高，要求恢复时间也小时为单位，系统需要考虑避免高可用的风险。到了今天，企业应用系统进一步飞速发展，业务要求能够达到行业级别的业务连续计划，此时，要求实现业务系统的更高可用性，恢复时间甚至要求达到实时的水平。业务的发展使得企业对业务连续性的要求也越来越高。在业务连续性中，以下几个概念非常重要，它们也是衡量业务持续及灾难备份需求的指标。10\uf06e恢复时间目标（RTO）恢复时间目标（RecoveryTimeObjective，简称RTO）是指灾难发生后，从I/T系统宕机导致业务停顿时刻开始，到IT系统恢复至可支持各部门运作、业务恢复运营之时，此两点之间的时间段称为RTO。一般而言，RTO时间越短，即意味要求在更短的时间内恢复业务至可使用状态。虽然从管理的角度而言，RTO时间越短越好，但是，这同时也意味着更多成本的投入。对于不同行业的企业来说，其RTO目标一般是不相同的。即使是在同一行业，各企业因业务发展规模的不同，其RTO目标也会不尽相同。RTO目标的确定可以用下图来说明：11如上所说，RTO目标越短，成本投入也越大。另一方面，各企业都有其在该发展阶段的单位时间赢利指数，该指数是通过业务影响分析（BusinessImpactAnalysis）咨询服务，以访谈、问答和咨询的方式得到确定的。在确定了企业的单位时间赢利指数后，就可以计算出业务停顿随时间而造成的损失大小。如上图，结合这两条曲线关系，我们将可以找到对该企业而言比较适合的RTO目标，即在该目标定义下，用于灾难备援的投入应不大于对应的业务损失。\uf06e恢复点目标（RPO）恢复点目标（RecoveryPointObjective，简称RPO）是指对系统和应用数据而言，要实现能够恢复至可以支持各部门业务运作，系统及生产数据应恢复到怎样的更新程度。这种更新程度可以是上一周的备份数据，也可以是上一次交易的实时数据。与RTO目标不同，RPO目标的确定不是依赖于企业业务规模，而是取决于企业业务的性质和业务操作对数据的依赖程度。因此，RPO目标对相同行业的企业而言会有些接近，而对于不同行业的企业来说仍可能会有较大差距。12RPO目标的确立仍是以咨询的方式，通过与各业务部门主管的交流，了解业务流程和IT应用的关系，以及通过回答问卷的方式，确定能够支持该企业核心业务的RPO目标。通常可以用以下1到5的等级来衡量企业业务连续性的成熟度。在长年灾难服务提供的过程中，中国电信在业务持续服务方面形成了一套13完整的实施方法论，如下图所示，它包括分析、设计、和实施三个阶段的咨询和技术服务，中国电信又将该三个阶段工作划分为七个步骤，即“风险分析”、“业务影响分析”、“可恢复性评估”、“恢复策略制定”、“灾难恢复方案设计”、“业务持续计划设计”和“业务持续计划演练和维护”。中国电信采用业务持续咨询方法论来规划和设计出企业的业务持续计划。该广受验证的实施方法论的7个步骤由三个阶段串连而成：14分析阶段包含“风险评估”、“业务影响分析”、及可恢复性评估。此阶段提供对灾害潜在损失、各种冲击、及现行恢复能力等方面的量化及质化的分析评估，同时也根据需求来向客户建议必需的措施及迅速的解决方案来实现完全的恢复能力。设计阶段包含“恢复策略制定”及企业“灾难恢复整体解决方案设计”。此阶段根据分析阶段的结果来制定出企业的恢复策略，规划及设计出为实现企业业务持续所必需的行动与解决方案，以达到企业在组织、流程及技术层面的恢复需求。实施阶段包含“业务持续计划设计”及“业务持续计划的演练和维护”。此阶段将建立业务持续计划、实施业务持续计划的桌面演练、执行业务持续计划及灾难恢复的测试、设计业务持续计划的维护方案。其中，业务持续计划中将包括企业的“业务恢复计划”和“技术恢复计划”。建议，企业的业务持续计划的设计及拟定应该是一个持续并循环往复的过程，每一阶段都能持续不断的改进，并且在实际工作中体现有效性与高效性。上述业务持续计划的分析、设计与执行三个阶段，正如上图所绘，可根据其特性分类，分为与企业业务相关及技术相关的不同步骤，共分为以下七个步15骤：1.风险分析2.业务影响分析3.可恢复性评估4.恢复策略制定5.灾难恢复方案设计6.业务持续计划设计7.业务持续计划的演练与维护以下将分别介绍这七个步骤。2.2.1.3.1风险分析风险分析（RiskAnalysis）分析可能对企业业务系统和IT系统的安全性造成威胁的各种风险因素并提出相应的对策和改进方案。因此，风险分析的工作将不仅仅只是提出补救措施，还将定义出对于风险的预防措施。161.风险分析的目标是：1)对企业可能面临的主要威胁性风险进行质与量化的评估；2)按照各风险的严重性，分别定义其所处的风险层次和级别；3)根据各风险发生的可能性，分别定义其所处的风险级别；4)定义风险矩阵图（如上图所示），提出应对风险的建议（避免风险、转移风险、或接受风险）。2.风险分析的进行方式为：1)首先通过召开启动会议来说明风险分析的目的、参加人员需求与职责、设计及分发调查问卷、安排访谈与现场巡视的进度。2)辨认现存风险：搜集财务资料、实施人员访谈、巡视当地状况、检查物理设施、分析搜集到的数据、审核各设施和设备的操作程序（包括IT和非IT）。3)评估风险冲击：检视损失冲击、开发评估分析细节、记录评估结论、定义冲击的等级和层次。4)确定合理的减低风险威胁的处理方法和优先次序。5)记录风险分析工作中的发现与建议。176)制作书面《风险分析报告》7)向管理阶层汇报工作成果和最终交付项目。3.实施风险分析给客户带来的效益是：降低由于不安全、不可靠与不适宜的管理所造成的威胁和风险。风险分析的对象通常为“基础设施与技术”、“人的因素”、和“不可抗力”三个层面，同时，又分为内部原因和外部原因，具体如下表所示：人的因素不可抗力基础设施和技术内部员工外部人员气候自然灾害\uf077硬件故障\uf077技术缺陷\uf077电源故障\uf077电压波动\uf077电源接地不良\uf077电缆老化\uf077空调损坏\uf077消防设施毁坏\uf077通讯线路中断\uf077…\uf077病毒\uf077误操作\uf077盗窃\uf077蓄意破坏\uf077粗心或无知\uf077辞职\uf077情绪波动\uf077…\uf077病毒\uf077黑客攻击\uf077误操作\uf077入室行窃\uf077蓄意破坏\uf077间谍活动\uf077示威活动\uf077消防灌水\uf077…\uf077严寒\uf077冰雪\uf077恶劣气候\uf077崩塌\uf077雷击\uf077龙卷风\uf077海啸\uf077交通堵塞中断\uf077…\uf077水位过高\uf077地震\uf077火灾\uf077塌方\uf077飞行器撞击\uf077爆炸\uf077火山爆发\uf077…内部原因外部原因2.2.1.3.2业务影响分析业务影响分析（BusinessImpactAnalysis，简称BIA）收集、分析及汇总及排序当信息系统一旦遭遇灾害对各项重要关键性业务的影响程度，并依据18其优先级提出恢复策略建议。通过业务影响分析可验证实施容灾解决方案的必要性及需求。1.业务影响分析的目标是：1)确定企业的关键业务流程；2)定义各关键业务可容许中断的最大时间长度；3)确认各关键业务数据丢失的可容许程度。2.业务影响分析的进行方式为：1)首先通过召开启动会议来说明业务影响分析的目的、参加人员需求与职责、设计及分发调查问卷、安排后续访谈行程；2)执行后续访谈，收集问卷、与参加人员共同检查问卷内容以确定：\uf0fc重要业务项目；\uf0fc恢复时间目标（RecoveryTimeObjectives）的需求；\uf0fc业务中断的影响；\uf0fc各部门执行恢复所需的资源。3)开发初步总结；4)举行复审会议来验证以下项目：\uf0fc验证各业务项目恢复优先级；\uf0fc验证恢复时间目标；19\uf0fc验证重要数据的完整。5)制作书面《业务影响分析报告》。6)向管理阶层作总结报告。3.实施业务影响分析给客户带来的效益是：了解不同中断时间对各业务造成的直接与间接损失及优先级，开发恢复策略目标。2.2.1.3.3可恢复性评估可恢复性评估（RecoverabilityAssessment）定义现行各业务流程的恢复能力及现行技术环境的特征，它将从架构、平台、技术、基础设施、组织结构、恢复流程等各层面来评估企业目前的恢复能力。在可恢复性评估中将证实企业当前的业务恢复能力，而在业务影响分析之后，可确定企业需要的恢复能力，这样，将可发现当前恢复能力与需要的恢复能力之间的差距，从而在“恢复策略制定”工作中，根据此差距可规划出企业的恢复策略。201.可恢复性评估的目标是：评估使用现有处理流程与程序，IT作业目前是否能够恢复、需要多少时间恢复、以及可能的数据丢失数量。2.可恢复性评估的进行方式为：1)首先通过召开启动会议来说明项目目的、参加人员的需求与职责、设计及分发调查问卷、安排访谈与现场访视行程。2)复审现有文件。3)举行可恢复性评估研讨会。4)记录现行备份时间长度与方式。5)确定持续时段。6)定义运行重要应用所需资源。7)举行异地分储设施的稽查。8)记录可恢复性评估结果。9)定义适当的业务持续需求。10)制作书面《可恢复性评估报告》。11)向管理阶层作总结报告。213.实施可恢复性评估给客户带来的效益是：1)正确地得出企业当前的恢复能力。2)为恢复策略的制定提供理论依据。3)评估恢复所需投资。2.2.1.3.4制定恢复策略恢复策略制定（RecoveryStrategy）依据前述各项分析和评估的结果和发现，定义消减当前恢复能力与恢复能力目标之间差距的高层次计划（Highlevelplan）。业务影响分析（BIA）是一项深入的研究，用于确定业务之间的关键功能和其中的关键点。然后对该关键点及与其相关的可能发生的损失进行权衡，以决定可能的业务持续策略和所需成本。利用这一信息，管理层可以依照风险几率和业务需要的优先次序，制订出适当的业务持续策略。可恢复性评估与业务影响分析共同作用，对数据中心的流程和当前的恢复能力进行分析。着重于数据中心环境的分析，其中包括硬件、软件、网络和工作流程。通过正常的数据收集、深入的采访和数据分析，可恢复性评估将帮助您了解系统及其与整体业务之间的关系。根据业务影响分析所确定的恢复能力目标与可恢复性评估所确定的当前恢复能力的差距，即可设计和制定出各业务流程的恢复策略。使业务部门所需要的恢复方案（业务影响分析）和系统部门所具备的恢复能力（恢复能力）同步十分重要。中国电信为用户通过业务影响分析和可恢复性评估所进行的顾问工作，将产生一个全面的业务持续策略，并提出为了业务持续所需要进行的改变，以及各种相关的具体建议；配合目前最新的IT可行技术，提出最适当的灾难恢复策略。221.制定恢复策略的目标是：1)消减当前恢复能力与恢复能力目标之间差距的高层次计划（Highlevelplan）。2)解决方案的投资估算。3)建立短期、中期、长期策略。4)提出对组织与运作的建议。2.恢复策略制定的进行方式为：1)依据前述各项分析，配合目前技术，提出最适当的灾难恢复短、中、长期策略。2)估算各种解决方案的投资成本与效益分析。3)召开研讨会确认恢复策略。4)向管理阶层作总结报告。3.实施恢复策略制定给客户带来的效益是：明确了恢复方案的策略计划与所需投资。232.2.1.3.5容灾方案设计灾难恢复方案设计（RecoverySolutionDesign）依据恢复策略来详细设计所选择的最适用的容灾技术方案。中国电信建议，在设计容灾方案时，应综合考虑基础设施、硬件平台、软件技术、网络配置、IT组织、技术恢复流程等方面。根据1992年在美国加州阿纳海姆制定的国际标准SHARE78的定义，容灾技术方案可以根据以下主要方面所达到的程度而分为七个层次：1.备份/恢复的范围；2.灾难恢复计划的状态；3.主生产中心与容灾中心之间的距离；4.主生产中心与容灾中心之间是如何相互连接的；5.数据是怎样在两个中心之间传送的；6.允许有多少数据被丢失；7.怎样保证更新的数据在在容灾中心被更新；8.容灾中心可以开始进行恢复工作的能力。即从低到高的七种不同层次的容灾解决方案。如下图所示，该七个层次的技术方案标准分别是：24很明显，这七个层次所实现的恢复目标是不同的、实施费用也不同。以上七个级别的容灾技术方案的特点和区别，可以参见如下描述：层次RTORPO容灾中心备份方式数据更新/恢复主机Tier172hrs以上24hrs无磁带磁带关机Tier224-72hrs24hrs专有的磁带磁带关机Tier312-24hrs文件级专有的电子文件，定时的活动Tier44-12hrs日志级专有的电子文件或日志，时间段活动Tier52-4hrs交易级专有的电子数据，软件活动Tier630-60min交易级专有的电子数据，系统/硬件活动Tier730-60min交易级专有的电子数据，系统/硬件活动1.0层：无异地备份数据(Nooff-siteData)对于使用0层灾难恢复解决方案的业务，可称其为没有灾难恢复计划，主要表现为：数据仅在本地进行备份恢复，没有任何数据信息和资料被送往异地，没有处理意外事故的计划。25恢复时间：在此种情况下，恢复时间不可预测。事实上也不可能恢复。例如，目前我们通常在机房内所做的数据备份，备份介质保留在机房内，用于本地的数据恢复。当灾难发生时，数据备份和设备有可能一同被毁，无法进行恢复。2.1层：有数据备份，无备用系统（DataBackupwithNoHotSite）使用1层灾难恢复解决方案的业务，通常将需要的数据备份到磁带上，然后将这些介质运送到其它较为安全的地方。但在那里缺乏能恢复数据的系统，若数据备份的频率很高，则在恢复时丢失的数据就会少些。此类业务应能忍受几天乃至几星期的数据丢失。例如，PTAM（PickupTruckAccessMethod）是一种许多数据中心所采用的标准备份方式。在完成所需的数据备份后，用适当的运输工具将它们送到远离本地的地方，同时备有数据恢复的程序。灾难发生后，一整套系统安装需要在一台未开启的计算机上重新完成，系统和数据可以被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低(仅仅需要运输工具的消耗以及存储设备的消耗)。但恢复的时间长，且数据不够新。263.2层：有数据备份，有备用系统（DataBackupwithHotSite）使用2层容灾解决方案的业务会定期将数据备份到磁带上，并将其运到安全的地点。在备份中心有备用的系统，当灾难发生时，可以使用这些数据备份磁带来恢复系统。虽然还需要数小时或几天的时间来恢复数据以使业务可用，但不可预测的恢复时间减少了。2层相当于在1层上增加了备份中心的灾难恢复。备份中心拥有足够的硬件和网络设备来维持关键应用的安装需求，这样的应用是十分的关键的，它必须在灾难发生的同时，在异地有正运行着的硬件提供支持。这种灾难恢复的方式依赖于PTAM方法去将日常数据放入仓库，当灾难发生的时候，再将数据恢复到备份中心的系统上。虽然备份中心的系统增加了成本，但明显降低了灾难恢复时间，系统可在几天内得以恢复。4.3层：电子链接（ElectronicVaulting）使用3层容灾解决方案的业务，是在2层解决方案的基础上，又使用了对关键数据的电子链接技术。电子链接将磁带备份后更改的数据进行记录，并传到备用中心，使用此种方法会比使用传统的磁带备份更快地得到更新的数据。所以，当灾难发生后，只有少量的数据需要重新恢复，恢复时间会缩短。由于备用中心要保持持续运行，与生产中心间的通讯线路要保证畅通，增加了运营成本。但消除了对运输工具的依赖，提高了灾难恢复速度。例如，某企业在每天下班后，将当日的流水全部记录下来，通过网络传到备份中心；备份中心在备用系统上，重新将所有业务重做，保证与生产中心的一致性。这一领域的产品可以分四层：271）存储设备层：IBM-ESS-PPRC、IBMSVC、IBM-DS4000-RM、EMC-SRDF、HP-EVA-StorageWorksContinuousAccess、FALCONSTOR-IPSTOR、NETAPP等。2）操作系统及系统软件层：IBM-GEORM、VERITAS-StorageReplicator/VolumeReplicator、LEGATAL-RepliStor。3）数据库层：IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATAGUARD等。4）应用程序层：应用程序开发时考虑到数据的复制。5.4层：使用快照技术拷贝数据（Point-in-timeCopies）使用4层灾难恢复方案的业务，对数据的实时性和快速恢复性要求更高些。1-3层的方案中较常使用磁带备份和传输，在4层方案中开始使用基于磁盘的解决方案。此时仍然会出现几个小时的数据丢失，但同基于磁带的解决方案相比，通过加快备份频率，使用最近时间点的快照拷贝恢复数据会更快。系统可在一天内恢复。4层灾难恢复可有两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件必须保证与另一方平台在地理上分离，在这种情况下，工作负载可能在两个中心之间分享，中心1成为中心2的备份，反之亦然。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复也可降低到小时级。支持这种工作方式的产品包括IBM-HAGEO、VARITAS-GlobalClusterManager。286.5层：交易的完整性（TransactionIntegrity）使用5层灾难恢复方案的业务，要求保证生产中心和数据备份中心的数据的一致性。在此层方案中只允许少量甚至是无数据丢失，但是该功能的实现完全依赖于所运行的应用。5层除了使用4层的技术外，还要维护数据的状态-要保证在本地和远端数据库中都要更新数据。只有当两地的数据都更新完成后，才认为此次交易成功。生产中心和备用中心是由高速的宽带连接的，关键数据和应用同时运行在两个地点。当灾难发生时，只有正在进行的交易数据会丢失。由于恢复数据的减少，恢复时间也大大缩短。数据库的数据复制功能一般可以工作在这样的方式下：IBM-DB2-HADR、ORACLE-ORACLE-Replication等。7.6层：少量或无数据丢失（Zeroorlittledataloss）6层灾难恢复方案可以保证最高一级数据的实时性。适用于那些几乎不允许数据丢失并要求能快速将数据恢复到应用中的业务。此种解决方案提供数据的一致性，不依赖于应用而是靠大量的硬件技术和操作系统软件来实现的。29这一级别的要求很高，一般需要整个系统应用程序层到硬件层均采取相应措施。1）应用程序层采用基于交易（TRANSACTION）的方法开发。2）数据库可以采取数据复制。IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATAGUARD等。3）操作系统使用集群软件、站点迁移软件、数据复制软件：IBM-HACMP、VARITAS-GlobalClusterManager等。4）硬件层使用同步的数据复制：IBM-ESS-PPRC、IBMSVC、IBM-DS4000-RM、EMC-SRDF或使用带有CONSISTANCY-GROUP功能的异步数据复制IBM-ESS-PPRC、IBM-DS4000-RM。8.7层：解决方案与具体业务相结合，实现自主管理(HighlyAutomated,BussinessIntegratedSolution)7层灾难恢复方案在第6层的基础上，集成了自主管理的功能。在保证数据一致性的同时，又增加了应用的自动恢复能力，使得系统和应用恢复的速度更快、更可靠（按照灾难恢复流程，手工操作也可实现整个恢复过程）。7层可以实现0数据丢失率，同时保证数据立即自动地被传输到恢复中心。7层被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。7层是灾难恢复中最昂贵的方式，但也是速度最快的恢复方式。当一个工作中心发生灾难时，7层能够提供一定程度的跨站点动态负载平衡和自动系统故障切换功能。现在已经证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能需要一个应该纳入考虑范围的重要事项。30在实际选择灾难备份方案时，需要在方案本身、宕机时间和实施方案所需成本三者之间找到一个平衡点。三者的平衡关系2.2.1.3.6业务连续性计划设计业务持续计划设计（BusinessContinuityPlanning）定义、书面化与测试在灾难发生之前、之中与之后的企业营运组织架构与任务职责，以确定可被接受的业务持续运作的规范。中国电信建议，业务持续计划将主要由“业务恢复计划”和“技术恢复计划”两方面来组成。其中，业务恢复计划为：当灾难事件发生时，为确保企业关键业务功能连续运作而必须遵循的恢复程序和实施细节。31技术恢复计划为：当灾难事件发生时，在容灾中心建立和执行基础架构恢复所必须遵循的恢复程序，包括IT系统和相关设施。为有效并高效的实施业务持续计划，还必须为灾难恢复和业务持续设计相应的组织架构和人员职责。1.业务持续计划设计的目的是：定义、制作、建置与测试于灾害发生前、中、后的组织架构设计与行动计划，以确保公司各重要关键业务的持续运作。2.业务持续计划设计的进行方式为：1)首先召开启动会议来说明项目目的、参加人员需求与职责、分发业务规范工作手册（Workbook）、确定工作手册返回日期。2)收集与分析工作手册内容。3)确认下列项目的备份处理：\uf0fc重要应用系统\uf0fc系统软/硬件\uf0fc数据库\uf0fc网络\uf0fc特殊需求\uf0fc备份处理\uf0fc数据保存\uf0fc系统安全4)确认下列项目的持续处理\uf0fc系统持续\uf0fc本地用户\uf0fc远程用户32\uf0fc入网机构\uf0fc服务者\uf0fc供货商\uf0fc人员\uf0fc特殊需求\uf0fc次序/优先级5)开发业务持续计划的细节。\uf0fc确定各项工作的负责人及其应完成职责。\uf0fc开发灾难通报程序。\uf0fc开发业务恢复工作项目图表及时间安排\uf0fc开发回切作业处理。\uf0fc设备修复与重购\uf0fc建筑物重建\uf0fc数据回归\uf0fc业务切换6)完成《业务持续计划》初稿。7)制作业务持续计划的桌面演练计划，演练活动包括：演练时间、演练范围、目标、参加人员、所需资源、假设状况、衡量标准、过程叙述、结果讨论与计划维护。8)建立业务持续计划维护的处理规范：包括正常计划维护、根据演练结果的维护、由于各项变更而产生的维护、定期维护、回切作业的维护。9)在灾备技术系统建立后，实施业务持续计划实际测试。10)根据桌面演练与测试，完成对《业务持续计划》的完善和修订。3311)向管理阶层作总结报告。3.业务持续计划设计给客户带来的效益是：1)建立紧急应变组织与行动的指导文件。2)作为演练和测试的指导方针。3)用于企业业务持续计划的稽核。2.2.1.3.7业务连续性计划的演练和维护业务持续计划的演练和维护通过对业务持续计划的桌面演练、实际测试、和维护管理，确保业务持续计划保持最新及有效性。根据各个等级的灾难备份系统策略和灾难恢复等级，可以进行不同类型的演练和模拟演习，但整体上讲，演练和演习一般需要达到以下的目标：通过对灾难恢复预案的桌面演练、模拟演练和实战演练，以确保灾难恢复预案保持最新及有效性。根据各个等级的容灾系统策略和灾难恢复等级，可以进行不同类型的演练和模拟演习，但整体上讲，演练和演习一般需要达到以下的目标：1.验证能力灾难备份系统和灾难恢复计划是一个系统工程，包含基础环境、灾难备份系统、相关的恢复计划和组织协调，通过演练和演习，需要对相应的内容是否可以支撑灾难时业务恢复的需求进行检验。基础环境部分需要对灾难恢复时的场地、业务恢复环境和配套设施、灾难恢复时IT系统所依赖的基础设施如UPS、供电、机房环境和进入控制等各个方面的能力是否可以满足灾难恢复的需要进行检验。对灾难备份系统，在发生灾难时，用于灾难恢复和业务恢复的IT支持系统以及相应的配套设备的处理能力、备份网络系统的网络贷款和流量等各个方面进行检验和验证。对灾难备份系统的运营和管理能力也是一种检验，通过演练，可以对灾难备份系统在日常运营管理情况、数据同步情况、系统版本管理情况、容灾中心34的响应及时性和有效性进行检验和验证。通过演练和演习，也是对整个灾难恢复执行过中组织协调能力的检验和验证，在灾难发生时，需要面对媒体的公关、对客户的安抚、对员工的指引和各项工作的有序开展和及时协调等多个方面的工作，对灾难恢复的组织架构、人员操作和工作协调均有着较高的要求，通过演练也可以检验组织和机构是否已经具备了相应的应变能力和执行力，确保在基础环境、灾难备份IT系统的等硬件基础上，各项相关方面已经作好准备和具备有序工作的能力。只有通过以上的各个方面的能力的综合体现，通过演练和演习，对以上各个方面的能力的整体综合检验，才可以确保灾难备份系统和灾难恢复计划是一个可以信赖的系统，可以在发生灾难事件时，相应的组织和机构以及所建立的灾难备份系统和灾难恢复计划具备相应的灾难恢复能力。2.发现不足建立灾难备份系统和灾难恢复计划，只是建立了一个基础和起点，并不是一个一劳永逸的工作完成得标志。对于初次建立的灾难备份系统和灾难恢复计划，需要通过演练和演习来发现不足和发现问题。对于已经进入正常运营的灾难备份系统和灾难恢复计划，由于业务、IT系统的变化和变更，以及组织架构的变化和调整，也需要不断的进行演练和演习，以发现问题和不足，确保灾难备份系统和灾难恢复计划的正确性、有效性和可操作性。3.流程改进灾难备份系统的有效恢复，以及灾难恢复计划中，均定义了不少的流程和过程，这些流程和工作规范在相当大的程度上保证一旦在灾难事件的危机情况下，各项工作和任务的有序执行和有效恢复。这些流程和规范会随着技术的发展和业务的发展不断变化和优化。通过演练和演习，我们可以发现流程和规范上的不足和可以改进的方面，不断进行改进和优化，确保相应的灾难恢复工作可以有效地运作。4.锻炼团队所有的工作都是由人来完成的，灾难备份系统的运作依靠运营团队的运营来保证灾难备份系统的可用性和有效性，灾难恢复计划的执行依靠灾难恢复的各个恢复团队的有效执行来保证系统的恢复和业务的连续性。因此，如何保证35各个团队以及各个团队中的相关人员对灾难恢复工作熟悉和有效执行是灾难有效恢复的关键。通过演练和演习，可以使灾难恢复的指挥团队、技术恢复团队、业务恢复团队、后勤保障团队等各个团队熟悉、了解相关的策略、流程和方法；并且通过演练和演习，使相关团队的相关人员能进行实际操作和完成具体的工作内容，使相关人员掌握相关的技术和规程；通过演练和演习，也是各个业务部门、后勤部门、公关控制部门了解情况和处理的方法，使整体上保证灾难恢复和业务连续性可以有效地执行和恢复。业务持续计划的维护包括：1)日常计划维护2)根据演练结果的维护3)由于各项变更而产生的维护4)定期维护5)恢复计划和回切计划的维护2.2.1.4同城双活方案2.2.1.4.1整体架构在同城租用电信运营商机房作为主数据中心，利用省二院省电子政务中心机房作为省政务云项目的同城双活数据中心，通过波分设备与省二院机房互联组成同城双活数据中心，同时向外提供业务服务，实现关键业务双活。任意一数据中心站点故障，都不会中断业务，确保云平台安全，实现业务连续性保护。362.2.1.4.2双活容灾方案设计2.2.1.4.2.1网络层双活设计\uf0d8双活整体架构37路由策略引导技术：广域网和城域网用户访问主IDC机房和省二院数据中心，可以通过调整BGP或OSPF等路由策略即可实现用户到不同业务的网络分流。DNS和全局负载引导技术：DNS服务器和全局负载均衡设备实现互联网用户访问外部业务时对两个数据中心的流量智能调度，服务器负载均衡产品实现本地业务服务器的负载均衡同时，向全局负载均衡设备通报本地应用服务器的健康状况及应用服务器的负载情况。CSS+EVN++VXLAN技术:从网络上来看，双活数据中心需要将同一个网络扩展到多个数据中心，在数据中心间需要大二层网络连接并且实现服务器和应用的虚拟化数据中心互联技术。大二层的网络技术有CASS、TRILL、SPB、EVN等。CSS是将多台网络设备（成员设备）虚拟化为一台网络设备（虚拟设备），并将这些设备作为单一设备管理和使用。VSS把多台设备合并，简化了管理提高了性能，但VSS构建二层网络时，汇聚交换机最多是可达4台，在二层无阻塞的前提下可接入13824台双网卡的千兆服务器，如果客户期望其服务器资源池可以有效扩充到2万台甚至更大，就需要其他技术提供更大的网络容量；TRILL的全称就是TransparentInterconnectionofLotsofLinks，顾名思义，其本质就是将很多条链路透明地组织在一起，以致于上层IP应用感觉这只是一条链路似的。它本质上是一个2.5层的技术，使用最短路径、多路径等三层路38由技术来讲多条链路组织成为一个大二层网络，并支持VLAN、自配置、多播等二层功能。TRILL目前最大可以支持10核心组网，其最大能力可以无阻塞的接入27648台双网卡千兆服务器，但TRILL技术目前在芯片实现上存在客观缺陷，核心层不能支持三层终结，也就是说TRILL的核心层不能做网关设备。必须要在核心层上再增加一层设备来做网关，这导致网络结构变得复杂，管理难度增加，网络建设、运维成本都会增加；SPB的组网方案和TRILL基本相同(同样可支持接入27648台)，其优势在于能够方便的支持VLAN扩展功能，但同样存在网关与SPB核心必须分离的芯片缺陷，导致网络层次增加，管理、运维成本增加；EVN可以通过汇聚层和核心层之间的IP网络实现二层互通，所以通过EVN扩展多个二层域的时候不需要更改布线或是设备，仅仅需要在汇聚设备上启用EVN特性即可，这样可以平滑的扩展二层网络的规模。其技术成熟、架构稳定，能够支持大规模二层网络(接入规模221184)，运维也简单方便。另外，也有部分虚拟化和软件厂商提出了软件的L2overL3技术解决方案。例如VXLAN、NVGRE，前者是由VMware和思科提出的标准(使用了L2oUDP的封装方式)，后者是由HP和微软提出的标准（使用了L2oGRE封装方式），在虚拟化层的vSwitch中将二层数据封装在UDP、GRE报文中，在物理网络拓扑上构建一层虚拟化网络层，从而摆脱对网络设备层的二层、三层限制。这两种技术的主要特点是隧道的起点和终点主要在vswitch上，而不是物理交换机上。隧道的封装在服务器内部的vswitch就已经打好，然后将物理网络当作大的IP背板加以穿透，大二层范围可以跨DC。以期达到快速部署，灵活创建虚拟化网络的目的。但这些技术由于性能、扩展性等问题，也没有得到广泛的使用。\uf0d8大二层技术选型为了满足本次的“省级电子政务外网统一云平台”项目业务实际需求，在业务承载的基础网络部分也衍生出如下几个基本的需求：1.首先需要满足在云计算环境下能够为政务云下的各种业务隔离；政务云是为各厅局单位共同接入的公共平台，从安全性的角度考虑，各厅局单位之间以及单位内各业务系统需要实现相互隔离。392.其次从省级平台的情况看，横向互联的职能单位由于运营商在做IP地址规划时的简单处理，局委办都是通过NAT转换后接入到省电子政务外网，而局域网的私网IP地址段这大多相同，如何在不改变原有各厅局委办IP地址的情况下，实现平缓接入到政务云非常关键。3.其次在云计算环境下，最大的好处在于计算资源能够随需移动，计算资源通过计算虚拟化可以实现在单台的物理机下虚拟化成多个虚机，为了保障业务快速部署，业务的高可靠性，各虚机需要在各租户网络内部进行迁移，或进行集群，虚机迁移，其IP地址和IP网关本身不会变化，同时虚机集群也需要各虚机保持在一个网段之内，所以从整个基础网络来看，需要整个数据中心需要提供一个大二层网络。4.从整个“省级电子政务外网统一云平台”的建设情况来看，其接入单位众多，业务需求多样；各厅局单位后续的业务规模难以准确预测，需要基础网络具备灵活的弹性，能够满足在后期业务的弹性扩展，包括单一业务的规模扩展，单一用户的规模扩展；扩展范围甚至覆盖到另外区域的数据中心。根据上述的几个需求来看，“省级电子政务外网统一云平台”的建设必须要满足多租户安全接入，租户内部网络隔离，实现各厅局存在的相同IP地址段的平滑接入，简单的大二层，后续弹性扩展等多个需求。针对当前常见的数据中心技术进行具体分析：VLAN+STP技术传统的核心、汇聚、接入通过VLAN实现租户的隔离，通过STP实现多路径保护；但传统二层网络中部署的STP生成树技术协议，部署和维护繁琐，网络规模不宜过大，限制了网络的扩展。而后以厂家私有网络虚拟化技术如vPC等网络虚拟化技术，虽然可以简化部署、同时具备高可靠性，但是对于网络的拓扑架构有严格要求，同时各厂家不支持互通，在网络的可扩展性上有所欠缺，只适合小规模网络部署，一般只适合数据中心内部网络；此外云业务中虚拟机的大规模部署带来的另一个问题就是使传统网络设备二层地址（MAC）表项的大小成了云计算环境下虚拟机规模的关键参数，特别是对于接入设备而言，二层地址表项规格较小，这也将限制整个云计算数据中心业务规模；不建议在此次项目中采用。40TRILL/SPB/FabricPath+VLAN技术随着数据中心接入规模的要求，新出现了大规模二层网络技术TRILL/SPB/FabricPath等，它们通过引入IS-IS等协议实现多个二层网络的互通，能支持二层网络的良好扩展，但对数据包所经过的沿途所有网络设备有特殊要求，网络中的设备需要软硬件升级才能支持此类新技术，带来部署成本的上升，同时各厂商互通成为一个难以解决的问题，由于采用传统的VLAN接入，随着政务云业务的快速发展，对于租户的数量可能在不远的将来成为制约政务云向更多规模扩展的瓶颈，因此本次需要寻求更具弹性的网络技术实现政务云的接入。SDN+Overlay的网络虚拟化技术Overlay技术是专门针对多租户数据中心建设而引入的技术，在业界知名的互联网数据中心中，以及公有云的建设中成为当前基础网络的首选技术，Overlay是一种网络架构上叠加的虚拟化技术模式，其大体框架是对基础网络不进行大规模修改的条件下，实现应用在网络上的承载，并能与其它网络业务分离，并且以基于IP的基础网络技术为主。Overlay网络是指建立在已有网络上的虚拟网，逻辑节点和逻辑链路构成了Overlay网络。具有独立的控制和转发平面，对于连接在Overlay边缘设备之外的终端系统来说，物理网络是透明的。Overlay网络是物理网络向云和虚拟化的深度延伸，使云资源池化能力可以摆脱物理网络的重重限制，是实现云网融合的关键。从当前业界的应用情况来看，Overlay可以满足“省级电子政务外网统一云平台”对于多租户接入、多租户隔离、弹性扩展、大二层组网等需求，建议本次“省级电子政务外网统一云平台”采用Overlay技术实现整个基础网络的构建。IETF在Overlay技术领域提出三大技术方案：VXLAN：VXLAN是将以太网报文封装成UDP报文进行隧道传输，UDP目的端口为已知端口，源端口可按流分配，标准5元组方式有利于在IP网络转发过程中进行负载分担；隔离标识采用24比特来表示；未知目的、广播、组播等网络流量均被封装为组播转发。NVGRE：NVGRE采用的是RFC2784和RFC2890所定义的GRE隧道协议。将以41太网报文封装在GRE内进行隧道传输。隔离标识采用24比特来表示；与VXLAN的主要区别在对流量的负载分担上，因为使用了GRE隧道封装，NVGRE使用了GRE扩展字段flowID进行流量负载分担，这就要求物理网络能够识别GRE隧道的扩展信息。STT：STT是无状态传输协议，通过将以太网报文封装成TCP报文进行隧道传输，隔离标识采用64比特来表示。与VXLAN和NVGRE的主要区别是在隧道封装格式使用了无状态TCP，需要对传统TCP协议进行修改以适应NVGRE的传输。总体比较，VXLAN技术具有最佳优势：1、L2-L4层链路HASH能力强，不需要对现有网络改造。2、对传输层无修改，使用标准的UDP传输流量（STT需要修改TCP）。3、业界支持度最好，商用网络芯片大部分支持。\uf0d8VXLAN设计VXLAN简介VXLAN（VirtualeXtensibleLocalAreaNetwork）是VLAN扩展方案草案，采用MACinUDP（UserDatagramProtocol）封装方式，是NVo3（NetworkVirtualizationoverLayer中的一种网络虚拟化技术。一台服务器可虚拟多台虚拟机，而一台虚拟机相当于一台主机。主机的数量发生了数量级的变化，这也为虚拟网络带来了如下问题：\uf06c虚拟机规模受网络规格限制在大二层网络环境下，数据报文是通过查询MAC地址表进行二层转发，而MAC地址表的容量限制了虚拟机的数量。\uf06c网络隔离能力限制当前主流的网络隔离技术是VLAN或VPN（VirtualPrivateNetwork），在大规模的虚拟化网络中部署存在如下限制：–由于IEEE802.1Q中定义的VLANTag域只有12比特，仅能表示4096个VLAN，无法满足大二层网络中标识大量用户群的需求。–传统二层网络中的VLAN/VPN无法满足网络动态调整的需求。\uf06c虚拟机迁移范围受网络架构限制虚拟机启动后，可能由于服务器资源等问题（如CPU过高，内存不够等），42需要将虚拟机迁移到新的服务器上。为了保证虚拟机迁移过程中业务不中断，则需要保证虚拟机的IP地址、MAC地址等参数保持不变，这就要求业务网络是一个二层网络，且要求网络本身具备多路径的冗余备份和可靠性。针对大二层网络，VXLAN的提出很好地解决了上述问题。\uf06c针对虚拟机规模受网络规格限制VXLAN将虚拟机发出的数据包封装在UDP中，并使用物理网络的IP/MAC地址作为外层头进行封装，对网络只表现为封装后的参数。因此，极大降低了大二层网络对MAC地址规格的需求。\uf06c针对网络隔离能力限制VXLAN引入了类似VLANID的用户标识，称为VXLAN网络标识VNI（VXLANNetworkID），由24比特组成，支持多达16M（(2^24-1)/1024^2）的VXLAN段，从而满足了大量的用户标识。\uf06c针对虚拟机迁移范围受网络架构限制通过VXLAN构建大二层网络，保证了在虚拟迁移时虚拟机的IP地址、MAC地址等参数保持不变。随着数据中心在物理网络基础设施上实施服务器虚拟化的快速发展，作为NVo3技术之一的VXLAN：通过24比特的VNI可以支持多达16M的VXLAN段的网络隔离，对用户进行隔离和标识不再受到限制，可满足海量租户。除VXLAN网络边缘设备，网络中的其他设备不需要识别虚拟机的MAC地址，减轻了设备的MAC地址学习压力，提升了设备性能。通过采用MACinUDP封装来延伸二层网络，实现了物理网络和虚拟网络解耦，租户可以规划自己的虚拟网络，不需要考虑物理网络IP地址和广播域的限制，大大降低了网络管理的难度。VXLAN原理描述VXLAN通过采用MACinUDP封装来延伸二层网络，是大二层虚拟网络扩展的隧道封装技术。在大二层网络，为了方便控制与部署引入了SDN（SoftwareDefinedNetwork）控制器概念。控制器通过OpenFlow协议将信息下发给转发器，以实现控制器统一维护管理。43\uf06cSDN控制器相关概念概念描述控制器控制器是OpenFlow协议的控制面服务器，所有的路径计算与管理都由独立的控制器完成。（Controller）通常，刀片服务器即可作为控制器。转发器OpenFlow协议的转发平面设备，只处理数据转发任务。OpenFlow协议OpenFlow协议是SDN中的重要协议，是控制器和转发器的通信通道。控制器通过OpenFlow协议将信息下发给转发器。OpenFlow流表OpenFlow流表用来指导转发器进行报文转发。转发器根据流表中的匹配项对报文进行匹配，匹配上则执行相应的动作。如，流表的匹配域是源MAC地址，动作是向某个端口转发，则转发器根据这个流表，对匹配这个MAC地址的报文进行向某个端口转发的动作。控制器通过下发流表直接控制转发器的转发行为，实现控制器对转发器的控制。\uf06c在控制器上配置VXLAN，通过OpenFlow协议将VXLAN信息下发给转发器。通过VXLAN，虚拟网络可接入大量租户，且租户可以规划自己的虚拟网络，不需要考虑物理网络IP地址和广播域的限制，降低了网络管理的难度。相关概44念如表所示。概念描述NVE（NetworkVirtualizationEdge）网络虚拟边缘节点NVE，实现网络虚拟化功能的网络实体。VAP（VirtualAccessPoint）虚拟接入点VAP统一为二层子接口，用于接入数据报文。为二层子接口配置不同的流封装，可实现不同的数据报文接入不同的二层子接口。VTEP（VXLANTunnelEndpoints）VTEP是VXLAN隧道端点，封装在NVE中，用于VXLAN报文的封装和解封装。VTEP与物理网络相连，分配有物理网络的IP地址，该地址与虚拟网络无关。VXLAN报文中源IP地址为本节点的VTEP地址，VXLAN报文中目的IP地址为对端节点的VTEP地址，一对VTEP地址就对应着一个VXLAN隧道。VNI（VXLANNetworkIdentifier）VXLAN网络标识VNI类似VLANID，用于区分VXLAN段，不同VXLAN段的虚拟机不能直接二层相互通信。一个VNI表示一个租户，即使多个终端用户属于同一个VNI，也表示一个租户。VNI由24比特组成，支持多达16M（(2^24-1)/1024^2）的租户。基本格式VXLAN是MACinUDP的网络虚拟化技术，所以其报文封装是在原始以太报文之前添加了一个UDP封装及VXLAN头封装45\uf06cVXLAN头封装–Flags：8比特，取值为00001000。–VNI：VXLAN网络标识，24比特，用于区分VXLAN段。–Reserved：24比特和8比特，必须设置为0。\uf06c外层UDP头封装目的UDP端口号是4789。源端口号是内层以太报文头通过哈希算法计算后的值。\uf06c外层IP头封装源IP地址为发送报文的虚拟机所属VTEP的IP地址；目的IP地址是目的虚拟机所属VTEP的IP地址。\uf06c外层Ethernet头封装–SA：发送报文的虚拟机所属VTEP的MAC地址。–DA：目的虚拟机所属VTEP上路由表中直连的下一跳MAC地址。–VLANType：可选字段，当报文中携带VLANTag时，该字段取值为0x8100。–EthernetType：以太报文类型，IP协议报文该字段取值为0x0800。46数据报文转发在VXLAN网络中，业务接入点统一表现为二层子接口，通过在二层子接口上配置流封装实现不同的接口接入不同的数据报文。广播域统一表现为BD（Bridge-Domain），将二层子接口关联BD后，可实现数据报文通过BD转发。由于VXLAN网络中通过VNI标识不同租户，将VNI以1:1方式映射到BD，可实现不同的租户通过不同的BD转发。和VLAN类似，不同VNI之间的VXLAN，及VXLAN和非VXLAN之间不能直接进行二层通信。为了使VXLAN之间，以及VXLAN和非VXLAN之间能够进行通信，VXLAN引入了VXLAN网关VXLAN网关分为：\uf06c二层网关：用于同一网段的终端用户通信。VXLAN二层网关收到用户报文，根据报文中包含的目的MAC地址类型，报文转发流程分为：–MAC地址是BUM（Broadcast&Unknown-unicast&Multicast）地址，按照BUM报文转发流程进行转发。–MAC地址是已知单播地址，按照已知单播报文转发流程进行转发。\uf06c三层网关：用于非同一网段的终端用户通信或VXLAN和非VXLAN用户间的通信。BUM报文转发流程当BUM报文进入VXLAN隧道，接入端VTEP采用头端复制方式进行报文的VXLAN封装。BUM报文出VXLAN隧道，出口端VTEP对报文解封转。BUM报文具体转发流程如图所示。471.Switch_1收到来自终端A的报文，根据报文中接入的端口和VLAN信息获取对应的二层广播域，并判断报文的目的MAC是否为BUMMAC。\uf06c是，在对应的二层广播域内广播，并跳转到2。\uf06c不是，通过已知单播报文转发流程。2.Switch_1上VTEP根据对应的二层广播域获取对应VNI的头端复制隧道列表，依据获取的隧道列表进行报文复制，并进行VXLAN封装。基于每个出端口和VXLAN封装信息封装VXLAN头和外层IP信息，并从出端口转发。3.Switch_2/Switch_3上VTEP收到VXLAN报文后，根据UDP目的端口号、源/目的IP地址、VNI判断VXLAN报文的合法有效性。依据VNI获取对应的二层48广播域，然后进行VXLAN解封装，获取内层二层报文，判断报文的目的MAC是否为BUMMAC。\uf06cl是，在对应的二层广播域内非VXLAN侧进行广播处理。\uf06cl不是，再判断是否是本机MAC。–是，上送主机处理。–不是，在对应的二层广播域内查找出接口和封装信息，并跳转到4。4.Switch_2/Switch_3根据查找到的出接口和封装信息，为报文添加VLANTag，转发给对应的终端B/C。已知单播报文转发流程已知单播报文具体转发流程491.Switch_1收到来自终端A的报文，根据报文中接入的端口和VLAN信息获取对应的二层广播域，并判断报文的目的MAC是否为已知单播MAC。\uf06c是，再判断是否为本机MAC。–是，上送主机处理。–不是，在对应的二层广播域内查找出接口和封装信息，并跳转到2。\uf06c不是，在对应的二层广播域内进行广播处理，并跳转到2。2.Switch_1上VTEP根据查找到的出接口和封装信息进行VXLAN封装和报文转发。3.Switch_2上VTEP收到VXLAN报文后，根据UDP目的端口号、源/目的IP地址、VNI判断VXLAN报文的合法有效性。依据VNI获取对应的二层广播域，然后进行VXLAN解封装，获取内层二层报文，判断报文的目的MAC是否为已知单播报文MAC。\uf06c是，在对应的二层广播域内查找出接口和封装信息，并跳转到4。\uf06c不是，再判断是否是本机MAC。–是，上送主机处理。50–不是，通过BUM报文转发流程。4.Switch_2根据查找到的出接口和封装信息，为报文添加VLANTag，转发给对应的终端B。三层网关不同网段的VXLAN间通信，及VXLAN和非VXLAN的通信，需要通过IP路由实现。在三层网关上创建BD，将VNI以1:1方式映射到BD，基于BD创建BDIF接口，通过BDIF接口配置IP地址实现不同网段的VXLAN间，及VXLAN和非VXLAN的通信。如图2-7所示，三层网关通信具体实现过程如下：1.作为VXLAN二层网关的Switch_4收到VXLAN报文后进行解封装，确认内层报文中的DMAC是否是本网关接口的MAC地址。\uf06c是，转给对应目的网段的三层网关处理，并跳转2。\uf06c不是，在对应的二层广播域内查找出接口和封装信息。512.作为VXLAN三层网关的Switch_4剥除内层报文的以太封装，解析目的IP。根据目的IP查找ARP表项，确认DMAC、VXLAN隧道出接口及VIN等信息。\uf06c没有VXLAN隧道出接口及VIN信息，进行三层转发。\uf06c有VXLAN隧道出接口及VIN信息，跳转3。3.作为VXLAN二层网关的Switch_4重新封装VXLAN报文，其中内层报文以太头中的SMAC是网关接口的MAC地址。2.2.1.4.2.2负载均衡设计\uf06c数据中心间负载均衡电子政务广域网、城域网或互联网的用户采用域名访问省电子政务外网应用时，可以采用GSLB实现站点间的负载均衡。本方案的GSLB采用Radware实现数据中心间的负载均衡。在两个数据中心各部署一台GSLB，配置两台GSLB为Active-backup模式，两个数据中心间的GSLB通过网络连接。GSLB以“单臂旁挂”的方式连接到入口路由，GSLB可以对接现网DNS,GSLB作为下一级DNS。现网DNS通过轮询方式保证第一台GSLB故障时其他的GSLB可以接替工作。\uf06c数据中心内负载均衡本方案的SLB采用RadWare负载均衡器实现数据中心内的负载均衡。SLB支持两种组网方式：三层旁挂方式与二层旁挂方式。三层旁挂方式，采用将SLB旁挂在核心交换机，将业务服务器接到接入交52换机上的方式，适合大规模组网的应用场景。组网如下图所示：二层旁挂方式，适合小规模组网，吞吐量4Gbs以下的应用场景，所有业务服务器和SLB同时接到同一个接入交换机。SLB在双活方案的部署图如下：53SLB部署原则：一个站点部署两台SLB，组成双机热备集群，两站点各部署一个SLB集群，两个SLB集群没有关系；在每个站点分别配置两台SLB为双机热备集群，分别挂载在核心交换机上，保证在主、备机之间的数据同步，当主用SLB故障时会自动切换到备用SLB上。SLB通过监控交换机的状态，当发现主用交换机故障时，SLB也会自动切换到备机上，保证了可靠性。WEB服务器部署原则：将DC1所有WEB服务器创建一个资源池DC1pool，将DC2所有WEB服务器创建一个资源池DC2pool。资源池可以绑定一个备份的资源池。当主资源池处于失效状态时，新的请求可以指向备份资源池，以保证业务的正常使用。上下层连接原则：SLB连接GSLB：GSLB不分发业务，不参与业务IO路径，只做域名解析（一个域名解析到DC1或DC2），将两个站点的SLB对外IP添加到GSLB的域名解析IP列表。WEB服务器连接SLB：DC1和DC2的WEB服务器都有相同域名。DC1的SLB默认分发到DC1的web服务器，DC2的web服务器作为备站点。DC2的SLB默认分发到DC2的web服务器，DC1的web服务器作为备站点。2.2.1.4.2.3应用层双活设计一个从浏览器发送的HTTP请求经过Web服务器，Web服务器处理静态页面，同时将动态页面业务负载转发到应用服务器。WEB应用工作原理如下：一般的，应用服务器将组成一个集群，一台WEB服务器对应一个应用服务器集群。WEB服务器+应用服务器部署图如下：54WEB服务器+应用服务器的双活部署图如下：网络拓扑如上图所示。WEB服务器部署原则：一个站点部署多台WEB服务器，不组成集群，由SLB创建将一个站点内部的所有WEB服务器组成资源池。双活数据中心方案分别创建WEB服务器DC1资源池和WEB服务器DC2资源池；应用服务器部署原则：一个站点部署多台应用服务器，组成AA集群。两站点各部署一个应用服务器集群，两个应用服务器集群没有关系。双活数据中心方案分别创建应用服务器DC1集群和应用服务器DC2集群；WEB服务器+应用服务器上下层连接原则：55WEB服务器连接SLB：DC1的SLB默认分发到WEB服务器DC1资源池，WEB服务器DC2资源池作为备站点。DC2的SLB默认分发到WEB服务器DC2资源池，WEB服务器DC1资源池作为备站点。应用服务器连接IHS：WEB服务器DC1资源池的WEB服务器默认分发到应用服务器DC1集群，应用服务器DC2集群作为备站点。WEB服务器DC2资源池的WEB服务器默认分发到应用服务器DC2集群，应用服务器DC1集群作为备站点。DB连接应用服务器：应用服务器DC1集群和应用服务器DC2集群都连接上DB集群。2.2.1.4.2.4虚拟化平台双活设计本次方案中，虚拟化平台采用华为FusionSphere解决方案。FusionSphere集群以共享存储为基础，通过共享的存储资源，两个数据中心分别部署多台CNA主机，组成FusionSphere集群。方案结合HA功能，保证当任一主机或单数据中心故障时，业务虚拟机可以自动切换到正常的主机运行，数据无丢失，业务中断时间趋近于零。方案结合DRS功能，业务虚拟机可跨数据中心自动实现负载均衡，实现主机资源均衡分配使用。当系统需要计划内维护或者主机资源重新分配时，可通过迁移功能手动将业务虚拟机在主机间迁移，迁移过程中业务不中断。FusionSphere双活方案中，需要启用DRS特性进行虚拟机本地优先启动和HA.2.2.1.4.2.5数据库层双活设计\uf06c数据库双活架构选择数据库层双活部署通过集群技术实现，在业界主要分为两种方式：A/S（Active-Standby）集群与A/A（Active-Active）集群。Active-Standby集群节点之间为主备部署，备节点只在主节点故障后进行故障切换。常见的主备集群系统如：IBMPowerHA、HPServiceGuard、MicrosoftWSFC、VeritasClusterServer等。在主节点故障后，集群备节点将自动重新启动应用系统，无需管理员干预，即所谓的“故障56切换(Failover)”。管理员需要提前在所有集群主备节点上部署集群软件，由集群软件控制文件系统的挂载，应用系统服务的启动，以及公网IP地址的配置。主备集群架构如下图所示：Active-Active集群的多个集群节点可以同时运行同一项服务，可同时对外提供业务访问。采用Active-Active集群，不仅可以和主备应用集群一样提升应用系统的可靠性，更可以做到故障的无缝切换，而且可以提升应用系统整体性能。当前最典型、应用最广泛的Active-Active集群，是OracleRAC(RealApplicationCluster)集群系统。OracleRAC集群是一种数据库集群，实现了多节点对数据库访问的动态负载分担。Active-Active集群架构如下图所示：57\uf06cOracleRAC双活设计OracleRAC以共享存储为基础，通过本方案存储层HyperMetro提供的双活LUN，实现各节点对数据文件、重做日志文件、控制文件和参数文件的并行访问，且在单个节点出现故障时，业务能自动切换到正常节点，从而保证数据库系统正常可用。HyperMetro的双活LUN技术提供共享卷，将跨数据中心的存储以共享方式提供给上层应用访问，满足OracleRAC的共享存储需求，实现跨数据中心的OracleExtendedRAC集群构建。OracleExtendedRAC集群配合Oracle监听器技术，可实现客户端在数据中心间业务双活访问和负载均衡；配合Oracle透明应用程序故障转移（TAF）技术，当服务器或单数据中心故障时，使客户端能够在新的连接中继续工作，防止业务中断。OracleRAC节点部署建议：在出现中间网络心跳链路故障时，OracleRAC会采用如下的原则进行仲裁：\uf0d8拥有最多节点数目的子集群（Sub-clusterwithlargestnumberofNodes）获胜。\uf0d8若子集群内数目相等则拥有最低节点号的子集群(Sub-clusterwithlowestnodenumber)获胜。建议OracleRAC采用“2+1”的部署方式，主数据中心部署2台服务器，同城双活中心部署1台服务器。保证在出现心跳链路故障时主数据中心的实例优先存活。若节点数一致，则建议部署时将节点号小的服务器部署在主数据中心。OracleExtendedDistanceCluster节点部署方式如下图所示：58OracleRAC服务部署建议：为了避免跨数据中心进行数据的交互，建议在OracleRAC层创建不同的service，实现业务分离。通过OracleRAC透明应用程序故障切换（TAF）的PREFERRED功能设置应用只访问本地实例；同时设置远端数据中心的实例为AVAILABLE，只有本地实例都故障才切换到远端实例。服务设置方式如下表所示：服务配置策略服务名INSTANCE1INSTANCE2INSTANCE3SERVICE1PREFERREDPREFERREDAVAILABLESERVICE2AVAILABLEAVAILABLEPREFERRED59其他建议：\uf0d8要实现Oracle数据库的跨数据中心的集群部署，需采用支持OracleExtendedDistanceCluster的Oracle版本。建议使用Oracle10g发行版2或更高版本。\uf0d8Oracle部署通常有三种存储管理方式：文件系统，裸盘和ASM，推荐使用ASM。\uf0d8对于OracleExtendedDistanceCluster配置，建议对OracleClusterware和Oracle数据库二进制文件和主目录进行本地存储，以减少站点间流量。\uf06cDB2双活设计方案采用IBMPowerHA/XD（IBMPowerHA/ExtendedDistance）集群实现DB2数据库的跨数据中心双活部署。PowerHA/XD（ExtendedDistance）是PowerHAforAIX的一个可选特性。支持将应用切换到远程站点的备份资源。PowerHA的目标是消除SPOF（SinglePointOfFailure），当两个服务器中的一个发生故障时，让另一个服务器接管。PowerHA集群技术通过提供冗余实现故障转移保护，同时通过并发/并行访问支持水平扩展。典型的PowerHA双机系统结构如下图所示：PowerHA为主备集群模式，在一个时刻只有一个节点可对外提供服务，从方案的成本与可靠性角度出发，建议部署两节点的PowerHA集群。60\uf06cSQLServer双活设计SQLServer数据库实现集群的方式主要是通过操作系统的集群实现，如WindowsServerFailoverCluster。WindowsMulti-SiteFailoverCluster允许将WindowsServerFailoverCluster集群的成员部署于不同站点。此次方案采用WindowsMulti-SiteFailoverCluster集群实现SQLServer数据库的跨数据中心双活部署。WSFC为主备集群模式，在一个时刻只有一个节点可对外提供服务，从方案的成本与可靠性角度出发，建议部署两节点的WSFC集群。如果一个集群节点或服务失败，则该节点上承载的服务可在一个称为“故障转移”的过程中自动转移到另一个可用节点。612.2.1.4.2.6分布式存储双活设计说明：\uf06c在两个站点提供两个FusionStorage集群来做双活存储容灾设计。容灾存储卷在两个站点同时支持读和写。\uf06c如果是写操作，系统接收到写请求时调用双写入操作，数据被直接发送到本地和远程FusionStorage集群；对于读请求，数据优先从本地FusionStorage集群读取。\uf06c对于如何来调度和仲裁两地的集群优先等级，FusionStorage支持两种模式：静态优先和第三地仲裁。静态优先可以设置一个主数据中心，默认由主数据中心提供业务支撑能力；仲裁机制是使用第三个站点（站点C）的仲裁服务来处理两个数据中心脑裂问题，根据一致性组支持仲裁和恢复。本次项目中国电信建议采用仲裁机制，可选择在某个合适的市/州数据中心部署仲裁。\uf06c解决将两个数据中心在相同卷与无锁的方式在同一地址写冲突。2.2.1.4.2.7集中式存储双活设计本方案采用华为集中式存储设备提供的HyperMetro作为存储双活实现方案。62各层面设计如下：\uf06c存储架构HyperMetro特性基于两套存储阵列实现AA(Active-Active)双活，两端阵列的双活LUN数据实时同步，且双端能够同时处理应用服务器的I/O读写请求，面向应用服务器提供无差异的AA并行访问能力。当任何一台磁盘阵列故障时，业务自动无缝切换到对端存储访问，业务访问不中断。相较于AP方案，AA双活方案可充分利用计算资源，有效减少阵列间通信，缩短I/O路径，从而获得更高的访问性能和更快的故障切换速度。下图展示了几种双活方案的交互流程。存储双活架构\uf06c跨站点集群两套独立的存储阵列组建成跨站点集群，并以跨站点集群为核心，提供双活存储架构，向应用服务器提供无差异的并行访问，处理应用服务器的I/O请求。双活跨站点集群配置过程极为简单，只需要将两套存储阵列配置成双活域，即可完成跨站点集群配置。跨站点集群系统使用阵列间FC或IP链路作为通信链路，完成全局节点视图建立和状态监控。在全局节点视图基础上，跨站点集群系统提供分布式互斥等能力，支持AA双活架构。下图为双活跨站点集群示意图。双活跨站点集群63集群节点具有并发访问能力。当出现单个控制器故障时，其承接的业务将被切换到本地集群的其它工作控制器；本地集群工作控制器全故障时，则切换至跨站点集群另一个本地集群。双活访问与切换在跨站点集群基础上，HyperMetro以双活Pair或双活一致性组为单位提供服务和进行状态管理。两套存储阵列上的双活成员LUN组成一个虚拟双活LUN，通过实时镜像技术保持两个数据中心的双活成员LUN的数据实时一致。一致性组是多个双活pair的集合，可以确保单个存储系统内，主机在跨多个LUN进行写操作时数据的一致性。一致性组进行分裂、同步等操作时，一致性组的所有双活pair保持步调一64致。当遇到链路故障时，一致性组的所有成员对会一起进入异常断开状态。当故障排除后，所有成员同时进行数据的同步，从而保证从站点灾备阵列数据的可用性。\uf06c跨站点数据实时镜像HyperMetro通过实时镜像功能，保证两个站点存储阵列之间数据的实时同步。主机写操作通过实时镜像技术同时写入两个数据中心的双活成员LUN，保持数据实时一致。具体的写I/O流程如图4-4所示。跨站点镜像假如数据中心A阵列收到写I/O，镜像处理流程如下：\uf0d8申请写权限和记录写日志：数据中心A阵列收到主机写请求，先申请双活Pair的写权限。获得写权限后，双活Pair将该请求记录写日志。日志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电保护能力的内存空间记录以获得良好的性能。\uf0d8执行双写：将该请求拷贝两份分别写入本地LUN和远端LUN的Cache。\uf0d8双写结果处理：等待两端LUN的写处理结果都返回。\uf0d8响应主机：双活Pair返回写I/O操作完成。HyperMetro支持断点续传功能。当某些故障场景（如单套存储故障）导致双活Pair关系异常断开时，HyperMetro通过记录日志的方式，记录主机新产生的写I/O。当故障恢复时，HyperMetro将自动恢复双活Pair关系，并且将所记65录的增量数据自动同步到远端，无需全量同步所有数据，整个过程对主机“透明”，不会影响主机业务。双活Pair运行状态和主机访问状态关系见下表。双活Pair运行状态主机访问状态状态描述主LUN从LUN暂停读写不可读写用户暂停双活镜像关系待同步读写不可读写阵列间链路故障或I/O错误导致双活镜像关系断开同步中读写不可读写恢复双活镜像关系时全量/增量同步双端差异数据正常读写读写两端LUN都进入双活AA实时镜像关系强制启动读写不可读写用户进行了强制将双活从LUN升级为主LUN的操作双活Pair运行状态和镜像状态关系见下表。双活Pair运行状态镜像状态主LUN从LUN暂停/待同步/强制启动不镜像，记录差异日志不涉及同步中镜像写，后台复制差异不涉及正常镜像写镜像写\uf06c跨站点坏块修复硬盘在使用过程中可能因为掉电等异常情况出现坏块，如果是可修复错误但是本端已经无法修复时，HyperMetro将自动从远端阵列获取数据，修复本地数据盘的坏块，进一步提高系统的可靠性。跨站点数据修复66数据中心A阵列出现坏块时，从该阵列读I/O处理流程如下：\uf0d8主机下发读I/O。\uf0d8读本地LUN。\uf0d8读取到坏块后，如果为可修复错误，执行步骤4，否则执行1、2后流程结束。\uf0d8重定向远端读。\uf0d8远端读返回。\uf0d8将读数据返回主机，确保主机响应的快速返回。\uf0d8根据远端的读数据，进行本地写入修复。\uf0d8写修复结果返回。\uf06c仲裁防脑裂当提供双活LUN的两套阵列之间的链路故障时，阵列已经无法实时镜像同步，此时只能由其中一套阵列继续提供服务。为了保证数据一致性，HyperMetro通过仲裁机制决定由哪套存储继续提供服务。HyperMetro支持按双活Pair或双活一致性组为单位进行仲裁。当多个双活Pair提供的业务相互依赖时，用户需要把这些双活Pair配置为一个双活一致性组。仲裁完成后，一个双活一致性组只会在其中一套存储阵列继续提供服务。例如，Oracle数据库的数据文件、日志文件可能分别存放在不同的LUN上，访问Oracle数据库的应用系统存放在另一些LUN上，相互之间存在依赖关系。配67置双活时，建议数据LUN、日志LUN和应用LUN分别配置双活pair，并且加入同一个一致性组。HyperMetro提供了两种仲裁模式：\uf0d8静态优先级模式\uf0d8仲裁服务器模式配置双活Pair前，需要配置双活域，双活域为逻辑概念，包括需要创建双活关系的两套存储阵列和仲裁服务器。每个双活Pair创建时均要选择双活域，每个双活域只能同时应用一种仲裁模式。仲裁服务器模式比静态优级模式具备更高的可靠性，可保证在各种单点故障场景下，业务连续运行。因此，本项目双活方案推荐采用仲裁服务器模式。1.静态优先级模式静态优先级模式主要应用在无第三方仲裁服务器的场景。用户可以按双活Pair或一致性组为单位，设置其中一端阵列为优先站点，另一端为非优先站点如图4-6所示，不需要额外部署仲裁服务器。该模式下，阵列间心跳中断时，优先站点仲裁胜利。当发生阵列间链路故障，或者非优先站点故障时，优先站点上的LUN继续提供服务，非优先站点的LUN停止提供服务。当优先站点阵列故障时，非优先站点不能自动接管双活业务，双活业务停止，需要人工强制启动非优先站点服务静态优先级部署68注意：有一种情况除外，当优先站点阵列主动下电维护时，非优先站点阵列立即接管所有双活业务，业务不会中断。该模式的缺点是：两阵列之间的心跳丢失时，可能是站点间链路丢失或其中一个阵列故障，系统无法区分这两种情况。下表为静态优先级模式下的仲裁策略。静态优先级模式仲裁示意图编号示意图仲裁结果1故障类型：链路故障仲裁结果：H1继续运行业务，H2停止业务2故障类型：非优先故障仲裁结果：H1继续运行业务，H2失效3故障类型：优先故障仲裁结果：H1失效；H2停止业务，需要人工启动2.仲裁服务器模式使用独立的物理服务器或者虚拟机作为仲裁设备，仲裁服务器建议部署在第三方站点，推荐选取省内某个合适的市/州数据中心，作为仲裁站点，部署仲69裁设备。这样可以避免单数据中心整体发生灾难时，仲裁设备也同时故障。如下图所示。仲裁服务器部署仲裁服务器模式下，当存储阵列间心跳中断时，两端阵列向仲裁服务器发起仲裁请求，由仲裁服务器综合判断哪端获胜。仲裁获胜的一方继续提供服务，另一方停止服务。仲裁服务器模式下如果有优先获得仲裁的要求，也可以配置站点优先级。优先阵列端具有仲裁获胜的优先权，心跳中断但其它正常时，优先阵列将获得仲裁胜利。仲裁过程如下图所示：仲裁机制\uf0d8数据中心之间的链路断开时，跨站点阵列集群分裂为两个小集群。\uf0d8小集群分别抢占仲裁，优先阵列将优先抢占仲裁，抢占成功的小集群“获胜”，将继续对外提供服务，为应用提供存储访问空间；抢占失败的小集群则停止对外服务。\uf0d8中间链路恢复时，两个子集群检测到中间链路恢复正常，经过握手通信将两个小集群自动组成一个跨站点集群，双活关系恢复，以Active-Active模式提供服务。70下表列出了仲裁服务器模式下，各种故障场景下双活业务表现。各故障场景仲裁示意图编号示意图仲裁结果1故障类型：仲裁失效仲裁结果：H1、H2继续运行业务2故障类型：一套阵列与仲裁之间链路故障仲裁结果：H1、H2继续运行业务3故障类型：一套阵列失效仲裁结果：H1失效，H2继续运行业务4故障类型：阵列间链路中断仲裁结果：H2失效，H1继续运行业务5故障类型：一套阵列与仲裁同时失效仲裁结果：H1失效，H2停止业务6故障类型：一套阵列与对端、仲裁的链路同时中断仲裁结果：H1停止业务，H2继续运行业务7故障类型：一套阵列失效，且对端与仲裁链路中断仲裁结果：H1失效，H2停止业务8故障类型：仲裁失效，且阵列间链路中断仲裁结果：H1与H2均停止业务9故障类型：仲裁失效，且其与一套阵列链路中断仲裁结果：H1、H2继续运行业务说明：H1和H2表示组成双活HyperMetroLUN的两个阵列，C表示对应的仲裁服务器。\uf06c强制启动某些特定的多重故障情况下，仲裁机制优先保证数据的一致性，可能会将存活的双活成员LUN都停止主机访问。例如静态优先级模式下优先站点故障等场景，存活的双活成员LUN会被停止主机访问，用户或售后工程师可根据故障71情况选择人工强制启动业务，快速恢复业务。强制启动后，被强制启动端会升级为双活数据同步源端，强制启动端的双活成员LUN具有最新数据。链路恢复后，系统主动停止对端双活成员LUN主机访问。发起数据同步时，将以强制启动端的双活成员LUN数据覆盖对端。该过程中只会同步增量差异数据。注意：执行强制启动前，需要充分考虑双主风险，应在执行前确认两个数据中心的LUN状态和业务状态，确保对端存储已经停止工作。\uf06c数据精简拷贝在双活镜像数据的初始同步或者恢复过程中的增量同步过程中，差异数据块通常有大量的零数据块，无需逐块复制，该功能叫数据精简拷贝。例如，虚拟化场景下，新建虚拟机时会产生大量的零数据块，一个数十GB的操作系统盘，实际非零数据块仅2-3GB。数据精简拷贝原理图如图4-9所示。数据精简拷贝HyperMetro零页面识别技术的实现方法如下：通过硬件芯片，对数据拷贝源端进行快速识别，找出零数据，在拷贝过程中，对全零数据特殊标识，只传输一个较小的特殊页面到对端，不再全量传输。该技术可有效减少同步数据量，减少带宽消耗，缩短同步时间。FastWriteHyperMetro通过FastWrite功能对阵列间数据传输进行了协议级优化，应用SCSI协议的FirstBurstEnabled功能，将写数据的链路传输交互次数减少一半。正常的SCSI流程中，写I/O在传输的双端要经历“写命令”、“写分配完72成”、“写数据”和“写执行状态”等多次交互。利用FastWrite功能，优化写I/O交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，将跨站点写I/O交互次数减少一半。如下图所示。传输协议优化\uf06c地域优化访问双活数据业务场景，两站点的距离远近，是影响I/O访问性能的关键因素。HyperMetro特性通过与华为OceanStorUltraPath多路径配合，根据双活站点部署距离，提供了两种I/O访问策略供用户选择。\uf0d8负载均衡模式\uf0d8优选阵列模式1.负载均衡模式该模式下实现了I/O的跨阵列负载均衡，即I/O以分片的方式在两个阵列上下发。分片大小可配，例如分片大小为128M，即起始地址为0-128M的I/O在A阵列下发，128M-256M在B阵列下发，以此类推。负载均衡模式主要应用于双活业务部署在同一数据中心的场景。在该场景下，主机业务访问两套双活存储设备的性能几乎相同，为最大化利用两套存储设备的资源，将主机I/O按分片方式下发到两套阵列上。负载均衡访问732.优选阵列模式该模式下，由用户在OceanStorUltraPath上指定优选访问阵列，主机业务访问时，I/O只会在用户设置的优选阵列路径上进行负载均衡下发，不产生跨阵列的I/O访问。只有当优选阵列出现故障时，才切换到非优选阵列下发I/O。优选阵列模式主要应用于双活业务部署在距离较远的双数据中心场景。在该场景下，双活数据中心的跨站点访问的代价较高，假如两个数据中心的链路距离为100km，一次往返传输通常需要消耗约1.3ms时间。优选阵列模式可以减少跨站点交互次数，从而提升I/O性能。针对数据读场景，双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，避免主机跨数据中心读取数据，提升整体访问性能。优选阵列模式数据读74针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据，充分利用HyperMetroAA双活能力，AA集群的每个控制器都能够接收写I/O，由本地控制器处理本地主机的写I/O请求，减少跨数据中心的转发次数，提升方案整体性能。数据写I/O过程如下图所示。优选阵列模式数据写752.2.1.5异地灾备方案本同城双活架构支持平滑升级。无需改造生产系统，只要在异地灾备数据中心部署相应集中存储、分布式存储，并创建和双活数据中心匹配的备份卷，建立双活数据中心共享卷和异地灾备中心备份卷的远程复制管理，即可平滑升级到两地三中心灾备架构。通过两地三中心的建设，省级电子政务外网数据中心的灾难恢复能力达到“信息系统灾难恢复规范”国家标准GB/T20988-2007的6级，即RTO为数分钟，RPO为0，部分业务RTO可以达到0的水平。2.2.1.6系统整体切换方案双活数据中心在各单部件和链路故障，甚至整个数据中心故障，都可以实现业务自动无缝切换。以下列举各种故障场景的连续性分析：762.2.1.6.1GSLB故障两站点各部署一台GSLB，一个数据中心中只需配置一台。上级DNS通过轮询方式保证第一台GSLB故障时其他的GSLB可以接替工作。GSLB故障-数据流向示意主数据中心的GSLB故障，原来用户继续使用主数据中心的Web服务器访问，业务正常运行，如下描述新用户的访问情况，处理过程如下：\uf0d8新用户发起访问前，查询该域名的DNS。\uf0d8主数据中心的DNS服务器通过轮询方式，发现主数据中心的GSLB故障，访问同城双活数据中心的GSLB，同城双活数据中心的GSLB根据负载均衡策略返回主数据中心的SLB群集的IP地址给用户。\uf0d8新用户根据IP地址发起访问。本地主数据中心的GSLB故障恢复后，上级DNS将访问同城双活中心的77GSLB，上层业务无影响，负载均衡策略不变。2.2.1.6.2SLB故障主数据中心和同城双活中心每个站点部署两台SLB，组成双机HA集群，自动同步集群各节点的配置信息，确保所有节点配置文件的一致性；两站点各部署一个集群，各自独立。站点内一台SLB故障站点内一台SLB故障-数据流向示意图主数据中心内SLB主节点故障，处理过程如下：\uf06e主数据中心内部SLB备节点接管VirtualServerIP。\uf06e客户端将HTTP请求依然发至SLB的VirtualServerIP。\uf06eWeb服务器和应用服务器仍然照常工作，不受影响。主数据中心的SLB故障恢复后，SLB自动重组HA集群，客户端仍然访问SLB的VirtualServerIP，上层业务无影响，单个客户的HTTP会话能够保持。78站点内两台SLB故障站点内两台SLB故障-数据流向示意图站点内两台SLB故障，处理过程如下：\uf06e新用户发起访问前，查询该域名的DNS。主数据中心的DNS服务器接收到域名解析请求后，访问主数据中心本地的GSLB。\uf06e主数据中心本地的GSLB探测到本地两台SLB都已经失去响应，将同城双活中心SLB的IP返回给客户端。\uf06e客户端将HTTP请求发送至同城灾备中心SLB的VirtualServerIP。\uf06eWeb服务器和应用服务器仍然照常工作，不受影响。主数据中心的SLB故障恢复后，SLB自动重组HA集群，客户端仍然访问SLB的VirtualServerIP，上层业务无影响，单个客户的HTTP会话能够保持。792.2.1.6.3Web服务器故障在主数据中心和同城双活数据中心的虚拟化群集分别部署多台Web服务器，各自创建为一个集群。由本地的SLB创建一个pool（负载均衡池），将站点内的所有Web服务器组成一个资源池。这样分别创建主数据中心资源池和同城双活数据中心资源池。站点内所有Web服务器故障站点内所有Web服务器故障-数据流向示意图假如站点内所有Web服务器故障，处理过程如下：\uf0d8主数据中心的Web服务器对外的IP将无法访问，无法提供服务。\uf0d8主数据中心的SLB探测到所有IP均无法访问，SLB的http检查失败。\uf0d8GSLB检测到SLB的http故障，修改负载均衡策略，分流业务到数据同80城双活数据中心的SLB。\uf0d8客户端将HTTP请求发至SLB的VirtualServerIP。\uf0d8SLB查询不到上次处理该会话的Web服务器，分发至同城双活数据中心的一个Web服务器。\uf0d8新Web服务器查询不到故障节点的会话信息，客户Session将丢失，要求客户重新登陆。\uf0d8连接同城双活数据中心的客户业务正常运行；连接主数据中心的客户HTTP会话不能保持，客户重新登陆。主数据中心的Web服务器故障恢复后，SLB检测到后自动加入资源池，上层业务无影响，单个客户的HTTP会话能够保持。2.2.1.6.4数据库故障以oraclerac为例OracleRAC故障示意OracleRAC建议采用“2+1”的部署方式，数据中心A部署2台服务器，数据中心B部署1台服务器：如果数据中心A的1台Oracle服务器故障，数据中心A内OracleRAC单个数据库服务器故障，业务不切换到数据中心B，业务在DCA内的另外一个数据库服务器上运行。如果数据中心A的2台Oracle服务器故障，数据中心A内所有OracleRAC数据库服务均短暂悬挂，随后，业务自动切换到数据中心B的数据库服务器上81继续运行。故障恢复后，数据库服务器故障修复后，自动加入集群，无需人工干预。2.2.1.6.5存储故障存储故障示意-数据流向图当一个数据中心存储故障时，业务I/O自动切换到另一数据中心的存储处理，业务无中断。假设主数据中心的一套存储故障，处理过程如下：\uf06e主数据中心存储主动下电，自身发送命令至同城双活数据中心阵列，告知其接管业务。\uf06e主数据中心存储同时停工所有双活LUN。\uf06e多路径置所有至主数据中心阵列的路径为不可用，所有I/O直接转发送同城双活数据中心存储。\uf06e同城双活数据中心存储对新接收I/O记录差异位图。主数据中心的存储恢复上电后，双活关系自动恢复，根据差异位图盘的记82录自动同步新增数据，上层业务无影响。2.2.1.6.6站点间链路故障站点链路故障示意-数据流向图主数据中心和同城双活数据中心网络包括业务数据同步网络、阵列心跳网络和OracleRAC私有网络，当同城网络故障时，两个数据中心的阵列均发现心跳中断，设置为优先的阵列抢占仲裁成功，接管所有的业务，另一套阵列停止提供业务，数据库同时发生仲裁，由于只有一个数据中心能提供LUN供读写，业务自动切换至该中心。详细处理过程如下：\uf06e同城网络链路故障，阵列检测到心跳网络链路故障，阵列开始抢占仲裁。83\uf06e如果主数据中心的阵列仲裁抢占胜利，同城双活数据中心的阵列停工所有双活LUN。\uf06e阵列将该同城双活数据中心的LUN状态置为不可用，阵列双活关系故障。\uf06e对于Oracle来说，同城双活数据中心的服务器到主数据中心的阵列链路故障，业务I/O不能正常访问，同城双活数据中心的数据库服务自动切换到主数据中心。\uf06e同城双活数据中心的Web和应用服务器无法访问数据库。\uf06eGSLB的健康检测发现Web和应用服务器出现异常，修改负载均衡策略，不分发到同城双活数据中心。2.2.1.6.7站点故障站点故障示意当一个数据中心发生停电或火灾等灾难时，另一个数据中心阵列抢占仲裁84胜利，接管所有的业务，业务自动切换。详细处理过程如下：\uf06e主数据中心故障，同城双活数据中心的阵列检测到心跳网络链路故障，阵列开始抢占仲裁。\uf06e由于主数据中心故障，主数据中心阵列无法抢占仲裁磁盘，同城双活数据中心的阵列抢占仲裁成功。\uf06e同城双活数据中心的阵列无法访问到主数据中心阵列，阵列将主数据中心阵列的LUN状态置为不可用，阵列双活关系故障。\uf06e对于Oracle来说，主数据中心的服务自动切换到同城双活中心。\uf06e同城双活数据中心的Web和应用服务器无法访问数据库，。\uf06eGSLB的健康检测发现Web和应用服务器出现异常，修改负载均衡策略，不分发到主数据中心。85',)