Comparaison de la solution Oracle RAC HA à Galera Cluster pour MySQL ou MariaDB

Les entreprises ont toujours souhaité tirer des enseignements des informations pour prendre des décisions fiables, plus intelligentes, en temps réel et fondées sur des faits. Comme les entreprises s'appuient davantage sur les données et les bases de données, l'information et le traitement des données sont au cœur de nombreuses opérations commerciales et décisions commerciales. La confiance dans la base de données est totale. Aucun des services quotidiens de l'entreprise ne peut fonctionner sans les plates-formes de base de données sous-jacentes. En conséquence, la nécessité d'évolutivité et de performances des logiciels de système de base de données est plus critique que jamais. Les principaux avantages du système de base de données en cluster sont l'évolutivité et la haute disponibilité. Dans ce blog, nous allons essayer de comparer Oracle RAC et Galera Cluster à la lumière de ces deux aspects. Real Application Clusters (RAC) est la solution premium d'Oracle pour la mise en cluster des bases de données Oracle et offre une haute disponibilité et une évolutivité. Galera Cluster est la technologie de clustering la plus populaire pour MySQL et MariaDB.

Présentation de l'architecture

Oracle RAC utilise le logiciel Oracle Clusterware pour lier plusieurs serveurs. Oracle Clusterware est une solution de gestion de cluster intégrée à Oracle Database, mais elle peut également être utilisée avec d'autres services, pas seulement la base de données. Oracle Clusterware est un logiciel supplémentaire installé sur des serveurs exécutant le même système d'exploitation, qui permet aux serveurs d'être enchaînés pour fonctionner comme s'ils n'étaient qu'un seul serveur.

Oracle Clusterware surveille l'instance et la redémarre automatiquement en cas de panne. Si votre application est bien conçue, vous ne subirez peut-être aucune interruption de service. Seul un groupe de sessions (celles connectées à l'instance défaillante) est affecté par l'échec. La panne peut être efficacement masquée pour l'utilisateur final à l'aide de fonctionnalités RAC avancées telles que la notification d'application rapide et le basculement de connexion rapide du client Oracle. Oracle Clusterware contrôle l'appartenance aux nœuds et empêche les symptômes de cerveau partagé dans lesquels deux instances ou plus tentent de contrôler l'instance.

Galera Cluster est une technologie de clustering de base de données active-active synchrone pour MySQL et MariaDB. Galera Cluster diffère de ce que l'on appelle le cluster MySQL d'Oracle - NDB. Le cluster MariaDB est basé sur le plugin de réplication multi-maître fourni par Codership. Depuis la version 5.5, le plugin Galera (API wsrep) fait partie intégrante de MariaDB. Percona XtraDB Cluster (PXC) est également basé sur le plugin Galera. L'architecture du plugin Galera repose sur trois couches principales :certification, réplication et cadre de communication de groupe. La couche de certification prépare les ensembles d'écriture et effectue les vérifications de certification sur eux, garantissant qu'ils peuvent être appliqués. La couche de réplication gère le protocole de réplication et fournit la capacité de commande totale. Group Communication Framework implémente une architecture de plug-in qui permet à d'autres systèmes de se connecter via le schéma principal de gcomm.

Pour conserver l'état identique sur l'ensemble du cluster, l'API wsrep utilise un ID de transaction global. L'identifiant unique GTID est créé et associé à chaque transaction validée sur le nœud de la base de données. Dans Oracle RAC, diverses instances de base de données partagent l'accès à des ressources telles que des blocs de données dans le cache de tampon pour mettre en file d'attente des blocs de données. L'accès aux ressources partagées entre les instances RAC doit être coordonné pour éviter les conflits. Pour organiser l'accès partagé à ces ressources, le cache distribué conserve des informations telles que l'ID du bloc de données, l'instance RAC contenant la version actuelle de ce bloc de données et le mode de verrouillage dans lequel chaque instance contient le bloc de données.

Concepts clés de stockage de données

Oracle RAC s'appuie sur une architecture de disque distribué. Les fichiers de base de données, les fichiers de contrôle et les journaux redo en ligne pour la base de données doivent être accessibles à chaque nœud du cluster. Il existe différentes manières de configurer le stockage partagé, notamment les disques directement connectés, les réseaux de stockage (SAN), le stockage en réseau (NAS) et Oracle ASM. Les deux plus populaires sont OCFS et ASM. Oracle Cluster File System (OCFS) est un système de fichiers partagé conçu spécifiquement pour Oracle RAC. OCFS élimine l'exigence selon laquelle les fichiers de base de données Oracle doivent être connectés à des lecteurs logiques et permet à tous les nœuds de partager un seul Oracle Home ASM, RAW Device. Oracle ASM est la solution de gestion de stockage conseillée d'Oracle qui offre une alternative aux gestionnaires de volumes, systèmes de fichiers et périphériques bruts conventionnels. Oracle ASM fournit une couche de virtualisation entre la base de données et le stockage. Il traite plusieurs disques comme un seul groupe de disques et vous permet d'ajouter ou de supprimer dynamiquement des disques tout en maintenant les bases de données en ligne.

Il n'est pas nécessaire de créer un stockage sur disque partagé sophistiqué pour Galera, car chaque nœud dispose de sa copie complète des données. Cependant, il est recommandé de fiabiliser le stockage avec des caches en écriture sauvegardés par batterie.

Communication et cache des nœuds du cluster

Oracle Real Application Clusters a une architecture de cache partagé, il utilise Oracle Grid Infrastructure pour permettre le partage des ressources de serveur et de stockage. La communication entre les nœuds est l'aspect critique de l'intégrité du cluster. Chaque nœud doit disposer d'au moins deux adaptateurs réseau ou cartes d'interface réseau :un pour l'interface réseau public et un pour l'interconnexion. Chaque nœud de cluster est connecté à tous les autres nœuds via un réseau privé à haut débit, également reconnu comme l'interconnexion de cluster.

Le réseau privé est généralement formé avec Gigabit Ethernet, mais pour les environnements à volume élevé, de nombreux fournisseurs proposent des solutions à faible latence et à large bande passante conçues pour Oracle RAC. Linux étend également un moyen de lier plusieurs cartes réseau physiques en une seule carte réseau virtuelle pour fournir une bande passante et une disponibilité accrues.

Bien que l'approche par défaut pour connecter les nœuds Galera consiste à utiliser une seule carte réseau par hôte, vous pouvez avoir plusieurs cartes. ClusterControl peut vous aider avec une telle configuration. La principale différence est l'exigence de bande passante sur l'interconnexion. Oracle RAC expédie des blocs de données entre les instances, ce qui impose une charge plus lourde sur l'interconnexion par rapport aux jeux d'écriture Galera (qui consistent en une liste d'opérations).

Avec l'utilisation de l'interconnexion redondante dans RAC, vous pouvez identifier plusieurs interfaces à utiliser pour le réseau de cluster privé, sans avoir besoin d'utiliser la liaison ou d'autres technologies. Cette fonctionnalité est disponible à partir d'Oracle Database 11gR2. Si vous utilisez la fonction d'interconnexion excessive d'Oracle Clusterware, vous devez utiliser des adresses IPv4 pour les interfaces (UDP est une valeur par défaut).

Pour gérer la haute disponibilité, chaque nœud de cluster se voit attribuer une adresse IP virtuelle (VIP). En cas de défaillance d'un nœud, l'adresse IP du nœud défaillant peut être réattribuée à un nœud survivant pour permettre aux applications de continuer à accéder à la base de données via la même adresse IP.

Une configuration réseau sophistiquée est nécessaire à la technologie Cache Fusion d'Oracle pour coupler la mémoire physique de chaque hôte en un seul cache. Oracle Cache Fusion permet aux données stockées dans le cache d'une instance Oracle d'être accessibles à toute autre instance en les transportant sur le réseau privé. Il protège également l'intégrité des données et la cohérence du cache en transmettant des informations de verrouillage et de synchronisation supplémentaires au-delà des nœuds du cluster.

En plus de la configuration réseau décrite, vous pouvez définir une seule adresse de base de données pour votre application - Single Client Access Name (SCAN). L'objectif principal de SCAN est de faciliter la gestion des connexions. Par exemple, vous pouvez ajouter de nouveaux nœuds au cluster sans modifier votre chaîne de connexion client. Cette fonctionnalité est due au fait qu'Oracle distribuera automatiquement les demandes en conséquence en fonction des IP SCAN qui pointent vers les VIP sous-jacents. Les écouteurs de balayage font le pont entre les clients et les écouteurs locaux sous-jacents qui dépendent de VIP.

Pour Galera Cluster, l'équivalent de SCAN consisterait à ajouter un proxy de base de données devant les nœuds Galera. Le proxy serait un point de contact unique pour les applications, il peut mettre sur liste noire les nœuds défaillants et acheminer les requêtes vers des nœuds sains. Le proxy lui-même peut être rendu redondant avec Keepalived et Virtual IP.

Basculement et récupération de données

La principale différence entre Oracle RAC et MySQL Galera Cluster est que Galera est une architecture sans partage. Au lieu de disques partagés, Galera utilise une réplication basée sur la certification avec une communication de groupe et un ordre de transaction pour réaliser une réplication synchrone. Un cluster de bases de données devrait pouvoir survivre à la perte d'un nœud, bien que cela soit réalisé de différentes manières. Dans le cas de Galera, l'aspect critique est le nombre de nœuds, Galera nécessite un quorum pour rester opérationnel. Un cluster à trois nœuds peut survivre au crash d'un nœud. Avec plus de nœuds dans votre cluster, votre disponibilité augmentera. Oracle RAC ne nécessite pas de quorum pour rester opérationnel après une panne de nœud. C'est à cause de l'accès au stockage distribué qui conserve des informations cohérentes sur l'état du cluster. Cependant, votre stockage de données pourrait être un point de défaillance potentiel dans votre plan de haute disponibilité. Bien qu'il soit relativement simple d'avoir des nœuds de cluster Galera répartis dans des centres de données de géolocalisation, ce ne serait pas si facile avec RAC. Oracle RAC nécessite une mise en miroir de disque haut de gamme supplémentaire, cependant, une redondance de base de type RAID peut être obtenue à l'intérieur d'un groupe de disques ASM.

Schémas de verrouillage

Dans une base de données mono-utilisateur, un utilisateur peut modifier des données sans se soucier des autres sessions modifiant les mêmes données en même temps. Cependant, dans un environnement multi-nœuds de base de données multi-utilisateurs, cela devient plus délicat. Une base de données multi-utilisateurs doit fournir les éléments suivants :

• concurrence des données :l'assurance que les utilisateurs peuvent accéder aux données en même temps,
• cohérence des données :l'assurance que chaque utilisateur dispose d'une vue cohérente des données.

Les instances de cluster nécessitent trois types principaux de verrouillage de la concurrence :

• La simultanéité des données se lit sur différentes instances,
• La simultanéité des données lit et écrit sur différentes instances,
• La simultanéité des données écrit sur différentes instances

Oracle vous permet de choisir la politique de verrouillage, pessimiste ou optimiste, en fonction de vos besoins. Pour obtenir le verrouillage de la concurrence, RAC dispose de deux tampons supplémentaires. Il s'agit du Global Cache Service (GCS) et du Global Enqueue Service (GES). Ces deux services couvrent le processus de fusion de cache, les transferts de ressources et les escalades de ressources entre les instances. Les GES incluent les verrous de cache, les verrous de dictionnaire, les verrous de transaction et les verrous de table. GCS gère les modes de blocage et les transferts de blocs entre les instances.

Dans le cluster Galera, chaque nœud a son stockage et ses tampons. Lorsqu'une transaction est démarrée, les ressources de base de données locales à ce nœud sont impliquées. Lors de la validation, les opérations qui font partie de cette transaction sont diffusées dans le cadre d'un jeu d'écriture, au reste du groupe. Étant donné que tous les nœuds ont le même état, le jeu d'écriture réussira sur tous les nœuds ou échouera sur tous les nœuds.

Galera Cluster utilise au niveau du cluster un contrôle de concurrence optimiste, qui peut apparaître dans les transactions qui entraînent un abandon COMMIT. Le premier commit gagne. Lorsque des abandons se produisent au niveau du cluster, Galera Cluster génère une erreur de blocage. Cela peut ou non avoir un impact sur l'architecture de votre application. Un nombre élevé de lignes à répliquer dans une seule transaction aurait un impact sur les réponses des nœuds, bien qu'il existe des techniques pour éviter un tel comportement.

Configuration matérielle et logicielle requise

La configuration du matériel des deux clusters ne nécessite pas de ressources puissantes. La configuration minimale du cluster Oracle RAC serait satisfaite par deux serveurs avec deux processeurs, une mémoire physique d'au moins 1,5 Go de RAM, une quantité d'espace d'échange égale à la quantité de RAM et deux cartes réseau Gigabit Ethernet. La configuration minimale des nœuds de Galera est de trois nœuds (l'un des nœuds peut être un arbitre, gardb), chacun avec un processeur monocœur de 1 GHz, 512 Mo de RAM, une carte réseau de 100 Mbps. Bien qu'il s'agisse du minimum, nous pouvons affirmer que dans les deux cas, vous aimeriez probablement disposer de plus de ressources pour votre système de production.

Chaque nœud stocke des logiciels, vous devrez donc préparer plusieurs gigaoctets de votre stockage. Oracle et Galera ont tous deux la possibilité de patcher individuellement les nœuds en les supprimant un à la fois. Ce correctif progressif évite une panne complète de l'application car il y a toujours des nœuds de base de données disponibles pour gérer le trafic.

Ce qu'il est important de mentionner, c'est qu'un cluster Galera de production peut facilement fonctionner sur des machines virtuelles ou sur du métal nu de base, tandis que RAC aurait besoin d'investir dans un stockage partagé sophistiqué et une communication par fibre.

Suivi et gestion

Oracle Enterprise Manager est l'approche privilégiée pour surveiller Oracle RAC et Oracle Clusterware. Oracle Enterprise Manager est un système de gestion unifié basé sur le Web Oracle pour surveiller et administrer votre environnement de base de données. Il fait partie d'Oracle Enterprise License et doit être installé sur un serveur séparé. La surveillance et la gestion du contrôle du cluster s'effectuent via une combinaison des commandes crsctl et srvctl qui font partie des fichiers binaires du cluster. Vous trouverez ci-dessous quelques exemples de commandes.

Vérification de l'état des ressources du clusterware :

    crsctl status resource -t (or shorter: crsctl stat res -t)

Exemple :

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Vérifiez l'état de la pile Oracle Clusterware :

    crsctl check cluster

Exemple :

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Vérifiez l'état d'Oracle High Availability Services et de la pile Oracle Clusterware sur le serveur local :

    crsctl check crs

Exemple :

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Arrêtez Oracle High Availability Services sur le serveur local.

    crsctl stop has

Arrêtez Oracle High Availability Services sur le serveur local.

    crsctl start has

Affiche l'état des applications de nœud :

    srvctl status nodeapps

Affiche les informations de configuration pour tous les VIP SCAN

    srvctl config scan

Exemple :

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

L'utilitaire de vérification de cluster (CVU) effectue des vérifications du système en vue de l'installation, des mises à jour de correctifs ou d'autres modifications du système :

    cluvfy comp ocr

Exemple :

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Les nœuds Galera et le cluster nécessitent que l'API wsrep signale plusieurs états, ce qui est exposé. Il existe actuellement 34 variables d'état dédiées pouvant être visualisées avec l'instruction SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';

L'administration de MySQL Galera Cluster est à bien des égards très similaire. Il n'y a que quelques exceptions comme l'amorçage du cluster à partir du nœud initial ou la récupération de nœuds via des opérations SST ou IST.

Cluster d'amorçage :

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

La solution Web équivalente prête à l'emploi pour gérer et surveiller Galera Cluster est ClusterControl. Il fournit une interface Web pour déployer des clusters, surveiller les métriques clés, fournir des conseillers de base de données et prendre en charge des tâches de gestion telles que la sauvegarde et la restauration, les correctifs automatiques, le chiffrement du trafic et la gestion de la disponibilité.

Restrictions sur la charge de travail

Oracle fournit la technologie SCAN que nous avons trouvée manquante dans Galera Cluster. L'avantage de SCAN est que les informations de connexion du client n'ont pas besoin de changer si vous ajoutez ou supprimez des nœuds ou des bases de données dans le cluster. Lors de l'utilisation de SCAN, la base de données Oracle se connecte de manière aléatoire à l'un des écouteurs SCAN disponibles (généralement trois) de manière circulaire et équilibre les connexions entre eux. Deux types d'équilibrage de charge peuvent être configurés :côté client, équilibrage de charge au moment de la connexion et côté serveur, équilibrage de charge au moment de l'exécution. Bien qu'il n'y ait rien de similaire dans le cluster Galera lui-même, la même fonctionnalité peut être traitée avec des logiciels supplémentaires comme ProxySQL, HAProxy, Maxscale combiné avec Keepalived.

En ce qui concerne la conception de la charge de travail des applications pour Galera Cluster, vous devez éviter les mises à jour conflictuelles sur la même ligne, car cela entraîne des blocages dans le cluster. Évitez les insertions ou les mises à jour en bloc, car elles peuvent être plus volumineuses que le jeu d'écritures maximal autorisé. Cela pourrait également provoquer des blocages de cluster.

Lors de la conception d'Oracle HA avec RAC, vous devez garder à l'esprit que RAC protège uniquement contre les pannes de serveur et que vous devez mettre en miroir le stockage et disposer d'une redondance réseau. Les applications Web modernes nécessitent un accès à des services de données indépendants de l'emplacement et, en raison des limites de l'architecture de stockage du RAC, cela peut être difficile à réaliser. Vous devez également passer beaucoup de temps à acquérir des connaissances pertinentes pour gérer l'environnement ; C'est un long processus. Du côté de la charge de travail des applications, il y a quelques inconvénients. La distribution d'opérations de lecture ou d'écriture séparées sur le même jeu de données n'est pas optimale car la latence est ajoutée par l'échange de données entre les nœuds supplémentaires. Des éléments tels que le partitionnement, le cache de séquence et les opérations de tri doivent être examinés avant de migrer vers RAC.

Redondance multi-centres de données

Selon la documentation d'Oracle, la distance maximale entre deux boîtiers connectés en point à point et fonctionnant de manière synchrone ne peut être que de 10 km. À l'aide d'appareils spécialisés, cette distance peut être portée à 100 km.

Galera Cluster est bien connu pour ses capacités de réplication multi-centres de données. Il prend en charge les paramètres réseau des réseaux étendus. Il peut être configuré pour une latence de réseau élevée en prenant des mesures de temps d'aller-retour (RTT) entre les nœuds du cluster et en ajustant les paramètres nécessaires. Les paramètres wsrep_provider_options vous permettent de configurer des paramètres tels que suspect_timeout, interactive_timeout, join_retrans_timouts et bien d'autres.

Utiliser Galera et RAC dans le cloud

Selon la note Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf, aucun cloud tiers ne répond actuellement aux exigences d'Oracle concernant le stockage partagé fourni en mode natif. "Natif" dans ce contexte signifie que le fournisseur de cloud doit prendre en charge le stockage partagé dans le cadre de son infrastructure conformément à la politique de support d'Oracle.

Grâce à son architecture sans partage, qui n'est pas liée à une solution de stockage sophistiquée, le cluster Galera peut être facilement déployé dans un environnement cloud. Des choses comme :

• protocole réseau optimisé,
• réplication sensible à la topologie,
• chiffrement du trafic,
• détection et éviction automatique des nœuds non fiables,

rend le processus de migration vers le cloud plus fiable.

Licences et coûts cachés

Les licences Oracle sont un sujet complexe et nécessiteraient un article de blog séparé. Le facteur de cluster le rend encore plus difficile. Le coût augmente car nous devons ajouter des options pour obtenir une licence pour une solution RAC complète. Ici, nous voulons juste souligner à quoi s'attendre et où trouver plus d'informations.

RAC est une fonctionnalité de la licence Oracle Enterprise Edition. La licence Oracle Enterprise est divisée en deux types, par utilisateur nommé et par processeur. Si vous considérez Enterprise Edition avec une licence par cœur, le coût d'un seul cœur est de RAC 23 000 USD + Oracle DB EE 47 500 USD, et vous devez toujours ajouter des frais de support d'environ 22 %. Nous aimerions faire référence à un excellent blog sur les prix trouvé sur https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba a calculé le prix d'un RAC Oracle à quatre nœuds. Le montant total était de 902 400 USD plus 595 584 USD supplémentaires pour trois ans de maintenance de la base de données, et cela n'inclut pas des fonctionnalités telles que le partitionnement ou la base de données en mémoire, le tout avec une remise Oracle de 60 %.

Galera Cluster est une solution open source que tout le monde peut exécuter gratuitement. Des abonnements sont disponibles pour les implémentations de production qui nécessitent l'assistance d'un fournisseur. Un bon calcul du TCO peut être trouvé sur https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Conclusion

Bien qu'il existe des différences significatives dans l'architecture, les deux clusters partagent les grands principes et peuvent atteindre des objectifs similaires. Le produit d'entreprise Oracle est livré avec tout prêt à l'emploi (et son prix). Avec un coût de l'ordre de> 1 million USD, comme indiqué ci-dessus, il s'agit d'une solution haut de gamme que de nombreuses entreprises ne pourraient pas se permettre. Galera Cluster peut être décrit comme une solution de haute disponibilité décente pour les masses. Dans certains cas, Galera pourrait bien être une très bonne alternative à Oracle RAC. Un inconvénient est que vous devez créer votre propre pile, bien que cela puisse être complètement automatisé avec ClusterControl. Nous aimerions connaître votre avis à ce sujet.