Fondamentaux des solutions de haute disponibilité

Généralités et comparatif des solutions de haute disponibilité SQL Server

  10 minutes à lire  

Généralités

Les fondamentaux de la haute disponibilité

Il faut évaluer le niveau de criticité et les impacts d’un arrêt de production.

Un contrat de service dit des « cinq neuf », qui correspond à une disponibilité à 99,999 %, implique de ne pas dépasser 5,26 minutes d’indisponibilité dans l’année.

Uptime SLAIndisponibilité par annéeIndisponibilité par mois

99.9%

8.76 heures

43.8 minutes

99.99%

52.6 minutes

4.38 minutes

99.999%

5.26 minutes

0.438 minutes

Principes de la haute disponibilité

  • La haute disponibilité est construite sur un ensemble de composants, qui peut nécessiter ou non du matériel spécifique. Le Failover Clustering (FC) nécessite du matériel adapté, notamment un disque partagé. AlwaysOn Availability Groups (AG) ne nécessite pas de matériel spécifique, outre les serveurs.

  • Le Failover Clustering (FC) nécessite du matériel adapté, notamment un disque partagé.

  • AlwaysOn Availability Groups (AG) ne nécessite pas de matériel spécifique, outre les serveurs.

  • Permet ou non le basculement automatique. Le Log Shipping ne prend pas en charge le basculement automatique. AlwaysOn AG supporte le basculement automatique en synchronisation synchrone, pas en asynchrone.

  • Le Log Shipping ne prend pas en charge le basculement automatique.

  • AlwaysOn AG supporte le basculement automatique en synchronisation synchrone, pas en asynchrone.

  • Un basculement automatique n’est jamais instantané et transparent. Il y aura toujours déconnexion de l’application. Ce qui compte est la capacité du client à la résilience. La bibliothèque ADO.NET a nativement la capacité d’essayer de se reconnecter de façon transparente si une déconnexion à lieu. Ce n’est pas le cas de la bibliothèque JDBC de Microsoft.

  • Il faut tester, et par exemple ajuster les valeurs de timeout au besoin.

  • Microsoft développe une logique de réessai plus complète en ADO.NET (Microsoft.Data.SqlClient v3.0.0), et travaille à son implémentation dans ses autres bibliothèques (mars 2021) : https://devblogs.microsoft.com/azure-sql/configurable-retry-logic-for-microsoft-data-sqlclient/

  • On peut utiliser le basculement manuel, pour diminuer l’indisponibilité dans les mises à jour de versions, par exemple.

  • Est shared ou shared nothing – les données sont partagées entre les instances (sur du FC en actif-passif), ou non partagées, donc copiées et dupliquées sur les réplicas (en AG).

Solutions de haute disponibilité dans SQL Server

  • La sauvegarde – backup et restore – Ce n’est pas de la haute disponibilité. Mais même avec de la haute disponibilité, les sauvegardes sont nécessaires. Elles seules permettent de revenir en arrière, et de proposer un PITR (Point-In-Time Recovery) grâce aux sauvegardes de journaux de transactions.

  • La réplication – La réplication transactionnelle permet de copier en temps réel des données sur un ou plusieurs serveurs abonnés. Ce n’est pas de la HA, car il n’y a pas de basculement automatique, et pas de redirection automatique des connexions clientes. De plus, la base de données n’est pas forcément entièrement répliquée. On doit choisir des articles parmi les tables. Il s’agit plus d’une solution d’échange automatisée de données en temps réel. Elle peut être éventuellement choisie comme une solution de haute disponibilité simple, avec des basculements manuels. Technologie un peu ancienne, difficile à diagnostiquer quand on a peu l’habitude de SQL Server.

  • Le Log Shipping – Solution de reprise sur incident basée sur un warm standby. Un assistant simplifie la mise en place de sauvegardes de journaux de transactions, automatiquement restaurés par planification sur un ou plusieurs serveurs secondaires. Se met en place base de données par base de données. Permet une mise à disposition de la base secondaire en lecture, mais de façon peu souple. Pas de basculement automatique, pas de système intégré de redirection des clients. Volontiers utilisé par les PME, et pour un PRA sur un site distant. Permet de décaler les restaurations sur le secondaire, pour avoir une copie retardée dans le temps.

  • Le Failover Clustering – officiellement appelé AlwaysOn Failover Clustering (FC) depuis SQL Server 2012. Solution shared everything basée sur un cluster Windows (WSFC) actif / passif. SQL Server s’installe en cluster et les services sont gérés par WSFC. Très peu d’actions administratives du côté SQL. Solution solide et « simple ». Plus coûteux en matériel, car nécessite un disque partagé, et un serveur passif. Basculement automatique et redirection assurés par WSFC.

  • Le Mirroring – technologie ancêtre d’AlwaysOn, maintenant abandonnée depuis que SQL Server 2016 dispose d’un groupe de disponibilité « basique » (Basic Availability Group, ou BAG), qui reprend les fonctionnalités du miroir pratiquement à l’identique, en édition Standard de SQL Server.

  • AlwaysOn Availability Groups (AG) – disponible, en édition Entreprise, à partir de la version 2012. évolution notable du miroir. Plusieurs bases de données, réunies dans un groupe de disponibilité, peuvent basculer ensemble, sur un ou plusieurs réplicas. Les réplicas peuvent être ouverts en lecture. Les clients se connectent à un listener, qui redirige les connexions sur le réplica principal, et peut aussi rediriger des connexions pour la lecture seule, sur un réplica secondaire. Solution en shared nothing, copie en temps réel des transactions via un canal TCP sur les secondaires, en mode transactionnel synchrone, ou en asynchrone. La détection de panne, le basculement et la redirection des clients sont assurés par le service de cluster Windows (WSFC). Solution souple, en constante amélioration. Nécessite une licence Entreprise de SQL Server.

Comparatif des solutions de haute disponibilité

SolutionRPORTOBasculementSecondaire en lecture

AlwaysOn AG synchrone

Zero

Secondes

Oui

≤ 5 réplicas synchrones, selon la version

AlwaysOn AG asynchrone

Secondes

Minutes

Non

≤ 8 réplicas, selon la version

Failover Clustering

N/A

Secondes-Minutes

Oui

N/A

Log Shipping

Minutes

Minutes-Heures

Non

Oui, mais pas pendant une restauration.

RPO – Recovery Point Objective – la durée maximum d’enregistrement des données qu’il est possible de perdre lors d’une panne.

RTO – Recovery Time Objective – le temps maximum de basculement et donc de remise en service. AlwaysOn AG asynchrone et le log shipping ne basculent qu’avec une intervention manuelle. Le RTO de ces solutions est donc aléatoire.

Intérêts de l’édition Entreprise de SQL Server

L’édition Entreprise permet un full AlwaysOn, qui offre les avantages suivants :

Divers :

  • L’édition Standard est limitée à 128 Go de RAM. Si on veut consolider des bases volumineuses sur le même serveur, c’est une limitation.

  • L’édition Entreprise permet la création de snapshots de bases de données, qui sont très pratiques pour effectuer une sauvegarde instantanée de base de données avant une mise en production, ou un changement important, par sécurité3https://docs.microsoft.com/fr-fr/sql/relational-databases/databases/database-snapshots-sql-server. https://docs.microsoft.com/fr-fr/sql/relational-databases/databases/database-snapshots-sql-server

  • La reconstruction (défragmentation) des index est non bloquante en édition Entreprise, et surtout, elle est « resumable » à partir de SQL Server 2016. On peut la mettre en pause et la reprendre ensuite. C’est très pratique sur les gros index pour éviter l’explosion du journal de transactions de la base.

  • Optimisation de performances en Entreprise : les métadonnées de tempdb sont en interne en tables in-memory depuis SQL Server 2019. C’est une fonctionnalité qu’il faut activer manuellement.

  • On dispose du gouverneur de ressources en édition Entreprise : on est capable de limiter l’occupation mémoire, CPU, IO sur le disque, par session, pour limiter certaines opérations et les empêcher de surconsommer.

  • Améliorations des performances en SQL Server 2019 : certains avantages de Intelligent Query Processing sont disponibles seulement en éd. Entreprise.

  • La reconstruction d’index (défragmentation) est parallélisée en éd. Entreprise.

  • La vérification d’intégrité (DBCC CHECKDB) est parallélisée en éd. Entreprise.

SQL Server sur Windows Server Core

SQL Server peut être installé sur Windows Server Core, sans gestionnaire de fenêtres. Vous pourrez ainsi administrer Windows et SQL Server via PowerShell ou à distance avec les outils graphiques. Vous pouvez installer en ligne de commande. L’avantage en termes de haute disponibilité en clair : 40 à 50 % de patchs en moins à appliquer, donc moins de temps d’indisponibilité.

Fichiers de bases de données sur SMB

Il est possible de stocker les fichiers de bases sur des partages SMB, y compris les bases système. C’est en général une mauvaise idée pour des raisons évidentes de performances. En revanche, Microsoft affirme que les performances de la version 3 de SMB permet d’obtenir des performances acceptables.

Les instructions DDL du langage Transact-SQL, comme CREATE DATABASE, supportent des chemins UNC pour la définition des chemins.

Cela lève au moins la limite des lettres de lecteur. Cela peut être intéressant pour les serveurs de test.

Les avantages de SMB 3 sont :

  • SMB Transparent Failover – configuration dans un cluster WSFC pour accès continu.

  • SMB Scale Out – partage ouvert par plusieurs serveurs.

  • SMB Multichannel – utilisation de plusieurs interfaces réseau en parallèle pour le trafic.

  • SMB Direct – utilisation de la pile RDMA.

  • SMB Encryption – comme son nom l’indique.

  • VSS for SMB file shares – support de VSS

  • SMB PowerShell – Import-Module Smb*

Support généralisé du SID de service

Le support du SID par service est disponible sur tous les systèmes d’exploitation. Le SID de service est automatiquement enregistré à l’installation et peut être utilisé pour les ACL sur les répertoires de données par exemple, quel que soit le compte de service. Vous pouvez donc utiliser Utiliser [NT SERVICE\MSSQLSERVER] Ou [NT SERVICE\MSSQL$INSTANCE] pour les ACL.

Le login correspondant doit exister dans SQL Server et être sysadmin.

Kerberos et les SPN

Pour une meilleure sécurité dans le domaine, le SPN (Service Principal Name) du service SQL Server doit pouvoir s’enregistrer dans l’Active Directory, pour pouvoir profiter de l’authentification et de l’échange de clés par Kerberos. Le compte de service doit avoir cette permission, ou vous pouvez enregistrer une fois ce SPN manuellement. Cela vous permettra de bénéficier des gMSA (voir section suivante).

Utilisation du compte managé

Le compte managé (MSA pour Managed Service Account), permet, sur un Active Directory, de définir un compte de service avec gestion automatique des stratégies de mot de passe. Le mot de passe est géré par l’AD. En revanche, il ne peut être attribué qu’à un service sur une machine du domaine.

Le compte managé de groupe (gMSA)4https://docs.microsoft.com/fr-fr/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview est apparu en Windows Server 2012. Il permet d’attribuer un compte managé sur plusieurs serveurs, ce qui permet effectivement de l’utiliser pour le compte de service SQL Server dans un Failover Clustering ou en AlwaysOn, où les différents réplicas doivent tourner sous le même compte de service (en tout cas pour simplifier la gestion des permissions). Le gMSA est supporté pour un service SQL Server en haute disponibilité depuis SQL Server 2016.

Le gMSA fonctionne grâce à une clé racine de distribution des clés de service (KDS, pour Key Distribution Service, kdssvc.dll). Les contrôleurs de domaine requièrent une clé racine pour commencer à générer des mots de passe gMSA.

Pour ajouter cette clé racine sur le contrôleur de domaine, vous pouvez utiliser une des cmdlets PowerShell suivantes :

Add-KdsRootKey-EffectiveImmediately
Add-KdsRootKey-EffectiveTime $date

Vérifiez ensuite qu’un événement 4004 a été consigné dans le journal des événements kds.

Ensuite, le compte gMSA lui-même peut être créé en PowerShell5https://docs.microsoft.com/fr-fr/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts . Il n’y a pas de GUI officiel, mais vous pouvez télécharger un outil tiers : http://www.cjwdev.co.uk/Software/MSAGUI/Download.html.

En PowerShell, le cmdlet à exécuter sur le contrôleur de domaine est le suivant :

New-ADServiceAccount [-name] < chaîne > -dNSHostName < chaîne > [-KerberosEncryptionType < ADKerberosEncryptionType > ] [-ManagedPasswordIntervalInDays <Nullable [Int32] >] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal [] >] [-SamAccountName < chaîne > ] [-ServicePrincipalNames <String [] >]

Par exemple :

New-ADServiceAccount sqlcluster -DNSHostName sqlcluster.contoso.com -PrincipalsAllowedToRetrieveManagedPassword SqlClusterHosts$ -KerberosEncryptionType RC4, AES128, AES256 -ServicePrincipalNames MSSQLSvc/Batterieit1. contoso. com : 1433

Vous pouvez ajouter après coup des hôtes :

Get-ADServiceAccount [-Identity] ITFarm1 -Properties PrincipalsAllowedToRetrieveManagedPassword
Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host2$,Host3$

Pour supprimer un hôte, relancez la commande sans l’hôte en question :

Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host3$
Expertise SQL Server Besoin de services avec SQL Server ? Contactez-moi et parlons de votre projet