【導讀】整體業務全部遷移到到雲端是個複雜而龐大的工程，一定要有前期的充分調研，明確的需求定位，與雲端廠商和系統廠商的充分交流溝通。即便如此在遷移的過程中仍舊會遇到各種預料不到的問題，本文結合某醫院雲端遷移專案，分享了專案建設過程中面臨的技術問題和解決方案。

【作者】社群ID：diliangyu520，某三甲醫院資訊中心科員，從事虛擬化、大資料等領域，參與醫院整個資訊系統遷移雲端的專案。

某省級綜合三甲醫院，開放床位 3092 張，開設住院病區 78 個，設有 38 個臨床科室， 15 個醫技科室。2019 年，醫院完成年門急診量 250.7 餘萬人次，出院 11.9 餘萬人次，完成手術 3.5 萬臺，平均住院日 8.8 天，屬於中等規模的大型三甲醫院。醫院建設有 2 個機房，分別位於兩棟不同的大樓中透過光纖相連線，院內共有 45 個各類資訊系統，共有實體伺服器及虛擬化伺服器 200 餘臺。2019 年，根據省衛建委要求，所有醫療機構不建議新建機房，所有服務都應遷移至雲端，至此醫院決定將院內所有系統遷移至雲端。

經過調研分析後，選擇國內大型 ISP 商，距醫院 15 公里外的核心機房中構建一個私有云，共需約 8 架 4KW 機櫃，含 9 臺計算節點伺服器和 10 臺儲存節點伺服器、 4 臺管理監控伺服器、 4 臺資料庫物理伺服器、 1 臺災備前置機伺服器、 2 臺集中式雙活儲存、 2 臺光纖交換機，配套網路裝置 2 臺四槽位核心交換機，萬兆交換機 4 臺、千兆交換機 3 臺，並附有等保涉及的安全裝置一併規劃，安全裝置將按照等保三標準統一建設。專案在建設過程中面臨的技術問題和解決方案如下。

一、 網路問題

1） 埠管控：醫院計劃與雲機房用 40G 頻寬 4 路光纖專線連線。出於安全考慮，與雲端的所有連線都要經過埠管控。醫院經過十幾年資訊化的發展，也有著自己原本的網路構架，因為做了內外網隔離，所有院內系統都是在內網中傳輸，只需要設定好 IP 地址就不需要考慮埠的問題。經過雲端的埠管控，所有的資訊系統都要對埠進行整體測試。私有云的底層架構中網路卡的所有配置需要在底層運維人員的修改處理，所有網路卡地址的修改都伴隨著埠的統一管理，遷移後要與開發廠商共同協調各類埠。對於這個複雜的工作，整個遷移專案中採用初期調研，詳細記錄好所有系統及裝置的埠使用情況，在雲端先建立測試機，與廠商協同測試好相應網路卡及埠配置，在系統測試成功後再進行遷移。

二、 伺服器

1）伺服器的配置：專案開始初期，雲端廠商做了大量的前期調研。整理了醫院現有系統使用的 CPU 、記憶體、儲存和資料庫等相關資訊。醫院原有的無論實體機還是虛擬機器都是按照 CPU 核數 1 ：1 比例的配置，遷移至雲端後，因為雲端計算資源調配的靈活性， CPU 核數並非按照 1 ：1 比例配置。初期雲端廠商使用 6 臺伺服器做虛擬化計算資源，院方認為醫院內的資訊系統比較複雜，有些應用系統對資源的需求量很高，雲端如果按照 1 ：3 的虛擬 CPU 核數將無法達到院內需求，甚至影響醫院未來資訊化發展。透過與雲端廠商的討論研究，最終雲端廠商同意將計算節點伺服器由 6 臺增至 9 臺，並把虛擬 CPU 核數的虛擬比例由 1 ：3 降低至 1 ：2 ，為此擴容工作將工期多拖延 2 個月。

2）作業系統的安裝：醫院現有伺服器有實體的、有使用 ctrix 為底層的 XEN 構架的虛擬機器。而云端使用的是使用 openstack+KVM 做虛擬機器的構架。整體遷移方案時採用在雲端重新安裝作業系統、重新部署應用和安裝資料庫，這樣在將醫院系統遷移至雲端就存在很多問題，一些常用的作業系統可以透過直接安裝來解決，而院內虛擬機器環境中有些系統是定製化的系統， openstack 支援 qCOW2 格式的虛擬機器， XEN 架構只有 ova 或 ovf 格式的虛擬機器，面對這樣的定製系統時，如果原始系統安裝映象 iso 不能很好的轉換成 qCOW2 格式，那麼伺服器的基本安裝都存在問題。醫院在遷移中就遇到因作業系統無法安裝，導致一個重要的系統遲遲不能遷移，後來由雲端廠商進行技術攻關才解決此問題。

3） 資料的遷移：能夠保證遷移資料完整性和一致性的整機遷移需要透過停機後才可以遷移，而因為醫療行業的特殊性，業務系統的執行不能中斷，醫院也存在各類佔用極大空間的資料，使得整體遷移並不能透過短暫停機來實現。

經過論證最終遷移使用的方案就是在源伺服器和目標伺服器同時安裝資料遷移代理軟體，透過建立好互通的網路鏈路，架設一臺用於遷移資料的控制伺服器對資料進行傳輸校驗。首先在雲端建立全新目標機虛擬機器，安裝相同的作業系統、預留相同的磁碟空間、部署相同的環境，根據不同應用系統要求在後臺傳輸目標伺服器所需要資料，待資料傳輸完成經過校驗後，將源伺服器暫時停機資料庫匯出透過遷移代理傳輸至目標伺服器，目標伺服器將資料庫匯入恢復，將網路配置更改後關閉源伺服器，啟用新伺服器。資料遷移的過程中一定要注意以下原則，以防目標伺服器不可用時產生髒資料。

1. 確保業務系統平穩順利遷移為最根本原則。

2. 在遷移工程中，不進行任何系統架構的調整或變更，以避免專案交叉導致的業務風險。

3. 制定相應的遷移方案，確保當機時間可控。

4. 需要對遷移前後的應用伺服器效能進行對比分析，保證資源利用率的合理性以及 IOPS 要求。

三、 儲存

醫院的儲存基本是用伺服器自帶硬碟（包括 SAS ， SATA 和 SSD ）和多個品牌型號的集中儲存。雲端使用的是 Ceph 儲存，使用大量伺服器插滿硬碟做分散式儲存，這樣不同的儲存方式也帶來不同的問題。Ceph 本身就是分散式儲存構架，優勢在於能夠動態地伸縮、再均衡和修復，醫院內系統應用的複雜導致儲存資料的格式差異非常大，如有需要實時讀取的小碎片 XML 檔案，也有體積巨大的 DCom 影像檔案，而且不同的系統對檔案儲存響應時間要求也不同。專案初期時是使用 SAS 和 SATA 硬碟作為儲存，院方與雲端廠商提出不同系統的 IO 需求時，雲端廠商使用 SSD 硬碟擴容，用於影像系統這類對 IO 要求較高的系統。

四、 災備

當醫院的所有資訊系統遷移至雲端後，所有的業務都透過光纖專線進行傳輸。儘管有 4 條專線，但仍舊存在光纖故障導致醫院業務停滯的可能。

基於以上考慮，這次遷移後將對醫院原有伺服器進行充分利舊，做成一個緊急災備機房，將核心業務系統在醫院內做應用級備份。當線路出現故障時第一時間能夠啟用醫院內的災備應用，保障醫院所有業務的正常執行。

本次資訊系統的資料備份均採用網路方式進行資料備份，根據醫院需求本次資料備份資料量共計 100TB ，容災資料 15TB 。初期要分別對院內所有需求進行容災和備份的業務系統進行調研並定級，在制定完善調研表後，其中 HIS 、 LIS 等核心系統需要實時資料保護， PACS 系統業務自身為冗餘互備模式，不需要使用容災系統，只需對部分資料做定期備份。根據對各業務系統的定級，確定每臺伺服器的災備策略，並與各業務系統廠商確認要備份的檔案目錄和業務型別，如資料庫或普通檔案等，在災備策略中進行配置。根據業務系統的要求配置對應的備份策略和資料保留策略，啟動容災備份服務，對核心系統（如 HIS ， EMR ， PACS,LIS, 整合平臺等）建立應用級災備，保證因為網路問題連線中斷時在院內原有系統可以順利接管。

五、 結語

整體業務全部遷移到到雲端是個複雜而龐大的工程，一定要有前期的充分調研，明確的需求定位，與雲端廠商和系統廠商的充分交流溝通。即便如此在遷移的過程中仍舊會遇到各種預料不到的技術問題，所以當決定系統整體遷移的時候，務必規劃好工期進度以及軟硬體的需求，充分考慮好未來的擴容的需求，內外網互訪，安全管理，災備等方面內容。