Partager via

Principes de base de la disponibilité SQL Server pour les déploiements Linux

  • Article

S’applique à : SQL Server - Linux

À partir de SQL Server 2017 (14.x), SQL Server est pris en charge sur Linux et sur Windows. Comme les SQL Serverdéploiements SQL Server basés sur Windows, les bases de données et les instances doivent être hautement disponibles sous Linux. Cet article aborde les aspects techniques de la planification et du déploiement de bases de données et d’instances SQL Server basées sur Linux à haut niveau de disponibilité, ainsi que certaines des différences par rapport aux installations Windows. Comme SQL Server peut être une nouveauté pour les professionnels Linux et que Linux peut être une nouveauté pour les professionnels SQL Server, l’article présente parfois des concepts pouvant être familiers aux uns et ne pas l’être aux autres.

SQL Server options de disponibilité pour les déploiements Linux

Outre la sauvegarde et la restauration, les trois mêmes fonctionnalités de disponibilité sont disponibles sur Linux comme pour les déploiements basés sur Windows :

Sur Windows, les instances de cluster de basculement (FCI) exigent une instance de cluster de basculement Windows Server (WSFC) sous-jacente. Selon le scénario de déploiement, un groupe de disponibilité requiert généralement un WSFC sous-jacent, à l’exception de la nouvelle variante None dans SQL Server 2017 (14.x). Il n’existe pas de WSFC dans Linux. L’implémentation du clustering dans Linux est abordée dans la section Pacemaker pour les groupes de disponibilité et les instances de cluster de basculement sur Linux.

Première initiation rapide à Linux

Certaines installations Linux peuvent être installées avec une interface, mais la plupart ne le sont pas. Cela signifie que presque toutes les opérations au niveau de la couche du système d’exploitation s’effectuent via la ligne de commande. Le terme courant pour cette ligne de commande dans l’environnement Linux est shell bash.

Dans Linux, de nombreuses commandes doivent être exécutées avec des privilèges élevés, comme de nombreuses choses qui doivent être effectuées dans Windows Server en tant qu’administrateur. Il existe deux méthodes principales d’exécution avec des privilèges élevés :

  1. Exécuter dans le contexte de l’utilisateur approprié. Pour passer à un autre utilisateur, utilisez la commande su. Si su est exécuté seul sans nom d'utilisateur, tant que vous connaissez le mot de passe, vous êtes dans un shell comme root.

  2. La manière la plus courante et la plus respectueuse de la sécurité d'exécuter les choses consiste à utiliser sudo avant d’exécuter quoi que ce soit. De nombreux exemples dans cet article utilisent sudo.

Voici certaines commandes courantes, chacune ayant plusieurs commutateurs et options qui peuvent être recherchés en ligne :

  • cd - modifier le répertoire
  • chmod - modifier les autorisations d’un fichier ou d’un répertoire
  • chown - modifier la propriété d’un fichier ou d’un répertoire
  • ls - afficher le contenu d'un répertoire
  • mkdir - créer un dossier (répertoire) sur un lecteur
  • mv - déplacer un fichier d'un emplacement à un autre
  • ps - afficher tous les processus de travail
  • rm - supprimer un fichier localement sur un serveur
  • rmdir - supprimer un dossier (répertoire)
  • systemctl - démarrer, arrêter ou activer des services
  • Commandes de l’éditeur de texte. Sur Linux, il existe différentes options de l’éditeur de texte, telles que vi et emacs.

Tâches courantes relatives aux configurations de disponibilité de SQL Server sur Linux

Cette section traite des tâches qui sont communes à tous les déploiements SQL Server basés sur Linux.

Vérifiez que les fichiers peuvent être copiés

La copie de fichiers d’un serveur à un autre est une tâche que toute personne utilisant SQL Server sur Linux doit pouvoir effectuer. Cette tâche est très importante pour les configurations des groupes de disponibilité.

Certains incidents comme des problèmes d’autorisation peuvent survenir sur des installations Linux comme Windows. Toutefois, ceux qui sont familiarisés avec la procédure de copie d’un serveur à l’autre sur Windows n’ont peut-être pas connaissance de la façon de le faire sur Linux. Une méthode courante consiste à utiliser l’utilitaire de ligne de commande scp, qui correspond à la copie sécurisée. En arrière-plan, scp utilise OpenSSH. SSH est l’acronyme de Secure Shell. Selon la distribution Linux, OpenSSH lui-même n’est peut-être pas installé. OpenSSH doit d’abord être installé le cas échéant. Pour plus d’informations sur la configuration d’OpenSSH, consultez les informations sous les liens suivants pour chaque distribution :

Quand vous utilisez scp, vous devez fournir les informations d’identification du serveur s’il n’est ni la source ni la destination. Par exemple, l’utilisation de

scp MyAGCert.cer username@servername:/folder/subfolder

copie le fichier MyAGCert.cer dans le dossier spécifié sur l’autre serveur. Vous devez disposer des autorisations du fichier (et éventuellement en être propriétaire) pour le copier. il se peut donc que vous deviez également utiliser chown avant de le copier. De même, du côté de la réception, l’utilisateur approprié a besoin d’un accès pour manipuler le fichier. Par exemple, pour restaurer ce fichier de certificat, l’utilisateur mssql doit pouvoir y accéder.

Samba, qui est la variante Linux du protocole SMB (Server Message Block), peut également être utilisé pour créer des partages accessibles par des chemins d’accès UNC tels que \\SERVERNAME\SHARE. Pour plus d’informations sur la configuration de Samba, consultez les informations sous les liens suivants pour chaque distribution :

Les partages SMB sur Windows peuvent également être utilisés. Les partages SMB n’ont pas besoin d’être sur Linux tant que la partie cliente de Samba est configurée correctement sur le serveur Linux hébergeant SQL Server et que le partage dispose de l’accès approprié. Dans le cas d’un environnement mixte, cela permet d’utiliser l’infrastructure existante pour les déploiements SQL Server sur Linux.

Une chose importante est que la version de Samba déployée doit être compatible avec SMB 3.0. Lors de l’ajout de la prise en charge de SMB dans SQL Server 2012 (11.x), tous les partages sont nécessaires pour prendre en charge de SMB 3.0. Si Samba, et non Windows Server, est utilisé pour le partage, le partage basé sur Samba doit utiliser Samba 4.0 ou une version ultérieure, et dans l’idéal, 4.3 ou une version ultérieure qui prend en charge SMB 3.1.1. Une bonne source d’informations sur SMB et Linux est SMB3 dans Samba.

Enfin, l’utilisation d’un partage de système de fichiers réseau (NFS) est une option. NFS n’est pas une option sur les déploiements de SQL Server basés sur Windows. NFS peut être utilisé uniquement pour les déploiements sur Linux.

Configurer le pare-feu

Comme les distributions Windows, les distributions Linux ont un pare-feu intégré. Si votre entreprise utilise un pare-feu externe pour les serveurs, la désactivation des pare-feux dans Linux peut être acceptable. Cependant, quel que soit l’emplacement où le pare-feu est activé, les ports doivent être ouverts. Le tableau suivant répertorie les ports courants requis pour des déploiements SQL Server hautement disponibles sur Linux.

Numéro de port Type Description
111 TCP/UDP NFS - rpcbind/sunrpc
135 TCP Samba (si utilisé) - mappeur de point de terminaison
137 UDP Samba (si utilisé) - service de noms NetBIOS
138 UDP Samba (si utilisé) - datagramme NetBIOS
139 TCP Samba (si utilisé) - session NetBIOS
445 TCP Samba (si utilisé) - SMB sur TCP
1433 TCP SQL Server -port par défaut ; si vous le souhaitez, peut changer avec mssql-conf set network.tcpport <portnumber>
2049 TCP, UDP NFS (si utilisé)
2224 TCP Pacemaker - utilisé par pcsd
3121 TCP Pacemaker - requis s’il existe des nœuds Pacemaker distants
3260 TCP Initiateur iSCSI (si utilisé) - peut être changé en /etc/iscsi/iscsid.config (RHEL), mais doit correspondre au port de la cible iSCSI
5022 TCP SQL Server - port par défaut utilisé pour un point de terminaison de groupe de disponibilité ; peut être modifié lors de la création du point de terminaison
5403 TCP Pacemaker
5404 UDP Pacemaker : requis par Corosync si vous utilisez la multidiffusion UDP
5405 UDP Pacemaker : requis par Corosync
21064 TCP Pacemaker : requis par les ressources à l’aide de DLM
Variable TCP Port du point de terminaison du groupe de disponibilité ; la valeur par défaut est 5022
Variable TCP NFS : port pour LOCKD_TCPPORT (trouvé dans /etc/sysconfig/nfs sur RHEL)
Variable UDP NFS : port pour LOCKD_UDPPORT (trouvé dans /etc/sysconfig/nfs sur RHEL)
Variable TCP/UDP NFS : port pour MOUNTD_PORT (trouvé dans /etc/sysconfig/nfs sur RHEL)
Variable TCP/UDP NFS : port pour STATD_PORT (trouvé dans /etc/sysconfig/nfs sur RHEL)

Pour les ports supplémentaires qui peuvent être utilisés par Samba, consultez Utilisation des ports Samba.

À l’inverse, le nom du service sous Linux peut également être ajouté en tant qu’exception au lieu du port ; par exemple, high-availability pour Pacemaker. Reportez-vous à votre distribution pour les noms s’il s’agit de la direction que vous souhaitez poursuivre. Par exemple, sur RHEL, la commande à ajouter dans Pacemaker est

sudo firewall-cmd --permanent --add-service=high-availability

Documentation Pare-feu

Installer des packages SQL Server pour la disponibilité

Sur une installation SQL Server sur Windows, certains composants sont installés même dans le cas d’une installation du moteur de base, tandis que d’autres ne le sont pas. Sous Linux, seul le moteur SQL Server est installé dans le cadre du processus d’installation. Tout le reste est facultatif. Pour les instances SQL Server hautement disponibles sous Linux, deux packages doivent être installés avec SQL Server :

  • SQL Server Agent (mssql-server-agent)
  • Package haute disponibilité (HA) (mssql-server-ha)

Bien que SQL Server Agent soit techniquement facultatif, il s’agit du planificateur SQL Server pour les tâches et il est requis pour la copie des journaux de transaction. L’installation est donc recommandée.

Sur SQL Server 2017 (14.x) avec mise à jour cumulative CU 4 et versions ultérieures, SQL Server Agent est inclus dans le package du moteur de base de données. Toutefois, vous devez toujours l’activer. Sur les installations Windows, SQL Server Agent n’est pas facultatif.

Notes

Pour ceux qui sont nouveaux dans SQL Server, l’agent SQL Server est le planificateur de tâches intégré de SQL Server. Vous pouvez planifier des opérations telles que les sauvegardes et les autres opérations de maintenance SQL Server. Contrairement à une installation de SQL Server basée sur Windows, où l’agent SQL Server est un service complètement différent, sur Linux, l’agent SQL Server s’exécute dans le contexte de SQL Server proprement dit.

Quand les groupes de disponibilité ou les instance de cluster de basculement (FCI) sont configurés sur une configuration basée sur Windows, ils prennent en charge les clusters. La reconnaissance des clusters implique que SQL Server dispose des DLL de ressources spécifiques qu’un WSFC connaît (sqagtres.dll et sqsrvres.dll pour les instances de cluster de basculement, hadrres.dll pour les groupes de disponibilité) et qui sont utilisées par le WSFC pour s’assurer que la fonctionnalité en cluster SQL Server est opérationnelle, qu’elle s’exécute et fonctionne correctement. Étant donné que le clustering est externe non seulement à SQL Server, mais à Linux proprement dit, Microsoft a dû coder l’équivalent d’une DLL de ressource pour les déploiements de groupes de disponibilité et d’instances de cluster de basculement (FCI) basés sur Linux. Il s’agit du package mssql-server-ha, également appelé agent de ressources SQL Server pour Pacemaker. Pour installer le package mssql-server-ha, consultez Déployer un cluster Pacemaker pour SQL Server sur Linux.

Les autres packages facultatifs pour SQL Server sur Linux, la recherche en texte intégral SQL Server (mssql-server-fts) et SQL Server Integration Services (mssql-server-is), ne sont pas requis pour la haute disponibilité, que ce soit pour une instance de cluster de basculement (FCI) ou un groupe de disponibilité.

Partenaires pour la haute disponibilité et la récupération d’urgence de SQL Server

Pour fournir la haute disponibilité et la récupération d’urgence pour vos services SQL Server, vous pouvez choisir parmi un large éventail d’outils de pointe. Cette section présente les sociétés partenaires de Microsoft offrant des solutions de haute disponibilité et récupération d’urgence qui prennent en charge SQL Server.

Partenaire Description
DH2i DxEnterprise est un logiciel de disponibilité intelligente pour Windows, Linux et Docker permettant d’obtenir des temps d’arrêt, planifiés ou non, aussi proches que possible de zéro, de faire des économies importantes, de simplifier considérablement la gestion et de bénéficier d’une consolidation à la fois physique et logique.

- Déployer des groupes de disponibilité avec DH2i DxEnterprise sur Kubernetes
- Tutoriel : configurer un groupe de disponibilité Always On à trois nœuds avec DH2i DxEnterprise
HPE Serviceguard HPE SGLX offre des options de monitoring et de récupération contextuelles pour l’instance du cluster de basculement et les groupes de disponibilité Always On. Optimisez la disponibilité avec HPE SGLX sans compromettre l’intégrité des données et les performances.

- Tutoriel : configurer un groupe de disponibilité Always On à trois nœuds avec HPE Serviceguard pour Linux.
Pacemaker Pacemaker est un gestionnaire des ressources de cluster haute disponibilité open source. Avec le système de communication de groupe open source Corosync, Pacemaker permet de détecter les défaillances de composants et d’orchestrer les procédures de basculement nécessaires pour réduire les interruptions des applications.

- Pacemaker pour les groupes de disponibilité et les instances de cluster de basculement sur Linux
- Déployer un cluster Pacemaker pour SQL Server sur Linux

Contenu connexe