按照本期招标采购要求,中心在建成后要实现对迁移应用和新建业务平台的一体化集成。 考虑到需要迁移的指挥中心现有应用包含了分析管理平台、指挥平台,上述平台都是中心的核心、重要应用,因此我公司认为原系统的搬迁将是项目建设的重点和难点。 本方案设计以我公司与用户现系统承建公司的初步技术交流、用户现状分析为基础,给出搬迁方案设计。
按照用户招标要求,本期系统迁移的具体需求分析如下。 中心原有应用系统将全部迁移至虚拟化服务平台,迁移期间必须保证工作不能中断,历史数据不能损失;迁移后的系统与多媒体融合通信指挥平台融合对接。 系统迁移的难点是系统切割时间节点的合理规划和确保电话接入路由的转换,历史数据的无损迁移也是系统搬迁的难点和重点。
通过对中心现有上述应用迁移的需求分析,鉴于原系统建设单位并非我公司,迁移过程中还存在对原建设厂商协调的工程风险。我公司认为系统迁移的重点内容包括:涉及运营商的接入切割,原有数据的迁移,合理切割时间节点规划。
中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移方案设计中,我们重点考虑几个问题。
业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险,这样的风险特别对于时间敏感型数据和数据完整性业务都是不可接受的。我们给予这样的要求,考虑到如何将停机时间最小,能否实现0停机的建设目标? 1、对于服务器操作系统而言,我们可以采用P2V的方式,利用操作系统的Volume Shadow Copy卷影副本复制服务作为基础,来实现在旧系统环境下的系统无修改,不停机的情况下,将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。 2、对于应用中间件和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中,在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状态的安全性,我们可以采用会话数据库复制管理。 3、对于数据库而言,我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁移的不停机,而且还可以保证万一迁移中出现停机故障也不影响源数据库,而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行,这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。
针对×××系统等需要确保不间断对外提供服务的应用,需要通过对用户历史应用进行分析,选择最优的切割时间节点,并提切割期间的备份链路、人工受理手段。
迁移涉及到应用、实例、数据库的操作以外,还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。
按照用户招标要求,本次项目建设的服务硬件环境主要是从原有刀片服务器向本次招标新采购云服务平台的迁移。云服务平台支持对原有服务器硬件环境和操作系统环境虚拟,可以降低迁移的难度。
迁移前,我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派员勘察现有系统的架构和资源使用状况,评估过程必须包含以下信息和内容:
通过对现有网络环境的评估,我们对现有资源利用率,服务以及系统需求非常清晰并进行评估后才能开始对迁移进行计划,步骤如下:
迁移计划后,执行小批量的测试迁移方案,这里会涉及到首批迁移的测试和审核,步骤如下:
在第一批服务器和服务的小批量测试迁移后,需对迁移后的服务器进行测试,包括单元测试和性能测试。
在迁移实施过程中,所有的服务器都会被迁移到虚拟化系统下。执行步骤如下:
为了对旧系统中的物理服务器进行虚拟化,需考虑服务器虚拟化带来的影响。例如,现有服务器的重复利用,服务器虚拟化时会对这些服务器的CPU,内存以及硬盘资源进行再利用,然而这些服务器上存在某些服务仍在运行,若无备份则会影响现有业务。因此,在执行迁移和虚拟化之前,必须先对需利旧的服务器进行备份。 提供物理备份服务器,并已进行虚拟化,数据和服务器已备份到虚拟化系统。
迁移的具体步骤及描述如下:
运营商接入链路(路由)的迁移主要是新中心所需物理链路的申请,电话号码接入路由制作、应用正式切割前测试号码的开通以及切割当日应急措施。针对前四部分内容,可以按照中心需要完全备份一份,在系统正式切割前进行模拟运行测试。 切割当日要做好应急保障措施,如切割一旦不成功,迅速切回原路由保障系统的运行。同时在新指挥备份足够的备份链路,支持人工受理。 上述链路的具体配置方案在中标后进一步确认。
针对本项目建设,我们将在应用系统和数据库迁移前,在用户新招标采购的云平台中部署与原应用一样的操作系统、中间件、服务器管理平台软件环境,确保迁移的环境变化风险最低。
针对本项目应用系统迁移,原系统全部是基于Tomcat应用环境、Java应用程序框架。本方案计划对Tomcat等应用环境以及Java应用程序框架提出构建Tomcat环境的NLB群集,将当前系统不停机加入到NLB群集中,使之成为群集中的一个节点,而新环境则为另外一个节点。实施完成后再退出此迁移群集,将新环境加入到新的构建的NLB群集。 NLB不但能实现均衡负载,而且还能实现多种形式的冗余。NLB主要用于那些文件改动不大,并且不常驻内存的环境,比如WEB服务、FTP服务、和VPN服务等。 当用户访问集群的时候,集群能将访问请求分摊到集群中的每个服务器上,以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中,每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB要求至少两个节点,其中一个节点不能使用,这全部负载将落入到剩下的那个节点上,即全载。NLB能提供三种冗余功能,软件冗余、硬件冗余、站点冗余。
针对本项目数据库迁移,需要将中心积累的历史数据文件搬迁到新中心服务器,并且要求最小宕机时间,同时面临的难点还包括服务器并不在同一个一个机房。
针对本项目建设,涉及中心生产系统的搬迁,上述系统具有停机时间要求短、系统结构复杂、测试时间长、设备繁多、使用人员多、层次复杂等特点。本项目搬迁,时间非常紧,且设备间的稳定性也是一个考验。因此,必须协调好各单位人员的关系,齐心协力才可能在预定时间内完成搬迁工程。 本项目搬迁组织以尽量不影响日常工作或将影响降低到最低为前提的情况下制定,即在保障内容最少日的最少时间节点开始搬迁,尽快完成必须搬迁的服务器、网络设备的搬迁、安装及测试。并且在开机以后,继续跟踪系统的运行情况,随时处理系统运行的异常情况。搬迁需要原系统建设公司人员的充分协调及配合下才能完成本次搬迁任务。
实施流程:
为了搬迁能按时顺利进行,并且在搬迁后能够保证设备正常运行,我们制定了一系列简单明了的工作表,帮助工程实施人员确定各种搬迁工作中要执行的工作是否完成。避免工作失误,避免造成搬迁工作的延误。 实施流程:目的机房的要求: 需要在搬迁前检查目的机房的必要设备设施是否符合要求,本工作表是保证搬迁后设备能否稳定正常运行的先决条件,在搬迁前由搬迁负责人同相关人员填写确认。
在设备搬迁后出现异常情况时现场技术人员立即检查设备,检查故障现象,确定故障位置。 硬件故障在备件准备范围内的立即更换,不在范围内的立即使用备用设备,最短时间内启用备用设备。由于配置数据或系统不能启动的,立即使用系统光盘备份数据等先前准备的备用工具软件,系统软件重新按装或恢复。
本文作者:Gustav
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!