解析OpenShift的存储规划
上一篇分享了：PaaS中OpenShift持久化存儲的管理實踐和 解密OpenShift內部通信網絡
本篇繼續分享OpenShift的存儲規劃
1
? ?
OpenShift 使用存儲類型選擇
選擇合適的存儲有助于最大限度地減少所有資源的存儲使用。通過優化存儲, 管理員幫助確保現有存儲資源以高效的方式工作。在 OpenShift 上可用的存儲類型如下表 2-10 所示：
表 2-10 存儲類型
存儲類型 | 描述 | 示例 |
塊存儲 | 1.在操作系統中顯示為塊設備。 2.適用于可以完全繞過文件系統在底層塊讀寫的應用 3.也稱為存儲區域網絡 (SAN)。 4. 不可共享, 這意味著一次只能有一個客戶端可以裝載此類型的一個塊。 | Ceph RBD，OpenStack Cinder， AWS EBS， Azure Disk，GCE persistent disk和 VMware vSphere |
文件系統存儲 | 1.在操作系統中顯示為文件系統 2.也稱為網絡連接存儲 (NAS)。 3.并發性、延遲、文件鎖定機制和其他功能在協議、實現、供應商和擴展之間差別很大。 | Linux NFS，NetApp NFS， Azure File，Vendor NFS，AWS EFS |
對象存儲 | 1.通過REST API端點訪問。 2.應用程序必須將其驅動程序構建到應用程序和容器中。 3.鏡像倉庫支持使用對象存儲。 | Ceph Object Storage (RADOS Gateway)，OpenStack Swift，Aliyun OSS，AWS S3，Google Cloud Storage，Azure Blob Storage |
上表按目前存在的三種存儲類型整理了 OpenShift 支持的存儲，主要是幫助讀者理清三種存儲的區別和分類，可以根據不同的需求選擇合適類型的存儲。除了公有云存儲外，OpenShift 在私有云可以使用的主流的存儲包括 NAS、Ceph 以及基于 Linux 實現的 NFS。我們基于不同維度對這幾類存儲做個對比，如下表 2-11 所示：
表 2-11 OpenShift 常用后端存儲對比表
對比項 | 企業NAS (NFS協議) | OCS | 基于Linux的NFS |
PaaS平臺容器數據持久化的支持 | 支持 | 支持 | 支持 |
客戶端同時讀寫 | 支持同時讀寫 | CephFS支持客戶端同時讀寫 | 支持同時讀寫 |
服務端同時讀寫 | 支持同時讀寫 | 支持同時讀寫 | 不支持同時讀寫，有性能瓶頸 |
創建與掛載 | 手動創建，自動掛載 | 支持自動創建，自動掛載 | 手動創建，自動掛載 |
讀寫性能 | 高，主要取決于NAS性能 | 高 | 一般，主要取決于NFS使用的磁盤性能 |
服務器投資 | 相對較高，取決于NAS廠商和類型 | 一般，使用X86 Server建設集群 | 低，使用兩臺X86 Server建設 |
擴展能力 | 一般，取決于NAS本身對于可擴展的實現 | 高，可以動態增加或縮減數據存儲池和節點 | 一般，可以動態增加或縮減數據存儲池 |
安裝和管理 | 安裝簡單、維護簡單 | 安裝簡單、維護復雜 | 安裝簡單、維護簡單 |
服務端故障恢復 | 當節點、硬件、磁盤、網絡故障時，系統能自動處理，無須管理員介入 | 當節點、硬件、磁盤、網絡故障時，系統能自動處理，無須管理員介入 | 底層存儲的高可用依賴于存儲硬件的高可用 |
客戶端故障恢復 | OpenShift平臺會自動調度到其它可用節點并完成掛載 | OCS管理平面通過OpenShift實現高可用，外置Ceph集群的高可用通過自身的架構設計實現。 | OpenShift平臺會自動調度到其它可用節點并完成掛載 |
如上表所示，基于 Linux 的 NFS 方案生產不推薦，因為數據高可用難保證，且有性能瓶頸；企業 NAS 看似是最好的選擇，但是也存在成本較高，擴展難等問題。而 OCS 由于與 OpenShift 完美集成，并且支持外置 Ceph 的模式，因此會越來越成為 OpenShift 持久化存儲的理想選擇。
2
? ?
OpenShift 存儲容量規劃
OpenShift 存儲容量規劃包括 OpenShift 節點、OpenShift 附加組件、OpenShift 上運行的應用，由于 OpenShift 上運行的應用沒有通用的存儲容量規劃方法，需要根據具體的業務需求規劃，這里我們就不再討論。下面我們將分別說明 OpenShift 節點和 OpenShift 附加組件這兩部分的存儲容量進行規劃。
OpenShift 節點所需要的存儲主要是節點文件系統上一些特殊的目錄，通常消費本地存儲。
2.1
? ?
Etcd 數據存儲
Etcd 用于保存 OpenShift 所有的元數據和資源對象，官方建議將 Master 和 Etcd 部署在相同的節點，也就是 Etcd 數據保存在 Master 節點的本地磁盤，默認在/var/lib/etcd/目錄下，該目錄最小需要 20 GB 大小的存儲。
2.2
? ?
Docker/CRI-O 本地存儲
Docker/CRI-O 作為容器運行時，在每個節點都會運行，在運行過程中會保存鏡像到本地以及為容器運行分配根空間都需要消耗本地磁盤，官方建議在生產環境中專門為運行時配置一塊裸磁盤。這部分存儲的大小取決于容器工作負載、容器的數量、正在運行的容器的大小以及容器的存儲要求，通常建議配置 100G 甚至更大。另外，建議最好定期清理本地無用的鏡像和容器，一方面是為了釋放磁盤空間，一方面是為了提升運行時性能。
2.3
? ?
OpenShift 節點本地日志存儲
OpenShift 節點運行的進程的日志默認存放在/var/log 目錄下，該目錄最小需要 15G。
除了這三個對于 OpenShift 相對關鍵的目錄之外，其余操作系統分區規劃遵循企業操作系統安裝規范即可。在清楚了 OpenShift 節點存儲規劃之后，下面我們看看 OpenShift 附加組件的存儲規劃。OpenShift 包含一些附件組件是需要掛載持久存儲的，如鏡像倉庫、日志存儲等，這部分存儲是掛載到容器中消費，通常使用的是非本地存儲。主要包含如下幾部分：
鏡像倉庫
鏡像倉庫可以選擇的存儲類型有塊存儲、文件系統存儲、對象存儲，我們推薦優先使用對象存儲，其次是文件系統存儲，最后才是塊存儲。如果選擇塊存儲就只能一個實例讀寫，不利于鏡像倉庫高可用的實現。
OpenShift 中的鏡像倉庫包括 OpenShift 內部鏡像倉庫和外部鏡像倉庫。內部鏡像主要用于存放在開發過程中生成的應用鏡像，存儲空間增長主要取決于構建生成應用的二進制文件的數量和大小；OpenShift 外部鏡像倉庫在開發測試環境用于存儲應用所需要的基礎鏡像，如 Tomcat 鏡像，存儲空間主要取決于保存的基礎鏡像的數量和大小，對于一個企業來說，基礎鏡像相對是固定的，存儲空間增長不會很大；在生產環境的鏡像倉庫存放用于發布生產的鏡像，存儲空間取決于保存應用鏡像大小和數量。
經過上述描述，可以發現，開發測試環境的內部鏡像倉庫的存儲空間增長是最快的，因為頻繁的構建，每天會產生大量的鏡像上傳到內部鏡像倉庫。我們可以根據每天構建應用的次數以及每次構建生成應用二進制的大小粗略估計出該倉庫所需要的存儲空間，計算公式如下：
內部鏡像倉庫存儲空間=平均每天構建應用的次數 平均應用二進制的平均大小 保留鏡像的天數 + 基礎鏡像總大小
其中，基礎鏡像總大小可以在開發測試環境的外部鏡像倉庫拿到這個數據，當然也可以給一個適當足夠大的值。
開發測試環境的外部倉庫存放基礎鏡像，相對固定，每個企業對該倉庫存儲空間的需求是不一樣的，按以往經驗來說，通常配置 100G 或 200G 是足夠的。
生產環境的鏡像倉庫可以通過平均每天發布應用的次數、平均鏡像大小以及保留的天數，計算公式：
生產鏡像倉庫存儲空間=平均每天發布應用的次數 平均鏡像大小 保留的天數
到此為止，所有的鏡像倉庫存儲容量就規劃完了，如果在使用過程中出現了存儲不足的情況，優先考慮清理無用鏡像釋放空間，如果確實無法釋放，再考慮擴容空間。
日志系統
日志系統默認使用容器化的 EFK 套件，唯一需要掛載存儲的是 ElasticSearch，可以選擇的存儲類型有塊存儲和文件系統存儲。出于性能上的考慮，推薦優先使用塊存儲，其次選擇文件系統存儲。如果使用文件系統存儲，則必須每個 ElasticSearch 實例分配一個卷。
ElasticSearch 存儲大小可以使用以下方法進行粗略估算：
統計應用輸出日志每行的平均字節數，如每行 256 bytes；統計每秒輸出的行數，如每秒輸出 10 行。那么一天一個 Pod 輸出的日志量為：
256 bytes 10 60 60 24 大約為 216MB
在根據運行的 Pod 數目計算出每天大約需要的日志存儲量，再根據需要保留的日志的天數計算出總日志存儲空間需求，建議多附加 20%的額外存儲量。
如在生產環境 200 個容器，24 小時積累日志 43G 左右。如果保留一周，則需要 300G 的存儲空間。
上述計算只是估算了保存一份日志的存儲空間，我們都知道 ElasticSearch 是通過副本機制實現數據的高可用的，這樣為高可用 ElasticSearch 規劃空間時還需要考慮副本數的影響，通常是根據一份日志的存儲空間直接乘以保留的副本數。
以上方法只是一個粗略估計，如果需要更為精確的估算，則最好在應用穩定上線之后，通過 ElasticSearch 每天增加的存儲空間推算每天的日志增長量。
OpenShift 監控系統
OpenShift 的監控系統使用 Prometheus 套件，需要掛載存儲的組件有 Prometheus、AlertManager。可以使用存儲類型都是塊存儲和文件系統存儲，推薦優先使用塊存儲，其次使用文件系統存儲。如果使用文件系統存儲最好經過測試后再使用。
OpenShift 中的 Prometheus 默認使用 Operator 部署，配置存儲需要配置動態存儲類或提前創建好可用的 PV。Prometheus 有兩個實例，AlerManager 有三個實例，總共需要 5 個 PV。
AlertManager 所需要的存儲空間較小，按經驗配置 40G 是足夠的。Prometheus 所需要的存儲與集群節點數、集群 Pod 數、保留數據天數（默認 15 天）等因素有關。官方在默認配置下，給出四組 Prometheus 測試數據供我們參考，如下表 2-12 所示：
表 2-12 Prometheus 存儲需求測試數據
節點數 | Pod總數 | Prometheus每天增長的存儲 | Prometheus每15天增長的存儲 |
50 | 1800 | 6.3GB | 94GB |
100 | 3600 | 13GB | 195GB |
150 | 5400 | 19GB | 283GB |
200 | 7200 | 25GB | 375GB |
根據上述測試數據，在默認配置下，Prometheus 在 15 天需要的存儲量基本與節點數和 Pod 數呈線性增長，我們根據這個比例估算我們需要的存儲量即可，同樣建議在計算時多附加了 20%的額外存儲量預防意外情況。
3
? ?
本文選自《OpenShift 在企業中的實踐》（第 2 版），經出版社授權發布。
推薦語：經典暢銷書再次升級！紅帽首席解決方案架構師聯合撰寫，20 位全球知名企業 IT 負責人推薦，基于 OpenShift v4，詳述 PaaS、DevOps、云原生、微服務治理。完整描繪企業數字化轉型路線，為企業通過 OpenShift 實現 IT 轉型給出具體建議和參考架構。
推薦閱讀
限流 & 熔斷的考量
2021-10-19
用企業架構下好數字化轉型這盤大棋
2021-10-25
技術架構的戰略和戰術原則
2021-10-25
2021 編程語言排行榜
2021-10-22
微服務等于Spring Cloud？了解微服務架構和框架
2021-10-21
一個電商供應鏈系統的DDD實戰
2021-10-20
解密OpenShift內部通信網絡
2021-10-29
“釘釘打卡神器”開發者被判五年半！
2021-10-28
菜鳥技術專家胡斌：技術架構的戰略和戰術原則
2021-10-27
從0開始搭建公司后臺技術棧，這套架構值得擁有...
2021-11-01
八個維度講解秒殺系統架構分析與實戰
2021-11-02
為什么國內 996 干不過國外的 955呢？
2021-11-01
總結
以上是生活随笔為你收集整理的解析OpenShift的存储规划的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python中list转csv的两种方法
- 下一篇： Object Detection中的IO