Partage via

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

S’applique à :SQL Server sur Linux

À partir de SQL Server 2017 (14.x), SQL Server est pris en charge sur Linux et sur Windows. Comme les déploiements SQL Server basés sur Windows, les bases de données et les instances doivent être hautement disponibles sous Linux.

Cet article traite des aspects techniques de la planification et du déploiement d’instances et de bases de données SQL Server basées sur Linux hautement disponibles, et met en évidence les principales différences des installations windows. Étant donné que SQL Server ou Linux est peut-être nouveau pour vous, cet article décrit les concepts qui peuvent déjà vous être familiers.

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

Bien que certaines installations Linux incluent une interface, la plupart ne le font pas. Vous utilisez la ligne de commande pour presque tout ce qui se trouve au niveau de la couche du système d’exploitation. Le terme courant pour cette ligne de commande dans le monde Linux est un interpréteur de commandes, le plus courant étant bash.

Dans Linux, vous avez besoin de privilèges élevés pour exécuter de nombreuses commandes, comme pour avoir besoin de privilèges d’administrateur dans Windows Server. Vous pouvez exécuter des commandes avec des privilèges élevés de deux façons :

  1. Exécutez la commande en tant qu’utilisateur approprié. Pour passer à un autre utilisateur, utilisez la su commande. Si vous exécutez su sans nom d’utilisateur, vous entrez dans un interpréteur de commandes en tant que root si vous connaissez le mot de passe.

  2. Utilisez sudo avant la commande. Cette méthode est plus courante et plus sécurisée. De nombreux exemples de cet article utilisent sudo.

Voici quelques commandes courantes. Chaque commande dispose de différents commutateurs et options que vous pouvez rechercher 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 vous pouvez copier des fichiers

Toute personne qui administre SQL Server sur Linux doit pouvoir copier des fichiers d’un serveur vers un autre. Cette tâche est essentielle pour les configurations de groupes de disponibilité (AG).

Les problèmes d’autorisation peuvent exister sur les installations Linux et Windows. Toutefois, les utilisateurs Windows familiarisés avec la façon de copier des fichiers du serveur vers le serveur peuvent ne pas être familiarisés avec la façon dont il est effectué sur Linux. Une méthode courante consiste à utiliser l’utilitaire scpde ligne de commande, qui représente une copie sécurisée. En arrière-plan, scp utilise OpenSSH. SSH est un interpréteur de commandes sécurisé. Selon la distribution Linux, OpenSSH lui-même pourrait ne pas être installé. Si ce n’est pas le cas, vous devez installer OpenSSH.

Pour plus d’informations sur la configuration d’OpenSSH pour votre distribution Linux, consultez :

Note

À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

Lorsque vous utilisez scp, vous devez fournir les informations d’identification du serveur s’il ne s’agit pas de la source ou de la destination. Par exemple, la commande suivante copie le fichier MyAGCert.cer dans le dossier spécifié sur l’autre serveur :

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

Vous devez disposer d’autorisations, et éventuellement de propriété, du fichier pour le copier. Vous devrez peut-être donc utiliser chown avant la copie. 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 :

Note

À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

Vous pouvez également utiliser les partages de fichiers SMB de Windows. Les partages SMB n’ont pas besoin d’être basés 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 a le droit d’accès. Pour les clients dans un environnement mixte, cette approche vous permet d’utiliser l’infrastructure existante pour les déploiements SQL Server basés sur Linux.

La version de Samba que vous déployez doit être conforme À 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 vous utilisez Samba pour le partage et non Windows Server, le partage Samba doit utiliser Samba 4.0 ou version ultérieure, et idéalement 4.3 ou 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. Vous ne pouvez pas utiliser NFS sur les déploiements Windows de SQL Server, et il ne peut être utilisé que pour les déploiements basés sur Linux.

Configurer le pare-feu

Comme les distributions Windows, les distributions Linux ont un pare-feu intégré. Si votre organisation utilise un pare-feu externe pour les serveurs, vous pouvez peut-être désactiver les pare-feu dans Linux. Toutefois, quel que soit l’emplacement où vous activez le pare-feu, vous devez ouvrir des ports. Le tableau suivant répertorie les ports courants nécessaires pour les déploiements SQL Server hautement disponibles sur Linux.

Numéro de port Type Descriptif
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 Stimulateur cardiaque
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 autres ports utilisés par Samba, consultez Utilisation du port Samba.

À l’inverse, vous pouvez ajouter le nom du service sous Linux en tant qu’exception au lieu du port. Par exemple, utilisez high-availability pour le Pacemaker. Reportez-vous à votre distribution pour connaître les noms appropriés. Sur RHEL, par exemple, la commande à ajouter à Pacemaker est la suivante :

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

Documentation Pare-feu

Note

À compter de SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) n’est pas pris en charge.

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, c'est le planificateur par défaut pour les tâches de SQL Server et il est nécessaire pour l'expédition des journaux. Par conséquent, l'installation est 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.

Note

SQL Server Agent est le planificateur de travaux intégré pour SQL Server. Il est utilisé pour planifier des tâches telles que les sauvegardes et la maintenance de routine. Sur Windows, SQL Server Agent s’exécute en tant que service distinct. Sur Linux, il s’exécute dans le contexte de SQL Server lui-même.

Lorsque vous configurez des groupes de disponibilité (AG) ou des instances de cluster (FCI) sur une configuration Windows, ils sont compatibles avec le cluster. 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. Cette ressource est le mssql-server-ha package, é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.

Sur Linux, la Recherche en texte intégral (mssql-server-fts) et les Services d'intégration (mssql-server-is) sont des packages SQL Server facultatifs et ne sont pas nécessaires pour une instance de cluster de basculement (FCI) ou un groupe de disponibilité (AG).

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 Descriptif
DH2i DxEnterprise est une solution de gestion de la disponibilité pour les environnements Windows, Linux et conteneur. Il prend en charge la haute disponibilité, réduit les temps d’arrêt planifiés et non planifiés et simplifie la gestion des ressources physiques et logiques.

- 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.
Stimulateur cardiaque 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 associé

  • Last updated on