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

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

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

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

5、載均衡集群系統(tǒng)中，在 部分應用服務中我們可以使用 session會話復制來實現(xiàn)舊系統(tǒng)的全局環(huán)境變量 和會話請求狀態(tài)也遷移到新環(huán)境中來。 考慮到會話復制和狀態(tài)的快速實時， 我們 可以采用會話存復制，考慮到會話復制和狀態(tài)的安全性，我們可以采用會話數(shù)據(jù) 庫復制管理。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)絡出現(xiàn)故障的情況依然

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

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

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

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

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

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

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

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

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

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

16、持人工受理。上述鏈路的具體配置方案在中標后進一步確認。1.6應用系統(tǒng)和數(shù)據(jù)庫遷移方案針對本項目建設，我們將在應用系統(tǒng)和數(shù)據(jù)庫遷移前， 在用戶新招標采購的 云平臺中部署與原應用一樣的操作系統(tǒng)、 中間件、服務器管理平臺軟件環(huán)境，確 保遷移的環(huán)境變化風險最低。應用服務器遷移針對本項目應用系統(tǒng)遷移，原系統(tǒng)全部是基于 IIS應用環(huán)境、.NET應用程 序框架。本方案計劃對IIS等應用環(huán)境以及.net應用程序框架提出構(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曲艮務、FTP服務、和VPNK務 等。當用戶訪問集群的時候，集群能將訪問請求分攤到集群中的每個服務器上， 以達到均衡負載的效果。這些服務器被稱為集群節(jié)點。在負載平衡中，每個節(jié)點 的文件一般都要一樣的。這樣每個節(jié)點返回給客戶的結(jié)果都是一致的。一般來說 組建一個NLB要求至少兩個節(jié)點，其中一個節(jié)點不能使用，這全部負載將落入到 剩下的那個節(jié)點上，即全載。NLB能提供三種冗余功能，軟件冗余、硬件冗余、 站點冗余。162數(shù)據(jù)庫遷移實施針對本項目數(shù)據(jù)庫遷移，需要將中心積累的歷史數(shù)據(jù)文件搬遷到新中

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

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