基于云計算框架的OLTP類業務安全可控模型的一般性探究

李 萌

(國家藥品監督管理局信息中心 北京 100044)

0 引 言

當前，新一輪信息革命正引領人類從工業文明加速向信息文明轉型，全面影響和重塑經濟運行、社會發展、國家治理、人民生活等各個領域，政務信息化已成為通往現代治理之路必不可少的重要依托。全面加快政務信息化創新發展，已成為推進國家治理體系和治理能力現代化建設的重要手段，對于深化行政體制改革，建設法治政府、創新政府、廉潔政府和服務型政府具有重要意義。伴隨著信息技術和互聯網的飛速發展，政府采用信息技術調整行政管理的形態和方式，為社會和公眾提供便捷有效和高質量的服務是世界趨勢，政務信息化已成為時代潮流。國家也已經把信息化上升為國家戰略[1]。

2020年3月，中共中央政治局常務委員會召開會議提出，加快5G網絡、數據中心等新型基礎設施建設進度?！靶禄ā眲荼貙⑼七M5G、AI、大數據、云計算等業務飛速發展,未來數據中心網絡需要在無損、智慧、開源等方面全面提升能力,為新一代業務應用保駕護航[2]。在當前的國際競爭格局下，知識產權自主可控十分重要，做不到這一點就一定會受制于人。習總書記在關于網信工作的系列講話之中，強調了不止一次“加快推進國產自主可控替代計劃，構建安全可控的信息技術體系”。關于網絡安全信息化的一個重要指示，其中提到了要加快推進國產自主可控的替代計劃，就是國產的產品進入市場要有替代能力，要有個計劃去替代它，替代壟斷的外國產品。政務信息化系統有著數據敏感、關乎國計民生等重大事項，不管在硬件還是軟件部分都應當做好國產自主可控的替代[3]。

云計算不管是公有云還是私有云作為全新的資源服務模式起到舉足輕重的作用。在藥品監管領域，由于種種原因，部分物理環境下部署的OLTP應用系統，云化遷移的工作正在開展，但是遇到了許多問題[4]，物理環境和虛擬化環境的指標評估不對稱導致P2V的業務架構不合理、資源申請不合理、網絡設計不合理等系列問題，對整體工作量影響比較大。同時，在虛擬化環境下業務安全問題也是一個大的挑戰。在這個過程中，業內其實并沒有一個成熟的參考模式和考量指標[5]。尤其目前在我國加快推進國產自主可控替代的大環境下，這項工作的難度和復雜度又有提高。

1 OLTP業務系統分析

1.1 背景分析

對于OLTP業務系統，概念已經非常清晰，即聯機事務處理系統(On-Line Transaction Processing)是一種以事務元作為數據處理的單位、人機交互的計算機應用系統[6]。

在政府領域，存在大量的此類系統，比如國家藥品監督管理局網站管理系統、總局統一行政準入管理系統(互聯網)、執業藥師管理信息系統等，其最大的特點是由前臺、應用、數據庫共同完成，其處理快慢以及處理程度取決于數據庫引擎、服務器、應用引擎。

國家藥品監督管理局信息中心承擔著云平臺建設的相關任務和職責，云平臺構建完成后，各部門只需通過在虛擬的平臺上部署自己的應用，而后端的平臺交給云計算中心處理，那將可以大大簡化用戶部署的煩瑣性和維護的復雜性，也提高資源的利用率，各部門無須獨立購買硬件和基礎軟件來部署獨立的應用。各部門在部署應用系統的云化架構，需要平臺側配合來完成設計和部署?；诖?，本文設計相關云化模型的評估和探究。

1.2 維度分析

OLTP的云化一般考慮以下幾個維度。

維度1基礎信息分析。主要考慮因素如表1所示。

表1 基礎信息分析表

維度2業務負載分析。主要考慮因素如表2所示。

表2 業務負載分析表

維度3技術分析。主要考慮因素如表3所示。

表3 技術分析表

維度4風險分析。主要考慮因素如表4所示。

表4 風險分析表

維度5遷移價值分析。主要考慮因素如表5所示。

表5 價值分析表

經驗總結看來，對以上5個維度指標和因素的OLTP類業務適合云化，對于有特殊條件的業務系統應該遵循以下原則。

1.3 特殊條件評估原則

有以下特殊條件的業務系統不建議云化處理，本文所描述云化的概念是指基礎硬件經過hypervisor層資源管理調度的虛擬機或者提供的裸金屬物理機服務(Bare Metal Server，BMS)。

條件1：特殊硬件依賴，比如非云化的硬件密碼機、硬件網關類設備。

條件2：實時性要求特別高，比如實時數據采集類、直播視頻中流媒體轉發類服務。

條件3：大型數據庫，比如數據庫表數高于200、分布式數據庫、交易量高于1 000筆每秒、有復雜的數據庫邏輯、有存儲過程、有較強的約束條件。

條件4：部分一體機應用。

2 云化評估核心模型的設計

2.1 云化構造的一般描述

云化構造的過程不是簡單地把物理環境的應用系統按照資源1 ∶1搬遷到云平臺上，而是充分考慮到業務系統的訪問壓力、網絡帶寬、資源利用情況、運維管理、應用開發語言、應用所依賴的操作系統、中間件、數據庫等因素，重新設計云環境下的軟件和應用架構及網絡模型，重新考慮各類安全防護手段和策略，以滿足應用系統的正常訪問和資源利用的最大化，降低固定資產和人力資源的投資。

2.2 核心模型的設計

根據經驗，業務應用在云計算環境下設計以下幾類模型。

Type 1：簡單模式。

本模式為簡單模式，總體特點是簡單業務架構，單VPC，應用架構為三層架構，分為Web層、應用層和DB層。

每層中單獨劃分子網和子網掩碼，在不同的子網進行訪問時，考慮用VFW和安全組等方式進行南北向和東西向流量的防護。架構如圖1所示。

圖1 Type 1模型

Type 2：中等模式1。

本模式為通用型應用業務類，總體特點是業務架構每層都采用VPC單獨劃分和隔離，應用架構為三層架構，分為Web層、應用層和DB層三大類VPC，每個VPC內部根據不同的業務邏輯可以劃分多個子網網段。通常來講，在復雜的應用系統中，應用邏輯是由多個子系統或者子模塊來完成，相互之間有較強的交互關系和數據同步。不同的子系統或者子模塊用不同的子網網絡來承載，保證安全性，在后續彈性擴容的時候，也容易根據DHCP來合理規劃私網地址，確保子網空間的可用性和可規劃性。

VPC之間訪問和交互考慮用VFW來隔離，VFW和安全組方式進行南北向和東西向流量的防護。架構如圖2所示。

圖2 Type 2模型

Type 3：中等模式2。

本模式為重載應用業務類，總體特點是業務架構每層都采用VPC單獨劃分和隔離，應用架構同樣為三層架構，分為Web層、應用層和DB層三大類VPC，每個VPC內部根據不同的業務邏輯可以劃分多個子網網段。

與Type 2相類似的是，不同的子系統或者子模塊用不同的子網網絡來承載，保證安全性，在后續彈性擴容的時候，也容易根據DHCP來合理規劃私網地址，確保子網空間的可用性和可規劃性。

與Type 2不同的是，有些重載型業務應用不適合用虛擬機來承載，因此考慮用裸金屬物理機，物理機和虛擬機的差別這里不再贅述。同時，隨著重載業務上云，這些業務系統的重要性也不言而喻，對虛擬機的高可靠要求也越來越高，對于一些核心應用來說，采用HA的技術來保證虛擬機的高可靠，從而來保證業務系統的高可靠用性，滿足一定的SLA約束。

同樣地，VPC之間訪問和交互考慮用VFW來隔離，VFW和安全組方式進行南北向和東西向流量的防護，BMS作為一種資源的服務統一納管到云平臺，按照DCHP的模式來分配所需的子網空間和具體的IP地址。具體架構如圖3所示。

圖3 type 3模型

Type 4：復雜模式。

本模式為非單DC復雜業務類，總體特點是業務通過不同的數據中心(DC)來保證業務的連續性。在某單個數據中心內部，應用架構同樣為三層架構，分為Web層、應用層和DB層三大類VPC組，每個VPC內部根據不同的業務邏輯可以劃分多個子網網段。

具體架構如圖4所示。

圖4 type 4模型

在跨數據中心的鏈路中考慮3個層次的問題：(1) Web層，通過負載均衡設備來完成對于解析后的目的地址的分配，保證按照不同的區域來就近解析相關目的地址；(2) 應用層，通過自身做應用的集群，可以把應用的狀態數據實時或者非實時地同步到對端數據中心，對端數據可以提供近實時的數據服務；(3) DB層，通過數據庫軟件的集群的復制功能，把數據庫數據同步到對端數據中心數據庫軟件中，這個過程需要底層網絡時延的保障，具體的時延要求要根據應用系統的重要性和核心性進行設計。

3 基于國產CPU安全可控的軟件適配移植構建過程

3.1 安全可控的認知

數字化進程的飛速發展和近十年互聯網產業的發展都清晰地驗證了一個事實，不同的產業階段對IT基礎架構和計算能力提出不同的挑戰和要求。新應用、新技術、新架構是未來數字化轉型的關鍵，計算平臺的創新是數字化轉型的基石。

當前，信息安全、自主可控也已上升為國家戰略，自主可控計算機是構建自主可控信息系統的基礎。而芯片產業是計算機系統和整個信息產業的核心部件和基石，也是國家信息安全的最后一道屏障，芯片高度依賴進口使得整個國家安全受到嚴重威脅。

芯片的自主可控是整個信息產業自主可控的基礎，自主可控芯片將重塑ICT產業新格局，構建平行計算平面[7]。目前，我國服務器芯片自主研發有以下幾個方向[8]：

Alpha架構:代表有申威。

ARM(Advanced RISC Machine)架構：代表有華為、飛騰等。

MIPS架構：代表有龍芯。

X86架構：代表有海光、兆芯等。

Power架構：代表有中晟宏芯。

3.2 業務安全可控的適配流程

本文以華為ARM架構芯片鯤鵬920[9]為例來闡述特定的業務系統在進行安全可控的適配一般流程。流程如下：

Step1分析業務系統的軟件技術棧。

Step2確定如下指標信息：

1) x86架構的芯片/服務器；

2) 操作系統；

3) 操作系統相關驅動；

4) 編譯器；

5) JDK；

6) 軟件依賴組件；

7) 開源軟件；

8) 商用軟件；

9) 自研軟件。

Step3對于指標的前8項，獲取到支持ARM架構的軟件、硬件、相應的版本號，若沒有對應ARM版本，則考慮更換為相同功能的ARM對應版本軟件；對于指標9，執行以下代碼修改適配流程。

Step4判斷自研軟件的計算機編程語言類型，如果是編譯型語言(如C、C++等)，轉向Step 6；如果是解釋型語言(如Java和Python等)，則繼續下一步動作。

Step5判斷是否存在編譯型類庫的情況，如果不存在相關類庫，則可以直接使用；否則做類庫的移植后，重新打包，轉向Step 9。

Step6判斷是否為Linux軟件，如果不是Linux軟件，則可能面臨極大的代碼改動量，并且有移植不成功的風險；如果是Linux軟件，則繼續下一步動作。

Step7判斷是否存在x86的匯編代碼，如有，則統一替換成基于ARM的匯編代碼，繼續下一步動作。

Step8檢查是否存在代碼修改點，如有，則修改成基于ARM的版本；如沒有，則繼續下一步。

Step9重新編譯。

應用業務系統基于國產化CPU指令集的適配性遷移是一項比較復雜的工程[10]，以上是遷移適配的一般性流程，同時要考慮到遷移工作量和所用人時等因素開展此項工作。

4 核心模型的網絡規劃構建

云內部網絡訪問是一個比較復雜的過程，涉及到安全防護和業務流量的設計，因此需要一個通用的網絡模型來規劃，防止出現業務網絡的規劃導致內部網絡安全防護性較差。根據本文引出的云化業務模型，構建的統一網絡模型如圖5所示。

圖5 統一網絡模型

其中，主要網絡流向有以下幾個方向，在設計網絡中，需要重點考慮：

網絡流向1：VPC內部相同子網之間的二層訪問。通過安全組訪問，典型代表場景有Web集群服務之間的通信。

網絡流向2：VPC內部不同子網之間的三層訪問。典型代表場景有Web集群服務與應用各類邏輯之間的通信。

網絡流向3：不同VPC之間的三層訪問，通過VFW虛擬防火墻訪問，典型代表場景有Web集群服務或者應用各類邏輯與DB集群服務之間的通信。

網絡流向4：虛擬機與物理設備之間的三層訪問。也屬于跨VPC之間的通信，通過VFW虛擬防火墻訪問，典型代表場景有Web集群服務或者應用各類邏輯與第三方硬件或者軟件集群服務如認證網關等之間的通信。

網絡流向5：VPC虛擬機與第三方資源池之間的三層或者二層跨DC訪問。在三層場景下，通過接入路由器接入到云資源池，對于有Vlan網絡，配置明細路由；對于VXlan網絡，通過VPN的方式進入云網絡隧道，完成網絡路由的互通；在二層場景下，通過接入或者核心交換機，配置VXlan隧道，實現與VPC的二層互通通信。

網絡流向6：外部網絡的訪問。外部的訪問一般在業務平面較多，出口與云最外側防火墻互聯，實現外部網絡與云的業務VPC之間的訪問。

網絡流向7：專網網絡的訪問。專網部分一般分為業務流量和管理流量，在網絡對接上與云的專網網絡接入交換機對接，實現專網網絡流量的互通，管理流量經由管理交換機實現對接。

5 云化實例分析

5.1 現狀描述和分析

某業務系統15臺x86架構的物理機部署(Web和應用層、DB層3層架構)，CPU使用率長期持續在5%以下，內存使用率長期持續在10%以下，服務器操作系統為Linux Enterprise 6.4 64 bit，中間件為weblogic，開發語言為Java、Python，數據庫是MySQL。在業務訪問方面：每年特定時間段會出現業務訪問的高峰，并發峰值每秒約在4 000新建連接，業務訪問中有附件(標準圖片)的上傳和下載。

在業務出現訪問高峰時，系統經常性出現癱瘓等，頁面響應非常緩慢，響應時間在8～10 s左右。通過持續觀察可以發現，某幾臺服務器CPU和內存使用率在98%以上，歷史上多次臨時擴容服務器，但是未能解決該業務訪問問題。

故障出現時，某幾臺服務器的資源使用率出現較高情況，其他的大部分服務器使用率在較低水平，未出現其他異常情況。排除網絡攻擊后，可以初步得出結論：此系統整體架構設計不合理，使得某個或者某幾個流程成為整個業務系統的瓶頸，可以調整軟件部署架構來消除瓶頸。同時考慮國產化相關技術要求，重新設計云化軟件部署架構。

5.2 技術評估和云化架構設計

根據對業務系統的分析，本實例業務具備以下特點：

(1) 標準x86架構。

(2) 無特殊綁定硬件。

(3) 實時性要求不是特別高。

(4) 業務不同時段負載波動特別大。

(5) 業務增長不確定較高。

(6) 沒有大型分布式數據庫。

(7) 沒有小型機應用。

(8) 開發語言、中間件、數據庫、操作系統評估可以遷移。

根據本文前幾部分的評估論述，本業務系統適合部分云化，具備國產化適配的條件。

設計整體架構如圖6所示。

圖6 業務總體架構

架構具體描述：

注：整體流量防護請參考2.2節核心模型的設計Type3網絡模型。以下僅描述本實例相關部分。

Web層：采用全虛擬化部署方案，設立VPC1，在內部劃分兩個獨立子網，完成兩個前臺無狀態業務界面的資源承載，前端掛載軟件負載均衡服務，實現對訪問2個邏輯的七層負載分擔。同時設計自動彈性擴展服務，當節點出現CPU高于60%或者內存高于60%的時候會通過虛擬機鏡像自動拉起一定數量的虛擬機提供服務。

應用層：采用全虛擬化部署方案，設立VPC2，在內部劃分三個獨立子網，分別完成身份認證、接口和交換三個業務的資源承載，前端掛載軟件負載均衡服務，實現對訪問3個邏輯的七層負載分擔。同時設計自動彈性擴展服務，當節點出現CPU高于60%或者內存高于60%的時候會通過虛擬機鏡像自動拉起一定數量的虛擬機提供服務。

DB層：采用物理機部署方案，考慮到統一管理和運營資源，物理機采用BMS服務的資源納管方式。同時設立VPC3，在內部劃分獨立子網。數據庫物理機采用軟件集群的方式部署，對外提供virtual-ip負載分擔和保證讀、寫一致性。也可以采用獨立物理機部署方案，以專線VPN的方式接入到與云平臺Vxlan網絡，實現與云的overlay3層路由網絡通信。

5.3 國產化適配設計

根據國產化適配流程和原則，進行以下適配和遷移：

開發語言：Java和Python類應用系統參考本文論述的兩種語言的移植方法和流程。

中間件：由Weblogic適配為東方通中間件。

數據庫：由MySQL替換成Huawei GaussDB。

操作系統：由Linux Enterprise 6.4 64 bit適配為中標麒麟操作系統。

云平臺：適配國產云平臺。

服務器：由x86架構服務器適配成Huawei Taishan系列服務器。

5.4 改造效果

通過云化模型的技術評估和改造，確定物理服務器數量為3臺，進行虛擬化部署，考慮到20%的冗余資源量。云化后服務器減少比為80%。云化前服務器利用率5%，改造后資源利用率在60%左右，資源利用率提升55百分點。同時，投入成本降低80%以上。

國產化部分的性能對比有相關硬件廠商進行單點測試，本文只對資源層面進行對比測試。對所部署的環境進行整體壓力測試，按照經驗，壓力測試采用逐步提升到并發峰值為4 000每秒，觀測相關對應變化。

在具體的壓力測試實驗下，CPU資源均化使用率、彈性擴展與壓力測試數值的對應曲線如圖7所示。

圖7 資源均化使用率、彈性擴展與壓力測試數值對應曲線

5.5 效果分析和比對

目前業內OLTP業務在進行云化遷移的時候并沒有統一的方法和流程。大都是各個項目或者云平臺運營方根據關注點進行設計，關注點主要集中在遷移成本、資源使用量、業務的連續性，沒有對整體的架構和流程及SLA進行有效設計。

這種情況存在以下很多問題：(1) 業務和數據遷移過程不清晰，情況嚴重直接導致業務訪問中斷。(2) 資源評估不準確，過大導致成本上升，過小導致業務無法正常運行。(3) 云環境下業務架構沒有優化，只是物理環境的簡單復制，失去了使用云的很多優勢，也不能消除掉物理環境下的業務瓶頸。(4) 業務的架構沒有得到優化，導致云環境下業務細粒度的安全防護無法有效實施，出現安全緊急事件后無法快速有效地定位和阻斷。(5) 國產化的要求更是加大了業務遷移的時間復雜度和空間復雜度。

本文基于云計算框架提出的遷移評估模型和流程，以及針對國產化的適配作為一個整體體系是對OLTP業務云化遷移的技術性參考和流程的梳理，從改造效果看，能夠有效地解決暴露的問題。

6 結 語

當前政務OLTP業務系統在云化遷移過程中存在一系列問題，尤其是要滿足國家國產自主安全可控的安全要求。本文基于云計算框架對此類業務的云化遷移進行了模型分析和評估，得出了一般性指標的考量，提出了4種核心業務模型，并在此基礎上重點基于國產CPU核心指令集構建了安全可控的業務適配和遷移過程，形成了一套體系化云化遷移安全可控的評估模型。

經過實際業務的驗證與分析，4種核心模型、網絡流量模型及國產化適配流程有較高的應用性和有效性，在業務遷移過程中有較強的指導和借鑒意義。