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

32 3

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

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

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

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

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

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

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

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

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

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

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

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

База данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

Клиентские лог-файлы десктоп-клиента – хранятся на компьютерах пользователей. Пример имени лог-файла десктоп-клиента:

<Имя_комьютера>.DirectumRX.<Код систем>.<Дата>.log

Например: SERVER.DirectumRX.DEMO.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. Определите политику хранения созданных архивов.

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

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

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

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

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

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

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

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

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

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

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

<var name="AUTHENTICATION_PASSWORD" value="0z$Ede" />

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

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

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

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

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

Андрей Девятьяров

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

Интересно, проверяли на практике следующую ситуацию:

В ФХ есть жизненный цикл данных: transient (незафиксированные), persistent (долгоживущие), deleted (помеченные на удаление).

Если в ФХ есть тело документа в состоянии persistent, т.е. какая-то сущность в системе ссылается на эти данные. Эта ссылочная информация хранится в БД. Далее, БД восстановили из бэкапа, и этой ссылочной информации в БД не стало. Удалятся ли такие данные из ФХ автоматически? Или сервис хранилищ будет их игнорировать, т.к. они persistent.

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

Андрей Девятьяров: обновлено 22.06.2020 в 17:29
Станислав Зыкин

Андрей, если я правильно понял суть Вашего сообщения, то ответ нет. Эти данные не удалятся.

В любом случае, восстановление данных из резервной копии - нештатная ситуация. Поэтому в данной ситуации риск получить "мусор" в ФХ, ИМХО, оправдан.

Немного дополню статью Дмитрия: после восстановления БД и ФХ из резервной копии необходимо под пользователем с правами администратора в системе Directum RX запустить фоновый процесс "Контроль целостности версий документов". после запуска будет снята пометка на удаление "ошибочно" помеченных тел документов. Это дополнительные меры предосторожности.

Станислав Зыкин

Про резервное копирование от себя могу добавить, что рекомендуется придерживаться правила 3-2-1:

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

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

В идеальной картине мира правило расширяется до 3-2-1-0, где 0 означает "0 ошибок". Т.е. для контроля целостности бэкапы должны регулярно где-то разворачиваться и администратор должен контролировать, что не нарушена физическая или логическая целостность резервной копии.

Станислав Зыкин: обновлено 23.06.2020 в 11:02

Авторизуйтесь, чтобы написать комментарий