HA-инфраструктура для Totum: архитектура отказоустойчивости на двух серверах

Как сообщает Habr, разработчики low-code платформы Totum столкнулись с задачей переноса рабочей системы в новую отказоустойчивую инфраструктуру при жестком ограничении на количество серверов. Команда спроектировала отказоустойчивое решение с использованием двух основных нод и легковесного witness-сервера для обеспечения кворума.

Когда речь заходит об обеспечении высокой доступности или High Availability, стандартный набор требований обычно включает три полноценных сервера, выделенный балансировщик нагрузки, кластер базы данных PostgreSQL, распределенное хранилище данных и комплексную систему мониторинга. Такой подход гарантирует отказоустойчивость, но существенно увеличивает бюджет проекта и сложность обслуживания. Для self-hosted low-code платформы Totum, которая применяется для создания внутренних корпоративных систем, учетных приложений и ERP, классическая схема избыточна на этапе масштабирования малого или среднего бизнеса.

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

Предыстория и контекст

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

В качестве базы данных используется СУБД PostgreSQL, требующая надежного механизма репликации и быстрого переключения роли мастера при потере связи. Для синхронизации файлов пользователей потребовалось задействовать специализированное файловое хранилище, способное мгновенно отрабатывать сценарии сбоев без потери или повреждения загруженных документов. Автоматизация развертывания и повседневного обслуживания всей инфраструктуры была полностью возложена на сценарии Ansible, что исключает человеческий фактор при настройке сетевых интерфейсов и служб.

Как работает witness-сервер в этой схеме?

Для решения проблемы кворума без закупки дорогостоящего железа инженеры задействовали минималистичную третью ноду, выполняющую роль свидетеля или witness. Этот вспомогательный узел практически не несет вычислительной бизнес-нагрузки и не запускает основные контейнеры платформы Totum, но позволяет избежать сценария разделения мозга сети в критической ситуации. Если основной сервер теряет связь со второй рабочей нодой, именно witness помогает однозначно определить активный узел и предотвратить одновременную запись данных из двух источников.

Технические подробности и реализация архитектуры

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

Для работы с пользовательскими файлами применяется механизм репликации хранилища, обеспечивающий идентичность данных на обеих нодах в режиме реального времени. Переключение сетевых маршрутов и виртуальных IP-адресов происходит автоматически, благодаря чему клиенты не замечают смены активного сервера, а системным администраторам не требуется вручную корректировать настройки службы DNS. Весь стек программного обеспечения, включая конфигурации веб-серверов, параметры безопасности и системные службы, полностью описывается в виде кода через плейбуки Ansible, что позволяет воспроизвести идентичное окружение на любом аналогичном оборудовании за считанные минуты.

Кого затронет и как

Описанный подход представляет практический интерес для системных администраторов, DevOps-инженеров и разработчиков, занимающихся развертыванием self-hosted систем в компаниях с ограниченным бюджетом на IT-инфраструктуру. Создание отказоустойчивых контуров без избыточных затрат на покупку серверного оборудования позволяет малому и среднему бизнесу повысить надежность корпоративных систем управления без привлечения крупных инвестиций. Компании, использующие платформу Totum для автоматизации внутренних процессов, получают стабильно работающие приложения с минимальным временем простоя при минимальной стоимости владения аппаратной частью.

Что будет дальше

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

Итог

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