毕业论文-通信容灾技术探讨.doc

《毕业论文-通信容灾技术探讨.doc》由会员分享，可在线阅读，更多相关《毕业论文-通信容灾技术探讨.doc（36页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1 绪论21.1.概况21.1.1.容灾的定义21.1.2.容灾的评价指标21.1.3.容灾的分类31.1.4.容灾的等级划分31.2. 技术篇41.2.1.数据备份技术51.2.2.数据复制技术61.2.3.灾难检测技术71.2.4.系统迁移技术81.3. 展望篇81.3.1.业务连续性81.3.2.持续数据保护92.1容灾分类92.1.1 HLR数据容灾92.1.2 ULR业务容灾技术1522. 业务容灾的原则和方式202.2. 1业务容灾配置原则202.2.2 业务容灾数据同步方式212.3 虚拟卷/硬件232.4 容灾系统的容量232.5. HLR容灾的实施建议243. 存储网络容灾备

2、份253.1.概况253.2 技术篇263.2.1.磁带备份263.2.2.无需LAN的备份273.2.3.服务器负担较轻的备份283.2.4.备份行业和产品概述283.3. 利用SAN 进行备份的主要优势293.3.1提高数据可用性293.3.2.降低TCO293.4.灵活的备份选项303.4.1远程数据镜像/数据复制313.4.2思科的灾难恢复产品和解决方案313.4.3.虚拟SAN(VSAN)324. 结束语365. 参考文献371 绪论随着信息时代的到来，数据越来越突出地成为社会正常运作的核心。对于一个企业来讲，数据更是影响其生存和发展的关键，各行业的用户和企业对网络应用和数据信息的依

3、赖日益强烈，使得突发性灾难如火灾、洪水、地震或者恐怖事件等对整个企业的数据和业务生产会造成重大影响。因此，如何保证在灾难发生时企业数据不丢失，保证系统服务尽快恢复运行，成为人们关注的话题，容灾技术日益成为各个行业关注的焦点。本文从技术角度对容灾的概念、相关技术进行介绍，并对其发展趋势进行探讨。1.1.概况1.1.1.容灾的定义在给出容灾的概念之前，有必要先给出灾难的定义。从一个计算机系统的角度讲，一切引起系统非正常停机的事件都可以称为灾难。大致可以分成以下三个类型：A.自然灾害：包括地震、火灾、洪水、雷电等，这种灾难破坏性大，影响面广；B.设备故障：包括主机的CPU、硬盘等损坏，电源中断以及网

4、络故障等，这类灾难影响范围比较小，破坏性小；C.人为操作破坏，包括误操作、人为蓄意破坏等等。容灾（Disaster Tolerance），就是在上述灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。1.1.2.容灾的评价指标现在工业界都以数据丢失量和系统恢复时间作为标准，对某个容灾系统进行评价，公认的评价标准是RPO和RTO。 RPO（Recovery Point Objective）: 恢复点目标，以时间为单位，即在灾难发生时，系统和数据必须恢复到的时间点要求。RPO标志系统能够容忍的最大数据丢失量。系统容忍丢失的数据量越小，RPO的值越小。 RTO（Rec

5、overy Time Objective）: 恢复时间目标，以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间要求。RTO标志系统能够容忍的服务停止的最长时间。系统服务的紧迫性要求越高，RTO的值越小。RPO针对的是数据丢失，RTO针对的是服务丢失，两者没有必然的联系，并且两者的确定必须在进行风险分析和业务影响分析之后根据业务的需求来确定。1.1.3.容灾的分类由于容灾包含的内容比较广泛，对容灾的分类也可以从多个方面进行。总的来讲，可以从容灾的范围和容灾的内容来区分。从容灾的范围讲，容灾可以分为本地容灾、近距离容灾和远距离容灾。这三种容灾能容忍的灾难是不相同的，采用的容灾技

6、术也是不同的。从容灾的层次讲，容灾又可以分成数据容灾和应用容灾，本质上讲，这两种容灾是密不可分的。数据容灾是应用容灾的基础，没有数据的一致性，就没有应用的连续性，应用容灾也是无法保证的。数据容灾是指建立一个备用的数据系统，该备用系统对生产系统的关键数据进行备份。应用容灾则是在数据容灾之上，建立一套与生产系统相当的备份应用系统。在灾难发生后，将应用迅速切换到备用系统，备份系统承担生产系统的业务运行。1.1.4.容灾的等级划分由于容灾系统需要考虑众多的因素，目前，根据容灾系统中数据的丢失程度、生产系统和备用系统的距离，以及灾难恢复计划的状态等因素，公认的容灾级别划分如下：A.本地容灾：即将系统数据

7、或应用在本地备份，无异地后援。这一级别的容灾，仅能应付本地的硬件损坏或人为因素造成的灾难。B.异地数据冷备份：即将系统数据备份到物理介质（磁盘、磁带或光盘）上，然后送到异地进行保存。这种方案成本低、易于实现。但是在灾难发生时，数据的丢失量大，并且系统需要很长的恢复时间，无法保持业务的连续性。C.异地数据热备份：即在异地建立一个热备份中心，采取同步或者异步方式，通过网络将生产系统的数据备份到备份系统中。备份系统只备份数据，不承担生产系统的业务。当灾难发生时，数据丢失量小，甚至零丢失，但是，系统恢复速度慢，无法保持业务的连续性。D.异地应用级容灾：即在异地建立一个与生产系统相同的备用系统，备用系统

8、与生产系统共同工作，承担系统的业务。这种类似于RAID1的容灾系统，能够提供很小的数据丢失量，系统恢复速度是最快的。但是，需要配置复杂的系统管理软件和专用的硬件，相对成本也是最高的。在上述的级别之上，又有人提出业务级别的容灾级别。对于正常的业务而言，仅靠IT系统的保障是不够的，业务级别的容灾包括众多非IT系统的设施，比如电话，办公环境等。1.2. 技术篇传统的容灾技术通常指针对生产系统的灾难采用的远程备份系统技术。但是，随着对容灾系统要求的不断提高，现在的容灾技术包括了可能引起生产系统服务停止的所有防范和保护技术。一般来讲，一个容灾系统中实现数据容灾和应用容灾采取不同的实现技术。数据容灾的技术

9、包括数据备份技术、数据复制技术和数据管理技术等，而应用容灾包括灾难检测技术、系统迁移技术和系统恢复技术等等。本章节对数据容灾相关的数据备份技术和复制技术以及应用容灾相关的灾难检测技术和系统迁移技术做初步的介绍和分析，其它的技术请参考相关技术资料。1.2.1.数据备份技术数据备份就是把数据从生产系统备份到备份系统中的介质中的过程。数据备份技术最初是备份到本地磁带，随着网络发展，现在的备份技术有了飞速的发展。 主机备份：这种备份就是传统意义上的基于主机（Host-based）的备份。主机负责将数据备份到和主机直接相连的存储介质上（一般是磁带）。虽然这种备份的速度快，管理简单，但是仅能适应于单台服务

10、器备份，并且在灾难恢复过程中，系统恢复的时间长。 网络备份：随着网络的发展，传统的主机备份渐渐地转向了网络备份，即系统中备份数据的传输以网络为基础。根据备份系统中备份服务器、介质服务器是否在同一个LAN中，可以将网络备份分为基于局域网的备份和远程网络备份。基于局域网的备份特点是应用服务器、备份服务器和介质服务器共用一个局域网络，备份服务器统一管理备份的过程，多个应用服务器可以将各自的数据备份到介质服务器上。这种备份方式可以共享介质资源，实现集中的备份管理。缺点是对网络带宽和备份时间的压力比较大，并且不具备远程的容灾能力。当然通过将介质（磁盘、磁带或光盘）运输到远程保存，可以具备一定的容灾能力。

11、远程网络备份，则是介质服务器与应用服务器不属于同一个局域网，备份服务器依然统一管理备份的过程，备份数据则是通过WAN、ATM或者Internet等公共网络传送到远程的介质服务器上。这种备份方式基本上构成了一个异地的备份容灾方案。由于备份数据在公共网络上传输，备份的速度、备份数据的完整性和安全性等方面都需要考虑。 专有存储网络备份：当存储系统成为一个独立于备份系统的系统之后，特别是存储局域网（SAN：Storage Area Storage）的发展，使得备份过程可以在存储局域网中实现，根据备份过程中对应用服务器的影响，专有存储网络备份可以分为LAN-Free备份和Server-Free备份。 L

12、AN-Free备份，是在存储网络（Storage Network）之上建立的一种备份系统。在该备份系统中，生产系统的存储和介质服务器的存储直接通过专用存储网络进行连接，在备份过程中，庞大的备份数据不经过主机系统所在的网络，而是通过专用的存储网络传输到介质上。这种备份方式的优点是共享介质资源，实现集中管理，不会对主机系统网络有影响。缺点是实现比较复杂，成本相对较高。Server-Free备份，则是建立在存储区域网（SAN：Storage Area Network）的基础上，备份过程无需应用服务器参与数据传输的备份系统。这种备份方式可以保证生产系统及其网络不受影响。目前这种备份技术还不太成熟，对硬

13、件的性能和兼容性的要求都很高。专用存储网络备份更多关注的是存储系统的扩展性、可用性以及性能等方面的因素，可以讲存储局域网的发展将会在更大程度上提高系统的数据容灾能力。1.2.2.数据复制技术和数据备份相比，数据复制技术则是通过不断将生产系统的数据复制到另外一个不同的备份系统中，以保证在灾难发生时，生产系统的数据丢失量最少。按照备份系统中数据是否与生产系统同步，数据复制可以分成同步数据复制和异步数据复制。同步数据复制就是将本地生产系统的数据以完全同步的方式复制到备份系统中。由于发生在生产系统的每一次I/O操作都需要等待远程复制完成才能返回，这种复制方式虽然可能做得数据的零丢失，但是对系统的性能有

14、很大的影响。异步数据复制则是将本地生产系统中的数据在后台异步地复制到备份系统中。这种复制方式会有少量的数据丢失，但是对生产系统的性能影响较小。根据数据复制的层次，数据复制技术的实现可以分成以下四种：A存储系统数据复制：数据的复制过程通过本地的存储系统和远端的存储系统之间的通信完成。这种方式的复制对应用来讲是透明的，可以直接实现数据容灾功能，也可以提供很高的性能，可是，对存储系统的要求比较高。B交换层数据复制：这种方式的复制技术是伴随着存储局域网的出现引入的，即在存储局域网的交换层上实现数据复制。实现方式可以通过专有的复制服务器实现，也可以通过存储局域网（SAN）交换机，将数据同步地复制到远端存

15、储系统中。C操作系统层数据复制：主要通过操作系统或者数据卷管理器来实现对数据的远程复制。这种复制技术往往要求本地系统和远端系统是同构的，并且由于数据复制由主机系统完成，其效率和管理上也存在不少问题。D应用程序层数据复制：例如数据库的异地复制技术，通常采用日志复制功能，依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。这种复制技术对系统的依赖性小，有很好的兼容性。缺点是本地应用程序向远端复制的是日志文件，这需要远端应用程序重新执行和应用才能生产可用的备份数据。另外，由于各个应用程序采取的复制技术不同，无法以一种技术实现多种应用的数据复制。1.2.3.灾难检测技术对于一个容灾系统来讲，在灾

16、难发生时，尽早地发现生产系统端的灾难，尽快地恢复生产系统的正常运行或者尽快地将业务迁移到备用系统上，都可以将灾难造成的损失降低到最低。除了依靠人力来对灾难进行确定之外，对于系统意外停机等灾难还需要容灾系统能够自动地检测灾难的发生，目前容灾系统的检测技术一般采用心跳技术。心跳技术，其中一个实现是：生产系统在空闲时每隔一段时间向外广播一下自身的状态。检测系统在收到这些“心跳信号”之后，便认为生产系统是正常的，否则，在给定的一段时间内没有收到“心跳信号”，检测系统便认为生产系统出现了非正常的灾难。心跳技术的另外一个实现是：每隔一段时间，检测系统就对生产系统进行一次检测，如果在给定的时间内，被检测的系

17、统没有响应，则认为被检测的系统出现了非正常的灾难。心跳技术中的关键点是心跳检测的时间和时间间隔周期。如果间隔周期短，会对系统带来很大的开销。如果间隔周期长，则无法及时地发现故障。1.2.4.系统迁移技术灾难发生后，为了保持生产系统的业务连续性，需要实现系统的透明性迁移，利用备用系统透明地代替生产系统进行运作。一般对实时性要求不高的容灾系统，例如Web服务、邮件服务器等，可以通过修改DNS或者IP来实现，对实时性要求高的容灾系统，则需要将生产系统的应用透明地迁移到备用系统上。目前基于本地机群的进程迁移的算法可以应用在远程容灾系统中，但是需要对迁移算法进行改进，使之适应复杂的网络环境。1.3. 展

18、望篇1.3.1.业务连续性业务连续性，顾名思义，就是保证服务和业务的顺畅运行，它不仅仅指系统的不间断运行，更是保证业务的不间断运行。业务连续性是在容灾之上的业务级容灾系统，其实施过程不仅仅是个技术问题，它更多的是关注业务本身的连续性要求。即从理解业务本身开始，进行业务的冲击分析和风险估计，在此基础上，由企业的高层管理人员指定本企业的业务持续战略计划，然后规划业务持续计划，进行测试和实施。由于业务连续性计划的讨论超出本文讨论范围，感兴趣的读者可以参考相关资料。1.3.2.持续数据保护另一个值得注意的技术是持续数据保护（CDP）。这个技术首先在一些小公司中提出来的，主要面对中小企业甚至是普通PC用

19、户，但是随着企业和用户对CDP的认同，CDP已经吸引IBM、微软，赛门铁克和EMC等各大公司注意，这几家大公司已经宣布或表示已经制订了未来的CDP产品计划。持续数据保护（CDP）的应用范围，目前可以分成三类：A.为数据中心内的文件服务器/NAS提供普通的数据保护。在这种应用中，CDP逐渐取代了以前那种夜间的磁盘或磁带备份任务。B.为远程的分支机构进行集中化的备份。将CDP用于远程分支机构备份应用的最大好处就是从此避免远距离转移磁带介质的风险。C.解决笔记本电脑上的数据备份问题。例如IBM Tivoli CDP产品，可以对笔记本电脑进行很好的数据保护，即使笔记本电脑没有连接网络。随着各个国家和大

20、型企业对容灾越来越重视，容灾技术获得飞速发展，容灾技术涉及的范围也越来越广泛，并且新技术也层出不穷，本文仅仅对当前容灾的主要技术做了介绍和总结，希望能对同行有所帮助。2容灾技术应用2.1容灾分类2.1.1 HLR数据容灾数据容灾的方案实际为数据异地（异系统）备份的方案，即新建一个（或多个）HLR容灾备份中心，每个HLR容灾备份中心存储了所有（或部分）主用HLR的用户数据。在正常的运行过程中，对用户的任何静态数据的更改都将通过营账系统同步到HLR容灾备份中心，以保证数据的一致性。当发现有主用HLR发生故障时，通过人工对备用HLR加载故障HLR的用户数据，然后修改MSC、GMSC、HSTP、LST

21、P等相关设备的配置，使对原主用HLR的信令流程重路由到容灾备份HLR。由于容灾备份HLR设备已经加载了和故障HLR同步的用户静态数据，因此可以顺利接管故障HLR的一般功能。当故障HLR修复后，首先恢复该主用HLR的用户数据，然后把相关的信令流程重新定位回到该主用HLR，便实现了故障恢复。单纯的HLR设备数据容灾对主备用HLR设备的功能均无特别要求，一般仅备份静态数据，倒换和倒回都需要人工操作完成，是非实时的，考虑到备用HLR加载数据和启动的时间，一般倒换时间较长（在数十分钟级）。而在倒换效果上，数据容灾可以很好地保证用户主叫业务不受影响，但是，由于无法做到HLR设备的动态数据的同步，备份HLR

22、中只有用户的静态数据，缺乏如VLR位置信息，前转号码、漫游限制等补充业务的动态数据，因此，需要对全网下发MAP_HLR_Reset消息，在用户位置信息更新前，故障HLR设备内用户做被叫无法正常接续。至于用户的呼叫前转、呼叫限制等补充业务则由于动态数据丢失，而无法使用，需要用户再次设置方可，因此，备份效果较差。一般的，单纯的HLR设备数据容灾，对除营账系统外的周边网元的功能没有特别要求。但是，由于各厂家HLR设备内部数据格式各不相同，数据结构差异很大，而各厂家HLR设备对营账接口的指令格式和指令语言也大不相同，因此，如果要实现异厂家HLR数据的容灾，就需要营账系统具备以下功能。a） 如果主备用H

23、LR设备厂家对营账系统的接口指令不能使用统一的标准操作指令，则需要主用HLR厂家接口指令对备用HLR厂家接口指令翻译功能。b） 营账系统对主用HLR设备操作指令成功写入后，能自动将操作指令存储为文件存放在指定存储位置，以供备份HLR倒换时加载使用。c） 在主用HLR故障期间，营账系统对备用HLR设备操作指令成功写入后，需要能自动将操作指令存储为文件存放在指定存储位置，以备主用HLR恢复时加载。 数据远程备份技术的具体实现方式可分为4种： (1)基于硬件存储设备的备份方式 存储设备之间通过高速光纤通道相连，完成异地复制功能，如EMC公司的CLARiiON CX系列磁阵1。 (2)基于虚拟卷(存储

24、)的软件备份方式 由软件来接替UNIX文件系统的虚拟卷(存储)的硬件I/O操作，将写入虚拟卷的数据通过数据链路传输到备份节点并形成远程的文件镜像，以实现主节点到备份节点数据的备份，如IBM公司的HAGEO软件2。 (3)基于数据库备份的方式 通过数据库复制工具将主节点的数据复制到备份节点上，如Oracle公司的Data Guard系统3。 (4)基于私有软件的备份方式 通过内部协议将数据从一个节点备份到另一个节点以实现远程备份。 4种备份方式的特点如图1所示。4种远程备份方式技术比较如表1所示。从复制实时性考虑，数据远程备份技术可以分为同步方式和异步方式： (1)同步方式。同步传输方式数据传输

25、流程如图2所示，数据先写到远端，等完成后再回到本地做写入动作。同步能保证两个地方的数据在任何时刻都保持精确的一致，但显然速度较慢，使得本地生产中心的应用执行效率低，因为它总是要等待两端的数据都写好以后才能继续下一步操 (2)异步方式。异步传输方式数据传输流程如图3所示，资料先写到远端，但不等完成即在本地做写入动作，在本地写完后，给上层应用返回成功响应，速度快。 从数据远程备份技术的体系结构上分可以分为1+1容灾方式和N +1容灾方式： (1)1+1容灾方式 两个生产节点互为主备方式，即HLR1作为生产节点同时还承担HLR2数据备份的任务。当HLR2发生故障时，HLR1接管HLR2的业务，反之亦

26、然。 (2)N +1容灾方式 备份集中在一个备份中心，集中管理，对应多个生产中心。任何一个生产中心故障，业务都会被切换到备份中心。 从生产地点和备份地点的数据库逻辑实现上分可以分为同构数据库容灾和异构数据库容灾方式： (1)同构数据库容灾方式 同构数据库容灾是指生产地点的数据库和备份地点的数据库采用相同的数据模型。 (2)异构数据库容灾方式 异构数据库容灾是指生产地点的数据库和备份地点的数据库采用不同的数据模型。 HLR 容灾系统的实现原理如图4所示。利用多信令点技术，备份地点HLR配置自己以及生产地点HLR的信令点，移动交换中心(MSC)对每个生产地点的HLR和信令连接控制部分(SCCP)做

27、备选路由到备份地点HLR，当生产地点HLR发生故障导致业务不能继续进行时，通过7号信令链路和数据库切换可以将生产地点HLR的全部业务倒换到备份地点HLR，用于实现HLR业务的恢复。两个HLR的数据部件之间由光纤通道或ATM连接，可采用基于逻辑卷或者基于硬件等远程同步技术实现用户数据的同步备份。 HLR业务接管处理过程如下： (1)确定生产地点HLR发生短期内无法恢复的严重故障(以下称其为故障HLR)，需要切换到备份地点HLR。 (2)手工操作数据库同步软件，将该HLR数据库切换到备份地点HLR；因为在同步状态下，备份数据库是不可写的，所以必须要中断同步关系，将备份数据库状态更改为可读可写。 (

28、3)将备份地点HLR配置模块中备用数据库属性由“备用”改为“主用”，同步配置。 (4)手工阻塞故障HLR的7号信令链路，激活备份地点HLR的7号信令链路，将该HLR的7号信令切换到备份地点HLR。2.1.2 ULR业务容灾技术业务容灾是指容灾倒换后，备用HLR能基本上在功能上替代主用HLR，倒换效果较好，用户业务使用连续性基本不受影响的容灾方式。由于目前各厂家HLR设备内部数据结构各不相同，且数据格式互不开放，因此，业务容灾一般只能在同一厂家的HLR之间进行，主用HLR和备份HLR之间通过内部协议进行动态数据的更新，动态数据的更新可以是实时的，也可以是准实时的（根据网上的实际负荷情况，可以用人

29、工的方式定义动态数据更新周期间隔）。当主用HLR发生故障时，由于在容灾实施时，主用HLR相关直连网元设备的配置已经修改为用备用HLR的信令链路作为迂回路由，可以使对原来HLR的信令自动重新路由到容灾备份HLR。由于备份HLR具有和故障HLR同步的数据，因此很容易就接管了故障HLR的一切操作。当故障恢复后，首先恢复该主用HLR的用户数据，然后恢复主用HLR相关信令链路，则相关的信令重新路由到该HLR，这样便实现了故障恢复。1+1互备HLR设备1+1互备容灾方式数据关系如图1所示。HLR设备1+1互备容灾方式是指在HLR配置时，每2台HLR设备之间配置成互为备份的关系，每台的备份容量都等于另外1台

30、HLR的主用容量，互备HLR之间通过IP专网/线或七号信令链路相连，实时或定时进行数据同步，任何静态、动态数据更改都必须实时同步到备份HLR中，互备HLR中的用户数据部分应保持完全一致，并有定期一致性检查能力。当“配对”中的某个HLR故障时，另一台MSC Server能以自动或人工方式激活对故障HLR备份的相关静态配置数据和动态用户数据，接管故障HLR的业务。配置为1+1互备容灾的HLR设备基本网络组织如图2所示。N+1主备HLR设备N+1互备容灾方式数据关系如图3所示。HLR设备N+1容灾方式是指在建设有N个主用HLR的网络中，设置一个备份用的HLR设备，平时N个HLR正常工作，备份用的HL

31、R设备只同时运行与主HLR设备相同的软件和数据，并存储所有主用HLR设备内数据的镜像，而其与外部网元如MSC（G）MSC ServerSGSN/SCPSMSCSTP的信令链路正常连接，且这些链路中一般并无信令负荷，只在与主用HLR的心跳链路（可以通过STP转接）中有定期传递的“心跳”消息。当N个正常工作的HLR中任一个出现故障时，备份HLR将通过“心跳”消息判断出来，并提出告警，在倒换时，加载并激活故障的HLR设备用户数据，从而达到备用的HLR完全接管故障的HLR下用户业务功能的效果。配置为N+1主备容灾的HLR设备基本网络组织如图4所示。N+M主备HLR设备的N+M主备容灾实现，一般是基于用

32、户数据的统一管理的，而其中基于用户数据的统一存储和调用的技术，被称为分布式HLR技术，作为一种新兴的超大容量HLR组网技术，正成为近年来HLR设备制造技术发展的热点。分布式HLR技术，将HLR分为业务前端（FE）和数据后端（BE），分离设置，BE集中存储用户数据，BE一般采用数据库服务器实现，本身也可以做异地分布式设置，BE之间采用内部接口，统一提供用户数据的存储和高可靠性的备份能力；FE完成业务处理，可以实现N+M主备设置。FE使用内部接口，通过IP承载专网对BE进行数据访问。HLR设备N+M主备容灾方式数据关系如图5所示。在N+M主备容灾组网中，建设有N个主用HLR与M个备用HLR，设置一

33、个或多个集中用户数据调度或存储用的数据库设备，平时N个HLR正常工作，实时通过IP承载专网将动静态数据更新传送给数据库，备份用的HLR设备只同时运行与主HLR设备相同的软件和数据，并不激活任何用户数据，而其与外部网元如MSC（G）MSC ServerSGSN/SCPSMSCSTP的信令链路正常连接，且这些链路中一般并无信令负荷。当N个主用HLR中任一个出现故障时，备份HLR将通过分布式HLR故障判断机制发现，并提出告警，在倒换时，通过IP承载专网从用户数据库加载并激活故障的HLR设备用户数据，从而达到备用的HLR完全接管故障的HLR下用户业务功能的效果。配置为N+M主备容灾的HLR设备基本网络

34、组织如图6所示。22. 业务容灾的原则和方式2.2. 1业务容灾配置原则HLR设备业务容灾实现的网元配置原则如下：a） 主备用HLR设备应同厂家设备，并且硬件平台、软件版本保持一致。b） 在1+1互备配置时，任一HLR的容量等于与其配对的两个HLR设备实际动态容量之和。c） N1互备方案：备份HLR设备的动态容量应至少大于等于N个主用HLR中动态容量最大者，才可以保证当N个主用HLR中的任一台发生故障时，倒换后业务的完全接管；而备份HLR的静态容量需要配置为N个主用HLR中动态容量之和，以保证用户数据的存储和实时更新。d） N+M主备方案：任一备份HLR的动态容量应至少大于等于其所备份的主用H

35、LR中动态容量最大者，才可以保证当主用HLR设备中的任一台发生故障时，倒换后业务的完全接管；而BE设备的数据库容量应至少为N台主用HLR设备的动态容量和，以保证用户数据的存储和实时更新。e） 由于业务容灾实现时的配置方式均为各厂家采用备用HLR配置多信令点模式进行支持，备用HLR能够配置的最大信令点数量就成为制约业务容灾方式中最大备份能力的限制条件。当主用HLR数量较多时，该限制条件需要在设备配置中进行考虑。f） 在1+1互备和N+1主备容灾实现时，由于备用HLR需要对所有其备份主用HLR的用户数据进行分别存储，因此，设备的静态数据容量也成为制约其实现的限制条件。当主用HLR总容量较大时，该限

36、制条件需要在设备配置中进行考虑。2.2.2 业务容灾数据同步方式HLR网元级业务容灾的实现，离不开主备用HLR之间用户数据的传递和同步。其中，HLR静态数据的同步方式一般有3种。方式一是改造营账系统，使营账系统具备同时向主备用两个HLR输入操作指令，并对执行失败的指令进行记录的功能，部分厂家提供第三方软件定期核对数据的一致性功能（可选）。方式二是由主用HLR设备实现同步，即营账系统仍只向主用HLR输入操作指令，由主用HLR通过IP承载专网（可以是专为此搭建的IP承载专网/线或者利用现有的网管网或者营账网络等DCN网络）主动向备用HLR发出数据更新，并对执行失败的指令进行记录的功能，部分厂家也提

37、供第三方软件定期核对数据的一致性功能（可选）。方式三是新增一个专用系统，营账系统只需要对此系统输入操作指令，此系统完成将操作指令同时转发给主备HLR设备，并对执行失败的指令进行记录的功能。对于方式三，如果新增系统前端是一套接口设备，网络中仍难免单点故障的隐患，但是新增系统若前端设置两套接口设备，营账系统就无法避免改造需求。因此，方式三只在N+M容灾方式中才会考虑。而HLR的动态数据同步也有2种实现方式。a） 通过No.7信令网进行数据同步，这就需要主备HLR之间通过No.7信令链路传递动态数据同步消息，这些信令链路可以是直连链路也可以通过STP设备转接。b） 通过IP承载专网进行数据同步，即主

38、备HLR之间通过IP承载专网以私有数据包传递动态用户数据同步消息，所使用的IP承载专网可以是专为此搭建的IP承载专网/线，也可以利旧使用现有的网管/营账网络，只需要保证必要的带宽要求和QoS要求即可。2.6 业务容灾对相关网元配置的影响在HLR的业务容灾方案实施时，为了保证容灾效果，在核心网设备侧需要与主用HLR设备直连的核心网元设备和STP设备支持并启用信令路由优先级功能，将到备用HLR设备SPC的信令链路配置为到主用HLR的SPC的备用路由（低优先级路由）。而在营账和网管系统侧，则需要采取如下措施。a） 如果采用营账网络或者网管网络作为动/静态数据同步的承载网络，就需要营账网络、网管网络提

39、供足够的带宽和QoS保障。b） 如果静态数据同步采用方式一，则需要营账系统改造，使之具备同时向主备两个HLR输入操作指令，并对执行失败的指令进行记录的功能。c） 在倒换和倒回完成后，需要及时通知计费和网管中心将采集点IP地址修改为备用（主用）HLR设备的IP地址。2.3 虚拟卷/硬件 基于硬件存储设备的备份方式和操作系统无关，能够在AIX和WINDOWS平台下使用。相对于虚拟卷方式，对系统性能影响小。缺点在于需要特殊规格的磁阵。 基于虚拟卷的软件备份方式和操作系统紧密结合，对系统性能影响较大，但不需要特殊的磁阵配置。 选择基于硬件的复制方式还是基于虚拟卷的复制方式，主要考虑现有硬件情况。对于W

40、INDOWS平台+SQL Server数据库的情况，建议选择基于EMC磁阵的硬件复制方式；对于AIX+Oracle数据库的组合，选择基于硬件和虚拟卷的复制方式都可以。2.4 容灾系统的容量 容灾系统的容量设计需要考虑两个方面的指标：故障接管时的业务处理能力、日常运行时数据同步能力。如果希望故障接管时，保持全业务处理能力。对于采用1+1方式的容灾系统来说，意味着两个HLR必须配置7号前置机和业务处理机为当前运行能力一倍冗余。对于采用容灾中心的容灾系统来说，意味着容灾中心的7号前置机和业务处理机配置应该和业务量最大的一个生产HLR相同。如果希望节约成本，则可以减少冗余设备，甚至只使用当前设备，在故

41、障接管时，通过流量控制，牺牲部分业务。对于数据库节点，需要考虑单个数据库节点能容纳多少用户。在启用容灾系统后，整个系统性能会有很大下降(35%)，意味着如果原系统单数据库节点最大负荷100万用户，那么实行容灾后系统可能只能支持60万用户，需要新增数据库节点，才能满足要求。2.5. HLR容灾的实施建议HLR设备是核心网元容灾中首要考虑的网元设备，其容灾技术经过多年的发展，也都已经比较成熟。在实施核心网HLR容灾备份方案时，不仅要考虑提高HLR设备的容灾能力、提高网络服务质量，还应兼顾经济效益，制定尽可能满足多方面要求的安全保障措施。 在国内移动通信运营商进行HLR容灾规划实施时，建议如下：a）

42、 随着大容量HLR的逐步引入和用户服务质量要求的不断提高，各省级分公司应在满足集中化维护管理的要求的前提下，在满足条件地区积极推进N+1业务容灾备份方案，使业务恢复时间达到分钟级，同时对用户服务质量影响最小。b） 对于目前现网已部署实施完毕的HLR设备容灾备份方案暂不作改造，积极推进分布式HLR的试验和实施。c） 尚未实施及部分实施了HLR设备容灾备份的省公司，可分为以下2种情况，逐步完成对所有大容量HLR设备容灾建设。（a） 对投资效益较好、网络安全可靠性要求较高的省公司，在设备具备支持条件的情况下，可优先采用N+1实时动态数据备份方案，分设备厂家进行HLR容灾建设。（b） 对投资压力较大的

43、省公司，可采用基于N+1静态数据容灾备份方案，以省为单位统一建设备用HLR平台，并建立完善的日常数据备份制度和应急倒换预案，以便充分利用有限的投资成本，提供更好的HLR设备安全保障。另外，在经过充分测试后，可以考虑在新建HLR设备时，开始对用户快速增长地区考虑采用分布式HLR系统提供服务，并对现网无法实施动态数据容灾的陈旧HLR设备，有计划地进行替换，以提高移动通信网HLR设备整体服务质量和可靠性。3. 存储网络容灾备份3.1.概况随着数据的可用性成为区别企业能力的重要指标，企业正在将越来越多的资源用于确保业务的连续运营。思科提供的先进技术可以帮助企业以一种更加可扩展、更加安全、更加经济的方法

44、，建设端到端的备份和恢复解决方案以及灾难恢复解决方案。在服务器上存有关键任务型数据的跨国企业需要为它们的应用提供不间断的可用性。为了防止数据受损，这些数据至少应当定期备份到磁带。但是，不断增长的数据容量需要更大的存储容量、更快的服务器，也需要更长的备份时间。用户还必须考虑到，花几个小时进行备份意味着需要用相同的时间来进行恢复。用户往往无法接受这么长的恢复时间，因为它会导致停机时间的延长，从而导致收入的损失。因此，在很多情况下，磁带备份被视为是灾难恢复(DR)计划的最低等级。为了确保企业应用所需要的99.999%的正常运行时间，存储设计必须在每个级别考虑高可用性因素。所有企业都应制定一个灾难恢复

45、计划，以便在发生大规模中断时无缝地将数据转移到某个备用站点。除了磁带备份以外，企业通常需要在它们的容灾备份计划中，使用复制技术来远程复制整个数据中心。因此，恢复计划现在除了从磁带恢复数据以外，还应当包括在发生故障时将数据中心转移到一个远程地点。灾难可能由多种因素导致，并且很难预测。下面列出了可能导致灾难的主要因素：设备故障、应用故障、人为错误、自然和非自然灾害、 每个企业都必须找出所有需要保存、以实现连续访问的关键性数据，为从灾难中恢复做好充分准备。因此，用户必须进行业务影响和风险分析，以确定对企业最重要的地点、职能或者应用。一个远程数据中心DD即主数据中心的镜像，可以用于在发生大规模灾难之后

46、继续提供完整的访问。很多容灾备份解决方案都需要在将数据备份到磁带的同时，保存数据的实时镜像。复制技术还可以提供适用于不同应用需求的选项。尽管复制技术可以帮助一个企业更快地从灾难性故障中恢复，但是它也存在一定的限制，例如它会将受损数据和有效数据一同复制。因此，企业仍然需要进行磁带备份，以存档有效数据。本文着重介绍作为整个容灾备份计划的一个组成部分的磁带备份的技术、架构和选项。3.2 技术篇3.2.1.磁带备份在今天的企业环境中，大多数应用服务器都是通过并行SCSI直接连接到专用的磁带驱动器上。因为需要管理的磁带设备的数量与应用服务器的数量成正比，所以专用资源的部署和维护成本都很高。但是，直接连接

47、的磁带驱动器可以保障性能，因为服务器是唯一使用驱动器的设备。成本因素促使企业转向网络备份模式，即磁带驱动器放置在一个LAN 上，供多个服务器共享。在一个典型的基于LAN的备份模式中，数据和备份流量都会通过相同的LAN传输。这种网络备份模式有助于提高磁带的利用率和可管理性，但是也会带来一些问题，下面将详细介绍这些问题。首先，需要备份的大量数据会增加LAN 上的流量，导致应用性能的降低。备份通常都在下班之后进行，以便最大限度地减少对应用流量的影响。不断增长的数据量会导致备份时间的延长，有可能需要占用上班时间。随着企业业务的全球化，企业对247 正常运行的要求越来越高，可以用于备份的时间也越来越短。其次，让备份和应用流量都通过LAN 传输，就可能会导致备份中断，进而导致备份任务全都失败。第三，备份和数据应用共用同一个LAN 经常会导致很高的成本，因为一个环境的固件升级或者不稳定性可能会导致另外一个环境的中断。为了在一个共同的LAN 中消除这些潜在的冲突，管理员建议将应用和备份隔离开。在较新的部署中，客户正在向无需LAN 的架构转型，