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