作者 | 王焦

?容器和 Kubernetes 的發(fā)展成熟為應(yīng)用的云原生化提供最基礎(chǔ)的支撐，從而使企業(yè)最大化利用云上的資源。存儲作為應(yīng)用運行的基石，也在服務(wù)云原生化的過程中不斷演進。

一、容器化應(yīng)用 I/O 性能優(yōu)化挑戰(zhàn)

?目前在云上的容器化應(yīng)用場景選擇存儲方案時，通常會使用塊存儲（EBS），文件存儲（NAS，CPFS，DBFS）和對象存儲（OSS）三種，POSIX 語義的文件系統(tǒng)是面向容器存儲使用場景最直觀和最友好的方式，通常也是容器場景下使用最多的存儲訪問方式。另一方面，為了實現(xiàn)集群級別的存儲編排能力，K8s 在維護容器組（Pod）的生命周期中會將依賴的存儲卷以文件系統(tǒng)的形式掛載到容器內(nèi)，從而從應(yīng)用角度可以無差別地讀寫塊存儲、文件存儲和對象存儲的外置存儲。

現(xiàn)在，云原生應(yīng)用的規(guī)模化趨勢日益明顯，在大數(shù)據(jù)分析、AI 等數(shù)據(jù)密集型場景也得到越來越廣泛地應(yīng)用，這些場景對 I/O 性能的要求很高。而現(xiàn)實情況是，云上的文件存儲和對象存儲一般都是以 TCP 和 HTTP(s)協(xié)議提供存儲服務(wù)，是典型的客戶端服務(wù)器（CS）模式，傳統(tǒng)的服務(wù)端監(jiān)控是通過發(fā)起者的 IP／連接來區(qū)分不同的應(yīng)用，但在容器形式的部署中一個虛擬機／物理機節(jié)點可以部署數(shù)十個到數(shù)百個容器，一個應(yīng)用可以跨多個主機。因此，傳統(tǒng)的服務(wù)端監(jiān)控在現(xiàn)代的容器化部署中不能提供足夠的觀測粒度和維度來分析不同應(yīng)用的 I/O 特性。

二、基于 ACK CNFS 存儲卷的 I/O 可觀測性框架

?為了幫助企業(yè)快速定位引發(fā)容器化應(yīng)用 I/O 瓶頸的問題，保證業(yè)務(wù)持續(xù)穩(wěn)定運行，阿里云容器文件存儲 ACK CNFS 提供了面向應(yīng)用和集群維度的 I/O 可觀測性框架， 包括 POSIX 細粒度操作可觀測性、容器組粒度的可觀測性、跨機多副本的應(yīng)用級可觀測性，以及集群維度針對文件系統(tǒng)和對象存儲的聚合訪問特性等，幫助用戶構(gòu)建統(tǒng)一的客戶端 I/O 性能問題監(jiān)測和分析能力01

1.什么是 CNFS？

容器文件存儲（CNFS）是對文件存儲和對象存儲的生命周期管理邏輯抽象對象，通過提供 CNFS-OSSFS，CNFS-NAS，CNFS-CPFS，CPFS-DBFS 等存儲類（StorageClass）來實現(xiàn)對云上 OSS Bucket，NAS FileSystem，CPFS，DBFS 的全生命周期管理和動態(tài)卷（PV）的增刪查改（CRUD）：

• CNFS-OSSFS 今天已經(jīng)被廣泛的使用在大數(shù)據(jù)，自動駕駛，生物計算領(lǐng)域，作為訪問 OSS 的主要手段。 
• CNFS-NAS 已經(jīng)與彈性加速客戶端（Elastic Acceleration Client）深度整合，在 NFS 客戶端基礎(chǔ)上優(yōu)化了多連接傳輸、支持了本地緩存/分布式緩存，預(yù)讀預(yù)寫功能加速文件讀寫，目前已經(jīng)在 CICD，機器學(xué)習(xí)，生物計算等領(lǐng)域廣泛使用。  
• CNFS-CPFSv2 作為低延遲，百萬級文件訪問的高性能存儲，也已經(jīng)在高性能計算，自動駕駛，生物計算等領(lǐng)域廣泛使用。 
• CPFS-DBFS 已經(jīng)作為數(shù)據(jù)庫服務(wù)提供共享數(shù)據(jù)庫文件存儲，有效降低了數(shù)據(jù)庫系統(tǒng)的多副本成本，目前已經(jīng)在云上數(shù)據(jù)庫領(lǐng)域 DBaaS 使用。  

2.容器存儲卷 I/O 問題類型

本文會以對象存儲 OSS 訪問為例，通過 ACK 存儲卷 I/O 可觀測能力對應(yīng)用內(nèi)掛載的 I/O 特性分析、問題診斷和針對熱點應(yīng)用/熱點數(shù)據(jù)分析、掛載失敗分析來解決如下四類問題：

• 定位容器內(nèi)應(yīng)用哪些 I/O 操作高造成的系統(tǒng)繁忙。 
• 定位容器內(nèi)應(yīng)用元數(shù)據(jù)操作高造成的后臺系統(tǒng)繁忙。 
• 定位容器內(nèi)應(yīng)用數(shù)據(jù)操作高的熱點文件系統(tǒng)和熱點文件路徑。 
• 應(yīng)用數(shù)據(jù)卷文件系統(tǒng)掛載失敗分析。 

3.存儲卷監(jiān)控儀表板大盤

存儲卷的監(jiān)控儀表板包含三個大盤：

• Container Storage IO Monitoring (Cluster Level)：容器存儲 I/O 監(jiān)控（集群維度）的大盤，TOPN Pod 的重要指標(biāo)的統(tǒng)計。 
• Pod IO Monitoring (Pod Level)：容器組 I/O 監(jiān)控（容器組維度）的大盤，以 Pod 為過濾選項，存儲卷重要指標(biāo)的統(tǒng)計。 
• OSS IO Monitoring (Cluster Level)：對象存儲 I/O 監(jiān)控（集群維度）的大盤，以 OSS Bucket 為過濾選項，存儲重要指標(biāo)的統(tǒng)計。 

模擬用戶創(chuàng)建兩類有狀態(tài)服務(wù)：oss-fio-read-sts，ReplicaSet：3 個，功能：使用 fio 命令讀取 OSS 存儲卷中預(yù)先寫好的 5G 大小的臨時文件 5G.tmpfile， 模擬頻繁讀操作；oss-fio-list-sts，ReplicaSet：1 個，功能：在 OSS 存儲卷中執(zhí)行文件的 list 遍歷操作， 模擬頻繁請求文件元信息操作；接下來，我們?nèi)绾螐脑飘a(chǎn)品監(jiān)控收到告警，并通過 ACK 的存儲卷定位出哪些是高 I/O 的 pod，哪些請求元數(shù)據(jù)導(dǎo)致后臺系統(tǒng)繁忙，如何找出熱點數(shù)據(jù)。

三、?如何通過 ACK 存儲卷 I/O 可觀測能力定位應(yīng)用維度的 I/O 問題

1.問題一：哪些 I/O 操作頻繁會導(dǎo)致系統(tǒng)繁忙

（1）通過云產(chǎn)品監(jiān)控，創(chuàng)建內(nèi)網(wǎng)流量告警規(guī)則并添加規(guī)則描述：當(dāng) OSS Bucket 的內(nèi)網(wǎng)流出流量大于 10Gbps/s 時，將觸發(fā)告警，告警名稱為“內(nèi)網(wǎng)流出流量大于 10Gbps/s”。

（2）當(dāng) OSS Bucket 內(nèi)網(wǎng)出流量大于 10Gbps/s 時，會收到監(jiān)控告警，您可以通過以下操作定位當(dāng)應(yīng)用 Pod 的 PV 讀訪問請求高時，可能觸發(fā)服務(wù)側(cè)限流和不響應(yīng)問題。

（3）查看 Container Storage IO Monitoring (Cluster Level)監(jiān)控大盤，根據(jù) TopN_Pod_IOPS(IO/s)和 TopN_Pod_Throughput 面板的 read_rate 排序，找到高 I/O 和高吞吐的 Pod。

??由示例可看出，名稱為 oss-fio-read-sts-1 的 Pod 產(chǎn)生了最多的讀 I/O 和讀吞吐。4. 查看 Pod IO Monitoring (Pod Level)監(jiān)控大盤，選擇 Pod 為 oss-fio-read-sts-1，然后查看 Throughput 和 POSIX Operation(count/s)面板，找出導(dǎo)致高吞吐的 POSIX Operation，并定位數(shù)據(jù)卷。

???

由示例可看出，名稱為 oss-fio-read-sts-1 的 Pod 掛載的 oss-pv 數(shù)據(jù)卷產(chǎn)生了過多的 read 請求。

（5）在集群列表頁面中，單擊目標(biāo)集群名稱，然后在左側(cè)導(dǎo)航欄中，選擇工作負載 > 容器組。

（6）在容器組頁面，名稱列下名為 oss-fio-read-sts-1 的 Pod 進入詳情頁面。在該頁面下獲取應(yīng)用的鏡像信息，根據(jù)以上獲取的高 I/O 和高吞吐信息，根據(jù)該容器的標(biāo)準(zhǔn)輸出日志來定位具體哪些具體業(yè)務(wù)操作導(dǎo)致了過高的 I/O 吞吐，從而決定業(yè)務(wù)側(cè)的邏輯改進優(yōu)化 I/O 的訪問，重新構(gòu)建鏡像替換。對于低優(yōu)先的離線業(yè)務(wù)可以刪除該負載來暫時緩解吞吐壓力。7. 根據(jù)以上示例分析，可以嘗試刪除流量較大的 oss-fio-read-sts 工作負載，來降低 OSS 內(nèi)網(wǎng)出流量，再查看Pod監(jiān)控，流量降低，總體 OSS Bucket 吞吐降低，OSS 帶寬報警解除。

?2.問題二：哪些元數(shù)據(jù)的操作頻繁會導(dǎo)致后臺系統(tǒng)繁忙

（1）通過云產(chǎn)品監(jiān)控，創(chuàng)建 HeadObject 的告警規(guī)則并添加規(guī)則描述：

當(dāng) OSS Bucket 的 HeadObject 請求達到 10000 次/分鐘時，將觸發(fā)告警，告警名稱為“OSS Head 請求大于 10000 次/min”。

（2）當(dāng) HeadObject 請求大于 10000 次/分鐘時，收到監(jiān)控告警，您可以通過以下操作定位當(dāng) Bucket 元數(shù)據(jù)讀訪問請求過高時，可能觸發(fā)服務(wù)側(cè)限流和不響應(yīng)問題。

（3）查看 OSS IO Monitoring (Cluster Level)監(jiān)控大盤，選擇對應(yīng)的 Bucket，查看 Aggregated Operation of OSS Operation (count/s)面板中的 HeadObject 請求數(shù)。

??由示例可看出，Bucket 名稱為 oss--2 產(chǎn)生了大量的 HeadObject 請求。

（4）查看 Container Storage IO Monitoring (Cluster Level)監(jiān)控大盤，根據(jù) TopN_Pod_Head_OSS_Operation 面板的 counter 排序，找到 HeadObject 請求數(shù)過多的 Pod，根據(jù) TopN_PV_Head_OSS_Operation 面板，找到 HeadObject 請求最多的存儲卷。

???由示例可看出：名稱為 oss-fio-list_sts-0 的 Pod 產(chǎn)生的 HeadObject 請求數(shù)最多而且在 5 分鐘內(nèi) I/O 速率最高；名稱為 oss-pv 的數(shù)據(jù)卷產(chǎn)生的 HeadObject 請求數(shù)最多且 5 分鐘內(nèi) I/O 速率最高。

（5）查看 Pod IO Monitoring (Pod Level)監(jiān)控大盤，選擇 Pod 為 oss-fio-list_sts-0，查看 OSS Object Operation Ration(count/s)面板中 Pod 的 I/O 情況。

（6）在集群列表頁面中，單擊目標(biāo)集群名稱，然后在左側(cè)導(dǎo)航欄中，選擇工作負載 > 容器組。

（7）在容器組頁面，根據(jù)以上示例分析，單擊名稱列下名為 oss-fio-list_sts-0 的 Pod 進入詳情頁面。在該頁面下獲取應(yīng)用的鏡像信息，根據(jù)以上獲取的 HeadObject 請求數(shù)和 I/O 情況，根據(jù)該容器的標(biāo)準(zhǔn)輸出日志來定位具體哪些具體業(yè)務(wù)操作導(dǎo)致了過高的 I/O 吞吐，從而決定業(yè)務(wù)側(cè)的邏輯改進優(yōu)化 I/O 的訪問，重新構(gòu)建鏡像替換。對于低優(yōu)先的離線業(yè)務(wù)可以刪除該負載來暫時緩解吞吐壓力。針對次例子，修改應(yīng)用邏輯避免對根目錄做遞歸的目錄遍歷 e.g. 'ls -hlR';'grep -r'，對指定目錄和更準(zhǔn)確目錄執(zhí)行遍歷和搜索操作，來降低對元數(shù)據(jù)的遍歷操作。

（8）根據(jù)以上示例分析，可以嘗試修改成進入到最深的目錄執(zhí)行 ls 操作，再查看 Pod 監(jiān)控，HeadObject 每秒的請求量下降：

3.問題三：有哪些數(shù)據(jù)操作頻繁的熱點文件系統(tǒng)呵熱點文件路徑？

（1）查看 OSS IO Monitoring (Cluster Level)監(jiān)控大盤。獲取 OSS 的 Bucket 中頻繁訪問的文件和文件路徑。通過對 counter 和 rate 倒排序定位到熱點目錄和熱點文件。

?由示例可看出，Bucket 中頻繁讀取的文件是/fio-data/read/5G.tmpfile，訪問的路徑為/fio-data/read。

（2） 查看 Container Storage IO Monitoring (Cluster Level)監(jiān)控大盤，根據(jù) TopN_Pod_Read_Path 面板的 counter 排序，找到有問題的 Pod。

?由示例可看出，存在問題的 Pod 是 oss-fio-read-sts-0。

（3）查看 Pod IO Monitoring (Pod Level)監(jiān)控大盤，選擇 Pod 為 oss-fio-read-sts-0，根據(jù) HotSpot Path of Top Read Operation 面板的 counter 和 rate 倒排序，找到 Pod 中頻繁訪問的文件和文件路徑。

?由示例可看出，Pod 中頻繁讀取的文件/fio-data/read/5G.tmpfile，訪問的路徑為/fio-data/read。

（4）根據(jù)以上示例分析，通過開啟 OSSFS Cache 來實現(xiàn)單機的緩存命中，參考文末文檔。也可以開啟分布式緩存 Fluid 緩存熱點數(shù)據(jù)，來解決頻繁讀取熱點數(shù)據(jù)問題。04

4.掛載失敗事件透出

系統(tǒng)檢測到文件系統(tǒng)掛載失敗并透出事件，事件中心發(fā)送報警事件通知用戶 “文件系統(tǒng)掛載失敗”，用戶點擊鏈接定位到問題 Pod 的掛載失敗事件的詳細內(nèi)容。

在本示例中，名稱為 default 命名空間下的 oss-fio-read-sts1-0 掛載數(shù)據(jù)卷失敗。失敗原因：掛載 OSS 時未找到相應(yīng)的 Secret。通過修復(fù) secret，設(shè)定正確的子賬號的 AK／SK，掛載卷恢復(fù)正常，報警解除。

四、小結(jié)

綜上所述，在企業(yè)生產(chǎn)環(huán)境下 Pod 數(shù)量多、規(guī)模大，環(huán)境復(fù)雜場景下，通過阿里云容器服務(wù) ACK 的存儲卷的 I/O 可觀測性可以幫助客戶快速、準(zhǔn)確地定位是哪個 Pod、哪個應(yīng)用占用了過多帶寬，元數(shù)據(jù)請求和數(shù)據(jù)請求資源，幫助客戶通過優(yōu)化策略、修改應(yīng)用等方式解決 I/O 性能問題，提升業(yè)務(wù)運行效率。

[1] 開啟 OSSFS Cache

https://github.com/aliyun/ossfs/blob/master/doc/man/ossfs.1#L59

[2] 數(shù)據(jù)加速 Fluid 概述

https://help.aliyun.com/document_detail/208335.html?