Модуль «Горячий резерв». Обеспечивает постоянную доступность, отказоустойчивость и масштабируемость «Единого клиента».

Описание

«Единый клиент» часто участвует в критически важных бизнес-процессах: от его доступности могут зависеть обслуживание клиентов, оформление продуктов и работа других систем. У крупных заказчиков через MDM проходят миллиарды клиентских записей, поэтому требования к его доступности особенно высоки. Если единственная инсталляция становится недоступна из-за сбоя или технических работ, останавливаются и зависящие от нее процессы.

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

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

Уровни отказоустойчивости

Уровень отказоустойчивости показывает, сколько времени система может быть недоступна в течение года. Чем выше требования к доступности в компании, тем меньше допустимое время простоя.

На базовом уровне система может быть недоступна до 30 часов в год, что допустимо для некритичных процессов. Но если от MDM зависят ключевые бизнес-процессы, это уже большие риски.

Для критичных систем требования гораздо выше. На четвертом уровне допустимое время простоя сокращается примерно до 30 минут в год. Это уровень «четырех девяток» — 99,99% доступности: система должна работать практически постоянно.

Горячий резерв помогает «Единому клиенту» соответствовать таким требованиям за счет нескольких активных узлов и распределения нагрузки между ними.

«Единый клиент» без резерва

Имеет несколько точек отказа: выход из строя сервера с «Единым клиентом» и «Фактором» или сервера БД. Также нужны технические окна для выполнения обновлений, изменения настроек и других действий, требующих остановки или рестарта «Единого клиента».

«Единый клиент» с горячим резервом

Работают два или несколько серверов. Если один сервер вышел из строя, вся нагрузка автоматически переходит на другие.

Основные функции

Защищает от простоя при сбоях и техническом обслуживании

Если один из узлов кластера выходит из строя, балансировщик перенаправляет запросы на исправные узлы. Когда узел восстанавливается, он снова включается в распределение нагрузки.

Это же касается плановых работ: обновление ПО, изменение настроек, актуализация выполняются поочередно на каждом узле, поэтому систему не нужно останавливать целиком.

Обеспечивает отказоустойчивость и катастрофоустойчивость

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

Позволяет масштабировать ресурсы системы

Кластер помогает наращивать ресурсы системы по мере роста бизнеса, увеличения объема данных и подключения новых процессов. Чем больше узлов, тем большую нагрузку система готова выдержать.

Ускоряет пакетную обработку и очистку данных

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

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

Поддерживает онлайн-обработку запросов

Кластер распределяет нагрузку между узлами: например, один преимущественно обслуживает онлайн-запросы, другой занят пакетной обработкой. Поэтому большая загрузка данных не тормозит онлайн. Если пакетной обработки нет, свободные ресурсы могут использоваться для онлайн-запросов.

Технические особенности

Узлы синхронизируются между собой

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

Сохраняется правильный порядок событий

Система следит, чтобы события по одной и той же карточке клиента применялись в правильной последовательности, даже если они пришли на разные узлы. Устаревшее событие, которое пришло позже актуального, просто игнорируется.

Время на узлах синхронизировано

Перед запуском кластера администратор настраивает синхронизацию времени между серверами через NTP. Система постоянно проверяет, не разошлись ли часы на узлах, и фиксирует это в логе, если расхождение превышает допустимое значение.

Кластер можно расширять

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

Ключевые показатели

В технической презентации зафиксированы следующие показатели:

• 150 мс — средняя задержка синхронизации;
• 99,97% — доступность системы на двух узлах;
• 99,99% — доступность системы на трех и более узлах.

Ограничения

Для каждого дополнительного узла нужно покупать отдельный комплект лицензий, идентичный первому.