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

Назначение

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

Концепция

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

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

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

  5. В каждой из систем в настраиваемый домен из родительского выделить идентичное количество лицензий.

  6. В каждой из систем создать канал интеграции с привязкой к пользователю (например "System", либо другой с более тонкими настройками прав); в свойствах этих каналов интеграции открыть доступ к API эндпойнтам ('*' или более тонко). Убедиться, что каналы интеграции открывают доступ до /rest/v1/iam/users.

  7. Убедиться, что адреса серверов не находятся в черных списках правил пограничного фильтра друг у друга.

  8. Проверить взаимные доступы с каждой из систем к другой и к самой себе, осуществив CURL-запрос с использованием подготовленных токенов (например, curl -I -H "Authorization: Bearer 12345678123456781234567812345678" https://era.my-domain.org/rest/v1/iam/users?limit=1&mask=id - вызов должен вернуть код 200).

  9. Дополнительно, если резервная система ранее была настроена, то убедиться в отсутствии конфликтов по существующим сущностям:

    • по пользователям: идентификаторы, логины и email-адреса пользователей. Если в доменах есть пересечение, то его нужно устранить и привести к одной базе. Кроме того, не должно быть пересечения email-адресов у пользователей домена в обеих системах с email-адресами других учетных записей всех прочих доменов.

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

    • по каналам интеграции: привязка к учетным записям пользователей (в частности и к учетной записи System) должна гарантировать, что эти учетные записи исключены из синхронизации на обеих системах, например установить 'ext.survival_sync: false'.

  10. Дополнительно, если домен на мастер системе был создан и настроен на версиях ранее 1.9, то необходимо:

    • проапдейтить любым образом в мастер домене пользователей, копируемых в другие домены (в целевой домен).

  11. Особым образом следует отнестись к учетным записям провайдеров. В случае строгих привязок к IP-адресам конкретных серверов системы, такие учетные записи следует исключить из синхронизации (ext.survival_sync: false).

  12. Телефонные устройства и/или шаблоны автопровизии следует снабдить настройками альтернативных подключений к сип-серверам резервной системы.

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

survival_options

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

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

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

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

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

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

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

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

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

    • uris - URL веб-сервера или список из URL нескольких веб-серверов альтернативного экземпляра системы. Используется для http и websocket подключения к веб-серверу альтернативного экземпляра с целью определения доступности и синхронизации данных. Примеры: "https://instance2.era-platform.ru:443", "http://192.168.100.22". Возможные типы значений: string, array of string.

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

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

    • sg_redirect_to - опциональное поле. При заполнении корректными URI доступа к альтернативному экземпляру, во время пассивного состояния на эти адреса активного альтернативного экземпляра осуществляется переадресация всех SIP запросов. Примеры: "sip:instance2.era-platform.ru:5060", "192.168.100.22:5060", "192.168.100.23". Возможные типы значений: string, array of string.

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

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

  • 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 - выключатель обработчика синхронизации коллекции. Варианты значений: true | false.

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

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

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

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

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

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

      • enabled - выключатель обработчика синхронизации коллекции. Варианты значений: true | false.

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

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

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

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

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

Отладка

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

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

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

В коллекции /rest/v1/model/platform/monitoring/Services домена доступен объект с актуальным состоянием сервиса (поля service="survival", id="62a75cca-0196-5dbf-2cd9-7cd30a921f58"). Предоставляется следующий состав данных о состоянии (поле data):

survival_monitoring_status

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

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

  • activity - активен или пассивен домен на данном экземпляре системы.

  • active_alternative - для пассивных экземпляров отображает информацию о текущей активной альтернативе, поля: 'name', 'order', 'uri'.

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

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

  • process_status - текстовое человекочитаемое сообщение о состоянии сервиса на данном экземпляре системы.

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

  • etl_settings - объект с информацией о состоянии процесса синхронизации настроек и категорий.

    • status - текущее состояние процесса синхронизации

    • synchronize_prev_dt - дата/время завершения последней итерации синхронизации настроек и категорий.

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

    • synchronize_failed_cns - список коллекций (эндпойнтов), синхронизация которых во время последней итерации прошла с ошибкой. В этих коллекциях состав данных может отличаться от активного экземпляра.

    • synchronize_classpath - во время процесса синхронизации отображает текущий обрабатываемый эндпойнт, например "/rest/v1/iam/users" или "/rest/v1/model/callcenter/outbound/SimpleContragents".

    • synchronize_status - текущее состояние процесса синхронизации конкретной обслуживаемой в данный момент коллекции: 'initial', 'hc', 'differ', 'fin'

    • synchronize_retry - в случае переповтора отображает номер итерации

  • etl_history - объект с информацией о состоянии процесса синхронизации истории и логов транзакций.

    • status - текущее состояние процесса синхронизации

    • synchronize_prev_dt - дата/время завершения последней итерации синхронизации исторических коллекций.

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

    • synchronize_failed_cns - список коллекций (эндпойнтов), синхронизация которых во время последней итерации прошла с ошибкой. В этих коллекциях состав данных может отличаться от активного экземпляра.

    • synchronize_classpath - во время процесса синхронизации отображает путь к текущей обрабатываемой исторической коллекции, например "/rest/v1/model/callcenter/seances/ArchiveSeances".

    • synchronize_status - текущее состояние процесса синхронизации конкретной обслуживаемой в данный момент коллекции: 'initial', 'download', 'fin'

    • synchronize_retry - в случае переповтора отображает номер итерации

    • synchronize_interval_start - дата/время начала синхронизируемого интервала исторических данных конкретной обслуживаемой в данный момент исторической коллекции.

    • synchronize_interval_stop - дата/время конца синхронизируемого интервала исторических данных конкретной обслуживаемой в данный момент исторической коллекции.

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

Включением для активной ноды 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, при копировании попадают в файловое хранилище системы-приемника, доступное по оригинальному имени (тот же код хранилища и тот же путь).

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