Извините за глупый вопрос, но у меня пока зелёная рука.
У меня есть два Linux-сервера: на одном из них работает Apache с MySQL для обслуживания моей веб-платформы (главный сервер), другой должен быть своего рода репликацией для обеспечения аварийного переключения (подчиненный сервер). Эти машины обслуживаются разными хостерами и DNS-серверами.
Вся информация, которую я нашел в Интернете для реализации этого, основана на общем виртуальном IP-адресе или решениях для серверов, расположенных в одной локальной сети (кластеры, такие как Heartbeat, RedHat; DRBD, протокол CARP и т. Д.). не подходит для меня.
Есть ли какое-либо решение, которое будет отслеживать состояние сервера и в случае отсутствия ответа переключать работу с ведущего на ведомое и после его ремонта переключать его обратно? Я думаю, это должно работать через аварийное переключение DNS. Или мне может помочь только баланс трафика?
Рассмотрим Amazon AWS Route 53 DNS, который имеет такие возможности аварийного переключения. Также работает для серверов, размещенных вне Amazon AWS:
http://gc-taylor.com/blog/2013/04/02/amazon-route53-failover
Да, существуют службы балансировки нагрузки, которые сделают то, о чем вы просите. Поскольку у нас есть собственное оборудование, у нас фактически есть аппаратное решение, использующее балансировщики нагрузки Barracuda. Они отслеживают страницу на нашем веб-сайте (конкретная страница, которая устанавливает соединение с базой данных и отображает UP, если она работает). Если он говорит UP, мы знаем, что и веб-сервер, и база данных работают. Если этого не происходит, мы знаем, что либо веб-сервер, либо база данных не работают, и это вызывает аварийное переключение. Существуют программные балансировщики нагрузки, которые могут добиться того же. Спросите своего хостинг-провайдера, предоставляют ли они какие-либо такие услуги.
Изменить для абзаца выше: Извините, я думаю, я должен уточнить. У Barracuda есть «последнее средство» для аварийного переключения. Итак, у нас есть только 1 сервер, настроенный на 100% -ный трафик, идущий на него для балансировки нагрузки. В случае неудачи он будет использовать IP-адрес «в крайнем случае». Это не типичный вариант использования балансировщика нагрузки, но он отлично подходит для нашей небольшой установки. Мы можем принудительно выполнить переключение на центр обработки данных B, если нам когда-либо понадобится выполнить техническое обслуживание, а затем вернуть его по запросу.
Затем мы используем отработку отказа DNS в качестве вторичного уровня. Он контролирует веб-сайты таким же образом, но мы даем ему задержку в 5 минут или около того, потому что мы обнаружили, что не все интернет-провайдеры соблюдают TTL DNS, поэтому вы в конечном итоге заставите людей переходить на оба сайта одновременно. Поэтому мы стараемся по возможности избегать переключения DNS при отказе.
Говоря о том, что для того, чтобы правильно работать без проблем, вам понадобится какая-то централизованная база данных ИЛИ репликация мастер-мастер. Мы идем вторым, но это рискованный бизнес. В моем списке дел - переделать часть базы данных.
В любом случае, такой настройки достаточно для обеспечения безотказной работы от 99,9% до 99,99%, что приемлемо для большинства малых предприятий.
Что ж, мы обычно пробуем эти решения, когда у нас есть контроль над инфраструктурой, на которой они расположены. Поскольку вы нанимаете хостинговую компанию, они обязаны поддерживать ее работу в соответствии с указанным SLA (Соглашение об уровне обслуживания). Но если вам это действительно нравится, я предлагаю вам по крайней мере нанять одну компанию и либо решение SaaS, либо решение IaaS для достижения этой цели.