У меня есть 2 сервера CentOS linux в отдельных дата-центрах на каждом сайте страны. На этих Linux-машинах работают небольшие веб-сайты на Apache с серверной частью MySQL. В настоящее время между ними нет VPN-подключения, и единственный способ, которым они могут общаться, - это общедоступное IP-пространство.
У меня есть вопрос, как лучше всего сделать их избыточными в случае, если один из них выйдет из строя, другой возьмет на себя управление (отношения главный / подчиненный)? Я хотел бы иметь возможность сделать это с двумя серверами, которые у меня сейчас есть, без добавления третьего. Я предполагаю, что мне нужно будет создать VPN между ними, а затем использовать что-то вроде DRDB для MySQL.
Что бы вы порекомендовали?
MySQL имеет встроенные возможности репликации - нет необходимости в DRBD. Видеть Вот.
Эта репликация происходит по обычному протоколу MySQL, через TCP-порт 3306. Собственный протокол поддерживает шифрование TLS, но VPN тоже может быть неплохой идеей в свете недавние уязвимости. Вам решать!
Оттуда вам просто нужно, чтобы ваше приложение, использующее MySQL, каким-то образом знало об обоих серверах или разработало какой-либо другой механизм аварийного переключения в зависимости от вашего приложения - похоже, у вас есть локальный экземпляр вашего веб-приложения в каждое местоположение, поэтому просто указание каждого на его локальный экземпляр MySQL может помочь.
Однако будьте осторожны - если вы реплицируете в обоих направлениях, вы, скорее всего, не хотите, чтобы на оба сервера MySQL выполнялась запись одновременно; на разных серверах могут быть внесены конфликтующие изменения.
DRDB действительно работает только как отказоустойчивое решение. Как говорит Шейн, репликация MySQL - гораздо более разумный подход. Хотя вы можете реализовать это как ведущий / ведомый, у вас возникнут сложности с продвижением ведомого при обнаружении сбоя. Лучшее решение - использовать репликацию мастер-мастер.
Но есть пределы эффективности этого - реплицируемая запись осуществляется одним потоком, поэтому «ведомый» должен работать больше, чем мастер, чтобы применить их. Неизбежно возникает задержка - хотя обычно она достаточно мала, чтобы не создавать проблем.
Хотя mysql поддерживает шифрование SSL, он не предоставляет большой функциональности для настройки контроля доступа. Настроить шип или stunnel для обертывания определенного порта в SSL - тривиальная задача. Соединения репликации остаются открытыми, поэтому накладные расходы на полосу пропускания очень низкие. Или даже просто ограничьте доступ к порту MySQL удаленным IP-адресом с помощью iptables.
Но вам все еще нужно решить проблему обнаружения сбоев и ограждения отказавшего узла. Предположительно, вы выполняете циклическую балансировку между HTTP-серверами - в этом случае клиенты будут оставаться на одних и тех же серверах в течение всего сеанса. Веб-серверы получат максимальную производительность от локального экземпляра СУБД, поэтому следует пытаться получить доступ к удаленной системе только при обнаружении сбоя в локальной системе. Не беспокойтесь о попытках автоматизировать восстановление - главное, чтобы это было написано по сценарию.
Внимательно прочтите репликацию MySQL - если вы сделаете фундамент, конфликтующие записи должны быть очень, ОЧЕНЬ редкими.
У DRBD есть главный недостаток в том, что связь не будет зашифрована. Так что переходите к mySQL-репликации.
В вашей настройке я бы не стал использовать автоматическую кластеризацию, так как я не вижу безопасного способа избежать ситуаций раздвоения мозга.
Но вы можете запустить вручную скрипт, который
С другой стороны, вы должны предотвратить запуск стартапа, если он снова появится в сети - и вам нужна стратегия отката.