На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». По моим предыдущим статьям, наверно, уже понятно, что я люблю разбираться с разными техническими решениями, поэтому когда DATAREON предложил мне тестовую лицензию на кластер с модулем горячего восстановления, я не стал отказываться. Будем разбираться с тем, как работает кластер серверов DATAREON и для чего нужен модуль горячего восстановления.
Что такое DATAREON Platform
Цитата из документации:
DATAREON Platform является масштабируемой и отказоустойчивой low-code платформой для управления корпоративными данными и интеграционными потоками.
Платформа создана для интеграции приложений, при этом обеспечивается построение единого распределенного информационного ландшафта предприятия, а также целостных систем нормативно-справочной информации в компаниях с разветвленной филиальной структурой или неоднородным информационным ландшафтом.
Если кратко: DATAREON Platform — шина данных + хранилище данных. Далее, для простоты, DATAREON Platform буду называть DATAREON.
Общая информация о работе в режиме кластера
Кластер работает по схеме Active-active, т. е. в кластере отсутствуют резервные ноды, простаивающие в ожидании выхода из строя основных.
DATAREON обеспечивает отказоустойчивость по схеме N-1, т. е. пока жива хотя бы одна нода, кластер будет работать.
DATAREON способен работать в гетерогенной среде, когда часть нод работают с операционной системой Windows, другая часть работает с Linux. Это никак не ограничивает функциональные возможности кластера или отдельных нод.
Для работы кластера не требуется установка дополнительного ПО.
Количество нод в кластере никак не лицензируется. Дополнительно лицензируется только модуль горячего восстановления, приобретается опционально.
DATAREON не обеспечивает отказоустойчивость непрерывной доступности, при которой происходит быстрый перезапуск вышедшего из строя сервера.
Не обеспечивается предоставление единого адреса доступа для переехавших Сервисов и Внешних Систем.
Настройка кластера DATAREON
В моем кластере будут 3 виртуальные машины: 2 на базе Windows 10, одна Centos 9. Установка кластера практически ничем не отличается от установки нескольких отдельных нод и описана в документации. Я не буду на этом останавливаться, отмечу только один важный момент: после установки ноды не спешите заходить в центр настройки. Если вы в него зайдете и создадите конфигурацию, нода станет независимой, включить ее в кластер не получится. Придется очищать конфигурацию и делать переустановку.
После установки DATAREON на отдельные ноды заходим в «Центр настройки» только с одного сервера. В настройках меняем адрес 127.0.0.1 на реальный IP-адрес сервера.
Далее, в «Центре настройки» идем в раздел «Кластеры» и добавляем новый.
Затем возвращаемся в пункт «Серверы» и добавляем остальные сервера. Для каждого сервера указывается IP-адрес, порт (можно оставить по умолчанию 7290), название и имя сервера.
На этом первичная настройка кластера закончена, можно применять конфигурацию и посмотреть, как распределяться системы и коннекторы между нодами. Для этого переместимся в «Центр мониторинга».
Мониторинг работы кластера
Центр мониторинга кластера
Центр мониторинга у кластера один. За его работу отвечает нода — координатор кластера. Координатор кластера назначается автоматически, если есть необходимость ограничить список серверов, которые могут быть координаторами, это можно сделать в конфигурации кластера, перечислив EntityID нод в параметре «Coordinators».
Чтобы открыть «Центр мониторинга», можно воспользоваться кнопкой перехода из «Центра настройки».
Или пытаться зайти в центр мониторинга любой ноды, используя адрес ноды и порт 7201, например: https://10.0.0.8:7201/, нода автоматически перенаправит вас на центр мониторинга на координаторе с помощью редиректа.
Размещение сервисов
Для контроля распределения сервисов и систем по нодам кластера есть вкладка «Размещение сервисов», очень наглядно демонстрирующая, на какой ноде функционирует сервис или адаптер.
Мониторинг показателей работы кластера
Контроль работы DATAREON'а в режиме кластера мало отличается от контроля работы в режиме одной ноды. Благодаря единому центру мониторинга, все показатели собираются в одном месте, что очень удобно.
Что не очень удобно, так это отсутствие возможности посмотреть информацию сразу по всем серверам в таком виде.
В режиме одной ноды можно выбрать сервер и сразу увидеть все очереди, архивы, скорость обработки и т. д. Хорошо бы для кластера добавить такую возможность.
В остальном, работа с трассировками, логами и другими функциями центра мониторинга ничем не отличается от работы в режиме одной ноды.
Управление распределением сервисов
По умолчанию координатор сам распределят сервисы и системы по нодам. Если вам по каким-то причинам требуется скорректировать распределение, для этого есть ряд настроек:
В конфигурации сервера в секции allocationsGlobal, в массиве systems можно указать EntityID систем, которые приоритетно будут запускаться на этом сервере.
Опция конфигурации сервера disableAutoAssignment отвечает за запрет миграции сервисов на этот сервер. True – миграция запрещена. False (значение по умолчанию) — миграция разрешена. Если в конфигурации указывается True, все системы необходимо прописать в настройках (п.1), иначе система не запустится.
Привязка внешних систем к серверам через центр настройки.
⚠️ Настройки описаны в порядке уменьшения приоритета.
Скорее всего, это не все настройки. Если покопаться в конфигах кластера/сервера/системы, можно найти много всего интересного. К сожалению, далеко не все описано в документации. Тонкие настройки придется выпытывать у службы поддержки.
Центр мониторинга позволяет вручную отправить систему на конкретную ноду.
Отказоустойчивость
Балансировка нагрузки
Чаще всего узким горлышком системы DATAREON становится сервис обработки процессов, обеспечивающий всю вычислительную логику в процессах и маршрутах. Для предотвращения задержки обработки сообщений в кластере есть возможность создать несколько сервисов обработки процессов (максмально по одному на каждую ноду). Система мониторит длину очереди новых сообщений на входе в сервис обработки процессов и, если очередь превышает заданное в настройках количество сообщений, перенаправляет очередь на другой сервис обработки процессов.
Выход из строя одной или нескольких нод
При выходе из строя одной или нескольких нод, координатор кластера в течение некоторого времени (примерно 1,5 минуты по умолчанию) будет пытаться получить ответ от вышедшей из строя ноды. Не получив ответа, поднимет вышедшие из строя сервисы и системы на других нодах.
Если из строя выйдет сам координатор, другие ноды это заметят и какая-то из оставшихся нод назначит себя координатором.
Поведение внешних систем при миграции:
Модуль интеграции с 1С переключается автоматоматически.
Веб-сервер. Если служба DATAREON на ноде, к которой обращается клиент, находится в рабочем состоянии, но сам REST-сервер был перенесен на другую ноду, будет автоматически выставлен редирект для перенаправления запроса. На случай выхода из строя ноды на стороне клиента следует предусмотреть обращение к нескольким нодам.
REST-клиент переключается автоматоматически.
СУБД переключаются автоматоматически.
Хранилище данных, UI также поддерживают работу в кластере и будут мигрированы в случае недоступности нод.
Что же будет с данными, которые находились в обработке в момент выхода из строя ноды?
DATAREON спроектирован таким образом, что данные переходят по цепочке сервисов, сохраняясь перед каждым этапом обработки в очередях. Очереди хранятся на диске и, соответственно, никуда не исчезают при перезагрузке сервера или перезапуске службы. При выходе из строя ноды сообщения, которые находились в обработке, останутся сохраненными на диске этой ноды. После восстановления работоспособности данные из очередей будут возвращены в обработку. Таким образом, данные не пропадут, но обработка будет выполнена с задержкой на время, которое потребуется для восстановления работоспособности ноды. Разумеется, нужно иметь в виду, что при выходе из строя дисковой системы, данные будут потеряны безвозвратно.
Модуль горячего восстановления
Чтобы предотвратить потерю данных и даже задержку в обработке данных при выходе из строя ноды, был разработан модуль горячего восстановления (далее МГВ). Модуль обеспечивает репликацию данных из очередей ноды в резервные очереди на других нодах.
Благодаря такой репликации, данные, находящиеся в очередях вышедшей из строя ноды, будут запущены в обработку из резервных очередей, как только нода будет определена как вышедшая из строя.
Ключевой параметр настройки МГВ — faultTolerance в конфигурации кластера. Параметр отвечает за уровень отказоустойчивости, или по-другому за количество серверов, на которые будут реплицироваться очереди. Максимальная отказоустойчивость — количество нод-1. В этом случае очереди будут реплицироваться на все ноды кластера. Минимальное значение — 0, репликация отключена.
Заключение
Значительная часть настроек кластера производится правкой конфигураций, не всегда очевидно. Конечно, править конфиги через центр настройки значительно проще, чем бегать по серверам и править их в файлах, как это часто бывает в open source продуктах, но к конфигам явно не хватает документации.
Также хочется отметить, что для настройки и обслуживания кластера DATAREON не требуется изучать/устанавливать/обслуживать дополнительное ПО. Кластеризация поддерживается, что называется, из коробки. Встроенных средств мониторинга и работы с логами вполне достаточно.
Если для ваших интеграций допусти́м простой в пределах нескольких минут при падении сервера, можно рассматривать DATAREON как достаточно простую интеграционную платформу с высоким уровнем отказоустойчивости.
Статья появилась в результате подготовки к вебинару по модулю горячего восстановления. Чтобы получить видеозапись, пройдите короткую регистрацию.
Также приглашаю в сообщество по шинам данных. С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 15 разных решений. Для всех, кто интересуется шинами данных, я создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина. Если вы хотите узнать больше о DATAREON Platform, «1С:Шине», Factor-ESB и других отечественных решениях, прямо сейчас вступайте в сообщество и задавайте вопросы.
