Рассмотрение использования DRBD или кластерной файловой системы для обеспечения бесперебойной работы в условиях простоя в среде малого бизнеса.
В настоящее время мы используем серверный блок для файлового сервера с использованием Linux и самбы, а затем запускаем веб-сервер и базу данных на виртуальной машине. Искал добавление второго сервера и размещение файлов и виртуальной машины в распределенной файловой системе. Базовая ОС более статична, и ею легко управлять вручную (копируйте файлы конфигурации во время изменения, копируйте базовую ОС, если необходимо, из полных резервных копий и т. Д.)
Вопрос касается сценария отработки отказа, если это делается вручную. Если сервер 1 выходит из строя и переключение выполняется вручную, аварийное переключение завершается путем простой установки статического IP-адреса сервера 2 на сервер 1 (снова сервер 1 не работает и требует ремонта), запуска Samba и запуска виртуальная машина, у которой будут те же статические IP-адреса, что и при работе на сервере 1, и при запуске служб резервного копирования?
Это звучит как быстрый и простой процесс, почти слишком простой. Я что-то упускаю? Это также можно легко автоматизировать с помощью сценария или чего-то, что кто-то с ограниченными навыками может запустить в случае сбоя.
Время простоя в случае аппаратного сбоя может легко составить дни без поддержки оперативной ИТ-поддержки и необходимых деталей без второго сервера, но со вторым сервером время простоя составит максимум несколько часов (если нет один офис достаточно опытен для выполнения таких операций, минут, если кто-то был)
Описываемый вами процесс аварийного переключения настолько же прост, насколько и верен. Использование DRBD - ключевой шаг к созданию избыточности, поскольку вы устраняете единую точку отказа, такую как общее хранилище.
Текущее переключение при отказе, о котором вы говорите, можно легко автоматизировать с помощью Кардиостимулятор / Corosync так что нет необходимости в ручном вмешательстве. Я бы предпочел самописные сценарии, так как он также заботится об ограждении нефункциональных узлов, чтобы вы не столкнулись со сценарием разделения мозга (который может испортить все ваши данные).
Имейте в виду, что «настоящая» HA требует полного (или, по крайней мере, максимально архивируемого) разделения систем (отдельное помещение (или хотя бы стойка), разные USV, резервная коммутация и т. Д.). Единая точка отказа обычно сводит на нет все ваши усилия по оптимизации доступности.