次の方法で共有

SQL Server ビッグ データ クラスター Kubernetes のトラブルシューティング

  • [アーティクル]

適用対象: 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 2019 ビッグ データ クラスターの監視とトラブルシューティングに使用できる、いくつかの便利な Kubernetes コマンドについて説明します。 ビッグ データ クラスター内に存在するポッドまたは他の Kubernetes アーティファクトの詳細を表示する方法を示します。 この記事では、SQL Server ビッグ データ クラスター サービスのいずれかが実行されているコンテナーとの間でのファイルのコピーなど、一般的なタスクについても説明します。

ヒント

ビッグ データ クラスターのコンポーネントの状態を監視するには、azdata bdc status のコマンドを使用するか、Azure Data Studio に組み込まれているトラブルシューティングのノートブックを使用します。

ヒント

Windows (cmd または PS) または Linux (bash) のクライアント コンピューターで、次の kubectl コマンドを実行します。 それらには、クラスターでの以前の認証と、実行対象のクラスター コンテキストが必要です。 たとえば、以前に作成された AKS クラスターでは、az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name> を実行して Kubernetes クラスター構成ファイルをダウンロードし、クラスター コンテキストを設定できます。

ポッドの状態を取得する

kubectl get pods コマンドを使用して、クラスター内のすべての名前空間またはビッグ データ クラスターの名前空間のポッドの状態を取得できます。 次のセクションでは、両方の例を示します。

Kubernetes クラスター内のすべてのポッドの状態を表示する

すべてのポッドとその状態を取得するには、次のコマンドを実行します。これには、SQL Server ビッグ データ クラスターのポッドが作成された名前空間の一部であるポッドも含まれます。

kubectl get pods --all-namespaces

SQL Server ビッグ データ クラスター内のすべてのポッドの状態を表示する

特定の名前空間を指定するには、-n パラメーターを使います。 SQL Server ビッグ データ クラスターのポッドは、展開構成ファイルで指定されているクラスター名に基づいて、クラスターのブートストラップ時に作成される新しい名前空間に作成されることに注意してください。 ここでは、既定の名前 mssql-cluster を使います。

kubectl get pods -n mssql-cluster

実行されているビッグ データ クラスターについて、次のような出力が表示されます。

PS C:\> kubectl get pods -n mssql-cluster
NAME              READY   STATUS    RESTARTS   AGE
appproxy-f2qqt    2/2     Running   0          110m
compute-0-0       3/3     Running   0          110m
control-zlncl     4/4     Running   0          118m
data-0-0          3/3     Running   0          110m
data-0-1          3/3     Running   0          110m
gateway-0         2/2     Running   0          109m
logsdb-0          1/1     Running   0          112m
logsui-jtdnv      1/1     Running   0          112m
master-0          7/7     Running   0          110m
metricsdb-0       1/1     Running   0          112m
metricsdc-shv2f   1/1     Running   0          112m
metricsui-9bcj7   1/1     Running   0          112m
mgmtproxy-x6gcs   2/2     Running   0          112m
nmnode-0-0        1/1     Running   0          110m
storage-0-0       7/7     Running   0          110m
storage-0-1       7/7     Running   0          110m

Note

展開が行われている間、 [STATUS] が [ContainerCreating] のポッドはまだ起動中です。 何らかの理由で展開がハングする場合、これにより問題がある可能性のある場所についての情報が得られることがあります。 また、 [READY] 列も確認してください。 これにより、ポッドで開始されたコンテナーの数がわかります。 構成とネットワークによっては、展開に 30 分以上かかる場合があることに注意してください。 この時間の多くは、さまざまなコンポーネントのコンテナー イメージのダウンロードに費やされます。

ポッドの詳細を取得する

特定のポッドの詳細な説明を JSON 形式の出力で取得するには、次のコマンドを実行します。 これには、ポッドが現在配置されている Kubernetes ノード、ポッド内で実行されているコンテナー、コンテナーのブートストラップに使われたイメージなどの詳細が含まれます。 また、ポッドに関連付けられているラベル、状態、永続化ボリューム要求など、その他の詳細も表示されます。

kubectl describe pod  <pod_name> -n <namespace_name>

次の例では、mssql-cluster という名前のビッグ データ クラスター内の master-0 ポッドの詳細が示されます。

kubectl describe pod  master-0 -n mssql-cluster

何らかのエラーが発生した場合、ポッドに対する最近のイベントでエラーを確認できることがあります。

ポッドのログを取得する

ポッドで実行されているコンテナーのログを取得できます。 次のコマンドでは、master-0 という名前のポッドで実行されているすべてのコンテナーのログが取得されて、ファイル名 master-0-pod-logs.txt に出力されます。

kubectl logs master-0 --all-containers=true -n mssql-cluster > master-0-pod-logs.txt

サービスの状態を取得する

ビッグ データ クラスター サービスの詳細を取得するには、次のコマンドを実行します。 これらの詳細には、それらの種類と、それぞれのサービスおよびポートに関連付けられている IP アドレスが含まれます。 SQL Server ビッグ データ クラスターのサービスは、展開構成ファイルで指定されているクラスター名に基づいて、クラスターのブートストラップ時に作成される新しい名前空間に作成されることに注意してください。

kubectl get svc -n <namespace_name>

次の例では、mssql-cluster という名前のビッグ データ クラスター内のサービスの詳細が示されます。

kubectl get svc -n mssql-cluster

次のサービスでは、ビッグ データ クラスターへの外部接続がサポートされています。

サービス 説明
master-svc-external マスター インスタンスへのアクセスが提供されます。
(EXTERNAL-IP,31433 および SA ユーザー)
controller-svc-external クラスターを管理するツールとクライアントがサポートされます。
gateway-svc-external HDFS/Spark ゲートウェイへのアクセスが提供されます。
(EXTERNAL-IP および <AZDATA_USERNAME> ユーザー)1
appproxy-svc-external アプリケーション展開シナリオがサポートされます。

1 SQL Server 2019 (15.x) CU 5 以降、基本認証で新しいクラスターを展開すると、ゲートウェイを含むすべてのエンドポイントで AZDATA_USERNAME と AZDATA_PASSWORD が使用されます。 CU 5 にアップグレードされるクラスターのエンドポイントでは、ゲートウェイ エンドポイントに接続するとき、ユーザー名として root が引き続き使用されます。 この変更は、Active Directory 認証による展開には適用されません。 このリリース ノートの「ゲートウェイ エンドポイント経由でサービスにアクセスするための資格情報」を参照してください。

ヒント

これは kubectl を使ってサービスを表示する方法ですが、azdata bdc endpoint list コマンドを使ってこれらのエンドポイントを表示することもできます。 詳しくは、ビッグ データ クラスターのエンドポイントの取得に関する記事をご覧ください。

サービスの詳細を取得する

サービスの詳細な説明を JSON 形式の出力で取得するには、このコマンドを実行します。 それには、ラベル、セレクター、IP アドレス、外部 IP アドレス (サービスの種類が LoadBalancer の場合)、ポートなどの詳細が含まれます。

kubectl describe service <service_name> -n <namespace_name>

次の例では、master-svc-external サービスの詳細が取得されます。

kubectl describe service master-svc-external -n mssql-cluster

ファイルのコピー

コンテナーからローカル コンピューターにファイルをコピーする必要がある場合は、次の構文で kubectl cp コマンドを使います。

kubectl cp <pod_name>:<source_file_path> -c <container_name> -n <namespace_name> <target_local_file_path>

同様に、kubectl cp を使って、ローカル コンピューターから特定のコンテナーにファイルをコピーすることもできます。

kubectl cp <source_local_file_path> <pod_name>:<target_container_path> -c <container_name>  -n <namespace_name>

コンテナーからファイルをコピーする

次の例では、SQL Server のログ ファイルが、コンテナーからローカル コンピューター上の ~/temp/sqlserverlogs パスにコピーされます (この例では、ローカル コンピューターは Linux クライアントです)。

kubectl cp master-0:/var/opt/mssql/log -c mssql-server -n mssql-cluster ~/tmp/sqlserverlogs

コンテナーにファイルをコピーする

次の例では、AdventureWorks2022 ファイルが、ローカル コンピューターから master-0 ポッド内の SQL Server マスター インスタンス コンテナー (mssql-server) にコピーされます。 ファイルは、コンテナー内の /tmp ディレクトリにコピーされます。

kubectl cp ~/Downloads/AdventureWorks2022.bak master-0:/tmp -c mssql-server -n mssql-cluster

ポッドを強制的に削除する

ポッドを強制的に削除することはお勧めしません。 ただし、可用性、回復性、またはデータの永続性をテストする場合は、kubectl delete pods コマンドでポッドを削除してポッドの障害をシミュレートできます。

kubectl delete pods <pod_name> -n <namespace_name> --grace-period=0 --force

次の例では、記憶域プールのポッド storage-0-0 が削除されます。

kubectl delete pods storage-0-0 -n mssql-cluster --grace-period=0 --force

ポッドの IP アドレスを取得する

トラブルシューティングのために、ポッドが現在実行されているノードの IP アドレスを取得することが必要になる場合があります。 IP アドレスを取得するには、次の構文で kubectl get pods コマンドを使います。

kubectl get pods <pod_name> -o yaml -n <namespace_name> | grep hostIP

次の例では、master-0 ポッドが実行されているノードの IP アドレスが取得されます。

kubectl get pods master-0 -o yaml -n mssql-cluster | grep hostIP

Kubernetes ダッシュボード

Kubernetes ダッシュボードを起動して、クラスターに関する追加情報を確認できます。 以下のセクションでは、AKS 上の Kubernetes および kubeadm を使ってブートストラップされた Kubernetes のダッシュボードを起動する方法について説明します。

クラスターが AKS で実行されているときにダッシュボードを開始する

Kubernetes ダッシュボードを起動するには、以下を実行します。

az aks browse --resource-group <azure_resource_group> --name <aks_cluster_name>

Note

Unable to listen on port 8001: All listeners failed to create with the following errors: Unable to create listener: Error listen tcp4 127.0.0.1:8001: >bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. Unable to create listener: Error listen tcp6: address [[::1]]:8001: missing port in >address error: Unable to listen on any of the requested ports: [{8001 9090}] というエラーが表示された場合、別のウィンドウでダッシュボードを起動しなかったことを確認してください。

ブラウザーでダッシュボードを起動すると、AKS クラスターで RBAC が既定で有効になっていて、ダッシュボードで使用されるサービス アカウントにすべてのリソースにアクセスするための十分なアクセス許可がないため、アクセス許可の警告が表示される場合があります (たとえば、pods is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list pods in the namespace "default" (ポッドは禁止されています: ユーザー "system:serviceaccount:kube-system:kubernetes-dashboard" は名前空間 "default" 内のポッドをリストできません))。 次のコマンドを実行して kubernetes-dashboard に必要なアクセス許可を付与した後、ダッシュボードを再起動します。

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

kubeadm を使用して Kubernetes クラスターがブートストラップされたときにダッシュボードを開始する

Kubernetes クラスターでダッシュボードを展開して構成する方法の詳細については、Kubernetes のドキュメントを参照してください。 Kubernetes ダッシュボードを起動するには、次のコマンドを実行します。

kubectl proxy

次のステップ

ビッグ データ クラスターの詳細については、SQL Server ビッグ データ クラスター とはの概要に関するページを参照してください。