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

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются клиентом при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»). Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Примечание:

*

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

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

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Платформенные зависимости#

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех»:

Примечание:

***

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

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

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

При установке Unimon в Kubernetes рекомендовано использовать control-plane istio версии 1.12.1.4.

У компонента реализована интеграция со следующими компонентами из состава продукта:

Образы контейнеров#

1. Поддерживаемые образы контейнеров сервисов компонента:

• На базе Red Hat Enterprise Linux: openjdk/openjdk-11-rhel8:1.0-8

• На базе Platform V SberLinux OS Server: openjdk-11-runtime:8.8-172, container-8-ubi-sbt:8.8-172

2. Образы sidecar для прикладных pods

• proxyv2 (envoy), предоставляемый компонентом Граничный прокси (IGEG) в составе Platform V Synapse Service Mesh (SSM)

  • На базе ALT Linux: версия 1.12.1.2

  • На базе Red Hat Enterprise Linux (опционально): версия istio-release-1.6.14-se-release-1.2.2

• Образ FluentBit для сборки и отправки логов, предоставляемый компонентом Журналирование (LOGA) в составе Platform V Monitor (OPM). Версия fluent-bit:D-5.1.0-1086

• HashiCorp Vault Agent с поддержкой инструмента kubectl (опционально)

3. Образы для использования на ingress/egress
   Клиент OTT, предоставляемый Platform V One-Time-Token (OTT) (опционально)

Аппаратные требования#

На данном этапе отдельное исследование по сайзингу не проведено. Заключение подготовлено на основе данных полученных на НТ.

По умолчанию задаются квоты:

Для серверной части необходимо разворачивать БД PosgreSQL SberEdition в минимальной конфигурации 4/24/400 (ЦПУ/ОЗУ/Внутр. диски). Данные квоты параметризированы и могут изменяться в зависимости от потребности сервиса. Следует учесть, что в серверный namespace устанавливается серверная и клиентская часть.

Предусловия:

• Обращение клиентской части Unimon к серверной производится раз в 2 минуты по каждому процессу:

  • получение данных о подключениях потребителей;

  • получение данных фильтров для метрик;

  • передача метаданных о метриках.

• Для подсчета количества клиентских namespace учитывается конфигурация по умолчанию - 3 unimon-sender, 1 unimon-agent.

• Необходимо учитывать, что несколько unimon-sender могут отправлять запросы в разное время случайным образом. Т.е. возможны отклонения от средних величин в этом случае ресурсов может не хватать или наоборот быть в избытке.