容灾体系

容灾体系（精选七篇）

容灾体系 篇1

在竞争日趋激烈的今天, 网络质量也越来越成为运营商关注的生命线, 而在移动交换网络中, MSC、HLR、MGW又是影响网络质量的重中之重, 其稳定性直接关系着几乎所有移动业务的正常使用和用户感知。

核心网络的长期稳定运行是打造优质网络的根本所在, MSC-S、HLR、MGW是移动通信网络中最重要的核心设备, 它不仅是通信业务主体话音业务的处理层, 也是智能业务、SMSC等移动增值业务的承载层, 因此其稳定性直接关系着各项移动业务的正常开展和用户的直接感知。

2 解决方案

随着MSC IN POOL技术、HLR容灾技术、BSC双联技术的逐步成熟, 2009年廊坊移动率先利用HLR容灾技术在全省第一个实施了HLR容灾部署, 在一个HLR出现故障时, 系统会将故障HLR的功能自动倒换到配对的HLR, 减少了对客户的影响, 因而也进一步提高了我公司网络运行的安全性和稳定性。2010年在廊坊实施了MSC IN POOL方案, MSC IN POOL为网络提供MSC-S冗余备份功能, 当Pool内某个MSC-S出现故障的时候, 所有的话务将自动均衡地分摊到Pool内其它网络节点上, 降低了重大故障发生率。2011年在集团公司的统一部署下, 廊坊完成了BSC双联MGW, 实现了MGW的容灾。

2.1 HLR容灾机制

爱立信HLR容灾技术采用的是1+1动态数据备份方式, 当HLR1和HLR2互为备份时, HLR1中的用户成为主用用户, 正常运行时, 用户位置等数据通过HLR1和HLR2之间的信令实时的备份HLR2中, 称为备用用户。反之HLR2中的主用用户也会备份到HLR1, 如果HLR1出现故障, 会自动倒换到HLR2, 实现对客户的不间断服务。提高了HLR核心网的安全性。

2.2 MSC-S容灾机制

MSC池技术并不是单纯的网络容灾备份方案, 但是MSC池技术确实能够在遵从3GPP标准规范的前提下有效地提升核心网的安全性能。

当MSC池中的某个MSC发生故障时, 原来由该MSC所控制的用户一旦有业务请求时, 马上会被池内的其它MSC实时自动地接替工作, 成为该用户新的主控MSC。在这一过程中, 由于MSC池技术采用了真正意义上的实时自动的网络级冗余安全机制, 因此不需要任何操作, 对用户来说没有任何感知, 就可以自动实现无线网不变、位置区不变、核心网重选的过程, 使得网络服务的零中断时间成为可能。

此外, 由于MSC池技术是由池内仍然正常工作的多个网元来分担故障网元的话务负荷, 而不像其它备份方式那样仅仅由一个备份节点来承担故障网元的话务负荷, 因此MSC池备份方式不会造成故障传递引起的“雪崩效应”。而且MSC池内的各个MSC都是动态的互为备份的关系, 不需要再单独投资设置一个备份节点, 正常情况下也没有容量的浪费。

2.3 MGW容灾机制

在MSC IN POOL之后, 一个BSC仍然是连接至一个MGW, 如果POOL内某一个MGW发生宕机故障, 则该MGW下的BSC仍将断掉所有连接, 信令及话务受阻。

由拓扑图可以看到, 双联之后每个BSC都连接了两个MGW, 信令话务被平均分配到两个MGW, 实现了MGW的冗余备份。如果MGW1发生宕机故障, 会影响到BSC1/2/3/4内已建立的部分通话。对于BSC1/2/3/4中的新的通话则会通过MGW2来实现, 不会因MGW造成BSC退服。

3 结论

随着MSC-S、HLR、MGW容灾方案的部署, 大大提高了核心网设备的安全性。GSM应急容灾体系是动态、实施的进行数据备份, 缩短系统恢复的时间, 真正体现了应急的概念。在提升网络安全的同时, 也优化了网络的其它指标, 例如MSC IN POOL之后, 由于减少了MSC间的切换和位置更新, 降低了MSC和HLR之间的信令负荷, 也降低了HLR的负载。

摘要：随着MSCINPOOL技术、HLR容灾技术、BSC双联技术的逐步成熟, 廊坊移动在集团公司的统一部署下, 现已完成了BSC双联MGW, 实现了MGW的容灾。本文就解决方案展开分析, 并作出相关经验总结。

关键词：软交换,HLR,MGW应急容灾

参考文献

[1]陆逊.浅论HLR的容灾备份[J].中国新通信, 2009 (2) :77-80.

徐州电力通信网容灾体系建设 篇2

电力通信网是支撑电网安全稳定运行和电力企业管理信息化的重要组成部分。为了防止自然灾害和突发事件对电网调度及自动化的影响,保证电力通信网运行的可靠性和稳定性,满足徐州电网调度生产需求,保障通信网络所承载调度信息数据业务的安全、可靠、高效传输,提高通信网在自然灾害和突发事件时的业务支撑和保障能力[1,2],徐州电力通信网“十二五”规划中重点提出了容灾建设需求,并按照项目计划逐年落实[3]。依据原有通信网资源,对徐州电力通信传输网、业务网、支撑网的网络结构、设备配置、通道组织等进行相应的改造、调整和优化,形成逐级双汇聚、双上联的高可靠电力通信网络容灾体系构架,可确保在主调节点失效的情况下通信网络路由能够无间隙地切换至备调,实现电网调度生产、应急指挥、数据信息等业务的有效传输[4,5]。

1 徐州电力通信网现状

1.1 原有通信网运行情况

徐州地区电力通信网经过组网建设和通信网络技术演进,至2015年已形成了市到县汇聚层和城域/县域接入层的两级光通信传输网络,市县电力通信网具有A网、B网2个独立的环网,主要采用SDH/MSTP的技术模式,实现了徐州电网区域范围内所有电力调度机构、500 k V至35 k V变电站的双路由全覆盖。

地区汇聚层传输网采用华为、中兴通信设备建成A、B双网。汇聚层A网采用东西环相交结构,光路选择主要依托500 k V和220 k V光纤复合架空地线(Optical Fiber Composite Overhead Ground Wire,OPGW)光缆路由,10 G东、西主环在中心站和500 k V三堡站相交,覆盖500 k V变电站和地区调度中心站,县调中心站采用2.5 G支路环网方式双路由接入就近的500 k V或220 k V变电站。汇聚层B网为10 G单环网,覆盖地区调度中心站和各县调中心站节点。

市区城域和县域接入层传输网采用2.5 G主环下接入多个622 M支环的拓扑方式。徐州市区城域接入网分别采用华为和朗讯设备,建有1个主环,下接9个支环,调度数据网第一平面、调度电话等业务汇聚至中心站,调度数据网第二平面汇聚至500 k V三堡站内。六县各区域接入网采用华为和中兴设备,分别建有6个主环,下接多个支环,各区域业务汇聚至县调中心站。

徐州市县通信A网拓扑(优化前)如图1所示。

1.2 存在的问题

1)传输网业务汇聚点存在单点故障隐患。汇聚层光传输汇聚点只有单套设备在地调中心站,接入层光传输网虽然在中心站采用双设备汇聚,但双设备处于同一机房,只有一个物理汇聚点,均存在单点故障风险。由于通信网承担的数据业务(调度数据网、调度交换网、信息综合数据网等业务)为集中型业务,均在地调落地,在地调失效的情况下将造成上下级互联业务全部中断。

2)地区备调的建立对传输网提出了新的业务需求。至2011年底,徐州电网运行有500 k V变电站5座、220 k V变电站28座、110 k V变电站98座、35 k V变电站89座,根据电网调度要求需在沛县公司设置独立的地区备调。地区通信网需要适应此要求,在实现所有调度业务传送至徐州主调的同时,能够有效、可靠地传送至沛县备调。

3)县调中心站存在单点接入隐患。地区汇聚层传输A网中各县调通过支环方式接入500 k V或220 k V站点,虽然光缆采用双路由,但仍然存在单点故障隐患。当上联的500 k V或220 k V站点失效时,相关的县调至地调的业务将全部中断。500 k V姚湖变、岱山变是地区级重要通信节点,基建时采用朗讯传输设备,厂家已停止生产,设备故障后相应板卡不能及时恢复,无法满足运行要求,亟需对设备进行改造。

4)沛县备调不具备地区级调度交换系统调度台。徐州地区调度交换网建设有徐州地调和500 k V三堡变2个汇聚节点,各县调和500 k V变电站调度交换机采用2 M中继和IP中继的方式分别与2个汇聚节点连接,当第一汇聚点徐州地调失效时仍可通过第二汇聚点三堡变或环网IP中继方式与上级调度交换机通信。在徐州地调中心站内布置了第一汇聚点交换机数字调度值班台和第二汇聚点交换机放号的单机设备,实现主备独立路由与上下级调度通信。但作为地区备调的沛县公司不具备地区调度值班台,需要在容灾建设中增加功能。

2 徐州电力通信网容灾体系建设

徐州电力通信网容灾体系建设主要包括通信网第二汇聚点的选址和建设,汇聚层传输网、调度交换网、调度数据网、综合数据网、传输网管的改造、调整和优化,以及各类业务的通道组织、相关设备配置等。

2.1 地区汇聚层传输网方案

2.1.1 第二汇聚点的选择

按照电力通信网容灾体系建设要求,通信网需合理设置第二汇聚点,在主调失效时第二汇聚点可实现调度信息的可靠传输。第二汇聚点应优先考虑光缆资源丰富、便于同其他通信节点相连和汇聚业务、便于连接至上级通信网并与第一汇聚点保持适当距离的站点[6,7]。

徐州地区通信网汇聚层第二汇聚点选择沛县备调,一方面是因为此站点地理位置位于徐州地区,与徐州地调距离55 km,距离适当,原有市县传输A、B网已覆盖此站点,此站点具备合理的通道资源,便于组网。另一方面,沛县备调是徐州地区调度数据网、通信数据网及信息综合数据网核心层站点,也是调度自动化系统灾备数据中心,各类业务便于落地和上传,机房环境及电源配置良好,调度部门24 h值班,便于巡视和进行故障处理,故选择沛县备调作为地区通信汇聚层传输网的第二汇聚点。

2.1.2 汇聚层传输网拓扑演进

根据容灾体系双汇聚的要求,结合已选定的第二汇聚点,2012年开始逐步对地区汇聚层传输A网进行升级改造和拓扑调整。2011年的徐州地区汇聚层传输A网拓扑(见图1)采用2.5 G东西环相切结构,汇聚点只有徐州地调中心站,500 k V姚湖变、岱山变、220 k V孟楼变、闫集变、红卫变、庆安变等重要节点未接入东西主环,而是通过支环接入。

2012年至2013年期间,利用徐州地区东、西部电网OPGW光缆通道资源丰富的优势,将孟楼变、闫集变等节点调整到西环主环上,将姚湖变、岱山变、红卫变、庆安变、吴邵变等重要节点调整到东环主环上(东环引入ASON技术,建立了地调中心站至任庄变、岱山变、姚湖变、三堡变的2.5 G ASON光路),大大提高了市县A网环网的运行可靠性;在地调中心站新配置了1套汇聚设备,形成东西两环相交拓扑,并将具有主备关系的业务通道进行调整和割接,分别承载在2套设备上,2套设备形成传输对等、业务分担的状态,暂时缓解了第一汇聚点单设备故障隐患。2012年徐州通信网完成了10 G容量的地区汇聚层传输B网建设,覆盖了各供电公司中心站,主要开通了调度数据网一平面、通信数据网、信息综合数据网等市到县汇聚业务[8]。徐州市县通信B网拓扑如图2所示。

根据通信网“十二五”规划要求和容灾体系建设项目进度计划,徐州公司在2013年对汇聚层传输A网进行了升级改造,建设了沛县备调第二汇聚点设备;将东西两环第二相交点拓扑位置调整到沛县备调,将220 k V闫集变、孟楼变调整到西环网汇聚点上,升级东、西主环容量至10 G,增加业务承载能力,选取220 k V闫集变为沛县公司容灾点,选取220 k V孟楼变为丰县公司容灾点,220 k V红卫变为邳州公司容灾节点,220 k V吴邵变为铜山公司容灾节点,220 k V庆安变为睢宁公司容灾节点,500 k V姚湖变为新沂公司容灾节点,并将原汇聚层主网上的220 k V桃园变、潘家庵变调整到城区接入层支环网中;同时为了加强整个网络的运行管理,在灾备县(沛县)增加了1套网元级网管系统。

江苏省主干通信网第一汇聚点为江苏省调,第二汇聚点为镇江备调,目前省干苏北北环网覆盖了徐州地调和三堡变。徐州地调通过省网设备业务直接落地,区域内网与省干网设备互联实现与江苏省调及镇江备调的通信,沛县备调目前可通过三堡变省网设备实现与江苏省调及镇江备调的通信。江苏省电力公司2014年已建成了省干光传送网(Optical Transport Network,OTN),其中主网覆盖徐州地调、备网覆盖徐州地调及沛县备调,主备网之间多路由互联。结合2013年徐州城域、县域接入网第二汇聚点建设和拓扑优化,建成后将全面实现省—地—县通信网双汇聚、双上联的容灾体系[9]。

2.2 城域/县域接入层传输网拓扑优化

徐州市区城域接入网至“十二五”末建成2个两两相交的10 G主环,支环10余个。传输节点超过70个,网络规模较大。按照容灾体系建设要求,考虑到业务断面流量大和单点汇接能力有限,采用相交双环组网,拓扑结构清晰、简洁,且一个环中的节点故障不会影响到另一个环,极大地增加了网络的安全性。在17个站点配置10 G光传输设备,以徐州公司、三堡变为相交点组建10 G SDH/MSTP相交双环光传输网络,地区汇聚网设备与城域接入网设备互联,提高了通信网的安全可靠性[10]。

县域接入网第一汇聚点为县调中心站,第二汇聚点为与县调距离适当的1个220 k V变电站,其特点是光缆资源较为丰富且便于组网、机房环境良好、电源配置规范。县域通信网主环相交点为县调和220 k V站第二汇聚点,汇聚点站内接入网设备与地区汇聚层A网设备互联,实现调度电话、调度数据网、综合数据网业务与地调和备调的互通[11]。优化后的徐州市县通信A网拓扑如图3所示。

2.3 业务网组织架构优化

2.3.1 调度数据网

调度数据网部署的原则为实现主、备调度自动化系统能分别以双平面通道接入全部厂站,同时能够实现主、备用调度自动化系统任一单平面网络故障时不影响系统正常运行,以达到容灾要求[12]。

2.3.2 调度数据网容灾体系优化

调度数据网容灾优化方案为:每个县域及城域110 k V、35 k V变电站配置2台数据网设备,分别通过数字2 M方式与通信网连接,2个传输通道需要通过不同的传输路由至调度数据网主、备核心路由器[13]。

1)调度数据网主用系统。在区域县调或城域通信中心站,通信设备和数据网路由器分别配置1块155 M光板,通过CPOS方式实现互联,路由器采用100 M接口通过市县通信B网将信息传输至徐州自动化中心站骨干路由器,与省市自动化第一平面节点互联。

2)调度数据网备用系统。在城域220 k V汇聚节点,数据网设备及通信设备分别配置1块155 M光板,通过CPOS方式实现互联,汇聚路由器采用CPOS方式分配固定时隙,下联至区域内调度数据网设备,同时捆绑4×2 M带宽,上联至地区第二汇接点,上、下联共用155 M光路带宽资源,在区域灾备节点第二汇接点核心路由器至徐州城区及各县220 k V汇聚点采用4×2 M通道互联,经汇聚层传输网A网传输至城区及各县220 k V汇聚点,上行通道经站内转接后通过地区汇聚层A网传输至三堡变500 k V汇聚点,再通过省骨干网传输至江苏省调。徐州地区调度数据网容灾系统示意如图4所示。

2.3.3 调度交换网优化

徐州地区调度电话交换网采用Q信令和2 M数字中继组网,以徐州地调交换机为第一汇接点,三堡变调度交换机为第二汇接点。两汇接点在分别上联江苏省调和镇江备调汇聚交换机的同时,能够向下分别与各县调及500 k V变电站交换机互联;徐州地调、三堡变、任庄变、岱山变、姚湖变和沛县县调、邳州县调、睢宁县调、铜山县调、新沂县调、丰县县调通过2 M组网,同时徐州地区IP数据网与区域内各节点通过IP互联,满足调度交换网容灾要求[14]。徐州调度交换网容灾系统示意如图5所示。

因调度交换机2 M通道承载于地区汇聚层传输A网,随着A网的完善,2 M通道的运行可靠性将进一步提升,调度交换机容灾保障能力也将得到提升。同时,在沛县备调安装1套地区级数字调度交换机,并配置1部第一汇接点放号的单机设备,可充分保障沛县备调在主调失效时的调度能力。

2.3.4 综合数据网优化

徐州地区综合数据网于2013年建成,覆盖地区内县调、变电站、乡镇供电所、营业厅等站点,综合数据业务也已接入到市到县传输网B网,徐州市公司至各县公司采用GE光口互联,由于是单环结构,不能抗多点故障,可靠性较低。2014年底完成了市到县汇聚层A网的优化改造,实现了网络和通道的冗余。为提高运行可靠性,又对信息数据网络主备网节点间互联通道进行了优化,主网通道复用在市到县传输网B网上,备网通道复用在市到县传输网A网上。地区信息网任一节点失效都不会影响该点综合数据业务的上联[15]。

徐州地调核心路由器、沛县备调核心路由器分别与江苏省调、泰州备调(江苏省信息数据容灾备份中心设在泰州地调)实现业务上联,省级综合数据网为环状主备网结构,徐州地调节点位于主环上,拓扑方向分别连接至南京和淮安,实现与省公司主调和泰州备调的数据双汇聚、双上联。

2.4 传输网管系统完善

2012年,徐州电网已建成华为光传输网集中网管系统,网管服务器统一部署在徐州地调,各县调以终端方式登录服务器进行系统监视和控制。为满足容灾要求,首先增加了网管服务器设备,实现服务器主备冗余配置,2014年在沛县备调机房设置了网管备份系统,通过专线IP通道互联实现了与徐州地调的数据同步,形成了地区级传输网管系统主备异地容灾方式。江苏省已开展通信全省集中调控工作,省调采用TMS系统对全省设备进行统一监视和管理,徐州地调网管系统信息已接入TMS系统,沛县备调备份网管系统可以同时接入省级TMS系统,进一步提高了徐州地区网管系统运行可靠性。

3 需进一步完善的工作

3.1 地区汇聚层传输网光缆路由需进一步优化

虽然徐州地区电力光缆资源比较丰富,但随着传输网结构的不断复杂化,对光缆路由的需求不断增加,如汇聚层传输网县调中心点出局方向至少4个以上,但目前县调都不能达到各光缆路径完全独立、相互独立出局的要求;县域跨境光缆主要依赖500 k V或220 k V线路OPGW光缆,光缆路由冗余度不足,部分县域跨境传输段汇聚层传输A、B网光缆运行在同一条光缆上(如中心站至翟山变光缆),当该光缆故障时会导致A、B网同时开环,可靠性明显降低。针对这种情况,在今后的通信网建设中还需高度重视电力通信光缆的建设,并对在运的光缆路径进行优化,减少同方向光缆同塔、同沟敷设。

3.2 厂站调度数据网双平面路由未完全分离

220 kV及以下厂站调度数据网一、二平面站内信息向上传输依赖于单一传输设备,而且部分站点通道板卡无备用,当该设备故障时通道不能及时修复,造成双平面调度数据网信息全部中断。根据通信“十三五”规划,将在220 k V变电站建设中增加第2套光传输设备,逐渐解决路由未完全分离的问题。

4 结语

容灾体系 篇3

早期的容灾模式中, 很多时候将信息系统的高可用性看成产品质量问题的孤立事件, 试图单纯依赖软硬件产品质量的提升来改进系统的可用性。据专业机构的调查显示, 超过40%的系统故障是由人为因素造成的, 40%系统故障是由于不良的系统架构所导致, 直接源于软硬件设备失效的系统故障不到总量的20%。此外, 大部分业务规划缺乏明确的信息系统可用性目标, 仅通过对软硬件系统可用性指标的简单叠加来设计可用性计划, 而非通过正确的方法、规范的流程来规划和实施高可用性建设。

众所周知, 容灾高可用是一项复杂、艰巨而又意义深远的工作。作为一种全新的4G技术, TD-LTE在高速推动与发展的同时, 对支撑系统的可靠性提出新的挑战, 需要新的思路、新的方法、成熟的产品和全局规划来共同实现。网管LTE业务层面主要表现为省部接口数据上报和本地报表系统呈现。省部接口上报业务是通过省部接口程序从数据库提取数据, 通过MQ消息队列向移动集团网管上报实时LTE性能数据;本地报表系统是通过报表系统从数据库是获取LTE的业务数据提供分析。

针对早期容灾模式存在的局限性, 创造性地提出了基于容灾架构的LTE高可靠网管体系统, 首次提出容灾保护级别, 使得以前在一个机房保护机制变成不同机房之间关联容灾机制, 对企业网管业务高可靠建设及运维管理来说, 都进入新的模式, 新机制, 在为企业带来业务高可用的同时, 也为客户满意度和企业效益的同步提升具有重要影响。

1 基于容灾架构的LTE高可靠网管体系统

1.1 建设思路与效果呈现

基于容灾架构的LTE高可靠网管体系, 主要建设工作体现在:

(1) 建立城域SAN网络:新旧机房的SAN网络传输带宽主要取决于旧机房存储磁盘的读写, 中间传输带宽由4条8GB光纤传输通道构成。通过烽火和华为传输设备搭建起城域SAN网络。城域SAN网络的构建, 不仅提供了当前业务容灾, 更为后期扩大业务容灾范围打下基础。

(2) 注重能力提升, 强化业务变革, 即:由局限于使用单独机房的IT资源到可以跨地域使用不同机房的IT资源;具备业务系统平滑上线、下线、在不同的机房间使用IT资源的能力;由存储资源不足限制业务增长到相对充足的存储资源提供业务支撑、甚至数据冗余;跨地域的存储云架构, 具备了数据在线迁移、业务连续性等重要能力。

(3) 强调双机高可用保障, 这里包括如下几项:1数据库主机故障, 保障流程为:高可用双机软件判断来自系统的故障信息, 如数据库异常、硬件故障, 触发切换;故障节点依次为停止数据库、卸载文件系统、卸载浮动IP、停止卷、导出磁盘组;备用节点依次为导入磁盘组、启动卷、挂载文件系统、启动浮动IP、启动数据库;整个故障修复过程无需人为干预, 可在5min之内自动完成;Java管理界面, 操作简单直观, 故障切换过程可视化。2MQ、接口程序主机故障, 保障流程如下:高可用双机软件判断来自系统的故障信息, 如程序异常、主机硬件故障, 触发切换;开发的应用程序会进行轮询, 若发现程序异常, 它会触发VCS高可用软件进行主机硬件状态检查, 若硬件状态正常, 开发应用程序重启脚本尝试应用重启, 重启脚本最大尝试3次, 若不能正常则返回101给VCS, 集群软件直接切换给备机;故障节点依次为停止数据库、卸载文件系统、卸载浮动IP、停止卷、导出磁盘组;备用节点依次为导入磁盘组、启动卷、挂载文件系统、启动浮动IP、启动数据库;整个故障修复过程无需人为干预, 可在5min之内自动完成;Java管理界面, 操作简单直观, 故障切换过程可视化。

(4) 测试全专业综合告警拓扑系统, 能够正常查看相关拓扑数据;新建流水视图、选择过滤器、流水视图正常加载且有数据呈现;新建查询视图:正常选择过滤器, 正常同步历史数据。正常登录系统, 数据正常呈现。

1.2 主要创新点

基于容灾架构的LTE高可靠网管体系统, 主要具有如下创新点:

(1) 从业务高可用方面入手, 结合网管实际情况, 首次提出了重点业务跨机房容灾理念。将关键业务LTE首次保护机制延伸到备用机房。由于镜像的基本原理决定, 生产中心的存储与容灾中心的存储在写数据时不存在主从关系, 因此无论哪一个阵列因故停顿, 都不会导致数据的读写发生停顿, 可以做到数据容灾意义上的“零”停机。其意义不是单纯的通过“零”停机保障了业务的连续性, 并且避免了由于存储非正常停机带来的巨大的数据一致性风险, 而数据一致性风险是导致长时间业务停顿的主要因素。

(2) 彻底解决以前系统故障时恢复难度大、故障处理时间长、数据丢失等问题。由于同时采用VCS+SF容灾技术完全自动实现了零停机时间和零数据损失。当生产发生阵列级故障时, 零停机、零切换:基于镜像的原理, 镜像中的任何一个磁盘阵列出现问题停顿时, 都不会导致应用中断。容灾软件自动识别增量数据, 恢复周期短。从而使容灾的效果能够达到无缝的数据高可用性。当发生主机故障时, 双机软件会自动触发切换, 对业务系统的高可用性提供了保障。

(3) 解决以前双机管理复杂, 技术门槛高, 任何检查操依赖厂家工程师的问题。Java管理界面, 操作简单直观, 故障切换过程可视化。由于综合解决方案统一考虑了系统层面、应用层面、磁盘阵列层面, 链路层面、逻辑错误层面故障、在解决方案设计和产品设计上都做出了突出优化。实现了核心业务系统高可用。解决其他容灾技术在灾难发生时导致停机、切换甚至是数据一致性风险等问题。当故障难以避免并且出现的同时, 除了能够快速及时修复系统外, 同时数据同步自动识别增量数据, 过程可实现高度可控。

(4) 解决其他容灾产品难以跨越不同厂家硬件平台的问题。本次脱离硬件厂家技术壁垒, 不仅可以在磁盘阵列内部实现, 也可以跨越不同磁盘系统来实现, 镜像技术完全不依赖于磁盘系统的品牌和型号。因此, 在平台异构性上, 可以自由、灵活的选择磁盘系统。

1.3 系统应用效果

基于容灾架构的LTE高可靠网管体系统, 应用效果主要体现在3个方面。

1.3.1 容灾测试效果

此次容灾实施于2014年5月建成, 并且经过了严格的测试, 系统可以达到以下效果:

(1) 当金银湖生产数据卷发生故障时, 常青容灾存储会在3秒之内接管数据库, 数据库不用启停、业务无中断、数据零丢失、客户无感知后台切换, 整个过程无需人工干预。容灾卷性能可以满足告警库的日常业务量需求, 生产中心和容灾中心的光纤链路稳定可靠, 带宽足以满足镜像卷数据的传输。

(2) 同时对SF的性能、稳定性也进行了验证, 其自身非常稳定和强壮, 有效地满足了企业级应用的需求, 保证了核心业务系统的连续性。

1.3.2 保障效果

自系统实施以来, 已成功抵御多次LTE网管数据库故障导致的双机切换, 抵御过2次LTE消息队列MQ服务器程序故障导致的双机切换。若没有规划业务高可用, 在数据库及MQ服务器软件、硬件发生故障时, 业务将会中断, 直至故障修复, 业务在该时间段都将受到影响。有了高可用产品保护, 上述三次故障业务受影响时间从原来几小时甚至几天缩短为现在的几分钟。从存储设备角度来说, 目前加入容灾的告警数据库、网管性能数据库已经具备抵御存储级故障的能力, 且在故障发生时候常青存储会自动接管数据库, 业务不受影响。

1.3.3 技术适用性分析

(1) 满足业务需求上:LET业务的重要性对业务连续性要求很高, 因此数据要求实现绝对的零丢失, 从前面的分析来看, 只有镜像技术可以实现。

(2) 方案完整性上:LTE系统将建立应用级容灾, 后期将规划灾备机房节点集群, 除了数据复制外, 当灾难出现后, 需要进行切换;因此, 是否可以快速方便的进行切换, 以及操作的难易程度十分重要。各种技术中, 镜像技术可以提供完整的数据同步和容灾切换。

(3) 多品牌支持上:symantec SF支持各主流品牌主机、存储设备, 方便在各品牌之间进行选择。

2 结语

根据《信息系统灾难恢复规范》, GB/T20988-2007指导, 按照容灾等级6级数据零丢失和远程集群支持的要求, 接下来将持续推进: (1) 现有容灾业务后续应加入新节点到灾备端机房, 和生产机房计算节点配置集群, 从而实现从主机到存储故障的全方位抵御功能; (2) 及时回收灾备端存储空间, 为后续扩大业务容灾范围做保障。后期, 主要工作体现在两个方面:一方面, 对现有系统进行优化, 全面提升系统性能;另一方面, 面向全省进行系统的试用与推广, 争取为企业带来更多的利益。

摘要：早期的容灾模式中, 使用了很多成熟的高可用技术和设备, 但对高可用性的规划、设计、实施和改进过程却缺乏统一的认识和整体的管理, 通过对软硬件系统可用性指标的简单叠加来设计可用性计划, 而非通过正确的方法、规范的流程来规划和实施高可用性建设。该系统在实施规划期就把业务高可用及业务容灾做了全面系统的规划, 将产品选型和技术方案跟业务紧密结合起来。在实现系统容灾大幅提升的同时, 有效提升了容灾处理效率。

关键词：安全容灾,LTE,网络架构,可靠性

参考文献

[1]陈鹏, 杨频, 赵奎, 李雯, 吕若楠, 仲慧慧.远程容灾系统的设计与实现[J].计算机工程与设计, 2011 (10)

[2]韩伟杰, 阎慧, 王宇.航天测控系统容灾能力评估方法研究[J].计算机技术与发展, 2011 (8)

容灾体系 篇4

如何确保医院核心业务系统安全、可靠地运行,以及在发生服务器、存储器、数据库故障时仍能确保整个业务信息系统稳定运行和数据安全是医院IT人员重点思考的问题[2,3]。其次为提高业务系统性能,降低外围业务对业务系统的压力,将部分分析数据与统计业务数据分离到容灾系统,也是本文考虑解决的问题。

1 我院现状及需求

目前, 我院HIS数据库总数据量为127 GB左右,EMR数据库为278G左右。为避免数据丢失造成严重损失,我院对核心数据库进行了异地备份。采用IBMP720 小机+SAN交换+IBM DS5020 存储以及Oracle 10g2 数据库和AIX6.1 操作系统。利用OGG(数据复制技术)将源数据库的在线日志或归档日志获得的数据增删改变化应用到目标数据库,实现对核心数据库的备份[4]。

HIS是医院的核心业务系统,医院的业务基本上都是围绕着HIS开展,一旦HIS出现故障,病人无法正常就诊、交费、取药,医生开不了处方、医嘱、检验单、检查单,相关检查科室取不到病人的基本信息,造成病人情绪不稳定,医院处于全面瘫痪状态[5]。我院目前用两台IBM P550小机+ 双SAN交换+ 双IBM DS4700 存储,虽然避免了单点故障的风险,但机房物理环境发生灾难性事故,还是存在着相当大的风险;虽然有异地备份机制,但数据从备份恢复到正常需用时间周期长, 并需要对客户端进行相应配置更改。如何在短时间内恢复HIS的运行,减少信息系统故障对病人、医务人员、社会造成的影响仍是迫切需解决的问题。

2 应用级容灾的方案设计

2.1 容灾系统拓扑架构

为确保我院HIS业务正常运行,并保证在发生灾难时也能在短时间恢复业务正常,我院在外科大楼6 层计算机房进行应用级容灾建设,利用原有的IBMP720 小机+SAN交换+IBM DS5020 存储以及Oracle 10g2 数据库和AIX6.1 操作系统进行应用级容灾部署。应用级容灾部署后可以在业务系统和容灾系统之间形成相互切换、相互恢复的容灾关系。当业务系统出现异常或计划内维护时,业务系统可以简单地切换至容灾系统,容灾系统替代业务系统提供服务;业务系统硬件设备复原之后,容灾系统可以回切至业务系统运行[6]。我院应用级容灾的总体架构图设计,见图1。

2.2 容灾管理平台的部署

Trust DBRA(灾难备份系统)的部署分为3 部分:业务系统端部署、容灾系统端部署和WEB管理端部署。

(1)业务系统端部署:Trust DBRA在业务系统的数据库实例上安装一个Trust Diaster Backup Client Agent for Oracle(Trust Log Capture Service和Trust Log Transfer Service),用来获取Online redo log数据和传输Redo log数据[7]。如果需要进行应用服务器和文件数据同步,则需要同时部署Trust Backup Client Agent for App。

(2)容灾系统端部署:Trust DBRA在容灾系统为每个对应的Client Agent安装Server模块。多对一的部署方式,只需安装一个Server模块;一对一的部署方式,需要安装多个Server模块。

(3)WEB管理端部署:WEB管理端主要用来实现容灾系统的WEB管理,可以实现多项任务合一模式下的集中化管理,包括总体监视、切换、容灾操作、作业信息检查、活动站点管理等功能。

3 容灾切换技术及实现方式

3.1 数据库复制技术

Oracle数据库发出事务更新,日志写入进程(LGWR),即完成Online Redo Log的写入过程。具体过程是Trust Log Capture Service实时读取生产端在线日志信息,由Trust Log Service同步到灾备中心端写日志数据;在灾难备份中心,Trust灾备Server进程接收Trust Log Service传送过来的数据并且生成对应的灾备端的Online Redo Log数据,在业务系统进行Log switch的时候同步在灾难备份中心完成Log Switch, 在灾备端Trust Apply Service通过Oracle Physical Recover机制把相关Online Redo Log日志内容更新到灾备中心数据库(实时更新模式)或者直接把归档内容更新灾难备份中心数据库(异步模式),实现容灾库与生产库的实时同步[8],见图2。

3.2 应用复制技术

中间件(应用)同步简称APP同步,主要实现单个文件、多个文件、目录、文件系统等内容的数据同步。APP同步可以安装在数据库服务器上,也可以安装在中间件服务器或文件服务器上。APP同步时间间隔以分钟为单位计算,时间长度可以按实际需要进行调整,一般不建议间隔时间太短,如>5 min。APP同步缺省以首次全量同步,然后以增量同步的模式进行;每次增量同步时,自动检查同步内容的文件时间和文件大小,若遇到文件时间和文件大小不一致时,会自动同步整个文件至容灾服务器。APP同步支持断点续传功能,若遇到文件传输过程中出现意外,导致文件内容不完整等情形时,APP同步在增量扫描中会自动检测到该文件,并实现断点续传功能。APP同步在遇到文件传输成功结束时,会自动校验文件,以确认文件内容和生产端文件内容是否完全一致。

3.3 局部灾难切换方式

在生产中心发生局部灾难时,比如HIS本身发生灾难(HIS服务器、存储损坏等)致使HIS服务中断,但HIS相关外围接口系统及其他系统完好。此时可将HIS切换至灾备中心,其他系统在生产中心运行。切换方法如下:

(1)通过Trust DBRA切换管理平台,进行灾备切换操作:① 停止生产端应用,停止生产端中间件数据库,停止生产端数据库( 这个步骤在实际发生时,可能无需进行) ;② 切换IP地址(要求在二层网络下操作);③ 启动灾备端数据库、灾备端中间件、灾备端应用。

(2)由于生产中心其他应用系统、网络处于正常运行状态,因此,网络不需要切换至容灾汇聚点,而是通过生产汇聚点,访问灾备中心的HIS数据库。

(3)根据备份策略,进行HIS的系统数据备份。

3.4 整体性灾难切换方式

当整个生产中心发生灾难或机房停电、火灾、地震等情况下,所有应用系统不可用,将其切换到灾备中心运行。可通过如下方式和步骤来进行切换:

(1)通过Trust DBRA容灾切换平台,根据预先制定的灾难应急预案,进行应用级容灾切换:① 停止生产端应用及数据库;② 启动灾备端数据库、启动灾备端中间件、启动灾备端应用;③ 启动各业务系统的灾备端数据库、中间件和应用程序。

(2)通过三层网络容灾汇聚点,访问灾备中心的业务系统。

(3)业务系统在灾备端运行后,根据预先制定的备份策略,进行应用系统备份和数据库数据的备份。

4 容灾活动站点的管理

为了减轻生产端负载,以及充分利用现有设备资源提高经济效益,在容灾节点通过启动Trust DBRA站点来提供Oracle数据库的活动数据查询能力,分流主数据库的压力。在相关查询的客户端的tnsnames.ora文件中配置相关容灾节点信息,这样就能将相关的查询和数据统计业务分担给容灾端[9]。

5 容灾应急系统建立的意义

(1)容灾端建设后,我院定期组织相关人员进行信息系统故障应急演练,提高临床医务人员处理信息系统故障能力,并在演练后形成书面总结报告,为以后系统维护提供应急方案[10,11]。

(2)实现院内异地灾备建设,确保发生灾难时信息数据的安全性和完整性。

(3)保证了医院业务的连续性。我院IBM P550 小机+IBMDS4700 已运行多年,不时会出现一些硬件故障,在未建设容灾系统时,进行硬件更换时需要关闭Oracle数据库并停机,造成业务中断。建了容灾系统后,当业务系统出现异常或计划内维护时,业务系统可以简单的切换至容灾系统,容灾系统替代业务系统提供服务;业务系统硬设备复原之后,容灾系统可以回切至业务系统,并保持业务的连续性,数据的完整性。

(4)把相关数据统计、数据分析等业务的客户端指向灾备端,提高了灾备端设备资源利用率,减轻了生产端的运行压力,已取得了良好的经济效益和社会效益。

参考文献

[1]翁锦阳,何萍,朱铁兵.大型医院信息系统的容灾设计和应用[J].中国医疗设备,2011,26(1):59-61.

[2]夏旭.无线网络在医院信化中的应用优势及不足的探讨[J].信息与电脑,2011,(6):124.

[3]刘传高.浅谈医院信息系统的安全管理[J].中华全科医学,2012,(9):1474-1475.

[4]武冬春.基于Golden Gate技术实现关键业务容灾的解决方案[J].信息通信,2013,(7):232-233.

[5]王晨光.医院信息系统(HIS)安全维护措施探讨[J].中国医学创新,2013,(14):77-78.

[6]刘跃,宋兵.信息系统异地容灾技术探讨[J].中国传媒科技,2012,(12):74-77.

[7]邹先霞,贾维嘉,潘久辉.基于数据库日志的变化数据捕获研究[J].小型微型计算机系统,2012,(3):531-536.

[8]李民,曹阳.基于Oracle Data Guard构建医院信息系统的容灾备份方案[J].医疗卫生装备,2012,23(8):45-47.

[9]江英琴.基于日志复制技术的容灾系统研究与应用[J].电子技术与软件工程,2014,(12):217-219.

[10]王玉珍,孙巍,郭建魁.医院网络入侵检测系统联动策略的实施[J].中国医疗设备,2015,30(8):87-89.

容灾分级与技术选型 篇5

信息技术的迅速发展和广泛应用, 使企业的商业运作模式发生了变革性的变化, 企业信息系统占据了企业竞争优势的主体地位, 企业核心业务系统中的数据成为企业赖以生存的基础。然而, 人为的操作错误, 系统软件或应用软件的缺陷、硬件的损毁、电脑病毒、黑客攻击、自然灾难等等诸多因素, 都有可能造成计算机中数据的丢失, 从而给企业造成无可估量的损失, 如美国“9.11”事件就导致上千家公司倒闭。

中国的容灾建设在经历几年的探讨后, 正逐步进入实践阶段。促成容灾备份市场快速发展的原因主要源于两个方面:客观上是国内信息化建设的不断普及, 很多政府、行业和企业的关键业务已经全部信息化, 而保持业务运行的连续性和信息的安全已成为他们首要考虑因素;另一方面, 美国“9.11”事件、东南亚海啸、地震等灾难的频繁发生造成数据的丢失, 政府逐渐认识并已经在推动国家重要行业的灾备建设。2007年7月, 国务院信息化工作办公室领导编制的《重要信息系统灾难恢复指南》正式升级成为国家标准《信息系统灾难恢复规范》 (GB/T 20988-2007) 。这是中国灾难备份与恢复行业的第一个国家标准, 标志着我国灾难备份与恢复行业走向正轨。

2.容灾系统相关参数

在评价容灾系统时一般考虑三个参数:

RTO (Recovery Time Objective) :系统恢复的时间;

RPO (Recovery Point Objective) :灾难发生时丢失的数据量;

COST:建立及维护一套容灾方案所需的费用。

理想情况是在合理的费用下, RTO、RPO为零, 但是实际与理想的情况总是有差距的, 这时就应该选取一个折中的方案。1992年美国的SHARE用户组与IBM一起定义了SHARE 78标准, 将容灾系统分为了7层, GB/T 20988-2007中的分级也异曲同工。

容灾系统的每一个层次采用不同的容灾方法, 具有不同的数据恢复能力, 即RTO、RPO的差别。而当恢复策略转向更高层时, COST参数将呈指数增长。因此在选择容灾方案时应该根据实际情况在三个参数之间综合考虑。

2.1 一级:无异地备份

一等级容灾方案数据仅在本地进行备份, 没有在异地备份数据, 未制定灾难恢复计划。这种方式是成本最低的灾难恢复解决方案, 但不具备真正灾难恢复能力。

在这种容灾方案中, 最常用的是备份管理软件加上磁带机, 可以是手工加载磁带机或自动加载磁带机。它是所有容灾方案的基础, 从个人用户到企业级用户都广泛采用了这种方案。其特点是用户投资较少, 技术实现简单。缺点是一旦本地发生毁灭性灾难, 将丢失全部的本地备份数据, 业务无法恢复。

2.2 二级:实现异地备份

第二级容灾方案是将关键数据备份到本地磁带介质上, 然后送往异地保存, 但异地没有可用的备份中心、备份数据处理系统和备份网络通信系统, 未制定灾难恢复计划。灾难发生后, 使用新的主机, 利用异地数据备份介质 (磁带) 将数据恢复起来。

这种方案成本较低, 运用本地备份管理软件, 可以在本地发生毁灭性灾难后, 恢复从异地运送过来的备份数据到本地, 进行业务恢复。但难以管理, 即很难知道什么数据在什么地方, 恢复时间长短依赖于何时硬件平台能够被提供和准备好。以前被许多进行关键业务生产的大企业所广泛采用, 作为异地容灾的手段。目前, 这一等级方案在许多中小网站和中小企业用户中采用较多。

2.3 三级:热备份站点备份

第三级容灾方案是将关键数据进行备份并存放到异地, 制定有相应灾难恢复计划, 具有热备份能力的站点灾难恢复。一旦发生灾难, 利用热备份主机系统将数据恢复。它与第二级容灾方案的区别在于异地有一个热备份站点, 该站点有主机系统, 平时利用异地的备份管理软件将运送到异地的数据备份介质 (磁带) 上的数据备份到主机系统。当灾难发生时可以快速接管应用, 恢复生产。

由于有了热备中心, 用户投资会增加, 相应的管理人员要增加。技术实现简单, 利用异地的热备份系统, 可以在本地发生毁灭性灾难后, 快速进行业务恢复。但这种容灾方案由于备份介质是采用交通运输方式送往异地, 异地热备中心保存的数据是上一次备份的数据, 可能会有几天甚至几周的数据丢失。这对于关键数据的容灾是不能容忍的。

2.4 四级:在线数据恢复

第四级容灾方案是通过网络将关键数据进行备份并存放至异地, 制定有相应灾难恢复计划, 有备份中心, 并配备部分数据处理系统及网络通信系统。该等级方案特点是用电子数据传输取代交通工具传输备份数据, 从而提高了灾难恢复的速度。利用异地的备份管理软件将通过网络传送到异地的数据备份到主机系统。一旦灾难发生, 需要的关键数据通过网络可迅速恢复, 通过网络切换, 关键应用恢复时间可降低到一天或小时级。这一等级方案由于备份站点要保持持续运行, 对网络的要求较高, 因此成本相应有所增加。

2.5 五级:定时数据备份

第五级容灾方案是在第四级容灾方案的基础上, 利用备份管理软件自动通过通信网络将部分关键数据定时备份至异地, 并制定相应的灾难恢复计划。一旦灾难发生, 利用备份中心已有资源及异地备份数据恢复关键业务系统运行。

这一等级方案特点是备份数据是采用自动化的备份管理软件备份到异地, 异地热备中心保存的数据是定时备份的数据, 根据备份策略的不同, 数据的丢失与恢复时间达到天或小时级。由于对备份管理软件设备和网络设备的要求较高, 因此投入成本也会增加。但由于该级别备份的特点, 业务恢复时间和数据的丢失量还不能满足关键行业对关键数据容灾的要求。

2.6 六级:实时数据备份

第六级容灾方案在前面几个级别的基础上使用了硬件的镜像技术和软件的数据复制技术, 也就是说, 可以实现在应用站点与备份站点的数据都被更新。数据在两个站点之间相互镜像, 由远程异步提交来同步, 因为关键应用使用了双重在线存储, 所以在灾难发生时, 仅仅很小部分的数据被丢失, 恢复的时间被降低到了分钟级或秒级。由于对存储系统和数据复制软件的要求较高, 所需成本也大大增加。

这一等级的方案由于既能保证不影响当前交易的进行, 又能实时复制交易产生的数据到异地, 所以这一层次的方案是目前应用最广泛的一类, 正因为如此, 许多厂商都有基于自己产品的容灾解决方案。如存储厂商EMC等推出的基于智能存储服务器的数据远程拷贝;系统复制软件提供商VERITAS等提供的基于系统软件的数据远程复制;数据库厂商Oracle和Sybase提供的数据库复制方案等。但这些方案有一个不足之处就是异地的备份数据是处于备用 (Standby) 备份状态而不是实时可用的数据, 这样灾难发生后需要一定时间来进行业务恢复。更为理想的应该是备份站点不仅仅是一个分离的备份系统, 而且还处于活动状态, 能够提供生产应用服务, 所以可以提供快速的业务接管, 而备份数据则可以双向传输, 数据的丢失与恢复时间达到分钟甚至秒级。

2.7 七级:零数据丢失

第七级容灾方案是灾难恢复中最昂贵的方式, 也是速度最快的恢复方式, 它是灾难恢复的最高级别, 利用专用的存储网络将关键数据同步镜像至备份中心, 数据不仅在本地进行确认, 而且需要在异地 (备份) 进行确认。因为, 数据是镜像地写到两个站点, 所以灾难发生时异地容灾系统保留了全部的数据, 实现零数据丢失。

这一方案在本地和远程的所有数据被更新的同时, 利用了双重在线存储和完全的网络切换能力, 不仅保证数据的完全一致性, 而且存储和网络等环境具备了应用的自动切换能力。一旦发生灾难, 备份站点不仅有全部的数据, 而且应用可以自动接管, 实现零数据丢失的备份。通常在这两个系统中的光纤设备连接中还提供冗余通道, 以备工作通道出现故障时及时接替工作, 当然由于对存储系统和存储系统专用网络的要求很高, 用户的投资巨大。

3.容灾的用户需求

3.1 本地数据安全保护

中小企业是一个很大的群体, 他们都建有自己的局域网, 数据更新的频率不大, 这部分用户需要的是能把绝大部分业务数据, 像客户资料、技术文件、财务账目, 甚至企业管理的核心内容等企业的重要数据资产保存下来。相对而言, 这种企业每日处理的业务数据量不大, 能够容忍业务系统在1至2个工作日内恢复。他们需要简单易用的数据保护, 本地数据保护是采用备份软件对生产数据进行定时的备份, 当系统发生故障和人为的错误时, 确保系统在误操作或遭受恶意攻击时可以对数据进行恢复。

3.2 本地应用的高可用性

日常业务数据处理量大的快速发展型企业, 对交易处理数据比较敏感, 他们需要对业务数据实施连续性的保护, 防止事故发生时在最短的时间内迅速恢复业务数据, 最大限度地保障业务处理的继续运行。同时为防止重大灾难也需要对业务数据进行异地的容灾。

前面两个阶段, 但它们的共同弱点是无法完全承担应用系统发生灾难时业务系统的安全运行, 如备份系统无法保证灾难出现后系统的不间断运行。

3.3 异地数据保护

目前有很多公司在全国设有分支机构, 这部分用户更注重数据的完整性、可靠性, 他们需要各分支机构每天将变化了的数据汇总到总部, 以便于统一管理, 为业务数据和整个公司的信息安全提供了基本保障。同时为确保数据安全, 总部数据需要在异地进行远程备份以防止灾难发生, 确保企业的业务数据信息在灾难发生后得以保全。

3.4 异地应用的连续性

对金融、电信、海关等对交易处理非常重视的行业来说, 他们不但要求对本地数据实施连续性保护, 而且需要远程的实时容灾, 通过数据复制技术将数据实时传输到异地, 确保两地数据的一致, 在灾难发生后企业的业务数据能迅速恢复, 实现业务不间断的目标, 保证业务系统的连续性。

4.容灾的技术选型

数据容灾是通过技术手段实现数据级保障, 目前有数据复制与数据备份两种实现手段, 不过现阶段大家都关注数据复制技术的应用, 而忽略了数据备份。其实数据复制与数据备份对数据的关注点是不一样的, 数据复制关注的是当前数据, 而数据备份关注的是历史数据;数据复制能够保证当前数据的一致, 但对病毒攻击、人为误操作等数据损坏是无能为力的, 而数据备份能够解决历史数据的恢复, 当数据遭到病毒攻击、人为误操作时我可以通过数据备份恢复到前一个时间点的正常状态;同时数据复制的成本高, 对带宽占用大, 而数据备份能实现数据的多版本保存。因此我们认为用数据复制实现数据备份的功能代价太高, 直接用数据复制代替数据备份是不可取的。

我们认为容灾所承担的是用户最关键的核心业务, 其重要作用勿庸置疑, 容灾本身的复杂性也是十分明显的, 这就决定了容灾成为一项系统工程。性能、灵活性以及价格都是必须考虑的因素, 更重要的是, 用户需要根据自己的实际需求量身打造。针对客户不同的需求, 数据容灾通过各种手段和技术来完成。不同的容灾体系的投入是不同的, 所以不同的系统必须根据数据的重要程度建立相应的数据容灾体系。根据我们多年在容灾备份领域的经验, 基于对用户容灾需求的深入分析, 可以将容灾技术方案划分为简单易用型的本地数据备份、相对成本低廉的异地容灾数据备份、实用型综合数据保护、高可靠异地容灾复制与备份等几类典型。

4.1 本地数据备份

一个中小规模数据存储企业用户, 有几十台PC机, 几台Windows平台服务器, 通过局域网联在一起, 用户需要备份网络中的数据库、文件, 并能预防事故的发生。典型网络拓扑如图1。

我们通过部署备份软件, 实现网络中最根本的数据库备份、文件备份, 支持完全备份、增量备份、差分备份, 可以设置备份策略实现智能化数据备份。并能够将备份数据存储在磁带上, 根据需要可以将磁带离线存放到一个安全的地方以防灾难。

以很低的代价为用户提供最基本的数据容灾, 通过制定不同的备份策略, 可以对服务器和客户机中的数据加以保护, 不仅能详尽地记录历史数据、有效的管理日益增多的数据量, 还能在灾难发生时对系统进行恢复, 使损失减至最小。

4.2 异地数据备份

某政府机构现有比较完整的网络与应用系统, 网络系统主要由内网、外网两部分组成。由于用户应用系统上数据的重要性, 因而需要保护好计算机系统里的数据, 也就是对这些数据进行有效的备份, 并支持快速恢复是本次系统改造的中心。我们分析用户需要通过制定完善的数据备份与灾难恢复策略, 对信息网络中服务器上的文件和数据库信息进行智能化备份、恢复等操作, 以达到保护数据和最大限度提高存储资源效率的目的。同时由于用户对业务数据有极高的安全要求, 除了本地备份以外, 还要求在异地做备份或者多个业务点互备, 从而达到容灾的要求。我们为其设计了网络拓扑图, 如图2。

这是一个低成本的异地容灾备份解决方案, 采用有远程备份功能的备份软件, 可以有效地保障异地备份系统的可靠、高效和廉价, 从而用最简便的方法实现了远程数据容灾备份。在用户实时性要求不特别严格的情况下可以有效地替代复制技术实现异地容灾。

4.3 实用型数据保护

某事业单位网络建设已经基本形成, 随着科技不断发展, 业务变得越来越复杂, 业务数据变动频繁。同时用户在同城异地有新的办公地址, 而新址的资料需要通过网络从原址素材库中提取, 因此需要保证异地数据安全, 如遇问题可即时恢复。我们为其设计了网络拓扑图, 如图3。

通过实施数据备份和数据复制, 使用户以低成本在多平台、多备份源点、跨网络的复杂环境中有效地实现了数据的持续保护和远程容灾备份;满足了SAN环境中高效的数据迁移;全面有序地管理单位内多年的离线磁带;符合国人习惯的人性化界面让人倍感亲切, 提高了工作效率。

4.4 高可靠异地容灾与备份

某金融机构信息系统经过多年的建设, 其应用处理已经完善。本次系统改造将实现交易系统优化外;最重要的是要实现数据容灾和数据备份。根据我们实地考察, 认为用户应用系统上的数据极其重要, 备份是最基本的需要。同时由于业务数据变更的频率比较快, 需要对业务数据实现持续保护, 并实现远程的灾难恢复系统。在经过对用户的软、硬件及网络环境进行了综合考察, 从数据持续保护、数据远程容灾、数据备份等方面进行了深入分析而提出了网络拓扑图, 如图4。

浅论HLR的容灾备份 篇6

随着移动业务的日益发展,移动网络运营商对服务可用性的期望越来越高,对网络可靠性提出了更严格的要求。如果关键网元不可用而导致大面积用户的通信业务受到影响,将对运营商的营业收入和企业形象产生巨大负面影响。因此,保证网络的安全性,提高网络的可用性,业已成为各大运营商重要的关注点。

归属位置寄存器(以下简称HLR)作为GSM/UMTS网络中最重要的数据中心,网络地位非常重要。HLR一旦发生故障,将直接导致严重后果:就终端用户而言,将无法做为被叫,无法进行位置更新,无法获取鉴权信息,无法接收短消息,无法修改用户自定义的补充业务,部分用户无法做主叫等;就网络运营商而言,将导致营业厅和客服中心不能为用户提供正常服务。因此,HLR的安全性和可靠性在移动网络中十分关键。

当前,提高HLR的安全性和可靠性主要通过两种方式:(1)提高HLR系统自身的软硬件可靠性。(2)对HLR进行网元级容灾备份,通过在不同站点布放备份HLR来实现。

目前通行的HLR网元级容灾备份方案主要有:1+1主备,1+1互备,和N+1主备。本文将讨论前两种容灾备份方案。

无论是1+1主备方案还是1+1互备方案,均可以在物理上将两个HLR拉远放置,以实现地理级冗余。一旦某个站点遭遇灾难,该站点的HLR将可能完全瘫痪或者部分瘫痪。因此,故障HLR所处理的业务需要重新路由到对端HLR上,而SS7网络可以实现业务的重新路由。对端HLR之所以能够接管故障HLR的业务,源于故障前两个HLR之间进行了数据同步与复制。

2 HLR 1+1主备方案

2.1 方案原理

该方案中,主/备HLR间的静态用户数据和动态用户数据进行实时同步,备份HLR接管主用HLR后,因主用HLR发生故障而受到影响的终端用户能够立即正确地做被叫,或进行位置更新,或获取鉴权信息等。

2.1.1 数据同步与复制

主/备HLR间建立了数据库网络级同步通道。正常工作时,主/备HLR数据库的工作模式为Master/Slave,当主用HLR中的数据发生修改时,该数据修改被实时同步到备份HLR的对应数据库中。

主/备HLR间的数据同步通道具有心跳和再同步机制。当发现心跳断开时,系统发出告警。在主/备HLR间的心跳断开的时间内,主用HLR记录未同步的用户数据;当心跳恢复后,备份HLR自动对这一部分数据进行再同步。

2.1.2 备份HLR业务接管

1. 业务切换到备份HLR

主/备HLR具有不同的信令点编码,在以下情况下执行业务切换。

(1)主/备HLR都通过STP与SS7网络相连,在SCCP层做主备用路由,当主用HLR发生故障,且SS7网络完全不可达时,系统自动切换到备份HLR。

(2)当主用HLR发生重大故障但SS7网络部分不可达时,主用HLR发出告警信息,维护人员识别告警级别,从而判断是否执行切换操作。

2. 营帐系统的切换

主用HLR发生故障后,备份HLR发送消息到BOSS系统通知发生切换。

BOSS系统检测到与主用HLR间指令执行通信中断或者收到备份HLR发出的通知后,将指令切换到备份HLR。

2.1.3 主用HLR恢复

主用HLR故障排除、系统恢复后,执行倒回流程。

1.在主用HLR故障修复的过程中

(1)首先删除主用HLR到STP的所有信令链路,进行硬件和软件的故障排查,当故障修复后,执行(2)步骤。由于备份HLR接管业务后需要处理现网正常话务,因此,倒回操作建议在半夜12∶00话务低峰时进行。

(2)当主用HLR故障修复后,BOSS应停止向备份HLR发送用户数据修改请求。

(3)将备份HLR数据库设为Master,主用HLR数据库设为Slave,进行备份HLR数据库到主用HLR数据库的用户数据同步;

2.系统检查后,启动回切指令,激活主用HLR的SS7信令链路,将话务倒回到主用HLR;

3.BOSS恢复向主用HLR发送用户数据修改请求。

2.2 方案须具备的条件

(1)备份HLR需分配独立的信令点编码;

(2)需要在H/LSTP上配置好路由数据,以便切换时,H/LSTP能够自动选取路由。备份HLR与LSTP直联,由LSTP实现信令链路的自动重选。正常情况下,各网元与主用HLR相连;当主用HLR发生故障时,各网元到主用HLR的信令链路将路由到STP,STP将路由到备份HLR。

3 HLR 1+1互备方案

3.1 方案原理

1+1互备方案中,正常状态下,两个HLR以负荷分担的方式处理MAP信令。两个HLR处理的用户被分割为2个子集:子集0和子集1。其中一个HLR有数据更新时,更新的数据通过IP WAN准实时地复制到对端HLR中,详见图1。

3.1.1 数据同步与复制

1.数据复制

当两个HLR均正常工作时的状态,如图2所示。

2.子集切换—数据复制停止

当HLR1完全瘫痪,或者出于维护目的对HLR进行手动干预(例如,软件版本变更且不同版本的数据格式不兼容)时的状态,如图3所示。此时,HLR1停止数据流复制并发生切换。

3.子集切换——数据复制保持

当HLR1部分不可用,但能够处理MAP话务,或者是出于维护目的对HLR1进行手动干预(例如,软件版本变更且不同版本的数据格式兼容)时的状态,如图4所示。此时,HLR1保持数据流复制并进行话务切换。

3.1.2 SS7网络切换

如果站点遭遇灾难,SS7网络将来自其他网络节点(例如:MSC/VLR,SGSN)的话务自动切换到对端HLR接管,并采取其他所有的必要措施,例如,检查复制状态,通知BOSS系统。

如果对1+1互备的某个HLR进行手动切换,该HLR或者对端HLR将触发SCCP层的平滑隔离,这会被网络侧理解为站点故障,不过事实上,手动切换并不影响HLR与SS7网络的连接。

1.自动切换

在自动切换的过程中,会发生以下事件:

对故障HLR1(放弃业务)

失去与SCCP中继节点的连接(SRP SPC STA-TUS NOK);

定时器超时;

如果来自HLR0的消息表示HLR0也愿意放弃业务处理(Switchover Coordination Start(YIELDING)),则表示发生故障的是SCCP中继节点,而不是HLR,此时,两个HLR都应该拒绝切换(Switchover Coordination Deny)。

对非故障HLR0(接管业务)

接收备份子集或分区的业务;

如果SCCP中继节点发生故障,HLR0会失去与SCCP中继节点的连接。此时千万不能误读为HLR1发生故障;

收到HLR1愿意放弃业务消息(Switchover Coordination Start(YIEDING));

定时器超时;

如果HLR1尚未放弃业务,则拒绝倒换(Switchover Coordination Deny)。

2.手动切换

当1+1互备的某个HLR需要脱网进行维护时,通常启动手动切换流程。手动切换可以不产生任何数据丢失,或者只在切换时产生很小的业务中断。

3.2 方案须具备的条件

1.MAP话务自动倒换

该功能要求在话务/子系统复制中,SCCP中继节点具有GTT功能。

该功能可以在独立STP中实现,也可以在SP中实现。实际应用中,大多在独立STP中实现。

只有数据库一致性得到保证时才执行话务重定向,HLR软件支持该功能。为了使话务中断的可能性最低,必须保证两个HLR的数据库一致。

2.SS7点编码

每个HLR需要有且仅有一个信令点编码。

3.OAM流程自动切换(GUI/CCBS)

为了访问用户数据,营帐系统只要知道用户归属于哪个子集或分区(Partition)即可,无需知道物理上到底是哪个HLR处理该用户的话务。

也就是说,营帐系统对子集或分区进行寻址,不是通过物理地址(例如:IP地址,TCP段口号),而是通过逻辑名(例如:“子集0”或者“子集1”)。

HLR所支持的CORBA命名服务,可以将逻辑名转化为物理地址。

4 结束语

本文重点介绍了HLR1+1容灾备份的两种实现方式,分别介绍了这两种方式的原理,以及需配合的条件。目前,移动网络运营商逐渐意识到提高HLR可靠性和安全性的重要,因此正在逐步引入HLR的容灾备份,而本文介绍的两种备份方案正得到日益广泛的应用。

参考文献

[1]ITU-T Q.714Specifications of Signaling System No.7-Signaling Connection Control Part

[2]YD/T1126-2001No.7信令系统测试规范-信令链接控制部分(SCCP)

数据中心容灾备份系统 篇7

数据中心容灾备份系统简称“灾备系统”, 又称为灾难恢复系统或灾难备份系统。灾备系统是数据中心保护数据的最后手段, 其建设是一项系统工程, 不但涉及数据中心的服务器、存储、网络, 而且涉及组织架构、业务流程、规章制度、外部协作关系、资金投入等各个方面。灾备系统需要对可能遭受的风险进行风险分析和业务影响分析, 结合数据中心的现状进行设计, 同时筹备所需的各种资源, 制定详细的任务进度计划, 通过严格的项目设施管理措施, 才能保证项目的质量和进度的要求。

对此, 本刊以“数据中心容灾备份系统”为专题, 特别安排了《数据中心灾备系统的规划》、《数据中心灾备系统的分类》、《数据中心灾备系统的组成》、《数据中心灾难恢复的策略》、《灾备数据中心的基础架构的思考》、《大型综合布线系统的灾难备份思考》的文章, 希望通过本期专题的介绍, 帮助您对数据中心容灾备份系统的了解。

本栏目欢迎您提出宝贵意见与建议, 感谢您的参与与支持!