Une bonne pratique consiste à établir un plan avant de développer votre application. Commencez par définir les principaux objectifs commerciaux, recueillir les exigences, évaluer une pile technologique potentielle et comprendre les intégrations. À la fin du processus, vous devriez avoir un aperçu de l'architecture de référence de votre application, qui sert de plan directeur pour la mise en œuvre des composants de votre infrastructure et définit comment les données circulent entre ces composants.
Dans cet exemple, nous examinons une conception de base de données utilisant Galera pour MySQL et MariaDB. Les bases de données sont des composants critiques de nombreuses applications. Cet actif précieux repose sur la redondance pour maintenir votre charge de travail en vie. Un seul point de défaillance peut avoir un impact négatif sur les opérations commerciales, les accords de temps de fonctionnement et l'expérience globale de l'utilisateur.
En utilisant les architectures de référence comme guide, vous pouvez créer des bases de données et des déploiements d'applications résilients qui évoluent horizontalement (sans temps d'arrêt) à mesure que votre entreprise se développe.
Qu'est-ce qu'une architecture de référence ?
Les architectures de référence sont des diagrammes techniques réutilisables qui intègrent des principes de conception communs et les meilleures pratiques du secteur pour la mise en œuvre des solutions. Une architecture de référence en nuage hautement abstraite décrit les connexions entre les diverses instances de calcul, les équilibreurs de charge, le stockage, les réseaux définis par logiciel, etc. La valeur de vos bases de données en fait un domaine d'intérêt essentiel.
Bases de données et architecture de référence
L'objectif principal est d'ajouter de la redondance et d'empêcher la base de données d'être un point de défaillance unique. Il existe différentes façons d'atteindre cet objectif en fonction des contraintes liées à l'application et à la charge de travail. Par exemple, une application peut être plus performante en divisant les lectures et les écritures dans un modèle de réplication primaire-secondaire. Un besoin d'échelonner les opérations d'écriture nécessiterait une stratégie avec plusieurs primaires.
Parmi les autres considérations, citons le volume des données, la conformité ACID, le processus de basculement/sélection (manuel ou automatique), le nombre prévu de connexions clients et la technologie de base de données choisie. Ces considérations façonneront la solution de base de données et formeront une image plus large de la façon dont ces éléments s'assemblent dans votre architecture de référence.
Quand utiliser Galera
Galera est une solution de base de données haute disponibilité gratuite et open source, simple à gérer et ne dépendant pas d'un seul fournisseur de cloud. Si votre technologie de base de données est MySQL, ou l'un de ses forks comme MariaDB ou Percona, nous recommandons vivement Galera comme solution durable et portable.
Avantages de la grappe Galera
- Défaillances de nœuds - Empêche les conditions de division des cerveaux en invoquant un quorum pondéré pour élire un composant principal en cas de défaillances de nœuds.
- Cluster multi-primaire, actif-actif - Lecture et écriture sur n'importe quel nœud du cluster.
- Cohérence des données - Utilise une réplication synchrone basée sur la certification pour garantir la conformité ACID.
- Approvisionnement automatique des nœuds - Lorsque les nœuds défaillants se rétablissent ou lorsque de nouveaux nœuds rejoignent le cluster, ils sont automatiquement synchronisés avec l'état du composant principal à l'aide de transferts d'instantanés d'état (SST) ou de transferts d'état incrémentiels (IST).
Limites de la grappe Galera
- Pas de prise en charge de MyISAM - Prise en charge uniquement du moteur InnoDB. Les écritures dans d'autres types de tables, y compris les tables système, ne sont pas répliquées.
- Formatage des tables - Les tables sans clés primaires ne peuvent pas être supprimées ou répliquées correctement.
- Considération logique - La logique de l'application peut devoir être réécrite pour éviter l'utilisation du verrouillage explicite des tables.
- Évolutivité de l'écriture - Tous les nœuds doivent certifier qu'ils peuvent écrire avant de s'engager, par conséquent les performances d'écriture diminuent au fur et à mesure que le cluster s'agrandit. Nous recommandons de maintenir la taille du cluster à trois nœuds, ce qui est suffisant pour avoir le quorum et des performances d'écriture optimales.
Éliminer les points de défaillance uniques
Prenons l'exemple d'une pile LEMP traditionnelle, où le logiciel d'application et la base de données ont été séparés dans différentes instances de calcul en vue d'une future extension. Cette configuration pourrait ressembler à ceci :
La séparation des préoccupations est une bonne pratique et contribue certainement à l'évolutivité, mais l'absence de redondance fait des serveurs de bases de données et d'applications un point de défaillance unique. Nous pouvons améliorer cette structure pour éliminer ces points de défaillance uniques et construire l'architecture de référence globale.
Configuration simple du cluster Galera avec VLAN & Cloud Firewalls
Un cluster Galera augmente la couche de base de données à trois nœuds avec une réplication synchrone entre eux. Nous pouvons utiliser un Linode VLAN pour isoler le trafic de réplication des réseaux publics et privés partagés, et un Cloud Firewall pour restreindre l'accès depuis l'extérieur du site VLAN. Les nœuds Galera partagent une adresse IP flottante de sorte que si l'un d'entre eux tombe en panne, un autre est en mesure de prendre le relais pour servir les requêtes au serveur d'application qui ne le sait pas.
La couche base de données est maintenant hautement disponible. Il faut ensuite se concentrer sur le serveur d'applications. Ce processus est simple pour les systèmes apatrides mais des considérations supplémentaires doivent être prises en compte pour les applications qui sont avec état. Selon la manière dont l'état est maintenu, vous devrez peut-être remanier le code et/ou mettre en œuvre la réplication de fichiers avec des outils comme Unison ou Gluster. Pour cet exemple, supposons qu'à l'exception des fichiers de session temporaires, l'état de l'application est maintenu par la base de données.
Équilibrage des charges et réplication des applications
L'équilibrage de charge confère à votre application une grande disponibilité et une évolutivité horizontale, mais une instance unique d'équilibreur de charge crée également un point de défaillance unique. La redondance reste un élément essentiel de cette mise en œuvre. Linode NodeBalancers offre une solution prête à l'emploi et hautement disponible pour faciliter l'adhérence des sessions, la surveillance de l'état de santé et la distribution des demandes des clients à un ensemble de nœuds d'application dorsaux.
Si un serveur d'application tombe en panne, le NodeBalancer commence à diriger le trafic uniquement vers le nœud sain. Dès que le nœud malade se rétablit, il reprend l'équilibrage des connexions comme avant. Il est ainsi facile d'ajouter, de supprimer ou de mettre à jour des serveurs d'application sans temps d'arrêt, et grâce à la solution active-active fournie par Galera, tout nœud d'application peut lire/écrire sur tout nœud de base de données.
L'équipe d'ingénierie des solutions de Linode partage des cadres, des guides et des outils comme celui-ci pour développer des applications avec les meilleures pratiques à l'esprit. Lisez plus sur les avantages de haute disponibilité fournis par les clusters Galera. Si vous êtes prêt à commencer à construire sur Linode, consultez notre guide sur la mise en place de clusters MariaDB avec Galeria, Debian, et Ubuntu.
Commentaires