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