容器 I/O 性能診斷：到底哪個應用是帶寬殺手？
作者 | 王焦
?容器和 Kubernetes 的發展成熟為應用的云原生化提供最基礎的支撐，從而使企業最大化利用云上的資源。存儲作為應用運行的基石，也在服務云原生化的過程中不斷演進。
一、容器化應用 I/O 性能優化挑戰
?目前在云上的容器化應用場景選擇存儲方案時，通常會使用塊存儲（EBS），文件存儲（NAS，CPFS，DBFS）和對象存儲（OSS）三種，POSIX 語義的文件系統是面向容器存儲使用場景最直觀和最友好的方式，通常也是容器場景下使用最多的存儲訪問方式。另一方面，為了實現集群級別的存儲編排能力，K8s 在維護容器組（Pod）的生命周期中會將依賴的存儲卷以文件系統的形式掛載到容器內，從而從應用角度可以無差別地讀寫塊存儲、文件存儲和對象存儲的外置存儲。
現在，云原生應用的規模化趨勢日益明顯，在大數據分析、AI 等數據密集型場景也得到越來越廣泛地應用，這些場景對 I/O 性能的要求很高。而現實情況是，云上的文件存儲和對象存儲一般都是以 TCP 和 HTTP(s)協議提供存儲服務，是典型的客戶端服務器（CS）模式，傳統的服務端監控是通過發起者的 IP／連接來區分不同的應用，但在容器形式的部署中一個虛擬機／物理機節點可以部署數十個到數百個容器，一個應用可以跨多個主機。因此，傳統的服務端監控在現代的容器化部署中不能提供足夠的觀測粒度和維度來分析不同應用的 I/O 特性。
二、基于 ACK CNFS 存儲卷的 I/O 可觀測性框架
?為了幫助企業快速定位引發容器化應用 I/O 瓶頸的問題，保證業務持續穩定運行，阿里云容器文件存儲 ACK CNFS 提供了面向應用和集群維度的 I/O 可觀測性框架， 包括 POSIX 細粒度操作可觀測性、容器組粒度的可觀測性、跨機多副本的應用級可觀測性，以及集群維度針對文件系統和對象存儲的聚合訪問特性等，幫助用戶構建統一的客戶端 I/O 性能問題監測和分析能力01
1.什么是 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 使用。
2.容器存儲卷 I/O 問題類型
本文會以對象存儲 OSS 訪問為例，通過 ACK 存儲卷 I/O 可觀測能力對應用內掛載的 I/O 特性分析、問題診斷和針對熱點應用/熱點數據分析、掛載失敗分析來解決如下四類問題：
- 定位容器內應用哪些 I/O 操作高造成的系統繁忙。
- 定位容器內應用元數據操作高造成的后臺系統繁忙。
- 定位容器內應用數據操作高的熱點文件系統和熱點文件路徑。
- 應用數據卷文件系統掛載失敗分析。
3.存儲卷監控儀表板大盤
存儲卷的監控儀表板包含三個大盤：
- 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，哪些請求元數據導致后臺系統繁忙，如何找出熱點數據。
三、?如何通過 ACK 存儲卷 I/O 可觀測能力定位應用維度的 I/O 問題
1.問題一：哪些 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 帶寬報警解除。
?2.問題二：哪些元數據的操作頻繁會導致后臺系統繁忙
（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 每秒的請求量下降：
3.問題三：有哪些數據操作頻繁的熱點文件系統呵熱點文件路徑？
（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
4.掛載失敗事件透出
系統檢測到文件系統掛載失敗并透出事件，事件中心發送報警事件通知用戶 “文件系統掛載失敗”，用戶點擊鏈接定位到問題 Pod 的掛載失敗事件的詳細內容。
在本示例中，名稱為 default 命名空間下的 oss-fio-read-sts1-0 掛載數據卷失敗。失敗原因：掛載 OSS 時未找到相應的 Secret。通過修復 secret，設定正確的子賬號的 AK／SK，掛載卷恢復正常，報警解除。
四、小結
綜上所述，在企業生產環境下 Pod 數量多、規模大，環境復雜場景下，通過阿里云容器服務 ACK 的存儲卷的 I/O 可觀測性可以幫助客戶快速、準確地定位是哪個 Pod、哪個應用占用了過多帶寬，元數據請求和數據請求資源，幫助客戶通過優化策略、修改應用等方式解決 I/O 性能問題，提升業務運行效率。
[1] 開啟 OSSFS Cache
https://github.com/aliyun/ossfs/blob/master/doc/man/ossfs.1#L59
[2] 數據加速 Fluid 概述
https://help.aliyun.com/document_detail/208335.html?
