Профиль нагрузки на хранилище секретов сильно различается между организациями, поэтому приведённые значения следует рассматривать как отправную точку. Проверяйте фактическое потребление ресурсов по метрикам, описанным в разделе «Мониторинг», и корректируйте размер кластера.
Базовые системные требования приведены в разделе «Требования».
Профили кластера
Значения для небольшого и большого кластера взяты из раздела «Требования». Профиль «Средний» и объём диска — рекомендации, которые нужно проверить на своей нагрузке.
| Параметр | Небольшой | Средний (рекомендация) | Большой |
|---|---|---|---|
| Назначение | Разработка, тестирование, начальные развёртывания | Production с умеренной нагрузкой | Production с постоянной высокой нагрузкой |
| Процессор | 4–8 ядер | 8 ядер | 8–16 ядер |
| Память | 8–16 ГБ | 16 ГБ | 16–32 ГБ |
| Операции дискового ввода-вывода | 3000+ оп/с | 3000+ оп/с | 3000+ оп/с |
| Пропускная способность диска | 70+ МБ/с | 100+ МБ/с | 200+ МБ/с |
| Объём диска для данных Raft | 25 ГБ | 50 ГБ | 100+ ГБ |
Ориентировочная производительность в зависимости от числа ядер (из раздела «Требования»):
| Операция | 4 ядра | 16 ядер |
|---|---|---|
| Аутентификация (получение токена) | До 20 оп/с | До 100 оп/с |
| Чтение ключа до 1 КБ | До 500 оп/с | До 7000 оп/с |
| Запись ключа | До 30 оп/с | До 150 оп/с |
Диск для Raft
Каждая запись в Stronghold фиксируется в журнале Raft на большинстве узлов с синхронизацией на диск, поэтому задержка диска напрямую влияет на время записи и стабильность выборов лидера.
Рекомендации:
- используйте локальные SSD или NVMe-диски; избегайте сетевых дисков с непредсказуемой задержкой;
- выделите для данных Raft отдельный раздел, чтобы журналы ОС и аудита не могли заполнить его;
- контролируйте задержку синхронизации на диск — ориентир не более единиц миллисекунд;
- учитывайте, что размер хранилища растёт вместе с количеством аренд и токенов, а снимки Raft требуют места для временных файлов.
Проверить задержку синхронизации диска можно утилитой fio:
fio --name=raft-fsync --directory=/opt/stronghold/data --rw=write --ioengine=sync --fdatasync=1 --bs=4k --size=100mВ выводе обратите внимание на перцентили fsync/fdatasync/sync_file_range. Удалите созданный тестовый файл после проверки.
Количество узлов
| Узлов | Допустимо потерять | Когда использовать |
|---|---|---|
| 1 | 0 | Только разработка и тестирование |
| 3 | 1 | Стандартный production-кластер |
| 5 | 2 | Повышенные требования к доступности, размещение в трёх зонах отказа |
Рекомендации:
- используйте нечётное число голосующих узлов: при чётном числе устойчивость к отказам не увеличивается;
- не увеличивайте кластер больше пяти голосующих узлов: каждый дополнительный узел увеличивает время фиксации записи;
- размещайте узлы в разных зонах отказа с низкой сетевой задержкой между ними;
- для горизонтального масштабирования операций чтения используйте performance standby (Stronghold EE), для катастрофоустойчивости — DR-репликацию.
В DP
В DP ресурсы и количество реплик задаёт модуль:
- Запросы ресурсов (requests) пода
stronghold—50mCPU и256Miпамяти; VerticalPodAutoscaler (режимInitial) может увеличить их до500mи1Gi. Подstronghold-automaticзапрашивает10mCPU и50Miпамяти. - Размер диска по умолчанию (
diskSizeGigabytes) — 1 ГБ; задайте значение, достаточное для ваших данных. - При первоначальной установке количество реплик вычисляется как число master-узлов плюс arbiter-узлов; если получилось чётное число, добавляется ещё одна реплика. Затем сохраняется текущее количество реплик StatefulSet.
- У PodDisruptionBudget значение
minAvailableравноreplicas/2 + 1(с округлением вниз;0при одной реплике). - Деструктивные миграции хранилища требуют не менее 3 реплик.
Что создаёт нагрузку
| Фактор | Влияние | Как снизить |
|---|---|---|
| Аренды | Каждая аренда хранится в хранилище и обрабатывается при истечении. Большое количество увеличивает потребление памяти, время запуска и смены лидера | Уменьшайте TTL, отзывайте неиспользуемые аренды, применяйте квоты |
| Токены | Каждый вход создаёт токен и запись в хранилище | Переиспользуйте токены, используйте Stronghold Agent, уменьшайте TTL |
| Аутентификация | Операции входа значительно дороже чтения секрета | Кешируйте токены на стороне клиента |
| Запись | Каждая запись реплицируется через Raft с синхронизацией на диск | Используйте быстрые диски, избегайте частой перезаписи одних и тех же секретов |
| Аудит | Каждый запрос и ответ записываются во все аудит-устройства | Используйте быстрые локальные диски или надёжные сетевые приёмники, фильтрацию |
| Криптографические операции | Механизмы Transit и PKI нагружают CPU, особенно RSA-ключи большой длины | Увеличьте число ядер, выбирайте алгоритмы с меньшей стоимостью |
Пересмотр размера кластера
Увеличьте ресурсы, если:
- 99-й перцентиль
stronghold_core_handle_requestустойчиво растёт; - загрузка CPU на активном узле регулярно превышает 70–80%;
- потребление памяти приближается к объёму ОЗУ узла;
- возрастает
stronghold_raft_commitTimeи учащаются выборы лидера.