Behandeln von Problemen eines Big Data-Clusters für SQL Server mit Kubernetes

Gilt für: SQL Server 2019 (15.x)

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

In diesem Artikel werden verschiedene nützliche Kubernetes-Befehle beschrieben, die Sie zum Überwachen und Behandeln von Problemen eines Big Data-Clusters für SQL Server 2019 verwenden können. Sie erfahren zudem, wie Sie ausführliche Informationen zu einem Pod oder anderen Kubernetes-Artefakten erhalten, die sich im Big-Data-Cluster befinden. In diesem Artikel werden auch allgemeine Aufgaben behandelt, z. B. das Kopieren in oder aus einem Container, der einen der folgenden Big-Data-Clusterdienste für SQL Server ausführt.

Tipp

Für die Überwachung des Status von Big Data-Clusterkomponenten können Sie azdata bdc status-Befehle oder die integrierten Notebooks zur Problembehandlung verwenden, die mit Azure Data Studio bereitgestellt werden.

Tipp

Führen Sie die folgenden kubectl-Befehle auf einem Windows- (cmd oder PS) oder einem Linux-(bash)-Clientcomputer aus. Diese müssen zuvor im Cluster authentifiziert und für einen Clusterkontext ausgeführt werden. Für einen zuvor erstellten AKS-Cluster können Sie beispielsweise az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name> ausführen, um die Konfigurationsdatei des Kubernetes-Clusters herunterzuladen und den Clusterkontext festzulegen.

Abrufen der Status von Pods

Mithilfe des kubectl get pods-Befehls können Sie die Status von Pods im Cluster entweder für alle Namespaces oder für den Namespace des Big-Data-Clusters abrufen. Die folgenden Abschnitte umfassen Beispiele für beide Möglichkeiten.

Anzeigen der Status aller Pods im Kubernetes-Cluster

Führen Sie den folgenden Befehl aus, um alle Pods und deren Status abzurufen. Dies umfasst auch alle Pods, die Teil des Namespaces sind, in dem Big-Data-Clusterpods für SQL Server erstellt werden:

kubectl get pods --all-namespaces

Anzeigen aller Pods im Big-Data-Cluster für SQL Server

Verwenden Sie den -n-Parameter, um einen bestimmten Namespace anzugeben. Beachten Sie, dass Big-Data-Clusterpods für SQL Server in einem neuen Namespace erstellt werden, der zur Clusterbootstrapzeit basierend auf dem in der Konfigurationsdatei der Bereitstellung angegebenen Clusternamen erstellt wird. Der Standardname mssql-cluster wird hier verwendet.

kubectl get pods -n mssql-cluster

Ihnen sollte eine Ausgabe ähnlich der folgenden Liste für einen ausgeführten Big-Data-Cluster angezeigt werden:

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

Hinweis

Während der Bereitstellung werden Pods mit dem STATUSContainerCreating immer noch angezeigt. Wenn die Bereitstellung aus irgendeinem Grund hängt, erhalten Sie dadurch möglicherweise einen Eindruck von dem bestehenden Problem. Sehen Sie sich auch die Spalte READY (Bereit) an. Diese zeigt an, wie viele Container im Pod gestartet wurden. Beachten Sie, dass Bereitstellungen je nach Konfiguration und Netzwerk 30 Minuten oder länger dauern können. Ein Großteil dieser Zeit wird für das Herunterladen der Containerimages für verschiedene Komponenten aufgewendet.

Abrufen von Poddetails

Führen Sie den folgenden Befehl aus, um eine ausführliche Beschreibung eines bestimmten Pods in einer Ausgabe im JSON-Format zu erhalten. Sie enthält ausführliche Informationen wie den aktuellen Kubernetes-Knoten, auf dem der Pod platziert wurde, die im Pod ausgeführten Container sowie das zum Starten der Container verwendete Image. Zudem werden weitere Informationen wie Bezeichnungen, Status und persistierte Volumeansprüche angezeigt, die dem Pod zugeordnet sind.

kubectl describe pod  <pod_name> -n <namespace_name>

Im folgenden Beispiel werden die ausführlichen Informationen zum Pod master-0 in einem Big-Data-Cluster mit dem Namen mssql-cluster angezeigt:

kubectl describe pod  master-0 -n mssql-cluster

Wenn ein Fehler aufgetreten ist, wird Ihnen dieser manchmal unter den aktuellen Ereignissen des Pods angezeigt.

Abrufen von Podprotokollen

Sie können die Protokolle für Container abrufen, die in einem Pod ausgeführt werden. Der folgende Befehl ruft die Protokolle für alle Container im Pod master-0 ab und gibt sie in einer Datei mit dem Namen master-0-pod-logs.txt aus:

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

Abrufen des Status von Diensten

Führen Sie den folgenden Befehl aus, um ausführliche Informationen zu den Big-Data-Clusterdiensten abzurufen. Diese Informationen umfassen den Typ und die IP-Adressen, die den entsprechenden Diensten und Ports zugeordnet sind. Beachten Sie, dass Big-Data-Clusterdienste für SQL Server in einem neuen Namespace erstellt werden, der zur Clusterbootstrapzeit basierend auf dem in der Konfigurationsdatei der Bereitstellung angegebenen Clusternamen erstellt wird.

kubectl get svc -n <namespace_name>

Im folgenden Beispiel werden die Status der Dienste in einem Big-Data-Cluster mit dem Namen mssql-cluster angezeigt:

kubectl get svc -n mssql-cluster

Die folgenden Dienste unterstützen externe Verbindungen mit dem Big-Data-Cluster:

Dienst BESCHREIBUNG
master-svc-external Bietet Zugriff auf die Masterinstanz.
(EXTERNAL-IP,31433 und der SA-Benutzer)
controller-svc-external Unterstützt Tools und Clients, die den Cluster verwalten.
gateway-svc-external Bietet Zugriff auf das HDFS/Spark-Gateway.
(EXTERNAL-IP und der Benutzer <AZDATA_USERNAME>)1
appproxy-svc-external Unterstützt Anwendungsbereitstellungsszenarios.

1 Beginnend mit SQL Server 2019 (15.x) CU 5 verwenden alle Endpunkte einschließlich Gateway AZDATA_USERNAME und AZDATA_PASSWORD, wenn Sie einen neuen Cluster mit Standardauthentifizierung bereitstellen. Endpunkte auf Clustern, die ein Upgrade auf CU 5 erhalten, verwenden weiterhin root als Nutzername für die Verbindung mit dem Gatewayendpunkt. Diese Änderung gilt nicht für Bereitstellungen, die die Active Directory-Authentifizierung verwenden. Weitere Informationen finden Sie unter Anmeldeinformationen für den Zugriff auf Dienste über den Gatewayendpunkt in den Versionshinweisen.

Tipp

Dies ist eine Möglichkeit zur Anzeige der Dienste mit kubectl, es ist jedoch auch möglich, den Befehl azdata bdc endpoint list zur Anzeige dieser Endpunkte zu verwenden. Weitere Informationen finden Sie unter Get big data cluster endpoints (Abrufen der Endpunkte eines Big-Data-Clusters).

Abrufen von Dienstdetails

Führen Sie den folgenden Befehl aus, um eine ausführliche Beschreibung eines Diensts in einer Ausgabe im JSON-Format zu erhalten. Diese wird ausführliche Informationen wie Bezeichnungen, Selektoren, IP-Adressen, externe IP-Adressen (falls es sich bei dem Dienst um einen Dienst vom Typ LoadBalancer handelt), Ports usw. umfassen.

kubectl describe service <service_name> -n <namespace_name>

Im folgenden Beispiel werden ausführliche Informationen zum Dienst master-svc-external abgerufen:

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

Kopieren von Dateien

Wenn Sie Dateien aus dem Container auf Ihren lokalen Computer kopieren müssen, verwenden Sie den Befehl kubectl cp mit der folgenden Syntax:

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

Auf ähnliche Weise können Sie kubectl cp verwenden, um Dateien vom lokalen Computer in einen bestimmten Container zu kopieren.

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

Kopieren von Dateien aus einem Container

Im folgenden Beispiel werden die SQL Server-Protokolldateien aus dem Container in den ~/temp/sqlserverlogs-Pfad auf dem lokalen Computer (in diesem Beispiel handelt es sich bei dem lokalen Computer um einen Linux-Client) kopiert:

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

Kopieren von Dateien in Container

Im folgenden Beispiel wird die Datei AdventureWorks2022 vom lokalen Computer in den Container der SQL Server-Masterinstanz (mssql-server) im Pod master-0 kopiert. Die Datei wird in das /tmp-Verzeichnis in den Container kopiert.

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

Erzwingen des Löschens eines Pods

Es wird nicht empfohlen, das Löschen eines Pods zu erzwingen. Zum Testen der Verfügbarkeit, Resilienz oder Datenpersistenz können Sie mit dem Befehl kubectl delete pods einen Pod löschen, um einen Podfehler zu simulieren.

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

Im folgenden Beispiel wird der Speicherpoolpod storage-0-0 gelöscht:

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

Abrufen einer Pod-IP-Adresse

Für die Problembehandlung müssen Sie möglicherweise die IP-Adresse des Knotens abrufen, auf dem der Pod derzeit ausgeführt wird. Verwenden Sie den Befehl kubectl get pods mit der folgenden Syntax, um die IP-Adresse abzurufen:

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

Im folgenden Beispiel wird die IP-Adresse des Knotens abgerufen, auf dem der Pod master-0 ausgeführt wird:

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

Kubernetes-Dashboard

Sie können das Kubernetes-Dashboard starten, um weitere Informationen zum Cluster zu erhalten. In den folgenden Abschnitten wird erläutert, wie das Dashboard für Kubernetes in AKS und für einen gestarteten Kubernetes-Cluster mithilfe von kubeadm gestartet wird.

Starten des Dashboards bei Ausführung des Clusters in AKS

Führen Sie Folgendes aus, um das Kubernetes-Dashboard zu starten:

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

Hinweis

Möglicherweise wird die folgende Fehlermeldung angezeigt: Fehler beim Lauschen auf Port 8001: Fehler beim Erstellen aller Listener: Listener kann nicht erstellt werden: Fehler beim Lauschen tcp4 127.0.0.1:8001: >bind: Es ist normalerweise nur eine Verwendung jeder Socketadresse (Protokoll/Netzwerkadresse/Port) zulässig. Listener kann nicht erstellt werden: Fehler listen tcp6: address [[::1]]:8001: missing port in >address error: Unable to listen on any of the requested ports: [{8001 9090}]. Stellen Sie in diesem Fall sicher, dass Sie das Dashboard nicht bereits über ein anderes Fenster gestartet haben.

Wenn Sie das Dashboard in Ihrem Browser starten, werden Ihnen möglicherweise Berechtigungswarnungen angezeigt, da die rollenbasierte Zugriffssteuerung in AKS-Clustern standardmäßig aktiviert wird und das vom Dashboard verwendete Dienstkonto nicht über genug Berechtigungen für den Zugriff auf alle Ressourcen verfügt (z. B.: pods is forbidden: User "system:serviceaccount:kube-system:kubernetes-dashboard" cannot list pods in the namespace "default" (Pods nicht zulässig: Benutzer „system:serviceaccount:kube-system:kubernetes-dashboard“ kann Pods nicht im Namespace „default“ (Standard) auflisten)). Führen Sie den folgenden Befehl aus, um die erforderlichen Berechtigungen für kubernetes-dashboard zu erteilen, und starten Sie anschließend das Dashboard neu:

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

Starten des Dashboards mithilfe von kubeadm bei gestartetem Kubernetes-Cluster

Ausführliche Anweisungen zum Bereitstellen und Konfigurieren des Dashboards in Ihrem Kubernetes-Cluster finden Sie in der Kubernetes-Dokumentation. Führen Sie folgenden Befehl aus, um das Kubernetes-Dashboard zu starten:

kubectl proxy

Nächste Schritte

Weitere Informationen zu Big Data-Clustern finden Sie unter Was sind Big Data-Cluster für SQL Server?.