La seule chose qui n'est pas évidente est la signification de la lettre "P". Lorsque le cluster est divisé, il décide de ne pas répondre tant que le quorum n'est pas atteint ou de fournir les données qui le sont. En fonction des résultats de cette sélection, le système est classé comme CP ou AP. Cassandra, par exemple, peut se comporter de cette façon et cela, en fonction même pas des paramètres du cluster, mais des paramètres de chaque requête spécifique. Mais si le système n'est pas "P" et qu'il s'est divisé, alors quoi?
La réponse à cette question est quelque peu inattendue: le cluster CA ne peut pas être divisé.
Quel est ce cluster qui ne peut pas être divisé?
Un attribut indispensable d'un tel cluster est un système de stockage de données partagé. Dans la grande majorité des cas, cela signifie se connecter via un SAN, ce qui limite l'utilisation des solutions CA aux grandes entreprises qui peuvent héberger une infrastructure SAN. Pour que plusieurs serveurs puissent travailler avec les mêmes données, un système de fichiers en cluster est requis. Ces systèmes de fichiers se trouvent dans les portefeuilles de HPE (CFS), Veritas (VxCFS) et IBM (GPFS).
Oracle RAC
L'option Real Application Cluster est apparue pour la première fois dans la version 2001 d'Oracle 9i. Dans un cluster tel que plusieurs instances de serveur fonctionnent avec la même base de données.
Oracle peut fonctionner à la fois avec un système de fichiers de cluster et sa propre solution - ASM, Automatic Storage Management.
Chaque exemplaire tient son propre journal. La transaction est exécutée et validée en une seule instance. En cas de défaillance d'une instance, l'un des nœuds de cluster (instances) survivants lit son journal et récupère les données perdues, garantissant ainsi la disponibilité.
Toutes les instances gèrent leur propre cache, et les mêmes pages (blocs) peuvent être simultanément dans les caches de plusieurs instances. De plus, si une page est requise par une instance et qu'elle se trouve dans le cache d'une autre instance, elle peut l'obtenir du «voisin» en utilisant le mécanisme de fusion du cache au lieu de la lire à partir du disque.
Mais que se passe-t-il si l'une des instances a besoin de modifier les données?
La particularité d'Oracle est qu'il ne dispose pas d'un service de verrouillage dédié: si le serveur veut verrouiller une ligne, alors l'enregistrement de verrouillage est placé directement sur la page mémoire où se trouve la ligne verrouillée. Cette approche fait d'Oracle le champion des performances des bases de données monolithiques: le service de verrouillage ne devient jamais un goulot d'étranglement. Mais dans une configuration en cluster, cette architecture peut entraîner un trafic réseau important et des blocages.
Dès qu'un enregistrement est bloqué, l'instance informe toutes les autres instances que la page qui stocke l'enregistrement a été acquise en mode exclusif. Si une autre instance doit modifier un enregistrement sur la même page, elle doit attendre que les modifications de la page soient validées, c'est-à-dire que les informations de modification sont écrites dans le journal du disque (et la transaction peut continuer). Il peut également arriver que la page soit modifiée séquentiellement de plusieurs copies, puis, lors de l'écriture de la page sur le disque, vous devrez savoir qui possède la version actuelle de cette page.
L'actualisation accidentelle des mêmes pages sur différents nœuds RAC dégrade considérablement les performances de la base de données, au point où les performances du cluster peuvent être plus lentes qu'une seule instance.
L'utilisation correcte d'Oracle RAC consiste à partitionner physiquement les données (par exemple, à l'aide du mécanisme de table partitionnée) et à accéder à chaque ensemble de partitions via un nœud dédié. L'objectif principal du RAC n'était pas la mise à l'échelle horizontale, mais la tolérance aux pannes.
Si un nœud cesse de répondre à la pulsation, le nœud qui le détecte démarre en premier la procédure de vote de disque. Si le nœud manquant n'a pas été noté ici, l'un des nœuds assume la responsabilité de la récupération des données:
- «Gèle» toutes les pages qui se trouvaient dans le cache du nœud manquant;
- Lit les journaux (refaire) du nœud manquant et réapplique les modifications enregistrées dans ces journaux, en vérifiant en cours de route si d'autres nœuds ont des versions plus récentes des pages modifiées;
- annule les transactions non validées.
Pour simplifier la commutation entre les nœuds, Oracle a le concept d'un service - une instance virtuelle. Une instance peut servir plusieurs services et un service peut se déplacer entre les nœuds. Une instance d'application desservant une certaine partie de la base (par exemple, un groupe de clients) fonctionne avec un service et le service responsable de cette partie de la base, lorsqu'un nœud tombe en panne, se déplace vers un autre nœud.
IBM Pure Data Systems for Transactions
La solution cluster pour le SGBD est apparue dans le portefeuille Blue Giant en 2009. Idéologiquement, il est l'héritier du cluster Parallel Sysplex construit sur du matériel "conventionnel". En 2009, DB2 pureScale est sorti en tant que suite logicielle et en 2012, IBM propose une appliance appelée Pure Data Systems for Transactions. Il ne faut pas le confondre avec Pure Data Systems for Analytics, qui n'est rien de plus que le renommé Netezza.
L'architecture pureScale ressemble à Oracle RAC à première vue: de la même manière, plusieurs nœuds sont connectés à un système de stockage partagé, et chaque nœud exécute sa propre instance d'un SGBD avec ses propres zones de mémoire et journaux de transactions. Mais contrairement à Oracle, DB2 dispose d'un service de verrouillage dédié représenté par l'ensemble de processus db2LLM *. Dans une configuration en cluster, ce service est placé sur un nœud séparé, appelé la fonction de couplage (CF) dans Parallel Sysplex et PowerHA dans Pure Data.
PowerHA fournit les services suivants:
- gestionnaire de serrure;
- cache tampon global;
- le domaine des communications interprocessus.
L'accès à la mémoire à distance est utilisé pour transférer des données de PowerHA vers des nœuds de base de données et vice versa, de sorte que l'interconnexion de cluster doit prendre en charge le protocole RDMA. PureScale peut utiliser à la fois Infiniband et RDMA sur Ethernet.
Si un nœud a besoin d'une page et que cette page n'est pas dans le cache, le nœud demande une page dans le cache global, et seulement s'il n'y est pas, il la lit à partir du disque. Contrairement à Oracle, la requête ne va qu'à PowerHA et non aux nœuds voisins.
Si l'instance est sur le point de changer la chaîne, elle la bloque en mode exclusif, et la page où la chaîne réside en mode partagé. Tous les verrous sont enregistrés dans le gestionnaire de verrous global. Une fois la transaction terminée, le nœud envoie un message au gestionnaire de verrous, qui copie la page modifiée dans le cache global, libère les verrous et invalide la page modifiée dans les caches des autres nœuds.
Si la page contenant la chaîne modifiée est déjà verrouillée, le gestionnaire de verrouillage lira la page modifiée dans la mémoire du nœud qui a effectué les modifications, libère le verrou, invalide la page modifiée dans les caches des autres nœuds et attribue le verrou de page au nœud qui l'a demandé.
«Sale», c'est-à-dire modifié, les pages peuvent être écrites sur le disque à la fois à partir d'un nœud normal et de PowerHA (castout).
Si l'un des nœuds pureScale échoue, la récupération est limitée uniquement aux transactions qui n'étaient pas encore terminées au moment de l'échec: les pages modifiées par ce nœud dans les transactions terminées sont dans le cache global sur PowerHA. Le nœud redémarre dans une configuration simplifiée sur l'un des serveurs de cluster, annule les transactions non validées et libère les verrous.
PowerHA s'exécute sur deux serveurs et le nœud maître réplique son état de manière synchrone. Si le nœud PowerHA principal tombe en panne, le cluster continue de fonctionner avec le nœud de secours.
Bien sûr, si vous accédez à l'ensemble de données via un seul nœud, les performances globales du cluster seront meilleures. PureScale peut même remarquer qu'une zone de données est en cours de traitement par un nœud, puis tous les verrous liés à cette zone seront traités localement par le nœud sans communication avec PowerHA. Mais dès que l'application tente d'accéder à ces données via un autre nœud, le traitement de verrouillage centralisé reprendra.
Les benchmarks internes d'IBM à 90% de charge de travail en lecture et 10% en écriture, très similaires à une charge de production réelle, montrent une mise à l'échelle presque linéaire jusqu'à 128 nœuds. Les conditions de test, hélas, n'ont pas été révélées.
HPE NonStop SQL
Le portefeuille Hewlett-Packard Enterprise dispose également de sa propre plate-forme hautement disponible. Il s'agit de la plateforme NonStop lancée en 1976 par Tandem Computers. En 1997, la société a été acquise par Compaq, qui a fusionné à son tour avec Hewlett-Packard en 2002.
NonStop est utilisé pour créer des applications critiques - par exemple, le traitement HLR ou des cartes bancaires. La plate-forme est livrée sous la forme d'un complexe logiciel et matériel (appareil), qui comprend des nœuds informatiques, un système de stockage de données et des équipements de communication. ServerNet (dans les systèmes modernes - Infiniband) sert à la fois pour l'échange entre les nœuds et pour l'accès au système de stockage de données.
Les versions précédentes du système utilisaient des processeurs propriétaires qui étaient synchronisés les uns avec les autres: toutes les opérations étaient effectuées de manière synchrone par plusieurs processeurs, et dès que l'un des processeurs se trompait, il était désactivé et le second continuait à fonctionner. Plus tard, le système est passé aux processeurs conventionnels (d'abord MIPS, puis Itanium, et enfin x86), et d'autres mécanismes ont commencé à être utilisés pour la synchronisation:
- messages: chaque processus système a un jumeau «shadow», auquel le processus actif envoie périodiquement des messages sur son état; si le processus principal échoue, le processus d'observation commence à fonctionner à partir du moment déterminé par le dernier message;
- : , , ; , /.
Depuis 1987, un SGBD relationnel fonctionne sur la plate-forme NonStop - d'abord SQL / MP, puis SQL / MX.
La base de données entière est divisée en parties, et chaque partie est responsable de son propre processus Data Access Manager (DAM). Il fournit un mécanisme d'écriture, de mise en cache et de verrouillage des données. Le traitement des données est géré par le processus serveur exécuteur, fonctionnant sur les mêmes nœuds que les gestionnaires de données respectifs. Le planificateur SQL / MX répartit les tâches entre les exécuteurs et fusionne les résultats. Si vous devez apporter des modifications cohérentes, utilisez le protocole de validation en deux phases fourni par la bibliothèque TMF (Transaction Management Facility).
NonStop SQL sait hiérarchiser les processus afin que les longues requêtes analytiques n'interfèrent pas avec l'exécution des transactions. Cependant, son but est précisément le traitement de transactions courtes, pas l'analyse. Le développeur garantit la disponibilité du cluster NonStop au niveau de cinq neuf, c'est-à-dire que le temps d'arrêt n'est que de 5 minutes par an.
SAP HANA
La première version stable du SGBD HANA (1.0) a eu lieu en novembre 2010 et le package SAP ERP a été déplacé vers HANA en mai 2013. La plateforme est basée sur des technologies achetées: TREX Search Engine (recherche dans le stockage en colonnes), P * TIME et MAX DB.
Le mot «HANA» lui-même est un acronyme, Appliance ANalytique haute performance. Ce SGBD est fourni sous forme de code pouvant s'exécuter sur n'importe quel serveur x86, cependant, les installations industrielles ne sont autorisées que sur des équipements certifiés. Il existe des solutions de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Certaines configurations Lenovo permettent même un fonctionnement sans SAN - un cluster GPFS sur des disques locaux joue le rôle de stockage partagé.
Contrairement aux plates-formes répertoriées ci-dessus, HANA est un SGBD en mémoire, c'est-à-dire que l'image principale des données est stockée dans la RAM, et seuls les journaux et les instantanés périodiques sont écrits sur le disque pour une récupération en cas de sinistre.
Chaque nœud du cluster HANA est responsable de sa propre partie des données et la mappe de données est stockée dans un composant spécial, le serveur de noms, situé sur le nœud du coordinateur. Les données entre les nœuds ne sont pas dupliquées. Les informations de verrouillage sont également stockées sur chaque nœud, mais le système dispose d'un détecteur de blocage global.
Un client HANA, lorsqu'il se connecte à un cluster, charge sa topologie et, à l'avenir, peut accéder directement à n'importe quel nœud, en fonction des données dont il a besoin. Si une transaction affecte les données d'un seul nœud, elle peut être effectuée par ce nœud localement, mais si les données de plusieurs nœuds changent, le nœud initiateur contacte le nœud coordinateur, qui ouvre et coordonne la transaction distribuée, en la validant à l'aide d'un protocole de validation en deux phases optimisé.
Le nœud du coordinateur est dupliqué, donc si le coordinateur échoue, le nœud de sauvegarde prend immédiatement le relais. Mais si un nœud avec des données échoue, le seul moyen d'accéder à ses données est de redémarrer le nœud. En règle générale, dans les clusters HANA, un serveur de rechange est conservé afin de redémarrer le nœud perdu sur celui-ci dès que possible.