Руководство по системному администрированию#

Сценарии администрирования#

Администрирование базы и схемы данных#

Создание пользователя и табличных пространств#

Все действия выполняются администратором целевой БД.

Предварительно на сервере БД должны быть установлены Pangolin (PSQL), pgBouncer, а также должна быть создана база данных.

В примере вместо значений имя_пользователя, имя_схемы, имя_БД и пароль_пользователя нужно подставить свои значения. По умолчанию имя пользователя, БД и схемы имеют наименование mdmp.

Следует выполнить следующие действия:

1. Создать пользователя-владельца и схему mdmp (название можно выбрать иное), придумать пароль.

   CREATE USER имя_пользователя WITH
   PASSWORD 'пароль_пользователя'
   LOGIN
   NOSUPERUSER
   INHERIT
   NOREPLICATION;
    
   CREATE SCHEMA имя_схемы AUTHORIZATION имя_пользователя;
   

2. Создать под пользователем ОС папки табличных пространств mdmp_model_data, mdmp_big_model_data, mdmp_big_model_idx через sudo mkdir на любом достаточно свободном разделе на усмотрение администратора компонента NSIX и задать владельца этой папки и его группу как Pangolin (PSQL) (название может отличаться).

   sudo mkdir путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске
   sudo mkdir путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске
   sudo mkdir путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске
   sudo mkdir путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске
   sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске
   sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске
   sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске
   sudo chown postgres:postgres путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске
   

3. Cоздать в БД сами табличные пространства.

   CREATE TABLESPACE mdmp_model_data OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_MODEL_DATA_на_диске';
   CREATE TABLESPACE mdmp_big_model_data OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_BIG_MODEL_DATA_на_диске';
   CREATE TABLESPACE mdmp_model_idx OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_MODEL_IDX_на_диске';
   CREATE TABLESPACE mdmp_big_model_idx OWNER mdmp LOCATION 'путь_к_табличному_пространству_MDMP_BIG_MODEL_IDX_на_диске';
   

4. Выдать права пользователю.

   GRANT CONNECT ON DATABASE имя_БД TO имя_пользователя;
   GRANT CREATE ON TABLESPACE mdmp_model_data TO имя_пользователя;
   GRANT CREATE ON TABLESPACE mdmp_big_model_data TO имя_пользователя;
   GRANT CREATE ON TABLESPACE mdmp_big_model_idx TO имя_пользователя;
   GRANT CREATE ON SCHEMA имя_схемы TO имя_пользователя;
    
   GRANT ALL PRIVILEGES ON SCHEMA имя_схемы TO имя_пользователя;
   GRANT USAGE ON SCHEMA имя_схемы TO имя_пользователя;
   GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA имя_схемы TO имя_пользователя;
   GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA имя_схемы TO имя_пользователя;
   

5. Создать роль MDMP_APPL_ROLE и пользователя MDMP_APPL для доступа приложений без права удаления схемы, выдать им права на БД и схему, созданные в предыдущем пункте.

   CREATE ROLE IF NOT EXISTS mdmp_appl_role WITH PASSWORD 'пароль_пользователя';
   GRANT CONNECT ON DATABASE имя_БД TO mdmp_appl_role;
   GRANT USAGE ON SCHEMA имя_схемы TO mdmp_appl_role;
   GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA имя_схемы TO mdmp_appl_role;
   GRANT SELECT, USAGE ON ALL SEQUENCES IN SCHEMA имя_схемы TO mdmp_appl_role;
     
   CREATE USER mdmp_appl
   WITH PASSWORD 'пароль_пользователя'
   LOGIN
   NOCREATEDB
   NOCREATEROLE
   NOSUPERUSER
   INHERIT
   IN ROLE MDMP_APPL_ROLE
   NOREPLICATION
   NOBYPASSRLS;
     
   GRANT CONNECT ON DATABASE имя_БД TO mdmp_appl;
   GRANT mdmp_appl_role TO mdmp_appl;
   ALTER ROLE mdmp_appl_role SET search_path TO имя_схемы;
   ALTER user mdmp_appl SET search_path TO имя_схемы;
   

Переименование схемы БД и смена владельца#

Все действия выполняются администратором целевой БД.

Переименование схемы осуществляется командой:

ALTER SCHEMA имя_схемы RENAME TO новое_имя_схемы;

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

Смена владельца осуществляется командой:

ALTER SCHEMA имя_схемы OWNER TO имя_нового_пользователя;

Затем нужно сменить владельца всех таблиц и последовательностей схемы следующей процедурой:

DO $$
DECLARE
                query_line varchar(1000);
                rec RECORD;
                m_schemaName VARCHAR(100);
BEGIN
                m_schemaName := 'новое_имя_схемы';
                FOR rec IN (select PT.schemaname || '.' || PT.tablename TAB from pg_tables PT
                                                               where PT.schemaname = m_schemaName and PT.tableowner <> m_schemaName)
                LOOP
                               EXECUTE 'alter table if exists ' || rec.TAB || ' owner to '|| m_schemaName;
                END LOOP;
 
                FOR rec IN (select PS.schemaname || '.' || PS.sequencename SEQ from pg_sequences PS
                                                               where PS.schemaname = m_schemaName and PS.sequenceowner <> m_schemaName)
                LOOP
                               EXECUTE 'alter sequence if exists ' || rec.SEQ || ' owner to '|| m_schemaName;
                END LOOP;
END;
$$

Архивация дампов, копирование и восстановление#

Все действия выполняются администратором целевой БД.

Для копирования схемы с данными на другие сервера БД или создания копии, а также сохранения архива в целях резервирования следует использовать утилиты pg_dump и pg_restore от имени администратора Pangolin (PSQL).

Важная особенность — имя воссоздаваемой схемы должно совпадать с именем исходной.

Для запуска создания дампа в ОС от имени администратора БД следует использовать команду вида:

pg_dump --verbose --host=<имя_хоста> --port=<номер_порта> -d <имя_БД> --schema=<имя_схемы> --username=<имя_пользователя> --format=custom --file=/путь_к_файлу_дампа

Где <имя хоста> - доменное имя или ip-адрес сервера БД, с которого осуществляется снятие дампа (localhost если сервер БД и сервер с установленной утилитой одинаковые).

Можно не указывать "username" если предусмотрена авторизация по умолчанию от имени администратора.

Допустимые форматы

Путь к файлу дампа должен располагаться в директории, к которой у пользователя Pangolin (PSQL) есть полный доступ, а на разделе имеется достаточно свободного места.

Рекомендуется использовать разделы /pgbackup или /pgarclogs, где, как правило, есть свободное место.

Не рекомендуется использоваться раздел /pgdata, где место требуется для самой БД.

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

• переименовать исходную схему в новую (смотреть раздел в данном документе Переименование схемы БД и смена владельца);

• создать пользователя-владельца для новой схемы и переназначить на него объекты схемы (смотреть раздел в данном документе Переименование схемы БД и смена владельца);

• создать новую пустую схему и выдать права на нее исходному пользователю;

• восстановление из дампа осуществляется на пустую схему командой вида:

  pg_restore --verbose --host=<имя_хоста> --port=5432 -d <имя_БД> --schema=<имя_схемы> --username=<имя_пользователя> /путь_к_файлу_дампа
  

Конфигурация сервера приложений среды контейнеризации для компонента NSIX#

Создание и настройка ролевых прав пользователей#

Все действия выполняются администратором целевой БД.

Для добавления прав учетных записей пользователей в среду контейнеризации требуется зайти в меню User Management — Role Bindings, и нажать кнопку Create Binding.

Имя ролевой связки может быть любым (для улучшенной навигации желательно указывать имя пользователя и роли).

Имя роли выбирается из списка доступных. Если роли с нужными правами нет, ее можно создать в меню User Management — Roles, взяв за основу одну из существующих ролей и отредактировав необходимые права в yaml формате.

Имя пользователя — как в нужном домене.

Настройка параметров приложений#

Все действия выполняются администратором целевой БД.

Параметры приложений задаются в меню Workloads — Config Maps.

Для изменения настроек следует открыть файл yaml и отредактировать нужные конфигурации:

• nsix-cm-mdc — общие параметры приложений для внешних сервисов, такие как активность и хост компонента Аудит (AUDT) продукта Platform V Audit SE (AUD);

• nsix-cm-mdc-db — параметры схемы БД, кроме пароля;

• nsix-cm-mdc-ivs, nsix-cm-mdc-kmd, nsix-cm-mdc-jobs, nsix-cm-mdc-api — параметры конкретных модулей;

• nsix-cm-mdc-fluent-bit — параметры системы fluent bit в виде конфигурационного файла .conf, встроенного в yaml; Настройки параметров secrets редактируются в разделе Workloads — Secrets.

Используются secrets с переменной JDBC.MDC_POSTGRES.PASSWORD, содержащей пароль БД, и с переменной DBC.MDC_POSTGRES.USER, содержащей имя пользователя.

В Config Maps среды контейнеризации модуля cm-mdc присутствуют параметры:

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

• OTHER_KMD_ENABLED, в котором при значении true модуль mdc-kmd включен, при значении false модуль mdc-kmd отключен.

Получение токенов удаленного доступа#

Все действия выполняются администратором целевой БД.

Для выполнения удаленного доступа к пространству Kubernetes или OpenShift (опционально) из внешних заданий Jenkins следует использовать токен сервис-аккаунта.

Для этого необходимо:

• войти в меню User management — Service Account;

• выбрать нужный сервис аккаунт (обычно jenkins);

• пролистать вниз страницу сервис-аккаунта, выбрать secret вида имя аккаунта-token;

• в разделе Data нажать Revel values и скопировать значение последнего поля token. В дальнейшем использовать его в нужном задании Jenkins (например, зашифровать и добавить в репозиторий задания Jenkins, либо добавить в credentials).

Запуск/Перезапуск#

Все действия выполняются администратором целевой БД.

После установки приложений их pods по умолчанию стартуют автоматически.

Для перезапуска модулей нужно войти в меню Workloads — Deployment Configs.

После этого открыть конфигурацию развертывания нужного модуля и либо отредактировать его с изменением (рестарт пойдет автоматически), либо во вкладке Replication Controllers удалить текущий контроллер реплик (после удаления активного контроллера автоматически создается новый с запуском нового pod), либо в свернутом меню Actions выбрать Start rollout (в этом случае создается новый контроллер без удаления старого).

Необходимо убедиться, что в разделе Workloads — Pods все pods egress / ingress (если он используется), а также pods модулей mdc-api, mdc-jobs, mdc-ivs, mdc-kmd, mdc-ui запущены (находятся в статусе Running) и не содержат ошибок, а pods с таким же именем и названием deploy завершены.

Конфигурация ролевой модели#

Все действия выполняются администратором целевой БД.

Файл с ролевой моделью включается в поставку и при развертывании прикладного проекта загружается в AUTZ. Загрузка может быть осуществлена с помощью Pipeline, либо сотрудниками в АРМ AUTZ в том случае если инструменты DevOps Pipeline не функционируют. Загруженные привилегии могут быть включены в существующие в AUTZ наборы привилегий, либо для них могут быть созданы новые наборы. Управление наборами привилегий осуществляется в АРМ AUTZ. Набор привилегий назначается пользователю по условию включения данного пользователя в привязанную к набору привилегий группе пользователей.

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

Работа с системным журналом#

Включение, отключение, настройка размера, выбор уровня журналирования выполняется путем конфигурирования в консоли среды контейнеризации сущности ConfigMap с именем nsix-cm-mdc-fluent-bit в формате fluentbit.

Настройка правил безопасности на граничных прокси (Ingress, Egress)#

Все входящие и исходящие соединения Компонента проходят через ingress/egress proxy.

Для входящих/исходящих взаимодействий используется mTLS 1.2.

Настройка защищенного сетевого взаимодействия осуществляется продуктом Platform V Synapse Service Mesh (SSM), основанным на Istio.

На egress proxy реализованы механизмы аутентификации и авторизации (для исходящих запросов) через использование компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD).

Чтобы у различных команд сопровождения не возникало необходимости передачи secrets при настройке клиента OTTS, работа должна быть построена по следующему сценарию:

1. Администратор прикладного модуля выполняет генерацию ключевой пары в p12-контейнере:

keytool -genkey -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -keysize 256 -dname
"CN=${module_id}" -alias ${module_id}

2. Администратор прикладного модуля формирует запрос на сертификат:

keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -alias ${module_id} > ${module_id}_cert_req.pem

3. В результате выполнения данной команды создается файл CSR - ${module_id}_cert_req.pem, который необходимо передать администратору компонента OTTS в заявке на генерацию сертификата для модуля.

События системного журнала#

За логирование отвечает компонент Журналирование (LOGA) продукта Platform V Monitor (OPM). Расположение системного журнала событий настраивается в этом компоненте. Подробности настройки приведены в документации к компоненту Журналирование (LOGA) продукта Platform V Monitor (OPM).

Для системного журнала применимы следующие уровни логирования:

• FATAL — критические ошибки, при которых невозможна работа приложения.

• Error — информация об ошибках в работе приложения. Ошибки данного уровня можно разделить на следующие типы:

  • ошибки вызова компонентов платформы;

  • ошибки интеграционных вызовов.

• Warning — предупреждения.

• Info — информация о работе приложения и текущем состоянии процессов.

• Debug — подробности о работе приложения, позволяющие восстановить последовательность выполнения операций при обслуживании вызовов и вызовах внешних систем.

• TRACE — подробные записи о действиях приложения. Нужны в исключительных случаях для отладки.

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

Реализованная интеграция с компонентом Журналирование (LOGA) продукта Platform V Monitor (OPM) позволяет выполнять сбор, предобработку, транспортировку, хранение, поиск и просмотр логов прикладных модулей компонента NSIX в централизованной системе хранения логов данного компонента.

Если в системном журнале нет сообщений об ошибках, значит работа происходит в штатном режиме.

События ротации secrets

Чтобы изменить уровень логирования, администратору необходимо зайти в консоль администрирования облачной среды, выбрать проект, в который выполнена установка компонента NSIX, и выбрать Deployment модуль, уровень логирования которого необходимо изменить. Далее перейти в терминал pod и выполнить команду:

curl localhost:8081/actuator/loggers

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

curl -i -X POST -H 'Content-Type: application/json' -d '{"configuredLevel": "DEBUG"}' http://localhost:8081/actuator/loggers/sql

События мониторинга#

Все прикладные модули компонента публикуют метрики по стандарту мониторинга Prometheus. Метрики доступны для сбора системой мониторинга через HTTP-endpoint/actuator/prometheus. Сбор и отправка метрик выполняется с использованием подключаемого клиентского модуля компонента Объединенный мониторинг Unimon (MONA) продукта Platform V Monitor (OPM).

Мониторинг утилизации коммунальных (мультитенантных) и мульти-инстансных ресурсов. Реализована схема передачи метрик продуктов Платформы для вычисления потребления аппаратных ресурсов и биллинга.

Мониторинг ротации secrets

Часто встречающиеся проблемы и пути их устранения#

Действия при ошибках запуска приложений Компонента#

Ниже рассмотрены наиболее распространенные ошибки при запуске приложений и основные варианты их устранения.

Действия при ошибках запуска pods

Если pods нет, необходимо убедиться, что создана конфигурация развертывания (в разделе Workloads \ Deployment Configs), и в его настройках нажать Start Rollout. Если конфигурация не создана, нужно повторить процедуру ее установки и при наличии ошибок при автоустановке проверить лог и попытаться установить нужный yaml-файл вручную.

Если pod содержит ошибку вида CrashLoopBackOff или другую, подсвеченную красным цветом, нужно перейти в логи этого pod и посмотреть причину ошибки.

Это может быть, например, некорректная ссылка на Docker-образ, ошибка jdbc-соединения на стадии запуска, некорректная модель БД, отсутствие параметра конфигурации и т.д.

Необходимо убедиться, что:

• в настройках конфигурации развертывания указана ссылка на существующий Docker-образ с существующего сайта;

• в параметрах корректно указано имя secret, содержащего данные хоста хранилища Docker-образов;

• secret с данными Docker-образов создан и содержит корректные логин и пароль.

Затем перейти в раздел Pods и следить за появлением pods имя-модуля-deploy и имя-модуля, при появлении ошибки перейти в лог в течение минуты (далее pods самоудаляется) и, скопировав сообщение из лога, проанализировать ошибку и действовать исходя из ее типа.

JDBC Error

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

В первую очередь при ошибке такого рода следует проверить параметры конфигураций БД в Config Maps nsix-cm-mdc-db и убедиться, что в параметрах указаны верные диалект и драйвер СУБД, схема, адрес БД, логин и init-запросы, а также пароль в secret nsix-secret-mdc-db (secret-mdc-unver, где unver - номер версии по умолчанию). Если параметры заданы неверно, их следует исправить в консоли среды контейнеризации и связанных заданиях Jenkins, и затем перезапустить pods (например, изменив файл DeploymentConfig или удалив текущий Replication Controller - новый стартует автоматически). Если же параметры заданы верно, а соединиться с БД из внешней программы не удается по причине неправильного, просроченного пароля и т.п., следует перезапустить БД/сбросить блокировку/сменить пароль при наличии доступа, а при его отсутствии — запросить у администратора БД.

Действия, если pods запущены, но приложения не отображаются

Если pods работают, но при попытке перейти на страницу контекста выводится ошибка 404 или подобная, необходимо перейти в Networking-Routes и проверить работоспособность интерфейса и отсутствие ошибок с помощью маршрута no-ingress. Если такого маршрута по умолчанию нет, необходимо проверить маршрут ingress ввиду наличия сертификата.

В этом случае если компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) не настроен или не подключен, можно временно создать маршрут No-ingress вручную на основе следующего yaml-файла:

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: route-mdc-no-ingress
  labels:
    shard: default
spec:
  host: no-ingress.mdc.apps.название_кластера.название_домена
  to:
    kind: Service
    name: svc-mdc-ui
    weight: 100
  port:
    targetPort: http-8080
  wildcardPolicy: None

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

При наличии ошибок проверьте логи pods соответствующего компонента.

Действия при ошибках отправки событий в компонент Аудит (AUDT) продукта Platform V Audit SE (AUD)#

При появлении сообщения об ошибке отправки данных в компонент Аудит (AUDT) продукта Platform V Audit SE (AUD) необходимо проверить настройки, отвечающие за интеграцию с данным компонентом. Для этого требуется открыть консоль среды контейнеризации в режиме Администратора, открыть сущность ConfigMap nsix-cm-mdc, проверить задано ли значение для системной переменной AUDIT_HOST. Если системная переменная отсутствует или содержит некорректное значение (например, недопустимый хост для приема события компонентом Аудит (AUDT) продукта Platform V Audit SE (AUD)), то необходимо запросить актуальный хост сотрудников компонента Аудит (AUDT) продукта Platform V Audit SE (AUD) и актуализировать значение системной переменной AUDIT_HOST.

Действия при ошибках интерфейса#

Прикладной интерфейс не отображается

Обычно причиной не отображения интерфейса служит неверно указанный порт или контекст в компоненте IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) или в прокси-сервере.

Следует проверить, что модуль mdc-ui запущен и в адресной строке правильно указан порт и корневой контекст, а также верно настроено проксирование в конфигурации nsix-cm-mdc-nginx, особенно если UI запускается в отдельной проектной области.

В некоторых случаях Platform V может принудительно переопределять порт, указанный в настройках nsix-cm-mdc-nginx. В таком случае стоит проверить соседние порты. Например, для HTTP это могут быть 8080, 8081, 8082, 9080 и т.п., для HTTPS — 8444, 9443 и т.п.

Если используется компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) и прямая ссылка без него работает, а сам компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM) — нет, исправьте его настройки и проверьте, нет ли в зоне зависших серверов, на один из которых вместо рабочего он может перенаправлять.

Прикладной интерфейс отображается, но всплывает ошибка получения данных

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

Более точную причину ошибки можно установить, просмотрев логи pods — новое сообщение должно генерироваться в момент входа в главное меню или переход в меню модуля:

• mdc-ivs, если ошибка выводится на главном экране, либо в меню Справочники и Версии справочников;

• mdc-kmd, если ошибка выводится в меню Конструктор модели данных;

• mdc-jobs, если ошибка выводится в меню Регламентные задания.

Если включена аутентификация через AUTZ, то следует проверить, что AUTZ работает, а в самом компоненте AUTZ у пользователя, под которым осуществлен вход, добавлены все актуальные роли, и пароль не просрочен.

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

При наличии ошибки в БД следует проверить соединение и установить через liquibase последние патчи.

Если соединение не работает, администратору следует проверить состояние запуска БД и pgbouncer и при необходимости перезапустить (при отсутствии прав — запросить администратора). В некоторых случаях крах БД может быть вызван переполнением раздела с табличным пространством (по умолчанию - /pgdata), который в этом случае следует очистить или расширить за счет других свободных разделов.

Если соединение работает, но пароль не верный или просрочен — следует сменить пароль и актуализировать его в настройках, либо сбросить просроченный статус и при необходимости изменить парольную политику в компоненте password_policy, увеличив срок действия.

Действия при отказах технических средств#

В случае отказа какого-либо технического средства на активном плече кластера БД или сервера приложений кластерное ПО автоматически переключит работу на неактивное плечо кластера.

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

Действия по восстановлению программ и/или данных при обнаружении ошибок в данных (в т.ч. при переходе на предыдущую версию ПО)#

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

Действия в случаях обнаружения несанкционированного вмешательства в данные#

В случаях обнаружения несанкционированного вмешательства в данные необходимо посмотреть события изменения данных в компоненте Аудит (AUDT) продукта Platform V Audit SE (AUD), связаться с автором данных изменений и выяснить причины. Далее действовать по ситуации. С целью предотвращения несанкционированного вмешательства в данные до устранения проблемы рекомендуется остановить сервер приложений и сервер БД компонента NSIX.

Регламентные работы / работы по восстановлению#

Откат компонента NSIX

Для отката компонента NSIX к ранним версиям ПО после установки обновлений в самом простом случае достаточно изменить хеш-код sha256 текущего Docker-образа в строке image в конфигурационных файлах nsix-mdc-iv, nsix-mdc-jobs, nsix-mdc-kmd, nsix-mdc-ui и nsix-mdc-api. В более сложных случаях, если требуется изменить настройки Deployment Config и Config Maps на более ранние (например, если ранняя версия содержала ныне удаленную переменную), следует удалить текущую версию. В самом сложном общем случае, если были глобальные изменения (такие как переименование сущностей yaml), требуется удалить все объекты yaml в среде контейнеризации, относящиеся к Компоненту, и затем установить их из старого дистрибутива.

Откат БД

Для отката системы к БД более ранней версии компонента NSIX необходимо восстановить БД из созданной ранее резервной копии. Создание резервной копий данных и восстановление данных из резервной копии выполняется штатными утилитами (средствами) администрирования БД, такими как pg_dump и pg_restore соответственно. Информация об их использовании приведена в разделе Архивация дампов, копирование и восстановление настоящего Руководства по системному администрированию компонента Сервис управления справочными данными (NSIX).

Действия при ошибках работы api#

При загрузке больших файлов формата TransferReference приложение может выдавать ошибку следующего типа:

Ошибка выполнения POST запроса org.springframework.web.client.ResourceAccessException: I/O error on POST request for
"localhost:8080/mdc-api/rn/DEFAULT_TENANT/dictionary-version/content": Broken pipe (Write failed); 

Данное исключение возникает при подаче больших файлов (около 1.5 гб)

Решение

Необходимо увеличить значение параметра MULTIPART_MAX_UPLOAD_SIZE в конфигурации проекта. По умолчанию данный параметр принимает значение в 16 Мегабайт