Кейс Построение отказоустойчивой ИТ-инфраструктуры для инженерной компании

Цифровые сервисы компании (сайт + личный кабинет) были расположены на 1 сервере.

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

Devops инженеры RDN Group провели аудит инфраструктуры и устранили неполадки. Было предложено несколько вариантов решения.

Для обеспечения отказоустойчивости был собран географически распределенный кластер из трех серверов (в разных точках страны). Выполнены настройки по взаимодействию серверов с учетом экономических требований заказчика, которые позволяют в случае, если один из серверов станет недоступен, сократить максимальное время простоя до 5 минут.

Далее проект был передан на поддержку, которая включает:

• Регулярный мониторинг на наличие уязвимостей и применение обновлений безопасности.
• Резервное копирование.

Установлена Proxmox VE на разделы ZFS Mirror.

Еженедельно выполняется zfs scrub для верификации данных в пуле.

Установлен без использования ФС ZFS, так как вендор не предполагает установку ОС через KVM по собственным сценариям.

Для организации синхронизации данных ВМ был создан массив ZFS в файле объемом в 1 Тбайт.

На сервер выполняется синхронизация виртуальных машин.

Сервер используется для обеспечения кворума. Непосредственно в работе ВМ не участвует.

Для обеспечения отказоустойчивости создана группа виртуальных машин:

1. Приоритетным сервером является основной сервер. На дополнительный сервер выполняется репликация:
   Репликация выполняется ежеминутно для сервера СУБД, для остальных ВМ она выполняется раз в 5 минут для снижения нагрузки на сетевую и дисковую подсистему.
2. В случае отказа сервера, на котором в текущий момент не располагаются виртуальные машины, системой не производится никаких действий.

Рассмотрим сценарии, при которых происходит миграция машин:

1. Отказ узла, на котором расположены ВМ. В этом случае срабатывает алгоритм failover и виртуальные машины запускаются с дополнительного узла системой автоматически из созданных ранее состояний миграции.
2. Разрыв связи между узлом, с располагающимися на нём ВМ и другими узлами:
   Т.к. сервер не имеет связи с другими узлами кластера, виртуальные машины останавливаются, т. к. подразумевается, что два других узла имеют между собой связность и ВМ будут перезапущены на другом узле.
3. Разрыв связи между всеми узлами кластера. В этом случае каждый из серверов будет считать, что виртуальные машины запускать нельзя — кластер находится в «инконсистентном» состоянии. В этом случае, если необходимо возобновить работу сервисов даже на одном узле, системному администратору необходимо войти на узел, на котором нужно обеспечить работу виртуальных машин, и выполнить команду pvecm e 1 (игнорировать отсутствие кворума). Тогда такой узел запустит виртуальные машины, несмотря на то, что у него нет связи с другими узлами кластера.

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

Devops инженеры RDN Group провели аудит инфраструктуры и устранили неполадки. Было предложено несколько вариантов решения.

Для обеспечения отказоустойчивости был собран географически распределенный кластер из трех серверов (в разных точках страны). Выполнены настройки по взаимодействию серверов с учетом экономических требований заказчика, которые позволяют в случае, если один из серверов станет недоступен, сократить максимальное время простоя до 5 минут.

Далее проект был передан на поддержку, которая включает:

• Регулярный мониторинг на наличие уязвимостей и применение обновлений безопасности.
• Резервное копирование.

Установлена Proxmox VE на разделы ZFS Mirror.

Еженедельно выполняется zfs scrub для верификации данных в пуле.

Установлен без использования ФС ZFS, так как вендор не предполагает установку ОС через KVM по собственным сценариям.

Для организации синхронизации данных ВМ был создан массив ZFS в файле объемом в 1 Тбайт.

На сервер выполняется синхронизация виртуальных машин.

Сервер используется для обеспечения кворума. Непосредственно в работе ВМ не участвует.

Для обеспечения отказоустойчивости создана группа виртуальных машин:

1. Приоритетным сервером является основной сервер. На дополнительный сервер выполняется репликация:
   Репликация выполняется ежеминутно для сервера СУБД, для остальных ВМ она выполняется раз в 5 минут для снижения нагрузки на сетевую и дисковую подсистему.
2. В случае отказа сервера, на котором в текущий момент не располагаются виртуальные машины, системой не производится никаких действий.

Рассмотрим сценарии, при которых происходит миграция машин:

1. Отказ узла, на котором расположены ВМ. В этом случае срабатывает алгоритм failover и виртуальные машины запускаются с дополнительного узла системой автоматически из созданных ранее состояний миграции.
2. Разрыв связи между узлом, с располагающимися на нём ВМ и другими узлами:
   Т.к. сервер не имеет связи с другими узлами кластера, виртуальные машины останавливаются, т. к. подразумевается, что два других узла имеют между собой связность и ВМ будут перезапущены на другом узле.
3. Разрыв связи между всеми узлами кластера. В этом случае каждый из серверов будет считать, что виртуальные машины запускать нельзя — кластер находится в «инконсистентном» состоянии. В этом случае, если необходимо возобновить работу сервисов даже на одном узле, системному администратору необходимо войти на узел, на котором нужно обеспечить работу виртуальных машин, и выполнить команду pvecm e 1 (игнорировать отсутствие кворума). Тогда такой узел запустит виртуальные машины, несмотря на то, что у него нет связи с другими узлами кластера.