云南联通容灾实施案例
中国联通云南分公司计费信息系统部 李卫民
2004/05/24
项目概述
本次的容灾工程涉及到云南联通的综合营帐系统、短消息计费系统，分别运行在不同的操作系统平台上，其数据也分布在不同的存储设备上。业务系统已投入生产使用，所以，在整个工程实施过程中减小对运行业务的影响是重中之重。同时，由于各个系统数据分别存储在不同的中档磁盘阵列上，若实现磁盘阵列级容灾，必须采用更高端磁盘阵列，因此，实现容灾业务系统的数据需要迁移到高端的磁盘阵列。
本期工程采用了HP高端磁盘阵列XP512进行远程数据容灾，在云南联通业务中心本地新增一台HP XP512。同时，在异地备份中心新增一台XP512存储服务器，作为主生产中心XP512的异地容灾备份。本次容灾的建设目标是对综合营帐系统、专业计费、短消息计费系统进行同城异地数据级容灾的综合数据容灾系统，业务系统的数据将可以通过基于XP磁盘阵列的Continuous Access XP软件实时同步复制到备份数据中心的XP512中，从而实现数据的远程保护
下图是方案规划的容灾系统示意图（见图1）。
硬件环境的搭建在此就不赘述，下面主要从整个工程的重点和难点：系统迁移进行着重介绍。
系统迁移需求分析
在本次案例实施中，选取营业系统的迁移做简要说明。
一、系统现状
综合营账系统应用目前运行在两台主机superdome组成的群集上，其中一台运行营业的应用，另一台运行账务的应用。数据存储在一台MA8000磁盘阵列中，由于系统数据量较大，营业和账务的数据迁移工作必须分开进行，所以在一个系统数据迁移完毕后，MA8000磁盘阵列仍然需要在线，以保证其他系统迁移前的正常工作。
二、系统数据迁移要求
由于需迁移系统均为在线运行，因此，要尽量减少业务的影响。为此，整个迁移过程必须按以下步骤进行：
1．营业系统负责全省所有业务受理及客服系统的查询，如发生长时间中断，会对业务及公司形象带来非常不利影响。因此，业务中断必须在夜间或业务量较少时进行。
2．迁移前必须制定详细的时间计划表，每一步骤必须有专人负责。
3．系统要求：在迁移过程中系统设备具有可恢复性（事先做好备份和回退计划），迁移后系统能够运行正常。
4．数据要求：保证数据的完整性和可恢复性。
三、风险分析
由于目前营业系统属于实时生产系统，保证系统应用在停机迁移后仍能正常启动服务和系统数据在迁移过程中不受损坏是本次迁移的重点。因此本次系统迁移责任非常重大，如果没有周密的计划、精心的组织，一旦出现问题，必将导致重大的责任事故。为了保证迁移的顺利实施，根据系统现状进行了风险分析。
实施原则
完成项目的总原则是：按照方案的要求完成系统迁移工作，尽可能减少对营业业务的影响。
由于责任重大，当在实施中发生便捷与风险的矛盾时，要永远将规避风险放在首位。
实施重点
实施的重点在于系统迁移的前期准备、迁移后数据一致性检查及应用的测试验证工作。
系统迁移的切换发生在一个时间段，怎样把这个时间段缩短，进而保证对整个系统的影响最小、风险最小，这就需要我们把前期准备做好、做足。
实施难点
实施的难点在于系统迁移过程中应急情况下系统和数据的可恢复性。
通过与相关人员的讨论，确定了系统和数据的备份方案并论证了操作的可恢复性。
存在风险
项目中的风险贯穿于整个实施过程，在项目实施前应充分考虑到所有可能存在的风险，考虑出现风险时的应急措施，采取相应的手段规避风险。可能存在的风险有：
1.系统迁移的数据量较大，需要计划足够的时间；
2.设备在迁移中损坏，需要原厂及时响应；
3.系统结构比较复杂，营业系统的迁移可能对客服系统产生影响。
营业系统迁移计划
根据以上分析，总体计划分为前期准备阶段、系统迁移实施阶段和迁移后系统试运行阶段三个阶段。
一、 前期准备阶段
前期准备阶段是整个系统迁移成功的关键，该阶段需要完成的工作有：
1.掌握系统的现状、分布、IP地址、用途等，制定详细迁移任务清单；
2.通过实验确定系统迁移的操作并估算数据迁移需要的时间；
3.论证系统和数据备份的方式；
4.在XP512磁盘阵列上划分数据移植所需的磁盘空间；
5.确立实施时间表及人员配备与分工；
6.制定可行的应急方案，论证操作的可恢复性；
7.了解需求的基础上，分析项目实施重点和难点，对迁移的实施进行深层次的讨论，并就各方负责的实施部分的责任和实施细节进行细化，确立各方面负责人。最终产生一份科学可行、安全稳妥、组织严谨、符合要求的系统迁移实施方案。
二、 系统迁移实施阶段
为了系统的可靠性、数据的完整性和可恢复性，应对现有系统进行软硬件方面的检测，并对系统和数据进行备份，一旦在迁移过程中发生问题，可以马上恢复原有系统，保证系统运行。在此阶段需要完成的工作有：
1.迁移前的设备检测，系统、数据备份（如数据库未打开归档，需在实施迁移前打开）；
2.完成营业系统数据迁移，包括数据库、文件系统、系统参数调整等；
3.系统迁移后的数据一致性检测。
其中系统备份前最好对设备硬件和软件分别进行检查，确认迁移前系统处于正常状态。迁移的每个步骤都要按事先的规划进行，并确保操作的可逆性，一旦出现问题系统可以回退到迁移前状态。
营业系统迁移应急措施
一、系统迁移前的异常
如果在规划的时间点之前没有完成系统迁移准备阶段的任务，系统迁移时间顺延，在确保准备工作就绪的前提下才进行系统迁移。在系统开始迁移前请相关人员进行系统健康性检查，确保在迁移前系统完好。
二、系统迁移过程中的异常
本次营业系统迁移的原则是确保系统在规划的迁移时间段之外可以正常运行。由于营业系统迁移安排在夜间进行，为确保系统在发生硬件或软件故障时能够及时得到技术响应，需要协调各相关人员（包括原厂商技术人员）到位。在执行迁移的过程中操作步骤具有可逆性，确保以外发生的时候可将系统迅速回退到最初状态。系统和数据在迁移前都做最新的备份。如果迁移工作在凌晨6：00前没有完成，也要将系统回退到迁移前状态，保障系统在8：00前正常运行。
三、 系统迁移后的异常
营业系统在数据迁移到XP512后，原有MA8000磁盘阵列中的数据继续保留一段时间，以观察新系统的稳定性。如果在试运行期新系统发生故障，仍可以让营业系统回退到迁移前状态。
数据库迁移
一、数据库信息调查
数据库的迁移主要是所有数据文件、重做日志、控制文件的迁移，在准备阶段需调查清楚所有在用的数据文件、重做日志、控制文件所在裸盘的详细情况。同时建议数据库管理员在迁移前尽量不要添加新的数据文件，如遇特殊情况需增加新的数据文件，则必须通知工程项目组对已调查的数据进行更新。
二、在XP512上创建物理卷组和对应的逻辑卷
根据收集的信息,在XP512上为营业系统划分的物理空间上创建新卷组，然后在新卷组上创建逻辑卷，最后给主机数据库用户分配权限。
三、数据库备份与迁移
营业数据库采用的是ORACLE。推荐采用物理备份，该方法实现数据库的完整恢复，但数据库必须运行在归档模式下，且需要足够的外部存储设备，例如磁带库、硬盘空间等。物理级的备份主要是备份数据文件、控制文件、联机重做日志文件、归挡日志文件、回退段等。
1. Oracle数据库物理备份准备。
A 打开数据库归档；
B 数据库移植前几天做一次全备,移植当天晚上做增量备份；
2. 数据库物理备份。
A 使用dd拷贝和在sqlplus下用"alter database backup controlfile to trace"分别备份数据库控制文件；
B 数据库做增量备份。
3．修改inityy.ora文件，指定新的controlfile name（在XP512上），确保数据库可以启动，确保归档备份目录有足够空间。
4．停主机上所有应用程序，正常宕数据库，完后重启数据库（不启监听），根据业务情况编写SQL提取一致性数据，将结果用spool输出至一文本文件中保存。此外建议使用"alter system switch logfile"将所有日志组均做一次切换。
5．再次检查数据库数据文件是否与调查结果一致。
6．正常宕数据库，用dd物理移植数据文件、控制文件、日志文件到XP512上，实际可生成多个shell并行执行。
7．在XP512上启动数据库到mount状态，将数据文件指向XP512。
8．将数据库open，在XP512上给tempspace增加新的数据文件，然后删除原来MA8000上的数据文件。
9．运行迁移前的同一SQL提取一致性数据，将新生成的文本文件与迁移前生成的文本文件比较是否一致。
10．在测试环境中进行应用程序的验证。
四、 异常情况处理
原存储设备MA8000的逻辑卷不会立即删除, 这样原来数据库数文件，日志文件不会丢失，即便有控制文件更改，也可用控制文件恢复, 如迁移有问题或时间过长，要留出恢复时间，用原来数据文件、日志文件、控制文件启动原数据库。要求在测试阶段，只能对数据库的内容进行可控的增加、删除、修改。只有多方确认无问题情况下，才能启动应用。同时做好归档的保存,如联机重做日志少,可考虑增加几组联机重做日志。
工程试运行及演习
系统迁移工作成功后，工程即进入试运行阶段，在此期间相关人员需定时观察主机运行状态、主备两个中心XP512的同步状态及数据库运行状态并记录。系统稳定运行后，应制定定期进行主备中心切换的容灾演习制度，发现问题立即解决，确保在发生灾难时系统的可恢复性。
中国计费网(www.billingchina.com)
相关链接: