процесс
Devops инженеры RDN Group провели аудит инфраструктуры и устранили неполадки. Было предложено несколько вариантов решения.
Для обеспечения отказоустойчивости был собран географически распределенный кластер из трех серверов (в разных точках страны). Выполнены настройки по взаимодействию серверов с учетом экономических требований заказчика, которые позволяют в случае, если один из серверов станет недоступен, сократить максимальное время простоя до 5 минут.
Далее проект был передан на поддержку, которая включает:
- Регулярный мониторинг на наличие уязвимостей и применение обновлений безопасности.
- Резервное копирование.
Детальная информация по настройке географически распределенного кластера из трех узлов:
Сервер 1
Установлена Proxmox VE на разделы ZFS Mirror.
Еженедельно выполняется zfs scrub для верификации данных в пуле.
Сервер 2
Установлен без использования ФС ZFS, так как вендор не предполагает установку ОС через KVM по собственным сценариям.
Для организации синхронизации данных ВМ был создан массив ZFS в файле объемом в 1 Тбайт.
На сервер выполняется синхронизация виртуальных машин.
Сервер 3
Сервер используется для обеспечения кворума. Непосредственно в работе ВМ не участвует.
Для обеспечения отказоустойчивости создана группа виртуальных машин:
- Приоритетным сервером является основной сервер. На дополнительный сервер выполняется репликация:
Репликация выполняется ежеминутно для сервера СУБД, для остальных ВМ она выполняется раз в 5 минут для снижения нагрузки на сетевую и дисковую подсистему.
- В случае отказа сервера, на котором в текущий момент не располагаются виртуальные машины, системой не производится никаких действий.
Рассмотрим сценарии, при которых происходит миграция машин:
- Отказ узла, на котором расположены ВМ. В этом случае срабатывает алгоритм failover и виртуальные машины запускаются с дополнительного узла системой автоматически из созданных ранее состояний миграции.
- Разрыв связи между узлом, с располагающимися на нём ВМ и другими узлами:
Т.к. сервер не имеет связи с другими узлами кластера, виртуальные машины останавливаются, т. к. подразумевается, что два других узла имеют между собой связность и ВМ будут перезапущены на другом узле.
- Разрыв связи между всеми узлами кластера. В этом случае каждый из серверов будет считать, что виртуальные машины запускать нельзя — кластер находится в «инконсистентном» состоянии. В этом случае, если необходимо возобновить работу сервисов даже на одном узле, системному администратору необходимо войти на узел, на котором нужно обеспечить работу виртуальных машин, и выполнить команду pvecm e 1 (игнорировать отсутствие кворума). Тогда такой узел запустит виртуальные машины, несмотря на то, что у него нет связи с другими узлами кластера.