FAQ sur les clusters Big Data SQL Server

Il y a moins de flexibilité en comparaison de la configuration de SQL Server sur des ordinateurs nus sur Windows ou Linux. Dans l’environnement Kubernetes, ces artefacts sont abstraits et doivent être portables. Actuellement, 2 volumes persistants, un pour les données et un pour les journaux, sont fournis pour chaque pod et peuvent être configurés. Pour plus d’informations, consultez Persistance des données avec un cluster Big Data SQL Server sur Kubernetes.

Vous devez effectuer des sauvegardes des journaux seulement pour les bases de données utilisateur dans l’instance maître SQL Server (en fonction du modèle de récupération ou de la configuration de la haute disponibilité). Les bases de données du pool de données utilisent seulement le modèle de récupération SIMPLE. Il en va de même pour les bases de données DW* créées pour PolyBase.

Vous pouvez utiliser les vues de gestion dynamiques existantes de PolyBase, qui ont été améliorées pour les scénarios de Cluster Big Data. Pour plus d’informations, consultez Superviser et résoudre les problèmes de PolyBase.

Même si vous pouvez modifier certains paramètres en utilisant l’API Kubernetes ou kubectl, ce n’est pas pris en charge ni recommandé. Vous devez effectuer toutes les opérations de gestion de Cluster Big Data via azdata.

Vous pouvez utiliser les solutions qui permettent la capture instantanée du stockage au niveau du matériel ou la copie/synchronisation via webHDFS. Vous pouvez aussi utiliser azdata bdc hdfs cp. Pour plus d’informations, consultez azdata bdc hdfs.

Pas pour l'instant. Une option est de déployer SQL Server dans un groupe de disponibilité Always On. Vous pouvez ensuite utiliser un ou plusieurs réplicas secondaires accessibles en lecture pour exécuter certains processus (par exemple de l’entraînement/scoring pour du machine learning, des activités de maintenance, etc.).

Ce scénario n’est pas pris en charge pour l’instant.

La base de données de l’instance du pool de données n’a pas de métadonnées sur les tables externes : elle est similaire à une base de données utilisateur. Vous pouvez effectuer des sauvegardes/restaurations, mais pour éviter des résultats incohérents, vous devez vérifier que les métadonnées des tables externes dans la base de données de métadonnées de l’instance maître SQL sont synchronisées.

Le pool de données est un concept de table distribuée. Le partitionnement est généralement considéré comme un concept d’OLTP : ce n’est actuellement pas pris en charge.

Le terme « pool » est réservé pour décrire une collection de services ou d’applications homogènes. Par exemple, un pool de données est un ensemble de ressources de calcul et de stockage SQL Server avec état, et un pool de stockage est un ensemble de services HDFS et Spark. L’instance maître SQL Server est une seule instance unique ou plusieurs instances qui peuvent être configurées dans un groupe de disponibilité. L’instance maître SQL Server est une instance SQL Server normale sur Linux, et vous pouvez y utiliser n’importe quelle fonctionnalité disponible sur Linux. Commencez par le modèle de données, les entités et les services/applications qui vont effectuer des opérations principalement sur l’entité. Toutes les données ne doivent pas nécessairement être stockées à un même emplacement, comme SQL Server ou HDFS, ou un pool de données. En fonction de l’analyse des données, il est possible de stocker la plupart des données dans HDFS, de traiter les données à un format plus efficace et de les exposer à d’autres services. Les données restantes peuvent être stockées dans l’instance maître SQL.

Ce scénario n’est pas pris en charge pour l’instant.

Chaque pod ne peut avoir que deux volumes persistants. Vous pouvez abstraire le volume au niveau du système d’exploitation et l’utiliser pour le stockage persistant. Par exemple, vous pouvez créer une partition de système d’exploitation RAID 0 en utilisant plusieurs disques et l’utiliser pour le volume persistant avec un outil de provisionnement de stockage local. Il n’existe aujourd’hui aucun moyen d’utiliser davantage de volumes persistants. Les volumes persistants sont mappés aux répertoires à l’intérieur du conteneur et ceci est fixe. Pour plus d’informations sur les volumes persistants, consultez Volumes persistants dans la documentation Kubernetes.

Vous pouvez configurer un pool de stockage pour qu’il utilise une classe de stockage spécifique au moment du déploiement. Consultez Persistance des données avec un cluster Big Data SQL Server sur Kubernetes.

La hiérarchisation HDFS nous permet d’effectuer de façon transparente l’intégration aux protocoles basés sur S3. Pour plus d’informations, consultez Guide pratique pour monter S3 pour la hiérarchisation HDFS dans un cluster Big Data.

Oui, les données sont conservées, car elles se trouvent sur des volumes persistants et la mise à niveau déploie seulement des pods existants avec de nouvelles images.

Avec la hiérarchisation HDFS, les données sont mises en cache dans le HDFS local exécuté dans Cluster Big Data pour permettre aux utilisateurs de s’attacher à de grands lacs de données sans devoir importer toutes les données. La quantité d’espace allouée au cache est actuellement définie par défaut sur 2 %. Les données sont conservées dans le cache, mais sont supprimées si ce seuil est dépassé. La sécurité définie au niveau du lac est également maintenue et toutes les listes de contrôle d’accès sont appliquées. Pour plus d’informations, consultez Configurer la hiérarchisation HDFS sur Clusters Big Data.

Oui, vous pouvez virtualiser les données stockées dans ADLS Gen2 en utilisant la hiérarchisation HDFS. Une fois la hiérarchisation HDFS montée sur ADLS Gen2, les utilisateurs ont la possibilité d’interroger les données HDFS et d’exécuter des travaux Spark sur celles-ci. Le stockage monté apparaît dans le cluster HDFS pour un cluster Big Data à l’emplacement spécifié par --mount-path, et les utilisateurs peuvent utiliser ce chemin de montage comme s’ils travaillaient avec un stockage local. Pour plus d’informations, consultez Configurer la hiérarchisation HDFS sur Cluster Big Data. Pour plus d’informations sur les autorisations des niveaux HDFS, consultez Gérer les autorisations HDFS pour Clusters Big Data SQL Server.

Le plan de contrôle AKS prend en charge un contrat SLA de durée de bon fonctionnement avec une disponibilité de 99,95 %. Les nœuds de cluster AKS (nœuds Worker) utilisent des zones de disponibilité. Pour plus d’informations, consultez Zones de disponibilité AKS. Une zone de disponibilité est une offre de haute disponibilité d’Azure qui protège les applications et les données contre les défaillances des centres de données. AKS prend en charge une disponibilité de 99,9 % pour les clusters qui n’utilisent pas les zones de disponibilité. Pour plus d’informations, consultez le contrat SLA pour Azure Kubernetes Service (AKS).

Le redémarrage de sparkhead n’entraîne pas la perte des journaux, car ces journaux se trouvent dans HDFS. Vous devez normalement voir les journaux d’historique Spark à partir de l’interface utilisateur /gateway/default/sparkhistory. Pour les journaux des conteneurs YARN, vous ne verrez pas ces applications dans l’interface utilisateur de YARN en raison du redémarrage de YARN RM, mais ces journaux YARN sont néanmoins encore dans HDFS et vous pouvez établir un lien vers ceux-ci depuis le serveur d’historique Spark. Vous devez toujours utiliser le serveur d’historique Spark comme point d’entrée pour diagnostiquer ses applications Spark.

Par défaut, 1 % du stockage HDFS total est réservé à la mise en cache des données montées. La mise en cache est un paramètre global sur les montages. Actuellement, il n’existe pas de méthode exposée pour la désactiver. Cependant, le pourcentage peut être configuré via le paramètre hdfs-site.dfs.provided.cache.capacity.fraction. Ce paramètre contrôle la fraction de la capacité totale du cluster qui peut être utilisée pour mettre en cache des données provenant des magasins fournis. Pour le modifier, consultez Guide pratique pour configurer les paramètres de Cluster Big Data après le déploiement. Pour plus d’informations, consultez Configurer la hiérarchisation HDFS sur Clusters Big Data SQL Server.

Vous pouvez utiliser le service SQL Server Agent dans l’instance maître SQL Server du cluster Big Data.

Pour le moment, InfluxDB dans un cluster Big Data est utilisé seulement pour stocker les données de supervision collectées au sein du cluster Big Data et n’est pas exposé en tant que point de terminaison externe.

Pour le moment, InfluxDB dans un cluster Big Data est utilisé seulement pour stocker les données de supervision collectées au sein du cluster Big Data et n’est pas exposé en tant que point de terminaison externe.

Dans Cluster Big Data, la configuration de la haute disponibilité crée un groupe de disponibilité appelé containedag, qui comprend également des bases de données système répliquées sur des réplicas. Les bases de données créées avec un workflow CREATE DATABASE ou RESTORE sont automatiquement ajoutées au groupe de disponibilité contenu et amorcées. Avant SQL Server 2019 (15.0) CU2, vous devez vous connecter à l’instance physique dans Cluster Big Data, restaurer la base de données et l’ajouter au containedag. Pour plus d’informations, consultez Déployer Cluster Big Data SQL Server avec la haute disponibilité.

Pour l’instant, vous pouvez définir la mémoire pour les instances SQL en utilisant sp_configure, exactement comme dans SQL Server. Pour les cœurs, vous pouvez utiliser ALTER SERVER CONFIGURATION SET PROCESS AFFINITY. Par défaut, les conteneurs voient tous les processeurs de l’hôte et nous n’avons, pour l’instant, pas de moyen de spécifier des limites de ressources à l’aide de Kubernetes. Pour le pool de calcul/pool de données/pool de stockage, la configuration peut être effectuée en utilisant l’instruction EXECUTE AT DATA_SOURCE depuis l’instance maître SQL Server.

Les pods sans définition d’affinité pour un nœud Worker seront déplacés sur un autre nœud du cluster Kubernetes, à condition qu’il y ait des ressources suffisantes. Sinon, le ou les pods seront indisponibles, ce qui va entraîner des interruptions.

Cette action dépend seulement de Kubernetes. Hormis le placement des pods en utilisant des étiquettes de nœud, il n’existe pas d’autre mécanisme pour contrôler le rééquilibrage des ressources Kubernetes depuis Cluster Big Data.

Cette action équivaut à l’arrêt du nœud hôte. Il existe des mécanismes pour orchestrer cela dans Kubernetes en utilisant un processus de repoussement, qui est généralement appliqué pour la mise à niveau ou la maintenance des nœuds. Pour plus d’informations, consultez la documentation Kubernetes pour les Repoussements et tolérances.

Oui, le facteur de réplication est une des configurations disponibles pour HDFS. Pour plus d’informations, consultez Configurer des volumes persistants.

Cela dépend de vos cas d’utilisation et de vos spécifications. Cluster Big Data fournit une surface d’exposition SQL Server complète en plus de la prise en charge par Microsoft de Spark et de HDFS en local. Cluster Big Data permet aux clients utilisant SQL Server de s’intégrer à l’analytique et/ou au Big Data. Azure Synapse est une plateforme d’analytique pure offrant une expérience de premier ordre aux clients sous la forme d’un service managé dans le cloud, mettant l’accent sur l’analytique avec scale-out. Azure Synapse ne cible pas une charge de travail opérationnelle dans ce cadre. Cluster Big Data est destiné à fournir des scénarios d’analytique de base de données, beaucoup plus proches du magasin opérationnel.

Les fichiers de base de données de l’instance SQL Server ne sont pas stockés dans HDFS, mais SQL Server peut interroger HDFS en utilisant une interface de table externe.

ROUND_ROBIN et REPLICATED. ROUND_ROBIN est l’option par défaut. HASH n’est pas disponible.

Nous exposons actuellement le metastore Hive via le protocole Thrift. Nous documentons le protocole, mais nous n’avons pas ouvert de point de terminaison ODBC pour l’instant. Vous pouvez y accéder via le protocole HTTP du metastore Hive. Pour plus d’informations, consultez Protocole HTTP du metastore Hive.

SQL Server sur Linux (s’applique également à l’instance maître SQL Server dans Cluster Big Data) ne prend pas en charge la source de données ODBC générique qui vous permet d’installer un pilote ODBC tiers (SnowFlake, DB2, PostgreSQL, etc.) et de les interroger. Cette fonctionnalité est actuellement disponible seulement dans SQL Server 2019 (15.0) sur Windows. Dans Cluster Big Data, vous pouvez lire les données via Spark en utilisant JDBC et les ingérer dans SQL Server en utilisant le connecteur MSSQL Spark.

SQL Server sur Linux (s’applique également à l’instance maître SQL Server dans Cluster Big Data) ne prend pas en charge la source de données ODBC générique qui vous permet d’installer un pilote ODBC tiers (SnowFlake, DB2, PostgreSQL, etc.) et de les interroger.

Vous pouvez utiliser l’approche INSERT..SELECT pour éviter d’avoir besoin d’une nouvelle table à chaque fois.

Si votre instance maître SQL Server a suffisamment de ressources pour traiter votre charge de travail analytique, c’est toujours l’option la plus rapide. Un pool de données va vous aider si vous voulez décharger l’exécution sur d’autres instances SQL pour vos requêtes distribuées. Vous pouvez aussi utiliser un pool de données pour ingérer des données provenant d’exécuteurs Spark en parallèle à différentes instances SQL : les performances de chargement pour des grands jeux de données générés à partir du système de fichiers distribué Hadoop (HDFS) sont donc généralement préférables à l’utilisation d’une instance SQL Server unique. C’est cependant assez difficile à déterminer, car vous pourriez néanmoins avoir plusieurs tables dans SQL Server et les insérer en parallèle si vous le souhaitez. Les performances dépendent de nombreux facteurs, et il n’y a pas de règle ou de recommandation simple à cet égard.

Vous pouvez utiliser EXECUTE AT pour interroger des vues de gestion dynamiques comme sys.dm_db_partition_stats pour obtenir les données de chaque table locale.

Non, vous pouvez utiliser azdata bdc hdfs cp. Si vous spécifiez le répertoire racine, la commande va copier de façon récursive l’arborescence entière. Vous pouvez copier en entrée/sortie en utilisant cette commande en changeant simplement les chemins source/cible.

Vous pouvez utiliser la bibliothèque de connecteurs MSSQL Spark pour faciliter l’ingestion avec SQL et le pool de données. Pour une procédure pas à pas guidée, consultez Tutoriel : Ingérer des données dans un pool de données SQL Server avec des travaux Spark.

Essayez azdata bdc hdfs cp. Si vous spécifiez le répertoire racine, la commande va copier de façon récursive l’arborescence entière. Vous pouvez copier en entrée/sortie en utilisant cette commande en changeant simplement les chemins source/cible.

Il n’existe pas pour l’instant d’interface azdata pour effectuer cette opération. Vous avez la possibilité de redimensionner manuellement les PVC souhaités. Le redimensionnement est une opération complexe : consultez la documentation sur les volumes persistants dans Kubernetes.

Découvrez les principales différences et des cas d’usage ici : Forum aux questions sur PolyBase.

Cluster Big Data prend en charge la virtualisation des données provenant de sources ODBC : SQL Server, Oracle, MongoDB, Teradata, etc. Il prend également en charge la hiérarchisation des magasins distants comme Azure Data Lake Store Gen2 et le stockage compatible S3 ainsi que AWS S3A et ABFS (Azure Blob File System).

Oui, vous pouvez utiliser PolyBase dans Cluster Big Data pour accéder aux données dans Azure SQL Database.

En général, le mot clé EXTERNAL implique que les données ne se trouvent pas dans l’instance SQL Server. Par exemple, vous pouvez définir une table de pool de stockage au-dessus d’un répertoire HDFS. Les données sont stockées dans des fichiers HDFS et non pas dans vos fichiers de base de données, mais la table externe vous a fourni l’interface nécessaire pour interroger des fichiers HDFS en tant que table relationnelle comme s’ils se trouvaient dans la base de données.
Ce concept d’accès aux données externes est appelé « virtualisation des données ». Pour plus d’informations, consultez Présentation de la virtualisation des données avec PolyBase. Pour un tutoriel sur la virtualisation des données provenant de fichiers CSV dans HDFS, consultez [Virtualiser des données CSV provenant d’un pool de stockage Clusters Big Data.

Pour une comparaison, consultez Comparaison entre PolyBase dans Clusters Big Data et PolyBase dans des instances autonomes.

Vous pouvez déterminer le type de table externe en examinant le préfixe de l’emplacement de la source de données, par exemple sqlserver://, oracle://, sqlhdfs://, sqldatapool://.

Consultez Gérer Clusters Big Data SQL Server avec des notebooks Azure Data Studio. Consultez également les rubriques de dépannage dans Résoudre les problèmes de Kubernetes.

Toutes les personnalisations qui peuvent être effectuées au moment du déploiement sont documentées ici dans Configurer les paramètres de déploiement pour les ressources et les services des clusters. Pour Spark, consultez Configurer Apache Spark et Apache Hadoop dans Clusters Big Data.

Non. En l’occurrence, SQL Server Analysis Services (SSAS) n’est pas pris en charge sur SQL Server sur Linux : vous devez donc installer une instance SQL Server sur Windows Server pour exécuter SSAS.

Cluster Big Data peut s’exécuter sur n’importe quelle pile Kubernetes basée sur la version 1.13 et ultérieure. Cependant, nous n’avons pas effectué de validations spécifiques de Cluster Big Data sur EKS ou GKS.

La version de Spark est 2.4 et celle de HDFS est 3.2.1. Pour plus d’informations sur le logiciel open source inclus dans Cluster Big Data, consultez Informations de référence sur les logiciels open source.

Vous pouvez ajouter des packages lors de l’envoi d’un travail en utilisant les étapes de l’exemple de notebook pour l’installation de packages dans Spark.

Les services Machine Learning (R et Python) sont disponibles à compter de SQL Server 2017. Les services Machine Learning sont également disponibles dans Clusters Big Data SQL Server. Pour plus d’informations, consultez Qu’est-ce que SQL Server Machine Learning Services avec Python et R ?.

Reportez-vous au guide des licences qui contient bien plus de détails : téléchargez le PDF.
Pour obtenir un résumé, regardez la vidéo Gestion des licences SQL Server : Clusters Big Data | Données exposées.

Pas pour l'instant.

Oui, vous pouvez vous connecter aux différents services Cluster Big Data en utilisant l’authentification intégrée (avec Active Directory). Pour plus d’informations, consultez Déployer Cluster Big Data SQL Server en mode Active Directory. Consultez également Concepts de sécurité pour Clusters Big Data.

En mode d’authentification de base (nom d’utilisateur/mot de passe), il n’y a pas de prise en charge de l’ajout de plusieurs utilisateurs pour les points de terminaison de contrôleur ou de passerelle Knox/HDFS. Le seul utilisateur pris en charge pour ces points de terminaison est root. Pour SQL Server, vous pouvez ajouter des utilisateurs en utilisant Transact-SQL, comme vous le feriez pour n’importe quelle autre instance SQL Server. Si vous déployez Cluster Big Data avec l’authentification AD pour ses points de terminaison, l’ajout de plusieurs utilisateurs est pris en charge. Pour plus d’informations sur la configuration des groupes AD au moment du déploiement, consultez ceci. Pour plus d’informations, consultez Déployer Cluster Big Data SQL Server en mode Active Directory.

Vous pouvez examiner les adresses IP utilisées par les différents services dans Plages d’adresses IP Azure et étiquettes des services - Cloud public. Notez que ces adresses IP font l’objet de rotations périodiques.
Pour que le service de contrôleur puisse extraire les images conteneur du Microsoft Container Registry (MCR), vous devez accorder l’accès aux adresses IP spécifiées dans la section MicrosoftContainerRegistry. Une autre option est de configurer un registre Azure Container Registry privé et de configurer le cluster Big Data pour effectuer l’extraction à partir de là. Dans ce cas, vous devez exposer les adresses IP spécifiées dans la section AzureContainerRegistry. Des instructions sur la façon de procéder et un script sont fournis dans Effectuer un déploiement hors connexion d’un cluster Big Data SQL Server.

Oui. Pour plus d’informations, consultez Effectuer un déploiement hors connexion d’un cluster Big Data SQL Server.

Cela dépend des configurations de l’outil de provisionnement de stockage dynamique dans Azure Kubernetes Service (AKS). Pour plus d’informations, consultez Bonnes pratiques relatives au stockage et aux sauvegardes dans Azure Kubernetes Service (AKS).

Oui. Pour plus d’informations, consultez Versions des clés dans Cluster Big Data.

Oui, vous pouvez facilement pivoter les mots de passe des objets Active Directory générés automatiquement avec une nouvelle fonctionnalité introduite les clusters Big Data SQL Server CU13. Pour plus d’informations, consultez Rotation de mot de passe AD.

Oui, Microsoft prend en charge tous les composants livrés dans les clusters Big Data.

La stratégie de prise en charge de SQL Server Machine Learning Services est identique à celle de SQL Server, sauf que chaque version majeure est fournie avec une nouvelle version du runtime. La bibliothèque SparkML est elle-même un logiciel open source. Nous empaquetons de nombreux composants logiciels open source dans Cluster Big Data et ceci est pris en charge par Microsoft.

Pas pour l'instant. Consultez cette page pour connaître les configurations testées.

Oui, c’est le même noyau Jupyter que celui exposé dans Azure Data Studio.

Non, azdata n’est pas open source pour l’instant.

Voici quelques ressources que vous pouvez utiliser :
Atelier : Kubernetes - Des systèmes nus à Clusters Big Data SQL Server
Atelier : Clusters Big Data SQL Server - Architecture
Didacticiel : préparer une application pour Azure Kubernetes Service (AKS)

(PDF)Étude de cas : Charges de travail SQL exécutées sur Apache Spark dans Cluster Big Data MS SQL Server 2019

Voir aussi

• Clusters Big Data SQL Server