后端服务迁移方案.docx

上传人:王** 文档编号:1251529 上传时间:2024-06-06 格式:DOCX 页数:16 大小:29.19KB
下载 相关 举报
后端服务迁移方案.docx_第1页
第1页 / 共16页
后端服务迁移方案.docx_第2页
第2页 / 共16页
后端服务迁移方案.docx_第3页
第3页 / 共16页
后端服务迁移方案.docx_第4页
第4页 / 共16页
后端服务迁移方案.docx_第5页
第5页 / 共16页
后端服务迁移方案.docx_第6页
第6页 / 共16页
后端服务迁移方案.docx_第7页
第7页 / 共16页
后端服务迁移方案.docx_第8页
第8页 / 共16页
后端服务迁移方案.docx_第9页
第9页 / 共16页
后端服务迁移方案.docx_第10页
第10页 / 共16页
亲,该文档总共16页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《后端服务迁移方案.docx》由会员分享,可在线阅读,更多相关《后端服务迁移方案.docx(16页珍藏版)》请在优知文库上搜索。

1、后端服务迁移方案阶段时序动作双写+数据对比1新Fb集群上线双写+数据对比2新服务上线,无流量双写+数据对比2后端自己发起的流程比如job,新服务上线一份新的,独立运行双写+数据对比2消费二方mq,新服务使用新的消费组消费原有消息双写+数据对比3新旧服务比较转发服务ComPaQtor上线,定时拉取新旧库数据对比是否一致,并打印对比日志双写+数据对比4旧服务改造上线双写+数据对比4旧服务http读、写请求转发comparator,再转发到新服务双写+数据对比5运行若干天,根据数据对比结果处理程序问题,无问题后可确认写程序已无问题双写+数据对比5ComPaator打印部分新服务读请求结果,同时调用旧

2、服务获取结果,对比是否一致,无问题后可确认读程序已无问题灰度6由于数据是周期性的,而后台管理系统仅是内部人员使用,因此数据不做迁移,后台使用新旧不同前端入口做灰度流量转发灰度6新服务新增数据id起始值远大于旧服务id最大值灰度6由于是任务发放的业务,C端不产生新数据,都由后端生成数据,接口如果有id,转发旧服务,旧服务加开关,如大于阈值则转发新服务灰度6C端接口根据id查询,转发旧服务,旧服务加开关,如大于阈值则转发新服务,小于则继续走旧服务灰度6C端列表接口聚合新旧服务数据,旧服务做聚合,加开关切流过渡期7旧服务已无有效数据,关闭聚合逻辑切流完成8旧服务只做转发ip漂移9旧服务的ip漂移至新

3、服务,完成迁移后端服务迁移方案服务器和应用系统迁移方案一、迁移方案总体思路新旧系统的迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求,在迁移过程中,我们需要重点考虑几个问题:1.数据迁移如何保障业务中断停机时间”。业务中断对用用户无论是生产环境还是测试环境均存在较大的恢复风险,这样的风险特别是对于时间敏感型数据还是对于数据完整性业务都是不可以接受的。我们基于这样的要求,考虑到如何将停机时间最小,能否实现O停机的建设目标?i.对于应用HS和其他应用服务器来说,我们可以基于应用服务器的动态业务扩展集群方式,来实现服务器不停机环境下的增加业务节点操作,这样可以实现应用服务器热添加到新环境中

4、的故障转移/负载均衡集群系统中,在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时,我们可以采用会话内存复制,考虑到会话复制和状态的安全性,我们可以采用会话数据库复制管理。H.对于数据库而言,我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建,数据库镜像技术可以让我们不但保证数据库迁移的不停机,而且还可以保证万一迁移中出现停机故障也不影响源数据库,而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行,这样可以让我们的系统环境在网络出现故障的情况依然可以进行

5、迁移任务窗口的正常工作。2、迁移涉及到的除了应用、实例、数据库的操作以外,还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。二、服务器硬件环境迁移方案1 .迁移评估迁移前,对迁移方案进行评估以确保迁移成功。首先需要勘察现有系统的架构和资源使用状况,评估过程必须包含以下信息和内容:现有系统支撑的服务数量以及在服务器中的分布情况现有物理服务器资源占用状况,包括CPU、内存、磁盘和网络连接状况,为保证迁移成功,目标虚拟机规格应不低于原物理机标准当前的物理环境是否支持

6、虚拟化,是否支持资源扩展,因为在迁移之前须在物理服务器上完成虚拟化对当前的存储容量和资源利用率进行评估,需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用,比如有些服务器是在本地磁盘上创建系统盘和用户盘,有些服务器则在本地磁盘上创建系统盘而在SAN/NAS上创建用户盘。2 .迁移计划通过对现有网络环境的评估,我们对现有资源利用率,服务以及系统需求非常清晰。评估后才能开始对迁移进行计划,步骤如下:一、确定迁移步骤,包括所有服务器的迁移先后顺序,其顺序按风险的高低降序排列。二、确定备份方案,由于现有系统会被加固,某些服务器通过虚拟化重复利用,而在虚拟化前需要清除所有的数据,因此需要对这

7、些服务器进行备份保证服务的连续性。三、确定并准备好迁移所需的工具,包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。四、在实际迁移开始之前确定额外的测试环境,该测试环境能够引导测试从而确保迁移成功。因此,测试环境需明确设计的服务器和存储数量。五、规划网络环境,由于网络中的服务器各处不同位置,因此在迁移中需考虑到网络连接情况、数据备份方式,以及网络流量来源,确定网络流量是否会引发网络拥塞六、确定迁移周期以及参与人员,包括迁移起止时间,团队能力建设以及团队成员的角色。3 .测试计划迁移计划后,执行小批量的测试迁移方案,这里会涉及到首批迁移的测试和审核,步骤如下:准备用于测试迁移的测试系

8、统环境,在测试时,第一批服务器将会迁移到该系统环境中。安装并核实迁移工具,此时要执行第一批服务器的P2V迁移。对第一批服务器,需分析存储系统,不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS存储系统。4 .迁移测试在第一批服务器和服务的小批量测试迁移后,需对迁移后的服务器进行测试,包括单元测试性能测试。5 .迁移实施在迁移实施过程中,所有的服务器都会被迁移到虚拟化系统下。执行步骤如下:确保批量迁移的整个网络环境已准备完毕,并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。对迁移系统进行性能审核和健康检查,如果系统状态监视则停用旧系统并将其服务暂时转移到新的

9、虚拟化系统中。进行利旧,对于一部分可用的旧硬件可在服务器虚拟化中重新再利用,一些软件资源需扩展,如内存和硬盘。这些服务器构成最终的虚拟化基础设施,即最终系统。最后,在目标系统和最终系统之间进行V2V迁移。这样,最终系统完成了现存硬件的重复利用。a.服务器虚拟化前进行备份为了对旧系统中的物理服务器进行虚拟化,需考虑服务器虚拟化带来的影响。例如,现有服务器的重复利用,服务器虚拟化时会对这些服务器的CPU,内存以及硬盘资源进行再利用,然而这些服务器上存在某些服务仍在运行,若无备份则会影响现有业务。因此,在执行迁移和虚拟化之前,必须先对需利旧的服务器进行备份。提供物理备份服务器,并已进行虚拟化,数据和

10、服务器已备份到虚拟化系统。首先,对于要被迁移的服务器上,一般会存在多种服务正在运行,而且这些服务器在迁移评估后认为在虚拟化场景下可再利用的。但是,迁移过程中不允许存在较长的停机时间,因此需要准备一台采用虚拟化平台的备份虚拟机,通过P2V将该服务器备份到虚拟机上。备份完所有需要进行虚拟化的服务器之后,这些服务器上安装虚拟化软件进行虚拟化,根据评估阶段确定的容量规划,在虚拟化平台上创建相应规格的虚拟机,其计算资源用于承接旧系统中的服务。准备好所有的虚拟机后,规划和安装相关迁移工具,将备份系统中的服务迁移到虚拟化系统的虚拟机中。虚拟机迁移是指将备份的虚拟化系统中的应用服务迁移到最终的虚拟化系统中。虚

11、拟机迁移完毕后,要对这些服务进行测试,最后停用旧系统,所有服务切换到虚拟化系统中。b.迁移的详细操作步骤A.在评估阶段,虚拟化和迁移之前需收集的信息如下:性能统计:包括CPU使用率,内存使用率,硬盘IOPS和硬盘使用情况;物理服务器配置:包括CPU规格,内存容量,硬盘容量统计物理服务器部署位置,分析是否支持虚拟化,累计支持虚拟化的服务器数量,并规划出虚拟化中需新增的硬件情况;通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。可采用华为信息收集工具或者第三方工具。B.分析现有服务的依赖条件,对当前系统进行备份。上图描述了一种应用系统下的依赖关系,可作为迁移参考,确定所有服务器的迁

12、移优先级畴。在确定各服务的依赖条件后,对需进行虚拟化的服务器进行备份。具体备份过程参见本小节迁移实施方案中服务器虚拟化前进行备份部分的内容。C.容量规划和虚拟化执行根据当前的资源使用和需求情况,计算虚拟化所需的容量。D.规划应用服务在华为虚拟化解决方案中,同类虚拟机部署在同一个计算资源池中,在同一个池中可相互共享存储/计算资源,一个集群的故障不会影响其他资源池。E.虚拟化规划和虚拟机分配建立虚拟化平台后,要准备最终的迁移资源。迁移前,如果服务器a具备双核CPU和2G内存,那么在虚拟化平台中就创建一个2核/2G内存的虚拟机,并分配相应的硬盘。F.规划迁移工具采用迁移工具从物理或虚拟的服务器向最终

13、的虚拟化系统中进行磁盘复制。G.通过工具执行在线迁移准备好源系统,目标虚拟机以及目标系统后,决定迁移时需使用的迁移工具和迁移策略。H.迁移测试迁移后,需进行测试来验证迁移是否成功,测试场景如下:应用服务迁移后对虚拟化基本功能的监测;迁移前后应用服务的特性功能是否几乎相同;虚拟化系统的性能监控;I.停用旧系统截至目前现有的服务器已经被虚拟化和重复使用,其他一些不支持虚拟化的服务器上对应的服务也已经迁移到虚拟化平台,那么现在可将应用服务切换到虚拟系统并停用旧系统,其步骤如下:三、应用系统数据库迁移方案1.应用服务器迁移到群集环境为满足企业不断的成长需求,实现企业服务器的高可伸缩性、高可用、高可靠性

14、和高性能,提升服务器的S1.A,MiCBSOft到目前为止,提出了五种解决方案:我们对于11S等应用环境以及.net应用程序框架我们提出构建HS环境的N1.B群集,将当前系统不停机加入到N1.B群集中,使之成为群集中的一个节点,而新环境则为另外一个节点。实施完成后再退出此迁移群集,将新环境加入到新的构建的N1.B群集。微软的网络负载平衡可以提供最多32台主机的负载平衡,当我们的Web站点需要分担更多用户访问请求的时候,负载均衡无疑是值得考虑的一个解决方案。当然N1.B也有相应的限制,像广域网环境中,我们就不能使用N1.B进行设置,因为其网络不允许使用同一个MAC地址,也就违反了N1.B的基本要

15、求。在安全方面,除了我们进行的端口规则设定,Windows2003SerVer本身基于TCP/IP堆栈的集成是动态的,不用进行任何人工干预,这种设置有效的防止了DOS攻击等恶意攻击。除此之外,企业结合自身的网络安全,确保N1.B站点的高效运作。N1.B不但能实现均衡负载,而且还能实现多种形式的冗余。N1.B主要用于那些文件改动不大,并且不常驻内存的环境,比如WEB服务、FTP服务、和VPN服务等。N1.B不适合用于数据库、邮件等服务,因为不能保证每个节点的数据是一样的。当用户访问集群的时候,集群能将访问请求分摊到集群中的每个服务器上,以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中,每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个N1.B要求至少两个节点,其中一个节点不能使用,这全部负载将落入到剩下的那个节点上,即全载。Windowsserver2003最多支持32个节点。节点越多,可用性,可靠性就越高。N1.B能提供三种冗余功能,软件冗余、硬件冗余、站点冗余。基于N1.B集群的Web网站数据库设计1 .M

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/环境 > 建筑规划

copyright@ 2008-2023 yzwku网站版权所有

经营许可证编号:宁ICP备2022001189号-2

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!