Москва 2019
Руководство
администратора
«Электронная система документооборота для
организаций Госкорпорации «Росатом»
I СОДЕРЖАНИЕ
I СОДЕРЖАНИЕ 2
II ТЕРМИНЫ И СОКРАЩЕНИЯ 4
III ВВЕДЕНИЕ 6
1. Общие сведения 6
2. Назначение 6
IV УСЛОВИЯ ПРИМЕНЕНИЯ 8
1. Требования к техническому обеспечению 8
1.1. Описание технического обеспечения 8
1.1.1. Техническое обеспечение 8
1.1.2. Требования к оборудованию рабочих станций 8
1.1.3. Требования к пропускной способности каналов связи 8
1.2. Требования к ПО 8
1.2.1. Требования к системному ПО рабочих станций 8
1.2.2. Требования к ПО серверного оборудования 9
1.3 Требования к квалификации обслуживающего персонала 10
V СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ 11
1. Учетные записи на серверах для установки и администрирования 11
2. Установка и настройка ПО 11
2.1. Окружение для установки ПО 11
2.2. Установка и настройка системного ПО 14
2.3. Установка и настройка прикладного ПО 15
2.4. Установка и настройка клиентского ПО 22
3. Операции по обслуживанию 22
3.1. Мероприятия по текущему обслуживанию комплекса 22
3.2. Регламентные работы 28
3.3. Обновление комплекса 41
3.4. Мониторинг ЕОСДО 44
4. Ошибки работы системы и способы их устранения 45
4.1. Вход в Систему невозможен из-за ввода неправильного имени пользователя 45
4.2. Отображение окна сертификата при работе с Системой 45
4.3. Возможные ошибки при возобновлении работы с Системой после временного
интервала 45
4.4. Возможные ошибки при возврате на предыдущую страницу браузера с
помощью кнопки Back 46
4.5. Возможные ошибки при открытии файлов 46
5. Аварийные ситуации и действия по их устранению 48
5.1. Восстановление работоспособности ЕОСДО 51
3
6. Список Job и их параметры 56
6.1. Системные сервисы (JOB) и расписание их запуска 56
6.2. Параметры системных сервисов (JOB) 60
VI Техническое решение по созданию, установке и настройке отдельной
инсталляции системы ЕОСДО на основе существующего решения 70
1.1 Термины, сокращения и определения 70
1.2 Цель технического решения 71
2 ПРИНЦИПЫ СОЗДАНИЯ ОТДЕЛЬНОЙ ИНСТАЛЛЯЦИИ 71
3 ПЕРЕНОС МОДЕЛИ ДАННЫХ DOCUMENTUM 72
4 ПЕРЕНОС СПРАВОЧНЫХ ОБЪЕКТОВ 73
5 ОПИСАНИЕ УТИЛИТЫ WASABI 74
6 ПЕРЕНОС ЭЛЕМЕНТОВ СТРУКТУРЫ БАЗЫ ДАННЫХ 76
2 7. НАСТРОЙКА РЕПОЗИТОРИЯ DOCUMENTUM 79
8. СОЗДАНИЕ СИСТЕМНЫХ НАСТРОЕК ЕОСДО 79
9. ДОБАВЛЕНИЕ КОНФИГУРАЦИИ ДЛЯ ЛАНДШАФТА СИСТЕМЫ В КОД 79
VII ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ 80
4
II ТЕРМИНЫ И СОКРАЩЕНИЯ
В данном документе использованы следующие термины и сокращения (Таблица 1).
Таблица 1. Термины/сокращения и определения
Термины/Сокращ
ения
Определения
АРМП Автоматизированное рабочее место пользователя
ЕОСДО Единая отраслевая система электронного документооборота
ЖЦ Жизненный цикл
ПО Программное обеспечение
ПП Полнотекстовый поиск
Сервлет Специализированный механизм Java (Java-интерфейс),
используемый для создания WEB ресурсов, реализация которого
расширяет функциональные возможности сервера, и
взаимодействующий с клиентом посредством принципа запрос-
ответ.
СУБД Система управления базами данных
ТП Техническая поддержка
ЦПП Центр поддержки пользователей
ГК «Росатом» Государственная корпорация по атомной энергии «Росатом»
ДЗО Дочерние и зависимые общества
Ландшафт;
Системный
ландшафт
Группа взаимосвязанных систем, объединенных по признаку
функционального предназначения. В рамках данного Проекта
системные ландшафты могут быть представлены следующими
группами: разработка, тестирование, продуктив.
Перенос функциональности между ландшафтами Системы
осуществляется путем переноса релиза.
ОШС Организационно-штатная структура
Проект Проект «Система электронного документооборота для организаций
Госкорпорации «Росатом»»
Репозиторий Место, где хранятся и поддерживаются данные системы
Система ЕОСДО
ТЗ Техническое задание на выполнение работ по проекту «Система
электронного документооборота для организаций Госкорпорации
«Росатом»»
5
ТР Техническое решение по созданию, установке и настройке
отдельной инсталляции системы ЕОСДО на основе существующего
решения
ЦОД Центр обработки данных ГК «Росатом»
ФИО Фамилия, имя и отчество
6
III ВВЕДЕНИЕ
1. Общие сведения
Полное наименование системы:
Единая отраслева система электронного документооборота
Обозначение:
ЕОСДО, Система
2. Назначение
Система электронного документооборота (далее – ЕОСДО) предназначена для
организации процесса распределенного документооборота между организациями ГК «Росатом,
автоматизации процессов и процедур документационного обеспечения управления, обеспечения
защиты и сохранности документов. Функциональность системы реализована в объеме следующих
сценариев:
Cценарий № 01 (Обеспечение распорядительной деятельности)
Cценарий № 02.1 (Обеспечение деятельности коллегиальных органов управления дочерних и
зависимых обществ (ДиЗО))
Cценарий № 02.2 (Обеспечение деятельности коллегиальных органов управления в части
заседаний органов управления)
Cценарий № 03 (Доверенности)
Cценарий № 04 (Договорная работа)
Cценарий № 05 (Внешняя и внутренняя переписка)
Cценарий № 05.1 (Сквозная переписка между предприятиями отрасли)
Cценарий № 06 (Архивная работа)
Cценарий № 08 (Лицензии и сертификаты)
Cценарий № 09 (Судебно-претензионная работа)
Cценарий № 10 (Архив бухгалтерских документов) (Сделки, Captiva)
Cценарий № 12 (Объекты интеллектуальной собственности)
Cценарий № 13 (Взаимодействие ЕОСДО с системой МЭДО)
Cценарий № 14 (Контроль безопасности ЯРОО организаций Госкорпорации Росатом)
Cценарий № 16 (Корпоративная информация)
Cценарий № 17 (Электронный архив документации для учета основных средств)
Cценарий № 18 (Листы исполнения)
7
Cценарий № С1 (Контроль исполнения поручений)
Cценарий № С2 (Общие правила создания и согласования проектов документов)
Cценарий № С3 (Делегирование полномочий и организация прав доступа)
Cценарий № С4 (Управление стандартами, классификаторами и шаблонами, описание
интерфейсов)
Cценарий № С5 (Обработка в ЕОСДО документов, составляющих коммерческую тайну и
служебную тайну)
Cценарий № С6 (Поиск информации и формирование отчетов)
Cценарий № С7 (Интеграция с ЭЦП)
Cценарий № С9 (Рабочее место Генерального директора и его заместителей)
Cценарий интеграционный ЕОСДО с ЕОС - Закупки в части договорной работы
В данном документе описано руководство для технического обслуживания и
администрирования системы.
8
IV УСЛОВИЯ ПРИМЕНЕНИЯ
1. Требования к техническому обеспечению
1.1. Описание технического обеспечения
1.1.1. Техническое обеспечение
Описание технического обеспечения системы изложено в документе «Техническое
решение по созданию, установке и настройке отдельной инсталляции системы ЕОСДО на основе
существующего решения».
1.1.2. Требования к оборудованию рабочих станций
Типовой комплект оборудования рабочей станции пользователя системы должен
удовлетворять следующим минимальным требованиям:
процессор с тактовой частотой 1 ГГц;
объем свободной оперативной памяти (ОЗУ) − 1024 МБ;
объем свободного дискового пространства − 4 ГБ;
монитор и видеокарта с поддержкой разрешения 1280х1024 пикселей;
сетевая карта − 100 Мб/с;
клавиатура;
манипулятор «мышь».
1.1.3. Требования к пропускной способности каналов связи
Каналы связи между серверами должны быть обеспечены с пропускной способностью не
менее 1Гб/с
Каналы связи от конечных пользователей системы до серверной группы системы
долджны быть обеспечены с пропускной способностью не менее 256Кб/с на одного пользователя,
при средней задержке не более 50мс.
1.2. Требования к ПО
1.2.1. Требования к системному ПО рабочих станций
К системному ПО рабочих станций предъявляются следующие требования:
операционная система (ОС) Microsoft Windows 7/8.1/10;
9
обозреватель Internet Explorer 11, обозреватель Chrome версии 56.
1.2.2. Требования к ПО серверного оборудования
Таблица 3. Общие требования к ПО
Роль сервера Используемое системное и прикладное программное обеспечение
Серверы
приложений RedHat Enterprise Linux v.7 Update-5 x86_64;
IBM WebSphere 8.5 (8.5.5.15);
OpenText Documentum Administrator 16.4;
OpenText Webtop 6.8.2.
Серверы Shark
(Метод серверы)
RedHat Enterprise Linux v.7 Update-5 x86_64;
IBM WebSphere 8.5 (8.5.5.15);
ActiveMQ 5.15.8;
Oracle JDK 8.0.212;
MongoDB 4.0
Серверы контента RedHat Enterprise Linux v.7 Update-5 x86_64;
Oracle Database Client 12 (12.1);
OpenText Documentum Content Server 16.4;
Сервер
индексирования RedHat Enterprise Linux v.7 Update-5 x86_64;
OpenText xPlore 16.4;
Сервер СУБД RedHat Enterprise Linux v.7 Update-5 x86_64;
Oracle Database 12 (12.1)
Балансировщики
нагрузки RedHat Enterprise Linux v.7 Update-5 x86_64;
Nginx 1.14;
Nginx-sync;
keepalived
Серверы
хранения данных RedHat Enterprise Linux v.7 Update-5 x86_64;
RedHat Cluster suite;
NFS Server
10
1.3 Требования к квалификации обслуживающего персонала
Для эксплуатации системы предполагается наличие нескольких типов (ролей)
Администраторов Системы:
Системный администратор;
Администратор БД (Oracle DBA);
Администратор сервера приложений IBM WebSphere Application Server;
Администратор OpenText Documentum;
Прикладной администратор.
Один и тот же специалист может совмещать несколько типов (ролей) администраторов.
Системные Администраторы должны обладать следующими навыками:
администрирование ОС Linux – в рамках сертифицированных курсов;
администрирование ОС Windows – в рамках сертифицированных курсов;
администрирование платформы виртуализации VMware – в рамках
сертифицированных курсов;
администрирование системы резервного копирования – в рамках
сертифицированных курсов.
Администраторы БД (Oracle DBA) должны обладать следующими навыками:
администрирование СУБД Oracle 11/12 – в рамках сертифицированных курсов;
диагностика производительности СУБД – в рамках сертифицированных курсов.
Администраторы сервера приложений IBM WebSphere Application Server должны обладать
следующими навыками: администрирование серверов приложений IBM WebSphere Application
Server в кластерной конфигурации – в рамках сертифицированных курсов.
Администраторы OpenText Documentum, прикладные администраторы должны обладать
следующими навыками:
администрирование платформы OpenText Documentum – в рамках
сертифицированных курсов;
администрирование СУБД Oracle 11/12 – в рамках сертифицированных курсов.
11
V СИСТЕМНОЕ АДМИНИСТРИРОВАНИЕ
1. Учетные записи на серверах для установки и администрирования
Для установки и администрирования необходимо создать следующие учетные записи:
ibm – учетная запись, владелец установки серверов приложений, сервера федеративного обмена и
сервереа очередей
oracle – учетная запись, владелец установки сервера СУБД
dmadmin – учетная запись, владелец установки контент-серверов
2. Установка и настройка ПО
2.1. Окружение для установки ПО
Для установки базового программного обеспечения необходим обеспечить наличие
следующих библиотек и пакетов:
Для сервера СУБД:
inutils-2.23.52.0.1-12.el7.x86_64
compat-libcap1-1.10-3.el7.x86_64
compat-libstdc++-33-3.2.3-71.el7.i686
compat-libstdc++-33-3.2.3-71.el7.x86_64
gcc-4.8.2-3.el7.x86_64
gcc-c++-4.8.2-3.el7.x86_64
glibc-2.17-36.el7.i686
glibc-2.17-36.el7.x86_64
glibc-devel-2.17-36.el7.i686
glibc-devel-2.17-36.el7.x86_64
ksh
libaio-0.3.109-9.el7.i686
libaio-0.3.109-9.el7.x86_64
libaio-devel-0.3.109-9.el7.i686
libaio-devel-0.3.109-9.el7.x86_64
libgcc-4.8.2-3.el7.i686
libgcc-4.8.2-3.el7.x86_64
12
libstdc++-4.8.2-3.el7.i686
libstdc++-4.8.2-3.el7.x86_64
libstdc++-devel-4.8.2-3.el7.i686
libstdc++-devel-4.8.2-3.el7.x86_64
libXi-1.7.2-1.el7.i686
libXi-1.7.2-1.el7.x86_64
libXtst-1.2.2-1.el7.i686
libXtst-1.2.2-1.el7.x86_64
make-3.82-19.el7.x86_64
sysstat-10.1.5-1.el7.x86_64
Для контент-сервера:
xorg-x11-font-utils.x86_64
xorg-x11-fonts-100dpi.noarch
xorg-x11-fonts-75dpi.noarch
xorg-x11-fonts-Type1.noarch
xorg-x11-xauth.x86_64
libX11.x86_64
dbus-x11.x86_64
xorg-x11-server-utils.x86_64
xorg-x11-xkb-utils.x86_64
xterm xorg-x11-xauth
xorg-x11-utils
xorg-x11-fonts-*
xorg-x11-apps
xorg-x11-server-Xorg
libXp gcc make setarch
libaio glibc-devel glibc.i686
libXp.so.6 libXt.so.6
libXtst.so.6
compat-libstdc++-33.x86_64
binutils elfutils-libelf
elfutils-libelf-devel
glibc
glibc-common
13
glibc-devel
glibc-headers
gcc
gcc-c++
libaio-devel
libaio
libgcc
libstdc++
make
sysstat
unixODBC
unixODBC-devel
unzip
glibc-devel.i686
libgcc.i686
binutils
compat-db
libstdc++
gdbm
make
ksh
libaio-devel
libXtst
xorg-x11-utils
openmotif
openmotif.i686
libaio.i686 l
ibaio-devel.i686
compat-glibc.x86_64
compat-libcap1
dejavu-fonts-common.noarch
dejavu-sans-fonts.noarch
Для сервера приложений:
gtk2
14
libXtst
xorg-x11-fonts-Type1
psmisc
2.2. Установка и настройка системного ПО
Перед установкой ПО системы необходимо выполнить установку и настройку системного
ПО в соответствии с документацией производителей.
2.2.1. Предварительные требования
2.2.1.1. Сервер СУБД
На сервере СУБД должно быть установлено ПО Oracle Database Server 12c (12.1) и создан
экземпляр базы данных в режиме DEDICATED со следующими параметрами:
NLS_CHARACTERSET = AL32UTF8;
open_cursors = 600; (мимнимальное рекомендованное значение)
cursor_sharing = FORCE;
Рекомендуется увеличить размер каждого журнального файла Redo Log до 512 MБ.
2.2.1.2. Резервный сервер СУБД
На резервный сервер СУБД должно быть установлено ПО Oracle Database Server 12c
(12.1).
Настройка сервера горячего резервирования осуществляется согласно инструкции Oracle
Database 12c Release 1 Data Guard Concepts and Administration
2.2.1.3. Сервер контента
На сервере контента необходимо установить ПО Oracle Database Client 12.1и OpenText
Documentum Content Server 16.4 согласно инструкции OpenText Documentum Content Server
Installation Guide (Version 16.4). В репозитории настроены подключения к нужным серверам
LDAP, необходимым для осуществления аутентификации средствами Microsoft Active Directory
(см. OpenText Documentum Content Server Administration Guide).
2.2.1.4. Сервер приложений и метод сервер.
На сервере приложений должно быть установлено ПО IBM WebSphere 8.5.5.15.
Необходимо создать отдельные экземпляры сервера для каждой из нод. Развернут инстанс
ActiveMQ. Для работы сервисов федерации должна быть развернута MongoDB 4.0.
2.2.1.5. Сервер индексирования
Должно быть установлено ПО OpenText xPlore 1.6 согласно инструкции OpenText
Documentum Content Server Fulltext Indexing System Installation and Administration Guide, должен
быть создан агент индексирования, настроенный для работы с репозиторием на сервере контента.
15
2.2.1.6. Сервер балансировки нагрузки
Должно быть установлено ПО Nginx 1.14 с модулем nginx-sticky-module.
2.3. Установка и настройка прикладного ПО
2.3.1. Предварительные требования
Необходимо установить и настроить базовое системное ПО согласно документации,
предоставляемой поставщиком системного ПО (ОС, требуемые версии пакетов и т.д.).
2.3.2. Системные конфигурационные файлы
Конфигурационные файлы системы автоматически пакуются при сборке внутрь war-
приложений, дополнительное конфигурирование не требуется. Способ сборки приложения
исключает необходимость дополнительной ручной настройки.
Конфигурационные файлы прикладного ПО, уникальные для каждой из площадок,
расположены на серверах, указанных в Таблице 4.
Таблица 4. Конфигурационные файлы прикладного ПО.
Сервер Путь Параметры
Контент
серверы
/dm/имя_репозитор
ия/dba/config/rosato
m_mb/server.ini
[SERVER_STARTUP]
docbase_id =ID репозитория (уникален для
каждого репозитория)
docbase_name = имя репозитория
server_config_name = имя конфигурации
репозитория
database_conn = подключение к СУБД
database_owner = имя владельца репозитория
database_password_file = путь к
зашифрованному паролю СУБД
service = имя сервиса репозитория в ОС
[DOCBROKER_PROJECTION_TARGET] –
параметры проецирования репозитория на
докброкеры плошадки
Подробнее в OpenText Documentum Content
Server Version 16.4 Administration and
Configuration Guide
dm/oracle/product/12
.1.0/client_1/network
/admin/tnsnames.ora
Параметры подключения репозитория к
СУБД
16
Сервер Путь Параметры
/dm/имя_репозитор
ия/shared/config/dfc.
properties
Конфигурация DFC сервисов
dfc.data.dir= каталог с данными dfc, создается
автоматически при наличии прав при установке или
может быть указан вручную
dfc.tokenstorage.dir= путь к ключу безопасности dfc
клиента, создается при обращении клиента к
репозиторию, при установке или может быть указан
вручную
dfc.tokenstorage.enable=false
dfc.docbroker.host[0]= адрес хоста, на котором
развернуто ПО Documentum, где работает докброкер
репозитория
dfc.docbroker.port[0]= порт докброкера репозитория
dfc.docbroker.host[1]=адрес хоста, на котором
развернуто ПО Documentum, где работает докброкер
репозитория, используется при наличии
многосерверной конфигурации
dfc.docbroker.port[1]=порт докброкера репозитория,
используется при наличии многосерверной
конфигурации
dfc.crypto.repository= наименовение репозитория,
который осуществляет криптозащиту dfc клиентов
dfc.session.secure_connect_default= параметры
подключения, используется умолчание
dfc.globalregistry.repository= наименование
репозитория, являющегося global registry
dfc.globalregistry.pass = зашифрованный пароль
пользователя global registry
Подробнее в Documentum Foundation Classes 16.4
Development Guide и OpenText Documentum Content
Server Version 16.4 Administration and Configuration
Guide
17
Сервер Путь Параметры
Серверы
полнотекстового
поиска
/fti/xPlore/config/ind
exserverconfig.xml
/fti/xPlore/dsearch/
Конфигурация сервисов полнотекстового
поиска, подробнее см. в OpenText ™
Documentum® xPlore Version 16.4
Administration and Development Guide
Серверы Shark /etc/mongod.conf Параметры конфигурации сервисов
федеративного обмена
/opt/app/activemq/co
nf
Серверы
балансировки
нагрузки
/usr/local/nginx/ngin
x.conf
Конфигурация балансировки нагрузки Nginx
Описание сборок и основных конфигурационных файлов
Для упаковки правильных конфигурационных файлов в артефакты приложений системы
используется система профилей maven. Для каждого стенда создан отдельный сборочный
профиль:
devmb – для стенда разработки
testmb – для стенда тестирования
prodmb – для продуктивного стенда.
Для каждого профиля в коде системы хранится набор конфигурационных файлов, которые
пакуются в артефакты приложений Системы. Пароли от учетных записей не хранятся в системе
контроля версий и передаются maven как параметры сборки (через -D):
env.eosdo.jdbc.password – пароль пользователя базы данных
env.dfc.globalregistry.password – пароль пользователя общего реестра репозитория
env.SUPERUSER_PASSWORD – пароль администратора основного репозитория
env.RepositoryOwnerPassword – пароль администратора основного репозитория
env.archiveRepositoryPassword – пароль администратора архивного репозитория
Основные конфигурационные файлы, содержащие информацию о Системе:
Имя
файла
Расположение в war-
файле Свойство Описание
dfc.properties \WEB-
INF\classes\dfc.properties
dfc.docbroker.host Ip доброкера
репозиториев
18
Имя
файла
Расположение в war-
файле Свойство Описание
dfc.docbroker.port Порт
докброкера
репозиториев
dfc.globalregistry.repository Имя
основного
репозитория
dfc.globalregistry.username Имя
пользователя
общего
реестра
репозитория
dfc.globalregistry.password Пароль
пользователя
общего
реестра
репозитория
common.pr
operties
\WEB-
INF\classes\common.properties
SUPERUSER_PASSWOR
D
пароль
администрато
ра основного
репозитория
SUPERUSER_LOGIN имя
администрато
ра основного
репозитория
Repository.
properties
\WEB-
INF\classes\ksed\Repository.
properties,
\WEB-
INF\classes\eosdo\Repository
.properties
\WEB-
INF\classes\archive\Reposito
ry.properties
repositoryOwnerUserName пароль
администрато
ра основного
репозитория
repositoryOwnerPassword имя
администрато
ра основного
репозитория
archiveRepositoryPassword пароль
администрато
ра архивного
репозитория
19
Имя
файла
Расположение в war-
файле Свойство Описание
repositoryName Имя
основного
репозитория
archiveRepositoryName Имя
архивного
репозитория
2.3.3. Логирование, описание и настройка
2.3.3.1. Основные понятия
2.3.3.1.1. Понятие аппендера (Appender)
Аппендер – класс, часть подсистемы логирования, отвечающая за вывод лога во
внешнюю систему (например, файл, БД).
В ЕОСДО используется подход, при котором логи выгружаются в файл и аппендеры в
данной конфигурации отвечают за:
организацию в файловой системе (ежедневное архивирование как заданное
ограничение на содержание данных в одном файле);
кодировку;
форматирование сообщений;
фильтрацию входящих сообщений по уровню.
2.3.3.1.2. Понятие логгера (Logger)
Логгер – подсистема заполнения журналов событий (логирование), которая принимает
сообщения из системы и перенаправляет их соответствующим аппендерам.
2.3.3.1.3. Уровни логирования
Ниже приведен перечень уровней логирования, отсортированных по важности в порядке ее
возрастания:
TRACE;
DEBUG;
INFO;
WARN;
ERROR;
FATAL.
20
2.3.3.1.4. Файлы логов (аппендеры ЕОСДО)
Уровень лога файла указывает на уровень важности логов, попадающих в файл. Ниже
приведен перечень названий файлов и масок названий файлов, в которых хранятся логи
соответствующего уровня важности:
1) log4j.log – корневой файл с логами, принимает сообщения со всех логгеров.
Уровень логов, находящихся в файле – WARN.
2) trace.log – файл, в котором хранятся логи с уровнем TRACE и выше.
3) debug.log – файл, в котором хранятся логи с уровнем DEBUG и выше.
4) info.log – файл, в котором хранятся логи с уровнем INFO и выше.
5) warn.log – файл, в котором хранятся логи с уровнем WARN и выше.
6) *.log – файл с логами, специфичными для какого-либо функционального модуля.
Уровень логов обычно достаточно низкий (ALL | TRACE | DEBUG).
7) *.<Дата> - сохраненный файл с логами за указанную дату.
2.3.3.1.5. Логгеры системы
1) Любые логи, порождаемые классами системы, направляются в базовые аппендеры
(trace.log, debug.log, info.log, warn.log). Уровень логов, как правило, ограничивается INFO.
8) Любые логи, порождаемые классами системы и всех сопутствующих библиотек
(Documentum, Aspose и т.д), направляются в аппендер по умолчанию log4j.xml.
Уровень логов обычно ограничивается WARN. Таким образом, инженер поддержки
системы может в короткое время ознакомиться со всеми возможными проблемами в
работе системы в целом.
9) Любые логгеры, специфичные для какой-либо подсистемы, например, подсистемы
запросов DQL, подсистемы работы с сессией.
2.3.3.2. Дополнительные сведения
При старте сервера необходимо указать директорию для хранения логов, для этого
требуется задать значение системного свойства log_path. Значение свойства задается при старте
контейнера ключом –D.
Например,
set JAVA_OPTS=-Xmx1000m –Xdebug –
Xrunjdwp:transport=dt_socket,address=8010,server=y,suspend=n –Dlog_path=»D:/logs»
где =»D:/logs» каталог, в который будут писаться логи системы.
Настройки логирования приложения описаны в конфигурационном файле WEB-
INF/classes/log4j.xml (находится внутри war-файла приложения Системы).
Дополнительно создаются следующие файлы (раздел Component specific appenders файла
log4j.xml):
new_update_component.log (логирование Администрирование «Список
обновлений»);
new_clientfx.log (логирование взаимодействия с client fx);
new_capability-service.log (логирование службы доступности элементов
21
управления, связанных со свойствами модели);
new_work-delegation.log (логирование действий, выполняемых при
увольнении/освобождении/переназначении сотрудника);
new_dict-access.log (логирование компоненты обновления прав доступа к
справочникам);
new_user-login.log (логирование сервиса аутентификации пользователей);
new_reports.log (логирование сервиса работы с отчетами);
new_registration.log (логирование сервиса формирования регистрационного
номера);
outgoing_signer.log (логирование текущего подписанта исходящего документа
при сохранении документа на стадии Согласование);
new_formlogger.log (логирование старта и окончания рендеринга, запускаемых
веб-форм приложения);
deprecated_usage.log (логирование использования устаревших кодовых
конструкций);
archive_year_creation.log (логирование компоненты создания папок по годам в
оперативном архиве Системы);
Так же могут присутствовать пустые файлы журналов, функциональности
ЕОСДО:
new_erp-integration.log;
new_sap-integration-external.log;
new_sap-integration-parse.log;
new_sap-integration-server.log;
new_sap-integration-axis.log;
new_contract.log;
new_contract-lifecycle.log;
new_contract-container.log;
new_rid_request.log;
new_rid_response.log;
new_rid_update.log;
new_rid_update_states.log.
2.3.4. Установка системы
Порядок создания, установки и настройки системы описан в Техническом решении по
созданию, установке и настройке отдельной инсталляции системы ЕОСДО на основе
существующего решения.
22
2.4. Установка и настройка клиентского ПО
2.4.1. Настройка web-браузера Google Chrome
Руководство по настройке браузера приводится в документе «ИНСТРУКЦИЯ ПО
НАСТРОЙКЕ РАБОЧЕГО МЕСТА ПОЛЬЗОВАТЕЛЯ».
3. Операции по обслуживанию
3.1. Мероприятия по текущему обслуживанию комплекса
3.1.1. Учетные записи для администрирования
Для выполнения работ по администрированию необходимо использовать специальные
учетные записи.
1) Сервер СУБД и резервный сервер СУБД (standby):
а) oracle – владелец инсталляции ПО ORACLE Database;
б) sys – системный пользователь СУБД;
в) system – системный пользователь СУБД;
г) rosatom – пользователь СУБД, владелец схемы репозитория rosatom.
2) Сервер контента:
а) dmadmin – владелец инсталляции, суперпользователь Documentum.
3) Сервер приложений:
а) ibm - владелец инсталляции ПО IBM WebSphere Application Server;
б) wasadmin – системный пользователь WAAS для подключения к консоли
управления WebSphere Application Server (WebSphere Integrated Solutions
Console).
4) Сервер Shark (метод сервер):
а) ibm - владелец инсталляции ПО IBM WebSphere Application Server;
б) wasadmin – системный пользователь WAAS для подключения к консоли
управления WebSphere Application Server (WebSphere Integrated Solutions Console).
5) Сервер индексирования:
а) dmadmin - владелец инсталляции, суперпользователь Documentum.
6) Балансировщики нагрузки:
а) nginx – пользователь ОС, с правами которого работают процессы сервера
балансировки нагрузки (NGINX);
23
3.1.2. Смена паролей системных пользователей
Таблица 5. Процедура смена паролей для системных учетных записей.
Учетная запись Смена пароля
dmadmin, владелец
установки ПО
ibm, владелец
установки ПО
Осуществляется штатными способами ОС
passwd
Остановка системы не требуется.
dmadmin,
суперпользователь
репозитория
Через интерфейс Documentum Administrator в ветке дерева
администрирования users, пароль должен быть типа inline password
При смене пароля dmadmin требуется обновить пароль в настройках
репозитория
Требуется рестарт системы для применения конфигурации с новым
паролем
Требуется сборка и обновление системы
24
Учетная запись Смена пароля
Владелец схемы
репозитория в
СУБД
Смена пароля на продуктивной среде не рекомендуется!
Требуется остановка системы.
Остановить все сервисы репозитория
Выставить переменную окружения: export
R_SHLIB_LD_LIBRARY_PATH=$DOCUMENTUM/product/16.4/bin
/FIPS
Перейти на первом контент сервере в директорию
$DM_HOME/dba/config/ROSATOM_MB или
$DM_HOME/dba/config/ROSATOM_MB_ARCH
Сделать копию файла dbpasswd.txt
Сменить пароль для пользователя ROSATOM_MB или
ROSATOM_MB_ARCH в СУБД
Внести изменения в файл dbpasswd.txt, заменить зашифрованный
пароль новым паролем в формате plain text (не зашифрованный)
Сохранить dbpasswd.txt
Перейти в директорию: $DM_HOME/bin и выполнить:
dm_encrypt_password –location /opt/documentum/dba/secure/CSaek -
docbase <docbase name> -rdbms -encrypt <database password>
Скопировать файл dbpasswd.txt на второй контент сервер (при
наличии).
Стартовать сервисы репозитория
3.1.3. Порядок остановки системы
Остановку системы необходимо выполнять в следующей последовательности:
1) Сервера балансировки нагрузки
Из под пользователя root остановить сервер nginx
# systemctl stop nginx.service
2) Сервер приложений (Выполнить на каждой ноде из пула серверов приложения).
Из под пользователя владельца установки (ibm):
cd $WS_PROFILEDIR/bin
Команда: ./stopServer.sh <AS_NAME>
Где <AS_NAME> имя сервера приложений (например, ic-s-sedapp01)
25
Из под пользователя root остановить промежуточный сервер nginx
# systemctl stop nginx.service
Из под пользователя root остановить менеджер нод
# /etc/init.d/node_manger_name_was.init stop
3) Метод сервер
Из под пользователя владельца установки:
cd $WS_PROFILEDIR/bin
Команда: ./stopServer.sh <AS_NAME>
Где <AS_NAME> имя сервера приложений (например, ic-s-sedapp01)
Из под пользователя root остановить менеджер нод
# /etc/init.d/node_manger_name_was.init stop
4) Сервер индексирования.
Остановка сервисов:~/bin/stop_all_rosatom.sh от пользователя dmadmin
5) Сервер контента репозитория rosatom.
Последовательно остановить сервер методов Java, сервисы репозитория rosatom и
процесс докброкер, выполнив команды, соответственно:
$DOCUMENTUM_SHARED/$JMS_VERSION/server/stopMethodServer.sh
dm_shutdown_rosatom
dm_stop_Docbroker
6) Сервер контента репозитория rosatom_arch.
Последовательно остановить сервер методов Java, сервисы репозитория rosatom и
процесс докброкер, выполнив команды, соответственно:
$DOCUMENTUM_SHARED/$JMS_VERSION/server/stopMethodServer.sh
dm_shutdown_rosatom_arch
dm_stop_Docbroker
7) Резервный сервер СУБД (standby).
Для остановки резервного сервера БД выполнить команду:
sqlplus / as sysdba
SQL> alter database recover managed standby database cancel;
Для остановки процесса Oracle Listener выполнить команду:
lsnrctl stop
8) Сервер СУБД.
Для остановки экземпляра БД выполнить команду:
sqlplus / as sysdba
SQL> shutdown immediate
26
Для остановки процесса Oracle Listener выполнить команду:
lsnrctl stop
3.1.4. Порядок запуска системы
Запуск системы выполняется в обратном порядке:
1) Сервер СУБД.
Для запуска процесса Listener выполнить:
lsnrctl start
Для запуска экземпляра БД выполнить:
sqlplus / as sysdba
SQL> startup
2) Резервный сервер СУБД (standby)
Для запуска процесса Listener выполнить:
lsnrctl start
sqlplus / as sysdba
SQL> alter database recover managed standby database using current logfile disconnect from
session;
3) Сервер контента репозитория rosatom_arch.
Последовательно выполнить команды:
dm_launch_Docbroker
dm_start_rosatom_arch
$DOCUMENTUM_SHARED/$JMS_VERSION/server/startMethodServer.sh
4) Сервер контента репозитория rosatom.
Последовательно выполнить команды:
dm_launch_Docbroker
dm_start_rosatom
$DOCUMENTUM_SHARED/$JMS_VERSION/server/startMethodServer.sh
5) Сервер индексирования.
Старт сервисов:~/bin/stop_all_rosatom.sh от пользователя dmadmin. Скрипт выполняет
запуск процессов dsearch и IndexAgent, а также выполняет команду API для запуска Агента
Индексирования в репозитории.
6) Сервер приложений (Выполнить на каждой ноде из пула серверов приложения).
Из под пользователя root запустить менеджер нод
# /etc/init.d/node_manger_name_was.init start
Из под пользователя root запустить промежуточный сервер nginx
27
# systemctl start nginx.service
Из под пользователя владельца установки:
cd $WS_PROFILEDIR/bin
Команда: ./startServer.sh <AS_NAME>
Где <AS_NAME> имя сервера приложений (например, ic-s-sedapp01)
7) Метод сервер
Из под пользователя root запустить менеджер нод
# /etc/init.d/node_manger_name_was.init start
Из под пользователя владельца установки:
cd $WS_PROFILEDIR/bin
Команда: ./startServer.sh <AS_NAME>
Где <AS_NAME> имя сервера приложений (например, ic-s-sedapp01)
8) Сервера балансировки нагрузки
Из под пользователя root выполнить
# systemctl start nginx.service
3.2. Регламентные работы
Таблица 6. Перечень регламентных работ
Краткое описание Подробное описание Время проведения
[Регламентная работа]
Мониторинг серверов.
1. Провести мониторинг нагрузки CPU APP/CS/DB
2. Провести мониторинг сессий APP
3. Проверить доступность ЕОСДО по https
4. Проверить доступность серверов приложений по http
5. Проверить сообщения систем мониторинга на наличие ошибок
6. Проверить логи APP/CS на наличие error, fatal ошибок.
7. Проверить свободное пространство на файловых системах продуктивных серверов
(APP/CS/INDEX/DB/SHARK)
В начале и конце
рабочего дня
[Регламентная работа]
Сценарий 5.1. Проверить наличие необработанных документов 5.1 В начале каждого дня,
проверка за
предыдущий день
[Регламентная работа]
Мониторинг состояния.
1. Утилизации CPU APP/CS/DB/SHARK
2. Количества сессий APP/CS
3. Сообщений систем мониторинга
В течение рабочего
дня
[Регламентная работа]
Мониторинг
приложения.
1. Проверить наличие ошибок в логе
2. Проверить доступность приложений системы через браузер
3. При возникновении ошибки – проверить, влияет ли ошибка на функционирование
приложения, если не влияет – собрать логи и дамп процесса приложения, если влияет –
перезапустить экземпляр сервера приложений
4. Проверить отсутствие ошибок в логе
При возникновении
инцидента
3.2.1. Обслуживание прикладной части системы.
Система базируется на программном комплексе OpenText Documentum 16.4 и
представляет собой набор сервисов данной платформы, включающий:
a) Сервисы брокера соединений,
b) Сервисы репозитория,
c) Сервисы Java Method сервера,
Дополнительные компоненты платформы.
3.2.1.1. Описание компонентов системы ПП.
Прикладной комплекс OpenText Documentum развернут в /dm/, владельцем установки
является пользователь dmadmin. Экземпляры сервисов представлены следующими компонентами:
a) /dm/cs-rosatom_mb – домашний каталог системной части приложений репозитория системы,
b) /dm/cs-rosatom_mb_arch – домашний каталог системной части приложений репозитория
Архива,
c) /dm/cs-rosatom_mb/shared/wildfly11.0.0 – экземпляр Java Method Server для репозитория
системы,
d) /dm/cs-rosatom_mb_arch/shared/wildfly11.0.0 – экземпляр Java Method Server для репозитория
Архива,
e) /dm/data/rosatom* - каталоги СХД репозиториев.
3.2.1.2. Методика сопровождения прикладной части системы.
Управление системой осуществляется в соответствии с документацией вендора: OpenText
™ Documentum® Server Version 16.4 Administration and Configuration Guide, в которой описана
архитектура платформы, а также все необходимые шаги для осуществления мониторинга и
сопровождения платформы.
Основной мониторинг и обслуживание системы производится из командной строки хоста
с помощью CLI интерфейса idql или iapi и интерфейса управления – Documentum Administrator,
обращение к которому осуществляется через веб браузер по адресу: http://appserver_hostname/da.
30
В командной строке операции, выполняемые через интерфейс idql и iapi, осуществляются
с предварительной загрузкой переменных окружения, уникальных для каждого из репозиториев:
. ~/.docu_env_ROSATOM – переменные для репозитория rosatom_mb,
. ~/.docu_env_ROSATOM_ARCH – переменные для репозитория rosatom_mb_arch.
В качестве вспомогательного механизма для администрирования репозиториев, после
загрузки соответствующих переменных, доступно использование скрипта
run_script_ROSATOM.sh и run_script_ROSATOM_ARCH.sh, соответственно. Данные скрипты
упрощают выполнение sql, dql и api скриптов.
3.2.1.3. Остановка и старт сервисов репозиториев.
Остановка сервисов:
stop_all_ROSATOM.sh
stop_all_ROSATOM_ARCH.sh
Старт сервисов:
start_all_ROSATOM.sh
start_all_ROSATOM_ARCH.sh
3.2.1.4. Мониторинг и контроль сервисов.
Платформа OpenText Documentum включает набор скриптов для мониторинга активности
процессов и доступности репозитория и сервисов для пользователей и клиентских приложений.
Эти скрипты включены в установку контент сервера, они могут быть задействованы любым
программным комплексом мониторинга или администратором в консоли хоста контент сервера.
31
Скрипты должны запускаться только от имени учетной записи-владельца инсталляции
OPENTEXT Documentum Content Server. Результатом выполнения скриптов является возврат
значения в переменной $?.
0 – в случае доступности процесса
любое иное значение – в случае отказа/недоступности процесса
Таблица 7. Средства мониторинга статуса сервисов OpenText Documentum
Сервис Скрипт Местонахож
дение Синтаксис
Content
Server
ContentSer
verStatus
Java
программа в
файле server-
impl.jar
Синтаксис команды:
java
com.documentum.server.impl.utils.ContentServerStatus -
docbase_name «repository_name» -user_name
«user_name»
repository_name – имя репозитория для проверки
доступности.
user_name – учетная запись, используемая для
соединения с репозиторием
Результат работы команды будет отражен в
переменной $?.
Connectio
n
broker
dmqdocbro
ker
Расположен в
$DM_HOME/
bin
Синтаксис команды:
$DM_HOME/bin/dmqdocbroker -t
host_name -c ping
host_name - имя машины с процессом докброкера.
Результат работы команды будет отражен в
переменной $?.
Java
method
server
TestConne
ction
Java
программа в
файле server-
impl.jar
Синтаксис команды:
java TestConnection host port servlet
host – имя машины с Java Method Server (JVM).
port – порт, используемый JVM
Результат работы команды будет отражен в
переменной $?.
Индекс-
агент
IndexAgent
Ctrl
Синтаксис команды:
java com.documentum.server.impl.utils.IndexAgentCtrl
-docbasename repositoryname -username username -
32
Сервис Скрипт Местонахож
дение Синтаксис
action status
repository_name – имя репозитория для проверки
доступности.
user_name – учетная запись, используемая для
соединения с репозиторием
Результат работы команды будет отражен в
переменной $?.
3.2.1.5. Мониторинг производительности.
На хостах КТС ЕОСДО установлен пакет sysstat, входящий в дистрибутив RHEL. С
помощью следующих команд можно мониторить производительность серверов.
Таблица 8. Средства сбора метрики производительности sar.
Команда Описание
sar -b 3 10 Мониторинг дисковой i\o активности
sar -r 3 10 Статистика памяти и использования swap
sar -n DEV 3 10 Статистика сети
sar -P ALL 3 10 Статистика использования CPU
LC_ALL=C sar -A > /tmp/sar.data.txt Сбор статистики в файл для анализа ksar
Суточные графики-отчеты хранятся в sar файлах по адресу /var/log/sa.
3.2.1.6. Выполнение служебных работ.
Платформа OpenText Documentum включает набор утилит для администрирования и
оптимизации производительности. Эти утилиты включены в установку контент сервера, и
запускаются автоматически по расписанию, с помощью преднастроенных системных работ.
Месторасположение: Documentum Administrator >> Имя_репозитория >> Administration >> Job
Managemtnt >> Jobs.
Таблица 9. Перечень системных работ репозитория OpenText Documentum.
Список системных работ OpenText Documentum
Работа Функционал работы
Рекомендуемая
регулярность
выполнения
работы
33
dm_ConsistencyChe
cker
Автоматическое выполнение утилиты
администратора Consistency Checker
Детальное описание утилиты приведено в
разделе 3.2.1.6.2
При необходимости
dm_ContentWarnin
g
Автоматическое выполнение утилиты
администратора Content Warning, которая
осуществляет мониторинг свободного места для
областей хранения контента
Ежедневно, по
окончании рабочего
дня
dm_DBWarning
Автоматическое выполнение утилиты
администратора Database Space Warning,
которая осуществляет мониторинг свободного
места и наличия фрагментации для таблиц и
индексов базы данных
Ежедневно, по
окончании рабочего
дня
dm_DMClean
Автоматическое выполнение утилиты
администратора Dmclean, которая
осуществляет сканирование репозитория с
целью поиска устаревших (orphaned) объектов и
создает скрипт для возможности их удаления
dm_DMFilescan
Автоматическое выполнение утилиты
администратора Dmfilescan, которая
осуществляет сканирование областей хранения
контента с целью поиска файлов без
метаданных и создает скрипт для возможности
их удаления
dm_QueueMgt
Автоматическое выполнение утилиты
администратора Queue Management, которая
осуществляет удаление неиспользуемых
(dequeued) объектов dmi_queue_item
dm_AuditMgt
Автоматическое выполнение утилиты
администратора Audit Management, которая
осуществляет удаление неиспользуемых
(unneeded) объектов dm_audittrail
34
dm_UpdateStats
Автоматическое выполнение утилиты
администратора Update Statistics для
оптимизации работы базы данных с запросами
dm_LogPurge
Автоматическое выполнение утилиты
администратора Log Purge для удаления
устаревших логов и файлов отчетов
dm_DataDictionary
Publisher
Автоматическое выполнение утилиты
администратора Data Dictionary Publisher,
которая осуществляет обновление
(публикацию) информации о типах объектов и
атрибутах
При необходимости
dm_StateOfDocbase
Автоматическое выполнение утилиты
администратора State of the Repository Report
для получения актуальной сводной информации
о репозитории
При необходимости
Связанные документы/ссылки:
OpenText Documentum Content Server Version 16.4 Administration and Configuration Guide
(Chapter 11, Logging and Tracing)
3.2.1.6.1. Мониторинг работы (анализ системных журналов контент сервера).
Сбор информации в системных логах сервера контента для выявления потенциальных
проблем в работе.
Анализ системных журналов:
a) контент сервера: $Documentum\dba\log\имя_репозитория.log
b) метод сервера: $Documentum\shared\jboss11.0.0\server\DctmServer_MethodServer\logs\
Связанные документы/ссылки:
OpenText Documentum Content Server Version 16.4 Administration and Configuration Guide
(Chapter 11, Logging and Tracing)
35
3.2.1.6.2. Проверка целостности (согласованности) репозитория.
Для проверки целостности репозитория используется встроенная в OpenText Documentum
Content Server утилита администратора Consistency Checker, которая сканирует репозиторий и
сообщает любые несогласованности, такие как:
повреждение типов и объектов,
наличие объектов, ссылающихся на несуществующие группы, пользователи и т.д..
Механизм Consistency Checker не пытается исправлять эти несогласованности.
Систематизированный список несогласованностей и обозначения соответствующих кодов
ошибок, которые могу быть выявлены Consistency Checker, приведены в OpenText Documentum
Content Server Administrator’s Guide (Appendix A, Consistency Checks).
Выполнение системной работы dm_ConsistencyChecker создает отчет с перечнем
исследованных категорий и выявленных несогласованностей. Отчет записывается в репозиторий
по адресу: /System/Sysadmin/Reports/ConsistencyChecker.
Если в результате проверки целостности ошибки выявлены не были, новый отчет
записывается поверх прежнего, если ошибки выявлены – отчет сохраняется, как новая версия
предыдущего. По умолчанию, системная работа dm_ConsistencyChecker активирована и
запускается 1 раз в день, но возможно запускать утилиту администрирования Consistency Checker,
по необходимости, вручную, используя для этого следующую командную строку:
dmbasic -fconsistency_checker.ebs -eEntry_Point --repository_name superuser password
repository_name – репозиторий, в отношении которого инициирован процесс.
superuser – учетная запись суперпользователя репозитория.
password – пароль суперпользователя репозитория
Связанные документы/ссылки:
OpenText Documentum Content Server Version 16.4 Administration and Configuration Guide
(Chapter 11, Logging and Tracing)
3.2.2. Обслуживание системы полнотекстового поиска xPlore.
Сервер полнотекстового поиска представляет собой совокупность развернутого ПО
OpenText xPlore 16.4, состоящую из экземпляров приложений dsearch, indexagent и
дополнительных инструментов для конфигурации, сопровождения и восстановления
функционала полнотекстового поиска (далее - ПП).
36
3.2.2.1. Описание компонентов системы ПП.
Прикладной комплекс xPlore развернут в /dm/xPlore/, владельцем установки является
пользователь dmadmin. Экземпляры сервера ПП представлены следующими компонентами:
f) /dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/ - основной сервер ПП,
g) /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/ - индекс-агент для рабочего
репозитория системы,
h) /dm/xPlore/data/ - область хранения системных данных и данных коллекции default сервера
индексации,
i) /dm/xPlore/dsearch/admin/ - область хранения инструментария администрирования сервера
ПП через CLI (интерфейс командной строки),
j) /dm/xPlore/dsearch/xhive/admin/ - область хранения инструментария администрирования
базы данных xhive ПП через CLI (интерфейс командной строки),
k) /dm/xPlore/setup/indexagent/tools/ - область хранения инструментария для управления
консистенцией и соответствием индекса ПП данным репозитория.
3.2.2.2. Методика сопровождения системы ПП.
Управление системой ПП осуществляется в соответствии с документацией вендора:
OpenText ™ Documentum® xPlore Version 16.4 Administration and Development Guide, в которой
описаны все необходимые шаги для осуществления резервного копирования, мониторинга,
оптимизации и конфигурации служб ПП.
Основной мониторинг и обслуживание системы ПП производится из командной строки
хоста ПП и интерфейса управления ПП – dsearchadmin, обращение к которому осуществляется
через веб браузер по адресу: http://url.
37
В командной строке операции по обслуживанию системы ПП производятся следующими
бинарнными файлами:
a) /dm/xPlore/dsearch/admin/xplore.sh – выполнение операций по мониторингу, сбору
статистики, резервному копированию и восстановлению,
b) /dm/xPlore/dsearch/xhive/admin/XHAdmin – выполнение операций по обслуживанию,
резервному копированию федерации ПП, восстановлению, проверки консистентности базы
данных ПП (имеет графический интерфейс),
c) /dm/xPlore/dsearch/xhive/admin/XHCommand – выполнение операций по обслуживанию
базы данных xhive ПП,
d) /dm/xPlore/setup/indexagent/tools/ftintegrity_for_****.sh – инструментарий управления
коллекцией индексов ПП.
Подробные сведения о предназначении, выполнении рутинных задач, синтаксисе,
приводятся в документации вендора, указанной в начале раздела.
3.2.2.3. Описание базовых задач по обслуживанию системы ПП.
Проверка состояния сервисов осуществляется несколькими способами:
a) Доступность сервера индексации – http://url.9300/dsearch - отображается версия и статус
dsearch,
b) Доступность индекс-агента – http://url:9200/IndexAgent - отображается страница
авторизации индекс-агента, далее, после аутентификации – статус агента и интерфейс
управления параметрами работы и конфигурации индекс-агента,
c) Состояние сервисов сервера ПП через панель управления xPlore Administrator – в разделе
System Overview,
d) Статус сервисов, журналы, статистика – отображаются в разделе панели управления xPlore
Administrator – Instances, или в журналах на фс:
/dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/logs/,
38
e) /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/logs/.
f) Журналы экземпляров сервисов находятся в /dm/xPlore/logs/.
g) Состояние очереди dmi_queue_items для сервера полнотекстовой индексации отображается
в результате выполнения запросов dql в интерфейсе Documentum Administrator.
3.2.2.4. Остановка и старт сервисов ПП.
Остановка сервисов: ~/bin/stop_all_rosatom.sh
Скрипт включает: запуск сервера dsearch, запуск сервиса IndexAgent и выполнение
команды API для запуска Агента Индексирования в репозитории
Старт сервисов: ~/bin/start_all_rosatom.sh
Скрипт выполняет остановку сервисов dsearch и IndexAgent, а также остановку всех
связанных java процессов.
Контроль старта сервисов:
ll /dm/xPlore/wildfly11.0.0/server/DctmServer_PrimaryDsearch/deployments/
ll /dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/deployments/
Все приложения должны быть в статусе deployed.
ps -ef | grep JAVA_LINK – должно быть в активном состоянии два процесса java, по одному для
каждого из экземпляров сервисов ПП.
39
3.2.2.5. Запросы для мониторинга очереди индексации в репозитории.
Смотрим, какие события регистрируются в очередь
select * from dmi_registry where is_audittrail=0 and user_name like 'dm_fulltext_index_user%'
Количество dmi_queue_item, используемое очередью индексации
select name,count(name) from dmi_queue_item where name like 'dm_fulltext_index_user%'
group by name
Смотрим, какие типы индексируются
select name from dm_type where r_object_id in (select distinct registered_id from dmi_registry
where user_name='dm_fulltext_index_user')
3.2.2.6. Сбор статистики работы системы ПП.
Сбор статистики о работе сервера полнотекстового поиска запускается через панель
управления xPlore: Diagnostic and Utilities – Reports.
Рекомендуемые отчеты: User Activity Report, Query Counts By User, Indexing Metrics.
Данные отчеты рекомендуется просматривать 1 раз в неделю за необходимое количество рабочих
дней.
3.2.2.7. Проверка консистентности индексов ПП.
Проверка консистентности индексов выполняется:
a) При возникновении жалоб на работу поиска, после анализа отчета Indexing Metrics и User
Activity Report,
b) При возникновении ошибок в логах xhive (instances – Logging – xdb) с ошибками на сбои
сегментов базы данных,
c) При восстановлении индексов из резервной копии.
Проверка консистентности выполняется через панель управления xPlore – Data
Management – кнопка Check DB Consistency.
40
При большом размере индексов, операция может занимать от 1 часа до нескольких часов.
При нарушении консистенции индексов, рекомендуется выполнить восстановление базы
индексов из резервной копии и доиндексацию дельты.
3.2.2.8. Проверка целостности и соответствия ПП.
В результате различных сбоев может быть выявлено нарушение целостности и
соответствия индекса. Причиной подобного нарушения может быть – временная
неработоспособность индекс-агента, проблемы в работе КСПД (сети) и т.д.
В случае обнаружения проблем (жалобы на осутствие в результатах поиска новых
документов, разрастание очереди на индексацию) требуется:
a) Провести регламентные работы по чистке очереди dmi_queue_items от устаревших
объектов dm_fulltext_index_user. Не рекомендуется чистка удалением через sql или dql,
если число подобных объектов превышает 100 тыс. Требуется корректная операция по
пересозданию новой таблицы dmi_queue_item_s в СУБД,
b) Восстановить федерацию \ домен коллекции индексов,
c) Восстановить работу индекс-агента,
d) Запустить средство проверки целостности и соответствия индекса -
/dm/xPlore/setup/indexagent/tools/ftintegrity_for_****.sh. Запуск проверки рекомендуется
выполнять в нерабочее время,
e) После окончания работы ftintegrity проверить число объектов в файле ObjectId-
dctmOnly.txt, если число объектов менее 200 тыс, то скопировать данный файл на
индексацию:
cp ObjectId-dctmOnly.txt
/dm/xPlore/wildfly11.0.0/server/DctmServer_Indexagent/deployments/IndexAgent.war/WEB
-INF/classes/ids.txt
Если число объектов в файле превышает 200 тыс,, рекомендуется разбиение файла на части по
200 тыс и загрузка по очереди с интервалом 2 часа.
41
Работу ftintegrity можно автоматизировать запуском 1 раз в неделю в выходные с помощью
cron, а также автоматическую доиндексацию.
3.2.2.9. Резервное копирование и восстановление ПП.
Горячее резервное копирование и восстановление рекомендуется производить при
остановленном индекс-агенте, если число суточных операций по отчету User Activity Report
превышает 50 тысяч, и число обрабатываемых в сутки документов превышает 500 000 в сутки по
отчету Indexing Metrics. Резервное копирование выполняется средствами dsearch и только при
запущенном сервисе DctmServer_PrimaryDsearch, так как идет обращение к xdb.
Резервное копирование небольшого объема индексов (до 500 ГБ) можно выполнять
уровнем федерации (полное) и домена (инкрементальное). Выполнение инкрементального
резервного копирования чаще, чем 1 раз в сутки не рекомендуется, для построения
детальной схемы резервного копирования необходимо производить анализ объема данных и
скорости выполнения файловых операций для оценки скорости резервного копирования и
восстановления.
Резервное копирование:
./xplore.sh "backupFederation 'путь к резервной копии', false, null" >>путь к логу.log
./xplore.sh "backupDomain 'путь к резервной копии', false, null" >>путь к логу.log
Для создания целостной полной резервной копии требуется так же резервировать данные
из директорий:
/dm/xPlore/config/
/dm/xPlore/dsearch/
/dm/xPlore/setup/
Холодное резервное копирование выполняется при остановленных сервисах ПП,
необходимо убедиться, что база данных xdb остановлена и нет работающих процессов java, иначе
данные индексов будут неконсистентны.
Восстановление коллекций индексов выполняется по стандартной схеме GF-F (федерация
– домен).
./xplore.sh "restoreFederation 'путь к резервной копии федерации'"
./xplore.sh "restoreDomain 'путь к резервной копии федерации'"
3.3. Обновление комплекса
3.3.1. Общие замечания по процедуре обновления компонентов комплекса ЕОСДО.
Установка обновлений прикладного ПО производится в соответствии с документацией
производителя ПО. Для бесперебойной работы комплекса ЕОСДО должны быть полностью
отключены механизмы автоматического обновления системного ПО, прикладного ПО и любого
42
стороннего ПО, участвующего в работе комплекса. Установка обновлений должна
осуществляться только после проверки на второстепенных средах (тестирования и разработки).
Настоящий регламент не рассматривает процедуру обновления микропрограмм
аппаратного комплекса.
Процедура обновления может быть произведена только после разработки Плана
проведения работ, включающего:
Подробное описание подготовительных работ для проведения обновления,
Пошаговое описание шагов выполнения обновления,
План тестирования функционала системы после обновления,
Детальный план возврата системы в исходное состояние при неудачном выполнении работ.
Каждый их этапов плана должен иметь заданные временные рамки выполнения и
ответственных за выполнение работ специалистов.
Установка обновлений осуществляется в строгом соответствии с документацией вендора
компонента комплекса. Дополнительные рекомендации могут быть даны разработчиком системы
ЕОСДО после тестирования на второстепенных средах.
3.3.2. Установка минорных обновлений.
Установка минорных обновлений (патчей, исправлений) осуществляется:
Для ОС Red Hat Enterprise Linux – исключительно после использования команды «yum
check-update», построения списка версий пакетов, для которых имеются обновленные
версии и согласование перечная обновляемых пакетов с разработчиком системы ЕОСДО.
Установка обновлений пакетов без согласования версий может привести к нарушению
работоспособности комплекса.
Для IBM WebSphere – установка обновлений предусматривается для случаев, когда
применение исправления рекомендовано производителем для решения конкретной
проблемы в функционировании комплекса. Установка обновлений должна быть
согласована с разработчиком ЕОСДО.
Для продуктов OpenText Documentum – установка патчей выполняется только по
рекомендации службы поддержки вендора или по рекомендации разработчика системы
ЕОСДО. Установка осуществляется строго в соответствии с Patch Notes для конкретного
продукта OpenText Documentum. При наличии в патче обновления ПО стороннего вендора
(например, JDK или WildFly) требуется проведение дополнительной проверки на
второстепенных средах и привлечение разработчиков ЕОСДО для согласования проведения
обновления ПО.
Для Oracle Database – установка обновлений предусматривается для случаев, когда
применение исправления рекомендовано производителем СУБД для решения конкретной
проблемы в функционировании комплекса или задействованию нового функционала БД,
согласованного с эксплуатантом Системы. Установка обновлений должна быть согласована
с разработчиком ЕОСДО.
Установка минорных обновлений выполняется исключительно для одного компонента
комплекса (ОС, СУБД, Сервер приложений, Контент сервер и т.д.) в одну итерацию. Перед
43
проведением работ по обновлению системы выполняется полное резервное копирование
компонент, в отношении которых производятся работы.
3.3.3. Установка мажорных обновлений.
Установка любых мажорных обновлений (сервис пак, версия, релиз) осуществляется
после согласования версии обновленного ПО с матрицей совместимости прочих компонент
комплекса ЕОСДО. Так как комплекс представляет собой сложную архитектуру, в которой
используется ПО нескольких вендоров, требуется согласование используемых версий продуктов
во избежание проблем с совместимостью. Для установки отдельных мажорных обновлений
(например, ОС, СУБД) рекомендуется рассмотреть возможность использования stage окружений
(КТС временного размещения клона обновляемой системы). При масштабном обновлении
компонент комплекса ЕОСДО (более чем одной версии компонента одного типа) требуется
подготовка и согласование документа-стратегии выполняемых работ.
Установка мажоритарных обновлений осуществляется:
Для ОС Red Hat Enterprise Linux – обновление версии ОС осуществляется в соответствии с
рекомендациями производителя ОС, и после согласования с разработчиком ЕОСДО.
Для IBM WebSphere – установка обновлений должна быть согласована с разработчиком
ЕОСДО.
Для продуктов OpenText Documentum – обновление выполняется по рекомендации службы
технической поддержки производителя ПО или разработчика ЕОСДО. Обновление
ключевых компонент комплекса (контент сервер, версия приложения) выполняется в
обязательном порядке с использованием stage окружения, максимально приближенного по
конфигурации к среде Промышенной эксплуатации, так как второстепенные среды имеют
редуцированную (минимальный набор компонентов) схему развертывания и не
предполагают использование функций ПО, связанных с обеспечением распределения
нагрузки или обеспечением высокой доступности.
Для Oracle Database – установка обновлений предусматривается для случаев, когда
применение исправления рекомендовано производителем СУБД для решения конкретной
проблемы в функционировании комплекса или задействованию нового функционала БД,
согласованного с эксплуатантом Системы. Установка обновлений должна быть согласована
с разработчиком ЕОСДО. Обновление выполняется в обязательном порядке с
использованием stage окружения, максимально приближенного по конфигурации к среде
Промышенной эксплуатации, так как второстепенные среды имеют редуцированную
(минимальный набор компонентов) схему развертывания и не предполагают использование
функций ПО, связанных с обеспечением распределения нагрузки или обеспечением
высокой доступности.
Установка мажорных обновлений выполняется исключительно для одного компонента
комплекса (ОС, СУБД, Сервер приложений, Контент сервер и т.д.) в одну итерацию, за
исключением случаев, когда обновление одного компонента требует обновление одного или
нескольких для соблюдения требований матрицы совместимости. Перед проведением работ по
обновлению системы выполняется полное резервное копирование компонент, в отношении
которых производятся работы.
44
3.3.4. Установка обновлений на клиентские рабочие станции.
Автоматическое обновление на клиентских рабочих станциях должно быть отключено.
При произведении работ по установке обновлений необходимо согласование устанавливаемых
версий обновлений с разработчиком ЕОСДО для:
Версий браузера.
Установка патчей безопасности, системных драйверов выполняется согласно внутренней
политике ИС АО «Гринатом».
3.4. Мониторинг ЕОСДО
Администратор Системы должен контролировать свободное доступное пространство на
файловых системах, а также регулярно (не менее 1 раза в день) отслеживать предупреждения и
критические ошибки в следующих системных журнальных файлах:
на серверах приложений и метод сервере:
$WS_PROFILEDIR/<PROFILE>/logs/<AS_NAME>;
$WS_INSTALLDIR/logs/app;
на контент-серверах:
$DOCUMENTUM/dba/log,
$DOCUMENTUM_SHARED/wildfly11.0.1/server/DctmServer_MethodServer/log;
на сервере индексирования:
$XPLORE_HOME/wildfly11.0.1/server/DctmServer_PrimaryDsearch/logs;
$XPLORE_HOME/wildfly11.0.1/server/DctmServer_Indexagent/logs;
на серверах балансировки нагрузки:
/var/log/nginx.
4. Ошибки работы системы и способы их устранения
4.1. Вход в Систему невозможен из-за ввода неправильного имени
пользователя
При входе в Систему отказ в доступе возможен по причине неправильно введенного
имени пользователя, так как поле ввода чувствительно к регистру. Так же необходимо убедиться,
что на странице входа указан корректный домен для аутентификации.
4.2. Отображение окна сертификата при работе с Системой
При запуске Системы на экране может отобразиться окно сертификата безопасности,
которое изображено на рисунке 1. Для закрытия данного окна следует нажать кнопку ,
после чего окно больше не появится.
Рисунок 1 − Окно сертификата безопасности 1
4.3. Возможные ошибки при возобновлении работы с Системой после
временного интервала
Следует учитывать, что в Системе запускается автоматический учет времени простоя,
если авторизованный пользователь длительное время не работает с Системой. При возобновлении
деятельности возможно появление сообщений «Тайм-аут по простою», которые означают, что
пользователь из-за простоя Системы был отключен. В этом случае следует обновить окно и
выполнить повторную авторизацию в Системе.
Длительность допустимого простоя задается в файле-дескрипторе /WEB-INF/web.xml,
находящемся внутри war-файла приложения Системы. Для изменения значения необходимо
отредактировать секцию <session-config>.<session-timeout>, установив требуемое значение (в
46
минутах), после чего выполнить редеплой и рестарт приложения. Для изменения значения
параметра на постоянной основе необходимо изменить файл в коде Системы (GIT).
4.4. Возможные ошибки при возврате на предыдущую страницу браузера с
помощью кнопки Back
При работе с Системой запрещается использовать кнопку управления «Back» (Назад) в
браузере Internet Explorer или Chrome, так как это может привести к появлению ошибок и потере
вводимых данных.
Для перемещения между справочниками следует использовать дерево папок в левой
панели интерфейса Системы.
При перемещении между различными уровнями иерархических справочников следует
использовать путь к выбранному элементу в верхней части правого фрейма, щелкнув по
которому, можно вернуться на более высокий уровень дерева.
При открытии плоских справочников, на странице отображаются первые пянадцать
элементов справочника. Для отображения остальных элементов необходимо нажать левой
кнопкой мыши на одну из экранных кнопок перемещения между страницами .
4.5. Возможные ошибки при открытии файлов
Возможны 2 варианта развития событий при открытии файлов:
1. Уведомление «Запускается приложение работы с контентом. Повторите через
минуту.» - означает, что приложение не успело запуститься для открытия файла,
нужно подождать минуту и попробовать снова.
2. Ошибка «Не удалось запустить приложение для работы с контентом.» - появляется
спустя какое-то время после первой попытки открытия файла.
В случае возникновения ошибки при загрузке или открытии файлов на компьютере
пользователя необходимо выполнить следующие действия:
1) Убедиться, что установлены и используются корректные версии операционной
системы, Internet Explorer или Chrome и среды выполнения Java (Sun JRE).
2) Убедиться, что адрес приложения добавлен в зону «Надежные сайты» и для него не
блокируются всплывающие окна в Internet Explorer (если используется браузер
Internet Explorer).
3) Закрыть все окна Internet Explorer или Chrome, при необходимости, завершить в
Диспетчере Задач Windows все процессы iexplore.exe, java.exe и javaw.exe, если
система открыта в Internet Explorer, и все процессы chrome.exe и jp2launcher.exe,
если используется Chrome.
4) Убедиться, что адрес https://url /записан в Exeption Site List в консоли Java. Для этого
нужно открыть Java Control Panel из «Панели управления», перейти на закладку
Security.
47
5) Отключить, если используются, брандмауэр, антивирус и дополнительные средства
защиты, затем попробовать воспроизвести проблему. Если не воспроизводится,
необходимо тщательно проанализировать текущие настройки антивирусного ПО и
брандмауэра и настроить те из них, которые приводят к препятствованию работы
функционала апплета передачи содержимого в Webto
Далее, для диагности проблемы:
1. Запросить у пользователя скриншот ошибки, что приложение не запустилось или любое другое
сообщение системы о проблеме с запуском:
a. Нужны подробные сведение помимо шибки Java (в том числе, недоверия
сертификату);
b. Сообщение «Подождите минуту» - оповещение, а не ошибка.
2. Если проблема на АРМП:
2.1. Отправить пользователю архив 1_EOSDOSupportGenerator.7z
2.2. Попросить пользователя запустить вложенный в него скрипт и выслать обратным письмом
результат (оно будет сгенерировано автоматически);
2.3. На основании полученной информации запросить у ЦПП или пользователя (в зависимости от
необходимых прав доступа) выполнить необходимые шаги инструкции (в отчете будут указаны
номера проблемных пунктов).
2.4. Если вопрос касается сертификатов ГК (п.3.7)
a. ЦПП направить архив 2_certImport.7z
b. Запросить у ЦПП лог отработки или попросить их самостоятельно удостовериться,
что все настроено корректно
2.5. После исправления ЦПП настроек АРМП, повторить п.2.2.
5. Аварийные ситуации и действия по их устранению
Таблица 11. Перечень действий администраторов при сбоях компонент ЕОСДО.
Сервис Вид сбоя Последовательность действий
для диагностики сбоя Последовательность действий при сбое
Сервер
приложений
Недоступно
приложение
ЕОСДО
Проверить доступность узлов
серверов приложений
1) Вывести узел из-под балансировщика нагрузки
echo "disable server имя_балансировщика(backend)/имя сервера в
конфигурации HAProxy(server)" | socat stdio /var/run/haproxy.sock
2) Собрать журналы (логи) узла для анализа
3) Исследовать логи с целью выявления причины сбоя
4) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
5) Перезапустить узел сервера приложений согласно п. 3.1.3
6) Проверить доступность приложения
7) Вернуть узел под балансировщик нагрузки
echo "enable server имя_балансировщика(backend)/имя сервера в
конфигурации HAProxy(server)" | socat stdio /var/run/haproxy.sock
8) Предоставить пакет данных для анализа разработчикам (при
необходимости)
Сервер
Shark
Недоступно
приложение
Shark или
федеративные
прилоежния
Проверить доступность узла
сервера приложений Shark
1) Собрать журналы (логи) узла для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить узел сервера приложений согласно п. 3.1.3
5) Проверить доступность приложения
6) Вернуть узел под балансировщик нагрузки
7) Предоставить пакет данных для анализа разработчикам (при
необходимости)
49
Сервис Вид сбоя Последовательность действий
для диагностики сбоя Последовательность действий при сбое
Недоступен
сервис Apache
MQ
Проверить статус сервиса и
наличие процесса на сервер (ps –
ef | grep activemq)
1) Собрать журналы (логи) activemq для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить activemq (service activemq restart от root)
5) Предоставить пакет данных для анализа разработчикам (при
необходимости)
Недоступен
сервер базы
данных
федерации
(MongoDB
4.0)
Проверить доступность и
работоспособность базы
данных MongoDB 4.0.
1) Собрать журналы (логи) сервера для анализа в файлах логов и
mongo Shell
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить сервер MongoDB 4.0 (service mongod restart)
5) Проверить доступность (mongo –u, пользователь – p, пароль –
authenticationDatabase имя базы данных)
6) Предоставить пакет данных для анализа разработчикам (при
необходимости)
Контент
сервер
Недоступен
JMS
Проверить работоспособность
и доступность JMS (п. 3.2.1.4)
1) Собрать журналы (логи) JMS для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить JMS п.3.1.3
5) Предоставить пакет данных для анализа разработчикам (при
необходимости)
50
Сервис Вид сбоя Последовательность действий
для диагностики сбоя Последовательность действий при сбое
Недоступен
докброкер
Проверить работоспособность
и доступность докброкера (п.
3.2.1.4)
1) Собрать журналы (логи) докброкера для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить докброкер п.3.1.3
5) Предоставить пакет данных для анализа разработчикам (при
необходимости)
Недоступен
сервис
репозитория
Проверить работоспособность
и доступность репозитория (п.
3.2.1.4), проверить
возможность подключения к
репозиторию средствами
IDQL, Documentum
Administrator
1) Собрать журналы (логи) сервиса репозитория для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить репозиторий п.3.1.3
5) Перезапустить приложения ЕОСДО
6) Предоставить пакет данных для анализа разработчикам (при
необходимости)
Полнотексто
вый поиск
Недоступен
индекс-агент
Проверить работоспособность
и доступность индекс-агента
(п. 3.2.1.4, 3.2.2.2, 3.2.2.3)
1) Собрать журналы (логи) индекс-агента для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить индекс-агент п.3.1.3
Недоступен
полнотекстовы
й поиск
Проверить работоспособность
и доступность dsearch (п.
3.2.2.2, 3.2.2.3)
1) Собрать журналы (логи) dsearch для анализа
2) Исследовать логи с целью выявления причины сбоя
3) Устранить причину сбоя (проблема конфигурации, недостаток
ресурсов и т.д.)
4) Перезапустить сервисы полнотекстового поиска п.3.2.2.4
5) Предоставить пакет данных для анализа разработчикам (при
необходимости)
5.1. Восстановление работоспособности ЕОСДО
В данном разделе для каждого типа сбоя, указанного в подразделе 0, описывается
порядок выполнения операций для возвращения ЕОСДО в штатный режим работы.
5.1.1. Основные типы сбоев
Возможны следующие основные типы сбоев:
остановка системной службы (тип 1);
повреждение, либо утеря данных - БД, файловое или индексного хранилище (тип 2);
5.1.2. Восстановление в случае остановки приложения
В случае возникновения сбоя типов 1 и 3 необходимо перезапустить процессы
Documentum в следующей последовательности:
остановить сервисы репозитория и сервер методов java на сервере контента;
остановить агент и сервер индексирования на сервере индексирования;
запустить сервисы репозитория и сервер методов java;
запустить агент и сервер индексирования.
При недоступности контент-сервера возможно появление ошибок:
DM_SESSION_E_CANT_CONNECT и DM_DOCBROKER_E_HOST_NAME. Если не доступен
сервер приложений или вся сеть, то возможно появление следующей ошибки: The page cannot be
displayed.
При сбоях репозитория (приложения docbase, docbroker и т.д.) в обязательном порядке
требуется рестарт приложений ЕОСДО!
5.1.3. Восстановление в случае повреждения данных
В случае сбоя в работе сервера СУБД необходимо восстановить БД из резервной копии
при помощи штатного средства ORACLE RMAN, встроенного в используемую систему
резервного копирования. Руководство по RMAN содержится в документе Oracle Database Backup
and Recovery Advanced User’s Guide.
Восстановление необходимо производить только при остановленных процессах
Documentum.
В случае сбоя в работе сервера контента или сервера приложений необходимо
восстановить файловое хранилище из резервной копии. Восстановление производить при
остановленных процессах Documentum.
52
В случае серьезного сбоя в работе сервера поиска необходимо восстановить индексное
хранилище из резервной копии. Восстановление производить при остановленных процессах
Documentum.
Восстановлением данных занимается ОБИС - Отдел базовых информационных сервисов.
5.1.4. Полное восстановление
При выходе из строя аппаратных компонентов сервера, критическом сбое в работе ОС,
выхода из строя двух или более дисков из массива системного раздела необходимо выполнить
следующие действия (в зависимости от роли сервера):
1) Восстановление сервера СУБД:
а) восстановить работу аппаратного обеспечения сервера БД;
б) установить системное и прикладное ПО;
в) восстановить БД из резервной копии.
2) Восстановление сервера контента:
а) восстановить работу аппаратного обеспечения сервера контента;
б) установить системное ПО;
в) установить прикладное ПО;
г) восстановить файловое хранилище из резервной копии.
3) Восстановление сервера индексирования:
а) восстановить работу аппаратного обеспечения сервера поиска;
б) установить системное ПО;
в) установить прикладное ПО;
г) восстановить индексное хранилище из резервной копии.
4) Восстановление сервера приложений:
а) восстановить работу аппаратного обеспечения сервера приложений;
б) установить системное ПО;
в) установить прикладное ПО.
В системе предусмотрено частичное и полное восстановление прикладных данных.
1. Полное восстановление продуктивных прикладных данных, восстановление всех данных
контента и соответствующих им метаданным, хранящимся в БД Oracle, на конкретный день
недели, на одну или две недели, или один месяц назад от текущего момента («откат» назад на
сутки и более от текущего момента) осуществляется следующим образом:
o администратором выполняется остановка служб прикладной системы ЕОСДО;
53
o восстановление контента проводится с помощью имеющихся ленточных или дисковых
копий (которые делаются ежедневно, еженедельно и ежемесячно):
сначала восстанавливается полная ленточная \ дисковая копия, а затем
необходимое количество инкрементальных;
o восстанавливается полная ленточная \ дисковая копия БД Oracle (делается ежедневно,
еженедельно и ежемесячно);
o далее администратором выполняется запуск служб системы ЕОСДО, проверка данных
контента и СУБД.
2. Частичное восстановление продуктивных прикладных данных, а именно, восстановление
отдельного документа, на конкретный день недели, на одну или две недели, или один месяц
назад от текущего момента («откат» назад на сутки и более от текущего момента)
осуществляется следующим образом:
o восстановление продуктивных данных производится на временно выделенный
ресурсный пул Vmware (должен быть изолирован по сети от продуктивной среды);
o проводится восстановление продуктивного контента с помощью имеющихся
ленточных \ дисковых копий (которые делаются ежедневно, еженедельно и
ежемесячно):
сначала восстанавливается полная ленточная \ дисковая копия, а затем
необходимое количество инкрементальных (в хранилище тестовой среды);
возможно восстановление отдельного раздела СХД;
o восстанавливается полная ленточная копия продуктивной БД Oracle (делается
ежедневно, еженедельно и ежемесячно) в БД среды тестирования, в базе данных
изменяются параметры в таблице dm_location_s для области хранения контента;
o вручную выполняется реконфигурация для назначения требуемых адресов и имен
серверов (IP адрес сервера, FQDN сервера), а также конфигурации развернутых
сервисов;
o администратором выполняется запуск служб системы ЕОСДО на восстановленной
среде, проверка данных контента и БД Oracle;
o администратором выполняется поиск нужного документа, экспорт документа из
временной среды и импорт в продуктивный ландшафт.
54
После восстановления прикладных данных рекомендуется в ПО Documentum запускать
задание dm_ConsistencyChecker с целью выявления неконсистентных, поврежденных данных.
3. Восстановление прикладных данных ландшафта тестирования и разработки выполняется
полностью аналогично описанному выше процессу восстановления прикладных данных
продуктивного ландшафта.
4. Восстановление системных данных серверов всех ландшафтов производится с дисковых
резервных копий, сохраненных перед вводом систем в промышленную эксплуатацию. Для
восстановления серверов «с нуля»:
o сервер загружается через сеть;
o производится восстановление ОС сервера, системных дисковых разделов;
o полностью восстанавливаются системные данные с последней резервной копии.
5. Восстановление серверов среды виртуализации производится в следующем порядке:
o восстановление VMware ESX сервера;
o восстановление сервера управления виртуальной средой VMware;
o восстановление конфигурации виртуальной среды
Виртуальные машины восстанавливаются с резервных копий или шаблонов.
6. Порядок восстановления серверной среды при невозможности восстановления из резервной
копии:
a. Восстановление сервера СУБД:
Подготовить виртуальный сервер в соответствии с конфигурацией для
конкретного ландшафта;
Установить системное ПО (ОС и СУБД);
Сконфигурировать сервер СУБД или кластер серверов СУБД (в зависимости от
назначения ландшафта)
Восстановить базу данных из резервной копии
b. Восстановление сервера контента:
Подготовить виртуальные серверы для OpenText Documentum и NFS.
55
Установить системное ПО (ОС);
Восстановить параметры окружения;
Установить прикладное ПО (OpenText Documentum Content Server);
Сконфигурировать сервер контента и NFS в зависимости от назначения
ландшафта
Восстановить конфигурацию сервисов контента (параметры установки
прикладного ПО) из резервной копии
c. Восстановление сервера приложений:
Подготовить виртуальный сервер;
Установить системное ПО (ОС);
Сконфигурировать сервер приложений или группу серверов приложений в
зависимости от назначения ландшафта;
Восстановить параметры окружения;
Восстановить конфигурацию прикладных приложений (папки с приложениями)
из резервной копии.
56
6. Список Job и их параметры
6.1. Системные сервисы (JOB) и расписание их запуска
В настоящий момент системные сервисы Системы запускаются приложением rosatom-shark-quartz. Конфигурация этих джоб выполняется
в коде Системы и пакуется в war-файле приложения (по пути WEB-INF/classes/spring).
Таблица 12. Системные сервисы (JOB) и расписание их запуска.
Название Модуль Описание Способ реализации
(job или job+servlet)
Режим
запуска
Акти
вен
NotificationBalancerJob Базовый
блок
Балансировка очередей нотификаций.
Запускается с помощью
NotificationBalancerJobTrigger
Приложение rosatom-
shark-quartz
0 0/5 * * * ?1
Да
1 Режим запуска сервисов для приложения rosatom-shark-quartz задается в конфигурационных файлах самого приложения
57
Название Модуль Описание Способ реализации
(job или job+servlet)
Режим
запуска
Акти
вен
NotificationJob Базовый
блок
Отправка нотификаций.
Балансировщики:
NotificationJobTrigger_1
NotificationJobTrigger_2
NotificationJobTrigger_3
NotificationJobTrigger_4
NotificationJobTrigger_5
NotificationJobTrigger_6
NotificationJobTrigger_7
NotificationJobTrigger_8
NotificationJobTrigger_9
NotificationJobTrigger_10
Запускается с помощью NotificationJobTrigger
Приложение rosatom-
shark-quartz
0 0/15 * * * ?
Да
updateMonitorJob Базовый
блок
Монитор-Актив репликация обновлений.
Запускается с помощью updateDataTriger
Приложение rosatom-
shark-quartz
0 0 20 * * ?
Да
replicateDictionaryJob Базовый
блок
Монитор-Актив репликация справочников.
Запускается с помощью replicateDictionaryTriger
Приложение rosatom-
shark-quartz
0 0 20 * * ?
Да
replicateDocumentJob Базовый
блок
Монитор-Актив репликация документа.
Запускается с помощью replicateDocumentTrigger
Приложение rosatom-
shark-quartz
0 30 21 * * ?
Да
defaultApproveDocume
ntJob
Базовый
блок
Согласование по умолчанию.
Запускается с помощью
defaultApproveDocumentTrigger
Приложение rosatom-
shark-quartz
0 40/50 * * * ?
Да
58
Название Модуль Описание Способ реализации
(job или job+servlet)
Режим
запуска
Акти
вен
processServiceRequestsJ
ob
Базовый
блок
Обработка сохраненных запросов к веб-сервисам.
Запускается с помощью
processServiceRequestsTrigger
Приложение rosatom-
shark-quartz
0/30 * * * * ?
Да
periodicCommissionJob Базовый
блок
Периодические поручения.
Запускается с помощью periodicCommissionTrigger
Приложение rosatom-
shark-quartz
0 30 06 * * ?
Да
PeriodicNotificationGen
eratorJob
Базовый
блок
Генератор периодических нотификаций.
Запускается с помощью
PeriodicNotificationGeneratorJobTrigger
Приложение rosatom-
shark-quartz
0 0 8,13 * * ?
Да
ServiceDeskNotification
Job
Базовый
блок
Отправка запросов в техподдержку.
Запускается с помощью
ServiceDeskNotificationJobTrigger
Приложение rosatom-
shark-quartz
0 0/3 * * * ?
Да
ExchangeBy51Controlle
rJob
Обмен Распределение нагрузки по джобам сценария 5.1.
Запускается с помощью
ExchangeBy51ControllerTrigger
Приложение rosatom-
shark-quartz
55 1/02 * * * ?
Да
59
Название Модуль Описание Способ реализации
(job или job+servlet)
Режим
запуска
Акти
вен
ExchangeBy51Performe
rJob
Обмен Выполнения сценария 5.1 в заданной очереди.
Балансировщики:
ExchangeBy51PerformerTrigger01
ExchangeBy51PerformerTrigger02
ExchangeBy51PerformerTrigger03
ExchangeBy51PerformerTrigger04
ExchangeBy51PerformerTrigger05
ExchangeBy51PerformerTrigger06
ExchangeBy51PerformerTrigger07
ExchangeBy51PerformerTrigger08
ExchangeBy51PerformerTrigger09
ExchangeBy51PerformerTrigger10
Запускается с помощью
ExchangeBy51PerformerTrigger
Приложение rosatom-
shark-quartz
0 0/02 * * * ?
Да
Мониторинг состояния системных сервисов: Мониторинг состояния самих системных сервисов производится через Documentum
Administrator. Если системный сервис при последней отработке корректно завершался, то это отражено в его статусе. При корректной работе на
карточке системного сервиса в поле LAST STATUS должно отображаться «Completed», а также должно быть заполнено время последнего
выполнения (поле LAST RUN). Поле STATE системного сервиса должно быть «Active».
Процедура перезапуска системного сервиса: Дождаться окончания работы системного сервиса. Если системный сервис находится в статусе
Running и не останавливается, следует пользоваться способом из инструкции http://documentum-emc.blogspot.it/2012/04/how-to-unlock-job-in-
running-state.html. Дождаться автоматического запуска системного сервиса. В критическом варианте – перезапустить метод-сервер. Дождаться
автоматического запуска системного сервиса
60
6.2. Параметры системных сервисов (JOB)
Таблица 13. Параметры системных сервисов (JOB)
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_PeriodicNotific
ation
view
croc_notifiable_tasks,
которая выбирает
задачи со сроком
исполнения
Не
требуется
COMMISSION_NOTIFICATI
ON_PERIODS -
количество дней, за
которое надо отсылать
уведомления;
-SERVLETS_TIMEOUT –
таймаут сервлета;
-SERVLETS_URL – адреса
запускаемых сервлетов
По
умолчанию
При перезапуске системного сервиса,
и повторном вызове будут
обработаны только последние задачи
за период времени, а не весь объем
данных
61
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_checkscanconte
nt
com.croc.documentum.ro
satom.
methodserver.method.
CheckScanContentMetho
d.Query.
ATTACHMENTS_SCA
NNED_ONLY
Не
требуется
Для регулирования нагрузки на
системный сервис в параметрах
системного сервиса существует
возможность задавать перечень
кодов предприятий, сделки от
которых обрабатывает данный
системный сервис, например:
BAR_CODES1 000010;
BAR_CODES2 000020;
BAR_CODES3 000030.
Значения «000010», «000020»,
«000030» - первые цифры
штрих-кода, которые являются
кодом предприятия (кодом
учетной системы).
Если в Job Properties для
Method Arguments значения не
заданы, фильтра по учетным
системам нет – системный
сервис обрабатывает все
сделки.
Для распараллеливания
системных сервисов
существует возможность
создавать второй (третий и т.д.)
экземпляр системного сервиса
и для каждого системного
сервиса указывать те коды,
сделки которых должен
обрабатывать этот экземпляр.
При создании экземпляров
Отдельно с
уровнем
DEBUG в
файл erp-
integration.l
og
На момент составления описания:
select distinct r_object_id from
croc_document_attachment a
where is_scanned_only = TRUE and
document_id = '0000000000000000'
and exists ( select r_object_id from
croc_document_common b where
a.title = b.r_object_id)
Ищет и обрабатывает все сканы,
вложенных в документы (создает
задания на проверку
отсканированных файлов).
Достаточно ресурсоемкая операция,
обрабатывается около 2 тысяч
вложений.
Ограничения по времени нет, но
учитывая что обрабатываются
небольшие объемы записей,
удаление из выборки
нецелесообразно
62
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_NotificationDel
ivery
croc_notification по
флагу is_delivered
Не
требуется
-THREAD_COUNT –
количество потоков
обработки;
-SEND_TIMEOUT – время
отправки одного письма
По
умолчанию
Увеличение количества потоков
обработки увеличивает скорость
обработки очереди неотправленных
нотификаций. По умолчанию
используется два потока.
Время отправки задает промежуток
времени по истечении которого
отправка прерывается, и считается
что сессия неактивна и создается
новая для следующих нотификаций.
По умолчанию 60 секунд на письмо.
Довольно ресурсоемкая задача, так
как в день в среднем создается
порядка 100 тысяч нотификаций
croc_ExpiredDealNo
tification
dm_dbo.check_deal_task
s_view
Не
требуется
Нет По
умолчанию
Создает нотификации. Отправкой
нотификаций не занимается.
croc_AutoDealCreat
ion
croc_deal_register Не
требуется
Нет По
умолчанию
Обрабатывает несколько десятков
записей
croc_JobLoadIncom
eDocuments
- Не
требуется
Нет По
умолчанию
63
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_unlockdocume
nt
croc_lock Не
требуется
Входные параметры:
APPLICATION_URL – адрес
запуска метода.
Параметры работы:
lockDateTo Разрешенный
срок блокировки (формат
‘dd.MM.yyyy’). При
отсутствии берется
максимальный срок
блокировки документа
через
RepositoryConfiguration;
lockOwnerId Идентификатор
владельца блокировки, при
отсутствии не участвует в
запросе в качестве
критерия
- Обрабатывает блокировки, у
которых дата создания меньше
определенной даты.
При падении или длительном
отсутствии запуска обработает
записи за пропущенное время.
Разблокировка происходит через
LockService. Сервис служит в
качестве надстройки, фактическое
удаление объекта происходит через
интерфейс
IDfPersistentObject.destroy()
croc_ContractCancel
lation
dm_dbo.croc_signing_co
ntracts
Не
требуется
Нет По
умолчанию
Обрабатывает записи за последние
MAXIMUN_AFTER_SIGN_DAYS_
WAIT дней.
На момент описания
MAXIMUN_AFTER_SIGN_DAYS_
WAIT = 90 дней.
При запуске после длительного
простоя будет обработано больше
документов, чем обычно
64
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_PeriodicComm
ission
croc_periodic_commissio
n
Не
требуется
Нет По
умолчанию
Обрабатывает записи, которые
находятся в статусе
CommissionLifeCyclePolicyModel.
LifeCycleStateName.EXECUTE
При отсутствии запуска или сбоя
периодические поручения не
пересоздаются
croc_JobUnloadDoc
uments
- Не
требуется
Нет По
умолчанию
Обрабатывает по 128 записей за один
запуск
croc_UpdateSubstitu
teGroup
- Не
требуется
Нет По
умолчанию
Обрабатывает по 100 записей за один
запуск
croc_TruncateSubsti
tuteHistory
- Не
требуется
Нет По
умолчанию
Обрабатывает по 100 записей за один
запуск
65
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_repositorydatae
xchange
crc_repodataexch_out_qu
eue
Не
требуется
1) -
PROCESSING_QUEUE_SIZE -
количество обрабатываемых
сообщений за один запуск
джоба (по умолчанию «500»);
2) -THREAD_COUNT -
количество одновременно
обрабатываемых сообщений
(многопоточность) (по
умолчанию «1» - является
рекомендуемым значением, так
как увеличение этого параметра
приводит к увеличению
потребляемых системой
ресурсов).
По
умолчанию
Обрабатывает
croc_case_pass_hist
ory
croc_arch_doc_pass_hist. Не
требуется
Нет По
умолчанию
Создает на основании данных
уведомление и нотификацию
croc_warrant_notific
ations
croc_document_warrant Не
требуется
Нет По
умолчанию
Создает нотификации и уведомления
по доверенностям
croc_DutyPaymentT
askCreator
croc_protection_duty Не
требуется
Нет По
умолчанию
Обрабатывает записи, у которых
Плановая дата более 60 дней от
текущей
66
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_defaultapprovet
ype
Собирает задачи по
подразделению (если
стоит соответствующая
настройка в
справочнике).
Не
требуется,
при сбое
необходимо
запустить
повторно
Нет По
умолчанию
croc_JobLoadMedo
Notices
- Не
требуется
Нет По
умолчанию
croc_JobUnloadMed
oNotices
- Не
требуется
Нет По
умолчанию
croc_WorkDelegatio
n
croc_job Не
требуется
SERVLET_TIMEOUT –
таймаут сервлета;
APPLICATION_URL – адрес
сервера, на котором будет
запущена передача дел.
По
умолчанию
croc_cert_auth_notif
ications
croc_document_cert_auth
, croc_task
Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару сотен записей.
Отвечает за автоматическое
закрытие документов
croc_license_nearby
_end
croc_document_license,
croc_lifecycle_policy
Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару сотен записей.
Создает уведомления
67
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_license_nuclear
_install
croc_document_license Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Создает нотификации
croc_license_nuclear
_weapon
croc_document_license Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Создает нотификации
croc_lodge_notificat
ions
croc_document_lodge Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Рассылает уведомления
croc_ProtectionDoc
ValidInfo
croc_document_protectio
n
Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Рассылает уведомления
croc_SessionNotific
ation
dm_dbo.as_notificationcr
eator_view
Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Сами нотификации не
рассылает
croc_ActioAppealN
otification
dm_dbo.as_notificationcr
eator_view
Не
требуется
Нет По
умолчанию
Не ресурсоемкая операция,
обрабатывается пару десятков
записей. Сами нотификации не
рассылает
croc_comm_journal
_denorm
dm_dbo.croc_comm_jour
nal_denorm
Не
требуется
Нет По
умолчанию
Ресурсоемкая операция,
обрабатывается около 35 тысяч
записей.
Оптимизации не подлежит
68
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_checkscanconte
nt_01-06
com.croc.documentum.ro
satom.
methodserver.method.
CheckScanContentMetho
d.Query.
ATTACHMENTS_SCA
NNED_ONLY
Не
требуется
Является экземпляром
системного сервиса
croc_checkscancontent, описание
параметров см. в описании
croc_checkscancontent.
Отдельно с
уровнем
DEBUG в
файл erp-
integration.l
og
На момент составления описания:
select distinct r_object_id from
croc_document_attachment a
where is_scanned_only = TRUE and
document_id = '0000000000000000'
and exists ( select r_object_id from
croc_document_common b where
a.title = b.r_object_id)
Ищет и обрабатывает все сканы,
вложенных в документы (создает
задания на проверку
отсканированных файлов).
Достаточно ресурсоемкая операция,
обрабатывается около 2 тысяч
вложений.
Ограничения по времени нет, но
учитывая, что обрабатываются
небольшие объемы записей,
удаление из выборки
нецелесообразно
croc_JobLoadMED
OMessages
- Не
требуется
Нет По
умолчанию
croc_ClearTrashAcl dm_dbo.trash_acl_ids_bu
lk_view
Не
требуется
Нет По
умолчанию
Выполняет наборы процедур,
которые очищают корзину ACL
69
Название Источник данных в
БД
Восстановл
ение Входные параметры
Логирован
ие Примечание
croc_allocateworkde
legation
- Не
требуется
SERVLET_TIMEOUT
"Timeout сервлета"(по
умолчанию 3 минуты);
APPLICATION_URL "URL
приложения"
(множественное значение)
По
умолчанию
Пример:
-SERVLET_TIMEOUT 10, -
APPLICATION_URL
http://localhost:7777/rosatom2/, -
APPLICATION_URL
http://localhost:7777/rosatom3/
croc_contractactivati
oncopyincase
- Не
требуется
Нет По
умолчанию
croc_ViolationPerio
dicNotification
- Не
требуется
Нет По
умолчанию
mtd_NdPeriodicNoti
ficationMethod
- Не
требуется
Нет По
умолчанию
70
VI Техническое решение по созданию, установке и настройке отдельной
инсталляции системы ЕОСДО на основе существующего решения
ОБЩИЕ СВЕДЕНИЯ
1.1 Термины, сокращения и определения
В данном документе использованы следующие термины и сокращения (см. Error!
Reference source not found.).
Таблица 2. Термины, сокращения и определения
Термин/сокращение Определение
ГК «Росатом» Государственная корпорация по атомной энергии «Росатом»
ДЗО Дочерние и зависимые общества
ЕОСДО Единая отраслевая система электронного документооборота
Ландшафт;
Системный
ландшафт
Группа взаимосвязанных систем, объединенных по признаку
функционального предназначения. В рамках данного Проекта
системные ландшафты могут быть представлены следующими
группами: разработка, тестирование, продуктив.
Перенос функциональности между ландшафтами Системы
осуществляется путем переноса релиза.
ОШС Организационно-штатная структура
Проект Проект «Система электронного документооборота для организаций
Госкорпорации «Росатом»»
ПО Программное обеспечение
Репозиторий Место, где хранятся и поддерживаются данные системы
Система ЕОСДО
ТЗ Техническое задание на выполнение работ по проекту «Система
электронного документооборота для организаций Госкорпорации
«Росатом»»
ТР Техническое решение по созданию, установке и настройке
отдельной инсталляции системы ЕОСДО на основе существующего
решения
ЦОД Центр обработки данных ГК «Росатом»
ФИО Фамилия, имя и отчество
71
1.2 Цель технического решения
Целью разработки данного технического решения является описание процесса создания,
установки и настройки отдельной инсталляции системы ЕОСДО на основе существующего
решения ЕОСДО, без клонирования репозитория ЕОСДО.
2 ПРИНЦИПЫ СОЗДАНИЯ ОТДЕЛЬНОЙ ИНСТАЛЛЯЦИИ
Отдельная инсталляция системы реализуется в соответствии со следующими принципами:
1) Система создается, устанавливается и настраивается на основе единого (действующего)
решения ЕОСДО на платформе OpenText Documentum версии 7.2.
2) Дистрибутив системы включает в себя: war-файл приложения системы rosatom-eosdo, war-
файл приложения для выполнения автоматических активностей rosatom-shark-quartz, war-
файл интеграционного приложения rosatom-shark-integration.war, zip-файл с артефактами
JMS rosatom-method-server (перечисленные артефакты аналогичны артефактам системы
ЕОСДО), а также пакет скриптов и утилит, выполнение которых позволит системе
функционировать в рамках сценариев, зафиксированных в ТЗ.
3) Для первоначального заполнения справочных данных в системе создается отдельная
программа (инсталлятор), которая позволяет автоматически заполнить начальные
справочные данные, необходимые для старта работы системы.
72
3 ПЕРЕНОС МОДЕЛИ ДАННЫХ DOCUMENTUM
Для функционирования новой инсталляции системы необходимо перенести следующие
объекты модели данных Documentum из существующей системы (в указанном порядке):
1. Типы данных (dm_type).
2. Форматы (dm_format).
3. Типы связей (dm_relation_type).
4. Группы и роли (dm_group).
5. Кабинеты (dm_cabinet).
6. Папки (dm_folder) с сохранением иерархии.
7. Наборы значений (dm_alias_set).
8. Методы (dm_method).
9. Джобы (dm_job).
10. Модули (dmc_module).
11. Библиотеки (dmc_java_library).
12. Jar-файлы (dmc_jar).
13. Зарегистрированные объекты базы данных (dm_registered).
При переносе групп исключить стандартные группы и группы, созданные для
конкретных подразделений (group_name содержит идентификаторы). При переносе групп в
рамках данного проекта использовался запрос:
select * from dm_group where (group_name like 'crc_%' or group_name like 'croc_%' or
group_name like 'ga_%') and group_name not like '%0b00012d%' and group_name not like
'%0c00012d%' and group_name not like '%1100012d%'
При переносе кабинетов и папок учесть, что в системе ЕОСДО многие справочные
объекты представлены типами-наследниками dm_folder. На данном этапе нужно исключить
перенос объектов пользовательских типов. Кроме того нужно исключить папки, созданные для
пользователей. Нужно перенести кабинеты DICT и Root_Cabinet.
При переносе зарегистрированных объектов базы данных исключить перенос
стандартных объектов. В рамках данного проекта для переноса зарегистрированных объектов
использовался запрос:
select * from dm_registered where object_name not like 'dm_%' and object_name not like
'dmi_%'
Перенос объектов необходимо выполнить и для основного и для архивного репозиториев
(из основного репозитория в основной, из архивного репозитория в архивный).
73
В рамках данного проекта для переноса модели данных Documentum использовалась
утилита WASABI. Краткое описание утилиты приведено в пункте 0 данного документа.
4 ПЕРЕНОС СПРАВОЧНЫХ ОБЪЕКТОВ
Для функционирования новой инсталляции системы в рамках сценариев,
зафиксированных в ТЗ, необходимо перенести следующие справочные объекты* из
существующей системы (в указанном порядке):
1. croc_corporate_root (узел «Корпоративный архив»);
2. crc_dict_departments_root (корень для объектов ОШС);
3. croc_archive_org_root (корень для архивных папок);
4. crc_dict_org_positions (корень для объектов должностей);
5. crc_dict_users_root (корень для объектов пользователей);
6. crc_dict_chief_user_root (корень для объектов справочника подчиненности);
7. croc_inbox_kinds (справочник вариантов вида узла Задания/Уведомления);
8. crc_dict_inbox_doctype (справочник для фильтра «Тип документа» в узле
Задания/Уведомления);
9. crc_dict_deliv_type_root (корень для объектов справочника «Способы доставки»);
10. crc_dict_delivery_type (объекты справочника «Способ доставки»);
11. crc_dict_delivery_subtype (вложенные объекты справочника «Способ доставки)
12. crc_dict_dockind (корень для объектов шаблонов рег.номеров);
13. crc_dockind_group (типы и подтипы документов с шаблонами рег.номеров);
14. crc_dict_dockind_names_root (корень для объектов справочника «Наименования видов
документов»);
15. crc_dict_dockind_name (объекты справочника «Наименования видов документов»);
16. crc_dict_relations_root (корень для объектов справочника «Виды взаимосвязей»);
17. crc_dict_relation (объекты справочника «Виды взаимосвязей»);
18. crc_dict_urgent_param_root (корень для объектов справочника «Параметры срочности»);
19. crc_dict_urgent_param (объекты справочника «Параметры срочности»);
20. crc_dict_confer_type_root (корень для объектов справочника «Виды заседаний»);
21. crc_dict_conference_type (объекты справочника «Виды заседаний»);
22. crc_dict_object_root (корень для объектов справочника «Объекты»);
23. croc_confidential_types (объекты справочника «Доступ»);
24. crc_dict_role_info (объекты справочника «Виды конфиденциальности»);
25. crc_dict_commissions_root (корень для объектов справочника «Типовые поручения»);
26. ga_corp_question_kind_root (корень для объектов справочника «Виды корпоративных
вопросов»);
27. ga_corp_question_kind (объекты справочника «Виды корпоративных вопросов»);
28. croc_attachment_types (объекты справочника «Вид вложения»);
29. ga_attr_value_list (системные списки значений);
30. croc_policies_types (справочник политик доступа);
31. croc_card_config (настройки карточек системы);
32. ga_attachment_kind_root (корень для объектов справочника «Наименования видов
вложений»);
33. crc_dict_case_spec_root (корень для объектов справочника «Особенности дела»);
74
34. crc_dict_cases_root (корень для объектов справочника «Дела»);
35. crc_dict_case_type_root (корень для объектов справочника «Наименования типов дел»);
36. crc_dict_corrgroups_root (структура для объектов справочника «Группы рассылки по
корреспондентам»);
37. crc_dict_emplgroups_root (корень для объектов справочника «Управление группами»);
38. crc_dict_arch_heading_root (корень для объектов справочника «Рубрики архива»);
39. crc_dict_topic_root (корень для объектов справочника «Тематики»);
40. crc_dict_mailinggroups_root (корень для объектов справочника «Группы рассылки»);
41. crc_dict_addressees (корень для справочника «Корреспонденты»);
42. ga_hpsm_routing_table_root (корень для объектов справочника «Таблица маршрутизации
обращений»);
43. mr_template (шаблоны отчетов для системы «Отчеты»).
* - Список справочников может быть актуализирован по согласованию с Заказчиком.
5 ОПИСАНИЕ УТИЛИТЫ WASABI
Wasabi – это утилита инкрементной загрузки данных из источника в приемник. В качестве
источника и приемника могут выступать репозиторий Documentum и файлы разных форматов.
Утилита представляет из себя запускаемый jar-файл.
В использованной реализации Wasabi могут быть выгружены (и загружены) следующие объекты
Documentum:
1. dm_alias_set
2. dm_format
3. dm_type
4. dm_relation_type
5. dm_group
6. dm_cabinet
7. dm_acl
8. dm_folder
9. dm_method
10. dm_job
11. dmc_module
12. dmc_jar
13. dm_registered
В качестве источника выгрузки объектов модели данных Documentum был использован
репозиторий Documentum тестовой системы ЕОСДО.
В текущей реализации Wasabi могут быть выгружены следующие справочники ЕОСДО:
1. croc_inbox_kinds
75
2. crc_dict_departments_root
3. croc_archive_org_root
4. crc_dict_org_positions
5. crc_dict_users_root
6. crc_dict_deliv_type_root
7. crc_dict_delivery_type
8. crc_dict_dockind_names_root
9. crc_dict_dockind
10. crc_dict_dockind_name
11. crc_dict_relations_root
12. crc_dict_relation
13. crc_dict_urgent_param_root
14. crc_dict_urgent_param
15. crc_dict_confer_type_root
16. crc_dict_conference_type
17. crc_dict_object_root
18. croc_confidential_types
19. crc_dict_role_info
20. crc_dict_commissions_root
21. ga_corp_question_kind_root
22. ga_corp_question_kind
23. ga_attr_value_list
24. croc_policies_types
25. crc_dockind_group
26. croc_corporate_root
27. croc_card_config
28. ga_attachment_kind_root
29. crc_dict_inbox_doctype
30. crc_dict_case_spec_root
31. crc_dict_cases_root
32. crc_dict_case_type_root
33. crc_dict_corrgroups_root
34. crc_dict_emplgroups_root
35. crc_dict_arch_heading_root
36. crc_dict_delivery_subtype
37. crc_dict_chief_user_root
38. croc_attachment_types
39. crc_dict_deal_kind_root
40. crc_dict_mailinggroups_root
41. crc_dict_addressees
42. ga_hpsm_routing_table_root
43. mr_template
В качестве источника выгрузки справочников был использован репозиторий Documentum
продуктивной системы ЕОСДО.
76
В ходе выгрузки утилита последовательно отбирает перечисленные объекты, создает
java-бины для этих объектов и сохраняет их в базовом java-объекте WasabiObjects. Дальнейшая
обработка зависит от приемника.
В качестве приемника выгрузки был использован формат сериализованного в файл
объекта WasabiObjects.
При загрузке в инсталляцию системы используется обратная конфигурация – источником
служит файл с сериализованным объектом WasabiObjects, приемником – целевой репозиторий
системы. Утилита выполняет операции создания и обновления объектов, но не выполняет
операции удаления объектов (в том числе, не удаляет атрибуты, если они уже были созданы в
целевом репозитории, но их нет в источнике). При загрузке каждого объекта производится поиск
ранее загруженного объекта в целевом репозитории по ключевому полю. В случае если объект не
был загружен – он создается. В случае существования объекта – обновляется.
6 ПЕРЕНОС ЭЛЕМЕНТОВ СТРУКТУРЫ БАЗЫ ДАННЫХ
Для функционирования новой инсталляции системы необходимо перенести следующие
элементы структуры базы данных из существующей системы (в указанном порядке):
1. Типы (type)
2. Таблицы (table)
3. Пакеты (package)
4. Функции (function)
5. Представления (view)
6. Последовательности (sequence)
7. Триггеры (trigger)
8. Журналы материализованных представлений (materialized view log)
9. Материализованные представления (materialized view)
10. Процедуры (procedure)
11. Индексы (index)
12. Джобы (user_scheduler_jobs)
В рамках данного проекта для переноса структуры базы данных использовались скрипты
DDL, сформированные с помощью инструмента SQLDeveloper. Во всех сформированных
скриптах DDL нужно заменить схему на ROSATOM (или удалить ее).
При формировании скриптов для создания таблиц и представлений необходимо
исключить стандартные объекты базы данных и объекты, автоматически созданные Documentum
CS. В рамках данного проекта для формирования DDL по таблицам был использован запрос:
77
select dbms_metadata.get_ddl(object_type, object_name, owner)
from
(
select
owner,
object_name,
decode(object_type,
'DATABASE LINK', 'DB_LINK',
'JOB', 'PROCOBJ',
'RULE SET', 'PROCOBJ',
'RULE', 'PROCOBJ',
'EVALUATION CONTEXT', 'PROCOBJ',
'CREDENTIAL', 'PROCOBJ',
'CHAIN', 'PROCOBJ',
'PROGRAM', 'PROCOBJ',
'PACKAGE', 'PACKAGE_SPEC',
'PACKAGE BODY', 'PACKAGE_BODY',
'TYPE', 'TYPE_SPEC',
'TYPE BODY', 'TYPE_BODY',
'MATERIALIZED VIEW', 'MATERIALIZED_VIEW',
'QUEUE', 'AQ_QUEUE',
'JAVA CLASS', 'JAVA_CLASS',
'JAVA TYPE', 'JAVA_TYPE',
'JAVA SOURCE', 'JAVA_SOURCE',
'JAVA RESOURCE', 'JAVA_RESOURCE',
'XML SCHEMA', 'XMLSCHEMA',
object_type
) object_type
from dba_objects
where owner in ('ROSATOM')
and object_type in ('TABLE')
and object_name not like '%_S' and object_name not like '%_R'
and object_name not like 'SYS_EXPORT_SCHEMA%'
and object_name not like 'MLOG$_%' and object_name not like 'dm_%'
and object_name not like 'dmi_%'
and object_name not in ('DUAL', 'SQLN_EXPLAIN_PLAN', 'TOAD_PLAN_TABLE',
'DMI_OBJECT_TYPE')
and (owner, object_name) not in (select owner, table_name from
dba_nested_tables)
and (owner, object_name) not in (select owner, table_name from dba_tables
where iot_type = 'IOT_OVERFLOW')
)
order by object_name;
Для формирования DDL по представлениям был использован запрос:
78
select dbms_metadata.get_ddl(object_type, object_name, owner)
from
(
select
owner,
object_name,
decode(object_type,
'DATABASE LINK', 'DB_LINK',
'JOB', 'PROCOBJ',
'RULE SET', 'PROCOBJ',
'RULE', 'PROCOBJ',
'EVALUATION CONTEXT', 'PROCOBJ',
'CREDENTIAL', 'PROCOBJ',
'CHAIN', 'PROCOBJ',
'PROGRAM', 'PROCOBJ',
'PACKAGE', 'PACKAGE_SPEC',
'PACKAGE BODY', 'PACKAGE_BODY',
'TYPE', 'TYPE_SPEC',
'TYPE BODY', 'TYPE_BODY',
'MATERIALIZED VIEW', 'MATERIALIZED_VIEW',
'QUEUE', 'AQ_QUEUE',
'JAVA CLASS', 'JAVA_CLASS',
'JAVA TYPE', 'JAVA_TYPE',
'JAVA SOURCE', 'JAVA_SOURCE',
'JAVA RESOURCE', 'JAVA_RESOURCE',
'XML SCHEMA', 'XMLSCHEMA',
object_type
) object_type
from dba_objects
where owner in ('ROSATOM')
and object_type in ('VIEW')
and object_name not like '%_SP' and object_name not like '%_RP'
and object_name not like '%_SV' and object_name not like '%_RV'
and not (object_type = 'TYPE' and object_name like 'SYS_PLSQL_%')
and (owner, object_name) not in (select owner, table_name from
dba_nested_tables)
and (owner, object_name) not in (select owner, table_name from
dba_tables where iot_type = 'IOT_OVERFLOW')
)
order by object_name;
После установки всех объектов в базу, нужно скомпилировать инвалидные объекты.
На окружениях системы присутствует конфигурация с архивной СУБД, данные в
которую передаются через Archive Link. Перенос данных из сконфигурированной СУБД в
архивную осуществляется штатными средствами Oracle, чтобы избежать необходимости
повторных операций.
79
2 7. НАСТРОЙКА РЕПОЗИТОРИЯ DOCUMENTUM
Для функционирования новой инсталляции системы необходимо выполнить скрипты для
разрешения работы с динамической группой dm_superusers_dynamic.
DQL: update dm_group object set is_protected=0 where
group_name='dm_superusers_dynamic'
API: retrieve,c,dm_group where group_name='dm_superusers_dynamic'
append,c,l,groups_names
dm_world
save,c,l
8. СОЗДАНИЕ СИСТЕМНЫХ НАСТРОЕК ЕОСДО
Для функционирования новой инсталляции системы необходимо создать объекты
системных настроек ga_system_settings. В частности настройки cma, DeleteInformations, jdbs,
shark, smtp, Для создания настроек используется DQL-скрипт, адаптируемый для каждой целевой
площадки.
9. ДОБАВЛЕНИЕ КОНФИГУРАЦИИ ДЛЯ ЛАНДШАФТА СИСТЕМЫ В КОД
В код системы необходимо добавить конфигурационные файлы и профиль для сборки
артефактов для новых площадок
80
VII ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ
Лист регистрации изменений
Из
м.
Номера листов (страниц) Всего
листов
(стра-
ниц) в
докум.
№
документа
Входящий
№ сопро-
водительного
докум. и
дата
Под
п.
Да
та
изме-
ненны
х
заме-
ненн
ых
новы
х
анну-
лиро-
ванных