容器雲環境下如何設計儲存架構?
金融機構的“數字化、智慧化”戰略落地,多數金融機構啟用了全新的容器雲平臺,並花了大量時間和精力對關鍵業務進行了微服務改造,以適配雲平臺。透過對金融企業架構和熱點主流技術的研究和探索,淺談一些個人觀點。
一、技術選擇
新應用系統需要更加靈活快速上線,以客戶體驗為主要考量指標。私有云IaaS雲平臺,能夠靈活提供虛擬機器、容器服務。而基於虛擬機器或物理機的緊耦合架構,軟體版本的細微更新就會造成牽一髮而動全身的後果,一個新版本往往需要數月,甚至更長時間,這無法滿足業務快速迭代的需求。
容器技術是細粒度的虛擬化技術,比傳統虛擬化技術的資源利用率要高很多。容器技術的輕量化能給基礎架構帶來的另一好處,就是具備了靈活的擴充套件能力,具備了真正意義上的資源彈性,實現了快速自動的擴充套件和回收。也正是因為其輕量化的特徵,讓業務具備了雲內、雲間的按需流動。
圖1:虛擬化與容器對比
二、容器需要儲存
微服務改造中,目標業務系統需要首先實現無狀態改造,將有狀態的資料分離到儲存系統。讓業務真正實現了無狀態的全自動伸縮,而有狀態的資料將由分散式資料庫來承載。
金融級的容器平臺需要提供一致效能力、彈性伸縮能力、灰度釋出能力,和DevOps開發運維一體化以及微服務架構整合,以實現持續整合、監控、改進的最佳化迴圈。
容器平臺除了常規所需的計算、記憶體、網路資源外,儲存資源也是不可缺失的關鍵能力之一。儲存作為容器平臺基礎資源,保證容器雲資料安全和持久儲存。同時,容器對儲存服務種類除了標準的NFS掛載外,還需要物件儲存服務,主要用於容器映象儲存。當然塊儲存也常見用於容器的持久化儲存,如應用程式的日誌讀寫。
而基礎平臺除了能夠提供NFS、物件儲存服務外,還需要具備和雲協同服務的儲存能力,隨著容器的發放、執行、終止、回收進行生命週期的管理。為了保證資料的安全性和可用性,儲存平臺除了前面提到的和雲配套的能力之外,還需要具備金融級的安全性和可靠性,從而能夠完全滿足監管機構對業務連續性要求。
圖2:容器應用場景
在業務連續性方面,微服務架構通常的做法是透過應用層面來提供容災能力,但當前主流的分散式資料庫採用的MySQL和類MySQL資料庫系統,它的本地、同城、異地容災能力往往是我們規劃的一個難題。比如,本地的一主多備模式保障本地的可用性,同城部署第三副本,以binlog複製方式保障RPO。若考慮強一致性的業務場景,這種方式下的RPO不能滿足業務需求。
另外,微服務改造後的容災架構往往也存在不合理的地方。業務拆分得非常複雜,某些業務和其他業務的關聯關係耦合度還很高,這就造成了一些高容災需求的業務系統依賴於低容災需求的業務系統,這種不合理的現象在分散式改造專案中是一個通病。這需要一個嚴格的統一的業務連續性規劃來規避這種潛在風險。
圖3:容器儲存使用場景
圖4:微服務架構應用容災
基於以上考慮,個人認為可以透過引入企業級集中式儲存來解決一些問題。利用集中式儲存的低時延、高可靠性解決容器應用的高效能場景,利用集中式儲存的雙活方案解決業務連續性的痛點。
三、實施效果
我行在雲端計算、微服務等技術方面進行了探索、試驗及落地,經過多年的技術探索,積累了一些經驗。諸如渠道類業務系統、辦公類系統、信貸類系統等利用容器技術實現了落地。為未來的其他重要業務系統的容器化部署打下了堅實的基礎,積累了豐富的實施經驗。
如智慧櫃面實現微服務改造,145個服務實現容器化部署。渠道業務層提供基於Docker的容器化服務,透過在容器中執行介面服務對接ESB以及其他業務系統和模組。單中心使用資源約為1400C,3600G。經實際執行,目前單中心交易TPS約為1900左右,響應時間在50ms以下。整體執行穩定,滿足業務要求。
四、總結
微服務改造、容器雲是當前熱點,我們緊跟時代技術發展脈搏,透過新技術的使用來解決當前的一些挑戰,也希望透過新技術來驅動金融服務的創新,從而完成資料來源於業務、資料驅動業務創新的閉環,實現真正意義上的企業數字化轉型,讓金融機構更加智慧化、智慧化。
劉豔春 某金融公司架構師:
絕大多數容器生產業務,需要資料持久化,需要有狀態的容器服務,需要穩定、全方位支撐的資料儲存平臺才能保證業務安全穩定執行。
資料成為繼土地、勞動力、資本之後一種新的生產要素,成為提高生產效率,降低成本,增強企業發展韌性的關鍵,資料安全可靠、穩定執行在核心基礎設施之中才能產生價值, 因此資料儲存也正成為加速數字化轉型的堅實底座。
自2020年年初以來,一場突如其來的疫情,席捲了全球,改變著人類生活和工作模式。企業級儲存的IT基礎設施也隨之改變,如何滿足資料對儲存各種場景的需求,湧現出了很多儲存解決方案,如軟體定義分散式儲存、全快閃記憶體儲、雲端儲存、容器雲端儲存、大資料儲存、AI儲存、區塊鏈儲存、邊緣儲存、量子儲存等等。當前越來越多的企業正發揮以容器云為代表的數字技術的巨大潛力,最佳化運營能力,加速數字創新程式。容器平臺是以Kubernetes和Docker為技術基礎,為容器化應用提供從應用的建立、釋出、執行、擴容、迭代、銷燬的全生命週期的管理能力,整合適應雲場景下的網路服務、儲存服務、映象服務等特性。絕大多數容器生產業務,需要資料持久化,需要有狀態的容器服務,需有穩定、全方位支撐的資料儲存平臺,才能保證業務安全穩定執行。本文將簡述容器雲環境下如何設計儲存架構。
一、容器雲平臺的儲存需求
1. 數量大-大量儲存卷
容器使用者需要建立更多的儲存捲來支援儲存的虛擬化和池化。由於容器技術可以實現在單個主機上執行數百個容器,但這些容器加起來需要的儲存卷可能超過作業系統的限制,需有靈活應對突發需求,敏捷響應業務變化、動態分配以及多容器應用的並行訪問的儲存卷的儲存。
2. 活性-動態儲存排程
由於容器會不斷的建立,銷燬,並且在Node之間遷移。因此需有動態靈活排程,軟硬體解耦,易於擴充套件並且可以緊密地整合到容器編排框架中的儲存。在容器層可實現卷的動態建立,裸卷對映、快照、克隆、卷擴充套件等。
3. 差異化-持久化卷支援適應不同場景
不同的容器有狀態應用需求不同的資料儲存方式,塊儲存(RBD,iSCSI)、檔案儲存(NFS)、物件儲存(S3)。當節點異常時,Pod會被排程到其他節點,如果使用本地卷,新的Pod啟動後無法訪問原有資料,需要有支援持久化卷(Persistent Volume),Pod被排程後,依然可以訪問到之前的資料的儲存。同時也需要多應用同時訪問資料,多協議的支援,多容器型別的支援儲存平臺。
二、容器雲平臺的儲存架構設計
1. 容器儲存卷主要有如下方式
1) 伺服器本地儲存:固定在容器正在執行的主機上的儲存。
2) 傳統儲存裝置:由其他供應商提供的容器儲存驅動程式配置的SAN、NAS或超融合系統平臺。
3) 分散式檔案系統:由多個伺服器提供的統一名稱空間的共享檔案系統。
4) 容器原生儲存:一種軟體定義的容器化儲存系統,專門為容器化應用程式提供資料管理。
5) 雲塊儲存服務:IaaS平臺的塊儲存服務。
6) 雲檔案儲存服務:IaaS平臺的檔案儲存服務。
2. 有狀態資料儲存要求
1) 儲存卷生命週期單獨管理。儲存卷的生命週期和容器分開,可以建立儲存卷,然後再繫結到容器,容器刪除不會自動刪除儲存卷。
2) 提供對接檔案儲存,多個容器可以共享同一個儲存卷用於儲存資料。
3) 提供儲存快照和恢復能力。能夠對儲存卷做快照,或者透過快照恢復儲存卷資料。4) 提供對接本地儲存,可將本地檔案路徑掛載到容器內部。
5) 支援外掛擴充套件不同第三方儲存方案。可以透過外掛的方式對接不同的底層儲存方案。
3. 容器雲端儲存架構
軟體定義儲存能夠支援適用於容器的可動態建立的持久化儲存,可同時支援不同型別應用的儲存訪問需求。透過軟體將通用伺服器整合為統一儲存資源池,以軟體定義的方式提供塊、檔案、物件等不同資料儲存形態。在企業儲存管理上,大多資料中心儲存承載敏態穩態混合架構資料服務,需有一個統一儲存平臺管控。統一儲存平臺不但可以提供基於商用硬體的分散式儲存系統以及高效能高可靠性儲存,而且可以透過基於控制平面的軟體應用儲存控制器,同一套儲存系統為上層應用同時提供塊、檔案和物件三種資料服務,滿足業務對結構化、半結構化、非結構化資料的存放需求。實現對虛擬化環境中不同異構儲存的統一管理交付,將底層異構儲存資源抽象化,資料中心管理員可依據前端業務團隊所要求的特性以需求建立儲存服務,並將其自動配置給所需的應用程式伺服器。容器雲平臺儲存按容器雲架構分為五層架構,各層功能特性如下表:
表 1:容器雲端儲存功能架構
容器雲端儲存常用CSI (Container StorageInterface) 外掛對外開放的儲存介面來實現儲存服務。解耦了Kubernetes系統的計算層和儲存層。
統一性:無論是塊儲存還是檔案儲存,都可以透過CSI的方式去使用。
穩定性:CSI方案將儲存和計算兩種資源完全解耦,實現了資源的隔離,同時CSI外掛以容器化部署, 因此穩定性更進一步得到保障。
相容性:CSI外掛以容器化部署,不會受作業系統版本和儲存叢集的限制,消除環境差異所帶來的不確定性以及其他約束。
易運維:不需要複雜的叢集配置修改和準備工作,只需填好CSI容器配置,拉取映象,一鍵可達。
無縫升級:如果之前使用的RBD,iSCSI,NFS對接,儲存也提供完善可靠的無縫升級到CSI介面。
豐富的特性:不僅僅滿足客戶儲存的基本需求,在實際使用中,儲存提供的儲存外掛有很多非常重要和倍受青睞的高階特性,支援動態擴容,根據實際需求動態地擴容和縮容。除此之外,還會有Snapshots快照以及QoS管理等其他的特性,進一步完善容器生態。
高曉峰 無錫農商行 科技管理部系統管理團隊長:
對於中大型銀行是不可能憑藉一種儲存技術解決大部分平臺容器需求,因此各種型別儲存資源池成為了設計主角,需要根據其業務特性選擇合適的儲存架構落地方案。
一、業務與容器雲、與儲存的關係
引用《以業務為核心的雲原生體系建設》對架構劃分,總的來說銀行IT架構包含以下幾個方面:業務架構、技術架構、資料架構、研發流程和組織架構。
就業務架構而言,目前大部分銀行核心系統多是外採的(合作開發),或者由於業務穩定性等諸多因素考慮,處於單體架構的階段。部分非核心業務,採用了服務化的架構,構建了中臺體系。而網際網路化業務因為要應對高併發流量,以及應對市場的快速變化,已經將服務拆分得更加細,實現了微服務架構。
就技術架構而言,最初銀行多會使用採購物理機的方式執行業務程式碼,因為資源使用效率和靈活度的問題,很多銀行採用了虛擬化平臺。從虛擬化平臺到雲平臺的變化不在於技術,而在於使用模式,主要是三點,統一介面,抽象概念,租戶自助,說白了就是讓業務方不需要特別專業的底層技術能力,就能實現應用的部署,同時將運維人員從應對越來越多的業務方的噩夢中解放出來。容器進一步讓應用從程式碼到執行無縫的連線起來,並且可以實現跨雲的遷移。ServiceMesh將微服務的治理放到統一的平臺上來做,進一步解放業務方。
就資料架構而言,在業務執行的過程中,會積累很多的資料。最初銀行的系統大多隻做資料記錄的作用,並沒有發揮太多的價值,資料是散落在各個系統的資料庫之中的。如果想進行分析,檢視當前業務的執行情況,需要分析師將資料匯出來,做成表格和報告,給領導看,這樣時效性就會很差。後來很多銀行開始做資料的梳理,建設資料倉儲(資料倉儲或者資料湖),並且建設BI大屏,領導駕駛艙,支撐戰略決策。當然這種方式沒有辦法和業務直接結合,後期考慮資料運營驅動業務創新(或IT引領業務),也就是在電商和社交APP上的千人千面,智慧推薦等功能。
容器雲是一種技術手段,與虛擬化或物理機相比能更好的節能增效,並且與現階段微服務化應用更緊密結合。以Kubernetes為例,其對底層基礎架構進行抽象,池化了底層資源,將資源交付的時效性降低至分鐘級別。系統資源維護從原來的虛擬機器(物理機)交付,變成了資源擴容(Quota分配),減輕運維的工作量;同時,開發應用通用映象技術打包釋出,避免了環境變數不一致帶來的應用部署麻煩,將應用部署從天級縮減至小時級,甚至於分鐘級。
儲存既是技術架構的組成部分,也是支撐資料架構的重要基石,對於容器雲來說,儲存提供了儲存資源池的功能,業務根據各自的需求按需申請儲存資源,存放資料資訊。
二、業務需求與儲存需求
根據《中華人民共和國金融行業標準—金融資料安全資料安全分級指南》對金融行業的分類規則提供的參考表,其分為了四大類:客戶、業務、管理、監管。而這四大類資料又可以抽象為兩大類資料即結構化資料與非結構化資料。其中結構化資料主要表現形式為資料庫資料,資料記錄小以及隨機查詢的需要,讀寫硬碟的塊大小(Block size)一般都很小,這種小資料塊的讀寫,對於總頻寬要求不會很大,因此通常評定這類資料的效能指標為IOP;而非結構化的資料一般是比較大的檔案為主,讀寫塊大小會設定得比較大(64KB以上,甚至512KB或者1MB),而且單個檔案內部可以認為是連續讀寫的,因此對於這類資料的讀寫,更多以頻寬為其效能指標。因此對銀行應用資料來說,儲存既需要提供滿足於高IOPS的需求,也需要滿足高頻寬的需求。
目前主流的容器雲平臺都是基於Kubernetes,Kubernetes儲存資料主要有三類:
映象檔案
配置資訊
應用資料
而資料庫一般不執行於容器雲平臺中,因此對容器雲來說,儲存需要提供高頻寬、高IOPS的服務。
三、容器雲端儲存架構設計
Kubernetes作為一個主流的開源容器平臺,有很多主流的儲存是預設支援的,例如本地盤,Ceph,以及主流公有云平臺的塊儲存等。支援這些儲存的程式碼邏輯都是在Kubernetes程式碼中執行的,我們稱為In-Tree方式。但是Kubernetes作為私有云平臺進行部署,會有一些商業化的NAS、SAN以及物件儲存需要進行對接,這就要用到CSI介面。CSI全稱Container Storage Interface,主要目標是將任意儲存系統都可以透過標準的介面暴露給容器化的應用。
對於多數銀行業的企業,都有豐富的SAN和NAS的儲存管理及運維經驗,結合應用的儲存需求、平臺映象方案的設計,以及銀行業的應用系統普遍有多中心部署的監管需求,我認為比較合適採用NFS型別的儲存用於支援容器資料持久化以及映象服務的相關儲存需求來應對容器平臺在小型銀行企業的落地。
當然對於中大型銀行是不可能憑藉一種儲存技術解決大部分平臺容器需求的,因此各種型別儲存資源池成為了設計主角,需要根據其業務特性選擇合適的儲存架構落地方案。
結束語
綜上所述,對於容器雲來說,儲存提供了儲存資源池的功能。金融企業不可能憑藉一種儲存資源解決所有的容器需求,需要根據其業務特點選擇適合的儲存架構落地方案。
來自 “ twt社群 ”, 原文作者:twt社群;原文連結:https://mp.weixin.qq.com/s/J2X1M38sXiOj45N5OnmZwA,如有侵權,請聯絡管理員刪除。
相關文章
- 如何進行雲端儲存架構框架設計?架構框架
- 在 KubeSphere 中使用 Rook 構建雲原生儲存環境
- 京東智聯雲物件儲存高可用架構設計思考物件架構
- 容器雲多叢集環境下如何實踐 DevOpsdev
- 設計信創雲架構,如何處理傳統雲架構存與棄的問題?架構
- 雲上跑容器,如何降低儲存成本
- DAOS 分散式非同步物件儲存|架構設計分散式非同步物件架構
- 雲原生環境下的日誌採集、儲存、分析實踐
- 容器附加儲存(CAS)是雲原生儲存
- SpringCloud Alibaba實戰(3:儲存設計與基礎架構設計)SpringGCCloud架構
- Longhorn 雲原生分散式塊儲存解決方案設計架構和概念分散式架構
- Linux 環境下安裝 Nexus 私服儲存庫Linux
- 金融行業聯機交易業務場景下的儲存架構設計行業架構
- 在生產環境中,阿里雲如何構建高效能雲原生容器網路?(含 PPT 下載)阿里
- 容器雲平臺微服務架構設計的誤區微服務架構
- 王懷遠:阿里雲一站式物聯網儲存架構設計阿里架構
- 雲端計算儲存之Ceph架構是怎麼樣的?架構
- 【RocketMQ】RocketMQ儲存結構設計MQ
- SaaS架構:中央庫存系統架構設計架構
- Nebula 架構剖析系列(一)圖資料庫的儲存設計架構資料庫
- 雲原生儲存詳解:容器儲存與 K8s 儲存卷K8S
- redis服務環境下mysql如何實現lnmp架構快取RedisMySqlLNMP架構快取
- 容器化RDS—— 計算儲存分離 or 本地儲存
- 小紅書自研KV儲存架構如何實現萬億量級儲存與跨雲多活架構
- 如何檢視Docker容器環境變數,如何向容器傳遞環境變數Docker變數
- 交易日均千萬訂單的儲存架構設計與實踐架構
- 系統架構設計面試指南(02)-MQ和檔案儲存架構面試MQ
- 本地讀寫的多活資料儲存架構設計要義架構
- 生產環境中如何切換MySQL儲存引擎GAMySql儲存引擎
- 阿里雲 Faas 架構設計阿里架構
- 結構化資料儲存,如何設計才能滿足需求?
- 直播預約 | 在生產環境中,阿里雲如何構建高效能雲原生容器網路?阿里
- 分散式儲存在雲環境下的應用和部署分散式
- 容器環境下如何將NuGet包XML文件新增到SwaggerXMLSwagger
- docker容器儲存Docker
- docker(podman)容器設定中文環境Docker
- 淺析雲端儲存的TCS和LCA兩大架構架構
- J2EE分散式架構整合阿里雲OSS儲存分散式架構阿里