小型機下移x86開放平臺最佳實踐

近年來，隨著技術進步，x86服務器性能日漸提升，同時供貨周期短、價格低，有利于銀行提高運營效率，降低維護成本。因此，各大銀行紛紛嘗試將關鍵系統部署環境從小型機下移到x86開放平臺，從而建立以x86開放平臺為基礎的自主可控運營體系。

在這個技術潮流引導下，中信銀行與時俱進，最終形成了一套成熟的小型機下移中信方案。在下移實施中，中信銀行在方案和技術上進行了創新和突破，沒有發生過一起因小型機下移導致的生產事件。

一、從小型機下移到x86開放平臺標準流程

中信銀行在從小型機下移到x86開放平臺的實踐中充滿各種挑戰，其中從組織層面，需要科技運營中心和軟件開發中心兩個部門緊密協作。因此，需要格式化、模板化的標準流程，按照標準流程制定小型機下移x86開放平臺的目標和計劃。只有這樣，才能降低跨部門溝通成本，從根本上控制風險和提高下移工作效率。

1.制定下移目標。

將目標系統所用小型機下移到x86開放平臺，并實現基礎軟件版本升級，這是總體目標。圍繞這個目標，還要綜合考慮以下方面。

x86服務器資源目標：選擇哪種資源配置可以代替小型機。

操作系統相關目標：由AIX替換為紅帽Linux系統，紅帽Linux系統采用什么版本。

數據庫相關目標：所用數據庫服務器由小型機替換為x86服務器，IBM DB2數據庫采用什么版本。

中間件相關目標：IBM Websphere Application Server（簡稱WAS）采用什么版本，Oracle JDK采用什么版本，IBM MQ采用什么版本。

應用相關目標：根據應用對軟件版本兼容性的限制要求，應用應如何部署。

存量數據遷移相關目標：將數據庫中的數據平滑遷移至新服務器中，還是無需遷移。

2.制定下移計劃。

明確了下移目標，接下來就是針對目標制定下移計劃。制定系統下移計劃時，按照以下內容進行。

首先，對目標系統進行技術分析，包括系統的架構，對周邊系統的影響，確認服務器資源轉換方案、基礎軟件版本升級方案等。

隨后，制定測試方案并開展測試工作，組織相關人員對測試后的測試報告進行評估，決定是否要真正實施下移。

再次，開始真正的下移實施。基于服務器資源轉換方案搭建硬件環境，基于基礎軟件版本升級分析結論，安裝相關軟件；完成舊應用遷移和部署；完成存量數據從舊環境到新環境的遷移與數據校驗；在時間窗口內，完成新系統割接上線；割接后進入試運行階段，在該階段如有阻斷性問題則進行回退，如果一切正常則認為下移成功。

最后，完成下移總結。總結下移的各個階段，有哪些做得好的，有哪些值得改進等。

二、從技術分析開始

在小型機下移標準流程中，對目標系統進行技術分析是初始步驟，需要深入分析系統架構、服務器資源轉換等內容。

1.系統架構分析。

系統架構分析包括邏輯架構分析和物理架構分析。

邏輯架構分析。分析該系統屬于哪類業務系統、與外聯系統的關系、各子系統關系；從邏輯關系判斷下移及升級工作對相關子系統或業務的影響。

物理架構分析。分析目標系統的物理拓撲圖，明確目標系統所用服務器、存儲和網絡情況，明確基礎軟件（包括應用、應用服務器、數據庫）的部署情況等。

2.服務器資源轉換分析。

基于目標系統所用小型機配置現狀，選定x86服務器的配置方案，這就需要確定從小型機到x86服務器的配置映射方案。

首先，中信銀行對小型機和x86服務器進行了性能對比測試。在測試中選擇了1臺總計24內核（2C 12核）的IBMS824小型機對比1臺總計88內核（4路 22核）的x86服務器，同時運行IBM DB2 V10.5數據庫，通過HammerDB工具測試對比TPC-C測評值NOPM（New Order Per Minute）。對比顯示，x86服務器88內核和IBMS824小型機24內核的處理能力相當，這說明根據相應的配置映射關系，x86服務器可以代替小型機。

基于上述對比測試結果，再結合中信銀行相關部署規范，中信銀行制定了下述資源映射原則。

（1）x86服務器與小型機CPU映射原則：x86服務器4內核相當于小型機1內核。例如1臺24內核的小型機可以用1臺88內核的x86服務器進行同等替換。

（2）內存映射原則：容量相等配置。

（3）硬盤映射原則：容量相等配置，但建議x86服務器優先選擇固態硬盤（SSD）。

（4）網絡映射原則：帶寬相等配置。

（5）服務器映射原則：應用、應用服務器采用虛擬機；數據庫服務器采用x86服務器。

3.基礎軟件版本升級分析。對目標系統涉及的數據庫、中間件等基礎軟件版本也要進行分析評估，確保滿足軟件版本管理要求，原則上下移后所有涉及的基礎軟件版本需要升級到主推版本，如有特殊情況則需要給出不升級的原因。

三、測試方案制定

在小型機下移中，測試方案的制定是重要一環，只有通過了專業測試才能開展后續下移工作。可以采用傳統測試方法或者高仿真測試方法，其中高仿真測試方法是科技運營中心科技創新成果，基于該方法科技運營中心還自主研發了高仿真自動化測試平臺。

1.傳統測試方法。

現階段，軟件產品升級或重大變更前，業內經常使用傳統測試方案，例如功能測試、系統測試和壓力測試等，來完成下移前測試。測試前需要梳理測試場景，并根據場景來定制測試用例；隨后，需要測試人員根據測試用例定制化開發測試腳本，用于實現各場景的回歸測試；測試的數據均采用測試人員模擬的數據，測試數據存在一定程度的失真。

2.高仿真測試方法。

高仿真測試是通過生產網絡流量鏡像方式獲取真實業務報文數據，再通過一種基于交易報文精確化匹配和自動化返回方法與裝置，將真實業務報文自動化地發送至兩種測試環境（小型機與x86服務器），基于報文粒度對每一筆系統間傳輸的往復報文進行字段級對比，依此判斷總結兩個平臺的差異化報文，從而達到測試目的，如圖所示。

圖 高仿真測試架構

傳統測試方法存在效率低、周期長、投入大的問題。針對小型機下移場景，絕大部分應用接口不變，在這種情況下高仿真測試是最適合的方法，其優勢表現如下。

高仿真測試突破了傳統測試方案對交易路徑設置固定擋板的方案，將每一筆交易的往復規則記錄在數據庫中，并自動關聯匹配真實的響應報文，替換關鍵動態信息字段后反饋被測系統，達到交易的100%全覆蓋。

解決了傳統測試模擬測試數據帶來的不真實性。高仿真所用真實生產數據，能清晰表現生產真實交易情況。

高仿真測試整個定制及測試過程實現自動化，因此大大節省了測試人力并縮短了測試工期。

3.測試方法選擇。

在小型機下移實踐中，我們按照下面的選擇原則：如果修改了程序，但是沒有改變接口和應用邏輯，使用高仿真測試；如果修改了接口，則繼續采用傳統測試方法；對于重新編譯了程序，但對功能、程序邏輯沒有影響，則仍然采用高仿真測試。

四、下移實施

基于服務器資源轉換分析結論，基于基礎軟件版本升級分析結論，在新的x86服務器環境安裝操作系統、數據庫和中間件等基礎軟件，接下來就進入系統下移實施階段。

1.前期準備。

在前期準備階段，重點在于檢查目標系統基礎軟硬件安裝部署情況，主要包含如下。

（1）檢查已交付應用服務器虛擬化配置，包括：系統參數、應用參數、連通性檢查等方面。

（2）檢查已交付數據庫服務器或虛擬化配置。包括：系統參數、數據庫參數、各服務器連通性等。

（3）檢查x86環境的應用程序、中間件、Web服務器、消息中間件、數據庫等版本是否與分析報告中一致。

（4）如涉及Java應用程序下移與升級，需要檢查通過單元測試和相應測試的應用程序包，是否和開發中心正式發布的版本一致。

（5）如涉及C/C++應用程序下移與升級，需要檢查通過單元測試和相應測試的應用可執行文件，是否和開發中心正式發布的版本一致。

（6）在測試環境，對整個下移步驟進行演練，如果發現問題及時修正。

2.應用遷移。

這里主要針對Java和C/C++兩類開發語言簡述其遷移過程。

（1）Java應用遷移。如果在遷移中，存在JDK版本升級，建議用新版JDK對Java應用進行重新編譯，如果有兼容性問題，在編譯時可以提前發現和解決；如果DB2數據庫版本發生了升級，那么應用連接DB2的驅動也要替換成新版驅動。

（2）C/C++應用遷移。使用x86平臺的C/C++編譯器，對源代碼重新編譯并鏈接生成可執行文件；如果代碼存在兼容性問題，可在編譯或者鏈接階段提前發現和解決。

3.數據遷移。

考慮到中信銀行原來運行在小型機的數據庫主要為IBMDB2，因此以IBMDB2為例說明以下供選擇的數據遷移方案。

（1）DB2遷移方案。DB2move采用DB2原生工具實現跨平臺數據遷移，在x86服務器目標端新建所有對象，隨后采用DB2move工具在小型機環境將DB2數據全量導出，傳輸至x86新環境加載。

（2）IBM CDC遷移方案。IBM CDC通過從源端（小型機）抽取日志，在目標端（x86服務器）回放實現源端與目標的數據同步，從而實現了將DB2中的數據從小型機到x86新環境的平滑遷移。

（3）Q復制遷移方案。IBM Q復制和IBM CDC類似，利用Capture程序在源端捕獲事務日志，利用IBM MQ將日志傳輸到目標端，最終在目標端進行日志重放實現數據同步。

（4）遷移方案選擇。在數據遷移中，方案選擇的基本策略如下：如果目標系統的停機時間窗口充足，數據量在300GB以內，首選DB2遷移方案；如果停機時間窗口不足，首選IBM CDC方案；在HP平臺下，如果時間窗口不足，應選擇IBM Q復制方案。

4.回退方案。

在小型機下移中或者下移后，如果遇到短時間無法解決的阻斷性問題，就要啟用預先準備好的回退方案及時回退，以確保業務連續性。

（1）回退決策點。根據下移實踐，具體決策點包括如下情形，如果滿足以下條件，則必須進行變更回退：小型機（源端）與x86服務器（目標端）存在數據不一致問題，且數據量巨大，無法在時間窗口內完成數據同步時；啟動應用后，出現影響業務使用的問題，且在時間窗口內無法解決時；由于某種外部不可抗力因素影響系統整體下移變更進度，從而導致時間窗口內無法完成變更時；系統出現嚴重性能問題，對業務影響程度較大、范圍較廣，且無法通過調優手段解決問題時。

（2）回退步驟。經決策后，將新增數據同步到舊數據庫，同時將業務切換到舊的小型機運行環境，實現整體回退。

五、實踐總結

依靠科技創新，中信銀行最終在2021年底，利用兩年時間基本完成了53套關鍵系統共計180臺IBM小型機下移工作，基礎設施云化比例達到99.6%以上。完成小型機下移后，中信銀行獲得了極好的收益。系統下移至x86服務器后，硬件采購和維護費減少了60%；聯機交易性能平均提升了10倍，批處理性能平均提升了2倍；提升了關鍵系統的處理性能，實現了資源整合，為基于x86開放平臺的智能運維奠定了良好基礎。中信銀行通過下移積累了豐富的技術資產，發表論文1篇，申請國家專利1項，申請軟件著作權2項。

尤為重要的是，中信銀行在此過程中取得了豐富的實踐經驗。

1.提升組織效率的關鍵——制定系統下移總控計劃。在遷移方案具體步驟和流程確定后，考慮到系統割接當日需要各方協作，因此根據下移時間要求編寫系統下移總控表是提高組織效率的關鍵。

2.預先發現問題的關鍵——遷移前做好自檢。當新的生產x86環境搭建完畢后，即可開展自檢工作，主要包括x86環境連通性、參數正確性、合規性等內容，預先發現和解決問題。

3.提升下移進度的關鍵——采用高仿真測試方法。在下移實施中，測試環節最耗時耗力，也是瓶頸所在。針對小型機下移應用接口不變的特點，中信銀行大膽采用高仿真測試方法，大幅提升了測試效率，確保了下移的快速推進。

4.確保數據正確的關鍵——一致性檢查。針對數據遷移，無論采用何種遷移方案，在系統割接后，為了確保數據的一致性，都必須做好數據一致性對比檢查。

5.節省時間窗口的關鍵——自動化方案。在下移過程中，盡量采用自動化變更步驟，從而大幅節省時間窗口。

6.提升安全性的關鍵——做好備份。在小型機下移割接前，必須進行相關數據的備份，萬一數據出現損壞可以使用備份及時恢復。