Risolvere i problemi relativi ai cluster Big Data di SQL Server Kubernetes

Si applica a:SQL Server 2019 (15.x)

Importante

Il componente aggiuntivo Cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e il software continuerà a essere mantenuto tramite gli aggiornamenti cumulativi di SQL Server fino a quel momento. Per ulteriori informazioni, vedere il post di blog sull'annuncio e le opzioni di Big Data sulla piattaforma Microsoft SQL Server.

Questo articolo descrive diversi comandi utili di Kubernetes che è possibile usare per monitorare e risolvere i problemi di un cluster Big Data di SQL Server 2019. Illustra come visualizzare i dettagli approfonditi di un pod o di altri artefatti Kubernetes che si trovano nel cluster Big Data. Questo articolo illustra anche le attività comuni, ad esempio la copia di file da o verso un contenitore che esegue uno dei servizi cluster Big Data di SQL Server.

Suggerimento

Per il monitoraggio dello stato dei componenti dei cluster Big Data, è possibile usare i comandi azdata bdc status o i notebook predefiniti per la risoluzione dei problemi disponibili in Azure Data Studio.

Suggerimento

Eseguire i comandi kubectl seguenti in un computer client Windows (cmd o PS) o Linux (bash). Richiedono una precedente autenticazione nel cluster e un contesto del cluster contro cui eseguire il comando. Ad esempio, per un cluster del servizio Azure Kubernetes creato in precedenza, è possibile eseguire az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name> per scaricare il file di configurazione del cluster Kubernetes e impostare il contesto del cluster.

Ottieni lo stato dei pod

È possibile usare il comando kubectl get pods per ottenere lo stato dei pod nel cluster per ciascun spazio dei nomi o per lo spazio dei nomi del cluster Big Data. Le sezioni seguenti mostrano esempi di entrambi.

Visualizzare lo stato di tutti i pod nel cluster Kubernetes

Eseguire il comando seguente per ottenere tutti i pod e i relativi stati, inclusi i pod che fanno parte dello spazio dei nomi in cui vengono creati i pod del cluster Big Data di SQL Server:

kubectl get pods --all-namespaces

Visualizzare lo stato di tutti i pod nel cluster Big Data di SQL Server

Usare il -n parametro per specificare uno spazio dei nomi specifico. Si noti che i pod del cluster Big Data di SQL Server vengono creati in un nuovo spazio dei nomi creato in fase di bootstrap del cluster in base al nome del cluster specificato nel file di configurazione della distribuzione. Il nome predefinito, mssql-cluster, viene usato qui.

kubectl get pods -n mssql-cluster

Verrà visualizzato un output simile all'elenco seguente per un cluster Big Data in esecuzione:

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

Annotazioni

Durante la distribuzione, i pod con statoContainerCreating sono ancora in arrivo. Se la distribuzione si blocca per qualsiasi motivo, questo può dare un'idea di dove potrebbe essere il problema. Esaminare anche la colonna READY . In questo modo viene indicato il numero di contenitori avviati nel pod. Si noti che le distribuzioni possono richiedere 30 minuti o più a seconda della configurazione e della rete. Gran parte di questo tempo viene impiegato per scaricare le immagini del contenitore per componenti diversi.

Ottieni i dettagli del pod

Eseguire il comando seguente per ottenere una descrizione dettagliata di un pod specifico nell'output in formato JSON. Include dettagli, ad esempio il nodo Kubernetes corrente su cui si trova il pod, i contenitori in esecuzione all'interno del pod e l'immagine usata per avviare il bootstrap dei contenitori. Mostra anche altri dettagli, ad esempio etichette, stato e attestazioni di volumi persistenti associati al pod.

kubectl describe pod  <pod_name> -n <namespace_name>

L'esempio seguente mostra i dettagli per il master-0 pod in un cluster Big Data denominato mssql-cluster:

kubectl describe pod  master-0 -n mssql-cluster

Se si sono verificati errori, a volte è possibile visualizzare l'errore negli eventi recenti per il pod.

Visualizzare i log dei pod

È possibile recuperare i log dei contenitori in esecuzione in un pod. Il comando seguente recupera i log per tutti i contenitori in esecuzione nel pod denominato master-0 e li restituisce in un nome master-0-pod-logs.txtfile :

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

Ottenere lo stato dei servizi

Eseguire il comando seguente per ottenere i dettagli per i servizi cluster Big Data. Questi dettagli includono il tipo e gli indirizzi IP associati ai rispettivi servizi e porte. Si noti che i servizi cluster Big Data di SQL Server vengono creati in un nuovo spazio dei nomi creato in fase di bootstrap del cluster in base al nome del cluster specificato nel file di configurazione della distribuzione.

kubectl get svc -n <namespace_name>

L'esempio seguente illustra lo stato dei servizi in un cluster Big Data denominato mssql-cluster:

kubectl get svc -n mssql-cluster

I servizi seguenti supportano connessioni esterne al cluster Big Data:

Servizio	Descrizione
master-svc-external	Fornisce l'accesso all'istanza principale. (EXTERNAL-IP,31433 e l'utente SA)
controller-svc-external	Supporta strumenti e client che gestiscono il cluster.
gateway-svc-external	Fornisce l'accesso al gateway HDFS/Spark. (EXTERNAL-IP e l'utente <AZDATA_USERNAME>)1
appproxy-svc-external	Supportare gli scenari di distribuzione delle applicazioni.

¹ A partire da SQL Server 2019 (15.x) CU 5, quando si distribuisce un nuovo cluster con autenticazione di base, tutti gli endpoint, incluso il gateway, utilizzano AZDATA_USERNAME e AZDATA_PASSWORD. Gli endpoint nei cluster aggiornati a CU 5 continuano a usare root come nome utente per connettersi all'endpoint del gateway. Questa modifica non si applica alle distribuzioni che usano l'autenticazione di Active Directory. Consulta Credenziali per l'accesso ai servizi tramite l'endpoint del gateway nelle note di rilascio.

Suggerimento

Si tratta di un modo per visualizzare i servizi con kubectl, ma è anche possibile usare azdata bdc endpoint list il comando per visualizzare questi endpoint. Per ulteriori informazioni, vedere Ottieni endpoint del cluster Big Data.

Ottenere i dettagli del servizio

Eseguire questo comando per ottenere una descrizione dettagliata di un servizio nell'output in formato JSON. Includerà dettagli come etichette, selettore, IP, IP esterno (se il servizio è di tipo LoadBalancer), porta e così via.

kubectl describe service <service_name> -n <namespace_name>

Nell'esempio seguente vengono recuperati i dettagli per il servizio master-svc-external :

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

Copiare i file

Se è necessario copiare i file dal contenitore al computer locale, usare kubectl cp il comando con la sintassi seguente:

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

Analogamente, è possibile usare kubectl cp per copiare file dal computer locale in un contenitore specifico.

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

Copiare file da un contenitore

L'esempio seguente copia i file di log di SQL Server dal contenitore al ~/temp/sqlserverlogs percorso nel computer locale (in questo esempio il computer locale è un client Linux):

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

Copiare i file nel contenitore

Nell'esempio seguente il AdventureWorks2022 file viene copiato dal computer locale nel contenitore dell'istanza master di SQL Server (mssql-server) nel master-0 pod. Il file viene copiato nella /tmp directory nel contenitore.

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

Forzare l'eliminazione di un pod

Non è consigliabile forzare l'eliminazione di un pod. Tuttavia, per testare la disponibilità, la resilienza o la persistenza dei dati, è possibile eliminare un pod per simulare un errore del pod con il kubectl delete pods comando .

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

Nell'esempio seguente viene eliminato il pod del pool di archiviazione, storage-0-0:

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

Ottenere l'IP del pod

Ai fini della risoluzione dei problemi, potrebbe essere necessario ottenere l'indirizzo IP del nodo in cui è in esecuzione un pod. Per ottenere l'indirizzo IP, usare il kubectl get pods comando con la sintassi seguente:

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

L'esempio seguente ottiene l'indirizzo IP del nodo in cui è in esecuzione il master-0 pod:

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

Dashboard kubernetes

È possibile avviare il dashboard kubernetes per altre informazioni sul cluster. Le sezioni seguenti spiegano come avviare il dashboard per Kubernetes su AKS e per Kubernetes inizializzato usando kubeadm.

Avvia il dashboard quando il cluster è in esecuzione nel servizio Azure Kubernetes (AKS)

Per avviare il dashboard kubernetes, eseguire:

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

Annotazioni

Se viene visualizzato il seguente errore: Impossibile ascoltare sulla porta 8001: Tutti i listener hanno fallito a causa dei seguenti errori: Impossibile creare listener: Errore nell'ascolto tcp4 127.0.0.1:8001: bind: >è normalmente consentito un solo utilizzo di ogni indirizzo socket (protocollo/indirizzo di rete/porta). Impossibile creare il listener: Errore nell'ascolto tcp6: indirizzo [[::1]]:8001: mancanza di porta nell'indirizzo >errore: Impossibile ascoltare su una delle porte richieste: [{8001 9090}], assicurati di non aver già avviato il dashboard da un'altra finestra.

Quando si avvia il dashboard nel browser, è possibile che vengano visualizzati avvisi di autorizzazioni perché RBAC (controllo degli accessi in base al ruolo) è abilitato per impostazione predefinita nei cluster AKS, e l'account del servizio usato dal dashboard non dispone di autorizzazioni sufficienti per accedere a tutte le risorse (ad esempio, pods non sono consentiti: l'utente "system:serviceaccount:kube-system:kubernetes-dashboard" non può elencare i pods nello spazio dei nomi "default"). Eseguire il comando seguente per concedere le autorizzazioni necessarie a kubernetes-dashboarde quindi riavviare il dashboard:

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

Avviare il dashboard quando il cluster Kubernetes viene avviato con kubeadm

Per istruzioni dettagliate su come distribuire e configurare il dashboard nel cluster Kubernetes, vedere la documentazione di Kubernetes. Per avviare il dashboard kubernetes, eseguire questo comando:

kubectl proxy

Passaggi successivi

Per altre informazioni sui cluster Big Data, vedere Che cosa sono i cluster Big Data di SQL Server.