iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 19
0
DevOps

Best Practice for DevOps on GitLab and GCP系列 第 19

Best Practice for DevOps on GitLab and GCP : GCP 永久硬碟管理 (上) - Day 19 -

Imgur

前言

永久硬碟對於計算實例而言,如同本篇文章中房子下的樹根,不可或缺必然存在。而在 Google Cloud Platform 上的硬碟,除了在選擇硬碟分為永久硬碟和固態硬碟外,還需要經過一個數學的計算過程,為什麼呢?因為在雲端上的硬碟效能與硬碟的大小、計算實例的 vCPU 數有著密不可分的關聯性。

IOPS 與 總處理量

這是兩個在閱讀 GCP 文件中相當重要的指標,IOPS 所影響的是對於小檔案的讀寫,在一些時候會稱之為隨機讀寫硬碟:處理總量則是對於大檔案的持續性讀寫,在一些時候稱之為循序讀寫硬碟。有玩過類似於 Kafka, Hadoop HDFS 或特別研究過日誌讀寫的讀者,或許對於這些詞會較為熟悉,總的來說這兩種值越高意味著越好的效能。但這通常這意味著更高的成本,如何選擇合適的方案並節省成本就是一門經驗談了。

標準永久硬碟

標準永久磁碟 IOPS 和總處理量效能會隨著磁碟大小線性提高,直到達到下列每個執行個體的上限為止:

  • 讀取總處理量:磁碟大小為 2 TB 時最高可達 240 MB/秒。
  • 寫入總處理量:磁碟大小為 2 TB 時最高可達 240 MB/秒。
  • 讀取 IOPS:磁碟大小為 4 TB 時最高可達 3,000 IOPS。
  • 寫入 IOPS:磁碟大小為 10 TB 時最高可達 15,000 IOPS。

SSD 永久磁碟

  • 在 2000 GB 時達到隨機讀取 IOPS 上限 (60,000)
  • 在 1000 GB 時達到隨機寫入 IOPS 上限 (30,000)。

寫入總處理量的網路輸出上限

每個永久磁碟的寫入作業都會計入虛擬機器執行個體的累積網路輸出上限。

Compute Engine 會將資料儲存在永久磁碟中,讓永久磁碟內建備援功能。執行個體會同時將資料寫入永久磁碟三次以提供備援功能。此外,每項寫入要求都會使用輸出頻寬並造成一定程度的負擔。

每個虛擬機器執行個體根據虛擬機器的網路輸出上限,都有一個永久磁碟寫入上限。在永久磁碟與 IP 流量競爭使用網路輸出的情況下,60% 的網路輸出上限會提供給永久磁碟流量使用,而 40% 則是供 IP 流量使用。

下表顯示包含及不包含額外 IP 流量的預計永久磁碟寫入頻寬:

Imgur

這段話與圖引用於 GCP 官網文件,其意思就是 vCPU 的數量或理解成指機器的類型,會影響網路可用的流量大小,而網路流量的 60% 會用於網路硬碟,掛載的硬碟是一種以網路傳輸來寫入/讀取的設備,因此需要對於 vCPU 的大小來評估網路是否充裕。

結語

從文章中可以看出對於一般常見的硬碟在選用時,想達到最好的效果又不要有過高的成本,選擇 4 vCPU 或 8 vCPU 的方案搭配 10 TB 以上的硬碟可以有著最佳的效果,而差別在於 4 vCPU 在寫入時依舊會受到網路分配的寫入量影響。

在硬碟選用方面有更深入需求的讀者則可以參考 最佳化永久磁碟和本機SSD 的效能,做更深入的評估與計算選擇一個既符合成本又能達到效能的方案。

參考


上一篇
Best Practice for DevOps on GitLab and GCP : GCP 中繼資料 SSH 金鑰管理 - Day 18 -
下一篇
Best Practice for DevOps on GitLab and GCP : GCP 永久硬碟管理 (下) - Day 20 -
系列文
Best Practice for DevOps on GitLab and GCP30

尚未有邦友留言

立即登入留言