高可用性を使用して 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 プラットフォームのビッグデータオプション」を参照してください。

SQL Server ビッグデータクラスターは、コンテナー化アプリケーションとして Kubernetes 上にあり、ステートフルセットや永続ストレージなどの機能を使用するため、このインフラストラクチャには、サービスの正常性を維持するためにクラスターコンポーネントで利用される、正常性監視、障害検出、およびフェールオーバーメカニズムが組み込まれています。信頼性を向上させるために、高可用性構成で追加のレプリカを使用して展開するように、SQL Server マスターインスタンス、HDFS 名前ノードと Spark 共有サービス、またはその両方を構成することもできます。監視、障害検出、および自動フェールオーバーは、ビッグデータクラスター管理サービス、つまり、制御サービスによって管理されます。このサービスでは、可用性グループのセットアップ、データベースミラーリングエンドポイントの構成から、可用性グループへのデータベースの追加またはフェールオーバーとアップグレードの調整まですべて、ユーザーの介入なしで提供されます。

次の図は、SQL Server ビッグデータクラスターに可用性グループが展開される方法を示しています。

high-availability-ag-bdc

可用性グループで有効になる機能の一部を以下に示します。

高可用性の設定が展開構成ファイルで指定されている場合は、containedag という名前の 1 つの可用性グループが作成されます。既定では、containedag に、プライマリを含む、3 つのレプリカがあります。可用性グループの CRUD 操作はすべて内部的に管理されます。これには、可用性グループの作成や作成された可用性グループへのレプリカの参加が含まれます。ビッグデータクラスターの SQL Server マスターインスタンスで、追加の可用性グループを作成することはできません。
データベースはすべて可用性グループに自動的に追加されます。これには、すべてのユーザーおよびシステムデータベース (master や msdb など) が含まれます。この機能により、可用性グループレプリカ全体で単一システムビューが提供されます。追加のモデルデータベース (model_replicatedmaster と model_msdb) は、システムデータベースのレプリケートされた部分をシード処理するために使用されます。これらのデータベースに加えて、インスタンスに直接接続している場合は、containedag_master および containedag_msdb データベースが表示されます。 containedag データベースは、可用性グループ内の master と msdb を表します。

重要

アタッチデータベースなどのワークフローの結果としてインスタンスに作成されたデータベースは、可用性グループに自動的に追加されることはありません。 SQL Server ビッグデータクラスター管理者はこれを手動で行う必要があります。 SQL Server インスタンスマスターデータベースに対して一時エンドポイントを有効にする方法を説明するには、「SQL Server インスタンスに接続する」を参照してください。 SQL Server 2019 CU2 より前のリリースでは、復元ステートメントの結果として作成されたデータベースも同じ動作を示し、データベースを包含可用性グループに手動で追加する必要がありました。
PolyBase 構成データベースは可用性グループには含まれません。これは、各レプリカに固有のインスタンスレベルのメタデータが含まれているためです。
外部エンドポイントは、可用性グループ内のデータベースへの接続用に自動的にプロビジョニングされます。このエンドポイント master-svc-external は、可用性グループリスナーの役割を果たします。
2 つ目の外部エンドポイントは、読み取りワークロードをスケールアウトするために、セカンダリレプリカへの読み取り専用接続用にプロビジョニングされます。

配置

可用性グループに SQL Server マスターを展開するには、次のようにします。

hadr 機能を有効にします
AG のレプリカの数を指定します (最小値は 3)
読み取り専用セカンダリレプリカへの接続用に作成された 2 番目の外部エンドポイントの詳細を構成します

aks-dev-test-ha または kubeadm-prod の組み込み構成プロファイルを使用して、ビッグデータクラスターのカスタマイズを開始できます。これらのプロファイルには、追加の高可用性を構成できるリソースに必要な設定が含まれます。たとえば、以下は、SQL Server マスターインスタンスの可用性グループの有効化に関連する、bdc.json 構成ファイルのセクションです。

{
  ...
    "spec": {
      "type": "Master",
      "replicas": 3,
      "endpoints": [
        {
          "name": "Master",
          "serviceType": "LoadBalancer",
          "port": 31433
        },
        {
          "name": "MasterSecondary",
          "serviceType": "LoadBalancer",
          "port": 31436
        }
      ],
      "settings": {
        "sql": {
          "hadr.enabled": "true"
        }
      }
    }
  ...
}

次の手順では、aks-dev-test-ha プロファイルから開始し、ビッグデータクラスターの展開構成をカスタマイズする方法の例について説明します。 kubeadm クラスターでの展開でも、同様の手順が適用されますが、endpoints セクションの serviceType には必ず NodePort を使用するようにしてください。

ターゲットとなるプロファイルを複製します

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

必要に応じて、カスタムプロファイルを任意で編集することもできます。
上記で作成されたクラスター構成プロファイルを使用して、クラスターの展開を開始します
```
azdata bdc create --config-profile custom-aks-ha --accept-eula yes
```

可用性グループ内の SQL Server データベースに接続する

SQL Server マスターに対して実行するワークロードの種類に応じて、読み取り/書き込みワークロードの場合はプライマリに、読み取り専用の種類のワークロードの場合はセカンダリレプリカ内のデータベースに接続できます。接続の種類ごとの概要を以下に示します。

プライマリレプリカのデータベースに接続する

プライマリレプリカへの接続では、sql-server-master エンドポイントを使用します。このエンドポイントは、AG のリスナーでもあります。このエンドポイントを使用する場合、すべての接続は可用性グループ内のデータベースのコンテキストにあります。たとえば、このエンドポイントを使用する既定の接続では、SQL Server インスタンスの master データベースではなく、可用性グループ内の master データベースに接続することになります。次のコマンドを実行して、エンドポイントを検索します。

azdata bdc endpoint list -e sql-server-master -o table

Description                           Endpoint             Name               Protocol
------------------------------------  -------------------  -----------------  ----------
SQL Server Master Instance Front-End  11.11.111.111,11111  sql-server-master  tds

Note

フェールオーバーイベントは、HDFS やデータプールなどのリモートデータソースからデータにアクセスする分散クエリの実行中に発生する可能性があります。ベストプラクティスとして、フェールオーバーによる切断が発生した場合に接続再試行ロジックを使用するように、アプリケーションを設計する必要があります。

セカンダリレプリカのデータベースに接続する

セカンダリレプリカのデータベースへの読み取り専用接続では、sql-server-master-readonly エンドポイントを使用します。このエンドポイントは、すべてのセカンダリレプリカにわたるロードバランサーのように機能します。このエンドポイントを使用する場合、すべての接続は可用性グループ内のデータベースのコンテキストにあります。たとえば、このエンドポイントを使用する既定の接続では、SQL Server インスタンスの master データベースではなく、可用性グループ内の master データベースに接続することになります。

azdata bdc endpoint list -e sql-server-master-readonly -o table

Description                                    Endpoint            Name                        Protocol
---------------------------------------------  ------------------  --------------------------  ----------
SQL Server Master Readable Secondary Replicas  11.11.111.11,11111  sql-server-master-readonly  tds

SQL Server インスタンスに接続する

サーバーレベルの構成を設定する、または可用性グループにデータベースを手動で追加するなどの特定の操作では、SQL Server インスタンスに接続する必要があります。 SQL Server 2019 CU2 よりも前のバージョンでは、sp_configure、RESTORE DATABASE、または任意の可用性グループの DDL などの操作には、この種類の接続が必要になります。既定では、ビッグデータクラスターにインスタンス接続を有効にするエンドポイントが含まれていないため、このエンドポイントを手動で公開する必要があります。

重要

SQL Server インスタンス接続用に公開されたエンドポイントでは、Active Directory が有効になっているクラスターであっても、サポートされるのは SQL 認証のみとなります。既定では、ビッグデータクラスターの展開中に、sa ログインが無効になり、AZDATA_USERNAME および AZDATA_PASSWORD 環境変数の展開時に指定された値に基づいて、新しい sysadmin ログインがプロビジョニングされます。

重要

含まれる可用性グループ DDL は BDC で排他的に自己管理されます。 (外部ユーザーが) 含まれる可用性またはデータベースミラーリングエンドポイントを削除することはできません。削除できても、BDC の状態が回復不可能になることがあります。

このエンドポイントを公開してから、復元ワークフローで作成されたデータベースを可用性グループに追加する方法の例を以下に示します。 sp_configure でサーバー構成を変更する場合は、SQL Server マスターインスタンスへの接続を設定するための同様の手順が適用されます。

Note

SQL Server 2019 CU2 以降では、復元ワークフローの結果として作成されたデータベースは自動的に包含可用性グループに追加されます。

sql-server-master エンドポイントに接続してプライマリレプリカをホストするポッドを特定して、以下を実行します。
```
SELECT @@SERVERNAME
```
新しい Kubernetes サービスを作成して外部エンドポイントを公開します

kubeadm クラスターの場合は、以下のコマンドを実行します。 podName を前の手順で返されたサーバーの名前に、serviceName を作成された Kubernetes サービスの優先名に、namespaceName* をビッグデータクラスターの名前に置き換えます。
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
```
aks クラスターを実行する場合も同じコマンドを実行しますが、作成されるサービスの種類は LoadBalancer となります。次に例を示します。
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
```
aks に対して実行されるこのコマンドの例を以下に示します。この場合、プライマリをホストしているポッドは master-0 となります。
```
kubectl -n mssql-cluster expose pod master-0 --port=1533  --name=master-sql-0 --type=LoadBalancer
```
作成された Kubernetes サービスの IP を取得します。
```
kubectl get services -n <namespaceName>
```

重要

ベストプラクティスとして、このコマンドを実行し、上記で作成された Kubernetes サービスを削除してクリーンアップする必要があります。

kubectl delete svc master-sql-0 -n mssql-cluster

可用性グループにデータベースを追加します。

データベースを AG に追加するには、データベースを完全復旧モードで実行する必要があり、ログバックアップを作成する必要があります。上記で作成された Kubernetes サービスの IP を使用して、SQL Server インスタンスに接続し、以下に示すように TSQL ステートメントを実行します。
```
ALTER DATABASE <databaseName> SET RECOVERY FULL;
BACKUP DATABASE <databaseName> TO DISK='<filePath>'
ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
```
以下の例では、インスタンスで復元された sales という名前のデータベースを追加します。
```
ALTER DATABASE sales SET RECOVERY FULL;
BACKUP DATABASE sales TO DISK='/var/opt/mssql/data/sales.bak'
ALTER AVAILABILITY GROUP containedag ADD DATABASE sales
```

既知の制限事項

ビッグデータクラスターの SQL Server マスターについて、含まれる可用性グループには次の既知の問題と制限事項があります。

ビッグデータクラスターが展開されるときに、高可用性構成が作成される必要があります。展開後に可用性グループで高可用性構成を有効にすることはできません。現時点では、同期コミットレプリカの構成のみが有効になります。

警告

クォーラムコミット内のいずれかのレプリカの同期モードを非同期コミットに更新すると、高可用性について無効な構成が生成されます。この構成での実行にはデータ損失のリスクが伴います。プライマリレプリカに影響を与える障害イベントが発生した場合にトリガーされる自動フェールオーバーが存在せず、ユーザーは手動フェールオーバーを発行する際にデータ損失のリスクを受け入れる必要があるためです。

別のサーバー上に作成されたバックアップから TDE 対応のデータベースを正常に復元するには、必須の証明書が、SQL Server インスタンスマスターと包含 AG マスターの両方に確実に復元されるようにする必要があります。証明書のバックアップと復元の方法の例については、こちらを参照してください。
sp_configure でのサーバー構成設定の実行などの特定の操作では、可用性グループ master ではなく、SQL Server インスタンス master データベースへの接続が必要になります。対応するプライマリエンドポイントを使用することはできません。指示に従ってエンドポイントを公開し、SQL Server インスタンスに接続して sp_configure を実行します。 SQL 認証を使用できるのは、エンドポイントを手動で公開して SQL Server インスタンス master データベースに接続する場合のみです。
包含 msdb データベースは可用性グループに含まれており、SQL Agent ジョブはレプリケートされますが、プライマリレプリカではジョブはスケジュールに従って実行されるのみです。
含まれている可用性グループに対するレプリケーション機能はサポートされていません。含まれている AG の一部である SQL Server インスタンスは、インスタンスレベルでも含まれている AG レベルでも、ディストリビューターまたはパブリッシャーとして機能することはできません。
データベースの作成中にファイルグループを追加することはサポートされていません。回避策として、まずデータベースを作成し、次に ALTER DATABASE ステートメントを実行してファイルグループを追加します。
SQL Server 2019 CU2 よりも前のバージョンでは、CREATE DATABASE および RESTORE DATABASE 以外のワークフロー (CREATE DATABASE FROM SNAPSHOT など) の結果として作成されたデータベースは、自動的に可用性グループに追加されません。インスタンスに接続し、データベースを可用性グループに手動で追加します。
Service Broker とデータベースメールは、高可用性を使用してデプロイされたビッグデータクラスターでは、現在サポートされていません。

次のステップ

ビッグデータクラスターの展開での構成ファイルの使用について詳しくは、「Kubernetes に SQL Server ビッグデータクラスターを展開する方法」を参照してください。
SQL Server の可用性グループの機能について詳しくは、「Overview of Always On Availability Groups (SQL Server)」 (Always On 可用性グループの概要 (SQL Server)) を参照してください。

次の方法で共有

高可用性を使用して SQL Server ビッグデータクラスターを展開する

配置

可用性グループ内の SQL Server データベースに接続する

プライマリレプリカのデータベースに接続する

セカンダリレプリカのデータベースに接続する

SQL Server インスタンスに接続する

既知の制限事項

次のステップ

フィードバック

その他のリソース

次の方法で共有

高可用性を使用して SQL Server ビッグ データ クラスターを展開する

配置

可用性グループ内の SQL Server データベースに接続する

プライマリ レプリカのデータベースに接続する

セカンダリ レプリカのデータベースに接続する

SQL Server インスタンスに接続する

既知の制限事項

次のステップ

フィードバック

その他のリソース

高可用性を使用して SQL Server ビッグデータクラスターを展開する

プライマリレプリカのデータベースに接続する

セカンダリレプリカのデータベースに接続する