Архитектура для высокодоступного MySQL с автоматическим переключением при сбое в физически разных местах

Я исследовал решения высокой доступности (HA) для MySQL между центрами обработки данных.

Для серверов, расположенных в одной и той же физической среде, я предпочел двойной мастер с биением сердца (плавающий VIP) с использованием активного пассивного подхода. Сердцебиение происходит как через последовательное соединение, так и через соединение Ethernet.

В конечном счете, моя цель - поддерживать тот же уровень доступности, но между центрами обработки данных. Я хочу динамически переключаться между двумя центрами обработки данных без ручного вмешательства и при этом сохранять целостность данных.

Там будет BGP на вершине. Веб-кластеры в обоих местах, которые могли бы направлять в базы данных между обеими сторонами. Если подключение к Интернету было прервано на сайте 1, клиенты перенаправили бы через сайт 2 в веб-кластер, а затем в базу данных на сайте 1, если связь между обоими сайтами все еще работает.

При таком сценарии из-за отсутствия физического соединения (серийного) существует более высокая вероятность расщепления мозга. Если бы WAN выходил из строя между обоими сайтами, VIP оказался бы на обоих сайтах, где множество неприятных сценариев могло бы привести к рассинхронизации.

Другая потенциальная проблема, которую я вижу, - это трудности с масштабированием этой инфраструктуры до третьего центра обработки данных в будущем.

Сетевой уровень не является фокусом. Архитектура является гибкой на данном этапе. Опять же, мое внимание сосредоточено на решении для поддержания целостности данных, а также автоматического переключения при сбое с базами данных MySQL. Я бы, вероятно, разработал остальное вокруг этого.

Можете ли вы порекомендовать проверенное решение для MySQL HA между двумя физически разнородными сайтами?

Спасибо, что нашли время, чтобы прочитать это. Я с нетерпением жду чтения ваших рекомендаций.

Вы столкнетесь с проблемой теоремы «CAP». Вы не можете иметь согласованность, доступность и допуск на разделы одновременно.

DRBD / MySQL HA опирается на синхронную репликацию на уровне блочных устройств. Это нормально, когда оба узла доступны, или если один из них имеет временную ошибку, перезагружается и т. Д., А затем возвращается. Проблемы начинаются, когда вы получаете сетевой раздел.

Сетевые разделы чрезвычайно вероятны, когда вы работаете в двух центрах обработки данных. По сути, ни одна из сторон не может отличить раздел от отказавшего другого узла. Вторичный узел не знает, должен ли он вступить во владение (первичный отказал) или нет (связь пропала).

Пока ваши машины находятся в одном и том же месте, вы можете добавить вторичный канал связи (обычно последовательный кабель или перекрестный Ethernet), чтобы обойти эту проблему - так что вторичный сервер знает, когда первичный выключен, а это не сетевой раздел ,

Следующая проблема - производительность. Хотя DRBD может дать приличную ** производительность, когда ваши машины имеют соединение с малой задержкой (например, гигабитный Ethernet - но некоторые люди используют выделенные высокоскоростные сети), чем больше задержка в сети, тем больше времени требуется для совершения транзакции *** , Это потому, что ему нужно подождать, пока вторичный сервер (когда он в сети) подтвердит все записи, прежде чем сказать «ОК» приложению, чтобы обеспечить долговечность записей.

Если вы делаете это в разных центрах обработки данных, у вас обычно есть задержка на несколько миллисекунд, даже если они находятся рядом.

** Все еще намного медленнее, чем приличный локальный контроллер ввода-вывода

*** Вы не можете использовать MyISAM для системы DRBD высокой доступности, потому что она не восстанавливается должным образом / автоматически после нечистого выключения, которое требуется во время восстановления после сбоя.

Как насчет использования VLAN, чтобы связать все серверы в двух (или более) центрах обработки данных вместе. Затем вы можете использовать CARP для автоматического перехода на другой ресурс. Используйте репликацию базы данных, чтобы синхронизировать все.

Если вы являетесь владельцем центра обработки данных, вы можете убедиться, что каждый центр обработки данных имеет несколько восходящих каналов глобальной сети.

Первым этапом должно быть обновление вашего текущего решения высокой доступности до того, которое использует OpenAIS в качестве уровня членства в кластере: это даст вам большую гибкость, и, учитывая низкую задержку соединений между сайтами, возможно, удастся достичь через них. PaceMaker и RHEL Clustering поддерживают это.

Для автоматического восстановления после сбоя центра обработки данных вам действительно нужен третий сайт, который будет действовать как средство разрыва связей, в противном случае ваши сайты не смогут различить проблемы маршрутизации между сайтами и сбой удаленного сайта. У Microsoft есть несколько удивительно хороших веб-роликов, охватывающих эту область:

Многосайтовая кластеризация Windows Server 2008

Очевидно, что точная технология не отображается на домен Linux, но концепции те же.

Извините, это еще одна сеть в стороне, но мысль о будущем

В упомянутом выше сценарии с разделенным мозгом у вас могут быть избыточные связи между двумя сайтами, чтобы уменьшить вероятность этого.

Обратите внимание, что вы, вероятно, не можете использовать BGP, так как наименьший маршрутизируемый блок 4k, a / 22, удачи вам. Вероятно, необходимо решение на основе DNS.

Правильный ответ может быть затруднен в зависимости от количества данных, которые у вас есть, количества серверов, на которые вы хотите вписаться, и т. Д. При этом мой ответ может быть не один или, по крайней мере, тот, который вы ищете.

Не существует проверенного решения для нескольких сайтов с MySQL. Но есть решение, которое работает. Как отмечали некоторые, да, DRDB работает нормально, но имеет свои ограничения или возможные проблемы в зависимости от ваших настроек.

Вам когда-нибудь понадобится третий сайт (еще один центр обработки данных)? Если да, сколько времени и денег у вас будет на это?

Учитывая каждый раз, когда вы добавляете главный / подчиненный / DNS-сервер, резервные копии, ... вы сами добавляете сервер для управления, каковы ваши возможности управления с точки зрения количества серверов? Если вы можете определить это число, вам, возможно, придется отбросить некоторые возможные решения и работать над теми, которые будут соответствовать вашим номерам, чтобы управление не стало узким местом.

Учитывая, что центры обработки данных не выходят из строя часто, несколько сайтов означают балансировку нагрузки и некоторый взлом DNS, будет ли это в одном центре данных? Если так, то если по какой-либо причине один из центров обработки данных выйдет из строя, у вас возникнут проблемы, поскольку значительная часть вашего DNS и балансировка нагрузки будут находиться в этом центре данных.

Так что вам, возможно, придется спланировать ситуацию с раздвоением мозга. Для каждой возможной установки almsot способ разрешения проблемы слюны различен. Кроме того, каждое решение занимает X времени.
Также может быть намного проще спланировать использование 3 центра обработки данных с самого начала. Я не эксперт по MySQL, но я слышал, что на производстве было легче иметь 3 мастера, чем 2, если у вас возникнут проблемы.

Одна вещь, которая может вам помочь, - это сервис балансировки нагрузки, предлагаемый некоторыми сетевыми поставщиками, такими как Zeus, посмотрите здесь. Вероятно, многие другие предлагают этот вид услуг. Я уверен, что это идет по цене, но иногда позволяет сократить некоторые другие вещи.

Удачи!

DRBD не рекомендуется для удаленных центров обработки данных, так как для него требуется пропускная способность, которая может повлиять на скорость вашей базы данных и репликацию. Рекомендуемое решение - Мастер - Мастер Репликация. Единственная проблема заключается в том, что вы автоматически увеличиваете поля.

Если вам требуется действительно HA-решение для MySQL, вам придется использовать MySQL Cluster, поскольку DRBD не может обеспечить целостность данных в случае сбоев.

Я нашел сообщения в блоге об опциях, доступных в MySQL, и о его плюсах и минусах. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Преодолеть недостаток последовательного кабеля на самом деле очень просто, вы используете вещь из темных веков, называемую модемом - у вас есть один на каждом конце, а затем запускаете Heartbeat по каналу PPP. Вы также можете использовать Frame Relay. Оба метода устранят любые ваши проблемы с избыточными путями уровня 1/2.

Однако, как говорится - DRBD, работающий по любой линии связи с задержкой более 300 мкс (обратите внимание, что 0,3 мс), очень быстро становится нелепым.

Вы бы лучше обслужили, используя стандартную репликацию MySQL, и LinuxHA поверх PPP & eth, чтобы выполнить обход отказа.

По крайней мере, это то, что я сделал для клиентов в прошлом.