Kubernetes 上に SQL Server ビッグ データ クラスターを展開する方法
適用対象:
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 クラスター上に docker コンテナーとして展開されます。 ここでは、セットアップと構成の手順の概要を説明します。
- 単一の VM、VM のクラスター、Azure Kubernetes Service (AKS)、Red Hat OpenShift、または Azure Red Hat OpenShift (ARO) で Kubernetes クラスターを設定します。
- クライアント コンピューター上にクラスター構成ツール Azure Data CLI (
azdata) をインストールする。 - Kubernetes クラスターに SQL Server ビッグ データ クラスターを展開する。
テスト済み構成
SQL Server ビッグ データ クラスターを展開するために検証されるさまざまな Kubernetes プラットフォームの完全な一覧については、「テスト済み構成」を参照してください。
SQL Server のエディション
| Edition | Notes |
|---|---|
| Enterprise Standard Developer |
ビッグ データ クラスターのエディションは、SQL Server マスター インスタンスのエディションによって決まります。 展開時に、Developer エディションが既定で展開されます。 エディションは、展開後に変更できます。 SQL Server マスター インスタンスの構成に関するページを参照してください。 |
Kubernetes
Kubernetes クラスターの設定
上記の前提条件を満たす Kubernetes クラスターを既にお持ちの場合は、展開の手順に直接進むことができます。 このセクションでは、Kubernetes の概念の基本的な理解を前提としています。 Kubernetes の詳細については、Kubernetes のドキュメントを参照してください。
次の方法で Kubernetes を展開できます。
| Kubernetes の展開先: | 説明 | Link |
|---|---|---|
| Azure Kubernetes Services (AKS) | Azure にあるマネージド Kubernetes コンテナー サービス。 | 手順 |
単一または複数のマシン (kubeadm) |
kubeadm を使用して物理または仮想マシン上に展開された Kubernetes クラスター |
手順 |
| Azure Red Hat OpenShift | Azure で実行されている OpenShift のマネージド オファリング。 | 手順 |
| Red Hat OpenShift | ハイブリッド クラウド、エンタープライズ Kubernetes アプリケーション プラットフォーム。 | 手順 |
ヒント
また、1 つの手順で AKS とビッグ データ クラスターの展開をスクリプト化することもできます。 詳細については、Python スクリプトまたは Azure Data Studio のノートブックにおいて、この操作を行う方法を確認してください。
Kubernetes の構成を確認する
クラスター構成を表示するには、kubectl コマンドを実行します。 Kubectl が正しいクラスター コンテキストを指していることを確認します。
kubectl config view
重要
kubeadm を使用してブートストラップしたマルチ ノード Kubernetes クラスターに展開する場合は、ビッグ データ クラスターの展開を開始する前に、展開の対象となっているすべての Kubernetes ノード間でクロックが同期されていることを確認します。 ビッグ データ クラスターには、時間の影響を受け、時計のずれが原因で不正な状態になる可能性があるさまざまなサービス用に、正常性プロパティが組み込まれています。
Kubernetes クラスターを構成したら、新しい SQL Server ビッグ データ クラスターの展開に進むことができます。 以前のリリースからアップグレードする場合は、「SQL Server ビッグ データ クラスターをアップグレードする方法」を参照してください。
ストレージを構成していることを確認する
ほとんどのビッグ データの場合、クラスターの展開のために永続ストレージを用意します。 この段階では、展開する前に、Kubernetes クラスターに永続ストレージを提供する方法を計画しておく必要があります。
- AKS で展開する場合、ストレージ セットアップは必要ありません。 AKS には、動的にプロビジョニングするためのストレージ クラスが組み込まれています。 ストレージクラス (
defaultまたはmanaged-premium) は、展開構成ファイルでカスタマイズできます。 組み込みプロファイルでは、defaultストレージ クラスが使用されます。 kubeadmを使用して展開した Kubernetes クラスターで展開する場合、望ましいスケールのクラスターのために十分なストレージがあることを確認し、使用できるように構成しておく必要があります。 ストレージの使用方法をカスタマイズする場合、続行前にそれを行ってください。 「Kubernetes 上の SQL Server ビッグ データ クラスターでのデータ永続化」を参照してください。
SQL Server 2019 のビッグ データ ツールをインストールする
SQL Server 2019 ビッグ データ クラスターを展開する前に、まず、ビッグ データ ツールをインストールします。
- Azure Data CLI (
azdata) kubectl- Azure Data Studio
- Azure Data Studio 用のデータ仮想化の拡張機能
- Azure CLI (AKS にデプロイする場合)
デプロイの概要
ほとんどのビッグ データ クラスター設定は、JSON 展開構成ファイルに定義されています。 AKS および kubeadm によって作成された Kubernetes クラスター用の既定の展開プロファイルを使用しても、セットアップ中に使用する独自の展開構成ファイルをカスタマイズしてもかまいません。 セキュリティ上の理由から、認証設定は環境変数を介して渡されます。
以降のセクションでは、ビッグ データ クラスターの展開を構成する方法と、一般的なカスタマイズの例について詳しく説明します。 また、たとえば VS Code のようなエディターを使用して、カスタムの展開構成ファイルをいつでも編集できます。
既定の構成
ビッグ データ クラスターの展開オプションは、JSON 構成ファイルに定義されています。 Azure Data CLI (azdata) に用意されている組み込みの展開プロファイルから、クラスター展開のカスタマイズを開始できます。
Note
ビッグ データ クラスターの展開に必要なコンテナー イメージは、Microsoft Container Registry (mcr.microsoft.com) の mssql/bdc リポジトリにホストされます。 既定では、これらの設定は、Azure Data CLI (azdata) に含まれる各展開プロファイルの control.json 構成ファイルに既に含まれています。 また、各リリースのコンテナー イメージ タグも、同じ構成ファイルにあらかじめ設定されています。 コンテナー イメージを独自のプライベート コンテナー レジストリにプルするか、コンテナー レジストリ/リポジトリの設定を変更する必要がある場合は、オフライン インストールに関する記事に記載されている手順に従ってください
次のコマンドを実行して、使用可能なテンプレートを確認します。
azdata bdc config list -o table
SQL Server 2019 CU5 では、次のテンプレートを使用できます。
| 展開プロファイル | Kubernetes 環境 |
|---|---|
aks-dev-test |
Azure Kubernetes Service (AKS) に SQL Server ビッグ データ クラスターを展開します |
aks-dev-test-ha |
Azure Kubernetes Service (AKS) に SQL Server ビッグ データ クラスターを展開します。 SQL Server マスターや HDFS の名前ノードなどのミッション クリティカルなサービスは、高可用性を実現するように構成されています。 |
aro-dev-test |
開発とテストのために、SQL Server ビッグ データ クラスターを Azure Red Hat OpenShift に展開します。 SQL Server 2019 CU 5 で導入されています。 |
aro-dev-test-ha |
開発とテストのために、高可用性を備えた SQL Server ビッグ データ クラスターを Red Hat OpenShift クラスターに展開します。 SQL Server 2019 CU 5 で導入されています。 |
kubeadm-dev-test |
1 つまたは複数の物理マシンまたは仮想マシンを使用して、kubeadm によって作成された Kubernetes クラスター上に SQL Server ビッグ データ クラスターを展開します。 |
kubeadm-prod |
1 つまたは複数の物理マシンまたは仮想マシンを使用して、kubeadm によって作成された Kubernetes クラスター上に SQL Server ビッグ データ クラスターを展開します。 ビッグ データ クラスター サービスを Active Directory と統合できるようにするには、このテンプレートを使用します。 SQL Server マスター インスタンスや HDFS 名前ノードなどのミッション クリティカルなサービスは、高可用性構成で展開されます。 |
openshift-dev-test |
開発とテストのために、SQL Server ビッグ データ クラスターを Red Hat OpenShift クラスターに展開します。 SQL Server 2019 CU 5 で導入されています。 |
openshift-prod |
高可用性を備えた SQL Server ビッグ データ クラスターを Red Hat OpenShift クラスターに展開します。 SQL Server 2019 CU 5 で導入されています。 |
azdata bdc create を実行することで、ビッグ データ クラスターを展開できます。 これにより、既定の構成の 1 つを選択するよう求めるメッセージが表示され、展開へと進みます。
初めて Azure Data CLI (azdata) を実行するときは、使用許諾契約書 (EULA) に同意するために --accept-eula=yes を含める必要があります。
azdata bdc create --accept-eula=yes
このシナリオでは、パスワードなど、既定の構成に含まれない設定をすべて入力するように求められます。
重要
ビッグ データ クラスターの既定の名前は mssql-cluster です。 -n パラメーターを使用して Kubernetes 名前空間を指定する任意の kubectl コマンドを実行するために、このことを知っておくことは重要です。
カスタム構成
実行する予定のワークロードに合わせて展開をカスタマイズすることもできます。 展開後にビッグ データ クラスター サービスのスケール (レプリカの数) またはストレージ設定を変更できないため、展開構成を慎重に計画して容量の問題を回避する必要があります。 展開をカスタマイズするには、次の手順に従います。
Kubernetes 環境に適合する標準の展開プロファイルの 1 つを使用して開始します。
azdata bdc config listコマンドを使用して、それらの一覧を表示できます。azdata bdc config list展開をカスタマイズするには、
azdata bdc config initコマンドを使用して、展開プロファイルのコピーを作成します。 たとえば、次のコマンドでは、aks-dev-test展開構成ファイルのコピーがcustomという名前のターゲット ディレクトリに作成されます。azdata bdc config init --source aks-dev-test --target customヒント
--targetには、--sourceパラメーターに基づいて、構成ファイルbdc.jsonおよびcontrol.jsonを含むディレクトリを指定します。展開構成プロファイルでの設定をカスタマイズするために、VS Code などの JSON ファイルの編集に適したツール上で、展開構成ファイルを編集できます。 スクリプト化されたオートメーションの場合、
azdata bdc configコマンドを使用してカスタムの展開プロファイルを編集することもできます。 たとえば、次のコマンドでは、カスタムの展開プロファイルを変更して、展開されたクラスターの名前を既定 (mssql-cluster) からtest-clusterに変えています。azdata bdc config replace --config-file custom/bdc.json --json-values "metadata.name=test-cluster"ヒント
また、
azdata create bdcコマンドに --name パラメータ―を使用して、展開時にクラスター名を渡すことも可能です。 コマンド内のパラメーターは、構成ファイルでの値よりも優先されます。JSON パスを検索するための便利なツールとして、JSONPath Online Evaluator があります。
キーと値のペアを渡すだけでなく、インライン JSON 値を指定したり、JSON パッチ ファイルを渡したりすることもできます。 詳細については、「ビッグ データ クラスターのリソースとサービスの展開設定を構成する」を参照してください。
カスタム構成ファイルを
azdata bdc createに渡します。 必須の環境変数を必ず設定することに注意してください。そうしないと、ターミナルから値の入力を求められます。azdata bdc create --config-profile custom --accept-eula yes
警告
展開プロファイルの control.json ファイルで、パラメーター imagePullPolicy を "Always" に設定する必要があります。
展開構成ファイルの構造の詳細については、展開構成ファイルのリファレンスに関するページを参照してください。 他の構成例については、「ビッグ データ クラスターの展開設定を構成する」を参照してください。
環境変数
次の環境変数は、展開構成ファイルに保存されないセキュリティ設定に使用されます。 資格情報以外の Docker 設定は、構成ファイル内で設定できることに注意してください。
| 環境変数 | 要件 | 説明 |
|---|---|---|
AZDATA_USERNAME |
必須 | SQL Server ビッグ データ クラスター管理者のユーザー名。 同じ名前の sysadmin ログインが SQL Server マスター インスタンス内に作成されます。 セキュリティのベスト プラクティスとして、sa アカウントは無効になっています。 SQL Server 2019 (15.x) CU 5 以降、基本認証で新しいクラスターを展開すると、ゲートウェイを含むすべてのエンドポイントで AZDATA_USERNAME と AZDATA_PASSWORD が使用されます。 CU 5 にアップグレードされるクラスターのエンドポイントでは、ゲートウェイ エンドポイントに接続するとき、ユーザー名として root が引き続き使用されます。 この変更は、Active Directory 認証による展開には適用されません。 このリリース ノートの「ゲートウェイ エンドポイント経由でサービスにアクセスするための資格情報」を参照してください。 |
AZDATA_PASSWORD |
必須 | 上記で作成したユーザー アカウントのパスワード。 SQL Server 2019 CU5 より前に展開されたクラスターでは、Knox ゲートウェイと HDFS のセキュリティ保護のために、root ユーザーに同じパスワードが使用されます。 |
ACCEPT_EULA |
Azure Data CLI (azdata) を初めて使用する場合は必須 |
"yes" に設定します。 環境変数として設定された場合、SQL Server と Azure Data CLI (azdata) の両方に EULA が適用されます。 環境変数として設定されない場合、Azure Data CLI (azdata) コマンドを初めて使用するときに、--accept-eula=yes を含めることができます。 |
DOCKER_USERNAME |
省略可能 | コンテナー イメージがプライベート リポジトリに格納されている場合に、それらにアクセスするためのユーザー名。 ビッグ データ クラスターの展開にプライベート Docker リポジトリを使用する方法の詳細については、オフライン展開に関するトピックを参照してください。 |
DOCKER_PASSWORD |
省略可能 | 上記のプライベート リポジトリにアクセスするためのパスワード。 |
これらの環境変数は、azdata bdc create を呼び出す前に設定される必要があります。 設定されていない変数がある場合は、入力を求められます。
次の例は、Linux (bash) と Windows (PowerShell) 用に環境変数を設定する方法を示しています。
export AZDATA_USERNAME=admin
export AZDATA_PASSWORD=<password>
export ACCEPT_EULA=yes
SET AZDATA_USERNAME=admin
SET AZDATA_PASSWORD=<password>
Note
SQL Server 2019 CU5 より前に展開されたクラスターでは、上記のパスワードを持つ Knox ゲートウェイの root ユーザーを使用する必要があります。 root は、この基本認証 (ユーザー名とパスワード) でサポートされている唯一のユーザーです。
SQL Server 2019 (15.x) CU 5 以降、基本認証で新しいクラスターを展開すると、ゲートウェイを含むすべてのエンドポイントで AZDATA_USERNAME と AZDATA_PASSWORD が使用されます。 CU 5 にアップグレードされるクラスターのエンドポイントでは、ゲートウェイ エンドポイントに接続するとき、ユーザー名として root が引き続き使用されます。 この変更は、Active Directory 認証による展開には適用されません。 このリリース ノートの「ゲートウェイ エンドポイント経由でサービスにアクセスするための資格情報」を参照してください。
基本認証を使用して SQL Server に接続するには、AZDATA_USERNAME および AZDATA_PASSWORD の環境変数と同じ値を使用します。
環境変数を設定したら、azdata bdc create を実行して展開をトリガーする必要があります。 この例では、上記で作成したクラスター構成プロファイルを使用します。
azdata bdc create --config-profile custom --accept-eula yes
次のガイドラインに注意してください。
- 特殊文字が含まれている場合は、必ずパスワードを二重引用符で囲みます。
AZDATA_PASSWORDは自由に設定できますが、必ずパスワードを十分に複雑にして、!、&、'文字は使用しないでください。 二重引用符の区切り記号は bash コマンドでしか機能しないことに注意してください。 AZDATA_USERNAMEログインは、セットアップ時に作成される SQL Server マスター インスタンス上でのシステム管理者です。 SQL Server のコンテナーを作成した後、そのコンテナーでecho $AZDATA_PASSWORDを実行すると、指定した環境変数AZDATA_PASSWORDが検索できるようになります。 セキュリティ上の理由から、ベスト プラクティスとしてパスワードを変更してください。
無人インストール
無人展開の場合は、必要なすべての環境変数を設定して、構成ファイルを使用し、--accept-eula yes パラメーターを指定して azdata bdc create コマンドを呼び出す必要があります。 前のセクションの例では、無人インストールに対応した構文を示しています。
展開を監視する
クラスターのブートストラップ中に、クライアントのコマンド ウィンドウに展開の状態が返されます。 展開プロセス中に、コントローラー ポッドを待機している一連のメッセージが表示されます。
Waiting for cluster controller to start.
15 から 30 分以内に、コントローラー ポッドが実行中になっていることが通知されるはずです。
Cluster controller endpoint is available at 11.111.111.11:30080.
Cluster control plane is ready.
重要
ビッグ データ クラスターのコンポーネントに対応するコンテナー イメージのダウンロードに必要な時間によって、展開全体に時間がかかる場合があります。 ただし、数時間もかかることはありません。 展開時に問題が発生した場合は、「SQL Server ビッグ データ クラスターの監視とトラブルシューティング」を参照してください。
展開が完了すると、出力に成功したことが通知されます。
Cluster deployed successfully.
ヒント
カスタム構成によって変更されない限り、展開されたビッグ データ クラスターの既定の名前は mssql-cluster になります。
エンドポイントを取得する
展開スクリプトが正常に完了したら、次の手順を使用して、ビッグ データ クラスターに対応する外部エンドポイントのアドレスを取得できます。
展開後、展開の標準出力から、または次の
kubectlコマンドの EXTERNAL-IP 出力を確認して、コントローラー エンドポイントの IP アドレスを検索します。kubectl get svc controller-svc-external -n <your-big-data-cluster-name>ヒント
展開中に既定の名前を変更しなかった場合、前のコマンドにある
-n mssql-clusterを使用します。mssql-clusterは、ビッグ データ クラスターの既定の名前です。azdata login を使用して、ビッグ データ クラスターにログインします。
--endpointパラメーターをコントローラー エンドポイントの外部 IP アドレスに設定します。azdata login --endpoint https://<ip-address-of-controller-svc-external>:30080 --username <user-name>展開中にビッグ データ クラスター管理者 (AZDATA_USERNAME と AZDATA_PASSWORD) に対して構成したユーザー名とパスワードを指定します。
ヒント
Kubernetes クラスター管理者であり、クラスター構成ファイル (Kube 構成ファイル) にアクセスできる場合は、対象の Kubernetes クラスターを指すように現在のコンテキストを構成できます。 この場合は、
azdata login -n <namespaceName>を使用してログインできます。ここで、namespaceはビッグ データ クラスター名です。 ログイン コマンド内で指定されていない場合は、資格情報の入力を求められます。azdata bdc endpoint list を実行して、各エンドポイントの説明とそれに対応する IP アドレスおよびポート値を示した一覧を取得します。
azdata bdc endpoint list -o table次の一覧は、このコマンドからの出力例を示しています。
Description Endpoint Ip Name Port Protocol ------------------------------------------------------ --------------------------------------------------------- -------------- ----------------- ------ ---------- Gateway to access HDFS files, Spark https://11.111.111.111:30443 11.111.111.111 gateway 30443 https Spark Jobs Management and Monitoring Dashboard https://11.111.111.111:30443/gateway/default/sparkhistory 11.111.111.111 spark-history 30443 https Spark Diagnostics and Monitoring Dashboard https://11.111.111.111:30443/gateway/default/yarn 11.111.111.111 yarn-ui 30443 https Application Proxy https://11.111.111.111:30778 11.111.111.111 app-proxy 30778 https Management Proxy https://11.111.111.111:30777 11.111.111.111 mgmtproxy 30777 https Log Search Dashboard https://11.111.111.111:30777/kibana 11.111.111.111 logsui 30777 https Metrics Dashboard https://11.111.111.111:30777/grafana 11.111.111.111 metricsui 30777 https Cluster Management Service https://11.111.111.111:30080 11.111.111.111 controller 30080 https SQL Server Master Instance Front-End 11.111.111.111,31433 11.111.111.111 sql-server-master 31433 tcp HDFS File System Proxy https://11.111.111.111:30443/gateway/default/webhdfs/v1 11.111.111.111 webhdfs 30443 https Proxy for running Spark statements, jobs, applications https://11.111.111.111:30443/gateway/default/livy/v1 11.111.111.111 livy 30443 https
次の kubectl コマンドを実行して、クラスターに展開されたすべてのサービス エンドポイントを取得することもできます。
kubectl get svc -n <your-big-data-cluster-name>
クラスターの状態を確認する
展開後に、azdata bdc status show コマンドを使用して、クラスターの状態を確認できます。
azdata bdc status show
ヒント
status コマンドを実行するには、最初に、前述のエンドポイントのセクションに示した azdata login コマンドを使ってログインする必要があります。
このコマンドからの出力例を、次に示します。
Bdc: ready Health Status: healthy
===========================================================================================================================================================================================================================================
Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Servicename State Healthstatus Details
sql ready healthy -
hdfs ready healthy -
spark ready healthy -
control ready healthy -
gateway ready healthy -
app ready healthy -
Sql Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
master ready healthy StatefulSet master is healthy
compute-0 ready healthy StatefulSet compute-0 is healthy
data-0 ready healthy StatefulSet data-0 is healthy
storage-0 ready healthy StatefulSet storage-0 is healthy
Hdfs Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
nmnode-0 ready healthy StatefulSet nmnode-0 is healthy
storage-0 ready healthy StatefulSet storage-0 is healthy
sparkhead ready healthy StatefulSet sparkhead is healthy
Spark Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
sparkhead ready healthy StatefulSet sparkhead is healthy
storage-0 ready healthy StatefulSet storage-0 is healthy
Control Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
controldb ready healthy -
control ready healthy -
metricsdc ready healthy DaemonSet metricsdc is healthy
metricsui ready healthy ReplicaSet metricsui is healthy
metricsdb ready healthy StatefulSet metricsdb is healthy
logsui ready healthy ReplicaSet logsui is healthy
logsdb ready healthy StatefulSet logsdb is healthy
mgmtproxy ready healthy ReplicaSet mgmtproxy is healthy
Gateway Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
gateway ready healthy StatefulSet gateway is healthy
App Services: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
appproxy ready healthy ReplicaSet appproxy is healthy
次のコマンドを使用してさらに詳しい状態を取得することもできます。
- azdata bdc control status show では、コントロール管理サービスに関連付けられているすべてのコンポーネントの正常性状態が返されます
azdata bdc control status show
サンプル出力:
Control: ready Health Status: healthy
===========================================================================================================================================================================================================================================
Resources: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
controldb ready healthy -
control ready healthy -
metricsdc ready healthy DaemonSet metricsdc is healthy
metricsui ready healthy ReplicaSet metricsui is healthy
metricsdb ready healthy StatefulSet metricsdb is healthy
logsui ready healthy ReplicaSet logsui is healthy
logsdb ready healthy StatefulSet logsdb is healthy
mgmtproxy ready healthy ReplicaSet mgmtproxy is healthy
azdata bdc sql status showでは、SQL Server サービスを持つすべてのリソースの正常性状態が返されます
azdata bdc sql status show
サンプル出力:
Sql: ready Health Status: healthy
===========================================================================================================================================================================================================================================
Resources: ready Health Status: healthy
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resourcename State Healthstatus Details
master ready healthy StatefulSet master is healthy
compute-0 ready healthy StatefulSet compute-0 is healthy
data-0 ready healthy StatefulSet data-0 is healthy
storage-0 ready healthy StatefulSet storage-0 is healthy
重要
--all パラメーターを使用する場合、これらのコマンドからの出力には、より詳細な分析のための Kibana および Grafana ダッシュボードへの URL が含まれています。
Azure Data CLI (azdata) を使用するほかに、Azure Data Studio を利用してエンドポイントと状態情報の両方を検索することもできます。 Azure Data CLI (azdata) および Azure Data Studio を利用したクラスターの状態の表示に関する詳細については、「ビッグ データ クラスターの状態を表示する方法」を参照してください。
クラスターに接続する
ビッグ データ クラスターに接続する方法の詳細については、「Azure Data Studio を利用して SQL Server ビッグ データ クラスターに接続する」を参照してください。
次のステップ
SQL Server ビッグ データ クラスターの展開に関する詳細については、次の資料を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示