Дваbackend-узла Directum RX сами по себе еще не гарантируют отказоустойчивость.Один из них может продолжать отвечать на HTTP-запросы с кодом 200, одновременноиспытывая нехватку памяти, перегрузку CPU или проблемы с отдельными сервисами.В этот момент обычная проверка доступности продолжает считать узел исправным инаправлять на него пользовательский трафик. В статье расскажем, как реализоватьhealth-agent, который помогает HAProxy учитывать не только доступность, но ифактическую степень деградации backend-узла.Когда HTTP 200 уже недостаточноПри построении отказоустойчивого контура Directum RX недостаточно просто развернуть несколько экземпляров приложения и поставить перед ними балансировщик нагрузки. Нужно понимать, способен ли конкретный узел нормально обрабатывать запросы в конкретный момент времени.Классический health-check отвечает на бинарный вопрос: сервис доступен или нет. Например, HAProxy отправляет HTTP-запрос на заданный URL и, получив ожидаемый код ответа, считает backend работоспособным. Если проверка не проходит, узел исключается из балансировки.Но между состояниями «полностью исправен» и «полностью недоступен» есть промежуточная зона. Узел может продолжать отвечать HTTP 200 и при этом:находиться под высокой загрузкой CPU;испытывать нехватку оперативной памяти;активно использовать swap;иметь заканчивающееся место на диске или inode;потерять связь с PostgreSQL;частично потерять связь с RabbitMQ;иметь недоступный PreviewService, IntegrationService или LogService;содержать контейнер Directum RX в состоянии Restarting или Exited.Обычная проверка доступности не различает такие состояния. Для нее backend либо работает, либо нет. Поэтому при частичной деградации балансировщик может продолжать отправлять на проблемный узел столько же запросов, сколько и на исправный.Именно для этой задачи появился проект Self-Healing Directum RX.Что было предложеноТекущая версия проекта — v0/MVP, реализованная в виде Bash health-agent. Ее задача не в том, чтобы самостоятельно перезапускать каждый проблемный компонент, а в том, чтобы дать HAProxy более точную информацию о состоянии backend-узла.RX-health-agent работает непосредственно на backend-узлах, выполняет локальные и сетевые проверки, объединяет результаты и передает итоговое состояние HAProxy через механизм agent-check.В результате балансировщик получает не только сигнал «сервер доступен или недоступен», но и рекомендацию по весу backend-а:СостояниеРеакцияНормаbackend работает с весом 100%Мягкая деградациявес backend-а уменьшается до 75% или 50%Критический отказbackend переводится в down и исключается из балансировкиПлановое обслуживаниеиспользуется maintМягкий административный выводиспользуется drainВосстановлениеузел проходит recovery window и возвращается к рабочему весуТакой подход позволяет не отключать backend полностью при каждой проблеме. Если узел еще способен обслуживать запросы, но давать ему полную нагрузку уже нежелательно, HAProxy снижает его вес и отдает предпочтение более здоровому серверу.Что проверяет health-agentВ версии v0 реализованы проверки:проверка доступности ключевых HTTP endpoint Directum RX;проверка /client/api/health;проверка /client/health;проверка StorageService;проверка PreviewService;проверка IntegrationService;проверка LogService;проверка состояния контейнеров Directum RX;проверка доступности Docker daemon;проверка свободного места на файловой системе;проверка inode;проверка CPU и load average;проверка RAM;проверка swap;Кроме того, агент:формирует причину деградации;рассчитывает итоговый вес узла;поддерживает мягкую деградацию без полного отключения backend-а;позволяет вручную перевести узел в maintenance;поддерживает режим drain;использует recovery window перед полноценным возвратом backend-а в балансировку.При этом уже сейчас важно четко обозначить границу возможностей это версии.Health-agent не является системой общего мониторинга и не заменяет HAProxy, Keepalived, Patroni, RabbitMQ или решение «Мониторинг Directum RX». Его задача — максимально быстро принять решение о пригодности конкретного RX backend-а для дальнейшей обработки пользовательского трафика.Архитектура тестового стендаДля разработки и тестирования проекта развернут отдельный стенд Directum RX 26.1 на РЕД ОС 8.В составе стенда для первой версии агента используются следующие группы узлов.УзелНазначениеМинимальные ресурсыdev-ddc-hap-01HAProxy + Keepalived, node 12 vCPU, 4 ГБ RAMdev-ddc-hap-02HAProxy + Keepalived, node 22 vCPU, 4 ГБ RAMdev-ddc-rx261aDirectum RX 26.1 backend 16 vCPU, 16 ГБ RAMdev-ddc-rx261bDirectum RX 26.1 backend 26 vCPU, 16 ГБ RAMДля кластерабалансировки используются два HAProxy-узла и Keepalived. Пользовательский трафик поступает на виртуальный IP и далее распределяется между backend-узлами Directum RX.Длявзаимодействия HAProxy с health-agent используется TCP-порт 9505.Кто за чтоотвечаетВтекущей архитектуре важно не смешивать функции 3-х компонентов.rx-health-agentАгентработает в контексте backend-узла Directum RX и оценивает:· состояниесамого RX;· состояниеконтейнерной среды;· ресурсыоперационной системы.Результатомстановится агрегированное состояние узла, например 100%, 75% или 50%, down, maint или drain.HAProxyHAProxyвыполняет две проверки:· штатныйHTTP health-check конкретного сервиса Directum RX;· получениедополнительного состояния backend-а через agent-check.Именно HAProxy принимает окончательное решениео доступности узла и его весе в балансировке.KeepalivedKeepalived отвечает не за отдельный backendDirectum RX, а за доступность самого слоя балансировки. Если первыйHAProxy-узел перестает выполнять свою функцию, Keepalived должен переключитьвиртуальный IP на второй HAProxy.Проверку состояния HAProxy и Keepalived неследует смешивать с проверками RX health-agent. Для балансировщиков планируетсяотдельный локальный механизм.Какустроена версия v0Health-agentустанавливается непосредственно на backend-узлы Directum RX. В тестовом контуреэто dev-ddc-rx261aи dev-ddc-rx261b.Для взаимодействия с HAProxyиспользуется TCP-порт9505.Состав файловОсновной сценарийагента располагается в:Конфигурационный файл:Текущее состояниеагента сохраняется в:Дляадминистративного управления backend-узлом дополнительно используются marker-файлы:Режимы maintenance, drain и механизм recoveryуже входят в возможности Bash-версии v0.В конфигурации задаются проверяемые endpoint-ыDirectum RX, допустимые HTTP-коды, таймауты, пороги ресурсов операционнойсистемы и параметры инфраструктурных проверок.Для Client API используетсяendpoint:с ожидаемым HTTP-кодом 200.Отдельные warning- и critical-пороги предусмотрены для диска, inode, CPU/load average, RAM и swap.Основная логика v0 реализована на Bash. За одинвызов агент выполняет проверки, определяет найденные проблемы и формируетитоговое решение для HAProxy. Затем результат передается через systemd socketactivation на TCP-порту 9505.Для подключения к HAProxy используются agent-check и отдельный периодпроверки agent-inter.После изменения конфигурации HAProxy она проверяется командой:После успешной проверки конфигурацию можно применить через:Политика длясервисов Directum RXДля разных компонентов используются разныереакции на отказ:ПроверкаЧто контролируетсяРеакцияClient API/client/api/healthdownWeb Client/client/healthdownStorageService/storage/healthdownPreviewService/preview/health50%IntegrationService/integration/health50%LogService/log/health75%Dockerdaemon и состояние контейнеров50% / downCPU / Loadнагрузка операционной системы50% / downRAMиспользование памяти50% / downSwapиспользование swap50%Diskзаполнение файловой системы50% / downInodeдоступные inode50% / downНа выходе агент может сформировать несколько состояний.РезультатЗначение100%узел полностью работоспособен75%небольшая деградация50%существенная деградацияdownузел необходимо исключитьmaintплановое обслуживаниеdrainмягкий административный выводup / readyпереходное состояние восстановленияClient API, Web Client иStorageService считаютсякритичными. Еслипроверка одного из них не проходит, backend исключается из балансировки.PreviewServiceи IntegrationService переводят узел в состояние с весом 50%, а LogService — свесом 75%. Пользовательский трафик продолжает обслуживаться обоими серверами,но HAProxy отдает предпочтение полностью исправному backend-у.АдминистративныережимыДля планового вывода узла используется режим maintenance:После этого агент возвращает состояние maint, а HAProxy переводитbackend в MAINT.После окончания работ marker-файл удаляется:Для более мягкого вывода используется режим drain:touch /var/lib/rx-health-agent/drainВэтом случае агент возвращает drain,а HAProxy не должен направлять на backend новые обычные запросы.После окончания работ файл также удаляется:Вv0 предусмотрен и recovery window. После состояния down агент не сразувозвращает backend к полной нагрузке. Сначала узел проходит переходноесостояние восстановления, после чего возвращается к рабочему весу.Этоснижает риск ситуации, когда недавно восстановившийся сервер мгновенно получаетвесь доступный объем трафика.Пример мягкого вывода с помощью drainПример мягкого вывода с помощью recovery windowКак проверятьработуНастенде проверяются три сценария: деградация из-за ресурсов, полный отказкритичного компонента и частичный отказ отдельного сервиса.Сценарий 1: Высокая загрузка CPUПриложениеможет продолжать отвечать HTTP 200, хотя сервер уже находится под высокойнагрузкой. Для теста на RX-узле создается CPU-нагрузка:Агент контролирует load average и при превышенииwarning-порога уменьшает вес backend-а.Ожидаемый результат:При этом первый сервер не переводится в DOWN: онпродолжает работать, но HAProxy начинает отдавать предпочтение второмуbackend-у.HAProxy Stats во время CPU-тестаСценарий 2: Остановкакритичного контейнераВторой сценарий —отказ компонента, без которого RX backend уже нельзя считать нормальноработоспособным.На одном из RX-узлов останавливаем нужный критичныйконтейнер:Его состояние можно проверить командой:Есликонтейнер Web Client или другого критичного компонента переходит в Exited либо другоепроблемное состояние, соответствующий health-check перестает проходить. Backendпереводится в down,а трафик продолжает обслуживаться вторым RX-узлом.Ожидаемое состояние:HAProxy Stats после остановки контейнера веб-сервераПосле завершения теста контейнер запускается обратно:После успешных проверок и прохождения recovery windowbackend возвращается в балансировку.Сценарий 3: ОтказPreviewServiceНе каждый отказ должен приводить к полному отключению узла.Для PreviewService используетсяendpoint:Если проверка перестает проходить, backend не переводится вdown. Вместоэтого агент уменьшает его вес до 50%:Обасервера продолжают обслуживать трафик, но HAProxy отдает предпочтение полностьюисправному backend-у.Почему для v0выбрали BashНапервом этапе нужно было быстро проверить саму концепцию: можно ли использоватьфактическое состояние RX-узла для динамического управления балансировкой.Дляэтого Bash оказался достаточным. Необходимые данные уже доступны штатнымисредствами Linux:· HTTP-проверкивыполняются через curl;· состояниефайловой системы получают через df;· сведенияо памяти — через free;· load average — из /proc;· состояниеконтейнеров — командами Docker.Bash-агентне требует тяжелого runtime и может быть размещен непосредственно на RX-узле.Сценарий легко изменить, проверить через bash-n, выполнить на сервере и сопоставить результат с состояниемHAProxy.ДляMVP этого оказалось достаточно. При этом Bash-версия рассматривается именно какv0 и проверка работоспособности идеи, а не как финальная реализация. По мереусложнения логики становятся важными история состояний, сложные API, статистиказа временное окно и дополнительные механизмы стабилизации.Что планируетсядальшеВследующих версиях планируется:· развитьболее глубокую диагностику RabbitMQ и PostgreSQL;· учитыватьвремя ответа сервисов;· анализироватьHTTP-ошибки за временной интервал;· хранитьисторию состояний;· улучшитьзащиту от частого изменения веса;· реализоватьполноценную проверку очередей RabbitMQ и SQL-проверка PostgreSQL;· рассчитыватьp95/p99 времени ответа HTTP-сервисов.Следующая версия должна сохранить основную идеюv0 — быстро формировать понятное решение для HAProxy, — но использовать большеданных для определения фактической деградации.НаширекомендацииПри построении отказоустойчивого контура неограничивайтесь проверкой доступности приложения: заранее определите, какиекомпоненты являются критичными, какие проблемы допускают мягкую деградацию, акакие требуют полного исключения узла из балансировки. Начинайте с минимальногонабора проверок и понятной матрицы реакций, тестируйте каждое состояние настенде и отделяйте health-check от общего мониторинга и автоматического восстановления.Такой подход позволяет сначала проверить саму логику маршрутизации трафика, азатем последовательно расширять self-healing без преждевременного усложненияархитектуры.