摘要：本文分享了華為雲Stack IaaS的設計思考與實踐，基于公有雲先進的架構技術和創新能力，采用重構改造+積木式搭配+抽屜式替換等方式，健康的、可持續的為客戶不斷的提供産品和服務。
本文分享自華為雲社群《【華為雲Stack】【大架光臨】第4期：IaaS首席架構師的架構設計思考與實踐》，作者：華為雲Stack基礎服務首席架構師 申思。
IaaS架構設計的思考
雲計算基礎設施即服務（IaaS）通常包括兩個内涵，一是提供計算、網絡、存儲資源的按需付費的使用模式，這種創新是将實體世界中被廣泛采用的共享使用及租用模式引入了IT領域，通過資源集約來提升效率并降低整體成本。但是我們也看到，仍然有相當數量的政企客戶，由于在自身IT長期發展的過程中，存在大量包括裝置機房、IT職員、傳統應用、固有組織流程、合規要求等因素，客戶的IT改造并采用新模式，将會是一個逐漸并且長期的過程。
IaaS的第二個内涵，是以虛拟化技術和分布式系統為主的新技術的更新，包括虛拟機、容器、采用SDN技術的網絡自動化、分布式存儲，以及管控系統的分布式化擴充等技術，提供統一的管理排程和資源靈活高效使用的能力。這一系列技術的更新并不是颠覆式的革命，而是IT技術發展過程的自然進化，需要不斷的疊代演進到成熟。廠商持續打磨産品的同時，客戶也需要結合自身的業務訴求和技術發展階段，對新技術的使用做出合理的規劃。
認識到不同政企客戶對IaaS的使用模式和技術發展，客觀存在自身特點和發展階段的差異性，是更好的幫助客戶成功實施雲化轉型的前提，也是華為面向政企雲場景基礎設施服務的一系列技術規劃和設計的出發點。
IaaS産品的參考架構，包含雲平台的計算控制、網絡控制、存儲控制部分，以及營運運維、安全災備、産品化等子系統，基于該參考架構，不同IaaS廠商提供了各自系統實作的産品執行個體。和主要以服務目錄提供産品的方式有所不同，線下政企雲場景，邊界會延伸到客戶的組織流程、管理制度、人員技能、存量資産、安全合規、發展規劃等各個方面，覆寫建雲、上雲、用雲、管雲4個階段，因而對廠商所提供的IaaS技術架構提出了更多的要求。
圖1 政企場景IAAS架構及外延
如圖1所示，政企場景下外延擴充所産生的對IaaS産品的需求，使得IaaS産品面臨着和其他軟體産品類似的挑戰 —— 如何識别客戶普遍合理的需求，在滿足客戶的同時，做到避免軟體複雜性漫延所導緻的成本不可控風險，進而可以健康的、可持續的為客戶不斷的提供産品和服務。
這是一個非常大的挑戰，時至今日，即使華為雲在國内政企市場佔有率已經數年蟬聯第一，也仍然在堅持不斷的探索和改進。實踐證明，這并非是不可完成的任務。政企雲場景的IaaS産品，完全可以做到以基線化的版本形态來傳遞客戶。一方面，基礎設施雲化的剛需強烈，處于快速上升趨勢，越來越多的客戶在逐漸了解和接受在這個轉型更新過程中，所存在的風險，願意和我們的咨詢、産品規劃、解決方案，研發以及傳遞服務團隊一起，從需求合理性分析、規劃、節奏控制到工程實施各個階段協同合作，共同保障項目的成功；另一方面，在産品研發過程中，也要充分考慮滿足客戶場景和産品能夠持續演進這兩者的辯證關系，并腳踏實地的付諸實施，進而規避産品的分裂和碎片化。
華為雲Stack基礎設施服務的産品設計，基于公有雲先進的架構技術和創新能力，采用了重構改造+積木式搭配+抽屜式替換等一些典型架構設計理念相結合的方式，繼承式的疊代改良産品能力來滿足政企客戶場景。
- 重構改造：會侵入原有系統，但具備複用效率上的優勢，适用于邏輯重疊且相對确定性的特性；
- 積木式搭配：與原有系統以接口方式松耦合內建，适用于邏輯相對獨立的特性能力；
- 抽屜式替：換要求系統提供基于模型抽象的架構能力來組合差異化能力，可用于需要差異化靈活适配的場景。
下面我們結合幾個具體例子，分享一些華為雲Stack基礎設施服務從場景分析到設計實作過程中的思考與實踐。
IaaS架構設計實踐
存量異構網絡的內建網關
雲内的網絡自動化設計，通常面向的是雲内資源，通過關聯雲内資源的生命周期管理子產品，實作網絡的自動化配置，雲和外部的連接配接通常以存在Internet或專線接入為前提。政企客戶由于多年IT基礎設施的發展，積累了大量存量或異構資源，包括實體機、虛拟化、多種Appliance裝置等，這些資源和雲之間的連接配接，往往是同機房或近機房的短距離部署，不依賴Internet或專線，客戶需要的是一種高效的二三層直連網絡，幫助客戶的應用快速上雲和互通。
存量異構網絡的內建網關正式面向這種場景的設計，考慮到VNF的帶寬限制及成本，選擇以單組800Gbps吞吐量*N組的硬體交換機來實作中轉，可以低成本連接配接雲内VPC網絡并提供L2/L3互聯能力，形成雲内雲外的一張網。
圖2 內建網關架構設計
如圖2所示，雲内VPC網絡控制器将虛拟機/裸機資源的虛拟網絡位置資訊，通過路由轉換子產品，轉換為EVPN路由，通過消息機制通知內建網關的路由控制子產品，配置到內建網關交換機，最後內建網關交換機根據路由資訊，配置相應的雲内VPC資源的ARP、MAC政策，以及到雲内實體主機的隧道政策。
在這個設計中，雲内控制器部分做了部分代碼重構，新增了路由轉換子產品和雲内VPC資源資料實施對接，同時新增了兩個裝置管理子產品及路由控制子產品，和雲平台松耦合內建，可獨立部署運作，通過積木式搭配滿足該場景下的客戶要求。
雲主機同城主備容災
政企關鍵應用在生産中心發生災難時，需要能夠在災備中心快速恢複業務，另外日常維護的計劃内停機，也往往會通過災備中心過渡，在原生産中心完成計劃性活動後将業務切回。雲主機容災服務即是針對這種場景的解決方案，和基于應用層的容災方案所不同，雲主機容災服務提供了基于IaaS層可以無需上層應用感覺或改造的主備容災能力。客戶也可以基于該能力，結合應用層容災或應用雙活的設計，來滿足自身的需要。
圖3 華為雲Stack 同城雙AZ容災設計
這裡以同城雙AZ場景為例，如圖3所示，當AZ1發生災害，或需要做計劃性維護時，管理者可以通過雲主機容災服務，将保護組内的業務通過自動或手工的方式在AZ2恢複。這個過程可以做到資料不丢失，業務恢複時間最小可達10分鐘。
這是一個複雜的系統級解決方案，架構設計思想如圖所示，采用一種分層解耦積木式搭建的思路：
- 存儲層：研發HyperMetro特性實作資料在生産中心到災備中心的實時同步，并相上提供雙活LUN的接口能力，可以被上層系統松耦合內建。作為存儲雙活的原子能力，可用于傳統IT的使用場景、雲場景下計算多路徑通路的高可用場景，也可以用于雲主機容災場景，由容災服務調用進行雙活LUN的配置和切換。
- 計算層：提供主備虛拟機的中繼資料擷取和配置的原子接口，并提供災備中心建立占位虛拟機的能力。容災服務通過建立生産和容災站點虛拟機之間的中繼資料映射關系，以保護組模型來管理，當需要進行故障切換時，可調用計算層接口進行容災虛拟機的啟動切換終止操作。
- 網絡層：無論是否需要容災特性，通用的多站點部署環境下，集中式形态的網元首先要解決自身的高可用能力，應對鍊路故障、網元叢集故障、裝置故障甚至控制軟體問題等多種故障場景，而容災隻是其中一種整體AZ級别的故障模式。通過多叢集備援、鍊路備援，裝置探測、中繼資料同步、路由切換等多種手段的結合，首先設計了通用的多站點部署高可用能力，而後提供給容災服務，來解決雙AZ容災的網絡切換問題。
- 管控層：管控面服務自身的設計和網絡類似，首先設計通用的站點内分布式叢集備援的高可用以及多站點部署環境下的高可用能力，解決管控面服務自身的故障切換問題，而後隻需要暴露原子切換能力給容災服務，針對站點故障時做容災切換的操作。
可以看出，以上各層提供的是應對通用故障場景下自身的高可用原子能力，并且互相之間不形成依賴耦合關系。而容災服務設計為一個獨立解耦的子產品，內建各層的能力，内聚編排、政策、演練、任務流程，并最終提供面向管理者的容災服務化體驗。
雲平台內建3rd塊存儲
客戶由于自身的采購政策或業務連續性等種種因素的考慮，會存在軟硬體分層的訴求。從雲平台軟體的角度，一定程度的南向開放能力，也是作為軟體平台的開放架構下的競争要求，可以促進市場生态的繁榮。
同一廠商對自身同構裝置的內建，由于研發組織協作緊密、特性路标規劃明确、版本配套互鎖，短路徑內建性能更優等一系列原因，通常會忽略對良好的開放性和能力差異化的設計考慮。下圖以雲平台內建某3rd塊存儲的實踐為例，分享一些雲平台在南向開放內建時的設計思路。
圖4 第三方存儲內建設計
如圖4所示，對南向裝置的內建，包括管理運維、服務控制、及資料面內建幾個層次。資料面的內建，包括存儲、伺服器及網絡裝置在内，采用成熟标準的協定來對接。管理運維通常直接采用裝置廠商的自帶系統，對于管理運維協定标準化成熟度較高的裝置，也可以考慮內建到統一管理運維平台來提升體驗。
控制面的內建，是設計複雜性的集中展現。一是裝置的控制方式鮮有一緻的标準，接口文法和語義各有不同，如果不做統一設計，逐款對接會導緻管控面的處理邏輯代碼互相耦合，難以維護；二是裝置的能力、規格和性能參差不齊，多種組合會引起代碼分叉嚴重，開發和交叉測試代價居高不下。
我們采用部分重構結合抽屜式替換的思路來緩解這個問題，模型部分抽象出存儲服務等級描述如性能、容量、保護能力等，來簡化屏蔽細節差異的代價；通用的南向架構提供以Driver機制接入的方式來內建多種不同類型的南向裝置，減少對主體控制流程的侵入；自動配置重構優化針對裝置能力差異如快照、復原、複制、動态調整等特性做自動識别進而減少代碼級别的耦合。進一步更靈活更解耦的優化改造也正在設計和實踐中，包括徹底的二進制級的部署解耦，運維邊界劃分的設計，以及面向3rd裝置廠商的開放的自動化內建測試驗證流程的工具集等。
跨平台雲主機遷移
IaaS技術的發展會存在一些跨代的階梯式演進，如虛拟化引擎從XEN到KVM、經典VLAN網絡到隧道網絡，單體平台架構到分布式平台架構等等。在提供更先進的技術生産力的同時，也要盡量避免對客戶的已上線業務造成影響。新平台通過解耦的管理系統納管舊平台來水準演進，并提供平台間的網路互聯服務，是一種比較穩妥的解決方案。而對于一些客戶，也希望能夠提供業務的遷移能力，高效的把舊平台上的存量業務便捷的遷移到新平台。
通用的遷移方式，是提供和雲平台不相關的遷移工具，基于計算資源内的代理子產品做資料同步和資源重建。這種方式的适用範圍更廣，但也存在着較為低效的問題，同時由于和雲平台能力互不關聯，資料模型的重建無法借助雲平台提供，在遷移體驗上會有損失。
基于這個考慮，在滿足一定條件的前提下，我們針對部分高優先的場景，做了一些嘗試和實踐，可以基于存儲資料不搬遷的方式重建計算資源，消減資料拷貝帶來的影響，同時利用和雲平台的配合，提升配置同步的自動化體驗。
圖5 跨平台雲主機遷移設計
這個設計是獨立解耦的積木式搭配思路，對雲平台不做任何侵入式改造。基于獨立的遷移服務子產品，以松耦合北向API對接平台的方式，可以形成和雲平台無關的可獨立演進的服務，既不受平台版本的内部疊代變化和研發進度限制，又具備了可以持續累加能力的演進性。在目前實踐的限定使用場景之上，未來也可以不斷擴充到更多的平台形态，更多的服務特性如遷移、排程、網絡互連，配置同步等，以及更廣泛的多雲跨雲場景下的混合控制能力。
以上列舉的幾點，是華為雲Stack基礎設施服務和政企客戶共同探索過程中沉澱下來的場景化産品能力，在衆多客戶的實際生産環境中發揮着良好的效果。同時我們也實踐了軟體架構設計中的一些典型思路，通過局部改造結合解耦分層設計的實踐，有效避免了由于碎片化發散帶來的産品不可持續演進的風險。
由于篇幅有限，更多的場景化能力和設計思考，會在後續的分享中提供。政企雲基礎設施服務更新的過程，道阻且長，行則将至，我們始終會和客戶一起，共同努力，貢獻我們的力量。
點選關注，第一時間了解華為雲新鮮技術~