Горячее резервирование домена

Назначение

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

Концепция

В обоих инстансах существует домен с одним и тем же названием. В настройках каждого из них заданы параметры резервирования с указанием альтернативного инстанса, доступов к нему, а также приоритета.

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

При корректно настроенной в домене и включенной резервирования выделяются следующие роли для экземпляра домена, а также инстанса при рассмотрении с точки зрения этого домена: * Мастером называется домен с наивысшим приоритетом (наименьшее значение параметра order). * Слейвом называется домен с приоритетом, отличным от наивысшего.

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

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

При этом в рамках инстанса может быть несколько различных доменов с настроенным и включенным резервированием, находящихся в разных ролях и состояниях.

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

При этом модель данных пассивного домена доступна для администраторов и системных процессов.

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

Активный домен ведет журнал своей активности. Он применяется для выкачивания истории в привязке к периодам пассивности и недоступности.

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

Настройка

Чтобы активровать режим резервирования необходимо:

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

  2. Убедиться, что в резервной системе существует домен с тем же именем.

  3. Установить в конфигурациях обеих систем идентичное значение параметра general.pwd_hash_alg.

  4. В каждой из систем в соответствующем домене, подлежащем резервированию, настраивается опция settings.survival_options:

survival_options

Цветом подсвечены обязательные поля для корректной работы сервиса.

  • enabled - должен быть включен в настройках обоих экземпляров.

  • order - приоритет для определения мастера и слейва. Должен отличаться от значения приоритета в настройке домена на другом инстансе, а также от приоритетов, указанных в списке альтернативых инстансов. Рекомендуется, чтобы значения соответствовали, то есть чтобы указанный в списке альтернатив приоритет совпадал с приоритетом соответствующего другого инстанса, и наоборот.

  • security_key - проверочная строка с произвольным ключом, должна совпадать в настройках обоих экземпляров.

  • token_local - токен канала интеграции в домене текущего экземпляра системы. Используется при синхронизации файлов-вложений.

  • uris_local - URL веб-сервера или нескольких веб-серверов текущего экземпляра системы. Используется при синхронизации файлов-вложений. Примеры: "https://instance1.era-platform.ru:443", "http://192.168.100.1".

  • alternatives - список из одного или более объектов-дескрипторов альтернативных систем из группы синхронизации домена.

    • name - опциональное поле, используется только для логирования упоминаний об описываемом альтернативном экземпляре.

    • order - приоритет для определения мастера и слейва. Должен непротиворечиво соответствовать значению order корневого объекта настройки в соответствующем альтернативном экземпляре системы.

    • uris - URL веб-сервера или нескольких веб-серверов альтернативного экземпляра системы. Используется для http и websocket подключения к веб-серверу альтернативного экземпляра с целью определения доступности и синхронизации данных.

    • token - токен канала интеграции в домене альтернативного экземпляра системы. Используется для авторизации http и websocket подключений к веб-серверу альтернативного экземпляра. Токен должен иметь назначенного пользователя с ролью admin для полноценного доступа к настройкам.

    • ws_redirect_to - опциональное поле. При заполнении корректными URL доступа к альтернативному экземпляру, во время пассивного состояния на эти адреса активного альтернативного экземпляра осуществляется переадресация всех HTTP запросов авторизации от пользователей без роли admin. Примеры: "https://instance2.era-platform.ru:443", "http://192.168.100.1".

    • sg_redirect_to - опциональное поле. При заполнении корректными URL доступа к альтернативному экземпляру, во время пассивного состояния на эти адреса активного альтернативного экземпляра осуществляется переадресация всех HTTP запросов авторизации от пользователей без роли admin. Примеры: "sip:instance2.era-platform.ru:5060", "192.168.100.5:5060", "192.168.100.5".

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

  • mode - режим поведения мастера в момент старта при наличии активного слейва - ожидать деактивации слейва или перехватывать активность приоритетно.

  • name - опциональное поле, при работе сервиса не используется.

  • sync_settings_mode - режим синхронизации настроек. isolate - не синхронизировать настройки. oneway - синхронизировать настройки только в сторону пассивного слейва. bothway - синхронизировать настройки в сторону пассивного слейва и пассивного мастера. По умолчанию oneway.

  • sync_history_mode - режим синхронизации истории. isolate - не выкачивать историю с другого экземпляра. oneway - выкачивать историю только со слейва на мастер в момент активации мастера без дальнейшей подписки на изменения. bothway - дополнительно подписываться слейвом на изменение истории активного мастера. По умолчанию isolate.

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

    • default_enabled_settings - значение поля enabled для всех коллекций по умолчанию (при этом режим sync_settings_mode по умолчанию oneway).

    • default_enabled_history - значение поля enabled по умолчанию (при этом режим sync_history_mode по умолчанию isolate).

    • endpoints_of_settings - объект тонкой настройки синхронизации коллекций настроек (коллекции доменного центра и коллекции модели данных типа 'category'). Каждым ключом объекта является рест-эндпойнт конкретной коллекции, а значением - объект тонких настроек синхронизации этой коллекции. Ключи/REST-эндпойнты, не соответствующие указанным типам коллекций игнорируются.

      • enabled - выключатель обработчика синхронизации коллекции.

      • filter - дополнительный фильтр на объекты коллекции, применяется стандартный формат параметра filter REST-запроса чтения коллекции. Система в любом случае применяет фильтры к коллекциям доменного центра на поля ext.source, ext.survival_sync, а для коллекции domain/settings на поле key. Дополнительные фильтры могут лишь усилить их.

      • order - сортировка сущностей при вычитывании данных, применяется стандартный формат параметра order REST-запроса чтения коллекции. По умолчанию применяется сортировка по идентификатору и в некоторых коллекциях доменного центра по ext.ct. Это важно для организации правильной последовательности создания объектов.

      • mask - ограничение на состав полей коллекции, применяется стандартный формат параметра mask REST-запроса чтения коллекции.

      • retries - количество итераций при синхронизации коллекции при возникновении ошибок. Например может использоваться как альтернатива order при работе с наследуемой коллекцией классов.

      • portion_size - нестандартный размер порции при вычитывании данных. По умолчанию 1000, но для сценариев 100. Имеет смысл опираться на средний размер сущности.

    • endpoints_of_history - объект тонкой настройки синхронизации коллекций истории (коллекции модели данных типов 'history' и 'transactionlog'). Каждым ключом объекта является рест-эндпойнт конкретной коллекции, а значением - объект тонких настроек синхронизации этой коллекции. Ключи/REST-эндпойнты, не соответствующие указанным типам коллекций игнорируются.

      • enabled - выключатель обработчика синхронизации коллекции.

      • filter - дополнительный фильтр на объекты коллекции, применяется стандартный формат параметра filter REST-запроса чтения коллекции.

      • use_sync - выключатель операции синхронизации, не влияет на изменения по уведомлениям на основании подписки. Может использоваться для коллекций типа transactionlog в KAFKA без Clickhouse, то есть там где чтение данных невозможно, но может иметь смысл подписка на поток событий.

      • portion_size - размер порции при вычитывании данных. По умолчанию 1000, но для сценариев 100. Имеет смысл опираться на средний размер сущности.

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

Не синхронизируются объекты, создаваемые автоматически, в том числе продуктовым слоем. Это осуществляется через фильтр по полю ext.source (исключаются значения "master", "fixture", "productLayer").

Отладка

Процесс управления резервированием обслуживатеся микросервисом mware. В рамках обслуживания применяются два вида сервисов:

  • survival - применяет опции, отслеживает состояние альтернативных экземпляров, управляет состоянием локального экземпляра.

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

Включением для активной ноды mware уровня логирования TRACE или DEBUG, весь процесс слежения и синхронизации попадет в лог-журнал ноды middleware/erl_*.log .

Синхронизация коллекций производится последовательно в одном процессе/потоке и процесс может быть основательно прослежен.

На пассивном экземпляре домен не обслуживается в следующих микросервисах:

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

  • im - сервис домена полностью выгружается, не происходят обращения к серверам мессенджеров, а также не обрабатываются хуки.

  • msvc - сервис домена полностью выгружается, продуктовые микросервисы прекращают работу.

  • mware - прекращают работу сервисы домена, инициирующие активности: распределение провайдеров, запуск сценариев по расписанию, обслуживание учетных записей транков без регистрации, callmanager, devicemanager.

  • sg - блокирует определенные начальные запросы REGISTER, INVITE, SUBSCRIBE, PUBLISH. При наличии настройки sg_redirect_to осущестляет ответ с перенаправлением на адреса активного экземпляра.

  • esg - не обслуживает вызовы от аплинков по учетным записям домена, воспринимает их как "неизвестные" и поступает в соответствии с настройками. Либо ответ с отказом, либо игнорирование.

  • b2b - не осуществляет маршрутизацию в домен с помощью кросс-доменных правил. Инициирующие вызовы в домен к нему не поступают из фасадных сервисов.

  • ivr - инициирующие вызовы в домен не поступают ни из b2b, ни из callmanager.

  • conf - инициирующие вызовы в домен не поступают из b2b.

  • svc - некому запускать служебные сценарии в домене в оставшейся действующей части системы.

  • ws - при обращениях к эндпойнту сессий осуществляет отказ. Запрос создания сессии, запрос чтения сессии. При наличии настройки ws_redirect_to добавляет в ответ локацию для перенаправления на адреса активного экземпляра. Разрываются все пользовательские веб-сокет подключения к домену, а также новые подключения при попытке авторизации в домен. При этом статика возвращается нормально, система дает авторизоваться пользователям с ролью 'admin'.

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

Важно убедиться, что резервная площадка в состоянии обеспечивать полный сервис при недоступности основной:

  • все устройства регистрируются без внесения изменений в конфигурации;

  • пользователи не испытывают сложностей с подключением и авторизацией;

  • основные или резервные подключения к провайдерам телефонии обеспечивают связь по требуемым направлениям;

  • внешние сервисы при наличии обеспечивают требуемую функциональность;

  • основные эксплуатируемые сценарии успешно реализуются;

  • запись разговоров обеспечивается;

  • продуктовый слой функционирует исправно;

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

Особенности и ограничения

  • Для синхронизации у обеих систем должны совпадать: имя домена, значение полей settings.survival_options.security_key, выбранный алгоритм хеширования паролей пользователей (в конфигурации).

  • Настройки синхронизируются при старте системы/микросервиса, а также каждый час после продления подписок. Синхронизация включает предварительную сверку инкремента модификатора в каждой коллекции, и при отсутствии изменений процесс пропускается. При возможном наличии локальных изменений в коллекции на пассивном экземпляре, его данные активному не отправляются, данные активного экземпляра имеют приоритет и восстанавливаются на пассивном в течение часа. При наличии изменений производится сверка чек-сумм каждой сущности в соответствии с фильтрами и масками. Операции создания, модификации и удаления производятся на пассивном экземпляре с сущностями и вложениями.

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

  • По умолчанию не синхронизируются каналы интеграции (integration_points). Чтобы канал интеграции синхронизировался, ему необходимо явно установить ext.survival_sync = true. Такие каналы синхронизируются вместе со значениями токенов.

  • Не синхронизируются дочерние домены.

  • Не синхронизируются сущности мастер-домена: конфигурации, правила пограничного фильтра и т.д.

  • При изменении состава классов типа 'category' происходит переинициализация сервиса синхронизации данных с последующим внеочередным стартом синхронизации. При этом переустановка продуктового слоя не влияет на это, поскольку все создаваемые им классы исключаются из процесса синхронизации стандартным статическим фильтром.

  • На момент реализации существуют коллекции, сущности которых могут иметь отсылки к конфигурации. Например 'providers.serveridxs' - имеет отсылки к идентификаторам экземпляров esg в конфигурации, 'sipusers.devices' - имеет отсылки к адресам гейтов из конфигурации. Это является ограничением, и в данный момент требует отказа от синхронизации таких учетных записей, либо выставление для них масок, исключающих эти поля.

  • Для коллекций доменного центра, предполагающих вложения (roleapps, mservices, ivrscripts, svcscripts) - исключить синхронизацию вложений при синхронизации сущности невозможно.

  • История не синхронизируется, а выкачивается в интервалах неактивности. Сверки чек-сумм сущностей не происходит, а только вставка при отсутствии записи с соответствующим идентификатором. Удаления также не происходит, даже если в источнике данные удалены. Решается задача выкачивания накопленных данных за время неактивности, но не их синхронизация. Вместе с каждой записью выкачиваются и сохраняются вложения. Применяется сортировка по полю партиционирования. Вычитка и вставка производится последовательно порциями.

  • Для выкачивания и синхронизации записей разговоров требуется включенный режим сохранения истории диалогов в настройках домена (domain.settings.archive_dialogs_enabled).

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

  • Если в маске не указано поле типа 'attachment', то соответствующие вложения не выкачиваются. Аналогично с полями типа 'filelink'.

  • Процесс синхронизации происходит в один поток в одном websocket подключении последовательно. Однако настройки и история синхронизируются раздельно.

  • Чтобы активировать перенос активности обратно на восстановленный мастер экземпляр, ожидающий вывода слейса из активного состояния, можно либо в экземпляре мастера временно выставить режим settings.survival_options.mode=takeover, либо в пассивном временно отключить резервирование settings.survival_opts.enabled=false, либо иным образом временно расцепить связывание в группу резервирования.

  • Не синхронизируется никакая инфраструктурная информация, содержание каталогов на диске (кроме файлов вложений).

  • Не синхронизируются учетные записи пользователей, скопированные автоматически из мастер-домена.

  • Вложения, размещенные в полях типа attachment, при копировании попадают в файловое хранилище, настроенное для использованию в классе экземпляра системы - приемника.

  • Файлы, ссылки на которые размещены в полях типа filelink, при копировании попадают в файловое хранилище системы-приемника, доступное по оригинальному имени (тот же код хранилища и тот же путь).

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт