Le théorème CAP est la pierre angulaire de la théorie des systèmes distribués. Bien sûr, la controverse qui l'entoure ne s'apaise pas : les définitions qu'il contient ne sont pas canoniques, et il n'y a pas de preuve stricte... Néanmoins, fermement ancrés dans les positions du bon sens quotidien™, nous comprenons intuitivement que le théorème est vrai.
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 jusqu'à ce qu'un quorum soit atteint ou de restituer les données disponibles. En fonction des résultats de ce choix, le système est classé soit en CP, soit en AP. Cassandra, par exemple, peut se comporter dans les deux sens, en fonction même 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 se divise, alors quoi ?
La réponse à cette question est quelque peu inattendue : un cluster CA ne peut pas se diviser.
De quel type de cluster s'agit-il qui ne peut pas se diviser ?
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 capables de maintenir une infrastructure SAN. Pour que plusieurs serveurs fonctionnent avec les mêmes données, un système de fichiers en cluster est requis. De tels systèmes de fichiers sont disponibles dans les portefeuilles HPE (CFS), Veritas (VxCFS) et IBM (GPFS).
OracleRAC
L'option Real Application Cluster est apparue pour la première fois en 2001 avec la sortie d'Oracle 9i. Dans un tel cluster, plusieurs instances de serveur fonctionnent avec la même base de données.
Oracle peut fonctionner à la fois avec un système de fichiers en cluster et avec sa propre solution - ASM, Automatic Storage Management.
Chaque exemplaire tient son propre journal. La transaction est exécutée et validée par une seule instance. Si une instance échoue, l'un des nœuds de cluster survivants (instances) lit son journal et restaure les données perdues, garantissant ainsi la disponibilité.
Toutes les instances conservent leur propre cache et les mêmes pages (blocs) peuvent se trouver simultanément dans les caches de plusieurs instances. De plus, si une instance a besoin d'une page et qu'elle se trouve dans le cache d'une autre instance, elle peut l'obtenir auprès de son voisin en utilisant le mécanisme de fusion de cache au lieu de la lire à partir du disque.
Mais que se passe-t-il si l’une des instances doit modifier des données ?
La particularité d'Oracle est qu'il ne dispose pas de service de verrouillage dédié : si le serveur souhaite verrouiller une ligne, alors l'enregistrement de verrouillage est placé directement sur la page mémoire où se trouve la ligne verrouillée. Grâce à cette approche, Oracle est le champion des performances parmi les bases de données monolithiques : le service de verrouillage ne devient jamais un goulot d'étranglement. Mais dans une configuration en cluster, une telle architecture peut conduire à un trafic réseau intense et à des blocages.
Une fois qu'un enregistrement est verrouillé, une instance informe toutes les autres instances que la page qui stocke cet enregistrement bénéficie d'une conservation exclusive. Si une autre instance doit modifier un enregistrement sur la même page, elle doit attendre que les modifications apportées à la page soient validées, c'est-à-dire que les informations de modification soient écrites dans un journal sur le disque (et que la transaction puisse continuer). Il peut également arriver qu'une page soit modifiée séquentiellement par plusieurs copies, puis lors de l'écriture de la page sur le disque, vous devrez savoir qui stocke la version actuelle de cette page.
La mise à jour aléatoire des mêmes pages sur différents nœuds RAC entraîne une chute spectaculaire des performances de la base de données, au point que les performances du cluster peuvent être inférieures à celles d'une instance unique.
L'utilisation correcte d'Oracle RAC consiste à partitionner physiquement les données (par exemple, à l'aide d'un 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 garantie de la tolérance aux pannes.
Si un nœud cesse de répondre à un battement de cœur, le nœud qui l'a détecté démarre en premier une procédure de vote sur le disque. Si le nœud manquant n'est pas noté ici, alors 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 simultanément si d'autres nœuds disposent de versions plus récentes des pages en cours de modification ;
- annule les transactions en attente.
Pour simplifier la commutation entre les nœuds, Oracle a le concept de 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 de données (par exemple, un groupe de clients) fonctionne avec un service, et le service responsable de cette partie de la base de données se déplace vers un autre nœud lorsqu'un nœud tombe en panne.
IBM Pure Data Systems pour les transactions
Une solution cluster pour SGBD est apparue dans le portefeuille Blue Giant en 2009. Idéologiquement, il est le successeur du cluster Parallel Sysplex, construit sur des équipements « classiques ». En 2009, DB2 pureScale, une suite logicielle, a été lancée et en 2012, IBM a proposé 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 qu'un Netezza renommé.
À première vue, l'architecture pureScale est similaire à Oracle RAC : de la même manière, plusieurs nœuds sont connectés à un système de stockage de données commun, et chaque nœud exécute sa propre instance de SGBD avec ses propres zones mémoire et journaux de transactions. Mais contrairement à Oracle, DB2 dispose d'un service de verrouillage dédié représenté par un ensemble de processus db2LLM*. Dans une configuration de cluster, ce service est placé sur un nœud distinct, appelé installation de couplage (CF) dans Parallel Sysplex et PowerHA dans Pure Data.
PowerHA fournit les services suivants :
- gestionnaire de serrures ;
- cache de tampon global ;
- domaine des communications interprocessus.
Pour transférer des données de PowerHA vers les nœuds de base de données et inversement, l'accès à la mémoire à distance est utilisé, l'interconnexion du cluster doit donc 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, alors le nœud demande la page dans le cache global et seulement si elle n'y est pas, la lit à partir du disque. Contrairement à Oracle, la requête est adressée uniquement à PowerHA, et non aux nœuds voisins.
Si une instance doit modifier une ligne, elle la verrouille en mode exclusif, et la page où se trouve la ligne 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 dans laquelle se trouve la ligne modifiée est déjà verrouillée, alors le gestionnaire de verrouillage lira la page modifiée dans la mémoire du nœud qui a effectué la modification, libérera le verrou, invalidera la page modifiée dans les caches des autres nœuds, et donnez le verrou de page au nœud qui l'a demandé.
Les pages « sales », c'est-à-dire modifiées, peuvent être écrites sur le disque à la fois à partir d'un nœud standard et à partir de PowerHA (castout).
Si l'un des nœuds pureScale échoue, la récupération est limitée aux seules 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 se trouvent dans le cache global sur PowerHA. Le nœud redémarre dans une configuration réduite sur l'un des serveurs du cluster, annule les transactions en attente 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 sauvegarde.
Bien entendu, si vous accédez à l'ensemble de données via un seul nœud, les performances globales du cluster seront plus élevées. PureScale peut même remarquer qu'une certaine zone de données est traitée par un nœud, puis tous les verrous liés à cette zone seront traités localement par le nœud sans communiquer avec PowerHA. Mais dès que l'application tentera d'accéder à ces données via un autre nœud, le traitement de verrouillage centralisé reprendra.
Les tests internes d'IBM sur une charge de travail de 90 % en lecture et 10 % en écriture, ce qui est très similaire aux charges de travail de production réelles, montrent une mise à l'échelle presque linéaire jusqu'à 128 nœuds. Les conditions de test ne sont malheureusement pas divulguées.
HPE NonStopSQL
Le portefeuille Hewlett-Packard Enterprise dispose également de sa propre plate-forme hautement disponible. Il s'agit de la plate-forme NonStop, lancée sur le marché en 1976 par Tandem Computers. En 1997, l'entreprise est rachetée par Compaq, qui fusionne à son tour avec Hewlett-Packard en 2002.
NonStop est utilisé pour créer des applications critiques - par exemple, HLR ou traitement des cartes bancaires. La plateforme est livrée sous la forme d'un complexe logiciel et matériel (appliance), qui comprend des nœuds informatiques, un système de stockage de données et des équipements de communication. Le réseau ServerNet (dans les systèmes modernes - Infiniband) sert à la fois à l'échange entre les nœuds et à l'accès au système de stockage de données.
Les premières versions du système utilisaient des processeurs propriétaires 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 faisait une erreur, il était éteint 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 possède un jumeau « fantôme », auquel le processus actif envoie périodiquement des messages sur son état ; si le processus principal échoue, le processus fantôme commence à fonctionner à partir du moment déterminé par le dernier message ;
- vote : le système de stockage dispose d'un composant matériel spécial qui accepte plusieurs accès identiques et les exécute uniquement si les accès correspondent ; Au lieu d'une synchronisation physique, les processeurs fonctionnent de manière asynchrone et les résultats de leur travail ne sont comparés qu'aux moments d'E/S.
Depuis 1987, un SGBD relationnel fonctionne sur la plateforme NonStop - d'abord SQL/MP, puis SQL/MX.
L'ensemble de la base de données est divisé en parties, et chaque partie est responsable de son propre processus Data Access Manager (DAM). Il fournit des mécanismes d’enregistrement, de mise en cache et de verrouillage des données. Le traitement des données est effectué par des processus Executor Server exécutés sur les mêmes nœuds que les gestionnaires de données correspondants. Le planificateur SQL/MX répartit les tâches entre les exécuteurs et regroupe les résultats. Lorsqu'il est nécessaire d'apporter des modifications convenues, le protocole de validation en deux phases fourni par la bibliothèque TMF (Transaction Management Facility) est utilisé.
NonStop SQL peut hiérarchiser les processus afin que les longues requêtes analytiques n'interfèrent pas avec l'exécution des transactions. Cependant, son objectif est précisément le traitement de transactions à court terme, et non 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 est passé à 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 DBMS et MAX DB.
Le mot « HANA » lui-même est un acronyme pour High Performance ANalytical Appliance. 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 du matériel certifié. Solutions disponibles auprès de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Certaines configurations Lenovo permettent même un fonctionnement sans SAN - le rôle d'un système de stockage commun est joué par un cluster GPFS sur les disques locaux.
Contrairement aux plates-formes répertoriées ci-dessus, HANA est un SGBD en mémoire, c'est-à-dire que l'image des données primaires est stockée dans la RAM, et seuls les journaux et les instantanés périodiques sont écrits sur le disque pour être récupérés en cas de sinistre.
Chaque nœud du cluster HANA est responsable de sa propre partie des données et la carte de données est stockée dans un composant spécial – Name Server, situé sur le nœud coordinateur. Les données ne sont pas dupliquées entre les nœuds. Les informations de verrouillage sont également stockées sur chaque nœud, mais le système dispose d'un détecteur de blocage global.
Lorsqu'un client HANA se connecte à un cluster, il télécharge sa topologie et peut ensuite 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 exécutée localement par ce nœud, 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 coordinateur est dupliqué, donc si le coordinateur échoue, le nœud de sauvegarde prend immédiatement le relais. Mais si un nœud contenant des données tombe en panne, le seul moyen d'accéder à ses données est de redémarrer le nœud. En règle générale, les clusters HANA conservent un serveur de rechange afin d'y redémarrer un nœud perdu le plus rapidement possible.
Source: habr.com