Масштабирование системы

Введение

Vulns.io Enterprise VM — многофункциональная система для управления уязвимостями, анализа, усиления защищённости и управления обновлениями активов IT-инфраструктуры в автоматическом режиме. Одно из ключевых свойств решения — способность обслуживать инфраструктуры самого разного масштаба: от нескольких десятков до десятков тысяч активов. Это достигается за счёт гибкой архитектуры и возможности масштабирования отдельных компонентов.

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

От чего зависит производительность сканирования

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

• производительность базы данных — сервис mongodb;
• количество воркеров (worker-main), обрабатывающих задачи сканирования;
• количество параллельно выполняемых задач других типов — генерация отчётов, обновление БД уязвимостей и пр.

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

Вертикальное масштабирование: работа на одном сервере

Для небольших и средних инфраструктур достаточно одного сервера. Его конфигурация подбирается исходя из количества активов — подробные требования приведены в разделе «Требования к серверу и ОС» документации «Описание системы».

Это базовый сценарий: минимум операционной сложности, единая точка администрирования, отсутствие необходимости в оркестрации контейнеров.

Способы повышения производительности на одном сервере

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

• Увеличение количества ядер CPU — а вместе с ними и количества воркеров worker-main, которые обрабатывают задачи сканирования.
• Использование высокоскоростных NVMe-накопителей — ускоряет операции с базой данных и работу с артефактами.

Принцип распределения ядер при ручной настройке

При ручной настройке ядра CPU распределяются между сервисами по следующему принципу:

• по одному ядру выделяется каждому из ключевых сервисов: mongodb, redisdb, nginx, centrifugo, data-updater;
• одно ядро резервируется под операционную систему;
• все оставшиеся ядра отводятся под воркеры worker-main.

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

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

Горизонтальное масштабирование: распределение на несколько серверов

Для крупных инфраструктур (от 10 000 активов) рекомендуется распределение компонентов Системы на нескольких серверах с оркестрацией контейнеров.

Что именно масштабируется горизонтально

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

Поддерживаемые варианты оркестрации

Горизонтальное масштабирование опирается на контейнерную оркестрацию. Поддерживаются два варианта:

• Docker Swarm;
• Kubernetes.

Сравнение подходов

Развёртывание в Kubernetes

Развёртывание в Kubernetes — это отдельный от стандартной on-premise установки сценарий, который требует отдельной консультации.

Ключевое преимущество этого варианта — автоматическое масштабирование компонентов, критичных к скорости сканирования, при высоких нагрузках, без необходимости ручного пересчёта количества воркеров. Это особенно ценно для инфраструктур с неравномерной, пиковой нагрузкой, где ручная подстройка ресурсов была бы трудоёмкой и неоперативной.

Расширение охвата: Сенсоры

Помимо масштабирования производительности, существует инструмент для расширения охвата инфраструктуры — Сенсоры.

Важно различать: Сенсоры масштабируют не производительность, а именно географию/сетевой охват. Они позволяют подключать активы из удалённых или изолированных сегментов сети без необходимости прямого доступа с основного сервера Системы.

Это востребовано в распределённых инфраструктурах, где часть активов физически или логически отделена от центрального узла. Подробнее о механизме работы — в статье «Модуль Сенсор».

Практические рекомендации по выбору сценария

1. Оцените количество активов. До порога в ~10 000 активов, как правило, достаточно одного сервера с корректно подобранной конфигурацией по разделу «Требования к серверу и ОС».
2. Определите узкое место. Если производительность ограничена обработкой задач — наращивайте ядра CPU и воркеры; если операциями с данными — переходите на NVMe-накопители.
3. Для крупных инсталляций планируйте горизонтальное масштабирование заранее — шардирование БД и распределение воркеров требуют оркестрации (Docker Swarm или Kubernetes).
4. При пиковых и непредсказуемых нагрузках рассмотрите Kubernetes ради автоматического масштабирования, но учитывайте, что это отдельный сценарий развёртывания с отдельной консультацией.
5. Для распределённых сетей с изолированными сегментами используйте Сенсоры для расширения охвата без прямого доступа к активам.

К кому обращаться

Сценарии горизонтального масштабирования (10 000+ активов) и, в частности, развёртывание в Docker Swarm/Kubernetes требуют отдельной проработки и консультации со стороны разработчика. Перед проектированием крупной инсталляции рекомендуется согласовать целевую архитектуру, требования к серверам и модель распределения компонентов с технической поддержкой Vulns.io VM (support@vulns.io).

Заключение

Vulns.io Enterprise VM спроектирована так, чтобы обслуживать инфраструктуры любого масштаба — от нескольких десятков до десятков тысяч активов — за счёт гибкой архитектуры и возможности масштабирования отдельных компонентов.

Небольшие и средние инфраструктуры полностью закрываются одним сервером с применением вертикального масштабирования: увеличением количества ядер CPU и воркеров worker-main, а также использованием высокоскоростных NVMe-накопителей. Конфигурация подбирается по количеству активов согласно таблице требований к серверу.

Крупные распределённые инфраструктуры обслуживаются за счёт горизонтального масштабирования через оркестрацию Docker Swarm или Kubernetes: основная база данных может шардироваться на необходимое количество хостов, а количество воркеров — увеличиваться и распределяться на дополнительных хостах. Развёртывание в Kubernetes дополнительно позволяет автоматизировать масштабирование критичных к скорости сканирования компонентов при высоких нагрузках, без ручного пересчёта количества воркеров.

Отдельный инструмент — Сенсоры — расширяет не производительность, а охват инфраструктуры: они позволяют подключать активы из удалённых и изолированных сегментов сети без необходимости прямого доступа с основного сервера Системы.

Таким образом, единая платформа последовательно покрывает весь диапазон сценариев — от одиночного сервера до распределённой отказоустойчивой инсталляции с оркестрацией и сетью Сенсоров. Это означает, что архитектура растёт вместе с инфраструктурой заказчика без смены платформы: по мере увеличения числа активов достаточно наращивать ресурсы и переходить от вертикального к горизонтальному масштабированию, сохраняя привычные инструменты и процессы.

Для инфраструктур от 10 000 активов, а также при развёртывании в Docker Swarm или Kubernetes рекомендуется обращаться в техническую поддержку за индивидуальными рекомендациями, поскольку требования к конфигурации серверов для таких случаев не типизированы в общей таблице требований.