Я исследовал решения высокой доступности (HA) для MySQL между центрами обработки данных.
Для серверов, расположенных в одной и той же физической среде, я предпочитаю двойной мастер с тактовым сигналом (плавающий VIP) с использованием активного пассивного подхода. Контрольное сообщение происходит как через последовательное соединение, так и через соединение Ethernet.
В конечном итоге моя цель - поддерживать тот же уровень доступности, но между центрами обработки данных. Я хочу динамически переключаться между обоими центрами обработки данных без ручного вмешательства и при этом поддерживать целостность данных.
Был бы BGP сверху. Веб-кластеры в обоих местах, которые могут иметь возможность маршрутизации к базам данных между обеими сторонами. Если подключение к Интернету на сайте 1 прервется, клиенты будут маршрутизировать сайт 2 в веб-кластер, а затем в базу данных на сайте 1, если связь между обоими сайтами все еще работает.
В этом сценарии из-за отсутствия физического канала связи (последовательного) повышается вероятность расщепления мозга. Если глобальная сеть прервется между обоими сайтами, VIP окажется на обоих сайтах, где различные неприятные сценарии могут вызвать рассинхронизацию.
Еще одна потенциальная проблема, которую я вижу, - это трудности с масштабированием этой инфраструктуры до третьего центра обработки данных в будущем.
Сетевой уровень не является фокусом. На этом этапе архитектура гибкая. Опять же, мое внимание сосредоточено на решении для поддержания целостности данных, а также на автоматическом переключении при отказе с базами данных MySQL. Я бы, вероятно, спроектировал остальное вокруг этого.
Можете ли вы порекомендовать проверенное решение для MySQL HA между двумя физически разными сайтами?
Спасибо, что нашли время, чтобы прочитать это. Жду ваших рекомендаций.
Вы столкнетесь с проблемой теоремы "CAP". У вас не может быть согласованности, доступности и устойчивости к разделам одновременно.
DRBD / MySQL HA полагается на синхронную репликацию на уровне блочного устройства. Это нормально, пока доступны оба узла, или если у одного из них возникла временная ошибка, он перезагружается и т. Д., Он возвращается. Проблемы начинаются, когда вы получаете сетевой раздел.
Если вы работаете в двух центрах обработки данных, вероятность возникновения сетевых разделов очень высока. По сути, ни одна из сторон не может отличить раздел от сбоя другого узла. Вторичный узел не знает, должен ли он взять на себя управление (первичный отказал) или нет (ссылка пропала).
Пока ваши машины находятся в одном месте, вы можете добавить вторичный канал связи (обычно последовательный кабель или перекрестный Ethernet), чтобы обойти эту проблему - чтобы вторичный знал, когда первичный ОБЯЗАТЕЛЬНО не работает, и это не сетевой раздел .
Следующая проблема - производительность. Хотя DRBD может обеспечить достойную ** производительность, когда ваши машины имеют соединение с низкой задержкой (например, гигабитный Ethernet - но некоторые люди используют выделенные высокоскоростные сети), чем больше задержка в сети, тем больше времени требуется для фиксации транзакции *** . Это связано с тем, что ему необходимо дождаться, пока вторичный сервер (когда он находится в сети) подтвердит все записи, прежде чем сказать «ОК» приложению, чтобы гарантировать надежность операций записи.
Если вы делаете это в разных центрах обработки данных, у вас обычно возникает задержка на несколько миллисекунд, даже если они находятся поблизости.
** Все еще намного медленнее, чем приличный локальный контроллер ввода-вывода
*** Вы не можете использовать MyISAM для системы DRBD высокой доступности, потому что она не восстанавливается должным образом / автоматически после некорректного завершения работы, которое требуется во время аварийного переключения.
Ваш первый этап должен заключаться в обновлении вашего текущего решения высокой доступности до того, которое использует OpenAIS в качестве уровня членства в кластере: это даст вам большую гибкость и, учитывая низкую задержку ссылок между сайтами, может быть в состоянии охватить. Это поддерживают PaceMaker и RHEL Clustering.
Для автоматического переключения центра обработки данных при отказе вам действительно нужен третий сайт, который будет выполнять функцию разрешения конфликтов, иначе ваши сайты не смогут отличить проблемы межсайтовой маршрутизации от сбоя удаленного сайта. У Microsoft есть несколько удивительно хороших веб-трансляций, охватывающих эту область:
Многосайтовая кластеризация Windows Server 2008
Очевидно, что точная технология не соответствует домену Linux, но концепции те же.
Как насчет использования VLAN для связывания всех серверов в двух (или более) центрах обработки данных вместе? Затем вы можете использовать CARP для автоматического переключения при отказе. Используйте репликацию базы данных, чтобы все синхронизировать.
Если вы владеете центрами обработки данных, вы можете гарантировать, что каждый центр обработки данных имеет несколько восходящих каналов WAN.
Извините, это еще одна сеть в стороне, но мысль о будущем ...
Для упомянутого вами сценария разделения мозга у вас могут быть избыточные ссылки между двумя сайтами, чтобы снизить вероятность этого.
Обратите внимание, что вы, вероятно, не можете использовать BGP, так как наименьший маршрутизируемый блок - 4k, a / 22, удачи в получении. Возможно, необходимо решение на основе DNS.
Дать правильный ответ может быть сложно в зависимости от объема данных, которые у вас есть, количества серверов, на которых вы хотите разместить это, и т. Д. При этом мой ответ может быть не таким или, по крайней мере, тем, который вы ищете.
Не существует проверенного решения для нескольких сайтов с MySQL. Но есть решение, которое работает. Как отмечали некоторые, да, DRDB работает нормально, но имеет свой предел или возможную проблему в зависимости от вашей настройки.
Вам когда-нибудь понадобится третий сайт (еще один центр обработки данных)? Если да, то сколько времени и денег у вас на это уйдет?
Учитывая каждый раз, когда вы добавляете главный / подчиненный / DNS-сервер, резервные копии, ... вы добавляете себе сервер для управления, каковы ваши возможности управления с точки зрения количества серверов? Если вы можете определить это число, вам, возможно, придется отказаться от некоторых возможных решений и работать над теми, которые будут соответствовать вашим цифрам, чтобы руководство не стало узким местом.
Учитывая, что центры обработки данных не часто выходят из строя, несколько сайтов означают балансировку нагрузки и некоторый взлом DNS, будет ли это в одном центре обработки данных? Если это так, то, если один из центров обработки данных выйдет из строя по какой-либо причине, вы столкнетесь с проблемой, потому что значительная часть вашего DNS и балансировки нагрузки будет находиться в этом центре обработки данных.
Так что вам, возможно, придется спланировать ситуацию с расщеплением мозга. Для всех возможных вариантов решения проблемы с мозговым взмахом различаются. Кроме того, каждое решение занимает X времени.
Также может быть намного проще спланировать использование трех центров обработки данных с самого начала. Я не эксперт по MySQL, но слышал, что на производстве было легче иметь 3 Мастера, чем 2, если вы когда-нибудь столкнетесь с проблемой.
Одна вещь, которая может вам помочь, - это услуга балансировки нагрузки, предлагаемая каким-то сетевым поставщиком, таким как Zeus, посмотрите Вот Вероятно, гораздо больше людей предлагают такого рода услуги. Я уверен, что это имеет свою цену, но иногда позволяет сократить некоторые другие вещи.
Удачи!
DRBD не рекомендуется для удаленных центров обработки данных, поскольку для него требуется пропускная способность, которая может повлиять на скорость вашей базы данных и репликации. Рекомендуемое решение - Master - Master Replication. Единственная проблема заключается в том, что поля автоматического увеличения должны быть расположены в шахматном порядке.
Если вам требуется действительно 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 для отработки отказа.
По крайней мере, это то, что я делал для клиентов в прошлом.