Рекомендации для начинающего администратора Directum RX

Итак, вы стали администратором системы Directum RX, которая установлена локально. С чего же стоит начать? В статье расскажем основные рекомендации для начинающего администратора, который будет заниматься поддержкой стабильности и производительности системы.

Шаг 1. Изучите архитектуру системы

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

Кратко зафиксируем здесь основные моменты:

• в основе Directum RX лежит функциональная масштабируемая платформа Sungero, архитектура которой позволяет работать локально и в облаке;
• платформа имеет трехзвенную архитектуру Клиентские приложения – Сервер приложений – Хранилище данных. Такая архитектура обеспечивает безопасность системы. Сотрудники не имеют прямого доступа к базе данных, так как все запросы осуществляются через сервер приложений, веб-сервер или сервер NOMAD. Клиентские приложения Directum RX взаимодействуют с сервером приложений по защищенному протоколу HTTPS;
• в отличие от монолитных систем, в состав платформы Sungero входят микросервисы – это независимые сервисы, каждый из которых выполняет определенную узкоспециализированную задачу. Например, сервис планировщика периодически инициирует только запуск фоновых процессов системы;
• за состоянием сервисов следит Агент управления сервисами (ServiceRunner) – служба Windows, следит за работой сервисов и своевременно запускает их, автоматически обновляет или останавливает. Обеспечивает бесперебойную работу сервисов, если один или несколько из них выходят из строя. Регулярно проверяет конфигурационные файлы сервисов и в случае их изменения перезапускает сервисы.

Благодаря использованию микросервисов обеспечивается:

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

Подробно архитектура системы описана в справке.

Шаг 2. Подумайте о будущем – настройте бэкапы

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

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

Далее рассмотрим отдельно особенности и рекомендации по резервному копированию БД и ФХ.

База данных

Резервное копирование и восстановление БД осуществляется средствами СУБД. Поддерживается работа с Microsoft SQL Server и PostgreSQL. В зависимости от используемой СУБД могут использоваться разные варианты: полное, разностное резервное копирование, резервное копирование журнала транзакций.

Выбор плана и стратегии резервного копирования базы данных Directum RX зависит от множества факторов, например, размера БД, приемлемого объема потери данных и активности работы с системой. Для обеспечения минимального достаточного уровня сохранности данных рекомендуется выполнять один из видов резервного копирования ежедневно. Пример реализации плана резервного копирования приведен в разделе справки «Стратегии резервного копирования».

Рекомендации по хранению резервных копий

• храните резервные копии (бэкапы) на физическом носителе, отличном от того, где размещена исходная БД. Бессмысленно хранить резервные копии на том же диске, на котором расположена рабочая БД. В случае выхода из строя физического носителя, вы потеряете как БД, так и ее резервные копии;
• целесообразно хранить несколько экземпляров бэкапов на разных носителях;
• полезно разнести хранилища бэкапов по разным помещениям или даже зданиям – на случай локальных затоплений, пожаров. Как минимум стоит разнести сервер с бэкапами и продуктивный сервер по разным кабинетам.

Восстановление БД из резервных копий

• перед восстановлением остановите все пулы приложений Directum RX и DrxServiceRunner. После окончания работ вновь запустите;
• всегда стоит помнить о том, что данные системы также хранятся и в файловом хранилище. Поднятие БД из бэкапа никак не затрагивает данные ФХ. Если их тоже нужно «откатить», то это надо делать дополнительно к работам с БД;
• если БД восстанавливается на новом сервере или сменилось ее имя, то после восстановления необходимо обновить информацию о подключении к БД в кроссплатформенном инструменте Directum Launcher;
• если восстановление БД сопровождается изменением аппаратных параметров сервера, например, сменился диск или сервер, то систему нужно заново зарегистрировать новым регистрационным ключом, ключ запросить в службе поддержки Directum.

Файловое хранилище

Файловые хранилища представляют собой обычные папки в операционной системе, поэтому в качестве инструмента для создания бэкапов ФХ можно использовать любые средства резервного копирования файлов, например, штатную консольную программу RoboCopy.

В справке есть раздел «Резервное копирование файлового хранилища». В нем предлагается использовать стандартный компонент Microsoft Windows «Система архивации данных Windows Server».

Рекомендации по частоте создания бэкапов ФХ, месту их хранения те же, что и для бэкапов БД. Они были перечислены выше.

Восстановление ФХ из резервной копии

• ФХ работает под управлением сервиса хранилищ. Перед восстановлением сервис хранилищ необходимо остановить;
• после восстановления ФХ из резервной копии необходимо убедиться, что в конфигурационном файле сервиса хранилищ указана правильная папка ФХ;
• восстановление ФХ из бэкапа стоит производить совместно с восстановлением БД. При этом стоит использовать максимально близкие по времени создания экземпляры бэкапов БД и ФХ.

Допустимо использовать более поздние бэкапы ФХ с более ранними бэкапами БД. Если в базе данных не будет информации о телах документов (версиях), которые есть в файловом хранилище, то эти файлы в ФХ просто не будут использоваться.

Обратная ситуация, когда в ФХ нет файлов для версий документов, которые есть в БД, может привести к ошибкам в работе с этими документами.

Шаг 3. Организуйте наблюдение

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

• решение «Мониторинг системы Directum RX» для контроля состояния системы и окружения, в котором она работает. Решение наглядно отображает ключевые показатели технического состояния системы: метрики производительности серверов, статистику использования системы, ошибки в разрезе служб. Решение предоставляется бесплатно (при наличии действующего абонемента) по запросу в службу поддержки.

Точки контроля, по-крупному:

• •  
  • работоспособность серверов, сервисов;
  • загрузка CPU. Постоянное нахождение нагрузки на CPU в пиковом диапазоне – признак того, что система не справляется с нагрузкой, не имеет «запаса прочности»;
  • расход ОЗУ. Анализируется аналогично CPU;
  • свободное место на дисках. Отсутствие места на дисках может приводить к выключению сервера.
• панель управления Kibana и веб-интерфейс RabbitMQ для мониторинга работы полнотекстового поиска документов, задач и заданий;
• список «Фоновые процессы» для мониторинга и состояния процессов, которые запускаются в системе по заданному расписанию. Например, процессы для рассылки уведомлений о завершении сроков действия договоров или для автоматической выдачи прав доступа на документы;
• лог-файлы, в которые записываются сообщения об ошибках, предупреждениях и информационные сообщения, появившиеся во время работы.

Работа с лог-файлами

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

Есть несколько видов лог-файлов.

Серверные лог-файлы – место сохранения лог-файлов указано в параметре LOGS_PATH в конфигурационном файле config.yml. Пример имени серверного лог-файла:

<Имя_сервера>.<Наименование серверной компоненты>.<Дата>.log

Например: SERVER.WebServer.2020-05-28.log

Remote-логирование (веб-клиент) – передача клиентских логов на сервер c целью собрать ошибки клиентов и статистику времени выполнения операций. Логи сохраняются на сервере в настроенную папку, в которой логи разделяются по файлам. Сообщения, которые логируют программный код клиента, накапливаются и передаются пачками, по умолчанию по 100 штук. Исключение составляют сообщения о том, что пользователь разлогинился, они отправляются сразу же. Пример имени лог-файла веб-клиента:

<ip-адрес>.WebClient.<Код системы>.<Дата>.log

Например: 37-235-64-229.WebClient.DirectumRX.2020-05-28.log

В случае, если в клиентском лог-файле встретилась какая-либо «общая ошибка», например, «Внутренняя ошибка сервера», либо ее текст непонятен, необходимо:

• зафиксировать время воспроизведения ошибки;
• просмотреть все серверные лог-файлы за последний день.

При обращении в службу поддержки с какой-либо ошибкой необходимо сообщить указанные выше данные.

Рекомендации по хранению лог-файлов

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

• не храните лог-файлы на дисках, где находятся файлы операционной системы, исполняемые файлы программ. Выделите для логов отдельные диски. В случае переполнения этих дисков Directum RX просто перестанет писать новые логи. Работа ОС, программ при этом не пострадает.
• настраивать хранение логов нужно отдельно для каждого серверного компонента Directum RX в их конфигурационных файлах;
• во избежание переполнения папок с логами настройте регулярные процедуры их архивирования, очистки, переноса на другие диски с обеспечением ротации хранимых данных. Например, напишите скрипты на PowerShell. Определите политику хранения созданных архивов.

Расположение текстовых лог-файлов можно менять в конфигурационном файле config.yml. Подробно можно посмотреть в разделе справки «Лог-файлы во время работы».

Шаг 4. Настройте учетные записи

Ну и перед тем, как приступить к настройке системы, нужно подготовить учетные записи. После установки в Directum RX появится несколько учетных записей для системных пользователей. Рассмотрим их подробнее.

Administrator. Администратор системы, под которым выполняется первоначальная настройка системы. Для входа в Directum RX используйте пароль, который был указан при установке системы. После этого:

• создайте записи в справочнике «Сотрудники» и учетные записи для администраторов системы;
• включите необходимых сотрудников в предопределенную роль «Администраторы»;
• дальнейшую настройку системы выполняйте от имени созданных сотрудников. В целях безопасности работу под пользователем Administrator рекомендуется сократить до минимума или совсем закрыть пользователя, и дальнейшую настройку вести уже от имени своего администратора.

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

Integration Service. Учетная запись для сервиса интеграции. Смените пароль пользователя, если планируете использовать интеграцию, например, с 1С. Если интеграция не нужна, то закройте запись данного пользователя.

Итак, в целях безопасности проверьте перечисленные учетные записи для системных пользователей. Для Adviser и Integration Service смените пароли, если они будут использоваться, иначе их нужно закрыть. Учетную запись Administrator закройте и настраивайте систему от своего администратора, с другим логином и паролем.

Кроме того, есть еще Service User. Учетная запись, под которой будут работать сервисы Workflow, сервис предпросмотра, сервис планировщика и другие. Задается на этапе установки системы, если было выбрано значение Использовать стандартную учетную запись «Service User». В дальнейшем не рекомендуется менять пароль данной учетной записи. Но, если по каким-то причинам вы изменили пароль, то нужно доработать конфигурационный файл config.yml. Параметры:

<var name="AUTHENTICATION_USE_THREAD_IDENTITY" value="false" />

<var name="AUTHENTICATION_USERNAME" value="Service User" />

<var name="AUTHENTICATION_PASSWORD" value="***" />

Перед тем, как изменить конфиг, нужно остановить сервисы командой do all down. После сохранения изменений сервисы надо запустить командой do all up.

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

И напоследок рекомендации к надежности пароля:

• пароль не должен содержать имя учетной записи пользователя или какую-либо его часть;
• пароль должен иметь длину не менее 6 знаков;
• пароль должен содержать знаки трех из четырех перечисленных ниже категорий:
  • латинские заглавные буквы (от A до Z);
  • латинские строчные буквы (от a до z);
  • цифры (от 0 до 9);
  • символы (например, !, $, #, %, ').

На этом все, используйте рекомендации в своей работе, а также делитесь в комментариях к статье своими рекомендациями и вариантами настройки.