Guide pratique pour déployer des Clusters Big Data SQL Server sur Kubernetes
S’applique à :
SQL Server 2019 (15.x)
Important
Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.
Un cluster Big Data SQL Server est déployé sous la forme de conteneurs Docker sur un cluster Kubernetes. Voici une vue d’ensemble des étapes d’installation et de configuration :
- Configurez un cluster Kubernetes sur une seule machine virtuelle, un cluster de machines virtuelles ou dans AKS (Azure Kubernetes Service), Red Hat OpenShift ou dans Azure Red Hat OpenShift (ARO).
- Installez l’outil de configuration de cluster Azure Data CLI (
azdata) sur votre machine cliente. - Déployez un cluster Big Data SQL Server dans un cluster Kubernetes.
Configurations testées
Consultez Configurations testées pour obtenir la liste complète des différentes plateformes Kubernetes validées pour le déploiement de clusters Big Data SQL Server.
éditions de SQL Server
| Édition | Notes |
|---|---|
| Entreprise standard Développeur |
L’édition du cluster Big Data est déterminée par l’édition de l’instance principale SQL Server. Au moment du déploiement, l’édition Développeur est déployée par défaut. Vous pouvez changer l’édition après le déploiement. Consultez Configurer l’instance principale SQL Server. |
Kubernetes
Configuration du cluster Kubernetes
Si vous avez déjà un cluster Kubernetes qui répond aux prérequis ci-dessus, vous pouvez passer directement à l’étape de déploiement. Cette section suppose que vous disposez de connaissances de base sur les concepts de Kubernetes. Pour obtenir des informations plus détaillées, consultez la documentation de Kubernetes.
Vous pouvez choisir de déployer Kubernetes des manières suivantes :
| Déployer Kubernetes sur : | Description | Lien |
|---|---|---|
| Azure Kubernetes Services (AKS) | Service de conteneur Kubernetes managé dans Azure. | Instructions |
Une ou plusieurs machines (kubeadm) |
Cluster Kubernetes déployé sur des machines physiques ou virtuelles à l’aide de kubeadm |
Instructions |
| Azure Red Hat OpenShift | Une version managée d’OpenShift qui s’exécute dans Azure. | Instructions |
| Red Hat OpenShift | Une plate-forme d’application Kubernetes entreprise et Cloud hybride. | Instructions |
Conseil
Vous pouvez également créer un script pour déployer AKS et un cluster Big Data en une seule étape. Pour plus d’informations, consultez la procédure à suivre dans un script Python ou dans un notebook Azure Data Studio.
Vérifier la configuration de Kubernetes
Exécutez la commande kubectl pour afficher la configuration du cluster. Vérifiez que kubectl pointe vers le bon contexte de cluster.
kubectl config view
Important
Si vous déployez sur un cluster Kubernetes à plusieurs nœuds que vous avez démarré à l’aide de kubeadm, avant de démarrer le déploiement du cluster Big Data, assurez-vous que les horloges sont synchronisées entre tous les nœuds Kubernetes ciblés par le déploiement. Le cluster Big Data intègre des propriétés d’intégrité temporaires pour différents services et des décalages d’horloge peuvent entraîner un état incorrect.
Après avoir configuré votre cluster Kubernetes, vous pouvez passer au déploiement d’un nouveau cluster Big Data SQL Server. Si vous effectuez une mise à niveau à partir d’une version précédente, consultez Guide pratique pour mettre à niveau des Clusters Big Data SQL Server.
Vérifier que le stockage est configuré
La plupart des déploiements de cluster Big Data doivent disposer d’un stockage persistant. À ce stade, vous devez vous assurer de disposer d’un plan pour la façon dont vous allez fournir un stockage persistant sur le cluster Kubernetes avant de déployer.
- Si vous déployez dans AKS, aucune configuration de stockage n’est nécessaire. AKS fournit des classes de stockage intégrées au provisionnement dynamique. Vous pouvez personnaliser la classe de stockage (
defaultoumanaged-premium) dans le fichier de configuration de déploiement. Les profils intégrés utilisent une classe de stockagedefault. - Si vous déployez sur un cluster Kubernetes que vous avez déployé à l’aide de
kubeadm, vous devez vous veiller à disposer d’un espace de stockage suffisant pour qu’un cluster de l’échelle souhaitée soit disponible et son utilisation configurée. Si vous souhaitez personnaliser la façon dont votre stockage est utilisé, vous devez le faire avant de continuer. Consultez Persistance des données avec un cluster Big Data SQL Server sur Kubernetes.
Installer les outils de Big Data SQL Server 2019
Avant de déployer un cluster Big Data SQL Server 2019, commencez par installer les outils de Big Data :
- Azure Data CLI (
azdata) kubectl- Azure Data Studio
- Extension de virtualisation de données pour Azure Data Studio
- Azure CLI, si le déploiement est fait sur AKS
Vue d’ensemble du déploiement
La plupart des paramètres de cluster Big Data sont définis dans un fichier de configuration de déploiement JSON. Vous pouvez utiliser un profil de déploiement par défaut pour AKS et les clusters Kubernetes créés avec kubeadm ou vous pouvez personnaliser un fichier de configuration de déploiement et l’utiliser pendant l’installation. Pour des raisons de sécurité, les paramètres d’authentification sont passés par le biais de variables d’environnement.
Les sections suivantes fournissent plus d’informations sur la façon de configurer vos déploiements de cluster Big Data, ainsi que des exemples de personnalisations courantes. Sachez que vous pouvez toujours modifier le fichier de configuration de déploiement personnalisé à l’aide d’un éditeur comme VS Code.
Configurations par défaut
Les options de déploiement d’un cluster Big Data sont définies dans les fichiers de configuration JSON. Vous pouvez démarrer votre personnalisation du déploiement de cluster à partir des profils de déploiement intégrés disponibles dans Azure Data CLI (azdata).
Notes
Les images conteneur nécessaires pour le déploiement de cluster Big Data sont hébergées dans le registre de conteneurs Microsoft (mcr.microsoft.com), dans le référentiel mssql/bdc. Par défaut, ces paramètres sont déjà inclus dans le fichier de configuration control.json dans chacun des profils de déploiement inclus avec Azure Data CLI (azdata). De plus, l’étiquette d’image conteneur pour chaque version est également préremplie dans le même fichier de configuration. Si vous devez extraire (pull) les images conteneur dans votre propre registre de conteneurs privé et/ou modifier les paramètres du référentiel/registre de conteneurs, suivez les instructions fournies dans l’article sur l’installation hors connexion
Exécutez cette commande pour rechercher les modèles disponibles :
azdata bdc config list -o table
Les modèles suivants sont disponibles sur à compter de SQL Server 2019 CU5 :
| Profil de déploiement | Environnement Kubernetes |
|---|---|
aks-dev-test |
Déployez un cluster Big Data SQL Server sur AKS (Azure Kubernetes Service) |
aks-dev-test-ha |
Déployez un cluster Big Data SQL Server sur AKS (Azure Kubernetes Service). Les services critiques comme le nœud de nom HDFS et le principal SQL Server sont configurés pour la haute disponibilité. |
aro-dev-test |
Déployez un cluster Big Data SQL Server sur Azure Red Hat OpenShift pour le développement et les tests. Introduite dans SQL Server 2019 CU 5. |
aro-dev-test-ha |
Déployez un cluster Big Data SQL Server avec une haute disponibilité sur un cluster Red Hat OpenShift pour le développement et les tests. Introduite dans SQL Server 2019 CU 5. |
kubeadm-dev-test |
Déployez le cluster Big Data SQL Server sur un cluster Kubernetes créé avec kubeadm à l’aide d’une seule ou de plusieurs machines physiques ou virtuelles. |
kubeadm-prod |
Déployer le cluster Big Data SQL Server sur un cluster Kubernetes créé avec kubeadm à l’aide d’une seule ou de plusieurs machines physiques ou virtuelles. Utilisez ce modèle pour permettre l’intégration des services du cluster Big Data avec Active Directory. Les services critiques tels que l’instance principale SQL Server et le nœud de nom HDFS sont déployés dans une configuration hautement disponible. |
openshift-dev-test |
Déployez un cluster Big Data SQL Server sur un cluster Red Hat OpenShift pour le développement et les tests. Introduite dans SQL Server 2019 CU 5. |
openshift-prod |
Déployez un cluster Big Data SQL Server avec une haute disponibilité sur un cluster Red Hat OpenShift. Introduite dans SQL Server 2019 CU 5. |
Vous pouvez déployer un cluster Big Data en exécutant azdata bdc create. Vous êtes alors invité à choisir l’une des configurations par défaut, puis à suivre la procédure de déploiement.
La première fois que vous exécutez Azure Data CLI (azdata), vous devez inclure --accept-eula=yes pour accepter le contrat de licence utilisateur final (CLUF).
azdata bdc create --accept-eula=yes
Dans ce scénario, vous êtes invité à fournir tous les paramètres qui ne font pas partie de la configuration par défaut, notamment les mots de passe.
Important
Par défaut, le cluster Big Data est nommé mssql-cluster. Il est important de le connaître si vous souhaitez exécuter l’une des commandes kubectl spécifiant l’espace de noms Kubernetes avec le paramètre -n.
Configurations personnalisées
Vous pouvez également personnaliser votre déploiement pour prendre en charge les charges de travail que vous envisagez d’exécuter. Vous ne pouvez pas modifier la mise à l’échelle (nombre de réplicas) ni les paramètres de stockage des services de cluster Big Data après les déploiements. Vous devez donc planifier votre configuration de déploiement avec soin afin d’éviter les problèmes de capacité. Pour personnaliser votre déploiement, procédez comme suit :
Commencez par l’un des profils de déploiement standard correspondant à votre environnement Kubernetes. Vous pouvez utiliser la commande
azdata bdc config listpour les lister :azdata bdc config listPour personnaliser votre déploiement, créez une copie du profil de déploiement avec la commande
azdata bdc config init. Par exemple, la commande suivante crée une copie des fichiers de configuration de déploiementaks-dev-testdans un répertoire cible nommécustom:azdata bdc config init --source aks-dev-test --target customConseil
--targetspécifie un répertoire qui contient les fichiers de configuration,bdc.jsonetcontrol.json, en fonction du paramètre--source.Pour personnaliser les paramètres dans votre profil de configuration de déploiement, vous pouvez modifier le fichier de configuration de déploiement dans un outil adapté à la modification des fichiers JSON, par exemple VS Code. Pour une automatisation par script, vous pouvez également modifier le profil de déploiement personnalisé à l’aide de la commande
azdata bdc config. Par exemple, la commande suivante modifie un profil de déploiement personnalisé en remplaçant le nom par défaut du cluster déployé (mssql-cluster) partest-cluster:azdata bdc config replace --config-file custom/bdc.json --json-values "metadata.name=test-cluster"Conseil
Vous pouvez également passer le nom du cluster au moment du déploiement à l’aide du paramètre --name pour la commande
azdata create bdc. Les paramètres dans la commande ont priorité sur les valeurs dans les fichiers de configuration.JSONPath Online Evaluator est un outil utile pour rechercher des chemins JSON.
En plus de passer des paires clé-valeur, vous pouvez également fournir des valeurs JSON inline ou passer des fichiers de correctif JSON. Pour plus d’informations, consultez Configurer les paramètres de déploiement pour les services et les ressources de cluster Big Data.
Passez ensuite le fichier de configuration personnalisé à
azdata bdc create. Notez que vous devez définir les variables d’environnement requises ; sinon, le terminal vous invitera à fournir les valeurs :azdata bdc create --config-profile custom --accept-eula yes
Avertissement
Le paramètre imagePullPolicy doit être défini comme "Always" dans le fichier du profil de déploiement control.json.
Pour plus de détails sur la structure d’un fichier de configuration de déploiement, consultez ces informations de référence. Pour obtenir d’autres exemples de configuration, consultez Configurer les paramètres de déploiement de clusters Big Data.
Variables d'environnement
Les variables d’environnement suivantes sont utilisées pour les paramètres de sécurité qui ne sont pas stockés dans un fichier de configuration de déploiement. Notez que les paramètres Docker, à l’exception des informations d’identification, peuvent être définis dans le fichier de configuration.
| Variable d’environnement | Condition requise | Description |
|---|---|---|
AZDATA_USERNAME |
Obligatoire | Nom d’utilisateur de l’administrateur du cluster Big Data SQL Server. Une connexion sysadmin portant le même nom est créée dans l’instance principale SQL Server. En guise de bonne pratique de sécurité, le compte sa est désactivé. À partir de SQL Server 2019 (15.x) CU 5, lorsque vous déployez un nouveau cluster avec l’authentification de base, tous les points de terminaison, dont la passerelle, utilisent AZDATA_USERNAME et AZDATA_PASSWORD. Les points de terminaison sur les clusters mis à niveau vers la CU 5 continuent à utiliser root comme nom d’utilisateur pour se connecter au point de terminaison de la passerelle. Cette modification ne s’applique pas aux déploiements utilisant l’authentification Active Directory. Voir Informations d’identification pour l’accès aux services via le point de terminaison de passerelle dans les notes de publication. |
AZDATA_PASSWORD |
Obligatoire | Mot de passe des comptes d’utilisateur créés ci-dessus. Sur les clusters déployés avant SQL Server 2019 CU5, le même mot de passe est utilisé pour l’utilisateur root, afin de sécuriser la passerelle Knox et HDFS. |
ACCEPT_EULA |
Obligatoire pour la première utilisation de Azure Data CLI (azdata) |
Définie sur « oui ». Si vous la définissez en tant que variable d’environnement, elle applique le CLUF à SQL Server et Azure Data CLI (azdata). Si vous ne la définissez pas en tant que variable d’environnement, vous pouvez inclure --accept-eula=yes dans la première utilisation de la commande Azure Data CLI (azdata). |
DOCKER_USERNAME |
Facultatif | Nom d’utilisateur utilisé pour accéder aux images de conteneur si elles sont stockées dans un dépôt privé. Pour plus d’informations sur l’utilisation d’un dépôt Docker privé pour le déploiement d’un cluster Big Data, consultez la rubrique Déploiements hors connexion. |
DOCKER_PASSWORD |
Facultatif | Mot de passe nécessaire pour accéder au dépôt privé ci-dessus. |
Ces variables d’environnement doivent être définies avant d’appeler azdata bdc create. Si une variable n’est pas définie, vous êtes invité à le faire.
L’exemple suivant montre comment définir les variables d’environnement pour Linux (bash) et Windows (PowerShell) :
export AZDATA_USERNAME=admin
export AZDATA_PASSWORD=<password>
export ACCEPT_EULA=yes
SET AZDATA_USERNAME=admin
SET AZDATA_PASSWORD=<password>
Notes
Sur les clusters déployés avant SQL Server 2019 CU 5, vous devez utiliser l’utilisateur root pour la passerelle Knox avec le mot de passe ci-dessus. root est le seul utilisateur pris en charge dans cette authentification de base (nom d’utilisateur/mot de passe).
À partir de SQL Server 2019 (15.x) CU 5, lorsque vous déployez un nouveau cluster avec l’authentification de base, tous les points de terminaison, dont la passerelle, utilisent AZDATA_USERNAME et AZDATA_PASSWORD. Les points de terminaison sur les clusters mis à niveau vers la CU 5 continuent à utiliser root comme nom d’utilisateur pour se connecter au point de terminaison de la passerelle. Cette modification ne s’applique pas aux déploiements utilisant l’authentification Active Directory. Voir Informations d’identification pour l’accès aux services via le point de terminaison de passerelle dans les notes de publication.
Pour vous connecter à SQL Server avec l’authentification de base, utilisez les mêmes valeurs que les variables d’environnement AZDATA_USERNAME et AZDATA_PASSWORD.
Après avoir défini les variables d’environnement, vous devez exécuter azdata bdc create pour déclencher le déploiement. Cet exemple utilise le profil de configuration de cluster créé ci-dessus :
azdata bdc create --config-profile custom --accept-eula yes
Notez les consignes suivantes :
- Veillez à inclure le mot de passe entre guillemets doubles s’il contient des caractères spéciaux. Vous pouvez définir
AZDATA_PASSWORDavec la valeur de votre choix, mais veillez à ce que le mot de passe soit suffisamment complexe et n’utilisez pas les caractères!,&et'. Notez que les délimiteurs de guillemets doubles fonctionnent uniquement dans les commandes bash. - La connexion
AZDATA_USERNAMEest un administrateur système sur l’instance principale SQL Server dont la création a lieu lors de l’installation. Une fois le conteneur SQL Server créé, la variable d’environnementAZDATA_PASSWORDque vous avez spécifiée peut être découverte en exécutantecho $AZDATA_PASSWORDdans le conteneur. Pour des raisons de sécurité, modifiez le mot de passe en guise de bonne pratique.
Installation sans assistance
Pour un déploiement sans assistance, vous devez définir toutes les variables d’environnement nécessaires, utiliser un fichier de configuration et appeler la commande azdata bdc create avec le paramètre --accept-eula yes. Les exemples de la section précédente illustrent la syntaxe d’une installation sans assistance.
Surveillance du déploiement
Durant l’amorçage du cluster, la fenêtre de commande du client retourne l’état du déploiement. Vous devez ensuite voir une série de messages indiquant que le processus de déploiement attend le pod du contrôleur :
Waiting for cluster controller to start.
Après 15 à 30 minutes, vous devez être informé que le pod du contrôleur est en cours d’exécution :
Cluster controller endpoint is available at 11.111.111.11:30080.
Cluster control plane is ready.
Important
L’ensemble du processus de déploiement peut durer longtemps en raison du temps nécessaire au téléchargement des images de conteneur pour les composants du cluster Big Data. Il ne devrait cependant pas prendre plusieurs heures. Si vous rencontrez des problèmes avec votre déploiement, consultez Supervision et résolution des problèmes de Clusters Big Data SQL Server.
Une fois le déploiement terminé, vous êtes notifié dans la sortie :
Cluster deployed successfully.
Conseil
Le nom par défaut du cluster Big Data déployé est mssql-cluster, sauf s’il est modifié par une configuration personnalisée.
Récupérer des points de terminaison
Une fois le script de déploiement terminé, vous pouvez obtenir les adresses des points de terminaison externes du cluster Big Data en effectuant les étapes suivantes.
Après le déploiement, recherchez l’adresse IP du point de terminaison du contrôleur dans la sortie standard du déploiement ou la sortie EXTERNAL-IP de la commande
kubectlsuivante :kubectl get svc controller-svc-external -n <your-big-data-cluster-name>Conseil
Si vous n’avez pas changé le nom par défaut durant le déploiement, utilisez
-n mssql-clusterdans la commande précédente.mssql-clusterest le nom par défaut du cluster Big Data.Connectez-vous au cluster Big Data avec azdata login. Affectez au paramètre
--endpointl’adresse IP externe du point de terminaison du contrôleur.azdata login --endpoint https://<ip-address-of-controller-svc-external>:30080 --username <user-name>Spécifiez le nom d’utilisateur et le mot de passe que vous avez configurés pour l’administrateur du cluster Big Data (AZDATA_USERNAME et AZDATA_PASSWORD) durant le déploiement.
Conseil
Si vous êtes l’administrateur du cluster Kubernetes et que vous avez accès au fichier de configuration du cluster (fichier de configuration Kube), vous pouvez configurer le contexte actuel pour qu’il pointe vers le cluster Kubernetes ciblé. Dans ce cas, vous pouvez vous connecter avec
azdata login -n <namespaceName>, oùnamespaceest le nom du cluster Big Data. Vous êtes invité à fournir des informations d’identification si elles ne sont pas spécifiées dans la commande de connexion.Exécutez azdata bdc endpoint list pour obtenir une liste comprenant la description de chaque point de terminaison ainsi que les adresses IP et ports correspondants.
azdata bdc endpoint list -o tableLa liste suivante montre un exemple de sortie de cette commande :
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
Vous pouvez également obtenir tous les points de terminaison de service déployés pour le cluster en exécutant la commande kubectl suivante :
kubectl get svc -n <your-big-data-cluster-name>
Vérifier l’état du cluster
Après le déploiement, vous pouvez vérifier l’état du cluster à l’aide de la commande azdata bdc status show.
azdata bdc status show
Conseil
Pour exécuter les commandes d’état, vous devez d’abord vous connecter à l’aide de la commande azdata login (présentée dans la section précédente sur les points de terminaison).
Voici un exemple de sortie de cette commande :
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
Vous pouvez également obtenir un état plus détaillé avec les commandes suivantes :
- azdata bdc control status show retourne l’état d’intégrité de tous les composants associés au service de gestion de contrôle
azdata bdc control status show
Exemple de sortie :
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 showretourne l’état d’intégrité de toutes les ressources qui ont un service SQL Server
azdata bdc sql status show
Exemple de sortie :
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
Important
Lorsque vous utilisez le paramètre --all, la sortie de ces commandes contient des URL vers les tableaux de bord Kibana et Grafana pour une analyse plus détaillée.
Outre Azure Data CLI (azdata), vous pouvez utiliser Azure Data Studio pour rechercher les points de terminaison et des informations d’état. Pour plus d’informations sur l’affichage de l’état du cluster avec Azure Data CLI (azdata) et Azure Data Studio, consultez Guide pratique pour afficher l’état d’un cluster Big Data.
Se connecter au cluster
Pour plus d’informations sur la façon de se connecter au cluster Big Data, consultez Se connecter à un cluster Big Data SQL Server avec Azure Data Studio.
Étapes suivantes
Pour en savoir plus sur le déploiement d’un cluster Big Data SQL Server, consultez les ressources suivantes :
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour