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

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.

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.

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.

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.

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.

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.

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!

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.

J'ai trouvé des articles de blog sur les options disponibles dans MySQL et ses avantages et inconvénients. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

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é.