Я исследовал решения высокой доступности (HA) для MySQL между центрами обработки данных. Для серверов, расположенных в одной физической среде, я предпочел плавающий VIP, используя активно-пассивный подход. Обработка осуществляется как через последовательное соединение, так и через ethernet.
В конечном итоге моей целью является поддержание такого же уровня доступности, но между центрами обработки данных. Я хочу динамически переходить от одного центра обработки данных к другому без ручного вмешательства и сохранять целостность данных.
На внешнем уровне будет использоваться BGP. Веб-кластеры в обоих местах, которые будут иметь возможность маршрутизации к базам данных между обеими сторонами. Если на сайте 1 пропадет интернет-соединение, клиенты будут направлены через сайт 2 на веб-кластер, а затем в базу данных на сайте 1, если связь между двумя сайтами все еще работает.
В этом сценарии из-за отсутствия физического соединения (последовательного) существует большая вероятность разделения обработки. Если WAN между обоими сайтами не работает, VIP окажется на обоих сайтах, где различные неприятные сценарии могут привести к десинхронизации. Еще одной потенциальной проблемой, которую я вижу, является сложность масштабирования этой инфраструктуры на третий центр обработки данных в будущем.
Сетевой уровень не является основным. На данном этапе архитектура является гибкой. Опять же, мое внимание сосредоточено на решении для поддержания целостности данных, а также на автоматической отказоустойчивости баз данных MySQL. Остальное я, скорее всего, буду проектировать вокруг этого.
Можете ли вы порекомендовать проверенное решение для MySQL HA между двумя физически различными сайтами?
Ответ 1
Вы столкнетесь с проблемой теоремы «CAP». Вы не можете одновременно иметь согласованность, доступность и устойчивость к разделам.
DRBD/MySQL HA полагается на синхронную репликацию на уровне блочных устройств. Это хорошо, пока оба узла доступны или если один из них испытывает временный сбой, перезагружается и т. д., а затем возвращается обратно. Проблемы начинаются, когда возникает сетевой раздел. Сетевые разделы чрезвычайно вероятны, когда вы работаете в двух центрах данных. По сути, ни одна из сторон не может отличить раздел от сбоя другого узла. Вторичный узел не знает, должен ли он взять на себя управление (основной узел вышел из строя) или нет (связь отсутствует). Пока ваши машины находятся в одном месте, вы можете добавить вторичный канал связи (обычно последовательный кабель или кроссовер ethernet), чтобы обойти эту проблему, — таким образом, вторичный узел знает, когда первичный действительно вышел из строя, и это не сетевой раздел.
Следующая проблема — производительность. Хотя DRBD может обеспечить достойную** производительность, когда ваши машины имеют соединение с низкой задержкой (например, гигабитный ethernet, но некоторые используют специальные высокоскоростные сети): чем больше задержка в сети, тем больше времени требуется для фиксации транзакции***. Это связано с тем, что для обеспечения долговечности записей необходимо дождаться подтверждения всех записей на вторичном сервере (когда он работает), прежде чем сказать «OK» приложению.
Если вы делаете это в разных центрах данных, у вас обычно будет еще несколько миллисекунд задержки, даже если они находятся рядом. Вы не можете использовать MyISAM для системы DRBD высокой доступности, потому что он не восстанавливается должным образом/автоматически после некорректного отключения, что требуется во время отказа в обслуживании.
Ответ 2
Первым этапом должно стать обновление вашего текущего решения HA на то, которое использует OpenAIS в качестве уровня членства в кластере: это даст вам большую гибкость, а учитывая низкую латентность каналов связи между сайтами, может оказаться возможным охватить все сайты. PaceMaker и RHEL Clustering поддерживают это.
Для автоматического обхода отказа центра обработки данных вам действительно нужен третий сайт, который будет действовать как разделитель, иначе ваши сайты не смогут отличить проблемы межсайтовой маршрутизации от отказа удаленного сайта. У компании Microsoft есть несколько удивительно хороших веб-кастов, посвященных этой области:
Многосайтовая кластеризация Windows Server 2008
Очевидно, что данная технология не подходит для домена Linux, но концепции одинаковы.
Ответ 3
Дать правильный ответ может быть сложно в зависимости от количества данных, которые у вас есть; количества серверов, на которых вы хотите это разместить, и т. д. Учитывая это, мой ответ может быть не совсем тем, который вы ищете. Не существует проверенного решения для нескольких сайтов с MySQL. Но есть решение, которое работает. Как некоторые отметили, да, DRBD работает хорошо, но имеет свои ограничения или возможные проблемы в зависимости от вашей установки. Понадобится ли вам когда-нибудь третий сайт (другой центр данных)? Если да, то сколько времени и денег у вас уйдет на это?
Учитывая, что каждый раз, когда вы добавляете главный/ведомый/днс сервер, резервное копирование, ... вы добавляете себе сервер для управления. Какова в этом случае ваша способность управления с точки зрения количества серверов? Если вы сможете определить это число, возможно, вам придется отбросить некоторые возможные решения и работать над теми, которые будут соответствовать вашим цифрам, чтобы управление не стало узким местом.
Учитывая, что центры обработки данных не часто выходят из строя, наличие нескольких сайтов означает балансировку нагрузки и некоторые DNS-хаки, будет ли все это находиться в одном центре обработки данных? Если да, то, если один центр данных выйдет из строя по какой-либо причине, вы столкнетесь с проблемой, потому что большая часть DNS и балансировки нагрузки будет находиться в этом центре данных.
Поэтому вам, возможно, придется планировать ситуацию с разделенной обработкой. Почти для каждой возможной установки способ разрешения ситуации с раздвоением обработки отличается. Кроме того, каждое решение занимает X времени.
Также может быть гораздо проще с самого начала планировать использование 3 центров данных. Я не эксперт по MySQL, но я слышал, что в производстве проще иметь 3 центра, чем 2, если вы когда-нибудь столкнетесь с проблемой.
Одна вещь, которая может помочь вам, — это услуга балансировки нагрузки, предлагаемая некоторыми сетевыми поставщиками, такими как Zeus, посмотрите здесь. Возможно, многие другие предлагают подобные услуги. Я уверен, что это стоит недешево, но иногда позволяет сократить расходы на некоторые другие вещи.
Ответ 4
DRBD не является рекомендуемым решением для удаленных центров обработки данных, поскольку требует пропускной способности, что может повлиять на скорость работы базы данных и репликации. Рекомендуемым решением является репликация Master — Master. Единственная проблема заключается в том, что поля автоинкремента должны быть ступенчатыми. Если вам требуется действительно HA-решение для MySQL, вам придется использовать MySQL Cluster, поскольку DRBD не может обеспечить целостность данных в случае сбоев.
Linux
