儲存體設定

發行項
04/10/2024

Kubernetes 儲存體概念

Kubernetes 在基礎虛擬化技術堆疊 (選用) 和硬體上提供基礎結構抽象層。 Kubernetes 將儲存體抽象化的方式是透過儲存類別。當您佈建 Pod 時，您可以為每個磁碟區指定儲存類別。在佈建 Pod 時，會呼叫儲存類別佈建器來佈建儲存體、在該佈建的儲存體上建立持續性磁碟區，然後由持續性磁碟區宣告將 Pod 掛接至持續性磁碟區。

Kubernetes 為儲存體基礎結構提供者提供一種方式，插入可擴充 Kubernetes 的驅動程式 (也稱為「附加元件」)。儲存體附加元件必須符合容器儲存體介面標準。在此 CSI 驅動程式的非明確清單中可以找到數十個附加元件。您使用的特定 CSI 驅動程式取決於各種因素，例如您是否在雲端裝載、受控 Kubernetes 服務執行，或您將哪個 OEM 提供者用於硬體。

若要檢視 Kubernetes 叢集中設定的儲存體類別，請執行此命令：

kubectl get storageclass

Azure Kubernetes Service (AKS) 叢集的範例輸出：

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

您可以執行下列命令，以取得儲存類別的詳細資料：

kubectl describe storageclass/<storage class name>

範例：

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

您可以執行下列命令來查看目前佈建的持續性磁碟區和持續性磁碟區宣告：

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

顯示持續性磁碟區的範例：


kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

顯示持續性磁碟區宣告的範例：


kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

選擇儲存體設定時要考慮的因素

選取正確的儲存類別對於資料復原和效能很重要。選擇錯誤的儲存類別可能會讓您的資料在發生硬體故障時發生完全資料遺失，或可能導致較低效能。

儲存體分為兩種類型：

本地儲存體 - 在指定節點上的本地硬碟上佈建的儲存體。這種儲存體在效能方面可能很理想，但需要透過跨多個節點複寫資料來特別設計資料備援。
遠端、共用儲存體- 在某些遠端儲存裝置上佈建的儲存體，例如 SAN、NAS 或 EBS 或 Azure 檔案儲存體等雲端儲存體服務。這種儲存體通常會自動提供資料備援，但不像本地儲存體一樣快速。

以 NFS 為基礎的儲存類別

視 NFS 伺服器和儲存類別佈建器的設定而定，您可能需要在資料庫執行個體的 Pod 設定中設定 supplementalGroups，而且您可能需要變更 NFS 伺服器設定，以使用用戶端所傳入的群組識別碼 (而不是使用傳入的使用者識別碼，在伺服器上尋找群組識別碼)。請洽詢 NFS 管理員，以判斷情況是否如此。

supplementalGroups 屬性會採用您可以在部署時設定的值陣列。 Azure Arc 資料控制器會將這些套用至其所建立的任何資料庫執行個體。

若要設定此屬性，請執行下列命令：

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

資料控制器儲存體設定

服務無法複寫資料，因此 Azure Arc 中資料服務的某些服務取決於使用遠端共用儲存體的設定。您可以在資料控制器 Pod 的集合中找到這些服務：

服務	持續性磁碟區宣告
OpenSearch	`<namespace>/logs-logsdb-0`, `<namespace>/data-logsdb-0`
InfluxDB	`<namespace>/logs-metricsdb-0`, `<namespace>/data-metricsdb-0`
控制器 SQL 執行個體	`<namespace>/logs-controldb`, `<namespace>/data-controldb`
控制器 API 服務	`<namespace>/data-controller`

在佈建資料控制器時，將 --storage-class |-sc 參數傳遞至 az arcdata dc create 命令，或在使用的 control.json 部署範本檔案中設定儲存類別，來指定要用於每個持續性磁碟區的儲存類別。如果您使用 Azure 入口網站在直接連線模式中建立資料控制器，您選擇的部署範本會在範本中預先定義儲存類別，否則您可選取沒有預先定義儲存類別的範本。如果您的範本未定義儲存類別，則入口網站會提示您輸入一個。如果您使用自訂部署範本，則可以指定儲存類別。

現成提供的部署範本具有已指定適用於目標環境的預設儲存類別，但在部署期間可以覆寫該範本。請參閱建立自訂設定範本的詳細步驟，以在部署時變更資料控制器 Pod 的儲存類別設定。

如果您使用 --storage-class 或 -sc 參數來設定儲存類別，該儲存類別會同時用於記錄和資料儲存類別。如果您在部署範本檔案中設定儲存類別，您可以針對記錄和資料指定不同的儲存類別。

為資料控制器 Pod 選擇儲存類別時要考慮的重要因素：

您必須使用遠端共用儲存類別，以確保資料持久性，如此一來，如果 Pod 或節點在 Pod 恢復運作時終止，就可以再次連線到持續性磁碟區。
寫入控制器 SQL 執行個體、計量 DB 和記錄資料庫的資料數量通常相當少，而且對延遲不敏感，因此超快速效能儲存體並不重要。如果您有經常使用 Grafana 和 Kibana 介面的使用者，而且您有大量的資料庫執行個體，則使用者可能會受益於更快的儲存體效能。
所需的儲存體容量會隨著您部署的資料庫執行個體數量而變動，因為會針對每個資料庫執行個體收集記錄和計量。資料會在記錄和計量 DB 中保留兩 (2) 週後清除。
在部署後變更儲存類別很困難，不會記載下來且不受支援。請務必在部署時正確選擇儲存類別。

注意

如果未指定儲存類別，則會使用預設儲存類別。每個 Kubernetes 叢集只能有一個預設儲存類別。您可以變更預設儲存類別。

資料庫執行個體儲存體設定

每個資料庫執行個體都有資料、記錄和備份持續性磁碟區。您可以在部署時指定這些持續性磁碟區的儲存類別。如果未指定儲存類別，則會使用預設儲存類別。

使用 az sql mi-arc create 或 az postgres server-arc create 建立執行個體時，有四個參數可用來設定儲存類別：

參數名稱，簡短名稱	用於
`--storage-class-data`, `-d`	所有資料檔案的儲存類別 (.mdf、ndf)。如未指定，則預設為資料控制器的儲存類別。
`--storage-class-logs`, `-g`	所有記錄檔的儲存類別。如未指定，則預設為資料控制器的儲存類別。
`--storage-class-data-logs`	資料庫交易記錄檔的儲存類別。如未指定，則預設為資料控制器的儲存類別。
`--storage-class-backups`	所有備份檔案的儲存類別。如未指定，則預設為資料的儲存類別 (`--storage-class-data`)。使用支援 ReadWriteMany (RWX) 的儲存類別以用於備份。深入了解存取模式。

警告

如果您未指定備份的儲存類別，則部署會使用資料指定的儲存類別。如果此儲存類別不支援 RWX，則時間點還原可能無法視需要運作。

下表列出對應至資料與記錄持續性磁碟區的 Azure SQL 受控執行個體容器內的路徑：

參數名稱，簡短名稱	`mssql-miaa` 容器內的路徑	描述
`--storage-class-data`, `-d`	/var/opt	包含 mssql 安裝和其他系統流程的目錄。 mssql 目錄包含預設資料 (包括交易記錄)、錯誤記錄檔和備份目錄
`--storage-class-logs`, `-g`	/var/log	包含目錄，可儲存主控台輸出 (stderr、stdout)、容器內流程的其他記錄資訊

下表列出對應至資料與記錄持續性磁碟區的 PostgreSQL 執行個體容器內的路徑：

參數名稱，簡短名稱	postgres 容器內的路徑	描述
`--storage-class-data`, `-d`	/var/opt/postgresql	包含 postgres 安裝的資料和記錄目錄
`--storage-class-logs`, `-g`	/var/log	包含目錄，可儲存主控台輸出 (stderr、stdout)、容器內流程的其他記錄資訊

每個資料庫執行個體都有個別的持續性磁碟區，以供資料檔案、記錄和備份使用。這表示每個檔案類型的 I/O 都會分開，但受限於磁碟區佈建器佈建儲存體的方式。每個資料庫執行個體都有自己的持續性磁碟區宣告和持續性磁碟區。

如果指定資料庫執行個體上有多個資料庫，則所有資料庫都會使用相同的持續性磁碟區宣告、持續性磁碟區和儲存類別。所有備份 - 差異記錄備份和完整備份都會使用相同的持續性磁碟區宣告和持續性磁碟區。資料庫執行個體 Pod 的持續性磁碟區宣告如下所示：

執行個體	持續性磁碟區宣告
Azure SQL 受控執行個體	`<namespace>/logs-<instance name>-0`, `<namespace>/data-<instance name>-0`
PostgreSQL 執行個體的 Azure 資料庫	`<namespace>/logs--<instance name>-0`, `<namespace>/data--<instance name>-0`
Azure PostgreSQL	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

為資料庫執行個體 Pod 選擇儲存類別時要考慮的重要因素：

從 2022 年 2 月版本的 Azure Arc 資料服務開始，您必須指定用於備份的 ReadWriteMany (RWX) 支援之儲存類別。深入了解存取模式。如果沒有指定用於備份的儲存類別，則會使用 Kubernetes 中的預設儲存類別，而如果不支援 RWX，Azure SQL 受控執行個體部署可能不會成功。
資料庫執行個體可以部署在單一 Pod 模式或多個 Pod 模式中。單一 Pod 模式的範例是一般用途定價層 Azure SQL 受控執行個體。多個 Pod 模式的範例是高可用性業務關鍵定價層 Azure SQL 受控執行個體。使用單一 pod 模式部署的資料庫執行個體必須使用遠端共用儲存類別，以確保資料持久性，如此一來，如果 Pod 或節點在 Pod 恢復運作時終止，就可以再次連線到持續性磁碟區。相反地，高可用性 Azure SQL 受控執行個體會使用 Always On 可用性群組，以同步或非同步方式將資料從某個執行個體複寫到另一個執行個體。特別是在同步複寫資料的案例下，資料一律有多個複本，通常是三個複本。因此，您可以使用本地儲存體或遠端共用儲存類別來儲存資料和記錄檔。如果使用本地儲存體，即使發生失敗的 Pod、節點或儲存體硬體，資料仍會保留，因為有多個資料複本。基於此彈性，您可以選擇使用本地儲存體來提升效能。
資料庫效能主要是指定儲存體裝置的 I/O 輸送量功能。如果資料庫需要大量讀取或大量寫入，則您應該選擇具有針對該工作負載類型設計的硬體的儲存類別。例如，如果資料庫大部分用於寫入，您可以選擇具有 RAID 0 的本地儲存體。如果您的資料庫最常用於讀取少量「經常性資料」，但有大量的冷資料整體儲存量，則您可以選擇能夠分層儲存的 SAN 裝置。選擇正確的儲存類別，與選擇您要用於任何資料庫的儲存體類型沒有區別。
如果您使用本地儲存體磁碟區佈建器，請確定針對資料、記錄和備份佈建的本地磁碟區都是在不同的基礎儲存體裝置上登陸，以避免磁碟 I/O 發生爭用。 OS 也應該位於掛接至個別磁碟的磁碟區上。這基本上與實體硬體上資料庫執行個體遵循的指導相同。
由於指定執行個體上的所有資料庫都會共用持續性磁碟區宣告和持續性磁碟區，因此請勿必將忙碌的資料庫執行個體共置在同一個資料庫執行個體上。可能的話，請將忙碌資料庫分開至自己的資料庫執行個體，以避免 I/O 爭用。此外，使用節點標籤定位，將資料庫執行個體放在不同的節點上，以便將整體 I/O 流量散發到多個節點。如果您使用虛擬化，請務必考慮不只是在節點等級散發 I/O 流量，同時考慮指定實體主機上所有節點 VM 所發生的合併 I/O 活動。

估計儲存體需求

每個包含具狀態資料的 Pod 都會使用至少兩個持續性磁碟區，一個持續性磁碟區用於資料，另一個持續性磁碟區用於記錄。下表列出單一資料控制器、Azure SQL 受控執行個體、適用於 PostgreSQL 執行個體的 Azure 資料庫和 Azure PostgreSQL 超大規模資料庫執行個體所需的持續性磁碟區數量：

資源類型	具狀態 Pod 的數量	持續性磁碟區的必要數量
資料控制器	4 (`control`、`controldb`、`logsdb`、`metricsdb`)	4 * 2 = 8
Azure SQL 受控執行個體	1	2
Azure PostgreSQL	1	2

下表顯示樣本部署所需的持續性磁碟區總數：

資源類型	執行個體數目	持續性磁碟區的必要數量
資料控制器	1	4 * 2 = 8
Azure SQL 受控執行個體	5	5 * 2 = 10
Azure PostgreSQL	5	5 * 2 = 10
持續性磁碟區的總數		8 + 10 + 10 = 28

此計算可用來根據儲存體佈建器或環境來規劃 Kubernetes 叢集的儲存體。例如，如果本地儲存體佈建器用於具有五個 (5) 節點的 Kubernetes 叢集，則對於樣本部署，上述每個節點至少需要 10 個持續性磁碟區的儲存體。同樣地，在佈建有五個 (5) 節點 Azure Kubernetes Service (AKS) 叢集時，為節點集區挑選適合的 VM 大小，以便可以連結 10 個資料磁碟，這點非常重要。如需如何為 AKS 節點的儲存體需求調整節點大小的詳細資訊，請參閱這裡。

選擇正確的儲存類別

內部部署和邊緣網站

Microsoft 及其 OEM、OS 和 Kubernetes 合作夥伴有 Azure Arc 資料服務的驗證計畫。此計畫會提供來自認證測試工具組的可比較測試結果。測試會評估功能相容性、壓力測試結果，以及效能和可擴縮性。測試結果指出所使用的 OS、使用的 Kubernetes 散發、使用的 HW、使用的 CSI 附加元件，以及使用的儲存類別。這可協助客戶針對需求選擇最佳的儲存類別、OS、Kubernetes 散發和硬體。如需此計畫和測試結果的詳細資訊，請參閱這裡。

公用雲端、受控 Kubernetes 服務

針對公用雲端式受控 Kubernetes 服務，我們可以提出下列建議：

公用雲端服務	建議
Azure Kubernetes Service (AKS)	Azure Kubernetes Service (AKS) 有兩種儲存體 - Azure 檔案儲存體和 Azure 受控磁碟。每種儲存體都有兩個定價/效能層 - 標準 (HDD) 和進階 (SSD)。因此，AKS 中提供的四個儲存類別為 `azurefile` (Azure 檔案儲存體標準層)、`azurefile-premium` (Azure 檔案儲存體進階層)、`default` (Azure 磁碟標準層) 以及 `managed-premium` (Azure 磁碟進階層)。預設儲存類別為 `default` (Azure 磁碟標準層)。您應該考慮的類型和階層之間有顯著的價格差異。針對具有高效能需求的生產工作負載，我們建議針對所有儲存類別使用 `managed-premium`。若是開發/測試工作負載、概念證明等，成本是考慮，而 `azurefile` 為成本最低的選項。這四個選項都可用於需要遠端、共用儲存體的情況，因為其都是 Azure 中網路連接儲存體裝置。深入瞭解 AKS 儲存體。
AWS Elastic Kubernetes Service (EKS)	Amazon 的 Elastic Kubernetes Service 有一個主要儲存類別 - 以 EBS CSI 儲存體驅動程式為基礎。建議對生產工作負載使用此項。有新的儲存體驅動程式 - EFS CSI 儲存體驅動程式 -可新增至 EKS 叢集，但目前處於搶鮮版 (Beta) 階段且可能變更。雖然 AWS 指出支援將此儲存體驅動程式用於生產環境，但我們不建議使用，因為其仍處於搶鮮版 (Beta) 且可能有所變更。 EBS 儲存類別是預設值，名為 `gp2`。深入瞭解 EKS 儲存體。
Google Kubernetes Engine (GKE)	Google Kubernetes Engine (GKE) 只有一個名為 `standard` 的儲存類別。這個類別用於 GCE 永續性磁碟。此類別是唯一的，也是預設值。雖然 GKE 有您可以與直接連結的 SSD 搭配使用的本地靜態磁碟區佈建器，但我們不建議使用，因為 Google 不會維護或支援此項。深入瞭解 GKE 儲存體。

共用方式為