李剛

關鍵詞：VMware Esxi虛擬化平臺；平臺升級改造；超融合；數(shù)據(jù)遷移

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2024）03-0088-03

1 概述

安徽醫(yī)科大學附屬阜陽醫(yī)院是一所集醫(yī)療、教學、科研、康復、保健、預防為一體的現(xiàn)代化綜合性三級甲等公立醫(yī)院，于2017年7月開診運營。因醫(yī)院臨床業(yè)務數(shù)據(jù)增多、大量新業(yè)務系統(tǒng)上線等原因，數(shù)據(jù)中心已不能滿足日益增長的信息化需求，需要進行升級改造。

本文結合醫(yī)院虛擬化平臺改造升級項目案例，重點探討虛擬化平臺改造升級中的數(shù)據(jù)遷移技術。

2 改造升級方案

2.1 項目背景

改造升級前，醫(yī)院有兩套虛擬化平臺和二十余臺X86物理服務器承載臨床業(yè)務系統(tǒng)，主要存在以下四種部署方式。

1） VMware Esxi虛擬化平臺：由三臺物理機承載，通過兩臺SAN交換機連接三臺存儲設備，承載PACS、病理管理、病案統(tǒng)計、LIS等30多個業(yè)務系統(tǒng)。

2） 華為Fusion Compute虛擬化平臺：由十臺物理機承載，通過兩臺SAN交換機連接三臺存儲設備，承載心電網(wǎng)絡、合理用藥、自助機打印、合理用血等40多個業(yè)務系統(tǒng)。

3） NAS平臺：由五臺高性能物理服務器承載，通過NAS技術共享一臺存儲設備，分別承載HIS、EMR數(shù)據(jù)庫、EMR應用、集成平臺數(shù)據(jù)庫、集成平臺應用五個重要的業(yè)務系統(tǒng)。

4） 單服務器：二十余臺低性能物理服務器，每臺服務器承載一個非常重要的業(yè)務系統(tǒng)。

改造前IT系統(tǒng)架構如圖1所示。

改造前的IT系統(tǒng)主要存在以下問題：

1） 設備型號老舊、軟件無法升級：承載虛擬化平臺的服務器（華為RH2285H V2） 、存儲設備（華為Ocean?Stor S2600T） 設備型號老舊，已到使用壽命周期。華為虛擬化平臺版本為1.0版，版本老舊且無法升級。

2） 架構可靠性低：HIS、EMR、系統(tǒng)集成平臺等核心服務器均為單臺部署，無雙活或主備機制；存儲設備均為單機部署，無冗余設計，存在單點故障，架構可靠性低。

3） 平臺拓性能低下：存儲設備型號老舊，存儲無法掛載存儲柜擴容；SAN交換機及服務器HBA卡均為8GB，傳輸速度慢。

2.2 需求分析

由于承載虛擬化平臺的物理服務器和存儲設備型號老舊，性能下降嚴重，架構可靠性存在安全隱患、業(yè)務拓展性差，需要建設一套新的虛擬化平臺，并遷移業(yè)務數(shù)據(jù)系統(tǒng)到新的虛擬化平臺。

2.3 升級方案

以虛擬化技術為基礎，結合Vmware軟件，將醫(yī)院現(xiàn)有生產(chǎn)業(yè)務系統(tǒng)部署到超融合虛擬化平臺上，利用萬兆以太網(wǎng)支撐系統(tǒng)間的數(shù)據(jù)交換，實現(xiàn)計算、存儲、網(wǎng)絡等資源的統(tǒng)一管理[1]。

1） 超融合架構：超融合架構是指在同一套單元設備中具備計算、網(wǎng)絡、存儲和虛擬化等資源和技術，多節(jié)點通過網(wǎng)絡聚合以用來實現(xiàn)模塊化的橫向擴展，形成統(tǒng)一資源池架構。由于穩(wěn)定可靠、優(yōu)異的性能、快速搭建等優(yōu)勢，已漸漸取代傳統(tǒng)的光纖存儲架構（FCSAN交換機+光纖存儲），而成為數(shù)據(jù)中心虛擬化平臺首選[2]。本次部署6臺高性能4U超融合服務器，搭載7.0版本Vmware軟件，搭建一套基于超融合架構的全虛擬化業(yè)務平臺。

2） 核心存儲：由于HIS、EMR、集成平臺是醫(yī)院最核心業(yè)務系統(tǒng)，選擇兩套15T全閃存核心存儲設備，將現(xiàn)有HIS、EMR、集成平臺的數(shù)據(jù)集中存儲在全閃存存儲陣列上，在兩套存儲之間采用雙活技術實現(xiàn)存儲級別的容災保護，并新增一臺容災存儲，作為核心存儲的數(shù)據(jù)備份，增強數(shù)據(jù)安全性。

3） FC-SAN交換機：目前SAN交換機均為8GB，本次采用兩臺主流的16GB-FC SAN，作為本次超融合平臺計算與存儲資源的數(shù)據(jù)橋梁，提高數(shù)據(jù)訪問速度。

改造后IT系統(tǒng)架構如圖2所示。

3 數(shù)據(jù)遷移問題與探索

數(shù)據(jù)遷移是本次虛擬化平臺改造升級的重點。遷移指的是把源主機上的操作系統(tǒng)和應用程序移動到目的主機，并且能夠在目的主機上正常運行[3]，主要分為冷遷移和熱遷移。冷遷移是指在源主機停止服務的狀態(tài)下，使用遷移工具將整個源主機的數(shù)據(jù)移動到目的主機。熱遷移是指在源主機不停機的狀態(tài)下，把數(shù)據(jù)遷移到目的主機。冷遷移方式可以創(chuàng)建一份和源主機最為一致的數(shù)據(jù)，因為在遷移期間源主機的數(shù)據(jù)庫數(shù)據(jù)不會被寫入，應用系統(tǒng)數(shù)據(jù)也屬于停止寫入狀態(tài)，因此遷移后的目標主機和源主機的數(shù)據(jù)最為一致。在允許停止業(yè)務的情況下，一般推薦使用冷遷移方式。但由于醫(yī)院信息系統(tǒng)使用環(huán)境的特殊性，例如HIS、LIS、電子病歷系統(tǒng)停用較長時間，會對病人、醫(yī)生造成極大的不便，影響病人就診和醫(yī)生及時診療。除此之外，醫(yī)院業(yè)務系統(tǒng)較多，各業(yè)務系統(tǒng)之間數(shù)據(jù)交互、數(shù)據(jù)共享復雜，因此本次數(shù)據(jù)遷移時不但要保證數(shù)據(jù)的安全性和完整性，更要盡可能地保證各業(yè)務系統(tǒng)的持續(xù)服務。本項目通過信息系統(tǒng)項目管理知識，根據(jù)不同場景采用多種遷移方式，進行不完全停機數(shù)據(jù)遷移。

3.1 項目管理

數(shù)據(jù)遷移工作十分煩瑣且龐雜，需要制定合理的計劃。本項目采用信息系統(tǒng)管理的進度管理、溝通管理、風險管理的相關知識。

進度管理階段：首先搜集待遷移業(yè)務系統(tǒng)數(shù)量、業(yè)務數(shù)據(jù)量、數(shù)據(jù)庫空間、操作系統(tǒng)版本等信息，定義超融合服務器安裝、存儲設備安裝、聯(lián)合調試、遷移服務器等活動節(jié)點，估算各項活動的持續(xù)時間，最終制定合理的施工進度計劃，確保每個活動在預定時間內(nèi)完成。

溝通管理階段：本次升級改造中涉及的應用軟件廠家、項目技術人員、醫(yī)院科室較多，由于不同角色對該項目的期望值不同，因此在項目實施中，采用了頭腦風暴、問卷調查、建立微信群等方式，定期召開項目溝通協(xié)調會，保持溝通流暢。

風險管理：在遷移業(yè)務系統(tǒng)前，根據(jù)醫(yī)院業(yè)務系統(tǒng)的重要程度，劃分為核心、重要、一般、非重要四個業(yè)務等級，并對每個系統(tǒng)進行定性風險評估和定量風險評估，制定了應急方案，方案內(nèi)容包括遷移詳細步驟及遷移失敗后的應急操作步驟及恢復所需時間。

3.2 數(shù)據(jù)遷移技術探討

本次虛擬化平臺改造升級，共涉及145臺服務器的遷移，數(shù)據(jù)庫主要是Oracle和Sql server數(shù)據(jù)庫。數(shù)據(jù)遷移應遵循盡量不停業(yè)務、降低影響范圍、能夠應急恢復等要求。

1） 同一類型虛擬化平臺遷移：源虛擬機平臺和目標虛擬機平臺都屬于VM架構，但不在同一個虛擬化平臺，需要跨vCenter Server 進行計算資源和存儲遷移。本次采用V2V業(yè)務系統(tǒng)在線熱遷移方式，實現(xiàn)不停機在線遷移業(yè)務系統(tǒng)。采用方式為：把源VM虛擬機平臺由6.0版本升級到6.5版本（目標VM虛擬機和源虛擬機平臺均需在6.5版本及以上），采用VM自帶的Advanced Cross vCenter vMotion 工具，把源虛擬機平臺內(nèi)業(yè)務系統(tǒng)的計算資源和存儲一起熱遷移到超融合VCENTER管理平臺。

2） 不同類型虛擬化平臺遷移：針對物理機、華為虛擬化平臺的業(yè)務系統(tǒng)，利用“VMware vcenter Con?verter”遷移工具進行P2V方式遷移。首先在超融合VM虛擬化平臺內(nèi)新創(chuàng)建一臺虛擬機并安裝VMwareConverter軟件，指定待遷移的源虛擬化平臺和目標虛擬化平臺，在遷移即將完成前幾分鐘，通知業(yè)務部門停止寫入數(shù)據(jù)，等待所有數(shù)據(jù)同步完成后，老的業(yè)務系統(tǒng)停機，遷移后的系統(tǒng)更換成老業(yè)務系統(tǒng)的IP地址，完成整個遷移工作。

3） 異構系統(tǒng)遷移：異構系統(tǒng)切換升級是一個數(shù)據(jù)資源遷移的過程[4]。HIS、EMR、集成平臺是醫(yī)院核心的業(yè)務系統(tǒng)，均部署在windows2008 R2操作系統(tǒng)，采用oracle 11.2.0.1數(shù)據(jù)庫。此次遷移，HIS服務器遷移后采用Centos系統(tǒng)，EMR、集成平臺的操作系統(tǒng)升級到WINDOWS 2016版本，數(shù)據(jù)庫都統(tǒng)一升級到oracle11.2.0.4 版本。在oracle 數(shù)據(jù)庫遷移中，本次采用ORACLE DATAGUARD 和RMAN工具保證數(shù)據(jù)庫的無縫遷移。步驟如下：首先在超融合內(nèi)部署虛擬機及操作系統(tǒng)、數(shù)據(jù)庫，在遷移準備階段，開啟歸檔并在目標虛擬機內(nèi)搭建ORACLE DATAGUARD，建立Win?dows與LinuX/Windows的數(shù)據(jù)同步機制并進行檢查，確保數(shù)據(jù)庫具備主備切換條件。在數(shù)據(jù)庫割接階段，根據(jù)提前和臨床科室溝通好的割接操作時間，目標服務器更改為源服務器的IP地址，并完成主備數(shù)據(jù)庫的切換工作，并交付給應用使用。在應用上線階段，對應用測試，確認是否具備上線條件，如測試數(shù)據(jù)正常則確認應用切換成功，否則按回退方案回退至原生產(chǎn)環(huán)境，啟動應用交付使用。

3.3 數(shù)據(jù)遷移注意事項

由于醫(yī)院臨床業(yè)務系統(tǒng)業(yè)務連續(xù)性、數(shù)據(jù)準確性要求較高，遷移數(shù)據(jù)時要注意以下幾點：

1） 系統(tǒng)遷移前，提前搜集各業(yè)務系統(tǒng)的業(yè)務數(shù)據(jù)量、數(shù)據(jù)庫數(shù)據(jù)量、操作系統(tǒng)版本、IP等信息，預估各系統(tǒng)遷移時間，切換的時間，并根據(jù)業(yè)務系統(tǒng)的數(shù)據(jù)量，通過事前測試，掌握數(shù)據(jù)遷移的耗時，落實各個操作的時間點[5]。

2） 遷移過程中，應做好充分的準備工作，因需要的遷移工具較多，在數(shù)據(jù)遷移時，要注意各工具出現(xiàn)的報錯信息，及時排查。遷移時，提前做好備份，萬一出現(xiàn)遷移失敗，可以通過備份文件及時恢復。

3） 數(shù)據(jù)遷移完成后，要登錄到業(yè)務系統(tǒng)服務器及時進行數(shù)據(jù)校驗，進行服務、數(shù)據(jù)庫數(shù)據(jù)驗證。如出現(xiàn)應用報錯，應及時回退到原生產(chǎn)環(huán)境。

4） 利用信息管理系統(tǒng)進行精細化管理。在數(shù)據(jù)遷移中，要注意做好管理計劃、風險管理、溝通管理等工作。

4 典型問題分享

本次遷移中，出現(xiàn)了一些數(shù)據(jù)遷移典型問題，進行分享。

問題一：輸血系統(tǒng)在遷移時，進度條長時間卡在1%，界面顯示報錯信息：“Connecting to the Converterhelper server on the destination virtual machine.”。

解決方式：由于源虛擬機的防火墻處于開啟狀態(tài)，阻止了443端口。由于443端口用于HTTPS服務， 因此一直遷移不成功。關閉防火墻，解除對443端口阻止即可。

問題二：低性能物理服務器利用VMware vcenterConverter 遷移時，提示“Error Clonevolume：detected awrite error during the cloning”報錯。

解決方式：由于VMware vcenter Converter軟件不支持部分服務器導致。本次利用Netbackup工具，選擇自定義RMAN腳本備份方式，進行“全量+增量”方式進行遷移。

5 總結

本次通過分享醫(yī)院虛擬化平臺升級改造案例，重點探討了虛擬化平臺改造升級中的數(shù)據(jù)遷移技術。通過本次升級，實現(xiàn)了一個管理平臺管理所有醫(yī)院內(nèi)網(wǎng)業(yè)務系統(tǒng)，在提高IT基礎運行環(huán)境、提供安全可靠性的同時，也方便了后期運維，助力醫(yī)院信息化更加穩(wěn)定運行。

【通聯(lián)編輯：光文玲】