Partage via

Problèmes connus des plateformes Clusters Big Data sur SQL Server 2019

  • Article

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.

Problèmes connus

Copie HDFS de fichiers volumineux via azdata avec des défaillances aléatoires

  • Versions concernées : CU14

  • Problème et effet client : il s’agissait d’un bogue provoquant des défaillances aléatoires sur les commandes azdata bdc cp entre les chemins HDFS. Le bogue affecte plus souvent les copies de fichiers plus volumineux.

  • Solution : mettez à jour vers la mise à jour cumulative 15 (CU15).

Sécurité Log4j

  • Versions concernées : aucune

  • Problème et effet sur le client : après une évaluation approfondie du codebase Clusters Big Data SQL Server 2019, aucun risque associé à la vulnérabilité log4j signalée en décembre n’a été identifié. CU15 comprend une version mise à jour de log4j (2.17) pour l’instance ElasticSearch dans le plan de contrôle afin de s’assurer que les alertes d’analyse d’images ne sont pas déclenchées par l’analyse du code statique des conteneurs du cluster Big Data.

  • Solution : maintenez votre cluster Big Data à jour avec la version la plus récente.

La mise à niveau du cluster à partir de CU8 et version antérieure vers une version postérieure à CU9 n’est pas prise en charge

  • Versions affectées : versions CU8 et antérieures

  • Problème et effet sur le client : quand vous mettez directement à niveau un cluster CU8 ou version antérieure vers une version postérieure à CU9, la mise à niveau échoue pendant la phase de monitoring.

  • Solution : Effectuez d’abord une mise à niveau vers CU9. Ensuite, effectuez une mise à niveau de CU9 vers la version la plus récente.

Plateformes Kubernetes avec la version d’API Kubernetes 1.21+

  • Mises en production affectées : toutes les mises en production

  • Problème et effet sur le client : l’API Kubernetes 1.21 ou supérieure n’est pas une configuration testée de Clusters Big Data SQL Server à partir de CU12.

Packages MicrosoftML sur SQL Server Machine Learning Services

  • Mises en production affectées : CU10, CU11, CU12 et CU13

  • Problème et effet sur le client : certains packages MicrosoftML R/Python sur SQL Server Machine Learning Services ne fonctionnent pas. Il affecte toutes les instances maîtres SQL Server.

Échec de la connexion à l’instance distante de SQL Server 2016 ou version antérieure

  • Versions concernées : CU10
  • Problème et effet sur le client : quand vous utilisez PolyBase dans SQL Server 2019 avec des Clusters Big Data CU10 pour vous connecter à une instance SQL Server existante qui utilise un certificat pour le chiffrement du canal créé avec l’algorithme SHA1, vous pouvez observer l’erreur suivante :

Msg 105082, Level 16, State 1, Line 1 105082;Generic ODBC error: [Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: An existing connection was forcibly closed by the remote host. Additional error <2>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection, SqlState: 08001, NativeError: 10054 Additional error <3>: ErrorMsg: [Microsoft][ODBC Driver 17 for SQL Server] Invalid connection string attribute, SqlState: 01S00, NativeError: 0 .

  • Solution : En raison des exigences de sécurité accrues d’Ubuntu 20.04 par rapport à la version précédente de l’image de base, la connexion à distance n’est pas autorisée pour un certificat avec l’algorithme SHA1. Le certificat auto-signé par défaut des versions 2005-2016 de SQL Server utilisait l’algorithme SHA1. Pour plus d’informations sur ce changement, consultez les changements effectués sur les certificats auto-signés dans SQL Server 2017. Dans l’instance de SQL Server distante, utilisez un certificat créé avec un algorithme qui utilise au moins 112 bits de sécurité (par exemple, SHA256). Pour les environnements de production, nous vous recommandons de vous procurer un certificat approuvé auprès d’une autorité de certification. À des fins de test, un certificat auto-signé peut aussi être utilisé. Pour créer un certificat auto-signé, reportez-vous à l’applet de commande PowerShell New-SelfSignedCertificate ou à la commande certreq. Pour obtenir des instructions sur l’installation d’un nouveau certificat sur l’instance de SQL Server distante, consultez Activer les connexions chiffrées dans le moteur de base de données.

Perte partielle des journaux collectés dans ElasticSearch lors de la restauration

  • Versions affectées : Affecte les clusters existants quand une mise à niveau non réussie vers CU9 aboutit à une restauration ou quand un utilisateur passe à une version antérieure.

  • Problème et effet sur le client : la version du logiciel utilisée pour Elastic Search a été mise à niveau vers CU9 et la nouvelle version n’offre pas de compatibilité descendante avec le format ou les métadonnées des journaux précédents. Si le composant ElasticSearch est mis à niveau et qu’une restauration est déclenchée par la suite, les journaux collectés entre la mise à niveau d’ElasticSearch et la restauration sont définitivement perdus. Si vous passez à une version antérieure de Clusters Big Data SQL Server 2019 (ce qui n’est pas recommandé), les journaux stockés dans ElasticSearch sont perdus. Si vous revenez à CU9, les données seront restaurées.

  • Solution de contournement : Si nécessaire, vous pouvez résoudre les problèmes à l’aide des journaux collectés avec la commande azdata bdc debug copy-logs.

Métriques sur les pods et les conteneurs manquantes

  • Versions concernées : Clusters existants et nouveaux clusters lors de la mise à niveau vers CU9

  • Problème et effet sur le client : à la suite de la mise à niveau de la version de Telegraf utilisée pour les composants de monitoring dans CU9, vous notez que les métriques sur les pods et les conteneurs ne sont pas collectées pendant la mise à niveau du cluster vers la version CU9. C’est parce qu’une ressource supplémentaire est nécessaire dans la définition du rôle de cluster utilisé pour Telegraf à la suite de la mise à niveau du logiciel. Si l’utilisateur qui déploie le cluster ou effectue la mise à niveau ne dispose pas d’autorisations suffisantes, le déploiement ou la mise à niveau continue avec un avertissement et aboutit, mais les métriques sur les pods et les nœuds ne sont pas collectées.

  • Solution de contournement : Vous pouvez demander à un administrateur de créer ou de mettre à jour le rôle et le compte de service correspondant (avant ou après le déploiement ou la mise à niveau) afin que le cluster Big Data utilise ces informations. Cet article explique comment créer les artefacts requis.

L’exécution de azdata bdc copy-logs n’entraîne pas la copie des journaux

  • Versions concernées : Azure Data CLI (azdata) version 20.0.0

  • Problème et effet sur le client : l’implémentation de la commande copy-logs suppose l’installation de l’outil client kubectl version 1.15 ou ultérieure sur la machine cliente qui émet la commande. Si vous utilisez kubectl version 1.14, la commande azdata bdc debug copy-logs se termine sans échec, mais les journaux ne sont pas copiés. En cas d’exécution avec l’indicateur --debug, vous pouvez voir cette erreur dans la sortie : La source '.' n’est pas valide.

  • Solution de contournement : Installez l’outil kubectl version 1.15 ou ultérieure sur le même ordinateur client et réexécutez la commande azdata bdc copy-logs. Vous trouverez ici des instructions sur l’installation de kubectl.

Les fonctionnalités MSDTC ne peuvent pas être activées pour l’instance maître SQL Server

  • Versions concernées : Toutes les configurations de déploiement de cluster Big Data, indépendamment de la version.

  • Problème et effet sur le client : quand SQL Server est déployé dans le cluster Big Data comme instance maître SQL Server, la fonctionnalité MSDTC ne peut pas être activée. Il n’existe aucune solution de contournement à ce problème.

Rotation du chiffreur de clé de chiffrement de base de données SQL Server HA

  • Versions concernées : Toutes les versions jusqu’à CU8. Résolu pour CU9.

  • Problème et effet sur le client  : quand SQL Server est déployé avec HA, la permutation de certificat pour la base de données chiffrée échoue. Quand la commande suivante est exécutée sur le pool principal, un message d’erreur s’affiche :

    ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER
CERTIFICATE <NewCertificateName>;

    Il n’y a pas d’effet, la commande échoue et le chiffrement de la base de données cible est conservé avec le certificat précédent.

Activer la prise en charge des zones de chiffrement HDFS sur CU8

  • Versions concernées : Ce scénario apparaît lors de la mise à niveau vers CU8 à partir de la version CU6 ou d’une version précédente. Il ne se produira pas dans les nouveaux déploiements de CU8+ ou lors de la mise à niveau directe vers CU9. Les versions CU10 ou supérieures ne sont pas affectées.

  • Problème et effet sur le client : la prise en charge des zones de chiffrement HDFS n’est pas activée par défaut dans ce scénario et doit être configurée en utilisant les étapes fournies dans le guide de configuration.

Tâches Livy vides avant d’appliquer les mises à jour cumulatives

  • Versions concernées : Toutes les versions jusqu’à CU6. Résolu pour CU8.

  • Problème et effet sur le client : pendant une mise à niveau, sparkhead renvoie l’erreur 404.

  • Solution de contournement : Avant de mettre à niveau le cluster Big Data, assurez-vous qu’il n’existe aucune session Livy ou aucun travail de traitement par lots actif. Suivez les instructions de Mise à niveau à partir d’une version prise en charge pour éviter cela.

    Si Livy retourne une erreur 404 pendant le processus de mise à niveau, redémarrez le serveur Livy sur les deux nœuds sparkhead. Exemple :

    kubectl -n <clustername> exec -it sparkhead-0/sparkhead-1 -c hadoop-livy-sparkhistory -- exec supervisorctl restart livy

Expiration des mots de passe des comptes de service générés par le cluster Big Data

  • Versions concernées : Tous les déploiements de cluster Big Data avec intégration Active Directory, quelle que soit la version

  • Problème et effet sur le client : pendant le déploiement du cluster Big Data, le workflow génère un ensemble de comptes de service. Selon la stratégie d’expiration de mot de passe définie dans le contrôleur de domaine, les mots de passe de ces comptes peuvent expirer (la valeur par défaut est de 42 jours). Pour l’instant, il n’existe aucun mécanisme permettant de permuter les informations d’identification de tous les comptes dans le cluster Big Data. Le cluster est donc inutilisable une fois la période d’expiration atteinte.

  • Solution de contournement : Mettez à jour la stratégie d’expiration pour les comptes de service d’un cluster Big Data avec « Le mot de passe n’expire jamais » dans le contrôleur de domaine. Pour obtenir la liste complète de ces comptes, consultez Objets Active Directory générés automatiquement. Cette action peut être effectuée avant ou après l’heure d’expiration. Dans ce dernier cas, Active Directory réactive les mots de passe arrivés à expiration.

Informations d’identification pour l’accès aux services via le point de terminaison de passerelle

  • Versions concernées : Nouveaux clusters déployés à partir de CU5.

  • Problème et effet sur le client : pour les nouveaux clusters Big Data déployés avec Clusters Big Data SQL Server CU5, le nom d’utilisateur de la passerelle n’est pas root. Si l’application permettant de se connecter au point de terminaison de la passerelle utilise des informations d’identification incorrectes, une erreur d’authentification se produit. Ce changement résulte de l’exécution d’applications dans le cluster Big Data en tant qu’utilisateur non-racine (nouveau comportement par défaut à compter de Clusters Big Data SQL Server CU5) : quand vous déployez un nouveau cluster Big Data à l’aide de CU5, le nom d’utilisateur du point de terminaison de la passerelle est basé sur la valeur transmise via la variable d’environnement AZDATA_USERNAME. Il s’agit du même nom d’utilisateur que pour le contrôleur et les points de terminaison SQL Server. Seuls les nouveaux déploiements sont affectés. Les clusters Big Data existants déployés avec les versions précédentes continuent d’utiliser root. Il n’y a aucun effet sur les informations d’identification si le cluster est déployé de façon à utiliser l’authentification Active Directory.

  • Solution de contournement : Azure Data Studio gère la modification des informations d’identification de manière transparente pour la connexion établie à la passerelle afin d’activer l’expérience de navigation HDFS dans l’Explorateur d’objets. Vous devez installer la dernière version d’Azure Data Studio qui comprend les modifications nécessaires pour ce cas d’utilisation. En ce qui concerne les autres scénarios dans lesquels vous devez fournir des informations d’identification pour accéder au service via la passerelle (par exemple une connexion avec Azure Data CLI (azdata) ou un accès aux tableaux de bord web pour Spark), vous devez vérifier que les informations d’identification utilisées sont correctes. Si vous ciblez un cluster existant déployé avant CU5, continuez d’utiliser le nom d’utilisateur root pour vous connecter à la passerelle, même après la mise à niveau du cluster vers CU5. Si vous déployez un nouveau cluster avec la build CU5, connectez-vous en fournissant le nom d’utilisateur correspondant à la variable d’environnement AZDATA_USERNAME.

Métriques sur les pods et sur les nœuds non collectées

  • Versions concernées : Clusters nouveaux et existants utilisant des images CU5

  • Problème et effet sur le client : à la suite d’un correctif de sécurité lié à l’API utilisée par telegraf pour collecter les métriques sur les pods et les nœuds hôtes, les clients peuvent constater que les métriques ne sont pas collectées. Cela est possible dans les déploiements nouveaux et existants de Clusters Big Data SQL Server 2019 (après la mise à niveau avec CU5). Avec ce correctif, Telegraf nécessite maintenant un compte de service avec des autorisations de rôle à l’échelle du cluster. Le déploiement tente de créer le compte de service et le rôle de cluster nécessaires. Cependant, même si l’utilisateur qui déploie le cluster ou effectue la mise à niveau ne dispose pas d’autorisations suffisantes, le déploiement ou la mise à niveau continue avec un avertissement et aboutit, mais les métriques sur les pods et les nœuds ne sont pas collectées.

  • Solution de contournement : Vous pouvez demander à un administrateur créer le rôle et le compte de service (avant ou après le déploiement ou la mise à niveau) afin que le cluster Big Data utilise ces informations. Cet article explique comment créer les artefacts requis.

échec de la commande azdata bdc copy-logs

  • Versions concernées : Azure Data CLI (azdata) version 20.0.0

  • Problème et effet sur le client : l’implémentation de la commande copy-logs suppose l’installation de l’outil client kubectl sur la machine cliente qui émet la commande. Si vous émettez la commande sur un cluster Big Data installé sur OpenShift, à partir d’un client où seul l’outil oc est installé, vous obtiendrez une erreur : An error occurred while collecting the logs: [WinError 2] The system cannot find the file specified.

  • Solution de contournement : Installez l’outil kubectl sur le même ordinateur client et réexécutez la commande azdata bdc copy-logs. Vous trouverez ici des instructions sur l’installation de kubectl.

Déploiement avec dépôt privé

  • Versions concernées : GDR1, CU1, CU2. Résolu pour CU3.

  • Problème et effet sur le client : la mise à niveau d’un dépôt privé a des exigences spécifiques

  • Solution de contournement : si vous utilisez un dépôt privé pour pré-extraire les images pour le déploiement ou la mise à niveau du cluster Big Data, vérifiez que les images de builds actuelles et cibles sont dans le dépôt privé. Cela permet une restauration réussie, si nécessaire. En outre, si vous avez modifié les informations d’identification du dépôt privé depuis le déploiement d’origine, mettez à jour le secret correspondant dans Kubernetes avant de procéder à la mise à niveau. Azure Data CLI (azdata) ne prend pas en charge la mise à jour des informations d’identification par le biais des variables d’environnement AZDATA_PASSWORD et AZDATA_USERNAME. Mettez à jour le secret à l’aide de kubectl edit secrets.

La mise à niveau avec des dépôts différents pour les builds actuelles et cibles n’est pas prise en charge.

La mise à niveau peut échouer en raison du délai d’expiration.

  • Versions concernées : GDR1, CU1, CU2. Résolu pour CU 3.

  • Problème et effet sur le client : une mise à niveau peut échouer en raison de l’expiration du délai d’attente.

    Le code suivant montre à quoi peut ressembler l’échec :

    > azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

    Cette erreur est plus susceptible de se produire lorsque vous mettez à niveau le Clusters Big Data SQL Server 2019 dans Azure Kubernetes Service (AKS).

  • Solution de contournement : Augmentez le délai d’expiration de la mise à niveau.

    Pour augmenter les délais d’attente pour une mise à niveau, modifiez le mappage de configuration de mise à niveau. Pour modifier le mappage de configuration de mise à niveau :

    1. Exécutez la commande suivante :

      kubectl edit configmap controller-upgrade-configmap

    2. Modifiez les champs suivants :

      controllerUpgradeTimeoutInMinutes Spécifie le nombre de minutes à attendre avant la fin de la mise à niveau du contrôleur ou de la base de données du contrôleur. La valeur par défaut est 5. Mettez à jour vers au moins 20.

      totalUpgradeTimeoutInMinutes : désigne la durée combinée du contrôleur et de la base de données du contrôleur pour terminer la mise à niveau (mise à niveau controller + controllerdb). La valeur par défaut est 10. Mettez à jour vers au moins 40.

      componentUpgradeTimeoutInMinutes : Désigne la durée d’exécution de chaque phase suivante de la mise à niveau. La valeur par défaut est 30. Mettez à jour vers 45.

    3. Enregistrez et quittez.

    Le script Python suivant est une autre façon de définir le délai d’expiration :

    from kubernetes import client, config
import json

def set_upgrade_timeouts(namespace, controller_timeout=20, controller_total_timeout=40, component_timeout=45):
     """ Set the timeouts for upgrades

     The timeout settings are as follows

     controllerUpgradeTimeoutInMinutes: sets the max amount of time for the controller
         or controllerdb to finish upgrading

     totalUpgradeTimeoutInMinutes: sets the max amount of time to wait for both the
         controller and controllerdb to complete their upgrade

     componentUpgradeTimeoutInMinutes: sets the max amount of time allowed for
         subsequent phases of the upgrade to complete
     """
     config.load_kube_config()

     upgrade_config_map = client.CoreV1Api().read_namespaced_config_map("controller-upgrade-configmap", namespace)

     upgrade_config = json.loads(upgrade_config_map.data["controller-upgrade"])

     upgrade_config["controllerUpgradeTimeoutInMinutes"] = controller_timeout

     upgrade_config["totalUpgradeTimeoutInMinutes"] = controller_total_timeout

     upgrade_config["componentUpgradeTimeoutInMinutes"] = component_timeout

     upgrade_config_map.data["controller-upgrade"] = json.dumps(upgrade_config)

     client.CoreV1Api().patch_namespaced_config_map("controller-upgrade-configmap", namespace, upgrade_config_map)

Échec de l’envoi de tâches Livy à partir d’Azure Data Studio (ADS) ou de curl avec l’erreur 500

  • Problème et effet sur le client : dans une configuration HA, les ressources partagées Spark sparkhead sont configurées avec plusieurs réplicas. Dans ce cas, vous pouvez rencontrer des échecs lors de l’envoi de tâches Livy à partir d’Azure Data Studio (ADS) ou de curl. Pour vérifier, une opération curl vers n’importe quel pod sparkhead entraîne un refus de connexion. Par exemple, curl https://sparkhead-0:8998/ ou curl https://sparkhead-1:8998 retourne l’erreur 500.

    Ceci est le cas dans les scénarios suivants :

    • Les pods ou les processus Zookeeper pour chaque instance Zookeeper sont redémarrés plusieurs fois.
    • Lorsque la connectivité réseau n’est pas fiable entre le pod sparkhead et les pods Zookeeper.

  • Solution de contournement : Redémarrage des deux serveurs Livy.

    kubectl -n <clustername> exec sparkhead-0 -c hadoop-livy-sparkhistory supervisorctl restart livy

    kubectl -n <clustername> exec sparkhead-1 -c hadoop-livy-sparkhistory supervisorctl restart livy

Créer une table à mémoire optimisée lorsque l’instance maître est dans un groupe de disponibilité

  • Problème et effet sur le client : vous ne pouvez pas utiliser le point de terminaison principal exposé pour la connexion aux bases de données du groupe de disponibilité (écouteur) afin de créer des tables à mémoire optimisée.

  • Solution de contournement : Pour créer des tables à mémoire optimisée lorsque l’instance maître SQL Server est une configuration de groupe de disponibilité, connectez-vous à l’instance SQL Server, exposez un point de terminaison, connectez-vous à la base de données SQL Server et créez les tables à mémoire optimisée dans la session créée avec la nouvelle connexion.

Insérer dans des tables externes en mode d’authentification Active Directory

  • Problème et effet sur le client : quand l’instance maître SQL Server est en mode d’authentification Active Directory, une requête qui sélectionne uniquement dans des tables externes, où au moins une des tables figure dans un pool de stockage, et insère dans une autre table externe retourne :

Msg 7320, Level 16, State 102, Line 1 Cannot execute the query "Remote Query" against OLE DB provider "SQLNCLI11" for linked server "SQLNCLI11". Only domain logins can be used to query Kerberized storage pool.

  • Solution de contournement : Modifiez la requête de l’une des manières suivantes. Joignez d’abord la table de pool de stockage à une table locale, ou insérez dans la table locale, puis lisez la table locale pour l’insérer dans le pool de données.

Les fonctionnalités de Transparent Data Encryption ne peuvent pas être utilisées avec des bases de données qui font partie du groupe de disponibilité dans l’instance maître SQL Server

  • Problème et effet sur le client : dans une configuration HA, les bases de données qui ont le chiffrement activé ne peuvent pas être utilisées après un basculement, car la clé principale utilisée pour le chiffrement est différente sur chaque réplica.

  • Solution de contournement : Il n’existe aucun moyen de contourner ce problème. Nous vous recommandons de ne pas activer le chiffrement dans cette configuration tant qu’un correctif n’est pas en place.

Contenu connexe

Pour plus d’informations sur Clusters de Big Data SQL Server 2019, consultez Présentation des Clusters de Big Data SQL Server 2019.