Системные требования#

Необходимое программное обеспечение#

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

Аппаратное обеспечение#

Для компонента продукта требуется следующая минимальная конфигурация аппаратного обеспечения.

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

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

Требования для контейнеров компонентов IDMX#

Для поддержания стабильной работоспособности IDM необходимо обеспечить следующую квоту ресурсов:

* — За эталонное ядро процессора принято считать «Intel® Xeon® E5-2673 v4» с тактовой частотой 2,3 ГГц

Обратите внимание, данные квоты ресурсов указаны для компонентов IDMX (idmx-engine, idmx-ui, idmx-connector-server) с учетом sidecar интеграций с компонентом LOGA Platform V Monitor, с продуктом Platform V Synapse Service Mesh (Istio) и системой хранения секретов Secret Management System. В случае использования дополнительных интеграций, выделяемую квоту ресурсов для компонентов и пространства имен следует увеличить согласно требованиям, указанным в документации на используемые интеграции.

В приведенной выше таблице размеров приведены значения для одного контейнера (узла) IDM. Как правило, количество активных узлов определяется исходя из предполагаемого объема потока операций и требований к отказоустойчивости системы (резервным узлам). В таком случае, для пространства имен IDM потребуется выделить количество ресурсов, достаточное для всех развертываемых узлов.

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

2^n=5*1,7^n

, где:

• n - степень в которую надо возвести 2, чтобы получить итоговое число узлов;

• 5 - пропускная способность одного узла, в операциях в секунду.

Например, посчитаем примерную пропускную способность для 2 серверов.

Для того, чтобы получить 2, необходимо возвести 2 в 1 степень. Подставим значение в формулу:

2^1 = 5 * 1,7^1

2=5 * 1,7 = 8,5

Таким образом, для двух узлов пропускная способность при квоте ресурсов из таблицы выше равна ~8,5 операциям в секунду.

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

Требования базы данных IDMX#

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

* — За эталонное ядро процессора принято считать «Intel® Xeon® E5-2673 v4» с тактовой частотой 2,3 ГГц

Обратите внимание, рост требуемого дискового пространства для БД обусловлен следующими причинами:

• При линейном росте количества пользователей объем данных по каждому из них занимает больше дискового пространства, чем 1 к 1. Так, например, для одного пользователя кроме учетной карточки создается от одной до нескольких (в зависимости от требований бизнеса) учетных записей. Также для пользователя может создаваться более одной учетной карточки, что влечет за собой дополнительные траты дискового пространства.

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

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

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

Размер БД = (количество пользователей * (количество ролей * вес одной роли))+вес БД без пользователей

, где: * вес одного пользователя = 14823,720 Байт; * вес одной роли = 11607,741 Байт; * размер БД, в которой присутствует только базовая конфигурация, до созданя пользователей = 21939181 Байт.

Данная формула позволяет получить лишь приблизительнй размер требуемой базы данных (но не дисковое пространство, которое потребуется выделить под нее). Она не учитывает операции UPDATE/DELETE, так как размер БД с учетом этих операций сложно предсказать из-за специфики работы внутренних механизмов БД (работа вакуума, MVCC).

Требования БД для раздельного хранения данных аудита#

В случае, если для экземпляра IDMX требуется выделить хренение данных аудита IDMX в отдельную БД, для этой БД потребуются следующие квоты ресурсов:

* — За эталонное ядро процессора принято считать «Intel® Xeon® E5-2673 v4» с тактовой частотой 2,3 ГГц

Дисковое пространство для выделенной БД аудита можно приблизительно рассчитать по следующей формуле:

V = A * T * V1

, где:

• V — размер БД, в байтах;

• A — интенсивность потока операций, в операциях в день;

• T — время хранения записей аудита, в днях;

• V1 — размер одной операции, в байтах.

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

Например, расчитаем примерный размер БД аудита для следующего стенда:

На данном стенде были проведены следующие действия, с измерением размера в МБ и количества строк в таблицах ma_audit_event и ma_audit_delta:

1. Создание 300 пользователей с provisioning.

2. Блокировка 300 пользователей.

3. Разблокировка 300 пользователей.

4. Сброс пароля для 300 пользователей.

5. Назначение роли с созданием УЗ для 300 пользователей.

6. Назначение роли с модификацией УЗ для 300 пользователей.

7. Отзыв роли с модификацией УЗ для 300 пользователей.

8. Отзыв роли с блокировкой УЗ для 300 пользователей.

После выполнения всех действий сценария и проведения расчетов, был получен размер одной операции V1 = 14735,36 Байт. Исходя из этого, для хранения записей аудита в течение 3 месяцев при интенсивноти в 100 операций в день, потребуется следующий размер отдельной БД для хранения записей аудита:

V = 100 операций/день * 90 дней * 14735,36 Байт/операция = 132618240 Байт, что приблизительно равно 127 ГБ.

Следует учитывать, что это только объем данных записей аудита, без учета требований специфики работы внутренних механизмов БД (работа вакуума, MVCC).

Требования БД для сервиса отправки сообщений аудита#

В случае, если требуется использование сервиса отправки сообщений аудита idmx-datapipe, для него также необходимо выделить БД со следующими ресурсами:

* — За эталонное ядро процессора принято считать «Intel® Xeon® E5-2673 v4» с тактовой частотой 2,3 ГГц

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

Сайзинг БД idmx-datapipe#

Для примерного расчета требуемого дискогового пространства, которое будет занимать БД idmx-datapipe, необходимо, в разрезе каждой таблицы, знать:

• количество строк в таблице (оно равно количеству запусков job передачи сообщений);

• средний размер записи в таблице.

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

SELECT pg_size_pretty(pg_total_relation_size('table_name') / COUNT(*)) AS avg_row_size_kb
FROM table_name fi

, где table_name — имя таблицы, размер записи в которой требуется вычислить. БД idmx-datapipe содержит следующие таблицы:

• batch_job_execution.

• batch_job_execution_context.

• batch_job_execution_params.

• batch_job_instance.

• batch_step_execution.

• batch_step_execution_context.

Следующим шагом вычислим количество записей в таблицах БД idmx-datapipe. Для этого возьмем количесво запусков job и подставим его в следующую формулу:

M  = (60 /(частота запуска job (раз в сколько секунд) ))  * 60, где M — количество запука сущности инструмента Jenkins (Jenkins job) в час.

Затем вычислим количество строк по формуле количество_строк = (M * 24) * N, где N — количество дней в измеряемом промежутке.

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

Зная примерное количество записей и средний размер каждой записи можно рассчитать примерный размер таблиц, как это сделано в примере ниже:

• batch_job_execution = количество_строк * средний_размер_записи_в_таблице.

• batch_job_execution_context =  количество_строк * средний_размер_записи_в_таблице.

• batch_job_execution_params = (2 * количество_строк) * средний_размер_записи_в_таблице.

• batch_job_instance = количество_строк * средний_размер_записи_в_таблице.

• batch_step_execution = (4 * количество_строк ) * средний_размер_записи_в_таблице.

• batch_step_execution_context = (4 * количество_строк) * средний_размер_записи_в_таблице.

Следующим шагом нужно перевести в гигабайты все значения, полученные из формул выше, и просуммировать их. Таким образом будет получен средний размер дискового пространства, требуемых для БД idmx-datapipe, без учета служебнго пространства.

Обратите внимание.

Данные расчеты не учитывают возможные сбои при отправке сообщений аудита. При сбоях при отправке будут появляться записи в таблицах failed_period и failed_item, и посчитать количество сбоев (например, недоступность Kafka сервиса аудита, в который отправляются сообщения) заранее невозможно.

Подобный расчет для таблиц failed_item и failed_period можно провести только на основе статистических данных, полученных во время реальной эксплуатации сервиса.