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

[アーティクル]
03/21/2023

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

重要

Microsoft SQL Server 2019 ビッグデータクラスターのアドオンは廃止されます。 SQL Server 2019 ビッグデータクラスターのサポートは、2025 年 2 月 28 日に終了します。ソフトウェアアシュアランス付きの SQL Server 2019 を使用する既存の全ユーザーはプラットフォームで完全にサポートされ、ソフトウェアはその時点まで SQL Server の累積更新プログラムによって引き続きメンテナンスされます。詳細については、お知らせのブログ記事と「Microsoft SQL Server プラットフォームのビッグデータオプション」を参照してください。

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

重要

マネージド Kubernetes サービス (AKS または ARO) のいずれかを使用して Azure にビッグデータクラスターをデプロイする場合は、アプリケーションのワークロード要件に応じた制限があり、対応が必要になる可能性があることに注意してください。たとえば、Azure マネージドディスクを使用するボリュームは、現在、ゾーン冗長リソースではありません。ボリュームをゾーン間で接続することはできず、ターゲットポッドをホストする特定のノードと同じゾーンに併置する必要があります。このような場合は、SQL Server ビッグデータクラスターで利用できる追加の高可用性ソリューションを使用することをお勧めします。 Azure Kubernetes サービスと可用性ゾーンの詳細については、こちらを参照してください。

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

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

リソース	データのストレージの種類	ログのストレージの種類	Notes
SQL Server マスターインスタンス	ローカル (レプリカ > = 3) またはリモート冗長ストレージ (レプリカ = 1)	ローカルストレージ	ステートフルセットベースの実装であり、この場合、ノードに対して維持されるポッドの再起動が確実に行われ、一時的なエラーによってデータ損失が発生しません。
計算プール	ローカルストレージ	ローカルストレージ	ユーザーデータが格納されていません。
データプール	ローカル/リモート冗長ストレージ	ローカルストレージ	データプールを他のデータソースから再構築できない場合は、リモート冗長ストレージを使用します。
記憶域プール (HDFS)	ローカル/リモート冗長ストレージ	ローカルストレージ	HDFS レプリケーションが有効になっている場合。
Spark プール	ローカルストレージ	ローカルストレージ	ユーザーデータが格納されていません。
コントロール (controldb、metricsdb、logsdb)	リモート冗長ストレージ	ローカルストレージ	ビッグデータクラスターのメタデータにストレージレベルの冗長性を使用することが重要です。

重要

制御関連コンポーネントがリモート冗長ストレージデバイス上にあることを確認してください。 controldb-0 ポッドは、クラスターサービスの状態、さまざまな設定、その他の関連情報に関するすべてのメタデータを格納するデータベースを使用して、SQL Server インスタンスをホストします。このインスタンスが使用できなくなると、クラスター内の他の依存サービスに正常性の問題が生じます。

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

他のカスタマイズと同様に、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 ストレージクラスを使用する永続ストレージ構成を備えています。

警告

組み込みのストレージクラスである default および managed-premium によって作成された永続ボリュームには、Delete の再要求ポリシーが用意されています。そのため、SQL Server ビッグデータクラスターを削除すると、永続ボリューム要求は、永続ボリュームと同様に削除されます。ストレージの概念に関する記事に示すように、Retain 再要求ポリシーによって azure-disk プロビジョナーを使用して、カスタムストレージクラスを作成できます。

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

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

重要

kubeadm 用の組み込みの展開構成ファイル (kubeadm-dev-test または kubeadm-prod) では、データおよびログのストレージ用のストレージクラス名は指定されていません。展開の前に、構成ファイルをカスタマイズして className に値を設定する必要があります。そうしないと、展開前の検証でエラーになります。また、展開には、ストレージクラスの存在について確認する検証手順が含まれますが、必要な永続ボリュームについては含まれません。クラスターのスケールに応じた十分なボリュームを確実に作成しておく必要があります。既定の最小クラスターサイズ (既定のスケール、高可用性なし) では、少なくとも 24 個の永続ボリュームを作成する必要があります。ローカルプロビジョナーを利用した永続ボリュームの作成方法を示す例については、Kubeadm を使用した Kubernetes クラスターの作成に関する記事を参照してください。

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

すべてのカスタマイズにおいて、使用する組み込みの構成ファイルのコピーを最初に作成しておく必要があります。たとえば、次のコマンドでは、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 ビッグデータクラスターを展開する方法」を参照してください。

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

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

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

AKS のストレージクラス

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

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

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

次のステップ

フィードバック

フィードバック

その他のリソース

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

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

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

AKS のストレージ クラス

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

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

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

次のステップ

フィードバック

フィードバック

その他のリソース

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

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

AKS のストレージクラス

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

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