Назад | Перейти на главную страницу

Предложите идеальный механизм аварийного переключения для автономного сервера Linux.

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

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

Любое предложение будет принято с благодарностью. Спасибо!

Вы можете зарегистрироваться в Round Robin DNS. с некоторыми оговорками

Циклический DNS - это метод применения нескольких IP-адресов (запись DNS PTR) к одному имени хоста (запись A DNS). DNS будет чередовать записи PTR всякий раз, когда запрашивается запись A. Это не решение высокой доступности, но если один IP-адрес не работает, пользователь может повторно загрузить свой веб-браузер, и будет выдан другой PTR. Одна вещь, которая делает его привлекательным, заключается в том, что это 5-минутная конфигурация в DNS, чтобы добавить несколько IP-адресов, а затем просто клонировать все виртуальные машины, которые вы хотите включить в пул (ПРИМЕЧАНИЕ: каждой виртуальной машине, конечно же, нужен собственный уникальный IP-адрес) .

Предостережения, с которыми я сталкивался раньше:

  • Если приложение выдает перенаправление на свое имя хоста, имейте в виду, что это приводит к выдаче нового IP-адреса пользователю. Иногда «неработающий» IP выдается. Это может быть проблемой с самого начала при перенаправлении HTTP> HTTPS.
  • Необходимо учитывать сертификаты SSL.
  • Состояние сеанса приложения не определено

Лично я отказался от RRDS для веб-приложений много лет назад (отлично работает для таких вещей, как LDAP), но могут появиться новые интересные вещи, которые были разработаны для решения некоторых из вышеперечисленных проблем.

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

Если вы хотите приобрести лицензию, выбирайте двойное решение. Это непрерывная HA и аварийное восстановление, у вас может быть второй vps, синхронизирующийся в реальном времени с вашим основным, а в случае сбоя вы можете просто переключить IP-адрес на клоне, чтобы принимать запросы.

Двойной дубль