Partager via


Configurer un cluster Big Data SQL Server - Version antérieure à CU9

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.

Dans les versions CU8 et antérieures des clusters de Big Data SQL Server 2019, vous pouvez configurer les paramètres au moment du déploiement à l’aide du fichier bdc.json de déploiement. L’instance maître de SQL Server peut être configurée après le déploiement à l’aide de mssql-conf uniquement.

Notes

Avant la version CU9 et la prise en charge des clusters avec configuration activée, les clusters Big Data pouvaient être configurés uniquement au moment du déploiement, à l’exception de l’instance maître de SQL Server, qui pouvait être configurée après le déploiement uniquement à l’aide de mssql-conf. Pour obtenir des instructions sur la configuration d’une version CU9 et ultérieure, consultez Configurer un cluster Big Data SQL Server.

Étendues de configuration

La configuration des clusters Big Data de version antérieure à CU9 offre deux niveaux d’étendue : service et resource. La hiérarchie des paramètres suit également cet ordre, de la plus élevée à la plus faible. Les composants Clusters Big Data prennent la valeur du paramètre défini avec la portée la plus faible. Un paramètre dont la portée n’est pas définie hérite de la valeur de la portée parente supérieure.

Vous pouvez, par exemple, définir le nombre de cœurs par défaut utilisé par le pilote Spark dans le pool de stockage et les ressources Sparkhead. Il existe deux méthodes pour le faire :

  • Spécifier une valeur de cœurs par défaut à la portée du service Spark
  • Spécifier une valeur de cœurs par défaut à la portée des ressources storage-0 et sparkhead

Dans le premier scénario, toutes les ressources du service Spark dont l’étendue est inférieure (pool de stockage et Sparkhead) héritent du nombre de cœurs par défaut défini par la valeur par défaut du service Spark.

Dans le second scénario, chaque ressource emploie la valeur définie comme sa propre portée.

Si le nombre de cœurs par défaut est configuré à la fois à la portée du service et à celle de la ressource, la valeur de portée ressource écrase celle de portée service, car il s’agit de la plus petite portée configurée par l’utilisateur pour le paramètre.

Pour obtenir des informations spécifiques sur la configuration, consultez les articles appropriés :

Configurer l’instance maître de SQL Server

Configurez l’instance maître des Clusters Big Data SQL Server.

Impossible de configurer les paramètres de configuration du serveur pour l’instance maître SQL Server au moment du déploiement. Cet article décrit une solution de contournement temporaire sur la manière de configurer des paramètres tels que l’édition SQL Server, d’activer ou de désactiver SQL Server Agent, d’activer des indicateurs de trace spécifiques ou d’activer/de désactiver les commentaires des clients.

Pour modifier l’un de ces paramètres, procédez comme suit :

  1. Créez un fichier mssql-custom.conf personnalisé qui comprend les paramètres ciblés. L’exemple suivant active le service SQL Agent, la télémétrie, définit un PID pour Édition Entreprise et active l’indicateur de trace 1204. :

    [sqlagent]
    enabled=true
    
    [telemetry]
    customerfeedback=true
    userRequestedLocalAuditDirectory = /tmp/audit
    
    [DEFAULT]
    pid = Enterprise
    
    [traceflag]
    traceflag0 = 1204
    
  2. Copiez le fichier mssql-custom.conf dans /var/opt/mssql dans le conteneur mssql-server du pod master-0. Remplacez <namespaceName> par le nom du cluster Big Data.

    kubectl cp mssql-custom.conf master-0:/var/opt/mssql/mssql-custom.conf -c mssql-server -n <namespaceName>
    
  3. Redémarrez l’instance SQL Server. Remplacez <namespaceName> par le nom du cluster Big Data.

    kubectl exec -it master-0  -c mssql-server -n <namespaceName> -- /bin/bash
    supervisorctl restart mssql-server
    exit
    

Important

Si l’instance maître SQL Server est dans une configuration de groupes de disponibilité, copiez le fichier mssql-custom.conf dans toutes les pods master. Notez que chaque redémarrage entraînant un basculement, vous devez veiller à planifier cette activité pendant les périodes d’inactivité.

Limitations connues

  • Les étapes ci-dessus nécessitent des autorisations d’administrateur de cluster Kubernetes
  • Vous ne pouvez pas modifier le classement du serveur pour l’instance maître SQL Server du cluster Big Data après le déploiement.

Configurer Apache Spark et Apache Hadoop

Pour configurer Apache Spark et Apache Hadoop dans des clusters Big Data, vous devez modifier le profil des clusters au moment du déploiement.

Un cluster Big Data comporte quatre catégories de configuration :

  • sql
  • hdfs
  • spark
  • gateway

sql, hdfs, spark et sql sont des services. À chacun d’eux est associée une catégorie de configuration du même nom. Toutes les configurations de passerelle sont affectées à la catégorie gateway.

Par exemple, toutes les configurations dans le service hdfs appartiennent à la catégorie hdfs. Notez que toutes les configurations Hadoop (core-site), HDFS et ZooKeeper appartiennent à la catégorie hdfs, et toutes les configurations Livy, Spark, YARN, Hive et Metastore à la catégorie spark.

La page Configurations prises en charge répertorie les propriétés Apache Spark & Hadoop que vous pouvez configurer lorsque vous déployez un cluster Big Data SQL Server.

Les sections suivantes répertorient les propriétés que vous ne pouvez pas modifier dans un cluster :

Étapes suivantes

Configurer un cluster Big Data SQL Server