容器和 Kubernetes 的發展成熟為應用的雲原生化提供最基礎的支撐，從而使企業最大化利用雲上的資源。儲存作為應用執行的基石，也在服務雲原生化的過程中不斷演進。
01
容器化應用 I/O 效能最佳化挑戰
Aliware
目前在雲上的容器化應用場景選擇儲存方案時，通常會使用塊儲存（EBS），檔案儲存（NAS，CPFS，DBFS）和物件儲存（OSS）三種，POSIX 語義的檔案系統是面向容器儲存使用場景最直觀和最友好的方式，通常也是容器場景下使用最多的儲存訪問方式。另一方面，為了實現叢集級別的儲存編排能力，K8s 在維護容器組（Pod）的生命週期中會將依賴的儲存卷以檔案系統的形式掛載到容器內，從而從應用角度可以無差別地讀寫塊儲存、檔案儲存和物件儲存的外接儲存。
現在，雲原生應用的規模化趨勢日益明顯，在大資料分析、AI 等資料密集型場景也得到越來越廣泛地應用，這些場景對 I/O 效能的要求很高。而現實情況是，雲上的檔案儲存和物件儲存一般都是以 TCP 和 HTTP（s）協議提供儲存服務，是典型的客戶端伺服器（CS）模式，傳統的服務端監控是透過發起者的 IP／連線來區分不同的應用，但在容器形式的部署中一個虛擬機器／物理機節點可以部署數十個到數百個容器，一個應用可以跨多個主機。因此，
傳統的服務端監控在現代的容器化部署中不能提供足夠的觀測粒度和維度來分析不同應用的 I/O 特性。
02
基於 ACK CNFS 儲存卷的 I/O 可觀測性框架
Aliware
為了幫助企業快速定位引發容器化應用 I/O 瓶頸的問題，保證業務持續穩定執行，阿里雲容器檔案儲存 ACK CNFS 提供了面向應用和叢集維度的 I/O 可觀測性框架， 包括 POSIX 細粒度操作可觀測性、容器組粒度的可觀測性、跨機多副本的應用級可觀測性，以及叢集維度針對檔案系統和物件儲存的聚合訪問特性等，幫助使用者構建統一的客戶端 I/O 效能問題監測和分析能力
01
什麼是 CNFS？
容器檔案儲存（CNFS）是對檔案儲存和物件儲存的生命週期管理邏輯抽象物件，透過提供 CNFS-OSSFS，CNFS-NAS，CNFS-CPFS，CPFS-DBFS 等儲存類（StorageClass）來實現對雲上 OSS Bucket，NAS FileSystem，CPFS，DBFS 的全生命週期管理和動態卷（PV）的增刪查改（CRUD）：
CNFS-OSSFS 今天已經被廣泛地使用在大資料，自動駕駛，生物計算領域，作為訪問 OSS 的主要手段。
CNFS-NAS 已經與彈性加速客戶端（Elastic Acceleration Client）深度整合，在 NFS 客戶端基礎上優化了多連線傳輸、支援了本地快取/分散式快取，預讀預寫功能加速檔案讀寫，目前已經在 CICD，機器學習，生物計算等領域廣泛使用。
CNFS-CPFSv2 作為低延遲，百萬級檔案訪問的高效能儲存，也已經在高效能計算，自動駕駛，生物計算等領域廣泛使用。
CPFS-DBFS 已經作為資料庫服務提供共享資料庫檔案儲存，有效降低了資料庫系統的多副本成本，目前已經在雲上資料庫領域 DBaaS 使用。
02
容器儲存卷 I/O 問題型別
本文會以物件儲存 OSS 訪問為例，透過 ACK 儲存卷 I/O 可觀測能力對應用內掛載的 I/O 特性分析、問題診斷和針對熱點應用/熱點資料分析、掛載失敗分析來解決如下四類問題：
定位容器內應用哪些 I/O 操作高造成的系統繁忙。
定位容器內應用元資料操作高造成的後臺系統繁忙。
定位容器內應用資料操作高的熱點檔案系統和熱點檔案路徑。
應用資料卷檔案系統掛載失敗分析。
03
儲存卷監控儀表板大盤
儲存卷的監控儀表板包含三個大盤：
Container Storage IO Monitoring (Cluster Level)
：容器儲存 I/O 監控（叢集維度）的大盤，TOPN Pod 的重要指標的統計。
Pod IO Monitoring (Pod Level)
：容器組 I/O 監控（容器組維度）的大盤，以 Pod 為過濾選項，儲存卷重要指標的統計。
OSS IO Monitoring (Cluster Level)
：物件儲存 I/O 監控（叢集維度）的大盤，以 OSS Bucket 為過濾選項，儲存重要指標的統計。
模擬使用者建立兩類有狀態服務：
oss-fio-read-sts，ReplicaSet：3 個，功能：使用 fio 命令讀取 OSS 儲存卷中預先寫好的 5G 大小的臨時檔案 5G。tmpfile， 模擬頻繁讀操作；
oss-fio-list-sts，ReplicaSet：1 個，功能：在 OSS 儲存卷中執行檔案的 list 遍歷操作， 模擬頻繁請求檔案元資訊操作；
接下來，我們如何從雲產品監控收到告警，並透過 ACK 的儲存卷定位出哪些是高 I/O 的 pod，哪些請求元資料導致後臺系統繁忙，如何找出熱點資料。
03
如何透過 ACK 儲存卷 I/O 可觀測能力定位應用維度的 I/O 問題
Aliware
01
問題一：哪些 I/O 操作頻繁會導致系統繁忙
1。 透過雲產品監控，建立內網流量告警規則並新增規則描述：
當 OSS Bucket 的內網流出流量大於 10Gbps/s 時，將觸發告警，告警名稱為“內網流出流量大於 10Gbps/s”。
2。 當 OSS Bucket 內網出流量大於 10Gbps/s 時，會收到監控告警，您可以透過以下操作定位當應用 Pod 的 PV 讀訪問請求高時，可能觸發服務側限流和不響應問題。
3。 檢視
Container Storage IO Monitoring (Cluster Level)
監控大盤，根據
TopN_Pod_IOPS(IO/s)
和
TopN_Pod_Throughput
面板的
read_rate
排序，找到高 I/O 和高吞吐的 Pod。
由示例可看出，名稱為 oss-fio-read-sts-1 的 Pod 產生了最多的讀 I/O 和讀吞吐。
4。 檢視
Pod IO Monitoring (Pod Level)
監控大盤，選擇 Pod 為
oss-fio-read-sts-1
，然後檢視
Throughput
和
POSIX Operation(count/s)
面板，找出導致高吞吐的 POSIX Operation，並定位資料卷。
由示例可看出，名稱為
oss-fio-read-sts-1
的 Pod 掛載的 oss-pv 資料卷產生了過多的 read 請求。
5。 在
叢集列表
頁面中，單擊目標叢集名稱，然後在左側導航欄中，選擇
工作負載 > 容器組
。
6。 在
容器組
頁面，
名稱
列下名為
oss-fio-read-sts-1
的 Pod 進入詳情頁面。在該頁面下獲取應用的映象資訊，根據以上獲取的高 I/O 和高吞吐資訊，根據該容器的標準輸出日誌來定位具體哪些具體業務操作導致了過高的 I/O 吞吐，從而決定業務側的邏輯改進最佳化 I/O 的訪問，重新構建映象替換。對於低優先的離線業務可以刪除該負載來暫時緩解吞吐壓力。
7。 根據以上示例分析，可以嘗試刪除流量較大的 oss-fio-read-sts 工作負載，來降低 OSS 內網出流量，再檢視Pod監控，流量降低，總體 OSS Bucket 吞吐降低，OSS 頻寬報警解除。
02
問題二：哪些元資料的操作頻繁會導致後臺系統繁忙
1。 透過雲產品監控，建立 HeadObject 的告警規則並新增規則描述：
當 OSS Bucket 的 HeadObject 請求達到 10000 次/分鐘時，將觸發告警，告警名稱為“OSS Head 請求大於 10000 次/min”。
2。 當 HeadObject 請求大於 10000 次/分鐘時，收到監控告警，您可以透過以下操作定位當 Bucket 元資料讀訪問請求過高時，可能觸發服務側限流和不響應問題。
3。 檢視
OSS IO Monitoring (Cluster Level)
監控大盤，選擇對應的
Bucket
，檢視
Aggregated Operation of OSS Operation (count/s)
面板中的 HeadObject 請求數。
由示例可看出，Bucket 名稱為
oss--2
產生了大量的
HeadObject
請求。
4。 檢視
Container Storage IO Monitoring (Cluster Level)
監控大盤，根據
TopN_Pod_Head_OSS_Operation
面板的
counter
排序，找到
HeadObject
請求數過多的 Pod，根據
TopN_PV_Head_OSS_Operation
面板，找到 HeadObject 請求最多的儲存卷。
由示例可看出：名稱為
oss-fio-list_sts-0
的 Pod 產生的
HeadObject
請求數最多而且在 5 分鐘內 I/O 速率最高；名稱為
oss-pv
的資料卷產生的
HeadObject
請求數最多且 5 分鐘內 I/O 速率最高。
5。 檢視
Pod IO Monitoring (Pod Level)
監控大盤，選擇 Pod 為
oss-fio-list_sts-0
，檢視
OSS Object Operation Ration(count/s)
面板中 Pod 的 I/O 情況。
6。 在
叢集列表
頁面中，單擊目標叢集名稱，然後在左側導航欄中，選擇
工作負載 > 容器組
。
7。 在
容器組
頁面，根據以上示例分析，單擊
名稱
列下名為
oss-fio-list_sts-0
的 Pod 進入詳情頁面。在該頁面下獲取應用的映象資訊，根據以上獲取的
HeadObject
請求數和 I/O 情況，根據該容器的標準輸出日誌來定位具體哪些具體業務操作導致了過高的 I/O 吞吐，從而決定業務側的邏輯改進最佳化 I/O 的訪問，重新構建映象替換。對於低優先的離線業務可以刪除該負載來暫時緩解吞吐壓力。針對次例子，修改應用邏輯避免對根目錄做遞迴的目錄遍歷 e。g。 ‘ls -hlR’；‘grep -r’，對指定目錄和更準確目錄執行遍歷和搜尋操作，來降低對元資料的遍歷操作。
8。 根據以上示例分析，可以嘗試修改成進入到最深的目錄執行 ls 操作，再檢視 Pod 監控，HeadObject 每秒的請求量下降：
03
問題三：有哪些資料操作頻繁的熱點檔案系統呵熱點檔案路徑？
1。 檢視
OSS IO Monitoring (Cluster Level)
監控大盤。獲取 OSS 的 Bucket 中頻繁訪問的檔案和檔案路徑。透過對 counter 和 rate 倒排序定位到熱點目錄和熱點檔案。
由示例可看出，Bucket 中頻繁讀取的檔案是
/fio-data/read/5G.tmpfile
，訪問的路徑為
/fio-data/read
。
2。 檢視
Container Storage IO Monitoring (Cluster Level)
監控大盤，根據
TopN_Pod_Read_Path
面板的
counter
排序，找到有問題的 Pod。
由示例可看出，存在問題的 Pod 是
oss-fio-read-sts-0
。
3。 檢視
Pod IO Monitoring (Pod Level)
監控大盤，選擇 Pod 為
oss-fio-read-sts-0
，根據
HotSpot Path of Top Read Operation
面板的
counter
和
rate
倒排序，找到 Pod 中頻繁訪問的檔案和檔案路徑。
由示例可看出，Pod 中頻繁讀取的檔案
/fio-data/read/5G.tmpfile
，訪問的路徑為
/fio-data/read
。
4。 根據以上示例分析，透過開啟 OSSFS Cache 來實現單機的快取命中，參考文末文件。也可以開啟分散式快取 Fluid 快取熱點資料，來解決頻繁讀取熱點資料問題。
04
掛載失敗事件透出
系統檢測到檔案系統掛載失敗並透出事件，事件中心傳送報警事件通知使用者 “檔案系統掛載失敗”，使用者點選連結定位到問題 Pod 的掛載失敗事件的詳細內容。
在本示例中，名稱為 default 名稱空間下的 oss-fio-read-sts1-0 掛載資料卷失敗。
失敗原因：掛載 OSS 時未找到相應的 Secret。透過修復 secret，設定正確的子賬號的 AK／SK，掛載卷恢復正常，報警解除。
04
小結
Aliware
綜上所述，在企業生產環境下 Pod 數量多、規模大，環境複雜場景下，透過阿里雲容器服務 ACK 的儲存卷的 I/O 可觀測性可以幫助客戶快速、準確地定位是哪個 Pod、哪個應用佔用了過多頻寬，元資料請求和資料請求資源，幫助客戶透過最佳化策略、修改應用等方式解決 I/O 效能問題，提升業務執行效率。歡迎點選閱讀原文了解產品更多詳情，並開通體驗。
