1.1
1.2 总述 ......................................................................................................................................... 2 系统迁移需求分析 ................................................................................................................. 2
中心系统迁移需求分析总体结论 ................................................................................. 2
1.3 迁移方案总体思路 ................................................................................................................. 2
1.3.1 保障业务中断停机时间最小化 ..................................................................................... 3
1.3.2 业务切割时间节点优化 ................................................................................................. 3
1.3.3 迁移后完整性测试 ......................................................................................................... 4
1.4 服务器硬件环境迁移方案 ..................................................................................................... 4
1.4.1 迁移评估 ......................................................................................................................... 4
1.4.2 迁移计划 ......................................................................................................................... 4
1.4.3 测试计划 ......................................................................................................................... 5
1.4.4 迁移测试 ......................................................................................................................... 5
1.4.5 迁移实施 ......................................................................................................................... 6
1.5 运营商接入链路(路由)迁移 . ............................................................................................. 8
1.6 应用系统和数据库迁移方案.................................................................................................. 8
1.6.1 应用服务器迁移 ............................................................................................................. 8
1.6.2 数据库迁移实施 ............................................................................................................. 9
1.7 系统迁移的具体组织实施方案 . ........................................................................................... 10
1.7.1 搬迁规划 ....................................................................................................................... 10
1.7.2 详细实施方案 ............................................................................................................... 11
1.7.3 应急处理 ....................................................................................................................... 11 1.2.1
1.1 总述
按照本期招标采购要求,中心在建成后要实现对迁移应用和新建业务平台的一体化集成。
考虑到需要迁移的指挥中心现有应用包含了分析管理平台、指挥平台,上述平台都是中心的核心、重要应用,因此我公司认为原系统的搬迁将是项目建设的重点和难点。
本方案设计以我公司与用户现系统承建公司的初步技术交流、用户现状分析为基础,给出搬迁方案设计。
1.2 系统迁移需求分析
按照用户招标要求,本期系统迁移的具体需求分析如下。
中心原有应用系统将全部迁移至虚拟化服务平台,迁移期间必须保证工作不能中断,历史数据不能损失;迁移后的系统与多媒体融合通信指挥平台融合对接。
系统迁移的难点是系统切割时间节点的合理规划和确保电话接入路由的转换,历史数据的无损迁移也是系统搬迁的难点和重点。
1.2.1 中心系统迁移需求分析总体结论
通过对中心现有上述应用迁移的需求分析,鉴于原系统建设单位并非我公司,迁移过程中还存在对原建设厂商协调的工程风险。我公司认为系统迁移的重点内容包括:涉及运营商的接入切割,原有数据的迁移,合理切割时间节点规划。
1.3 迁移方案总体思路
中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移方案设计中,我们重点考虑几个问题。
1.3.1 保障业务中断停机时间最小化
业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险,这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求,考虑到如何将停机时间最小,能否实现0停机的建设目标?
1、对于服务器操作系统而言,我们可以采用P2V 的方式,利用操作系统的V olume Shadow Copy卷影副本复制服务作为基础,来实现在旧系统环境下的系统无修改,无停机的情况下,将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。
2、对于应用中间件和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中,在部分应用服务中我们可以使用session 会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状态的安全性,我们可以采用会话数据库复制管理。
3、对于数据库而言,我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁移的不停机,而且还可以保证万一迁移中出现停机故障也不影响源数据库,而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行,这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。
1.3.2 业务切割时间节点优化
针对×××系统等需要确保不间断对外提供服务的应用,需要通过对用户历史应用进行分析,选择最优的的切割时间节点,并提切割期间的备份链路、人工受理手段。
1.3.3 迁移后完整性测试
迁移涉及到应用、实例、数据库的操作以外,还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。
1.4 服务器硬件环境迁移方案
按照用户招标要求,本次项目建设的服务硬件环境主要是从原有刀片服务器向本次招标新采购云服务平台的迁移。云服务平台支持对原有服务器硬件环境和操作系统环境虚拟,可以降低迁移的难度。
1.4.1 迁移评估
迁移前,我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派员勘察现有系统的架构和资源使用状况,评估过程必须包含以下信息和内容:
现有系统支撑的服务数量以及在服务器中的分布情况;
现有物理服务器资源占用状况,包括CPU 、内存、磁盘和网络连接状况,为保证迁移成功,目标虚拟机规格应不低于原物理机标准;
当前的物理环境是否支持虚拟化,是否支持资源扩展,因为在迁移之前须在物理服务器上完成虚拟化;
对当前的存储容量和资源利用率进行评估,需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用,比如有些服务器是在本地磁盘上创建系统盘和用户盘,有些服务器则在本地磁盘上创建系统盘而在SAN/NAS上创建用户盘。
1.4.2 迁移计划
通过对现有网络环境的评估,我们对现有资源利用率,服务以及系统需求非常清晰并进行评估后才能开始对迁移进行计划,步骤如下:
1、确定迁移步骤,包括所有服务器的迁移先后顺序,其顺序按风险的高低降序排列。
2、确定备份方案,由于现有系统会被加固,某些服务器通过虚拟化重复利用,而在虚拟化前需要清除所有的数据,因此需要对这些服务器进行备份保证服务的连续性。
3、确定并准备好迁移所需的工具,包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。
4、在实际迁移开始之前确定额外的测试环境,该测试环境能够引导测试从而确保迁移成功。因此,测试环境需明确设计的服务器和存储数量。
5、规划网络环境,由于网络中的服务器各处不同位置,因此在迁移中需考虑到网络连接情况、数据备份方式,以及网络流量来源,确定网络流量是否会引发网络拥塞
6、确定迁移周期以及参与人员,包括迁移起止时间,团队能力建设以及团队成员的角色。
1.4.3 测试计划
迁移计划后,执行小批量的测试迁移方案,这里会涉及到首批迁移的测试和审核,步骤如下:
准备用于测试迁移的测试系统环境,在测试时,第一批服务器将会迁移到该系统环境中。
安装并核实迁移工具,此时要执行第一批服务器的P2V 迁移。
对第一批服务器,需分析存储系统,不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS存储系统。
1.4.4 迁移测试
在第一批服务器和服务的小批量测试迁移后,需对迁移后的服务器进行测试,包括单元测试和性能测试。
1.4.5 迁移实施
在迁移实施过程中,所有的服务器都会被迁移到虚拟化系统下。执行步骤如下:
确保批量迁移的整个网络环境已准备完毕,并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。
对迁移系统进行性能审核和健康检查,如果系统状态监视则停用旧系统并将其服务暂时转移到新的虚拟化系统中。
进行利旧,对于一部分可用的旧硬件可在服务器虚拟化中重新再利用,一些软件资源需扩展,如内存和硬盘。这些服务器构成最终的虚拟化基础设施,即最终系统。
最后,在目标系统和最终系统之间进行V2V 迁移。
1.4.5.1 服务器虚拟化前进行备份
为了对旧系统中的物理服务器进行虚拟化,需考虑服务器虚拟化带来的影响。例如,现有服务器的重复利用,服务器虚拟化时会对这些服务器的CPU ,内存以及硬盘资源进行再利用,然而这些服务器上存在某些服务仍在运行,若无备份则会影响现有业务。因此,在执行迁移和虚拟化之前,必须先对需利旧的服务器进行备份。
提供物理备份服务器,并已进行虚拟化,数据和服务器已备份到虚拟化系统。 首先,对于要被迁移的服务器上,一般会存在多种服务正在运行,而且这些服务器在迁移评估后认为在虚拟化场景下可再利用的。但是,迁移过程中不允许存在较长的停机时间,因此需要准备一台采用虚拟化平台的备份虚拟机,通过P2V 将该服务器备份到虚拟机上。
备份完所有需要进行虚拟化的服务器之后,这些服务器上安装虚拟化软件进行虚拟化,根据评估阶段确定的容量规划,在虚拟化平台上创建相应规格的虚拟机,其计算资源用于承接旧系统中的服务。
准备好所有的虚拟机后,规划和安装相关迁移工具,将备份系统中的服务迁移到虚拟化系统的虚拟机中。虚拟机迁移是指将备份的虚拟化系统中的应用服务迁移到最终的虚拟化系统中。
虚拟机迁移完毕后,要对这些服务进行测试,最后停用旧系统,所有服务切换到虚拟化系统中。
1.4.5.2 迁移的详细操作步骤
迁移的具体步骤及描述如下:
1、在评估阶段,虚拟化和迁移之前需收集的信息如下:
性能统计:包括CPU 使用率,内存使用率,硬盘IOPS 和硬盘使用情况; 物理服务器配置:包括CPU 规格,内存容量,硬盘容量
统计物理服务器部署位置,分析是否支持虚拟化,累计支持虚拟化的服务器数量,并规划出虚拟化中需新增的硬件情况;
通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。可采用信息收集工具。
2、分析现有服务的依赖条件,对当前系统进行备份。
确定应用系统对服务器的依赖关系,可作为迁移参考,确定所有服务器的迁移优先级顺序。
在确定各服务的依赖条件后,对需进行虚拟化的服务器进行备份。
3、容量规划和虚拟化执行
根据当前的资源使用和需求情况,计算虚拟化所需的容量。
4、规划应用服务
在拟化解决方案中,同类虚拟机部署在同一个计算资源池中,在同一个池中可相互共享存储/计算资源,一个集群的故障不会影响其他资源池。
5、虚拟化规划和虚拟机分配
建立虚拟化平台后,要准备最终的迁移资源。迁移前,如果服务器a 具备双核CPU 和2G 内存,那么在虚拟化平台中就创建一个2核/2G内存的虚拟机,并分配相应的硬盘。
6、 规划迁移工具
采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进行磁盘复制。
7、通过工具执行在线迁移
准备好源系统,目标虚拟机以及目标系统后,决定迁移时需使用的迁移工具和迁移策略。
8、迁移测试
迁移后,需进行测试来验证迁移是否成功,测试场景如下:
应用服务迁移后对虚拟化基本功能的监测;
迁移前后应用服务的特性功能是否几乎相同;
虚拟化系统的性能监控;
….
9、停用旧系统
截至目前现有的服务器已经被虚拟化和重复使用,其他一些不支持虚拟化的服务器上对应的服务也已经迁移到虚拟化平台,那么现在可将应用服务切换到虚拟系统并停用旧系统。
1.5 运营商接入链路(路由)迁移
运营商接入链路(路由)的迁移主要是新中心所需物理链路的申请,电话号码接入路由制作、应用正式切割前测试号码的开通以及切割当日应急措施。针对前四部分内容,可以按照中心需要完全备份一份,在系统正式切割前进行模拟运行测试。
切割当日要做好应急保障措施,如切割一旦不成功,迅速切回原路由保障系统的运行。同时在新指挥备份足够的备份链路,支持人工受理。
上述链路的具体配置方案在中标后进一步确认。
1.6 应用系统和数据库迁移方案
针对本项目建设,我们将在应用系统和数据库迁移前,在用户新招标采购的云平台中部署与原应用一样的操作系统、中间件、服务器管理平台软件环境,确保迁移的环境变化风险最低。
1.6.1 应用服务器迁移
针对本项目应用系统迁移,原系统全部是基于IIS 应用环境、.NET 应用程序框架。本方案计划对IIS 等应用环境以及.net 应用程序框架提出构建IIS 环
境的NLB 群集,将当前系统不停机加入到NLB 群集中,使之成为群集中的一个节点,而新环境则为另外一个节点。实施完成后再退出此迁移群集,将新环境加入到新的构建的NLB 群集。
NLB 不但能实现均衡负载,而且还能实现多种形式的冗余。NLB 主要用于那些文件改动不大,并且不常驻内存的环境,比如WEB 服务、FTP 服务、和** 服务等。
当用户访问集群的时候,集群能将访问请求分摊到集群中的每个服务器上,以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中,每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB 要求至少两个节点,其中一个节点不能使用,这全部负载将落入到剩下的那个节点上,即全载。NLB 能提供三种冗余功能,软件冗余、硬件冗余、站点冗余。
1.6.2 数据库迁移实施
针对本项目数据库迁移,需要将中心积累的历史数据文件搬迁到新中心服务器,并且要求最小宕机时间,同时面临的难点还包括服务器并不在同一个一个机房。
1、分析与设计思路
针对本项目数据库搬迁环境特点:第一个是数据库文件比较大;第二是传送文件的速度可能会比较慢(广域网传输)。初步解决方案如下。
为了使宕机时间最短,我们这里使用完整备份和差异备份来迁移数据库,在白天的时候对需要迁移的数据库进行一次完整备份(XXX_full.bak),并把备份文件拷贝(这里可以使用FTP 软件进行断点续传)到目标服务器进行还原,等到下班时间之后再进行一次差异备份(XXX_diff.bak),再把这个差异备份拷贝到目标服务器,在完整还原的基础上再进行差异还原。
这里的宕机时间 = 差异备份时间 + 传送差异备份文件时间 + 还原差异备份文件时间,不存在宕机时间。
2、保证数据迁移过程中的安全性和操作可审计性
数据迁移中的安全性不可忽略,本方案设计基于多重数据审计功能实现迁移
安全性和操作审计性。
1.7 系统迁移的具体组织实施方案
针对本项目建设,涉及中心生产系统的搬迁,上述系统具有停机时间要求短、系统结构复杂、测试时间长、设备繁多、使用人员多、层次复杂等特点。本项目搬迁,时间非常紧, 且设备间的稳定性也是一个考验。因此,必须协调好各单位人员的关系,齐心协力才可能在预定时间内完成搬迁工程。
本项目搬迁组织以尽量不影响日常工作或将影响降低到最低为前提的情况下制定,即在保障内容最少日的最少时间节点开始搬迁,尽快完成必须搬迁的服务器、网络设备的搬迁、安装及测试。并且在开机以后,继续跟踪系统的运行情况,随时处理系统运行的异常情况。搬迁需要原系统建设公司人员的充分协调及配合下才能完成本次搬迁任务。
1.7.1 搬迁规划
实施流程:
流程主要根据搬迁前的需要制定,主要详细了解当前系统设备情况,系统运行情况。针对所了解情况制定详细搬迁方案以及应急方案。
专业工程师了解用户现在机房的现状以及搬迁后的具体要求。充分考虑在实施过程中可能出现的各种情况,定制详细可行性的迁移实施计划,将机房迁移工作对用户的影响降至最小。
编制搬迁前及搬迁后的物理布置表、连接表、线缆号表。可根据用户情况分为多个系统进行分类。
在搬迁过程中需要XXX 技术人员密切配合。
为保证搬迁工作顺利、有序、安全的进行将制定详细的搬迁流程,进行细致的分工,具体工作安排到人,责任到人。
搬迁工作中的每项工作原则最少安排(2)人,以保证工作的准确性。
1.7.2 详细实施方案
为了搬迁能按时顺利进行,并且在搬迁后能够保证设备正常运行,我们制定了一系列简单明了的工作表,帮助工程实施人员确定各种搬迁工作中要执行的工作是否完成。避免工作失误,避免造成搬迁工作的延误。
实施流程:
目的机房的要求:
需要在搬迁前检查目的机房的必要设备设施是否符合要求,本工作表是保证搬迁后设备能否稳定正常运行的先决条件,在搬迁前由搬迁负责人同相关人员填写确认。
1.7.3 应急处理
在设备搬迁后出现异常情况时现场技术人员立即检查设备,检查故障现象,确定故障位置。
硬件故障在备件准备范围内的立即更换,不在范围内的立即使用备用设备最
短时间内启用备用设备。由于配置数据或系统不能启动的立即使用系统光盘备份数据等先前准备的备用工具软件系统软件重新按装或恢复。
专业信息化应用系统迁移方案
1 某中心应用系统迁移方案
目录
1 某中心应用系统迁移方案 ...........................................................................................................................1 1.1 总述 ..........................................................................................................................................................2 1.2 系统迁移需求分析 ...............................................................................................................................2 1.2.1 中心系统迁移需求分析总体结论 ...........................................................................................2 1.3 迁移方案总体思路 ...............................................................................................................................2 1.3.1 保障业务中断停机时间最小化 ................................................................................................2 1.3.2 业务切割时间节点优化 .............................................................................................................3 1.3.3 迁移后完整性测试 ......................................................................................................................3 1.4 服务器硬件环境迁移方案 ..................................................................................................................4 1.4.1 迁移评估 ........................................................................................................................................4 1.4.2 迁移计划 ........................................................................................................................................4 1.4.3 测试计划 ........................................................................................................................................5 1.4.4 迁移测试 ........................................................................................................................................5 1.4.5 迁移实施 ........................................................................................................................................5 1.5 运营商接入链路(路由)迁移 .........................................................................................................8 1.6 应用系统和数据库迁移方案..............................................................................................................8 1.6.1 应用服务器迁移...........................................................................................................................8 1.6.2 数据库迁移实施...........................................................................................................................9 1.7 系统迁移的具体组织实施方案 .........................................................................................................9 1.7.1 搬迁规划 ..................................................................................................................................... 10 1.7.2 详细实施方案 ............................................................................................................................ 10 1.7.3 应急处理 ..................................................................................................................................... 11
1
1.1 总述
按照本期招标采购要求,中心在建成后要实现对迁移应用和新建业务平台的一体化集成。
考虑到需要迁移的指挥中心现有应用包含了分析管理平台、指挥平台,上述平台都是中心的核心、重要应用,因此我公司认为原系统的搬迁将是项目建设的重点和难点。
本方案设计以我公司与用户现系统承建公司的初步技术交流、用户现状分析为基础,给出搬迁方案设计。
1.2 系统迁移需求分析
按照用户招标要求,本期系统迁移的具体需求分析如下。
中心原有应用系统将全部迁移至虚拟化服务平台,迁移期间必须保证工作不能中断,历史数据不能损失;迁移后的系统与多媒体融合通信指挥平台融合对接。
系统迁移的难点是系统切割时间节点的合理规划和确保电话接入路由的转换,历史数据的无损迁移也是系统搬迁的难点和重点。
1.2.1 中心系统迁移需求分析总体结论
通过对中心现有上述应用迁移的需求分析,鉴于原系统建设单位并非我公司,迁移过程中还存在对原建设厂商协调的工程风险。我公司认为系统迁移的重点内容包括:涉及运营商的接入切割,原有数据的迁移,合理切割时间节点规划。 1.3 迁移方案总体思路
中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移方案设计中,我们重点考虑几个问题。
1.3.1 保障业务中断停机时间最小化
业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险,这
2
样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求,考虑到如何将停机时间最小,能否实现0停机的建设目标,
1、对于服务器操作系统而言,我们可以采用P2V的方式,利用操作系统的Volume Shadow Copy卷影副本复制服务作为基础,来实现在旧系统环境下的系统无修改,无停机的情况下,将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。
2、对于应用中间件和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中,在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状态的安全性,我们可以采用会话数据库复制管理。
3、对于数据库而言,我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁移的不停机,而且还可以保证万一迁移中出现停机故障也不影响源数据库,而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行,这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。
1.3.2 业务切割时间节点优化
针对×××系统等需要确保不间断对外提供服务的应用,需要通过对用户历史应用进行分析,选择最优的的切割时间节点,并提切割期间的备份链路、人工受理手段。
1.3.3 迁移后完整性测试
迁移涉及到应用、实例、数据库的操作以外,还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁
3
移的安全性和有效性。
1.4 服务器硬件环境迁移方案
按照用户招标要求,本次项目建设的服务硬件环境主要是从原有刀片服务器向本次招标新采购云服务平台的迁移。云服务平台支持对原有服务器硬件环境和操作系统环境虚拟,可以降低迁移的难度。
1.4.1 迁移评估
迁移前,我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派员勘察现有系统的架构和资源使用状况,评估过程必须包含以下信息和内容:
现有系统支撑的服务数量以及在服务器中的分布情况;
现有物理服务器资源占用状况,包括CPU、内存、磁盘和网络连接状况,为保证迁移成功,目标虚拟机规格应不低于原物理机标准;
当前的物理环境是否支持虚拟化,是否支持资源扩展,因为在迁移之前须在物理服务器上完成虚拟化;
对当前的存储容量和资源利用率进行评估,需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用,比如有些服务器是在本地磁盘上创建系统盘和用户盘,有些服务器则在本地磁盘上创建系统盘而在SAN/NAS上创建用户盘。
1.4.2 迁移计划
通过对现有网络环境的评估,我们对现有资源利用率,服务以及系统需求非常清晰并进行评估后才能开始对迁移进行计划,步骤如下:
1、确定迁移步骤,包括所有服务器的迁移先后顺序,其顺序按风险的高低降序排列。
2、确定备份方案,由于现有系统会被加固,某些服务器通过虚拟化重复利用,而在虚拟化前需要清除所有的数据,因此需要对这些服务器进行备份保证服务的连续性。
4
3、确定并准备好迁移所需的工具,包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。
4、在实际迁移开始之前确定额外的测试环境,该测试环境能够引导测试从而确保迁移成功。因此,测试环境需明确设计的服务器和存储数量。
5、规划网络环境,由于网络中的服务器各处不同位置,因此在迁移中需考虑到网络连接情况、数据备份方式,以及网络流量来源,确定网络流量是否会引发网络拥塞
6、确定迁移周期以及参与人员,包括迁移起止时间,团队能力建设以及团队成员的角色。
1.4.3 测试计划
迁移计划后,执行小批量的测试迁移方案,这里会涉及到首批迁移的测试和审核,步骤如下:
准备用于测试迁移的测试系统环境,在测试时,第一批服务器将会迁移到
该系统环境中。
安装并核实迁移工具,此时要执行第一批服务器的P2V迁移。
对第一批服务器,需分析存储系统,不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS存储系统。
1.4.4 迁移测试
在第一批服务器和服务的小批量测试迁移后,需对迁移后的服务器进行测试,包括单元测试和性能测试。
1.4.5 迁移实施
在迁移实施过程中,所有的服务器都会被迁移到虚拟化系统下。执行步骤如下:
确保批量迁移的整个网络环境已准备完毕,并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。
5
对迁移系统进行性能审核和健康检查,如果系统状态监视则停用旧系统并将其服务暂时转移到新的虚拟化系统中。
进行利旧,对于一部分可用的旧硬件可在服务器虚拟化中重新再利用,一些软件资源需扩展,如内存和硬盘。这些服务器构成最终的虚拟化基础设施,即最终系统。
最后,在目标系统和最终系统之间进行V2V迁移。
1.4.5.1 服务器虚拟化前进行备份
为了对旧系统中的物理服务器进行虚拟化,需考虑服务器虚拟化带来的影响。例如,现有服务器的重复利用,服务器虚拟化时会对这些服务器的CPU,内存以及硬盘资源进行再利用,然而这些服务器上存在某些服务仍在运行,若无备份则会影响现有业务。因此,在执行迁移和虚拟化之前,必须先对需利旧的服务器进行备份。
提供物理备份服务器,并已进行虚拟化,数据和服务器已备份到虚拟化系统。
首先,对于要被迁移的服务器上,一般会存在多种服务正在运行,而且这些服务器在迁移评估后认为在虚拟化场景下可再利用的。但是,迁移过程中不允许存在较长的停机时间,因此需要准备一台采用虚拟化平台的备份虚拟机,通过P2V将该服务器备份到虚拟机上。
备份完所有需要进行虚拟化的服务器之后,这些服务器上安装虚拟化软件进行虚拟化,根据评估阶段确定的容量规划,在虚拟化平台上创建相应规格的虚拟机,其计算资源用于承接旧系统中的服务。
准备好所有的虚拟机后,规划和安装相关迁移工具,将备份系统中的服务迁移到虚拟化系统的虚拟机中。虚拟机迁移是指将备份的虚拟化系统中的应用服务迁移到最终的虚拟化系统中。
虚拟机迁移完毕后,要对这些服务进行测试,最后停用旧系统,所有服务切换到虚拟化系统中。
1.4.5.2 迁移的详细操作步骤
迁移的具体步骤及描述如下:
1、在评估阶段,虚拟化和迁移之前需收集的信息如下:
性能统计:包括CPU使用率,内存使用率,硬盘IOPS和硬盘使用情况;
6
物理服务器配置:包括CPU规格,内存容量,硬盘容量
统计物理服务器部署位置,分析是否支持虚拟化,累计支持虚拟化的服务器数量,并规划出虚拟化中需新增的硬件情况;
通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。可采用信息收集工具。
2、分析现有服务的依赖条件,对当前系统进行备份。
确定应用系统对服务器的依赖关系,可作为迁移参考,确定所有服务器的迁移优先级顺序。
在确定各服务的依赖条件后,对需进行虚拟化的服务器进行备份。
3、容量规划和虚拟化执行
根据当前的资源使用和需求情况,计算虚拟化所需的容量。
4、规划应用服务
在拟化解决方案中,同类虚拟机部署在同一个计算资源池中,在同一个池中可相互共享存储/计算资源,一个集群的故障不会影响其他资源池。
5、虚拟化规划和虚拟机分配
建立虚拟化平台后,要准备最终的迁移资源。迁移前,如果服务器a具备双核CPU和2G内存,那么在虚拟化平台中就创建一个2核/2G内存的虚拟机,并分配相应的硬盘。
6、 规划迁移工具
采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进行磁盘复制。
7、通过工具执行在线迁移
准备好源系统,目标虚拟机以及目标系统后,决定迁移时需使用的迁移工具和迁移策略。
8、迁移测试
迁移后,需进行测试来验证迁移是否成功,测试场景如下:
应用服务迁移后对虚拟化基本功能的监测;
迁移前后应用服务的特性功能是否几乎相同;
虚拟化系统的性能监控;
….
7
9、停用旧系统
截至目前现有的服务器已经被虚拟化和重复使用,其他一些不支持虚拟化的服务器上对应的服务也已经迁移到虚拟化平台,那么现在可将应用服务切换到虚拟系统并停用旧系统。
1.5 运营商接入链路(路由)迁移
运营商接入链路(路由)的迁移主要是新中心所需物理链路的申请,电话号码接入路由制作、应用正式切割前测试号码的开通以及切割当日应急措施。针对前四部分内容,可以按照中心需要完全备份一份,在系统正式切割前进行模拟运行测试。
切割当日要做好应急保障措施,如切割一旦不成功,迅速切回原路由保障系统的运行。同时在新指挥备份足够的备份链路,支持人工受理。
上述链路的具体配置方案在中标后进一步确认。
1.6 应用系统和数据库迁移方案
针对本项目建设,我们将在应用系统和数据库迁移前,在用户新招标采购的云平台中部署与原应用一样的操作系统、中间件、服务器管理平台软件环境,确保迁移的环境变化风险最低。
1.6.1 应用服务器迁移
针对本项目应用系统迁移,原系统全部是基于IIS应用环境、.NET应用程序框架。本方案计划对IIS等应用环境以及.net应用程序框架提出构建IIS环境的NLB群集,将当前系统不停机加入到NLB群集中,使之成为群集中的一个节点,而新环境则为另外一个节点。实施完成后再退出此迁移群集,将新环境加入到新的构建的NLB群集。
NLB不但能实现均衡负载,而且还能实现多种形式的冗余。NLB主要用于那些文件改动不大,并且不常驻内存的环境,比如WEB服务、FTP服务、和**服务等。
8
当用户访问集群的时候,集群能将访问请求分摊到集群中的每个服务器上,以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中,每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB要求至少两个节点,其中一个节点不能使用,这全部负载将落入到剩下的那个节点上,即全载。NLB能提供三种冗余功能,软件冗余、硬件冗余、站点冗余。
1.6.2 数据库迁移实施
针对本项目数据库迁移,需要将中心积累的历史数据文件搬迁到新中心服务器,并且要求最小宕机时间,同时面临的难点还包括服务器并不在同一个一个机房。
1、分析与设计思路
针对本项目数据库搬迁环境特点:第一个是数据库文件比较大;第二是传送
文件的速度可能会比较慢(广域网传输)。初步解决方案如下。
为了使宕机时间最短,我们这里使用完整备份和差异备份来迁移数据库,在白天的时候对需要迁移的数据库进行一次完整备份(XXX_full.bak),并把备份文件拷贝(这里可以使用FTP软件进行断点续传)到目标服务器进行还原,等到下班时间之后再进行一次差异备份(XXX_diff.bak),再把这个差异备份拷贝到目标服务器,在完整还原的基础上再进行差异还原。
这里的宕机时间 = 差异备份时间 + 传送差异备份文件时间 + 还原差异备份文件时间,不存在宕机时间。
2、保证数据迁移过程中的安全性和操作可审计性
数据迁移中的安全性不可忽略,本方案设计基于多重数据审计功能实现迁移安全性和操作审计性。
1.7 系统迁移的具体组织实施方案
针对本项目建设,涉及中心生产系统的搬迁,上述系统具有停机时间要求短、系统结构复杂、测试时间长、设备繁多、使用人员多、层次复杂等特点。本项目搬迁,时间非常紧,且设备间的稳定性也是一个考验。因此,必须协调好各单位
9
人员的关系,齐心协力才可能在预定时间内完成搬迁工程。
本项目搬迁组织以尽量不影响日常工作或将影响降低到最低为前提的情况下制定,即在保障内容最少日的最少时间节点开始搬迁,尽快完成必须搬迁的服务器、网络设备的搬迁、安装及测试。并且在开机以后,继续跟踪系统的运行情况,随时处理系统运行的异常情况。搬迁需要原系统建设公司人员的充分协调及配合下才能完成本次搬迁任务。
1.7.1 搬迁规划
实施流程:
对所有设备进行与XXX技术人员现场勘察确定实施方案分析,制定应急现场交流方案
流程主要根据搬迁前的需要制定,主要详细了解当前系统设备情况,系统运行情况。针对所了解情况制定详细搬迁方案以及应急方案。
专业工程师了解用户现在机房的现状以及搬迁后的具体要求。充分考虑在实施过程中可能出现的各种情况,定制详细可行性的迁移实施计划,将机房迁移工作对用户的影响降至最小。
编制搬迁前及搬迁后的物理布置表、连接表、线缆号表。可根据用户情况分为多个系统进行分类。
在搬迁过程中需要XXX技术人员密切配合。
为保证搬迁工作顺利、有序、安全的进行将制定详细的搬迁流程,进行细致的分工,具体工作安排到人,责任到人。
搬迁工作中的每项工作原则最少安排(2)人,以保证工作的准确性。 1.7.2 详细实施方案
为了搬迁能按时顺利进行,并且在搬迁后能够保证设备正常运行,我们制定了一系列简单明了的工作表,帮助工程实施人员确定各种搬迁工作中要执行的工作是否完成。避免工作失误,避免造成搬迁工作的延误。
实施流程:
10
备品备件工具准新机房现场检查设备标记数据备份备
设备端口标记表数据备份表目的机房检查表
设备关机设备下架设备搬运设备连接
设备端口标记表
设备开机功能测试完成
目的机房的要求:
需要在搬迁前检查目的机房的必要设备设施是否符合要求,本工作表是保证搬迁后设备能否稳定正常运行的先决条件,在搬迁前由搬迁负责人同相关人员填写确认。
1.7.3 应急处理
在设备搬迁后出现异常情况时现场技术人员立即检查设备,检查故障现象,确定故障位置。
硬件故障在备件准备范围内的立即更换,不在范围内的立即使用备用设备最短时间内启用备用设备。由于配置数据或系统不能启动的立即使用系统光盘备份数据等先前准备的备用工具软件系统软件重新按装或恢复。
11
云平台应用系统迁移方案大纲
中国移动广东公司
UAP 云平台应用迁移方案
(大纲)
版本 拟制 审核 批准 沈志华 日期 日期 日期 2014.07.16 目录 1 2 文档说明 ......................................................................................................................................................... 4 应用系统迁移方法 ......................................................................................................................................... 4 2.1 2.2 3 应用迁移与整合方法 ............................................................................................................................. 4 应用迁移涉及的相关部门 ..................................................................................................................... 5 系统评估与分析 ............................................................................................................................................. 6 3.1 系统评估和分析流程 ............................................................................................................................. 7 3.2 评估准备 ................................................................................................................................................. 8 3.2.1 迁移范围确定 ................................................................................................................................. 8 3.2.2 评估方法与准备 ............................................................................................................................. 9 3.2.3 评估环境的准备 ............................................................................................................................. 9 3.3 系统调研与评估 ..................................................................................................................................... 9 3.3.1 物理基础架构调研与评估 ............................................................................................................. 9 3.3.2 应用系统调研与评估 ................................................................................................................... 10 3.3.3 迁移对应用系统的影响 ............................................................................................................... 11 3.4 需求分析及汇总 ................................................................................................................................... 11 3.4.1 基础架构需求分析与汇总 ........................................................................................................... 11 3.4.2 应用系统需求分析和汇总 ........................................................................................................... 11 4 方案设计 ....................................................................................................................................................... 11 4.1 4.2 方案设计流程 ....................................................................................................................................... 12 云平台方案设计 ................................................................................................................................... 13 4.3 迁移方案设计 ....................................................................................................................................... 13 4.3.1 虚拟化适用性分析 ....................................................................................................................... 13 4.3.2 迁移场景设计 ............................................................................................................................... 14 4.3.3 资源映射分析 ............................................................................................................................... 15 4.3.4 服务器放置设计 ........................................................................................................................... 16 4.3.5 资源竞争关系设计 ....................................................................................................................... 17 4.3.6 迁移顺序设计 ............................................................................................................................... 17 5 虚拟化环境准备 ........................................................................................................................................... 18 5.1 虚拟化环境准备步骤 ........................................................................................................................... 19 5.2 虚拟化环境准备与方案设计 ............................................................................................................... 19 5.2.1 环境确认 ....................................................................................................................................... 19 5.2.2 实施规划与设计方案 ................................................................................................................... 19 5.3 UAP 云平台实施 .................................................................................................................................. 20 5.3.1 虚拟化系统设置与调试 ............................................................................................................... 20 5.3.2 虚拟机系统设置 ........................................................................................................................... 20 6 应用迁移 ....................................................................................................................................................... 20 6.1 6.2 6.3 6.4 7 迁移实施流程 ....................................................................................................................................... 21 迁移环境准备 ....................................................................................................................................... 21 迁移执行 ............................................................................................................................................... 22 迁移后虚拟机的优化 ........................................................................................................................... 22 测试验证 ....................................................................................................................................................... 22 7.1 7.2 7.3 7.4 7.5 应用系统测试验证流程 ....................................................................................................................... 22 应用系统测试验证内容 ....................................................................................................................... 23 应用系统测试 ....................................................................................................................................... 23 系统优化 ............................................................................................................................................... 23 应用系统验证 ....................................................................................................................................... 24 8 应用系统割接 ............................................................................................................................................... 24 8.1 8.2 8.3 8.4 8.5 8.6 8.7 应用系统割接流程 ............................................................................................................................... 24 割接评估 ............................................................................................................................................... 24 割接准备 ............................................................................................................................................... 25 割接操作 ............................................................................................................................................... 25 回退机制 ............................................................................................................................................... 25 割接后观察 ........................................................................................................................................... 25 原系统删除 ........................................................................................................................................... 26 9 附录 ............................................................................................................................................................... 26 9.1 9.2 MAP 性能评估工具实施文档 ............................................................................................................. 26 典型案例 ............................................................................................................................................... 26 1 文档说明 本文档的目的在于为UAP 云平台地市应用系统设计的一个迁移与整合方法,并对实际操作有指导和建议。 本文档主要针对广东移动UAP 的地市应用系统迁移到UAP 云平台。 2 应用系统迁移方法 2.1 应用迁移与整合方法 根据以往丰富的项目经验,结合UAP 云平台的具体业务特点,定制了一套数据迁移与整合的方法。本迁移与整合方法分为6个阶段,分别为系统评估与分析、方案设计、虚拟化环境准备、应用移植、测试验证和业务割接。 图2-1 应用迁移与整合方法 评估与分析 在系统评估与分析阶段,应确定迁移范围和目标,利用调查问卷、系统评估工具(MAP )和访谈等评估形式,对应用系统进行评估,分析和汇总系统需求,形成调研报告。 方案设计 在方案设计阶段,针对项目范围内的物理服务器进行虚拟化适用性分析,设计迁移场景和云平台架构方案。在云平台方案设计的基础上,进行迁移顺序、迁移方法等内容的设计,形成总体迁移方案。 虚拟化环境准备 在虚拟化环境准备阶段,应判断现有的UAP 云平台环境是否能容纳被迁移的所有对象,以及,具体应检查计算资源、存储资源、网络资源以及数据库资源等,建立迁移所需的环境准备,如虚拟机、虚拟化网络等。 应用移植 在系统移植阶段,应根据既定的迁移方案严格的执行应用系统迁移,将物理机的应用系统移植到虚拟机内,有工具移植和手工部署两种方式。 测试验证 对云平台上的应用系统进行功能性测试、性能测试和稳定性测试,并进行应用验证,以便预先排除隐患,使得应用系统成功的运行在云平台环境下。 业务割接 制定割接方案,依照割接方案进行割接操作,割接完成后进入割接后观察期,通过割接验收后将原系统下线。 应用系统在UAP 云平台上线1个月后,提供性能分析报告。 2.2 应用迁移涉及的相关部门 业务迁移进行中,会涉及如下各部门,其具体职责如下: 省公司信息系统部:; 地市公司: 应用开发商:负责实施UAP 平台各应用系统日常的7×24小时故障响应处理工作,为UAP 平台 各应用系统的维护支撑提供技术支持。 迁移实施方: 1) 对应用系统进行评估和分析; 2) 根据需求设计云平台方案,或者评估现有云平台方案是否满足需求; 3) 设计应用系统迁移方案,如迁移方式、迁移工具等; 4) 进行应用系统迁移,将应用系统从物理机上移植到虚拟机上; 5) 与应用开发商一起进行测试验证; 6) 进行业务割接。 3 系统评估与分析 如何对被迁移系统进行有效的系统评估,为迁移和整合提供有效的支撑数据,是迁移前重要的工作,也是迁移和整合过程中的一个难点。系统评估分析,将使用调查问卷、自动化评估工具或访谈等形式对系统的基础架构层和应用层进行系统评估。 3.1 系统评估和分析流程 图3-1 评估和分析流程 应用系统迁移评估与分析流程描述如下: 表3-1 系统评估和分析流程 3.2 评估准备 3.2.1 迁移范围确定 应用系统迁移,首先要确定迁移范围,如: 哪些应用系统需求从哪些服务器上迁移到UAP 云平台虚拟机上; 哪些应用系统需要进行解耦和整合等操作; 迁移前后机房环境的变化确认等。 3.2.2 评估方法与准备 采用调查问卷方式、评估工具自动化评估或访谈等方法对UAP 应用系统进行评估和分析,从不同的维度获得全面的信息,为迁移工作提供有力依据。 调查问卷可以大规模的进行信息采集,收集各个层面的信息,范围较广,但是由于需要人工填写,人为因素将导致准确率不高。自动化评估工具可准确的对系统进行性能等方面的评估,准确率高,可信度大,但是适用范围有限,比如有些服务器由于客观原因无法被自动化工具评估。对于一些比较复杂的问题,可以采用深度访谈的方式,形成访谈报告,补充到文档中。 3.2.3 评估环境的准备 使用具体评估工具进行自动化评估时,需要准备好相关主机、网络、以及MAP 工具包等内容,以便顺利开展系统评估工作,详见附录中的具体评估工具需求。 3.3 系统调研与评估 3.3.1 物理基础架构调研与评估 在物理基础架构信息收集和评估中,计算容量、存储容量和网络容量以及相关的利用率和性能是重要的评估内容。自动化评估工具MAP 可帮忙得出比较客观的物理架构的容量和性能,调查问卷也可协助完成信息收集。 物理基础架构的评估中,应完成如下内容的评估: 在基础架构硬件的CPU 评估中,应收集CPU 的型号、主频、内核数、颗数,应评估CPU 的利用率。 在基础架构硬件的内存评估中,应收集内存的容量以及使用率。 在基础架构硬件的磁盘评估中,应收集磁盘的数量、RAID 方式、文件系统类型、文件系统总容量、磁盘IO 性能等。 在基础架构硬件的网络评估中,应收集物理服务器的网卡容量、数量及网络性能,网络交换机的型号、网口数、数量,基础架构的网络拓扑图等。 3.3.2 应用系统调研与评估 在应用系统层面,至少应评估业务的重要性、业务成熟度、应用系统逻辑架构等内容,从而为迁移提供重要的参考依据。 3.3.2.1 业务重要性 在评估阶段,应评估应用系统的重要程度,利用应用系统的重要程度设置相关的资源竞争策略,并且对重要的应用系统采用相应的技术方案进行保护,如重要的应用系统可使用HA 等技术方案保证业务连续性。 业务的重要性可作为虚拟机发生竞争时如何争取资源的一个重要输入。在虚拟机的资源竞争机制中,有最低占用资源设置、最高占用资源设置和相对权重。可根据业务的重要性设置相关的权重,比如可以设置重要业务权重为200,比较重要业务的权重是150,不重要的业务权重是100。需要注意的是具体虚拟机权重设计的时候一定要遵循一个统一的标准,保持前后连贯性。 3.3.2.2 业务生命周期 按照不同的业务成熟度为相关的虚拟机来预留资源,来满足业务发展所带来的需求。业务成熟度分为业务投入期、成长期、成熟期、衰退期,可按不同的成熟度为不同的业务系统进行预留空间等内容的设置。 在评估阶段,应评估业务的成熟度,业务成熟度可作为应用系统资源预留的一个重要衡量指标。可针对不同成熟度的业务提供不同的资源预留策略,比如成熟业务预留50%资源,衰退业务预留25%,成长的业务预留75%资源,投入期业务预留50%资源。 3.3.2.3 应用系统逻辑架构 评估中,应对应用系统间的逻辑架构进行分析,从而判断各应用系统间的依赖关系和应用系统间的逻 辑关系。应用系统的逻辑架构可为确定迁移依赖关系、迁移顺序和迁移后位置提供的有力参考。 3.3.3 迁移对应用系统的影响 将应用系统从物理服务器迁移到虚拟化,从一个机房迁移到另外一个机房,这种迁移会对应用系统本身产生不同程度的影响。 在评估的内容中,还要注意一起其他内容的分析,如硬件依赖关系,即那些服务器依赖于某种特定的硬件。大部分的虚拟化环境无法满足特殊硬件的需求,如视频卡、音频卡、加密卡等硬件。 3.4 需求分析及汇总 基于对基础架构和应用系统现状的评估,结合业务的发展需要,对具体应用系统进行基础架构和应用系统两个层面的需求分析和汇总。 3.4.1 基础架构需求分析与汇总 基础架构需求分析,需要整理所有应用系统的基础架构层面的需求,汇总整个所有业务系统所需要的基础架构需求,如网络、服务器、存储等,可用表格等形式汇总整个基础架构的需求。 3.4.2 应用系统需求分析和汇总 在系统调研中,基于调查问卷和访谈的方式对应用系统进行调研与评估,对应用系统层面的需求进行需求分析和汇总,常见的应用层面需求分析如无单点故障、高可用性等,在评估阶段需要分析和汇总所有这些应用层面的需求进行汇总,以及业务的成熟度、重要性等内容,以便后续为后期云平台架构设计提供依据。 4 方案设计 在对物理应用系统进行评估后,进一步的工作是迁移到什么地方,目标平台是否满足迁移需求,如何进行迁移等。 4.1 方案设计流程 图4-1 方案设计阶段流程图 方案设计的流程描述如下: 表4-1方案设计阶段流程图说明 4.2 云平台方案设计 在云平台的方案设计中,主要要考虑服务器、存储和网络基础架构的设计,要详细考虑具体架构、容量和性能的设计因素。 4.3 迁移方案设计 4.3.1 虚拟化适用性分析 在系统评估后,进一步细化了可迁移的服务器范围。虚拟化适用性判断阶段,应参考基础架构层和应用层的评估指标,明确哪些应用适用于虚拟化技术,哪些应用系统不适合虚拟化技术。 具体的指标如下但不限于以下指标: ? 基础架构层的评估指标 ◆ 不适合虚拟化的典型对象 平均使用率高于70%的双处理器系统或平均使用率高于45%的四处理器系统 需要特殊硬件(目前主流Hypervisor 软件能够模拟的硬件只有CPU 、内存、网卡、硬盘等, 对于其他需要直接使用的PCI 、PCI-x 、PCI-E 、AGP 设备均无法正常支持,包括窄带卡、 中继卡、3D 卡、显卡、加密卡、磁带机、infiniband 、电信业务中特有的语音E1板卡等) 的系统 平均网络带宽在600Mbps 以上、平均IO 在50MB/s以上、内存占有8GB 以上的系统 ◆ 适合虚拟化的典型对象 硬件配置较低(<> 硬件配置相对较高、平均使用率一直偏低(小于 20%)的系统 ? 应用层的评估指标 ◆ 不适合虚拟化的典型对象 运行CAD 、CAM 、PRoE 等工程设计应用程序的系统 运行音视频流媒体引用程序的系统 大型数据库系统,如Oracle 、DB2数据库软件 ◆ 适合虚拟化的应用类型 在不同的时间达到峰值使用率的应用 4.3.2 迁移场景设计 在迁移方案设计时,应依据源迁移对象、目标场所等因素来设计迁移阶段的相关场景。 过渡环境:进行应用系统的初步迁移,将数据中心的服务器首先迁移到本地的资源池,利用P2V 、V2V 和New VM等迁移方式; 测试环境:将本地资源池的业务服务器虚拟机迁移到测试环境,完成功能性和初步压力测试,利用虚拟机文件拷贝、V2V 或自动化工具等迁移方式; 验证环境:将云平台的业务服务器虚拟机迁移到验证环境,完成近似真实环境的压力测试,利用虚拟机文件拷贝、V2V 或自动化工具等迁移方式; 生产环境:将验证环境平台虚拟机迁移到生产云平台环境,云平台环境中承载应用系统运行,利用虚拟机文件拷贝、V2V 或自动化工具等迁移方式; 不同平台有各自的用途,各自的设计需求也不同: 过渡环境,临时性迁移场所; 测试环境,主要进行业务功能、性能等方面的压力测试的场所,不需要虚拟化高级功能,虚拟化单机版软件即可满足 验证环境,将采用与生产云近似的技术,进行上线前的真实场景模拟测试 生产环境,未来应用系统的生产环境,需要使用高级的技术手段来保证实际业务系统的连续性、可扩展性等功能,从而使得业务系统能健康运行。 4.3.3 资源映射分析 在迁移后的资源需求设计中,即对物理资源的需求映射为对虚拟资源的需求,应具体到CPU 、内存、硬盘和网络细颗粒度级别。 对于CPU 资源,虚拟机CPU 的主频与物理机主频一样大,一个虚拟机vCPU 对应一个物理机CPU 的核,而一个物理CPU 的核可以供多个虚拟机vCPU 使用。物理CPU 到虚拟机CPU 的转换性能损耗很小,大概5%以内。 对于内存资源,物理机内存到虚拟机内存的转换损耗较小,不同的虚拟化软件有不同的内存管理方式,有些使用内存固定分配机制,有些使用内存过量分配机制(overcommit ,即虚拟机的内存容量可超过物理机的内存容量)。 对于存储资源,物理系统到虚拟系统的损耗较大,设计虚拟系统请尽量加大物理系统的带宽,对于虚拟机的磁盘容量可选取按需分配模式。 对于网络资源,物理机网络性能到虚拟机系统的损耗较小,但是设计时应充分考虑到网络复用,以及虚拟化系统中网络的资源竞争设置较弱等因素。 4.3.4 服务器放置设计 源物理服务器到目标虚拟机的映射关系是将应用系统物理服务器与UAP 云平台的物理机进行映射,从而确定应用系统整合后所寄宿的物理主机。设计一个好的映射关系可以保证应用系统具有充足的物理资源的容量和性能,并保证业务应用系统具有良好的高可用性等高级功能,是应用系统迁移重要的一环。 设计应用系统到服务器映射关系应遵从如下原则: 性能均衡原则,将低性能和高性能的服务器组合放在一台物理服务器内,比如低IO 与高IO 服务器搭配,低CPU 使用率与高CPU 使用率搭配 容量均衡原则,将低容量和高容量的应用系统组合放置在一台服务器内 业务重要性均衡原则,即将低重要性的应用系统和高重要性的应用系统组合放置在一台服务器内,从而保证重要的应用系统在资源发生竞争的时候仍然能获得足够的资源(本生产环境的云平台系统中,所有物理服务器具有相同的重要级别,故可按业务重要性均衡原则。如在其他系统中,云平台服务器有重要级别差异,则将业务重要性高的应用系统放置在重要性高的服务器上。) 同一业务的应用系统尽量放置于一台服务器上,从而减少物理网络带宽的占用,并保持网络的稳定性 不同业务高峰的应用系统组合放置于一台物理服务器内 4.3.5 资源竞争关系设计 虚拟机资源竞争策略取决于两个因素,第一因素是资源设置,第二因素是资源控制。资源设置层面设置虚拟CPU 、内存、网卡容量等。资源控制分为如下几个部分: CPU 资源控制 ? 最小保留(百分比或者Hz ) ? 最大限制(百分比或者Hz ) ? 相对权重(具体数字,如100、150、200等) 内存资源控制 ? 最小保留(百分比或者GB ) ? 最大限制(百分比或者GB ) ? 相对权重(相对具体数字,如100、150、200等) 磁盘IO 性能资源控制 ? 相对权重(相对具体数字,如100、150、200等) 网络IO 性能资源控制 ? 相对权重(相对具体数字,如100、150、200等) 在相对权重设计中,应考虑全局,根据业务系统的重要性设置应用系统的权重,以便迁移后虚拟机可按相对权重获得相应的资源竞争机会。 4.3.6 迁移顺序设计 根据业务应用系统间的依赖关系及应用系统本身的特性设计整个系统的迁移顺序。对P2V 迁移过程,被迁移应用系统可分为独立应用系统、被依赖的应用系统、堆叠应用系统: 独立应用系统,是指该物理主机上只有一个应用系统,并且与其他应用系统没有任何依赖关系。 被依赖应用系统,是指该应用系统被其他应用系统所依赖,如数据库等。 依赖应用系统,是指该应用系统依赖于其他应用系统。 堆叠应用系统,是指物理主机上有多个应用系统,这些应用系统间或者有依赖关系或者没有依赖关系。 在实际迁移中,建议应由难而易,由复杂到简单,从而能更好的完成所有的迁移工作。建议遵从如下迁移顺序: 被依赖的应用系统优先,数据库等被迁移系统先进行迁移 应用依赖关系系统 独立应用的系统 应用堆叠的应用系统 5 虚拟化环境准备 根据需求进行虚拟环境的准备,为应用移植搭建好环境,从而更顺利的进行应用系统迁移。 5.1 虚拟化环境准备步骤 图5-1 虚拟化环境准备步骤 5.2 虚拟化环境准备与方案设计 5.2.1 环境确认 在环境确认中,应确认如下环境是否准备就位,以便顺利进行项目实施。 确认需要的网络资源是否就绪; 确认需要的存储资源是否就绪; 确认需要的计算资源是否就绪; 确认需要的数据库资源是否就绪 5.2.2 实施规划与设计方案 项目实施前应制定详细的实施规划与设计方案,包括但不限于如下内容: UAP 云平台及业务系统组网设计 UAP 云平台及业务系统存储系统设计 UAP 云平台实施详细规划及具体参数设计 虚拟机设置参数,如虚拟机硬盘等 外围环境设计,如域控制等 5.3 UAP 云平台实施 依据云平台实施规划与设计方案进行项目实施,严格遵从中国移动相关标准及广东移动相关标准,严格按照项目管理的要求。 5.3.1 虚拟化系统设置与调试 在虚拟化系统配置与调试中,包括如下内容: Hyper-V 管理软件的高级功能配置,如HA 、动态迁移等高级功能,以满足业务的具体需要 存储的相应配置 网络虚拟化的相应配置,建立虚拟交换机,并与物理网卡及物理网络联调 5.3.2 虚拟机系统设置 云平台物理和虚拟环境搭建好后,应创建相应的虚拟机,安装操作系统,按需安装相应的应用系统软件,制作相关的模板。 6 应用迁移 应用系统迁移首先将应用系统从物理服务器移植到虚拟机上,可直接在虚拟机上重新部署或者移植应用系统,也可将物理机利用迁移工具转换为虚拟机。 6.1 迁移实施流程 图6-1 应用系统迁移实施流程 6.2 迁移环境准备 迁移环境准备是迁移前最重要的工作,包括人员、网络环境、迁移技术手段、迁移工具等内容的准备。 1,应用系统迁移前,相关人员应准备就绪 迁移实施方:负责具体迁移工作 应用系统开发商:负责具体应用的部署和测试 网络系统管理员:负责网络的通信和连接情况 系统管理员:负责虚拟化环境的准备和资源提供,原物理服务器的密码等信息提供; 备份管理员:对重要的数据和应用进行迁移前备份; 2,确认UAP 云平台具有足够的CPU 、内存、存储和网络资源满足被迁移系统的需求。 3,迁移前,对重要的数据和应用系统进行必要的备份,以防迁移过程中有意外的情况发生。 6.3 迁移执行 在迁移执行阶段,须严格执行制定的迁移方案和迁移流程。 6.4 迁移后虚拟机的优化 在应用系统迁移到云平台环境后,应对虚拟机作出相关的设置调整,以满足更好的业务服务需求,具体调整可参考如下几点(不限于): 消除不必要的虚拟硬件设备 按需求适当增加或者减少虚拟资源配置,比如调整或者减少处理器和内存等设置 设置资源竞争相关参数,如设置虚拟机最小、最大CPU 可用资源,及发生竞争时的竞争权重 等 调整虚拟机磁盘空间大小,满足应用系统的发展需求 7 测试验证 应用系统应该做好充分的测试与验证,为业务割接做好准备工作。 7.1 应用系统测试验证流程 图7-1 应用系统迁移测试流程 7.2 应用系统测试验证内容 首先测试在UAP 平台虚拟机上的应用系统是否具有与物理服务器相同的功能,然后对应用系统进行功能性测试、性能测试、稳定性测试,并对有问题的地方进行初步优化,最后进行应用系统验证,保证应用系统顺利割接。 7.3 应用系统测试 对被迁移的应用系统通过创建测试用例和测试脚本,选择合适的测试数据和测试样例,确认迁移数据在应用系统迁移到云平台环境后的有效性,进行有计划的测试,并在测试结果基础上生成报告。 功能性测试对云平台的业务应用系统进行功能性测试,并与物理服务器进行对比,确保应用系统在平台迁移后所有功能工作正常,可采用手工测试或者自动化测试工具。对于迁移后应用系统,重点测试虚拟环境下对应用业务的影响,对于新的业务系统,需要进行完整的业务逻辑性测试。 在性能测试中,主要采用压力软件在压力机上对应用系统进行压力测试,或者采用人工脚本进行压力性测试,从而衡量应用系统对虚拟机系统的资源消耗及由此产生的对物理机的资源消耗,从而更好的掌握应用系统的性能需求,验证云平台是否能满足业务系统的性能需求。 7.4 系统优化 对测试过程中发现的系统问题,进行系统优化,达到比较优化的运行状态。 系统调优中,建议考虑如下因素: 从整体考虑资源组的资源保留情况,整体考虑资源组内的虚拟机的资源保留和竞争情况 充分利用性能测试结果,找出系统性能的短板,从物理基础架构和虚拟基础架构两个层次进行调 优 7.5 应用系统验证 应用系统验证是指在验证环境中,利用接近生产云平台的真实环境,对业务应用系统进行验证,从而更加准确的衡量云平台环境中的业务应用系统是否满足真实环境的需求,为应用系统割接做好准备。 8 应用系统割接 应用系统割接是在UAP 云平台中完成应用系统的上线割接,原系统停止对外服务,UAP 云平台上的应用系统开始提供对外服务。 8.1 应用系统割接流程 图8-1 应用系统迁移割接流程 8.2 割接评估 在进行系统割接前,首先对系统进行割接评估,包括但不局限于如下内容: 应用系统在云平台中的测试是否满足需求 应用系统对用户感知的影响是否很大 对现有业务产生的影响是否很大 应用系统的割接是否会影响具体业务运行 是否具备割接的具体条件 8.3 割接准备 应根据业务的特点制定合适的割接方案,为割接操作提供切实可行的依据。 割接操作前,应做好割接准备。割接准备分为两个层面,管理层面准备和技术层面准备。管理层面的准备如割接前的系统公告、割接后客户回访等;技术层面的割接准备,如准备好云平台相关硬件设备和功能等。 8.4 割接操作 在应用系统割接中,割接操作应包含但不限于如下几个步骤: 原系统停用 将原系统中止对外服务,停止数据访问,保持数据的完整性。中止服务时,请不要关闭原有系统,而是简单地将网络断开,这样,如果迁移后的虚拟机不能正常使用,可在最短时间内启用原系统。 最终的数据同步 将原生产系统内的数据与生产云平台内的新系统进行最终的数据同步,以便平滑迁移。 新系统上线 寄宿于云平台的应用系统上线,开始对外提供服务。 8.5 回退机制 由于应用系统割接后,地点和配置都可能发生变化,一些因素有可能导致割接失败。应用系统割接应在规定的时间窗口内完成,如规定时间内无法完成,或者割接后运行不稳定,则需考虑回退应用系统,拨回配置信息,启用原系统。 8.6 割接后观察 当云平台上的应用系统上线后,应成立专门的监护小组对割接后的系统进行观察。在割接后观察期中, 遇到不稳定运行的系统,要考虑是否回退。如可以解决,在进行问题解决及优化,如需要回退,则启动回退流程。 观察期周期设置取决于具体的应用系统特点,建议观察期在三个完整的业务周期以上。 8.7 原系统删除 当应用系统成功割接,并且在割接后观察期正常工作后,可考虑将原系统删除,释放物理资源,完成整个应用系统迁移。 9 附录 9.1 MAP 性能评估工具实施文档 9.2 典型案例 三个典型案例 服务器应用系统迁移解决方案 (此文档为 word 格式 , 下载后您可任意修改编辑! ) 一、迁移方案总体思路 新旧系统的迁移是一个整体系统工程。 迁移必须保证用户系统建设的相关要求,在迁移 过程中,我们需要重点考虑几个问题: 1、 数据迁移如何保障 “ 业务中断停机时间 ” 。 业务中断对于用户无论是运行环境还是测试 环境均存在较大的恢复风险, 这样的风险特别是对于时间敏感型数据还是对于数据完整 性业务都是不可以接受的。我们基于这样的要求,考虑到如何将停机时间最小,能否实 现 0停机的建设目标? i. 对于服务器操作系统而言,我们可以采用 P2V 的方式,利用操作系统的 Volume Shadow Copy卷影副本复制服务作为基础, 来实现在旧系统环境下的系统无修 改,无停机的情况下,将数据和应用软件、操作系统环境、系统环境变量等全部以 “ 快 照 ” 形式迁移到新服务器中。由此实现服务器环境的整体迁移。 ii. 对于应用 IIS 和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群 方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器 “ 热 添加 ” 到新环境中的故障转移 /负载均衡集群系统中,在部分应用服务中我们可以使用 session 会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。 考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状 态的安全性,我们可以采用会话数据库复制管理。 iii. 对于数据库而言, 我们可以基于数据库本身自带的数据库镜像技术、 数据库日志传递 技术来实现各自的分库、 迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁 移的不停机, 而且还可以保证万一迁移中出现停机故障也不影响源数据库, 而日志传递 技术构建的迁移可以保证系统数据库迁移以异步方式进行, 这样可以让我们的系统环境 在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。 2、迁移涉及到的除了应用、实例、数据库的操作以外,还涉及到迁移前规划、迁移后 测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会 话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和 有效性。 二、服务器硬件环境迁移方案 1. 迁移评估 迁移前, 对迁移方案进行评估以确保迁移成功。首先需要勘察现有系统的架构和资源使 用状况,评估过程必须包含以下信息和内容: 现有系统支撑的服务数量以及在服务器中的分布情况 现有物理服务器资源占用状况, 包括 CPU 、内存、磁盘和网络连接状况, 为保证迁移成 功,目标虚拟机规格应不低于原物理机标准 当前的物理环境是否支持虚拟化,是否支持资源扩展,因为在迁移之前须在物理服务 器上完成虚拟化 对当前的存储容量和资源利用率进行评估,需在目标系统中规划好迁移需要的存储空 间。需明确现有存储如何利用,比如有些服务器是在本地磁盘上创建系统盘和用户盘, 有些服务器则在本地磁盘上创建系统盘而在 SAN/NAS上创建用户盘。 2. 迁移计划 通过对现有网络环境的评估,我们对现有资源利用率,服务以及系统需求非常清晰。评 估后才能开始对迁移进行计划,步骤如下: 一、确定迁移步骤,包括所有服务器的迁移先后顺序,其顺序按风险的高低降序排列。 二、确定备份方案,由于现有系统会被加固,某些服务器通过虚拟化重复利用,而在虚 拟化前需要清除所有的数据,因此需要对这些服务器进行备份保证服务的连续性。 三、 确定并准备好迁移所需的工具,包括工具在迁移中必备的一系列功能和使用工具所 需具备的网络环境。 四、 在实际迁移开始之前确定额外的测试环境,该测试环境能够引导测试从而确保迁移 成功。因此,测试环境需明确设计的服务器和存储数量。 五、规划网络环境,由于网络中的服务器各处不同位置,因此在迁移中需考虑到网络连 接情况、数据备份方式,以及网络流量来源,确定网络流量是否会引发网络拥塞 六、确定迁移周期以及参与人员,包括迁移起止时间,团队能力建设以及团队成员的角 色。 3. 测试计划 迁移计划后,执行小批量的测试迁移方案,这里会涉及到首批迁移的测试和审核,步骤 如下: 准备用于测试迁移的测试系统环境,在测试时,第一批服务器将会迁移到该系统环境 中。 安装并核实迁移工具,此时要执行第一批服务器的 P2V 迁移。 对第一批服务器,需分析存储系统,不管该服务器在存储迁移中采用本地磁盘存储还 是远端 SAN/NAS存储系统。 4. 迁移测试 在第一批服务器和服务的小批量测试迁移后, 需对迁移后的服务器进行测试,包括单元 测试和性能测试。 5. 迁移实施 在迁移实施过程中,所有的服务器都会被迁移到虚拟化系统下。执行步骤如下: 确保批量迁移的整个网络环境已准备完毕,并通过迁移工具完成源系统和目标系统之 间的连通。此处的目标系统属于中转系统。 对迁移系统进行性能审核和健康检查,如果系统状态监视则停用旧系统并将其服务暂 时转移到新的虚拟化系统中。 进行利旧,对于一部分可用的旧硬件可在服务器虚拟化中重新再利用,一些软件资源 需扩展,如内存和硬盘。这些服务器构成最终的虚拟化基础设施,即最终系统。 最后,在目标系统和最终系统之间进行 V2V 迁移。这样,最终系统完成了现存硬件的 重复利用。 a. 服务器虚拟化前进行备份 为了对旧系统中的物理服务器进行虚拟化,需考虑服务器虚拟化带来的影响。例如,现 有服务器的重复利用,服务器虚拟化时会对这些服务器的 CPU ,内存以及硬盘资源进 行再利用,然而这些服务器上存在某些服务仍在运行,若无备份则会影响现有业务。因 此,在执行迁移和虚拟化之前,必须先对需利旧的服务器进行备份。 迁移步骤如下图所示。 提供物理备份服务器,并已进行虚拟化,数据和服务器已备份到虚拟化系统。 首先,对于要被迁移的服务器上,一般会存在多种服务正在运行,而且这些服务器在 迁移评估后认为在虚拟化场景下可再利用的。 但是,迁移过程中不允许存在较长的停机 时间, 因此需要准备一台采用虚拟化平台的备份虚拟机, 通过 P2V 将该服务器备份到虚 拟机上。 备份完所有需要进行虚拟化的服务器之后,这些服务器上安装虚拟化软件进行虚拟化, 根据评估阶段确定的容量规划, 在虚拟化平台上创建相应规格的虚拟机,其计算资源用 于承接旧系统中的服务。 准备好所有的虚拟机后,规划和安装相关迁移工具,将备份系统中的服务迁移到虚拟 化系统的虚拟机中。 虚拟机迁移是指将备份的虚拟化系统中的应用服务迁移到最终的虚 拟化系统中。 虚拟机迁移完毕后,要对这些服务进行测试,最后停用旧系统,所有服务切换到虚拟 化系统中。 b. 迁移的详细操作步骤 迁移的具体步骤及描述如下图所示 : A. 在评估阶段,虚拟化和迁移之前需收集的信息如下: 性能统计:包括 CPU 使用率,内存使用率,硬盘 IOPS 和硬盘使用情况; 物理服务器配置:包括 CPU 规格,内存容量,硬盘容量 统计物理服务器部署位置,分析是否支持虚拟化,累计支持虚拟化的服务器数量,并 规划出虚拟化中需新增的硬件情况; 通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。 可采用华为 信息收集工具或者第三方工具。 B. 分析现有服务的依赖条件,对当前系统进行备份。 上图描述了一种应用系统下的依赖关系,可作为迁移参考,确定所有服务器的迁移优先 级顺序。 在确定各服务的依赖条件后, 对需进行虚拟化的服务器进行备份。具体备份过程参见本 小节迁移实施方案中 “ 服务器虚拟化前进行备份 ” 部分的内容。 C. 容量规划和虚拟化执行 根据当前的资源使用和需求情况,计算虚拟化所需的容量。 D. 规划应用服务 在华为虚拟化解决方案中, 同类虚拟机部署在同一个计算资源池中,在同一个池中可相 互共享存储 /计算资源,一个集群的故障不会影响其他资源池。 E. 虚拟化规划和虚拟机分配 建立虚拟化平台后,要准备最终的迁移资源。迁移前,如果服务器 a 具备双核 CPU 和 2G 内存, 那么在虚拟化平台中就创建一个 2核 /2G内存的虚拟机, 并分配相应的硬盘。 F. 规划迁移工具 采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进行磁盘复制。 G. 通过工具执行在线迁移 准备好源系统, 目标虚拟机以及目标系统后, 决定迁移时需使用的迁移工具和迁移策略。 H. 迁移测试 迁移后,需进行测试来验证迁移是否成功,测试场景如下: 应用服务迁移后对虚拟化基本功能的监测; 迁移前后应用服务的特性功能是否几乎相同; 虚拟化系统的性能监控; …. I. 停用旧系统 截至目前现有的服务器已经被虚拟化和重复使用, 其他一些不支持虚拟化的服务器上对 应的服务也已经迁移到虚拟化平台, 那么现在可将应用服务切换到虚拟系统并停用旧系 统,其步骤如下: 三、应用系统数据库迁移方案 1. 应用服务器迁移到群集环境 为满足企业不断的成长需求,实现企业服务器的高可伸缩性、高可用、高可靠性和高性 能,提升服务器的 SLA , Microsoft 到目前为止,提出了五种解决方案: 我们对于 IIS 等应用环境以及 .net 应用程序框架我们提出构建 IIS 环境的 NLB 群集,将 当前系统不停机加入到 NLB 群集中,使之成为群集中的一个节点,而新环境则为另外 一个节点。实施完成后再退出此迁移群集,将新环境加入到新的构建的 NLB 群集。 微软的网络负载平衡可以提供最多 32台主机的负载平衡, 当我们的 Web 站点需要分担 更多用户访问请求的时候,负载均衡无疑是值得考虑的一个解决方案。当然 NLB 也有 相应的限制,像广域网环境中,我们就不能使用 NLB 进行设置,因为其网络不允许使 用同一个 MAC 地址,也就违反了 NLB 的基本要求。 在安全方面,除了我们进行的端口规则设定, Windows 2003 Server本身基于 TCP/IP 堆栈的集成是动态的, 不用进行任何人工干预, 这种设置有效的防止了 DOS 攻 击等恶意攻击。除此之外,企业结合自身的网络安全,确保 NLB 站点的高效运作。 NLB 不但能实现均衡负载,而且还能实现多种形式的冗余。 NLB 主要用于那些文件改 动不大,并且不常驻内存的环境,比如 WEB 服务、 FTP 服务、和 ** 服务等。 NLB 不适合用于数据库、邮件等服务,因为不能保证每个节点的数据是一样的。 当用户访问集群的时候, 集群能将访问请求分摊到集群中的每个服务器上, 以达到均衡 负载的效果。这些服务器被称为集群节点。在负载平衡中,每个节点的文件一般都要求 是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个 NLB 要求 至少两个节点,其中一个节点不能使用,这全部负载将落入到剩下的那个节点上,即全 载。 Windows server 2003 最多支持 32个节点。节点越多,可用性,可靠性就越高。 NLB 能提供三种冗余功能,软件冗余、硬件冗余、站点冗余。 基于 NLB 集群的 Web 网站 数据库设计 1.MSCS,提供后端服务与应用程序的容错移转,可提升系统的可用性。常见的应用 有 SQL Server与 Exchange Server等。 MSCS是由客户端来决定由谁来处理服务请求, 所有服务器共享一个共享存储器来储 存会话状态。当主动服务器挂了,则继续由被动服务器接手。被动服务器会从共享存储 器取出会话状态,继续未完成的工作,以达到容错移转的目的。 2.数据库是数据管理最有效的手段,要使用它来高效地管理和存取各种数据资源,必 须设计出结构合理、功能完善的数据库。数据库设计时一项复杂的工作,它是一项涉及 多学科的综合技术, 要求数据库管理员既要懂得数据库知识,又要充分了解应用领域的 专业知识。 在进行数据库设计时, 要根据企业组织中各类用户的信息要求和处理需求来对数据库 进行设计。 数据库设计的主要内容包过机构性设计和行为特性设计,设计的过程主要包 括需求分析、概念设计、逻辑设计和物理设计四个阶段。 (1)需求分析 需求分析就是对现实世界要处理的对象进行详细调查, 在了解原系统的概况、 确定新 系统功能的过程中, 获得用户对数据库的数据要求、 功能要求、 安全要求和完整性要求。 (2)概念设计 概念设计时将需求说明中关于数据的要求, 综合为一个统一的概念模型。 概念模型是 表达概念模型设计结果的工具, 是设计人员对系统的抽象的概括, 它能表达用户的需求, 且独立于支持数据库的数据库的管理系统和硬件系统。 (3)逻辑设计 概念设计的结果是得到一个与数据库的管理系统无关的概念模型, 而逻辑设计的目的 是吧概念设计的概念模型,转换成与选用的具体机器上的 DBMS 所支持的数据模型相 符合的逻辑结构。 (4)物理设计 物理设计的任务是确实数据库的存储结构, 主要包括确定数据库文件和索引文件的记 录格式和物理结构,悬着存取方法,决定访问路径和外存储器的分配策略,实现完整性 和安全性以及程序设计等。 对于一个比较大的网站来说, 数据库集群也应该是以集群的方式建立, 这样可以增强网 站的性能, 提高网站的可靠性。 数据库可分为三类:故障切换集群、 分布式数据库系统、 共享磁盘系统。 NLB 集群系统的总体设计 (1)环境下实现 Windows 2003服务器集群; (2)在域内环境内的 windows2003 web server群集; (3)利用 IIS 搭建了一个 WEB 站点。由于业务的逐渐增加,网站速度也越来越慢,而 且经常出现故障,为公司的利益带来了很多的不便;公司决定使用两台 WEB 站点为客 户机提供访问。因此采用了网络负载均衡技术。 NLB 集群工作原理及算法 1.NLB 的工作原理 当客户向 NLB 群集 (NLB 的虚拟 IP 地址) 发起请求时, 其实客户的请求数据包是发 送到所有的 NLB 节点,然后运行在 NLB 节点上的 NLB 服务根据同样的 NLB 算法来确 定是否应该由自己进行处理,如果不是则丢弃客户的请求数据包,如果是则进行处 理。 如何将请求数据包发送到所有的 NLB 节点是 NLB 运行的关键之处, 单播和多播这 两种操作模式就是用于实现这一需求。 NLB 不支持单个 NLB 群集中的单播 /多播的混合 环境;在每一个 NLB 群集中,该群集中的所有节点都必须配置为多播或单播,否则, 此 NLB 群集将无法正常工作。 2. 负载平衡算法 一个负载平衡算法都包含以下三个组成部分: 策略:制定任务放置策略的制定者使用的负载和任务量,以及分配的方式。 传送策 略:基于任务和计算机负载,判定是否要把一个任务传送到其它计算机上处理。 放置 策略:对于适合传送到其它计算机处理的任务,选择任务将被传送的目的计算机。 负载平衡的上述三个部分之间是以不同的方式相互作用的。 放置策略利用策略提供的 负载,仅当任务被传送策略判定为适于传送之后才行动。 总之,负载平衡的目标是:提供最短的平均任务响应时间;能适于变化的负载;是可 靠的负载平衡机制。 (1)策略 人们用来描述负载采用的参数有: 运行队列中的任务数、 系统调用的速率、 CPU 上下文切换率、 空闲 CPU 时间百分比、 空闲存储器的大小(K 字节)、 1分钟内的平均负载。 对于这些单个的负载描述参数,第(1)个,即采用运行队列中的任务数作为描述负 载的参数被证实是最有效的,即它的平均任务响应时间最短,并且已经得到广泛应用。 但是,假如为了使系统更全面而采集了更多的参数,则往往由于增加了额外开销,却得 不到所希望的性能改善。例如,采用将六个参数中的某两个进行 (2)传送策略 为了简单起见,在选用传送策略时,多选用阀值策略。例如, Eager 等人的方法是:在判定是否要在本地处理一个任务时, 无需交换计算机之间的状态,一旦服务队列或等 待服务队列的长度大于阀值时,就传送这个任务,而且传送的是刚刚接收的任务。而进 程迁移能够迁移正在执行的任务,是对这种只能传送刚刚接收的任务的一种改进。 在模拟研究七个负载平衡算法时, 其传送策略都采用阀值策略。 它的阀值策略基于两 个阀值∶计算机的负载阀值 Load 和任务执行时间阀值 TCPU 。假如计算机的负载超过 Load 并且任务的执行时间超过 TCPU 时,就把此任务传送到其它计算机执行。 (3)放置策略 经过总结,共有以下四种放置策略 ①集中策略。每隔 P 秒,其中一个计算机被指定为 ②阀值策略。 随机选择一台计算机,判定若把任务传送到那台计算机后, 那台计算机 的任务队列长度是否会超过阀值。假如不超过阀值,就传送此任务;否则,随机选择另 一台计算机,并以同样方式判定,继续这样做直到找到一台合适的目的计算机,或探测 次数超过一个静态值限制 LP ,当任务真正到达计算机以后,不管状态如何,必须处理 该任务。 ③最短任务队列策略。随机选择 LP 台不同的计算机,察看每台计算机的任务队列长 度,任务被传送到具有最短任务队列长度的计算机。当任务真正到达计算机,无论状态 如何,目的计算机必须处理该任务。对此策略的一个简单改进时,无论何时,碰到一台 队列长度为 0的计算机时, 不再继续探测, 因为可以确定此计算机是一台可以接受的目 的计算机。 ④保留策略。 当一个任务从一台计算机离开时, 该计算机检查本地负载, 假如负载小 于阀值 T1,就探测其它计算机,并在 R 个负载大于 T1的计算机中登记该计算机的名 字,并把登记的内容保留到一个栈中。当一个任务到达一台超载的计算机时,就把这个 任务传送到此台计算机栈顶的计算机上。假如一个计算机的负载低于 T1,就清空栈里 保留的所有计算机名。 从论文中,比较了②和③两种策略,结论是:以简单(计算不昂贵)的方式,利用少 量状态,第②中方法往往获得比第③种方法更好的效果。第③中方法比较复杂,它必须 用性能的改善来补偿额外花费,所以取得的效果会稍差一些。 4.3 地址分配 在 NLB 群集中,每台服务器都会有一个属于自己的静态 IP 地址,同时 NLB 群集中的 所有服务器还有一个共同的 IP 地址 — NLB 群集地址; 当客户向 NLB 群集(NLB 的虚拟 IP 地址)发起请求时,其实客户的请求数据包是发送 到所有的 NLB 节点, 即:NLB 算法需要 NLB 群集中的所有主机都能看到发往群集的每 一个数据包。然后运行在 NLB 节点上的 NLB 服务根据同样的 NLB 算法来确定是否应 该由自己进行处理,如果不是则丢弃客户的请求数据包,如果是则进行处理。 网络负载平衡使得单个子网上的所有群集主机可以同时检测群集 IP 地址的传入网络通 信。在每个群集主机上,网络负载平衡驱动程序充当群集适配器驱动程序和 TCP/IP 堆 栈间的过滤器,以便在主机间分配通信。 在配置负载均衡的时候步骤主要有三个 (1)启用网络负载平衡; (2)连接到现存的群集; (3)添加主机到群集。 1. 启用网络负载平衡:在开始 —— 运行中输入 nlbmgr , 单击 “ 确定 ” 按钮, 打开 “ 网络负载 平衡管理器 ” 窗口。如图所示 网络负载均衡管理器 2. 右击 “ 网络负载均衡群集 ” , 然后单击 “ 新建群集 ” 命令, 然后在弹出如图 5-2的对话框中 的 IP 地址和其他群集信息,选择群集操作模式为 “ 多播 ” ,然后单击 “ 下一步 ” 按钮。在这 里添加的 IP 地址是和 DC 所在在同一个网段的,在这里使用一个多播的原因是在客户 端是同时能收到信息。 3. 在 “ 群集 IP 地址 ” 的对话框中可以添加 IP 地址,如果有多个群集的 IP 地址也可以来添 加多个 IP 地址,如图 5-3是添加的端口的 IP 地址,在本次实验中只有一个网络群集的 IP 地址所以在下面选择自动添加而不是选择所有的端口,而在解析的时候是通过 DNS 服务器解析而没有使用其他的协议因此所采用 TCP 协议的端口 HTTP80;所以在这里 选择 80即可。 4. 在完成上面群集 IP 地址的规划之后, 会出现如图 5-4所示的端口规则:端口规则是可 以按照群集中每一个成员的负载量来分派客户端的通信。 当然在下面如图所示的界面中 也可以来删除端口规则。 删除端口规则也可以更加明显的看出群集的效果, 删除端口规 则可以按照端口的优先级来响应客户机请求, 假设当优先级高的出现故障那么优先级低 的主机会提供服务。当然对于客户机来说是感觉不到那个到底出现故障。 5. 完成上面的步骤在 “ 连接 ” 的对话框中来输入和服务器相连的 IP 地址;及 192.168.120.1, 点击 “ 连接 ” 就会弹出如图 5-5所示的对话框。 然后在下面的接口中选择 服务器的网络适配器(IP 地址)。 6. 完成上面的步骤基本在 DC 上的配置就完成了,在这里所采用系统默认的自动状态, 单击完成即可。 但是要明白在配置优先级的时候最多可以配置 32位, 因为 NLB 网络负 载均衡做多支持 32台主机。默认情况下他的初始状态是 “ 已启动 ” ,设置更高的优先级 的原因是当把 “ 端口规则 ” 删除的并且当其中的一台的出现故障的时候,优先级就会在这 时候起到作用。如图 5-6所示,把第一台主机的优先级设为 1。 7. 启动网络负载平衡后,在下图中 5-7所示:在群集中已经有了一台主机。根据实验的 需求还需要添加一台主机到群集:如果在第二台上添加的时候首先会连接到 “ 现存的群 集 ” 。 8. 把第二台主机连接到现存的群集,在这里连接时候是在第二个服务器上面添加。在第 二台服务器上(IP 地址为 192.168.20.2)的开始 —— 运行中输入 “nlbmgr”, 单击确定单 开 “ 网络负载均衡管理器 ” 窗口, 右击 “ 网络负载均衡平衡群集 ” ,然后 “ 选择连接到现存的 ” 命令。 在弹出的的对话框中输入第一台计算机的 IP 地址 “192.168.120.2” 单击 “ 连接 ” 然后 完成就可了! 9. 添加主机到群集; 在使用 “ 网络负载平衡管理器 “ , 在弹出的对话框中选择 “ 添加主机到 群集 ” ,添加主机的真正原因就是达到网络负载平衡的原因,如图 5-9所示: 10. 在完成上面的配置后,在下面图的界面中添加将要成为群集成员的 IP 地址(或者主 机的名称)单击连接按钮,将在底部的对话框中会弹出可以用的网络适配器。选择要用 网络负载平衡的网络适配器,即可完成。 11. 在保持主机参数为默认状态,注意优先级是 “2” 它是默认的:一切按照默认的即可。 12. 添加主机到群集后,在群集 cluster.domain.com 中会有两台服务器,最多可以有 32台主机。在图 5-12中可以知道两台主机的 IP 地址是 192.168.20.1和 192.168.20.2; 这样就完成了网络负载均衡的配置了。 网络负载均衡的最佳操作 1. 正确保护网络负载平衡主机和经过负载平衡的应用程序; 2. 在每一个群集主机上至少配置两个网络适配器,但是并非必要; 3. 在群集适配器上只使用 TCP/IP协议; 4. 保证群集中的所有主机属于同一个子网并且客户机能够访问该子网; 5. 使用网络负载均衡管理器配置 NLB 群集; 6. 不要启用网络负载平衡远程访问控制; 7. 启用日志记录; 8. 独立使用 NLB 群集和服务器群集。 2. 数据库迁移实施 一、实施概述 在做 SQL Server数据库维护的时候, 当上司要求我们把几十 G 的数据文件搬动到其它 服务器,并且要求最小宕机时间的时候,我们有没什么方案可以做到这些要求呢? 在这里我们假设这两台机器并不是在一个机房上, 这样看起来我们的解决方案才更有意 义,如果你那么好运这两台机器在同一个局域网,那么恭喜你,你可以多很多的方案可 以做到。 二、分析与设计思路 其实我们假设的环境有两个特点:第一个是数据库文件比较大; 第二个就是我们的传送 文件的速度可能会比较慢。 也许这传送速度我们是没有办法了, 但是我们可以就从文件 的大小这个问题出发,结合 SQL Server的特性,这样就有了下面的解决方案了。 为了使宕机时间最短, 我们这里使用了完整备份和差异备份来迁移数据库, 在白天的时 候对需要迁移的数据库进行一次完整备份(XXX_full.bak),并把备份文件拷贝(这里 可以使用 FTP 软件进行断点续传)到目标服务器进行还原,等到下班时间之后再进行 一次差异备份(XXX_diff.bak),再把这个差异备份拷贝到目标服务器,在完整还原的 基础上再进行差异还原。 这里的宕机时间 = 差异备份时间 + 传送差异备份文件时间 + 还原差异备份文件时间, 这宕机时间是不是让你感觉这时间很短呢? 三、参考脚本 注意修改下面脚本中数据库的名称,还有绝对路径。 --1:完整备份 declare @dbname varchar(100) declare @sql nvarchar(max) set @dbname = 'DataBaseName' set @sql = ' --'+@dbname+'_full BACKUP DATABASE ['+@dbname+'] TO DISK = ''D:\DBBackup\'+@dbname+'_full.bak'' WITH NOFORMAT, NOINIT, NAME = '''+@dbname+'-完整数据库备份 '', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO' print @sql --生成的 SQL --DataBaseName_full BACKUP DATABASE [DataBaseName] TO DISK = 'D:\DBBackup\DataBaseName_full.bak' WITH NOFORMAT, NOINIT, NAME = 'DataBaseName-完整数据库备份 ', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO --2:完整备份还原 declare @dbname varchar(100) declare @sql nvarchar(max) set @dbname = 'DataBaseName' set @sql = ' --RESTORE '+@dbname+'_full RESTORE DATABASE ['+@dbname+'] FROM DISK = ''D:\DBBackup\'+@dbname+'_full.bak'' WITH FILE = 1, MOVE N''DataBase_Name'' TO N''D:\DataBase\'+@dbname+'.mdf'', MOVE N''DataBase_Name_log'' TO N''D:\DataBase\'+@dbname+'_log.ldf'', NORECOVERY, NOUNLOAD, REPLACE, STATS = 10 GO' print @sql --生成的 SQL --RESTORE DataBaseName_full RESTORE DATABASE [DataBaseName] FROM DISK = 'D:\DBBackup\DataBaseName_full.bak' WITH FILE = 1, MOVE N'DataBase_Name' TO N'D:\DataBase\DataBaseName.mdf', MOVE N'DataBase_Name_log' TO N'D:\DataBase\DataBaseName_log.ldf', NORECOVERY, NOUNLOAD, REPLACE, STATS = 10 GO --3:差异备份 declare @dbname varchar(100) declare @sql nvarchar(max) set @dbname = 'DataBaseName' set @sql = ' --'+@dbname+'_diff BACKUP DATABASE ['+@dbname+'] TO DISK = N''D:\DBBackup\'+@dbname+'_diff.bak'' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'''+@dbname+'-差异数据库 备份 '', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO ' print @sql --生成的 SQL --DataBaseName_diff BACKUP DATABASE [DataBaseName] TO DISK = N'D:\DBBackup\DataBaseName_diff.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'DataBaseName-差异数据 库备份 ', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO --4:差异备份还原 declare @dbname varchar(100) declare @sql nvarchar(max) set @dbname = 'DataBaseName' set @sql = ' --RESTORE '+@dbname+'_full 基于小型机的信息系统迁移应用实例 【摘 要】计算机管理系统的信息量扩充到原来十几倍,由于 windows 系统消耗资源较大,同时容易遭受病毒攻击,因此需要将 由微机 windows 环境下的系统移植到运行于 unix 环境下的小型机 来替代。由于数据的重要性以及业务程序的统一及移植不容差错, 因此信息系统的迁移存在一定的安全隐患,需要采用先进安全的接 入运行系统加以保护并提高数据处理效率。本文就信息系统迁移的 流程及关键技术进行介绍。 【关键词】小型机;信息系统;多渠道;数据迁移 1 概述 1.1 项目背景 结算管理系统项目立项以来,结算管理中心本着“统一规划、发 布实施”的原则。 目前已经完成:客户信息、会计核算、资金清算、 柜员管理、系统管理、监管、数据移植、触摸屏等模块,并于 2007年 10月正式运行。剩余模块:个人抵押贷款操作、贷款管理、综 合管理等也在按计划推进。 1.2 网络现状 结算管理中心通过两台华为 -3com rt-2611实现与分中心的连接, 同时在局域网内配置两台 s2403h 交换机,提供中心内部服务器及 其他设备的连接。分中心采用华为 -3com ar18-12,通过 2m 光钎与 市中心相连,分中心交换机采用华为 -3com s1024。 1.3 部署现状服务器应用系统迁移解决方案
基于小型机的信息系统迁移应用实例