Kubernetes の SQL Server ビッグ データ クラスターでのデータ永続化

適用対象: SQL Server 2019 (15.x)

永続ボリュームでは、Kubernetes のストレージ向けのプラグイン モデルが提供されます。 このモデルでは、ストレージの提供方法は、その使用方法から抽象化されます。 そのため、独自の高可用性ストレージを利用して、SQL Server ビッグ データ クラスターに接続できます。 Kubernetes は、Azure ディスクとファイル、ネットワーク ファイル システム (NFS)、ローカル ストレージなどのさまざまな種類のストレージ ソリューションをサポートしていますが、ビッグ データ クラスターはテスト済みの構成でのみサポートされます。 サポートされている構成の詳細については、SQL Server 2019 ビッグ データ クラスター プラットフォームのリリース ノートをご覧ください。

永続ボリュームを構成する

SQL Server ビッグ データ クラスターでは、ストレージ クラスを利用してこれらの永続ボリュームが使用されます。 異なるストレージの種類に対して異なるストレージ クラスを作成し、ビッグ データ クラスターの展開時に指定できます。 特定の目的に使用するストレージ クラスと永続ボリューム要求のサイズをプール レベルで構成できます。 SQL Server ビッグ データ クラスターでは、永続ボリュームを必要とするコンポーネントごとに指定したストレージ クラス名を使って、永続ボリューム要求が作成されます。 その後、ポッド内で該当の 1 つの永続ボリューム (または複数のボリューム) がマウントされます。

ここでは、ビッグ データ クラスターのストレージ構成を計画する際に考慮する重要な事項について説明します。

• ビッグ データ クラスターの展開を成功させるには、必要な数の永続ボリュームが使用可能であることを確認する必要があります。 Azure Kubernetes Service (AKS) クラスターに展開していて、組み込みのストレージ クラス (default または managed-premium) を使用している場合、このクラスでは永続ボリュームの動的プロビジョニングがサポートされます。 そのため、永続ボリュームを事前に作成する必要はありませんが、AKS クラスター内で使用可能なワーカー ノードが、展開に必要な永続ボリュームと同じ数のディスクを接続できることを確認する必要があります。 ワーカー ノードに対して指定されている VM サイズによっては、各ノードが特定の数のディスクを接続できます。 既定のサイズのクラスター (高可用性なし) の場合は、少なくとも 24 個のディスクが必要です。 高可用性を有効にする場合、またはプールをスケール アップする場合は、スケール アップするリソースに関係なく、追加のレプリカごとに少なくとも 2 つの永続化ボリュームを確保する必要があります。

• 構成内で指定しているストレージ クラスのストレージ プロビジョナーによって動的プロビジョニングがサポートされていない場合は、永続化ボリュームを事前に作成する必要があります。 たとえば、local-storage プロビジョナーでは動的プロビジョニングが有効になりません。 kubeadm を使用して展開された Kubernetes クラスター内での作業の進め方に関するガイダンスについては、このサンプル スクリプトを参照してください。

• ビッグ データ クラスターを展開するときに、クラスター内のすべてのコンポーネントで使用する、同一のストレージ クラスを構成できます。 ただし、運用環境での展開のベスト プラクティスとして、さまざまなコンポーネントでは、サイズやスループットに関してさまざまなワークロードに対応するために、異なるストレージ構成が必要になります。 コントローラーで指定されている既定のストレージ構成は、SQL Server マスター インスタンス、データセット、および記憶域プールごとに上書きできます。 この記事では、これを行う方法の例を示します。

• 記憶域プールのサイズ要件を計算するときは、HDFS の構成に使用されているレプリケーション係数を考慮する必要があります。 レプリケーション係数は、展開時にクラスター展開構成ファイルで構成できます。 開発テスト プロファイル (つまり、aks-dev-test または kubeadm-dev-test) の既定値は 2 で、運用環境のデプロイに推奨されるプロファイル (つまり kubeadm-prod) の既定値は 3 です。 ベスト プラクティスとして、3 以上の HDFS のレプリケーション係数を使用して、ビッグ データ クラスターの運用環境の展開を構成することをお勧めします。 レプリケーション係数の値は、記憶域プール内のインスタンスの数に影響します。少なくとも、レプリケーション係数の値と同じ数の記憶域プール インスタンスを展開する必要があります。 また、ストレージのサイズを適切に変更し、レプリケーション係数の値と同じ回数だけ HDFS でデータがレプリケートされるように構成する必要があります。 HDFS でのデータ レプリケーションの詳細については、こちらを参照してください。

• SQL Server 2019 CU1 リリースの時点で、BDC では、展開後にストレージ構成設定を更新するエクスペリエンスを使用できません。 この制約があるため、BDC 操作を使用して、展開後に各インスタンスの永続ボリューム要求のサイズ変更や、プールのスケーリングを行うことはできません。 そのため、ビッグ データ クラスターを展開する前に、ストレージのレイアウトを計画することが非常に重要です。 ただし、Kubernetes API を直接使用して永続ボリューム サイズを拡張することができます。 この場合、BDC メタデータは更新されず、構成クラスター メタデータのボリューム サイズに関する不整合が表示されます。

• Kubernetes にコンテナー化されたアプリケーションとして展開し、ステートフル セットや永続ストレージなどの機能を使用することにより、Kubernetes では、正常性の問題が発生した場合にポッドが再起動され、同じ永続ストレージに接続されるようになります。 ただし、ノードで障害が発生し、ポッドを別のノードで再起動する必要がある場合は、ストレージが障害ノードに対してローカルであると、使用できなくなるリスクが高くなります。 このリスクを減らすには、追加の冗長性を構成し、高可用性機能を有効にするか、リモート冗長ストレージを使用する必要があります。 ここでは、ビッグ データ クラスター内のさまざまなコンポーネントのストレージ オプションの概要について説明します。

ビッグ データ クラスターのストレージ設定を構成する

他のカスタマイズと同様に、bdc.json 構成ファイル内の各プールと control.json ファイル内のコントロール サービスに対して、展開時にクラスター構成ファイル内にストレージの設定を指定できます。 プールの仕様にストレージ構成設定がない場合は、SQL Server マスター (master リソース)、HDFS (storage-0 リソース)、データ プール コンポーネントなど、他のすべてのコンポーネントに対してコントロールのストレージ設定が使用されます。 次のコード サンプルは、仕様に含めることができるストレージ構成セクションを表しています。

    "storage": 
    {
      "data": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
    }

ビッグ データ クラスターの展開では、永続ストレージを使用して、さまざまなコンポーネントに関するデータ、メタデータ、およびログが格納されます。 展開の一部として作成された永続ボリューム要求のサイズをカスタマイズできます。 ベスト プラクティスとして、Retain 再要求ポリシーによってストレージ クラスを使用することをお勧めします。

ストレージの構成に関するセクションで、SQL Server ビッグ データ クラスターの展開に対するストレージ設定の構成方法の例をさらに紹介しています。

AKS のストレージ クラス

AKS には、対応する動的プロビジョナーを備えた 2 つの組み込みのストレージ クラスである default と managed-premium が付属しています。 そのうちどちらかを指定するか、または、独自のストレージ クラスを作成して、永続ストレージが有効になったビッグ データ クラスターを展開できます。 既定では、AKS の aks-dev-test に対する組み込みのクラスター構成ファイルは、default ストレージ クラスを使用する永続ストレージ構成を備えています。

kubeadm クラスターのストレージ クラス

kubeadm を使用して展開された Kubernetes クラスターには、組み込みのストレージ クラスはありません。 ローカル ストレージまたは推奨のストレージ プロビジョナーを使用して、独自のストレージ クラスと永続ボリュームを作成する必要があります。 その場合は、構成したストレージ クラスに className を設定します。

各プール用のストレージ構成をカスタマイズする

すべてのカスタマイズにおいて、使用する組み込みの構成ファイルのコピーを最初に作成しておく必要があります。 たとえば、次のコマンドでは、aks-dev-test 展開構成ファイルのコピーが custom という名前のサブディレクトリに作成されます。

azdata bdc config init --source aks-dev-test --target custom

このプロセスでは bdc.json と control.json の 2 つのファイルが作成されます。これらは、手動で編集するか azdata bdc config コマンドを使用することによってカスタマイズできます。 jsonpath および jsonpatch ライブラリを組み合わせて使用すると、構成ファイルを編集する手段を提供できます。

ストレージ クラス名および要求サイズを構成する

既定では、クラスター内にプロビジョニングされた各ポッドに対応する、プロビジョニングされた永続ボリューム要求のサイズは、10 ギガバイト (GB) です。 この値は、クラスターの展開前にカスタム構成ファイル内で実行しているワークロードに合わせて更新できます。

次の例では、control.json 内で永続ボリューム要求のサイズが 32 GB に更新されています。 プール レベルで上書きされない場合、この設定はすべてのプールに適用されます。

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.size=100Gi"

次の例は、control.json ファイルでのストレージ クラスの変更方法を示しています。

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.className=<yourStorageClassName>"

また、カスタム構成ファイルを手動で編集したり、次の例にあるように .json パッチを使用して Storage プールに対するストレージ クラスを変更したりするオプションもあります。

{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.resources.storage-0.spec",
      "value": {
        "type":"Storage",
        "replicas":2,
        "storage":{
            "data":{
                    "size": "100Gi",
                    "className": "myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    },
            "logs":{
                    "size":"32Gi",
                    "className":"myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    }
                }
            }
        }
    ]
}

パッチ ファイルを適用します。 azdata bdc config patch コマンドを使用して、.json パッチ ファイルでの変更を適用します。 次の例では、patch.json ファイルをターゲットの展開構成ファイルである custom.json に適用します。

azdata bdc config patch --config-file custom/bdc.json --patch-file ./patch.json

次のステップ

• Kubernetes でのボリュームに関する詳細なドキュメントについては、ボリュームに関する Kubernetes ドキュメントを参照してください。

• SQL Server ビッグ データ クラスターの展開の詳細については、「Kubernetes に SQL Server ビッグ データ クラスターを展開する方法」を参照してください。