ストレージの構成

Kubernetes ストレージの概念

Kubernetes は、基盤となる仮想化技術スタック (オプション) とハードウェアにインフラストラクチャ抽象化レイヤーを提供します。 Kubernetes がストレージを抽象化する方法は、ストレージ クラスです。 ポッドをプロビジョニングする際、ボリュームごとにストレージ クラスを指定できます。 ポッドがプロビジョニングされると、ストレージ クラス プロビジョナーが呼び出されてストレージがプロビジョニングされ、プロビジョニングされたストレージ上に永続ボリュームが作成された後、永続ボリューム要求によってポッドが永続ボリュームにマウントされます。

Kubernetes は、Kubernetes を拡張するドライバー ("アドオン" とも呼ばれます) をストレージ インフラストラクチャ プロバイダーがプラグインする手段を提供します。 ストレージのアドオンは、Container Storage Interface 標準に準拠している必要があります。 この明確でない 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

ストレージ構成を選択する際に考慮する要素

適切なストレージ クラスを選択することは、データの回復性とパフォーマンスにとって重要です。 間違ったストレージ クラスを選択すると、ハードウェア障害が発生した場合にデータが失われたり、パフォーマンスが低下したりする可能性があります。

一般に、ストレージには次の 2 種類があります。

• ローカル ストレージ - 特定のノードのローカル ハード ドライブにプロビジョニングされているストレージ。 この種類のストレージはパフォーマンスに関しては理想的ですが、データを複数のノードにレプリケートすることによって、データの冗長性を確保するために特別に設計する必要があります。
• リモートの共有ストレージ - 一部のリモート記憶装置 (例えば、SAN、NAS、または EBS や Azure Files などのクラウド ストレージ サービス) でプロビジョニングされているストレージ。 通常、この種類のストレージはデータの冗長性を自動的に提供しますが、ローカル ストレージの場合ほど高速ではありません。

NFS ベースのストレージ クラス

NFS サーバーとストレージ クラス プロビジョナーの構成によっては、データベース インスタンスのポッド構成で supplementalGroups を設定する必要があります。また、クライアントによって渡されるグループ ID を使用するために NFS サーバー構成を変更する必要がある可能性があります (渡されたユーザー ID を使用してサーバー上のグループ ID を参照するのとは異なります)。 これに該当するかどうか、NFS 管理者に問い合わせて確認してください。

supplementalGroups プロパティは、デプロイ時に設定できる値の配列を受け取ります。 Azure Arc データ コントローラーは、作成するすべてのデータベース インスタンスにこれらを適用します。

このプロパティを設定するためには、次のコマンドを実行します。

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

データ コントローラーのストレージ構成

データ サービス用の Azure Arc の一部のサービスは、データをレプリケートする機能がないため、リモートの共有ストレージを使用するように構成する必要があります。 これらのサービスは、データ コントローラー ポッドのコレクションにあります。

データ コントローラーがプロビジョニングされるときに、これらの各永続ボリュームに使用されるストレージ クラスは、az arcdata dc create コマンドに --storage-class | -sc パラメーターを渡すか、使用する control.json 展開テンプレート ファイルでストレージ クラスを設定することによって指定されます。 Azure portal を使用して直接接続モードでデータ コントローラーを作成する場合、選択したデプロイ テンプレートには、テンプレートに定義済みのストレージ クラスがあるか、定義済みのストレージ クラスがないテンプレートを選択できます。 テンプレートでストレージ クラスが定義されていない場合は、ポータルからストレージ クラスの入力を求められます。 カスタム展開テンプレートを使用する場合は、ストレージ クラスを指定できます。

初期状態で提供される展開テンプレートでは、ターゲット環境に適した既定のストレージ クラスが指定されていますが、デプロイ時にオーバーライドできます。 デプロイ時にデータ コントローラー ポッドのストレージ クラス構成を変更するには、カスタム構成テンプレートを作成するための詳細な手順を参照してください。

--storage-class または -sc パラメーターを使用してストレージ クラスを設定した場合、そのストレージ クラスは、ログとデータの両方のストレージ クラスに使用されます。 展開テンプレート ファイルでストレージ クラスを設定した場合は、ログとデータに異なるストレージ クラスを指定できます。

データ コントローラー ポッドのストレージ クラスを選択する際に考慮する必要がある重要な要素は次のとおりです。

• データの持続性を確保するために、リモートの共有ストレージ クラスを使用する必要があります。これにより、ポッドが復旧したときにポッドまたはノードが停止した場合、永続ボリュームに再び接続できるようになります。
• コントローラー SQL インスタンス、メトリック DB、ログ DB に書き込まれるデータは、通常、非常に少ないボリュームであり、待機時間の影響を受けないため、超高速パフォーマンス ストレージは重要ではありません。 ユーザーが Grafana インターフェイスと Kibana インターフェイスを頻繁に使用していて、データベース インスタンスが多数ある場合、ユーザーはより高速なストレージの恩恵を受ける可能性があります。
• データベース インスタンスごとにログとメトリックが収集されるので、必要なストレージ容量は、配置したデータベース インスタンスの数による変数になります。 データは、消去される前に、ログとメトリック DB に 2 週間保持されます。
• デプロイ後にストレージ クラスを変更することは困難であり、ドキュメント化されておらず、サポートもされていません。 デプロイ時には、ストレージ クラスを正しく選択してください。

データベース インスタンスのストレージ構成

各データベース インスタンスには、データ、ログ、およびバックアップの永続ボリュームがあります。 これらの永続ボリュームのストレージ クラスは、デプロイ時に指定できます。 ストレージ クラスが指定されていない場合は、既定のストレージ クラスが使用されます。

az sql mi-arc create または az postgres server-arc create を使用してインスタンスを作成する場合、ストレージ クラスの設定に使用できるパラメーターが 4 つあります:

次の表は、データとログの永続ボリュームにマップされる Azure SQL Managed Instance コンテナー内のパスを示しています。

次の表は、データとログの永続ボリュームにマップされる PostgreSQL インスタンス コンテナー内のパスを示しています。

各データベース インスタンスには、データ ファイル、ログ、およびバックアップ用に個別の永続ボリュームがあります。 これは、ボリューム プロビジョナーがストレージをプロビジョニングする方法に応じて、これらの種類のファイルごとに I/O が分離されることを意味します。 各データベース インスタンスには、独自の永続ボリューム要求と永続ボリュームがあります。

特定のデータベース インスタンスに複数のデータベースが存在する場合、すべてのデータベースは同じ永続ボリューム要求、永続ボリューム、およびストレージ クラスを使用します。 すべてのバックアップ (差分ログ バックアップと完全バックアップの両方) で、同じ永続ボリューム要求と永続ボリュームが使用されます。 データベース インスタンス ポッドの永続ボリューム要求を次に示します。

データベース インスタンス ポッドのストレージ クラスを選択する際に考慮する必要がある重要な要素は次のとおりです。

• Azure Arc データ サービスの 2022 年 2 月のリリース以降、バックアップ用の ReadWriteMany (RWX) 対応ストレージ クラスを指定する必要があります。 アクセス モードの詳細についてご確認ください。 バックアップ用のストレージ クラスが指定されていない場合は、Kubernetes の既定のストレージ クラスが使用されます。これが RWX に対応していない場合、Azure SQL マネージド インスタンスのデプロイが成功しない可能性があります。
• データベース インスタンスは、単一のポッド パターンまたは複数のポッド パターンでデプロイできます。 単一のポッド パターンの例として、汎用価格レベルの Azure SQL マネージド インスタンスがあります。 複数のポッド パターンの例として、高可用性 Business Critical 価格レベルの Azure SQL マネージド インスタンスがあります。 単一のポッド パターンでデプロイされたデータベース インスタンスは、データの持続性を確保するために、リモートの共有ストレージ クラスを使用する必要があります。これにより、ポッドが復旧したときにポッドまたはノードが停止した場合、永続ボリュームに再び接続できるようになります。 これに対し、高可用性 Azure SQL マネージド インスタンスでは Always On 可用性グループを使用して、同期または非同期で 1 つのインスタンスから別のインスタンスにデータをレプリケートします。 特にデータが同期的にレプリケートされる場合、データのコピーは常に複数存在します (通常は 3 つのコピー)。 このため、データ ファイルとログ ファイルにローカル ストレージまたはリモートの共有ストレージ クラスを使用することができます。 ローカル ストレージを使用している場合でも、データのコピーが常に複数存在するため、ポッド、ノード、またはストレージのハードウェアに障害が発生した場合にはデータが保持されます。 この柔軟性を考慮して、パフォーマンスを向上させるためにローカル ストレージを使用することもできます。
• データベースのパフォーマンスは、主に特定の記憶装置の I/O スループットの関数です。 データベースの読み取りまたは書き込みが多い場合は、その種類のワークロード向けに設計されたハードウェアを備えたストレージ クラスを選択する必要があります。 たとえば、データベースがほとんど書き込みに使用されている場合は、RAID 0 を使用したローカル ストレージを選択できます。 データベースが主として少量の "ホット データ" の読み取りに使用されるが、コールド データの全体的なストレージ ボリュームが大きい場合は、階層化されたストレージを持つ SAN デバイスを選択できます。 適切なストレージ クラスを選択することは、データベースに使用するストレージの種類を選択することと全く同じです。
• ローカル ストレージ ボリューム プロビジョナーを使用している場合は、ディスク I/O の競合を避けるために、データ、ログ、およびバックアップ用にプロビジョニングされるローカル ボリュームが、基になる別々の記憶装置にそれぞれ配置されているようにします。 OS も、別のディスクにマウントされているボリューム上にある必要があります。 これは基本的に、物理ハードウェア上のデータベース インスタンスの場合と同じガイダンスです。
• 特定のインスタンス上のすべてのデータベースが永続ボリューム要求と永続ボリュームを共有するため、ビジー状態のデータベース インスタンスを同じデータベース インスタンス上に併置しないようにしてください。 可能であれば、I/O の競合を避けるために、ビジー状態のデータベースをそれぞれのデータベース インスタンスに分割します。 さらに、ノード ラベル ターゲット設定を使用してデータベース インスタンスを別々のノードに配置することで、全体的な I/O トラフィックを複数のノードに分散させることができます。 仮想化を使用している場合は、ノード レベルだけでなく、特定の物理ホスト上のすべてのノード VM によって発生する、結合された I/O アクティビティも、I/O トラフィックを分散することを検討してください。

ストレージ要件の推定

ステートフル データを含むすべてのポッドは、少なくとも 2 つの永続ボリューム (データ用の永続ボリュームとログ用の永続ボリューム) を使用します。 次の表は、単一のデータ コントローラー、Azure SQL マネージド インスタンス、Azure Database for PostgreSQL インスタンス、および Azure PostgreSQL HyperScale インスタンスに必要な永続ボリュームの数を示しています。

次の表は、サンプルのデプロイに必要な永続ボリュームの合計数を示しています:

この計算を使用して、ストレージのプロビジョナーまたは環境に基づいて Kubernetes クラスターのストレージを計画することができます。 たとえば、5 つのノードを持つ Kubernetes クラスターにローカル ストレージ プロビジョナーが使用されている場合、上記のサンプル デプロイでは、各ノードに少なくとも 10 個の永続ボリュームのストレージが必要です。 同様に、5 つのノードを持つ Azure Kubernetes Service (AKS) クラスターをプロビジョニングする場合は、10 個のデータ ディスクを接続できるように、ノード プールに適した VM サイズを選択することが重要です。 AKS ノードのストレージのニーズに応じてノードのサイズを変更する方法の詳細については、こちらを参照してください。

適切なストレージ クラスの選択

オンプレミスとエッジ サイト

Microsoft とその OEM、OS、Kubernetes パートナーには、Azure Arc データ サービスの認定プログラムがあります。 このプログラムは認定テスト ツールキットと同等のテスト結果を提供します。 テストでは、機能の互換性、ストレス テストの結果、パフォーマンスとスケーラビリティが評価されます。 テスト結果は、使用されている OS、使用されている Kubernetes ディストリビューション、使用されているハードウェア、使用されている CSI アドオン、および使用されているストレージ クラスを示します。 これにより、お客様は要件に合わせて最適なストレージ クラス、OS、Kubernetes ディストリビューション、およびハードウェアを選択できます。 このプログラムとテスト結果の詳細については、こちらを参照してください。

パブリック クラウド、マネージド Kubernetes サービス

パブリック クラウドベースのマネージド Kubernetes サービスについては、次の推奨事項を使用できます。