Architecture pour MySQL hautement disponible avec basculement automatique dans des emplacements physiquement diversifiés


19

J'ai recherché des solutions de haute disponibilité (HA) pour MySQL entre les 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. Le battement de cœur est à la fois sur une connexion série ainsi qu'une connexion Ethernet.

Au final, mon objectif est de maintenir ce même niveau de disponibilité mais entre les datacenters. Je souhaite basculer dynamiquement entre les deux centres de données sans intervention manuelle et conserver l'intégrité des données.

Il y aurait BGP sur le dessus. Clusters Web dans les deux emplacements, qui pourraient être acheminés vers les bases de données entre les deux côtés. Si la connexion Internet tombe en panne sur le site 1, les clients acheminent 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 est toujours actif.

Avec ce scénario, en raison de l'absence de lien physique (série), il y a plus de chance de diviser le cerveau. Si le WAN descendait entre les deux sites, le VIP finirait 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é de 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, mon objectif est une solution pour maintenir l'intégrité des données ainsi que le basculement automatique avec les bases de données MySQL. Je concevoirais probablement le reste autour de ceci.

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

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


1
Salut - 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 chacun. 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'à présent, cela semble être une grave limitation de la capacité de MySQL à évoluer.
Warner

Peut-être que vous n'obtenez pas la solution d'écriture, parce que vous posez la mauvaise question? De quelles données avez-vous besoin pour répliquer et pourquoi? Lorsque vous commencez à poser ces questions, vous serez en mesure de découvrir pourquoi vous aviez besoin d'une réplication en premier lieu. Le cerveau partagé n'est pas seulement un problème mysql, c'est un concept de cluster.
The Unix Janitor

Une réponse que j'ai fournie ici comprend quelques informations supplémentaires: serverfault.com/questions/142683/… Je fournirai également un suivi lorsque la mise en œuvre de la production finale sera en place.
Warner

Réponses:


9

Vous serez confronté au problème du théorème "CAP". Vous ne pouvez pas avoir simultanément la cohérence, la disponibilité et la tolérance de partition.

DRBD / MySQL HA repose sur la réplication synchrone au niveau du périphérique de bloc. C'est bien alors que les deux nœuds sont disponibles, ou si l'un souffre d'une panne 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 probables lorsque vous exécutez dans deux centres de données. Essentiellement, aucune des parties ne peut distinguer une partition de l'autre nœud défaillant. Le nœud secondaire ne sait pas s'il doit prendre le relais (le principal a échoué) ou non (le lien a disparu).

Pendant que vos machines se trouvent au même emplacement, vous pouvez ajouter un canal de communication secondaire (généralement un câble série ou Ethernet croisé) pour contourner ce problème - afin que le secondaire sache quand le principal est VRAIMENT en panne, et ce n'est pas une partition réseau .


Le prochain problème est la performance. Bien que DRBD puisse donner des performances décentes ** lorsque vos machines ont une connexion à faible latence (par exemple, Gigabit Ethernet - mais certaines personnes utilisent des réseaux dédiés à haute vitesse), plus le réseau a de latence, plus il faut de temps pour valider une transaction *** . 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 d'une latence de plusieurs millisecondes de plus, même s'ils sont à proximité.

** Toujours beaucoup plus lent qu'un contrôleur d'E / S local correct

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


J'apprécie votre temps et vos pensées. Vous avez très bien décrit certains des problèmes que j'essaie d'éviter. 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

1
En effet. Les données ne veulent pas être à deux endroits à la fois.
Matt Simmons

3

Qu'en est-il de l'utilisation d'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 êtes propriétaire des centres de données, vous pouvez vous assurer que chaque centre de données dispose de plusieurs liaisons montantes WAN.


C'était ma première pensée. Introduire la couche 2 à un tel degré nécessiterait une approche descendante entre les deux sites. D'autres rôles de serveur qui ont une redondance à l'aide de LinuxHA devraient 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 WAN entre les deux sites, mon niveau de confort est nettement inférieur à celui des liaisons montantes série et Ethernet. C'est plus de risques que je ne peux tolérer. De plus, il semble qu'il devrait y avoir une solution plus idéale.
Warner

3

Votre première étape devrait être de mettre à niveau votre solution HA actuelle vers une solution qui utilise OpenAIS comme couche d'appartenance au cluster: cela vous donnera beaucoup de flexibilité et, étant donné les liens à faible latence entre les sites, pourrait être en mesure d'atteindre. PaceMaker et RHEL Clustering prennent cela en charge.

Pour le basculement automatique du centre de données, vous avez vraiment besoin d'un troisième site pour agir en tant que bris d'égalité, sinon vos sites ne seront pas en mesure de faire la distinction entre les problèmes de routage inter-sites et les défaillances de sites distants. Microsoft a quelques web-castings étonnamment bons couvrant la région:

Mise en cluster multisite de Windows Server 2008

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


1

Désolé, c'est encore un autre réseau de côté, mais une pensée pour l'avenir ...

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


J'ai fait des allers-retours à ce sujet. Tout d'abord, je l'ai entièrement considéré comme trop risqué. Maintenant, je reconsidère. De manière réaliste, le risque de corruption de données, même avec deux voies entièrement diversifiées, est assez élevé. C'est sur ma liste restreinte en ce moment.
Warner

0

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 DNS est probablement nécessaire.


+1 pour une dose de réalité. Vous pouvez utiliser un service DNS bien géré comme UltraDNS et son service de surveillance de site "SiteBacker" pour vous y aider la plupart du temps.
Martin

1
Nous avons déjà BGP en place. Cela sort du cadre de ma question.
Warner

2
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

0

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

Il n'y a pas de solution éprouvée pour plusieurs sites avec MySQL. Mais il existe une solution qui fonctionne. Comme certains l'ont souligné, oui, DRDB fonctionne bien mais a sa limite ou son problème possible en fonction de votre configuration.

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

Considérant que chaque fois que vous ajoutez un serveur maître / esclave / DNS, des sauvegardes, ... vous vous ajoutez 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 des solutions possibles et travailler vers celles qui correspondront à vos chiffres afin que la gestion ne devienne pas un goulot d'étranglement.

Étant donné que les centres de données ne tombent pas souvent en panne, plusieurs sites signifient l'équilibrage de la charge et certains piratages DNS, est-ce que cela va être dans le même centre de données? Si c'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 trouvera dans ce centre de données.

Vous devrez donc peut-être planifier cette situation de division du cerveau. Pour l'aumône chaque configuration possible, la façon de résoudre une situation de cracher du cerveau est différente. De plus, chaque solution prend X durée.
Il peut également être beaucoup plus facile de planifier l'utilisation de 3 datacenter dès le départ. Je ne suis pas un expert MySQL mais j'ai entendu dire qu'en production, il était plus facile d'avoir 3 maîtres que 2 si jamais vous rencontriez un problème.

Une chose qui peut vous aider est le service d'équilibrage de charge proposé par certains fournisseurs de réseaux comme Zeus, jetez un œil ici Il y en a probablement beaucoup plus qui offrent ce type de service. Je suis sûr que cela a un prix mais vous permet parfois de réduire d'autres choses.

Bonne chance!


Les données sont relativement petites, tout bien considéré. Quelques centaines de gigaoctets pour la discussion. Troisième site, probablement. Si nécessaire, je suis prêt à compromettre l'architecture pour une meilleure solution maintenant et à y revenir plus tard pour un troisième. Le «goulot d'étranglement de la gestion» ou d'autres problèmes administratifs n'entrent pas dans le champ de la question. La redondance sera en place pour toutes les technologies de production. Le focus ici est MySQL.
Warner

0

DRBD n'est pas une solution recommandée pour les centres de données distants, car il nécessite une bande passante qui peut 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 vraiment HA pour MySQL, vous devrez opter pour MySQL Cluster car DRBD ne peut pas vous donner l'intégrité des données en cas de pannes.



0

Surmonter le manque d'un câble série est en fait très facile, vous utilisez une chose des âges sombres appelée un modem - vous en avez un à chaque extrémité, puis exécutez Heartbeat sur le lien PPP. Vous pouvez également utiliser le relais de trame. Les deux méthodes permettront de résoudre tous les problèmes que vous avez avec les chemins redondants de la couche 1/2.

Cependant, cela étant dit - DRBD fonctionnant sur n'importe quel lien avec beaucoup plus d'environ 300 µs (notez que c'est 0,3 ms) la latence devient ridicule très rapidement.

Vous seriez mieux servi en utilisant la réplication MySQL standard, et LinuxHA sur PPP & eth pour effectuer les basculements.

C'est du moins ce que j'ai fait pour les clients dans le passé.


Idée intéressante. J'ai déjà utilisé l'accès à distance comme basculement sur un PtP. Bien que je ne pense pas que cela éliminerait complètement le problème du théorème de la PAC, je pense que cela pourrait être supplémentaire pour rendre la fracture cérébrale moins susceptible de se produire. Difficile de créer le même niveau de confiance que celui créé par une connexion physique directe de plusieurs pieds.
Warner
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.