應(yīng)用系統(tǒng)遷移方案設(shè)計

1、目錄1.1 總述 21.2 系統(tǒng)遷移需求分析 21.2.1 中心系統(tǒng)遷移需求分析總體結(jié)論 21.3 遷移方案總體思路 21.3.1 保障業(yè)務(wù)中斷停機時間最小化 31.3.2 業(yè)務(wù)切割時間節(jié)點優(yōu)化 31.3.3 遷移后完整性測試 41.4 服務(wù)器硬件環(huán)境遷移方案 41.4.1 遷移評估 41.4.2 遷移計劃 41.4.3 測試計劃 51.4.4 遷移測試 51.4.5 遷移實施 61.5 運營商接入鏈路（路由）遷移 81.6 應(yīng)用系統(tǒng)和數(shù)據(jù)庫遷移方案 81.6.1 應(yīng)用服務(wù)器遷移 81.6.2 數(shù)據(jù)庫遷移實施 91.7 系統(tǒng)遷移的具體組織實施方案 101.7.1 搬遷規(guī)劃 101.7.2 詳細

2、實施方案 111.7.3 應(yīng)急處理 111.1總述按照本期招標采購要求，中心在建成后要實現(xiàn)對遷移應(yīng)用和新建業(yè)務(wù)平臺的 一體化集成?？紤]到需要遷移的指揮中心現(xiàn)有應(yīng)用包含了分析管理平臺、指揮平臺，上述平臺都是中心的核心、重要應(yīng)用，因此我公司認為原系統(tǒng)的搬遷將是項目建設(shè)的 重點和難點。本方案設(shè)計以我公司與用戶現(xiàn)系統(tǒng)承建公司的初步技術(shù)交流、用戶現(xiàn)狀分析為基礎(chǔ)，給出搬遷方案設(shè)計。1.2系統(tǒng)遷移需求分析按照用戶招標要求，本期系統(tǒng)遷移的具體需求分析如下。中心原有應(yīng)用系統(tǒng)將全部遷移至虛擬化服務(wù)平臺，遷移期間必須保證工作不 能中斷，歷史數(shù)據(jù)不能損失；遷移后的系統(tǒng)與多媒體融合通信指揮平臺融合對接。系統(tǒng)遷移的難點是

3、系統(tǒng)切割時間節(jié)點的合理規(guī)劃和確保接入路由的轉(zhuǎn)換，歷史數(shù)據(jù)的無損遷移也是系統(tǒng)搬遷的難點和重點。中心系統(tǒng)遷移需求分析總體結(jié)論通過對中心現(xiàn)有上述應(yīng)用遷移的需求分析，鑒于原系統(tǒng)建設(shè)單位并非我公 司，遷移過程中還存在對原建設(shè)廠商協(xié)調(diào)的工程風險。我公司認為系統(tǒng)遷移的重 點容包括：涉及運營商的接入切割，原有數(shù)據(jù)的遷移，合理切割時間節(jié)點規(guī)劃。1.3遷移方案總體思路中心系統(tǒng)遷移是一個整體系統(tǒng)工程。遷移必須保證用戶系統(tǒng)建設(shè)的相關(guān)要 求，在遷移方案設(shè)計中，我們重點考慮幾個問題。1.3.1 保障業(yè)務(wù)中斷停機時間最小化業(yè)務(wù)中斷對于用戶無論是運行環(huán)境還是測試環(huán)境均存在較大的恢復(fù)風險， 這 樣的風險特別對于時間敏感型數(shù)據(jù)和

4、數(shù)據(jù)完整性業(yè)務(wù)都是不可以接受的。 我們基 于這樣的要求，考慮到如何將停機時間最小，能否實現(xiàn) o停機的建設(shè)目標？1、對于服務(wù)器操作系統(tǒng)而言，我們可以采用 P2V的方式，禾U用操作系統(tǒng)的 Volume Shadow Copy卷影副本復(fù)制服務(wù)作為基礎(chǔ)，來實現(xiàn)在舊系統(tǒng)環(huán)境下的 系統(tǒng)無修改，無停機的情況下，將數(shù)據(jù)和應(yīng)用軟件、操作系統(tǒng)環(huán)境、系統(tǒng)環(huán)境變 量等全部以“快照”形式遷移到新服務(wù)器中。由此實現(xiàn)服務(wù)器環(huán)境的整體遷移。2、對于應(yīng)用中間件和其他應(yīng)用服務(wù)器來說，我們可以基于應(yīng)用服務(wù)器的動態(tài)業(yè)務(wù)擴展集群方式，來實現(xiàn)服務(wù)器不停機環(huán)境下的增加業(yè)務(wù)節(jié)點操作，這樣可以實現(xiàn)應(yīng)用服務(wù)器“熱添加”到新環(huán)境中的故障轉(zhuǎn)移 /負

5、載均衡集群系統(tǒng)中，在 部分應(yīng)用服務(wù)中我們可以使用 session會話復(fù)制來實現(xiàn)舊系統(tǒng)的全局環(huán)境變量 和會話請求狀態(tài)也遷移到新環(huán)境中來。 考慮到會話復(fù)制和狀態(tài)的快速實時， 我們 可以采用會話存復(fù)制，考慮到會話復(fù)制和狀態(tài)的安全性，我們可以采用會話數(shù)據(jù) 庫復(fù)制管理。3、對于數(shù)據(jù)庫而言，我們可以基于數(shù)據(jù)庫本身自帶的數(shù)據(jù)庫鏡像技術(shù)、數(shù) 據(jù)庫日志傳遞技術(shù)來實現(xiàn)各自的分庫、 遷移庫的構(gòu)建，數(shù)據(jù)庫鏡像技術(shù)可以讓我 們不但保證數(shù)據(jù)庫遷移的不停機，而且還可以保證萬一遷移中出現(xiàn)停機故障也不 影響源數(shù)據(jù)庫，而日志傳遞技術(shù)構(gòu)建的遷移可以保證系統(tǒng)數(shù)據(jù)庫遷移以異步方式 進行，這樣可以讓我們的系統(tǒng)環(huán)境在網(wǎng)絡(luò)出現(xiàn)故障的情況依然

6、可以進行遷移任務(wù) 窗口的正常工作。1.3.2 業(yè)務(wù)切割時間節(jié)點優(yōu)化針對XXX系統(tǒng)等需要確保不間斷對外提供服務(wù)的應(yīng)用， 需要通過對用戶歷 史應(yīng)用進行分析，選擇最優(yōu)的的切割時間節(jié)點，并提切割期間的備份鏈路、人工 受理手段。133 遷移后完整性測試遷移涉及到應(yīng)用、實例、數(shù)據(jù)庫的操作以外，還涉及到遷移前規(guī)劃、遷移后 測試的完整性測試。這些測試包括但不限于數(shù)據(jù)一致性測試、數(shù)據(jù)完整性測試、 應(yīng)用會話狀態(tài)完整性測試、連接中斷測試、數(shù)據(jù)恢復(fù)測試。只有這樣才能保證遷 移的安全性和有效性。1.4服務(wù)器硬件環(huán)境遷移方案按照用戶招標要求，本次項目建設(shè)的服務(wù)硬件環(huán)境主要是從原有刀片服務(wù)器 向本次招標新采購云服務(wù)平臺的遷

7、移。云服務(wù)平臺支持對原有服務(wù)器硬件環(huán)境和 操作系統(tǒng)環(huán)境虛擬，可以降低遷移的難度。遷移評估遷移前，我公司將對遷移方案進行評估以確保遷移成功。 首先我公司將派員 勘察現(xiàn)有系統(tǒng)的架構(gòu)和資源使用狀況，評估過程必須包含以下信息和容：現(xiàn)有系統(tǒng)支撐的服務(wù)數(shù)量以及在服務(wù)器中的分布情況；現(xiàn)有物理服務(wù)器資源占用狀況，包括 CPU存、磁盤和網(wǎng)絡(luò)連接狀況，為保 證遷移成功，目標虛擬機規(guī)格應(yīng)不低于原物理機標準；當前的物理環(huán)境是否支持虛擬化，是否支持資源擴展，因為在遷移之前須在 物理服務(wù)器上完成虛擬化；對當前的存儲容量和資源利用率進行評估， 需在目標系統(tǒng)中規(guī)劃好遷移需要 的存儲空間。需明確現(xiàn)有存儲如何利用，比如有些服務(wù)器

8、是在本地磁盤上創(chuàng)建系 統(tǒng)盤和用戶盤，有些服務(wù)器則在本地磁盤上創(chuàng)建系統(tǒng)盤而在 SAN/NASt創(chuàng)建用戶 盤。遷移計劃通過對現(xiàn)有網(wǎng)絡(luò)環(huán)境的評估，我們對現(xiàn)有資源利用率，服務(wù)以及系統(tǒng)需求非 常清晰并進行評估后才能開始對遷移進行計劃，步驟如下：1、確定遷移步驟，包括所有服務(wù)器的遷移先后順序，其順序按風險的高低 降序排列。2、確定備份方案，由于現(xiàn)有系統(tǒng)會被加固，某些服務(wù)器通過虛擬化重復(fù)利 用，而在虛擬化前需要清除所有的數(shù)據(jù)，因此需要對這些服務(wù)器進行備份保證服 務(wù)的連續(xù)性。3、確定并準備好遷移所需的工具，包括工具在遷移中必備的一系列功能和 使用工具所需具備的網(wǎng)絡(luò)環(huán)境。4、在實際遷移開始之前確定額外的測試環(huán)境

9、，該測試環(huán)境能夠引導(dǎo)測試從 而確保遷移成功。因此，測試環(huán)境需明確設(shè)計的服務(wù)器和存儲數(shù)量。5、規(guī)劃網(wǎng)絡(luò)環(huán)境，由于網(wǎng)絡(luò)中的服務(wù)器各處不同位置，因此在遷移中需考 慮到網(wǎng)絡(luò)連接情況、數(shù)據(jù)備份方式，以及網(wǎng)絡(luò)流量來源，確定網(wǎng)絡(luò)流量是否會引 發(fā)網(wǎng)絡(luò)擁塞6確定遷移周期以及參與人員，包括遷移起止時間，團隊能力建設(shè)以及團 隊成員的角色。測試計劃遷移計劃后，執(zhí)行小批量的測試遷移方案，這里會涉及到首批遷移的測試和 審核，步驟如下：準備用于測試遷移的測試系統(tǒng)環(huán)境，在測試時，第一批服務(wù)器將會遷移到 該系統(tǒng)環(huán)境中。安裝并核實遷移工具，此時要執(zhí)行第一批服務(wù)器的P2V遷移。對第一批服務(wù)器，需分析存儲系統(tǒng)，不管該服務(wù)器在存儲遷移

10、中采用本地 磁盤存儲還是遠端SAN/NA苗儲系統(tǒng)。遷移測試在第一批服務(wù)器和服務(wù)的小批量測試遷移后，需對遷移后的服務(wù)器進行測 試，包括單元測試和性能測試。遷移實施在遷移實施過程中，所有的服務(wù)器都會被遷移到虛擬化系統(tǒng)下。執(zhí)行步驟如 下：確保批量遷移的整個網(wǎng)絡(luò)環(huán)境已準備完畢，并通過遷移工具完成源系統(tǒng)和 目標系統(tǒng)之間的連通。此處的目標系統(tǒng)屬于中轉(zhuǎn)系統(tǒng)。對遷移系統(tǒng)進行性能審核和健康檢查，如果系統(tǒng)狀態(tài)監(jiān)視則停用舊系統(tǒng)并 將其服務(wù)暫時轉(zhuǎn)移到新的虛擬化系統(tǒng)中。進行利舊，對于一部分可用的舊硬件可在服務(wù)器虛擬化中重新再利用， 一 些軟件資源需擴展，如存和硬盤。這些服務(wù)器構(gòu)成最終的虛擬化基礎(chǔ)設(shè)施， 即最 終系統(tǒng)。最

11、后，在目標系統(tǒng)和最終系統(tǒng)之間進行 V2V遷移。145.1服務(wù)器虛擬化前進行備份為了對舊系統(tǒng)中的物理服務(wù)器進行虛擬化，需考慮服務(wù)器虛擬化帶來的影 響。例如，現(xiàn)有服務(wù)器的重復(fù)利用，服務(wù)器虛擬化時會對這些服務(wù)器的CPU存以及硬盤資源進行再利用，然而這些服務(wù)器上存在某些服務(wù)仍在運行，若無備份 則會影響現(xiàn)有業(yè)務(wù)。因此，在執(zhí)行遷移和虛擬化之前，必須先對需利舊的服務(wù)器 進行備份。提供物理備份服務(wù)器，并已進行虛擬化，數(shù)據(jù)和服務(wù)器已備份到虛擬化系統(tǒng)。首先，對于要被遷移的服務(wù)器上，一般會存在多種服務(wù)正在運行，而且這 些服務(wù)器在遷移評估后認為在虛擬化場景下可再利用的。 但是，遷移過程中不允 許存在較長的停機時間，因

12、此需要準備一臺采用虛擬化平臺的備份虛擬機， 通過 P2V將該服務(wù)器備份到虛擬機上。備份完所有需要進行虛擬化的服務(wù)器之后，這些服務(wù)器上安裝虛擬化軟件 進行虛擬化，根據(jù)評估階段確定的容量規(guī)劃，在虛擬化平臺上創(chuàng)建相應(yīng)規(guī)格的虛 擬機，其計算資源用于承接舊系統(tǒng)中的服務(wù)。準備好所有的虛擬機后，規(guī)劃和安裝相關(guān)遷移工具，將備份系統(tǒng)中的服務(wù) 遷移到虛擬化系統(tǒng)的虛擬機中。虛擬機遷移是指將備份的虛擬化系統(tǒng)中的應(yīng)用服 務(wù)遷移到最終的虛擬化系統(tǒng)中。虛擬機遷移完畢后，要對這些服務(wù)進行測試，最后停用舊系統(tǒng)，所有服務(wù) 切換到虛擬化系統(tǒng)中。145.2 遷移的詳細操作步驟遷移的具體步驟及描述如下：1、在評估階段，虛擬化和遷移之前

13、需收集的信息如下：性能統(tǒng)計：包括CPU使用率，存使用率，硬盤IOPS和硬盤使用情況；物理服務(wù)器配置：包括 CPU規(guī)格，存容量，硬盤容量統(tǒng)計物理服務(wù)器部署位置，分析是否支持虛擬化，累計支持虛擬化的服務(wù) 器數(shù)量，并規(guī)劃出虛擬化中需新增的硬件情況；通過上述無代理收集和代理收集兩種場景收集當前系統(tǒng)的使用和配置情況。 可采用信息收集工具。2、分析現(xiàn)有服務(wù)的依賴條件，對當前系統(tǒng)進行備份。確定應(yīng)用系統(tǒng)對服務(wù)器的依賴關(guān)系， 可作為遷移參考，確定所有服務(wù)器的遷 移優(yōu)先級順序。在確定各服務(wù)的依賴條件后，對需進行虛擬化的服務(wù)器進行備份。3、容量規(guī)劃和虛擬化執(zhí)行根據(jù)當前的資源使用和需求情況，計算虛擬化所需的容量。4、

14、規(guī)劃應(yīng)用服務(wù)在擬化解決方案中，同類虛擬機部署在同一個計算資源池中， 在同一個池中 可相互共享存儲/計算資源，一個集群的故障不會影響其他資源池。5、虛擬化規(guī)劃和虛擬機分配建立虛擬化平臺后，要準備最終的遷移資源。遷移前，如果服務(wù)器a具備雙 核CPU和 2G存，那么在虛擬化平臺中就創(chuàng)建一個 2核/2G存的虛擬機，并分配 相應(yīng)的硬盤。6 規(guī)劃遷移工具采用遷移工具從物理或虛擬的服務(wù)器向最終的虛擬化系統(tǒng)中進行磁盤復(fù)制。7、通過工具執(zhí)行在線遷移準備好源系統(tǒng)，目標虛擬機以及目標系統(tǒng)后，決定遷移時需使用的遷移工具 和遷移策略。8、遷移測試遷移后，需進行測試來驗證遷移是否成功，測試場景如下：應(yīng)用服務(wù)遷移后對虛擬化

15、基本功能的監(jiān)測；遷移前后應(yīng)用服務(wù)的特性功能是否幾乎相同；虛擬化系統(tǒng)的性能監(jiān)控；9、停用舊系統(tǒng)截至目前現(xiàn)有的服務(wù)器已經(jīng)被虛擬化和重復(fù)使用， 其他一些不支持虛擬化的 服務(wù)器上對應(yīng)的服務(wù)也已經(jīng)遷移到虛擬化平臺，那么現(xiàn)在可將應(yīng)用服務(wù)切換到虛 擬系統(tǒng)并停用舊系統(tǒng)。1.5運營商接入鏈路（路由）遷移運營商接入鏈路（路由）的遷移主要是新中心所需物理鏈路的申請，接入路由制作、應(yīng)用正式切割前測試的開通以及切割當日應(yīng)急措施。針對前四部分容， 可以按照中心需要完全備份一份，在系統(tǒng)正式切割前進行模擬運行測試。切割當日要做好應(yīng)急保障措施，如切割一旦不成功，迅速切回原路由保障系 統(tǒng)的運行。同時在新指揮備份足夠的備份鏈路，支

16、持人工受理。上述鏈路的具體配置方案在中標后進一步確認。1.6應(yīng)用系統(tǒng)和數(shù)據(jù)庫遷移方案針對本項目建設(shè)，我們將在應(yīng)用系統(tǒng)和數(shù)據(jù)庫遷移前， 在用戶新招標采購的 云平臺中部署與原應(yīng)用一樣的操作系統(tǒng)、 中間件、服務(wù)器管理平臺軟件環(huán)境，確 保遷移的環(huán)境變化風險最低。應(yīng)用服務(wù)器遷移針對本項目應(yīng)用系統(tǒng)遷移，原系統(tǒng)全部是基于 IIS應(yīng)用環(huán)境、.NET應(yīng)用程 序框架。本方案計劃對IIS等應(yīng)用環(huán)境以及.net應(yīng)用程序框架提出構(gòu)建IIS環(huán) 境的NLB群集，將當前系統(tǒng)不停機加入到NLB群集中，使之成為群集中的一個節(jié) 點，而新環(huán)境則為另外一個節(jié)點。實施完成后再退出此遷移群集，將新環(huán)境加入 到新的構(gòu)建的NLB群集。NLB不

17、但能實現(xiàn)均衡負載，而且還能實現(xiàn)多種形式的冗余。 NLB主要用于那 些文件改動不大，并且不常駐存的環(huán)境，比如 WE曲艮務(wù)、FTP服務(wù)、和VPNK務(wù) 等。當用戶訪問集群的時候，集群能將訪問請求分攤到集群中的每個服務(wù)器上， 以達到均衡負載的效果。這些服務(wù)器被稱為集群節(jié)點。在負載平衡中，每個節(jié)點 的文件一般都要一樣的。這樣每個節(jié)點返回給客戶的結(jié)果都是一致的。一般來說 組建一個NLB要求至少兩個節(jié)點，其中一個節(jié)點不能使用，這全部負載將落入到 剩下的那個節(jié)點上，即全載。NLB能提供三種冗余功能，軟件冗余、硬件冗余、 站點冗余。162數(shù)據(jù)庫遷移實施針對本項目數(shù)據(jù)庫遷移，需要將中心積累的歷史數(shù)據(jù)文件搬遷到新中

18、心服務(wù) 器，并且要求最小宕機時間，同時面臨的難點還包括服務(wù)器并不在同一個一個機 房。1、分析與設(shè)計思路針對本項目數(shù)據(jù)庫搬遷環(huán)境特點：第一個是數(shù)據(jù)庫文件比較大；第二是傳送 文件的速度可能會比較慢(廣域網(wǎng)傳輸)。初步解決方案如下。為了使宕機時間最短，我們這里使用完整備份和差異備份來遷移數(shù)據(jù)庫，在白天的時候?qū)π枰w移的數(shù)據(jù)庫進行一次完整備份(XXX_full.bak)，并把備份文件拷貝(這里可以使用FTP軟件進行斷點續(xù)傳)到目標服務(wù)器進行還原，等到 下班時間之后再進行一次差異備份(XXX_diff.bak)，再把這個差異備份拷貝到 目標服務(wù)器，在完整還原的基礎(chǔ)上再進行差異還原。這里的宕機時間 =差異

19、備份時間 +傳送差異備份文件時間 +還原 差異備份文件時間，不存在宕機時間。2、保證數(shù)據(jù)遷移過程中的安全性和操作可審計性數(shù)據(jù)遷移中的安全性不可忽略，本方案設(shè)計基于多重數(shù)據(jù)審計功能實現(xiàn)遷移 安全性和操作審計性。1.7系統(tǒng)遷移的具體組織實施方案針對本項目建設(shè)，涉及中心生產(chǎn)系統(tǒng)的搬遷，上述系統(tǒng)具有停機時間要求短、 系統(tǒng)結(jié)構(gòu)復(fù)雜、測試時間長、設(shè)備繁多、使用人員多、層次復(fù)雜等特點。本項目 搬遷，時間非常緊，且設(shè)備間的穩(wěn)定性也是一個考驗。因此，必須協(xié)調(diào)好各單位 人員的關(guān)系，齊心協(xié)力才可能在預(yù)定時間完成搬遷工程。本項目搬遷組織以盡量不影響日常工作或?qū)⒂绊懡档偷阶畹蜑榍疤岬那闆r 下制定，即在保障容最少日的最少時間節(jié)點開始搬遷， 盡快完成必須搬遷的服務(wù) 器、網(wǎng)絡(luò)設(shè)備的搬遷、安裝及測試。并且在開機以后，繼續(xù)跟蹤系統(tǒng)的運行情況, 隨時處理系統(tǒng)運行的異常情況。搬遷需要原系統(tǒng)建設(shè)公司人員的充分協(xié)調(diào)