Question Architecture de MySQL hautement disponible avec basculement automatique dans des emplacements physiquement divers


Je cherchais des solutions de haute disponibilité pour MySQL entre centres de données.

Pour les serveurs situés dans le même environnement physique, j'ai préféré le double maître avec pulsation (VIP flottant) en utilisant une approche passive active. La pulsation se fait par une connexion série et une connexion Ethernet.

En fin de compte, mon objectif est de maintenir ce même niveau de disponibilité, mais entre centres de données. Je souhaite effectuer un basculement dynamique entre les deux centres de données sans intervention manuelle tout en maintenant l'intégrité des données.

Il y aurait BGP sur le dessus. Des clusters Web situés dans les deux sites pourraient potentiellement être acheminés vers les bases de données entre les deux côtés. Si la connexion Internet était interrompue sur le site 1, les clients achemineraient via le site 2 vers le cluster Web, puis vers la base de données du site 1 si le lien entre les deux sites était toujours actif.

Avec ce scénario, en raison du manque de liaison physique (série), le risque de fracture du cerveau est plus probable. Si le réseau étendu disparaissait entre les deux sites, le VIP se retrouverait sur les deux sites, où une variété de scénarios désagréables pourrait introduire la désynchronisation.

Un autre problème potentiel que je vois est la difficulté à faire évoluer cette infrastructure vers un troisième centre de données à l'avenir.

La couche réseau n'est pas un focus. L'architecture est flexible à ce stade. Encore une fois, je me concentre sur une solution visant à préserver l’intégrité des données ainsi que le basculement automatique avec les bases de données MySQL. Je voudrais probablement concevoir le reste autour de cela.

Pouvez-vous recommander une solution éprouvée pour MySQL HA entre deux sites physiquement divers?

Merci de prendre du temps pour lire ceci. J'ai hâte de lire vos recommandations.


19
2018-03-01 23:12


origine


Bonjour - avez-vous déjà déterminé une approche? Il serait intéressant d'entendre ce que vous avez décidé de faire. Nous avons le meme probleme. - Martin
J'apprécie toutes les réponses et le temps de tout le monde. Malheureusement, aucune de ces réponses ne répond vraiment à la racine de la question, à savoir comment les gens ont réussi à résoudre la question dans un environnement de production. Quand j'arriverai à une conclusion ici, je serai certain de partager mes dernières pensées. Jusqu'ici, cela semble être une limite sévère à la capacité d'évolution de MySQL. - Warner
Peut-être que vous n'obtenez pas la solution d'écriture, parce que vous posez la mauvaise question? Quelles données devez-vous répliquer et pourquoi? Lorsque vous commencez à poser ces questions, vous serez alors en mesure de comprendre pourquoi vous avez besoin de la réplication. La scission du cerveau n’est pas simplement un problème mysql, c’est un concept de cluster. - The Unix Janitor
Une réponse que j'ai fournie ici inclut des informations supplémentaires: serverfault.com/questions/142683/…  Je fournirai également un suivi lorsque la mise en œuvre finale de la production sera en place. - Warner


Réponses:


Vous allez faire face au problème du théorème "CAP". Vous ne pouvez pas avoir à la fois cohérence, disponibilité et tolérance de partition.

DRBD / MySQL HA repose sur une réplication synchrone au niveau du périphérique en mode bloc. Ceci est correct tant que les deux nœuds sont disponibles, ou si l'un d'entre eux subit une défaillance temporaire, est redémarré, etc., puis revient. Les problèmes commencent lorsque vous obtenez une partition réseau.

Les partitions réseau sont extrêmement susceptibles lorsque vous utilisez deux centres de données. Essentiellement, aucune des parties ne peut distinguer une partition de l'autre nœud défaillant. Le noeud secondaire ne sait pas s'il doit prendre le relais (le primaire a échoué) ou non (le lien a disparu).

Alors que vos machines sont au même endroit, vous pouvez ajouter un canal de communication secondaire (généralement un câble série ou Ethernet croisé) pour contourner ce problème - ainsi le secondaire sait quand le primaire est EN GÉNÉRALEMENT hors service, et ce n'est pas une partition réseau. .


Le problème suivant est la performance. Bien que DRBD puisse offrir des performances décentes ** lorsque vos machines disposent d’une connexion à faible temps de latence (par exemple, une connexion Ethernet gigabit - mais certaines personnes utilisent des réseaux haut débit dédiés), plus le réseau a de latence, plus la validation d'une transaction est longue *** . En effet, il doit attendre que le serveur secondaire (lorsqu'il est en ligne) reconnaisse toutes les écritures avant de dire "OK" à l'application pour garantir la durabilité des écritures.

Si vous effectuez cette opération dans différents centres de données, vous disposez généralement de plusieurs latences en millisecondes, même si elles sont proches.

** Toujours beaucoup plus lent qu'un contrôleur IO local décent

*** Vous ne pouvez pas utiliser MyISAM pour un système DRBD à haute disponibilité, car il ne récupère pas correctement / automatiquement à partir d'un arrêt impropre, requis lors d'un basculement.


9
2018-03-03 21:56



J'apprécie votre temps et vos pensées. Vous avez décrit certains des problèmes que j'essaie d'éviter très bien. Idéalement, j'aimerais conserver les avantages du double maître actif / passif pour la maintenance et le basculement rapide tout en minimisant le risque de corruption des données. Je pense que quelqu'un a trouvé une solution acceptable. - Warner
Effectivement. Les données ne veulent pas être deux endroits à la fois. - Matt Simmons


Pourquoi ne pas utiliser un VLAN pour relier tous les serveurs des deux (ou plus) centres de données? Vous pouvez ensuite utiliser CARP pour le basculement automatique. Utilisez la réplication de base de données pour tout synchroniser.

Si vous possédez les centres de données, vous pouvez vous assurer que chaque centre de données dispose de plusieurs liaisons montantes WAN.


3
2018-03-02 01:37



C'était ma première pensée. Introduire la couche 2 à un tel degré nécessiterait une approche descendante entre les deux sites. Les autres rôles de serveur utilisant la redondance avec LinuxHA devront avoir des implémentations similaires, telles que les pare-feu. Sinon, il y aurait des problèmes de routage. En fin de compte, même avec plusieurs liaisons montantes de réseau étendu (WAN) entre les deux sites, mon niveau de confort est bien inférieur à celui des liaisons montantes série et Ethernet. C'est plus de risque que je peux tolérer. De plus, il semble qu'il devrait y avoir une solution plus idéale. - Warner


La première étape consiste à mettre à niveau votre solution haute disponibilité actuelle vers une solution utilisant OpenAIS en tant que couche d'appartenance à un cluster: vous bénéficierez ainsi d'une grande flexibilité. Grâce à des liens à faible temps de latence entre sites, vous pourrez peut-être atteindre votre réseau. PaceMaker et RHEL Clustering le supportent.

Pour le basculement automatique de centre de données, vous avez vraiment besoin d'un troisième site qui joue le rôle de déclencheur, sinon vos sites ne seront pas en mesure de faire la distinction entre les problèmes de routage entre sites et les défaillances de sites distants. Microsoft propose d'étonnants web-cast sur le domaine:

Mise en cluster multi-sites Windows Server 2008

Évidemment, la technologie exacte ne correspond pas au domaine Linux, mais les concepts sont les mêmes.


3
2018-03-02 13:37





Désolé, ceci est un autre réseau à part, mais une pensée pour plus tard ...

Pour le scénario de partage du cerveau que vous avez mentionné, vous pourriez également avoir des liens redondants vers deux sites afin de réduire les risques que cela se produise.


1
2018-03-11 01:50



Je suis allé et retour à ce sujet. D'abord, je l'ai entièrement qualifié de trop risqué. Maintenant, je reconsidère. De manière réaliste, le risque de corruption de données avec même deux chemins totalement diversifiés est assez élevé. C'est sur ma courte liste en ce moment. - Warner


Notez que vous ne pouvez probablement pas utiliser BGP, car le plus petit bloc routable est 4k, a / 22, bonne chance pour en obtenir un. Une solution basée sur le DNS est probablement nécessaire.


0
2018-03-02 01:15



+1 pour une dose de réalité. Vous pouvez utiliser un service DNS bien géré tel qu'UltraDNS et son service de surveillance de site «SiteBacker» pour vous y rendre le plus souvent possible. - Martin
Nous avons déjà BGP en place. Cela sort du cadre de ma question. - Warner
Non, le plus petit bloc routable est / 24. En fait, non. Le plus petit bloc physiquement routable est / 28, mais vous risquez d'être ignoré par tout le monde. Le plus petit préfixe qui sera écouté est / 24. - Tom O'Connor


Donner une réponse correcte peut s'avérer difficile en fonction de la quantité de données dont vous disposez, du nombre de serveurs sur lesquels vous souhaitez l'intégrer, etc. Cela étant dit, ma réponse pourrait ne pas être celle du moins que vous recherchez.

Il n’existe pas de solution éprouvée pour plusieurs sites avec MySQL. Mais il y a une solution qui fonctionne. Comme certains l'ont fait remarquer, la DRDD fonctionne bien, mais son problème est limité ou possible en fonction de votre configuration.

Aurez-vous besoin d'un troisième site (un autre centre de données)? Si oui, combien de temps et d'argent devrez-vous faire?

Chaque fois que vous ajoutez un serveur maître / esclave / DNS, des sauvegardes, vous ajoutez vous-même un serveur à gérer, quelle est votre capacité de gestion en termes de nombre de serveurs? Si vous pouvez définir ce nombre, vous devrez peut-être jeter quelques solutions possibles et rechercher celles qui conviendront à vos chiffres afin que la gestion ne devienne pas un goulot d'étranglement.

Considérant que les centres de données ne tombent pas souvent en panne, l'équilibrage de charge et le piratage DNS sur plusieurs sites signifient, est-ce que cela se fera dans le même centre de données? Si tel est le cas, si un centre de données tombe en panne pour une raison quelconque, vous rencontrerez un problème, car une bonne partie de votre DNS et de l’équilibrage de charge se trouveront dans ce centre de données.

Donc, vous devrez peut-être planifier cette situation de fractionnement du cerveau. Pour chaque configuration possible, la manière de résoudre une situation de cerveau craché est différente. En outre, chaque solution prend X quantité de temps.
Il peut également être beaucoup plus facile de planifier l’utilisation de 3 centres de données dès le début. Je ne suis pas un expert de MySQL, mais j'ai entendu dire qu'en production, il était plus facile d'avoir 3 Masters que 2 si vous rencontriez un problème.

Une chose qui peut vous aider est le service d’équilibrage de charge proposé par un fournisseur de réseau tel que Zeus. ici Il y en a probablement beaucoup plus qui offrent ce genre de service. Je suis sûr que cela a un prix, mais vous permet parfois de réduire certaines autres choses.

Bonne chance!


0
2018-03-13 19:55



Les données sont relativement petites, toutes choses considérées. Quelques centaines de giga-octets pour des raisons de discussion. Troisième site, probablement. Si nécessaire, je suis prêt à compromettre l'architecture pour une meilleure solution maintenant et à revenir plus tard pour une troisième. Les "goulets d'étranglement de la gestion" ou d'autres problèmes administratifs ne relèvent pas de la portée de la question. La redondance sera en place pour toutes les technologies de production. L'accent est mis ici sur MySQL. - Warner


DRBD n'est pas une solution recommandée pour les centres de données distants, car il nécessite une bande passante susceptible d'affecter la vitesse de votre base de données et de la réplication. La solution recommandée est Master - Master Replication. Le seul problème avec cela est que vos champs d'incrémentation automatique doivent être échelonnés.

Si vous avez besoin d’une solution véritablement haute disponibilité pour MySQL, vous devrez utiliser MySQL Cluster, car DRBD ne peut pas vous garantir l’intégrité des données en cas de défaillance.


0
2017-07-16 17:54