La haute disponibilité des données est un facteur fondamental dans l’élaboration d’une architecture de bases de données, notamment pour des données sensibles dont la disponibilité doit être continue. C’est le cas pour les applications du monde de l’hôpital, les services de secours ou encore la régulation des transports.
Cet article à pour but de comparer les solutions de deux systèmes de base de données relationnelles PostGreSQL et Microsoft SQL Server.

Publication le 2024-07-13

1 – Qu’est ce que la haute disponibilité ?

La haute disponibilité en anglais high availability (HA) consiste à mettre en œuvre une architecture physique et logique pour redonder les données des bases de données (aspect physique) et faire en sorte que le système bascule d’une unité à l’autre (aspect logique) de la manière la plus rapide et la plus transparente au regard des besoins d’accès aux données.

2 – Qu’est ce que le taux de disponibilité ?

C’est une mesure communément admise, calculée en pourcentage du temps ou le système est indisponible par rapport au  temps passé. Par exemple un système qui serait en moyenne indisponible quelques jours par an, se verrait alors attribuer un taux de disponibilité compris entre 95% (18 jours / an) et 99% (3 jour s/ an).

Aujourd’hui il est courant de viser un taux de disponibilité de l’ordre de 99,99 à 99,999 % du temps, soit une limite d’indisponibilité de 9,75 heures à 5 minutes et 30 secondes…

3 – Différence entre haute disponibilité, PRA et PCA

Un Plan de Reprise d’Activité, PRA, vise à rétablir le système d’information de l’entreprise au plus vite en cas de sinistre majeur (incendie, inondation, …).

Un Plan de Continuité des Activités PCA vise la poursuite des activités de l’entreprise face à un incident dont la gravité est circonscrite (panne machine, erreur logique, …).

Les mécanismes spécifiques introduits dans les bases de données, permettent aussi bien d’assurer le PCA ou le PRA pour l’unique périmètre des bases de données, ce qui constitue, il ne faut l’oublier, le principal capital économique de l’entreprise.

En règle générale, les mécanismes intégrés de haute disponibilité permettent d’atteindre un PCA sans perte de données, grâce à un mode synchrone pour lequel la distance entre les données répliquées doit être relativement faible (LAN) ou bien à longue distance (WAN) via des réseaux à très haut débit extrêmement résilients.

Dans le cas du PRA une réplication asynchrone est préférable, car les machines se trouvent généralement à grande distance afin de ne pas être affecté par un sinistre de grande étendue (inondation, tremblement de terre, panne du réseau public de distribution d’électricité…), le mode asynchrone étant plus performant du point de vue du service des données, mais induisant une perte potentielle des données…

4 – Architecture technique

4.1 – Le principe

Une première instance du serveur de bases de données concentre les bases actives dites « primaires » et un mécanisme, généralement basé sur les transactions, propage aux nœuds passif (généralement appelés esclaves), c’est à dire aux autres instances de serveurs de bases de données, les informations nécessaires à reconstruire les données qui ont été modifiées dans les différentes bases.

Une fonctionnalité complémentaire surveille la disponibilité des machines et en cas de problème alerte le DBA sur la défaillance ou bascule directement sur l’un des nœuds de secours.

4.2 – L’implémentation

Nous n’allons pas recopier bêtement les aides en lignes officielles et les exemples documentés sur Internet, mais en voici les liens :

• Pour PostGreSQL
• Pour Microsoft SQL Server

5 – Différences entre les deux approches

Parlons maintenant de ce qui différencie PostGreSQL de SQL Server en matière de haute disponibilité…

5.1 – Quelles bases sont concernées ?

Dans PostGreSQL du fait qu’il n’existe qu’un seul journal de transactions, toutes les bases, sans exception, doivent être répliquées de manière physique d’un nœud à l’autre…

Au contraire dans SQL Server, chaque base de données dispose de son propre journal de transactions. On peut alors répliquer certaines bases d’un nœud A vers un nœud B et d’autres du nœud A vers un nœud C et enfin d’autres peuvent ne pas être répliquée du tout. Pour simplifier la chose, SQL Server propose de regrouper les bases de données dans des groupes de disponibilité afin que les opérations mutuelles soient conjointes aux bases d’un même groupe…

5.2 – Toutes les opérations sont-elles répliquées ?

Dans PostGreSQL la réplication est arrêtée dès qu’une commande propage l’exécution d’instruction au niveau externe (par exemple la création d’un « storage » CREATE TABLESPACE… qui induit la création d’un répertoire). Il faut donc effectuer une reprise en reconstruisant l’ensemble de la réplication car malheureusement et toujours à cause de l’unique journal de transactions, cette reconstruction doit concerner toutes les bases, même si une seule est en cause.

Ceci ne pose aucun problème à SQL Server, à condition que le chemin dans lequel sera créé le nouvel espace de stockage existe dans les différents nœuds et le nouveau répertoire sera créé par SQL Server.

5.3 – Synchrone ?

Par défaut asynchrone dans PostGreSQL, le mécanisme permet un mode « synchrone » qui peut s’avérer désastreux en production car il tire les performances vers le bas : le nœud actif n’envoie la transaction qu’après quelle ait été finalisée sur le « master » et le système attend la confirmation de l’unique nœud passif pour continuer, ce qui peut prendre de nombreuses minutes pour des transactions longues.

Au contraire, SQL Server agit en amont au démarrage de la transaction : les différentes transactions sont propagées en parallèle, immédiatement sur tous les nœuds, y compris le primaire. Il en résulte que, si les machines sont équilibrées, le délai n’est que celui du transit réseau dont le seuil d’alerte est de l’ordre de 15 ms, au-delà duquel SQL Server passe transitoirement en mode asynchrone pour éviter les blocages (phase de rattrapage).

5.4 – Combien de nœuds ?

Le mode synchrone de PostGreSQL est toujours limité à deux nœuds, les autres étant asynchrones, car le mécanisme de réplication est en cascade dans PostGreSQL. Par exemple à 3 nœuds (A, B, C), les deux premiers (A et B, le premier A étant actif et le second B passif) pourront être synchrones, mais pas le 3e car la réplication se fait d’abord du nœud A vers le B puis, lorsque le nœud B a finalisé ses transactions, le nœud C les reçoit de B…

Dans SQL Server, tous les nœuds reçoivent les transactions à répliquer en parallèle, qu’ils soient en mode synchrone (dans la limite de 5 nœuds synchrone) ou asynchrone (dans la limite de 8 nœuds)…

5.5 – Quid du quorum ?

Le quorum est un algorithme dans lequel un élément interne ou externe, agit en tant que témoin pour assurer une majorité de vote afin déclencher le basculement. Par exemple avec une solution de réplication à deux nœuds, il faut un mécanise tiers pour décider quel nœud défaillant isoler et faire en sorte que le nœud résistant prenne le rôle de master si ce n’est pas le cas. L’imparité des votes devant être la règle pour décider de comment traiter le problème.

PostGreSQL ne disposant pas d’un mécanisme de quorum indépendant et au niveau système, il faut impérativement au moins 3 nœuds, c’est-à-dire trois instances de PostGreSQL pour pouvoir prétendre à un basculement automatique en mode synchrone.

En comparaison SQL Server utilise le cluster Windows et un quorum (disque ou partage de fichier) pour assurer le vote majoritaire qui décide du basculement.

5.6 – En combien de temps le système bascule ?

Bien que PostgreSQL propose un basculement automatique, celui-ci met beaucoup de temps en mode synchrone (30 secondes environ).

SQL Server en comparaison ne met que quelques millisecondes…

5.7 – Les applications se reconnectent-elles sans problème ?

PostGreSQL ne dispose pas de manière interne de la notion de « listener » qui permet à toute application de ne jamais être coupé de la base opérationnelle quel que soit le nœud actif (le listener étant constitué dans SQL Server d’une adresse IP de redirection vers le nœud actif). Compte tenu de ceci, il faudra donc modifier les chaines de connexion des applicatifs pour que le service des données fonctionne de nouveau.
On comprend donc que, si le rétablissement de la disponibilité des bases peut être très rapide en cas de sinistre dans PostGreSQL, il n’en est pas de même pour les applicatifs car il faudra agir manuellement… !

Dans SQL Server, chaque groupe de disponibilité rassemblant différentes base, est généralement doté d’un listener qui redirige le flux des requêtes applicatives sur le serveur actif de manière totalement transparente du point de vue des applications. Il n’y a donc aucune action à entreprendre au niveau des applications pour que celles-ci continuent de d’accéder aux données de la base active en cas de basculement automatique.

5.8 – Quel volume transite sur le réseau ?

PostGreSQL ne disposant que d’un seul journal de transactions commun à toutes les bases de données, si la réplication n’a d’intérêt que pour certaines bases, le volume des communications entre nœuds est pollué par des informations inutiles qui obère les ressources.

En comparaison, dans SQL Server chaque base de données possède son propre journal de transactions ce qui minimise le volume du transit. De plus SQL Server pratique la compression des données des tables et index ce qui permet de diminuer encore plus le volume du transit. La compression des données étant une fonctionnalités inconnue de PostGreSQL [1].
De surcroit les informations transmises sont elles aussi compressées avant d’être envoyée sur le réseau, en particulier si elles ne le sont déjà pas aux niveau des tables et des index…

5.9 – la réplication peut-elle assurer la répartition de charge ?

Là encore une fois, le mauvais choix d’une architecture avec un seul journal de transactions pour toutes les bases de données de PostGreSQL empêche de panacher les différents nœuds en ayant une partie des bases actives sur le nœud A et l’autre sur le nœud B…
Avec PostGreSQL vous aurez donc toujours un nœud dont toutes les bases sont actives et sur l’autre toutes passives avec l’étrange impression que le serveur accueillant toutes les bases passives dispose de ressources presque toutes totalement inexploitées.

Ceci n’est pas le cas dans SQL Server, car grâce au concept de Groupe de Disponibilité, vous pouvez par exemple, enrôler 50 % de vos bases dans un groupe et le reste dans l’autre, le groupe 1 étant actif sur le nœud A et le groupe 2 actif sur le nœud B. Ceci améliore grandement les performances globales du service des données, ou encore, permet de choisir des serveurs moins « costaud » au niveau des ressources afin d’économiser sur le matériel et les licences…

5.10 – Quel est le coût des licences ?

Nous savons tous que PostGreSQL est un outil gratuit… Mais dans une certaines mesure ! En effet plusieurs entreprises proposent des versions payantes de PostGreSQL (Enterprise DB, Fujitsu, Citus…) dont le coût est loin d’être négligeable et qui deviennent vite indispensable dès que la volumétrie augmente ou que l’on a besoin de telle ou telle fonctionnalité manquante dans la version « libre » de PostGreSQL…  N’oublions pas que les développeurs de PostGreSQL ont eux aussi besoin de manger et que bon nombre d’entre eux sont salariés de la société Enterprise DB qui bride sciemment les fonctionnalités de PostGreSQL pour permettre de vendre leurs produits…

Cette avancée masquée n’est pas le mode de fonctionnement de Microsoft dont les coûts sont les plus bas des SGBDR d’entreprise. L’édition Standard limitée à 24 cœurs physiques (soit 48 logiques) et 192 Go de cache (RAM : 128 table et index relationnels + 32 tables in memory + 32 index columnstore… deux fonctionnalités qui n’existent pas dans PostGreSQL) coute un peu moins de 2000 € par cœur physique auquel il faut ajouter la Software Insurance (nécessaire pour la haute disponibilité AlwaysOn – 700 € par cœurs physique et par an) ce qui donne droit à la version future gratuitement.
Autre gratuité, celle des instances passives… Microsoft ne fait jamais payer les licences SQL Server des machines passives. Vous n’aurez donc rien à payer en licence pour le second nœud par exemple.

Ainsi, pour une machine à 16 cœurs logiques, avec un amortissement sur 5 ans, pour lequel vous serez passé par deux à trois versions de SQL Server (2017, 2019, 2022… par exemple), le budget mensuel sera donc de moins de 1000 €, soit un peu moins que le TJM de 2 journées d’un développeur…
J’oubliais le prix des licences Windows… environ 1000 € pour 16 cœurs physiques. En amortissement sur 5 ans, cela représente donc 5 € par mois…
Cher non ?

5.11 – Quel sont les outils pour faciliter la mise en œuvre et l’exploitation ?

PostGreSQL ne dispose d’aucun assistant pour la mise en place de cette réplication (il faut tout scripter) et encore moins de tableau de bord permettant la surveillance de l’état du système, ni, bien entendu d’alertes intégrées pour être informé des dysfonctionnements… Ceci oblige à rajouter, à un outil de monitoring externe, de nombreuses requêtes tant au niveau de PostGreSQL que de l’OS afin de capturer les informations essentielles de la surveillance…
Bref un travail complexe, couteux et casse gueule, que seuls quelques entreprises comme Dalibo, Enterprise DB, … maitrisent…

En comparaisons, SQL Server dispose d’un assistant de mise en œuvre et de nombreux tableaux de bord pour la surveillance…

6 – Questions complémentaires

Lorsque les nœuds sont synchrones à basculement automatique et qu’une latence importante devrait modifier le flux de réplication en le passant en mode asynchrone, peut-on interrompre le processus pour arrêter la base ou l’instance SQL Server ?

Le principe de la haute disponibilité est de ne jamais interrompre le service des données. Autrement dit toute arrêt de la base ou de l’instance étant considérée comme une indisponibilité totale contreviendrait aux principe d’AlwaysOn et n’est donc pas prévu dans ce dispositif.

Néanmoins, il est possible d’arrêter le service des données d’une base en la mettant OFFLINE ou en mode READONLY ou encore d’arrêter l’instance (commande SHUTDOWN), après avoir intercepté le moment ou cet état change soit via l’Agent SQL et ses différentes scrutations, via les alertes :

• exceptions (erreurs ou simples warnings)
• conditions de performances (vue sys.dm_os_performance_counters)
• paramètres systèmes capturés par requête WMI

…soit par des événements étendus, notamment « sqlserver.lock_redo_blocked » :

…soit par le biais des politiques d’administration

Par exemple, les politiques suivantes peuvent être utiliser pour intercepter cet événement :

 

Un quorum basé sur un disque ou sur le partage de fichier. N’est-ce pas un peu léger ou dangereux ? Cela ne constituerait pas un SPOF ?

Rappelons ce qu’est un SPOF … Single Point Of Failure. Soit un composant d’un ensemble d’éléments coopérant à un même but, dont l’un des éléments n’est pas redondé. Dans ce cas la perte de cet élément entraines le naufrage de la solution. Ceci ne se voit qua dans les systèmes dotées de plusieurs machines, que ce soit des PCs, des SANs des équipements réseaux… Brefs de multiples ressources physiques ou logiques tenants d’une même architecture, ce qui est le cas générale de la haute disponibilité…. L’actualité récente de Microsoft avec la panne de Crowdstrike qui est l’un des bugs informatique ayant coûté le plus cher en terme d’indisponibilité nous montre à quel point l’élimination des SPOFs est une chose importante…

À ce jour et depuis la version 2012 de SQL Server, aucune problématique de ce genre n’a été relevé… Sur quelque millions d’instances SQL Server en cluster ! Mais le partage doit impérativement être situé sur une machine distincte des machines à surveiller…

N’oublions pas que le listener assure l’indirection vers le groupe survivant. Soit tout le réseau est coupé et donc plus aucun service des données n’est possible et la base reste en l’état sur tous les nœuds, soit le réseau du listener est accessible et les requêtes continues d’être dirigées vers l’instance qui produisait avant que l’incident ne survienne.

La question suivante va éclaircir la chose…

De même, quel est le nombre de membres dans un « cluster windows » ? Il devrait être impair ? Sinon la solution parait sensible au split-brain…

Rappelons ce qu’est le syndrome du split-brain… Pour simplifier la chose considérons un cluster à deux nœuds (par extrapolation cela pourrait être appliqué à un cluster à 4 nœuds, 6, etc). En cas de perte de communication entre les deux nœuds et si les deux nœuds survivent et sont exploitable, chacun de ces nœuds peut penser à être le seul à produire et va donc accepter les requêtes SQL… Il en résulte que certaines applications vont atteindre le nœud A d’autres le nœud B, et la base de données va diverger car les mises à jour vont se produire tantôt dans la base A et tantôt dans la base B. Les deux bases seront alors devenues irréconciliables et il n’existe pas de moyen simple pour remédier à ce problème qu’il convient d’éviter à tout prix…

Rassurez-vous le cluster veille et désactive le quorum quand un nombre pair de votant est atteint afin de rétablir l’imparité du vote…
Par exemple chez un grand logisticien international fonctionnant 24h sur 24 nous avions, en version 2016, 5 nœuds (1 actif RW, 1 passif, 3 Readable) le quorum était non votant mais si nous éteignions une machine, alors il devenait votant…

Il reste quand même important de placer la communication entre les machines sur des réseaux physiques différents de celui du service des données. Sur les machines modernes les serveurs physiques sont souvent dotées de plusieurs cartes réseaux à deux ports. On peut alors déléguer l’une des cartes aux applicatifs accédant à la base et l’autre à la communication AlwaysOn et le transport des données de réplication entre les nœuds. Ceci suppose aussi que les commutateurs soient physiques et redondants et qu’un routage différent soit assuré. Hélas la stratégie du tout VM conduit souvent à un SPOF…

Où s’exécute le listener ? Sur tous les membres du cluster ? Est-ce un SPOF ? Quelle adresse configure-t-on sur le client ? …

C’est une ressources externe, une adresse IP virtuelle (VNN) enregistrée dans l’AD comme nom de machine « flottante » et qui assure la redirection. Elle est considérée comme une machine (PC) mais elle est gérée à la fois au niveau du cluster et propre au groupe de disponibilité.

Grace au listener, les applications client peuvent se connecter à un nœud et ne voient le groupe de disponibilité contenant les bases actives, sans avoir à fournir le nom de l’instance physique du serveur SQL Server. Du fait que l’écouteur route le trafic, il n’est pas nécessaire de modifier la chaîne de connexion du client après un basculement. Le listener n’est pas obligatoire mais sans cet outil tout basculement nécessiterait une redirection des applications, soit en modifiant la chaine de connexion, soit en modifiant l’adresse IP du serveur survivant, et dans tous les cas une phase manuelle et une perte de temps.

Il  ne constitue donc pas un SPOF puisque l’on peut s’en passer !

Comment le choix de basculer se fait-il ? Quel nœud sera pris en compte en cas de défaillance du nœud primaire ?

Chaque nœud est valué avec un poids. Ce qui permet de savoir sur quelle machine passe automatiquement la production en cas de défaillance du nœud actif. Avec 2 nœuds, le mieux est de placer les nœuds avec une priorité égale. Rappelons que le basculement automatique n’est possible qu’en mode synchrone. Avec 3 nœuds synchrones ou plus, baisser le poids des nœuds de rang supérieur à deux. Par exemple avec 4 mettre 30%, 30%, 25% et 15% de poids de vote.

Ceci se fait dans SQL Server lors de la construction des groupes de disponibilité et se trouve visible au niveau du gestionnaire de cluster :

Comme les nœuds sont gérés au niveau des groupe de disponibilité ou de la base de données et non de toute l’instance, vous pouvez avoir des politiques de poids différentes en fonction des bases de données, de leur nature et de leur criticité…

Que se passe-t-il quand le réseau est instable (grosse latence réseau ou micro-coupures de quelques millisecondes) ?

Dans une telle situation, mieux vaut être en mode asynchrone. Cependant nul n’est à l’abri de tels incidents même dans le cas d’un réseau local physique…

Tant que la latence est acceptable (quelques millisecondes par défaut) la réplication reste synchrone au prix d’une attente somme toute peu importante. Si ce délai est dépassé, alors le groupe de disponibilité passe en mode asynchrone et le basculement automatique n’est temporairement plus possible. Un mécanisme de rattrapage va se mettre en place dès que la latence redeviens correcte ou que la coupure est terminée. Lorsque tout redevient normal, le groupe de disponibilité est à nouveau en mode synchrone et le basculement automatique redevient possible.

Des détails intéressants, et comment scruter cela avec les événements étendus, se trouvent dans l’article  » Troubleshooting data movement latency between synchronous-commit AlwaysOn Availability Groups  »

Que se passe-t-il si l’on a une base de données qui bouffe plus des ressources que les voisines au point que ces dernières soient ralenties ? Existe-t-il un système de quota de ressources données à une base ? …

Bien évidemment. Cela passe par le gouverneur de ressources qui permet d’imposer des quotas de mémoire, de disque et de CPU…
On peut aussi effectuer de nombreux réglages différents base par base. Par exemple avoir des bases qui travaillent en version 2008, 2012, 2016, 2017, 2019, 2022 dans une instance 2022 (ni PostGreSQL ni Oracle ne savent faire ça..). On peut régler le niveau de parallélisme base par base, etc…

Le cluster ne pourrait-il pas devenir instable si le basculement automatique se faisait de part et d’autre en mode « ping-pong » en raison d’un état dysfonctionnel du système ?

Bien évidemment ce cas a été pris en compte dès l’origine dans la conception d’AlwaysOn. Conventionnellement ceci est fixé à 1 seul basculement par unité de 6 heures de temps.

Cela est bien faible dans un système à deux nœuds et personnellement je permet 3 basculement par unité de 4 heures… Et il convient d’augmenter cela si vous avez plus de 2 nœuds car en cas de passage d’un correctif, si vous vous y prenez mal dans le séquencement des correctifs à passer, vous pouvez vous retrouver bloqué au mauvais moment… Il est donc conseillé de passer les CU en commençant toujours par les nœuds passifs et en terminant par le nœud actif, en vérifiant bien qu’il n’a pas basculé sur un autre, entre le moment ou l’on a élaboré sa stratégie et le moment ou l’on applique cette dernière correction…

Nous avons vu que les instances secondaires peuvent servir pour faire de la lecture. Il faudra faire attention à la fraicheur des données (si réplication asynchrone) pour ne pas avoir de surprises…

En pratique, la latence est souvent de moins d’une seconde… À la condition d’avoir, si site distant, de la fibre avec un débit dédié… Nos clients ont remarqué que la vitesse de transmission des données vers les nœuds synchrones et asynchrones étaient identique dans un même réseau. Je dirais même que la transmission est souvent plus rapide vers les nœuds asynchrones dans un même réseau que vers les nœuds synchrone, mais il y a toujours une double problématique, celle de l’impossibilité d’un basculement automatique et le fait qu’aucune garantie ne peut être apportée quant à la non perte de données…

Par exemple dans le cas de notre grand logisticien international déjà cité ci-avant, trois nœuds étaient lisible dont 2 assurait la production de toute l’éditique… Et en matière de transport, non seulement il y en a sur les colis (acheminement), dans les colis (bon de colisage), dans l’outil de transport (manifeste)…  Il fallait donc pour ces deux nœuds être très proche des données dans le temps, les opérateurs ayant l’habitude de valider leurs écrans et d’appuyer immédiatement sur la touche « IMPRIM » dans la foulée…. Et ceci ne posait aucun problème ! Le 3e nœud servant à alimenter la BI…

J’ai entendu dire qu’AlwaysOn permettait de corriger automatiquement les données corrompues… Comment cela fonctionne t-il ?

Effectivement lorsqu’il y a détection d’une page corrompue (par lecture physique depuis le disque) SQL Server demande aux autres nœuds de lui fournir la page correcte et il remplace toute page abimée par une page corrigée. Il enregistre l’information de correction dans ses tables système et cela peut être requêté par la vue :

Un article de Microsoft Learn montre comment gérer ce type de problématique, heureusement assez rare en production…

Comment se passe les montées de versions (mineures et majeurs) lorsqu’on utilise un groupe de disponibilité ?

Le problème est bien différent dans SQL Server par rapport à PostGreSQL… SQL Server permet de faire tourner des bases en rétrocompatibilité. Les versions « mineures » de PostGreSQL correspondent aux CU (Cumulative Update) et n’ont généralement pas besoin de redémarrage (modification à chaud). Si un tel CU a besoin de redémarrer, alors le système bascule et les applications ne voient rien… Pour ce qui est des versions majeures il est possible d’assurer la continuité en ajoutant un nœud dans la version supérieure et de forcer le basculement, en mode synchrone, mais le retour arrière n’est pas possible (revenir à une version antérieure). Là aussi les applications ne voient rien. Les bases de données ainsi migrées restent dans leur mode de rétrocompatibilité jusqu’à ce qu’on les modifient (à chaud) pour être dans la dernière version. Par exemple si, sur une instance 2019, on ajoute un nœud 2022 et qu’il y a une base en rétrocompatibilité 2016 et une autre en compatibilité directe (2019) alors la bascule vers 2022, laisse les bases en rétrocompatibilité 2016 et 2019, jusqu’à ce que le DBA lance la commande :

Ceci se faisant à chaud avec des utilisateurs qui verront les requêtes suivantes dans leur connexion utiliser la toute dernière version…

Compte tenu des différences entre la version Standard (limité à deux nœuds et un groupe de disponibilité par base) et la version Enterprise qui n’a pas ces limites, est-ce bien raisonnable de prendre la version Enterprise ?

Je dirais que c’est souvent une question de taille… Je travaille avec des entreprises et des éditeurs de logiciel dont les bases font couramment plusieurs téraoctets et ces bases comptent souvent plusieurs milliers de tables (sans compter les vues et procédures stockées….).
À mon sens la version Enterprise est nécessaire dans quatre cas indépendants :

• la forte volumétrie (au delà de 2 To de données);
• le grand nombre de connexions (au delà de 3 000);
• un fonctionnement 24h sur 24, 7j sur 7 sans heures creuses (cas des bases « mondiales » dont le transporteur dont je parlais);
• une extrême complexité de certaines requêtes (plusieurs dizaines ou centaines de table dans une même requête, nécessitant l’ajout de guide de plan, c’est à dire d’indicateur mis à la volée pour guider l’optimiseur et l’apport de « l‘Intelligent Query Processing« ).

C’est le cas de la plupart des logisticiens que je compte comme clients et dont les bases de données font plusieurs téraoctet voire plusieurs dizaines de téraoctet (en mode compressé, ce qui reviendrais à plus de 100 To sous PostGreSQL malheureusement…).

Ce n’est donc pas tellement les fonctionnalités d’AlwaysOn qui détermine le choix de l’édition, mais des fonctionnalités spécifiques indispensable pour les VLDB comme :

• le mode ONLINE pour la modification des objets (ALTER TABLE en particulier) comme pour la maintenance des index;
• le mode « resumable » (interruptible) de l’indexation ou de l’ajout de contraintes indispensable pour de grands index (de 200 Go à plusieurs téraoctets) ou de grandes tables;
• l’indexation verticale « columnstore » (qui est limitée à 32 Go dans l’édition Standard – indispensable pour les très grandes tables);
• la création de tables « in memory » (la aussi limitée à 32 Go dans l’édition Standard – indispensable pour la modification à très haute fréquence et répliquée via AlwaysOn);
• la restauration des bases en mode ONLINE (en fait du « racommodage » de pages)
• la restauration par parties d’une base (PEACEMEAL);
• la récupération accéléré en cas de crash de l’instance (il faut un dispositif spécifique aux microprocesseurs Intel);
• l’ajout de ressources physiques à chaud (RAM, CPU…);
• les sauvegarde en « miroir » (une même sauvegarde avec plusieurs destinations simultanées)
• le gouverneur de ressources;
• la mise en place de guide de plan pour contraindre l’optimiseur en ajoutant des indicateur de requête à la volée;
• et les tous nouveaux algorithmes de gestion intelligente de l’optimiseur
• … et bien d’autres choses encore !

Mais il y a des inconditionnels de la version Enterprise. Un de mes clients, une banque, voulait contre toute logique un seul groupe de disponibilité pour faire basculer toutes ses bases en même temps, ce que ne permet pas l’édition Standard qui oblige a avoir des groupes de disponibilités constitués d’une seule base… Ce que l’on peut contourner un tant soit peu si l’on est astucieux…

Les prix indiqués des licences prennent-ils en compte le coup de la licence Windows ? Sur le sujet, des groupes de disponibilité, cela se passe comment avec SQL server linux ? Est-ce que je lis bien ce tableau en pensant que c’est disponible dés la version standard ? …

La licence de l’OS n’est pas compris dans le prix de la licence SQL Server. Mais Windows Server standard (suffisante dans 99% des cas et 99.9 pour SQL Server) est très peu cher. De tête je dirais moins de 1 000 €…. par paquet de 16 cœurs physique (soit 32 cœurs logiques…)…
Et oui, AlwaysOn est disponible en version standard mais avec quelques restrictions :

• un groupe de disponibilité par base (comme PostGreSQL)
• deux nœuds au maximum
• pas de lecture sur les nœuds passifs

En revanche le prix de SQL Server n’est pas donné et est le même que ce soit sous Windows ou Linux…
Mais il faut savoir qu’il existe deux possibilités de rabais. Soit en utilisant le service des licences en volume (c’est plutôt pour les grosses entreprise qui ne veulent pas se préoccuper de comptabiliser leurs licences au jour le jour, mais font un bilan annuel), soit par secteur d’activité. Par exemple, les organisations non gouvernementales reconnues peuvent bénéficier d’un rabais systématique de Microsoft qui est assez important, tandis que le bijoutier de la place Vendôme, aura probablement un rabais bien moindre…
Cela dit les rabais que propose Microsoft ne sont pas des trompes couillons comme le fait assez systématiquement Oracle en proposant des rabais allant jusqu’à 80%… Seulement ce que Oracle oublie de dire, c’est que ce genre de rabais ne porte jamais sur les options… Or la plupart des clients ignorent c’est que parmi les nombres options, certaines sont indispensables comme le diagnostic pack, le tuning, le multi-tenant (multi bases), le partitionnement, la compression, la masquage des données, les données spatiales ou les tables de graphe  ou le parallélisme des requêtes. Dans un tel cas, il n’est pas rare de payer jusqu’à 25 fois plus cher que SQL Server, même après ce rabais poudre aux yeux… Car la politique Microsoft c’est que tout est inclus dans la version Enterprise, sinon vous devez étudier les limites de la version Standard…

Dernière chose, Microsoft offre régulièrement des licences gratuites dans certaines conditions. Notamment pour passer d’Oracle à SQL Server ou encore pour monter sur le cloud Azure…

… Autre chose aussi qui peut rebuter, les changements « surprise » de licence et donc de prix. Si on regarde du coté, d’Oracle ils ont tellement resserré les vis qu’ils ont fait fuir pas mal de client de leur SGBD. Toujours Oracle, en changeant régulièrement le fonctionnement de la licence oracle JDK, crée une instabilité qui me parait déraisonnable/préjudiciable.. Elasticsearch qui tue sa licence gold (la moins chère) faisant exploser le coût des clusters Elasticsearch auto-hébergé. Certes, il y a plus de fonctionnalités, mais tout le monde n’en a pas besoin… Atlassian qui se tourne en full sas. Ne parlons pas de ce que fait VMWare depuis son rachat par Broadcom.
Comme dirait le MEDEF, les entreprises ont besoin de stabilité…
Vous avez données les prix actuels, mais les conditions d’accès d’un produit (libre ou pas) peuvent très vite changer.
Après il me semble que Microsoft est du genre « stable » sur les licences, mais c’est un avis au doigt mouillé. …

Effectivement Microsoft est extrêmement stable sur son modèle de licence pour SQL Server qui n’a changé qu’une seule fois en 25 ans, pour passer d’une tarification « processeur » à une tarification par cœur au moment de la sortie de la version 2012…
C’est une volonté pour se démarquer de la concurrence… qui change de modèle de vente comme de chemise !
Mais comme dans toute technologie nouvelle (ce qui n’est pas le cas de SQL Server) et donc évolutive, rien n’est assuré d’avance. C’est ainsi que Azure a effectivement changé de modèle de prix ce qui a eut pour conséquence quelques retour en arrière en revenant au mode « on premise » de client s’étant porté vers Azure…

Quant aux prix des licences Windows Server elles ont notablement baissées du fait de la concurrence avec Linux… En effet, aujourd’hui une version Enterprise  (en fait « Data Center ») n’est nécessaire que si vous faites de la virtualisation et le prix, comme les caractéristiques de la version Standard de Windows Server est à peine celui de la version Small Business d’il y a 15 ans !

Nous avons abordé le cluster Windows, mais quid des MS SQL Server sous Linux ? La question est intéressante à aborder car les fonctionnalités ne sont pas au même niveau entre les deux éditions…

Bonne question. Mais je vais vous décevoir… rares sont les installations de SQL Server sous Linux et très rares sont celle avec de la haute disponibilité car trop complexe, trop instables… Cela nécessite des outils externes qui collaborent mal (Pacemaker, Corosync, …) Cela rend lourd complexe et peu performant et horriblement couteux en administration car aucun de ces outils ne communique avec les autres… Et il existe plusieurs limitations de fonctionnement sous Linux comme le DTC, Active Directory et le basculement des nœuds manuels (pas de possibilité de basculement automatique).

Tout ceci fait que la plupart des clients préfèrent, de très loin, la solution toute intégrée Windows / Microsoft à la complexe, éparse et lourdingue Linux !

À lire : « Availability groups for SQL Server on Linux »

7 – En guide de conclusion

Certains des problèmes évoqués ci-avant au sujet de PostGreSQL peuvent être contournés en ajoutant des outils complémentaires comme Barman, repmgr, Slony I, PGpool II, Patroni, Pacemaker…
Mais cela complexifie encore plus l’architecture et nécessite une administration complémentaire lourde, complexe et cher en exploitation et pour ce dernier point parce qu’il n’existe quasiment pas d’assistance de niveau professionnelle à contacter en cas de problème…

Bref, la soi-disant économie réalisé du fait de la gratuité des licences PostGreSQL en comparaison de l’explosion du coût d’exploitation et du hardware complémentaire montre vite que SQL Server est plus que compétitif, et il restera toujours de nombreuses lacunes à PostGreSQL par rapport aux fonctionnalités incluses dans Microsoft SQL Server en matière de haute disponibilité…

Pour information, les pompiers de Paris (BSPP) utilise SQL Server pour la base de données des secours depuis 2005 d’abord avec le mirroring puis depuis la version 2012 avec AlwaysOn… De même pour Vigicrues qui analyse le comportement de plusieurs dizaines de cours d’eau afin de prévenir des risques d’inondation…

Pour information, le site web leboncoin avait mis en place une réplication pour ses 70 instances de PostGreSQL et avait perdu le mécanisme de haute disponibilité le 1er mars 2013 nécessitant 5 jours d’efforts pour le remettre en fonctionnement… Et Jean-Louis Bergamo (@JLB666 ça ne s’invente pas…) était fier de présenter ce désastre comme une réussite aux PGDays 2014…
Il est a noter que leboncoin utilise une seule instance MS SQL Server pour leur base analytique… !

 

[1] la compression des données dans SQL Server concerne les données des tables et des index et s’opère a différents niveau qui permettent d’économiser plus ou moins d’octets, mais n’affecte pas les lectures dont les performances sont améliorées grâce au gain de place en cache liée à cette compression.  Les techniques de compressions étant spécifiques aux SGBDR. Dans SQL Server ces algorithmes consistent en deux familles : l’élimination des données non significatives d’une part (compression « ROW ») et la réalisation de dictionnaires de racines d’autre part (compression « PAGE ») dont on trouvera, pour cette dernière, quelques les détails techniques ici : Implémentation de la compression de page

 

Fred Brouard/SQLpro, expert bases de données relationnelles SQLpro@SQLspot.com
* Le site sur les SGBD relationnels et le SQL : https://sqlpro.developpez.com *
* le blog SQL, SQL Server, SGBDR... sur : https://blog.developpez.com/sqlpro/ *
* Expert Microsoft SQL Server MVP (Most valuable Professional) pendant 14 ans *
* Entreprise SQL SPOT : modélisation, conseil, audit, optimisation, formation *
* * * * * Enseignant CNAM PACA -  ISEN Toulon  - CESI Aix en Provence * * * * *
***             Et pour un séjour à Toulon, pensez au 16e ciel !            ***