Требования
Здесь описаны требования, предъявляемые платформой «Агредатор» к IT-инфраструктуре, в которую планируется интеграция. Поскольку платформа представляет собой комплексное и конфигурируемое решение, то данные требования носят консультационный характер и могут меняться в зависимости от конкретной выбранной схемы размещения или иных условий.
Системные требования
«Агредатор» должен работать на любой современной операционной системе семейства Linux и на любой современной версии Docker. На данный момент единственной поддерживаемой архитектурой является 64-bit x86.
Поскольку требования к аппаратной части сильно зависят от планируемой загрузки (и выбранной схемы размещения), тут будут приведены приблизительные характеристики серверов с «Агредатором», базой данных, RabbitMQ и Minio, позволяющие обрабатывать различные потоки обращений к платформе.
Пропускная способность сильно зависит от характера и размера сообщений, обрабатываемых системой. При данной оценке рассматривалась работа с типовым ВС СМЭВ. Такая работа включает несколько циклов сетевого взаимодействия в рамках обработки одного «запроса»: обращения для выполнения цифровой подписи, сохранение промежуточных XML-документов в надёжное хранилище, обработка файла вложения и непосредственное взаимодействие с поставщиком данных.
Рекомендованные требования сервера приложений «Агредатор»
| Запросы | VM | ЦПУ | ОЗУ |
|---|---|---|---|
| До 50 тыс. в сутки (~2 rps) | 1 | 4 vCPU | 8Gb |
| До 200 тыс. в сутки (~4 rps) | 1 | 8 vCPU | 12Gb |
| До 1 млн в сутки (~10 rps) | 3 | 4 vCPU | 8Gb |
| До 10 млн в сутки (~100 rps) | 3 | 10 vCPU | 12Gb |
Рекомендованные требования к подсистеме хранения данных
| До 50 тыс. в сутки 1 | До 200 тыс. в сутки 1 | До 1 млн в сутки 2 | |
|---|---|---|---|
| RabbitMQ | 2 vCPU 2Gb ОЗУ 100Gb HDD |
4 vCPU 4Gb ОЗУ 200Gb HDD |
3 x (3 vCPU 6Gb ОЗУ 200Gb SSD) |
| PostgreSQL | 2 vCPU 4Gb ОЗУ 100Gb HDD |
6 vCPU 12Gb ОЗУ 200Gb HDD |
12 vCPU 24Gb ОЗУ 200Gb+ SSD 3 |
| MinIO (S3) | 2 vCPU 4Gb ОЗУ 100Gb HDD |
4 vCPU 8Gb ОЗУ 200Gb SSD |
8 vCPU 16Gb ОЗУ 200Gb+ SSD 3 |
1. Подсистемы хранения данных могут располагаться на том же сервере, что и сервер приложений «Агредатор».
2. Кластеризация RabbitMQ и иных компонентов необходима для обеспечения отказоустойчивости и рассчитывается отдельно.
3. Объём дискового пространства (для СУБД или S3) обусловлен требуемым сроком хранения данных и должен быть рассчитан под конкретные условия.
Оценка объёма данных, подлежащих хранению
Для некоторых поставщиков данных (ВС СМЭВ) результатом информационного обмена являются юридически значимые цифровые документы (в виде XML-файлов), которые подлежат длительному хранению и могут занимать значительный объём. Далее приведён примерный расчёт размера хранимых данных для типового ВС СМЭВ без файлов вложения.
| Запросы | Запросов в секунду | Данных в день | Данных в месяц |
|---|---|---|---|
| До 50 тыс. в сутки | 2 | 7,5Gb | 220Gb |
| До 200 тыс. в сутки | 4 | 15Gb | 450Gb |
| До 1 млн в сутки | 10 | 37Gb | 1,1Tb |
| До 10 млн в сутки | 100 | 370Gb | 11Tb |
Для типового ВС СМЭВ полный цикл информационного взаимодействия состоит их трех шагов: отправка/получение запроса, получение/отправка ответа, отправка подтверждения. Каждый шаг состоит из двух XML-документов, содержащих цифровую подпись: XML-запроса и XML-ответа. Средний размер XML-файла в СМЭВ составляет 7,5 Kb. Таким образом, расчёт занимаемых данных выглядит следующим образом: Размер = 6 × 7,5 × RPS × Срок Хранения
При 1 запросе в секунду и периоде хранения 1 день получается 6 × 7,5 × 1 × 86400 = 3,7Gb
Использование сжатия (на уровне «Агредатора» или СХД) позволяет уменьшить данный размер почти в 2 раза, при условии что в информационном взаимодействии отсутствуют файлы вложения.
Окружение и ПО
Для запуска платформы или её сервисов можно использовать современную ОС семейства Linux. Тем не менее есть минимальные требования, которые гарантируют стабильную работу и простоту запуска, поскольку они используются при разработке и тестировании платформы.
- ОС: Debian 9.5 x64 или выше, Ubuntu 18.04 x64 или выше
- наличие на машине доступа к
docker.rnds.pro,harbor.rnds.pro,hub.docker.comпо протоколу HTTPS на порт 443 для скачивания Docker образов сервисов. Если на подготавливаемом сервере нет доступа в интернет, образы можно получить у нас через архивацию - системная служба docker не ниже версии 20.10. Более ранние версии также поддерживаются, но требуют некоторого изменения файлов конфигурации docker-compose.yml
- утилита docker-compose не ниже версии 1.25. Более ранние версии имеют команды и синтаксис, отличный от приведённого в документации, но также позволяют выполнять все необходимые действия по запуску и обслуживанию ПО
Информацию о том, как установить docker и docker-compose, а также описание эксплуатации и допустимых команд можно найти по ссылкам:
Безопасность
Требования к безопасности в существенной степени определяются окружением клиента и принятыми внутренними регламентами, уставными документами и иными нормативными и законодательными актами.
Платформа «Агредатор» спроектирована для работы в изолированной сети, исключающей несанкционированный доступ. Доступы от внешних систем (пользователей) к платформе должны явно настраиваться с учетом внутренней политики безопасности заказчика. Отсутствие несанкционированного доступа к компонентам системы извне является неотъемлемым требованием системы.
При планировании внедрения платформы следует учитывать приведенные здесь рекомендации.
Сеть и требования к ней
Для продуктового развертывания мы рекомендуем строго ограничивать трафик и возможность подключения к определенному набору портов, специально выбранных для этих целей. Большинство сервисов и подсистем платформы не имеют прямого интерфейса взаимодействия и для общения с ними используются HTTP-шлюз или точка подключения AMQP. Конкретные порты и протоколы приведены в описании сервисов.
Поскольку компоненты системы запускаются с использованием технологии Docker контейнеров, то дополнительные требования накладываются на конфигурацию платформы контейнеризации, например docker-engine. Они включают отсутствие несанкционированного доступа к самой системе оркестрации, обеспечение сетевой связности узлов и другие стандартные требования. Подробно про безопасность для Docker контейнеров можно узнать на следующих ресурсах:
- Безопасность для Docker-контейнеров - Статья от компании Флант
- Docker в банке - Практики продуктовой эксплуатации Docker
- Docker security - Официальный раздел Docker, посвященный безопасности
Хранение данных
Все компоненты платформы «Агредатор» не хранят данные локально и представляют из себя read-only контейнеры. Все данные сохраняются в строго определенных местах: RabbitMQ, PostgreSQL и Redis, которые в свою очередь не являются частью платформы и могут быть настроены и запущены силами специалистов заказчика согласно установленным нормам.
Кроме того, большинство сервисов платформы спроектированы так, чтоб во время работы не сохранять сами данные, с которыми они работают, а хранить лишь информацию о выполненной работе - какой запрос как именно был обработан. Таким образом, есть строго определённые сервисы и точно известные места (таблицы в СУБД) где данные хранятся непосредственно, что позволяет гибко настроить политику работы с данными, резервное копирование, архивирование и удаление.
Взаимодействие сервисов
Основным протоколом взаимодействия сервисов является AMQP. При этом используется TLS-соединение между всеми сервисами и брокером сообщений RabbitMQ. HTTP-взаимодействие используется при передаче файлов (например XML-логов взаимодействия СМЭВ) между некоторыми сервисами.
Всё взаимодействие с внешним миром, такое как работа операторов, взаимодействие по API с АБС или другими системами должно производиться строго с использованием защищенного соединения HTTPS. Управление доменными именами, сертификатами, TLS-терминация, балансировка входной нагрузки (использование прокси-серверов nginx и подобных) выполняется силами и средствами заказчика, исходя из требований внутренней инфраструктуры и политики ИБ.