Отказоустойчивость на бюджетном железе: два сервера вместо одного

Три девятки. 99,9% доступности в год - это примерно 8,7 часа допустимого простоя за 12 месяцев, меньше минуты в сутки. Несколько лет назад такое требование звучало только от крупных компаний с собственными серверными и отдельным бюджетом на железо. Сейчас с этим приходят средние конторы на 30-80 человек, у которых есть один сервер в углу бухгалтерии и желание, чтобы он не падал.

Запрос понятный. Когда весь документооборот, 1С и почта сидят на одной машине, каждый час простоя - это потерянные деньги и нервы. Проблема в том, что нормальная отказоустойчивость в классическом понимании стоит нормальных денег: кластерное программное обеспечение, общая дисковая полка, специализированное железо. У клиента ничего этого нет и не предвидится.

Мы немного подумали и собрали схему, которая не решает задачу идеально, но решает её реально - на том, что есть.

Идея: два одинаковых сервера и один адрес

Суть простая. Берём два одинаковых сервера - можно и не совсем одинаковых, лишь бы тянули одну и ту же нагрузку. Один работает как основной, второй стоит рядом в горячем резерве: включён, настроен идентично, данные синхронизированы. На оба прописан один виртуальный IP-адрес, который в данный момент поднят только на основном.

Когда основной сервер падает, администратор поднимает этот адрес на резервном. Пользователи переподключаются - и работают дальше. Никакой магии, никакого автоматического переключения. Просто два сервера вместо одного и понятный алгоритм действий при аварии.

Схема выглядит так:

Пользователи -> [виртуальный IP: 192.168.1.10]
                        |
          +-------------+--------------+
          |                            |
   [Основной сервер]          [Резервный сервер]
   192.168.1.11               192.168.1.12
   (vIP поднят)               (vIP не поднят)

Что надо синхронизировать и как

Это главный вопрос, и от ответа зависит всё. Резервный сервер бесполезен, если на нём вчерашние данные.

Файловый сервер. Синхронизация через rsync по расписанию - каждые 15-30 минут. Не идеально: при падении основного потеряем изменения за последние полчаса максимум. Для большинства задач приемлемо. Для критичных документов - дополнительно просим пользователей сохраняться почаще.

Почта. Тут зависит от того, что стоит. Если IMAP и почта хранится на сервере - тот же rsync с частым интервалом плюс синхронизация очереди. Если POP3 и письма скачиваются на компьютеры - задача проще, почтовая очередь небольшая.

База данных 1С или MySQL. Горячий резерв базы - самая сложная часть. Rsync работающую базу корректно не скопирует: файлы заблокированы или находятся в промежуточном состоянии. Делаем дамп по расписанию, синхронизируем дамп, на резервном держим скрипт развёртывания. Интервал - раз в час или раз в два часа в зависимости от активности. Да, при переключении откат будет на последний дамп. Это надо объяснить клиенту до аварии, не во время.

О том, почему данные надо копировать отдельно от железа, мы писали - те же принципы работают и здесь.

Переключение: как быстро и что делает администратор

При обнаружении проблемы с основным сервером последовательность такая:

Первое - убедиться, что основной действительно упал, а не просто завис на две минуты и сейчас поднимется. Поспешное переключение при случайной нагрузке - лишний стресс и путаница. Ждём 3-5 минут, смотрим мониторинг.

Второе - поднять виртуальный IP на резервном. Одна команда. На Linux это ip addr add 192.168.1.10/24 dev eth0, плюс arping, чтобы коммутаторы обновили ARP-таблицы и трафик пошёл к правильному порту.

Третье - проверить работу сервисов на резервном и сообщить пользователям, что можно работать.

Четвёртое - разобраться с основным уже не спеша, без давления текущей аварии.

Всё время переключения при нормальной работе - от 5 до 15 минут. Это не секунды автоматического failover, но это и не час ожидания пока привезут железо или найдут нужный диск.

Что схема не решает

Честность важна. Эта схема - не кластер и не замена нормальному отказоустойчивому решению.

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

Данные на момент переключения не идеально актуальны - есть окно синхронизации. Для большинства офисных задач это терпимо, но надо понимать заранее.

Сам резервный сервер тоже может сломаться. За двумя машинами следить сложнее, чем за одной. Мониторинг обоих обязателен.

Почему это всё равно работает

Практика показывает: большинство простоев в небольших компаниях - не катастрофические отказы с потерей данных, а обычные поломки железа. Умер диск, отказал блок питания, перегрелся процессор. Именно от этого схема с резервным сервером защищает хорошо: основная машина вышла из строя, через 10 минут работа продолжается на второй.

Стоимость второго сервера сопоставимого класса - в разы меньше, чем кластерное программное обеспечение плюс специализированная дисковая полка. И этот второй сервер не стоит мёртвым грузом: на нём можно держать тестовую среду, дополнительные сервисы, то, что не критично по доступности.

Три девятки в году - это 8,7 часа простоя. При одной аварии в квартал с временем восстановления 10-15 минут годовой бюджет использован едва на четверть. Для небольшой компании это честный результат без честного бюджета на enterprise-железо.

Управляемая инфраструктура - это как раз про то, чтобы у клиента была работающая схема под его реальные ограничения, а не красивая презентация про кластеры, которую он не может купить.