Настройка производительности

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

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

Это руководство посвящено настройке среды StarVault для достижения оптимальной производительности. Обратитесь к разделу "Лимиты и максимумы StarVault", чтобы узнать об известных верхних ограничениях на размер определенных полей и объектов, а также о настраиваемых ограничениях для других объектов.

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

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

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

1. Исследование производительности

Часть настройки производительности включает в себя исследование путем наблюдения и измерения текущих характеристик системы. Для исследования производительности можно использовать ряд методик и инструментов. Одним из таких методов анализа производительности системы является метод Utilization Saturation and Errors (USE).

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

Утилизация (Utilization) — получали ли вы предупреждения о низком объеме памяти или, например, об ошибках, связанных с нехваткой памяти?
Насыщенность (Saturation) — есть ли признаки того, что IOPS хранилища достигли допустимого максимума?
Ошибки (Errors) — есть ли ошибки, например, в логах приложений или логах StarVault? Сохраняются ли они при снижении производительности?

Вы можете применить метод USE к системным ресурсам кластера StarVault и получить более глубокое понимание существующих узких мест или проблем в рамках исследования производительности.

В данном руководстве используются элементы метода USE. Например, при исследовании отказоустойчивости производительности в кластере высокой доступности, ошибки ("E" в USE) могут подсказать, какие ресурсы нуждаются в настройке.

Кроме того, вы можете использовать такие функции, как телеметрия, для сбора показателей и измерения использования и насыщенности ресурсов в кластере StarVault.

Обзор Monitor telemetry & audit device log data позволяет узнать больше об использовании телеметрии StarVault и метрик устройств аудита с помощью стека агрегации на основе Fluentd, Telegraf и Splunk.

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

2. Инструменты для исследования производительности

Метод USE представляет собой всеобъемлющий контрольный список для систем Linux, который отлично подходит для исследования производительности на уровне системы. В методе USE также подробно описаны инструменты, которые можно использовать для исследования использования и насыщения каждого ресурса.

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

Компонент	Инструмент	Примечание
CPU	dstat, htop, lscpu, sar, top, vmstat	У dstat нет реализации на Python 3; пользователи Red Hat могут эмулировать dstat с помощью Performance Co-Pilot.
Memory	free, sar, vmstat
Storage	df, iostat, sar, swapon
Network	ifconfig, netstat

Компонент

Инструмент

Примечание

CPU

dstat, htop, lscpu, sar, top, vmstat

У dstat нет реализации на Python 3; пользователи Red Hat могут эмулировать dstat с помощью Performance Co-Pilot.

Memory

free, sar, vmstat

Storage

df, iostat, sar, swapon

Network

ifconfig, netstat

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

К числу широко используемых решений относятся:

Мониторинг логов данных контейнеров в реальном времени.
Dynatrace.
Sysdig Inspect — это мощный интерфейс с открытым исходным кодом для поиска и устранения неисправностей контейнеров.

3. Настройка операционной системы Linux

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

3.1. Пользовательские ограничения

Ядро Linux может устанавливать пользовательские ограничения (также известные как значения ulimit) для каждого пользователя, для каждого процесса или для всей системы. Эти ограничения исторически были разработаны для того, чтобы предотвратить потребление всех доступных ресурсов одним пользователем или процессом в многопользовательских и многопроцессных системах.

В современной системе Linux эти ограничения обычно контролируются свойствами процесса systemd.

Для серверов StarVault, на которых установлено минимальное количество запущенных процессов и отсутствуют многопользовательские интерактивные сессии, ограничения по умолчанию могут быть слишком низкими и вызывать проблемы.

Вы можете прочитать активные лимиты для запущенного процесса хранилища из таблицы процессов ядра под соответствующим идентификатором процесса (PID). В этом примере показано использование команды pidof для динамического получения PID хранилища и вставки его в путь для получения правильных значений.

cat /proc/$(pidof starvault)/limits

Пример вывода:

Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             7724                 7724                 processes
Max open files            1024                 4096                 files
Max locked memory         16777216             16777216             bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       7724                 7724                 signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

В выводе отображается имя предела и три значения:

Мягкий предел (Soft Limit) — это настраиваемое пользователем значение, которое ядро будет применять, чтобы не превысить жесткий предел.
Жесткий предел (Hard Limit) — это значение, настраиваемое пользователем root, которое будет применяться ядром и которое не может превышать общесистемный предел
Единицы (Units) представляют тип измерения для предела

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

Будьте осторожны при использовании таких подходов, как ulimit -a, для получения значений пользовательских лимитов. Лимиты, выводимые этой командой, предназначены для текущего пользователя и не обязательно совпадают с лимитами идентификатора пользователя, под которым выполнялся ваш процесс StarVault.

3.1.1. Максимальное количество открытых файлов

Операционная система StarVault использует дескрипторы файлов как для доступа к файлам в файловой системе, так и для представления сокетных соединений, установленных с другими сетевыми узлами.

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

Как измерить использование?

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

cat /proc/$(pidof starvault)/limits | awk 'NR==1; /Max open files/'

Пример вывода:

Limit                     Soft Limit           Hard Limit           Units
Max open files            1024                 4096                 files

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

sudo lsof -p $(pidof starvault)

Пример вывода:

COMMAND       PID      USER   FD      TYPE             DEVICE  SIZE/OFF   NODE NAME
starvault   14810 starvault   cwd      DIR              253,0      4096      2 /
starvault   14810 starvault   rtd      DIR              253,0      4096      2 /
starvault   14810 starvault   txt      REG              253,0 138377265 131086 /usr/bin/starvault
starvault   14810 starvault    0r      CHR                1,3       0t0      6 /dev/null
starvault   14810 starvault    1u     unix 0xffff89e6347f9c00       0t0  41148 type=STREAM
starvault   14810 starvault    2u     unix 0xffff89e6347f9c00       0t0  41148 type=STREAM
starvault   14810 starvault    3u     unix 0xffff89e6347f8800       0t0  41208 type=DGRAM
starvault   14810 starvault    4u     a_inode            0,13         0   9583 [eventpoll]
starvault   14810 starvault    6u     IPv4              40467       0t0    TCP *:8200 (LISTEN)

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

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

Файловый дескриптор номер 6, открытый с правами чтения и записи (u), имеет тип IPv4, является TCP-узлом, привязанным к порту 8200 на всех сетевых интерфейсах.

Какие типичные ошибки?

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

http: Accept error: accept tcp4 0.0.0.0:8200: accept4: too many open files; retrying in 1s

Ключевые части логов:

Источником ошибки является HTTP-подсистема StarVault (http:).
Поскольку ошибка исходит от http, она также связана с исчерпанием файловых дескрипторов в контексте сетевых сокетов, а не обычных файлов (обратите внимание на accept4() вместо open()).
Самая важная часть ошибки и та, которая объясняет непосредственную причину этой проблемы, — слишком много открытых файлов. Если максимальное количество открытых файлов не настроено на этом сервере StarVault, то настройка этого значения будет разумной отправной точкой для устранения ошибки.

Эта ошибка является одновременно предупреждением о нехватке дескрипторов файлов и о том, что что-то внутри или вне StarVault может чрезмерно их потреблять.

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

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

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

cat /proc/sys/fs/file-max

Пример вывода:

В этой системе невозможно указать максимальный лимит открытых файлов, превышающий 197073.

Увеличение лимитов

В предыдущем примере вы видели, что максимальное количество открытых файлов для процесса StarVault имело мягкое ограничение 1024 и жесткое ограничение 4096. Эти значения часто используются по умолчанию в некоторых дистрибутивах Linux, и для использования StarVault в боевой среде вам всегда следует увеличивать эти значения сверх установленных по умолчанию.

Узнав общесистемный лимит, вы можете соответствующим образом увеличить его для процессов StarVault. В современной Linux на базе systemd это можно сделать, отредактировав файл блока служб StarVault systemd и указав значение для свойства процесса LimitNOFILE.

Имя файла блока systemd может варьироваться, но чаще всего он называется starvault.service, и найти его можно по адресу /lib/systemd/system/starvault.service или /etc/systemd/system/starvault.service.

Редактируйте файл от имени суперпользователя системы:

sudo vi /lib/systemd/system/starvault.service

Либо добавьте свойство процесса LimitNOFILE в [Service], либо измените его значение, если оно уже существует, чтобы увеличить мягкие и жесткие ограничения до разумного базового значения 65536.

LimitNOFILE=65536

Сохраните файл, выйдите из редактора.

Любое изменение устройства требует перезагрузки демона; сделайте это прямо сейчас.

sudo systemctl daemon-reload

Эта команда не выводит результатов, если перезагрузка происходит без проблем.

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

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

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

Перезапустите службу хранилища.

sudo systemctl restart starvault

После перезапуска StarVault проверьте таблицу процессов на наличие нового процесса хранилища:

cat /proc/$(pidof starvault)/limits | awk 'NR==1; /Max open files/'

Пример вывода:

Limit                     Soft Limit           Hard Limit           Units
Max open files            65536                65536                files

Пример юнит файла systemd StarVault, который также включает это свойство процесса, см. в разделе "Включение и запуск службы" в руководстве по развертыванию StarVault.

3.2. Примечание о масштабировании процессора

Вы можете ожидать, что StarVault будет линейно масштабироваться до 100% использования CPU при настройке определенных рабочих нагрузок, таких как шифрование на движке Transit или Transform Secrets. Как правило, это нереалистичные ожидания.

StarVault создан на языке программирования Go, и отчасти это связано с его характеристиками производительности. В Go есть понятие goroutines — это функции или методы, которые выполняются одновременно с другими функциями или методами.

Чем больше одновременно запланированных goroutines, тем больше переключений контекста выполняет система, тем больше прерываний от сетевого интерфейса и т.д.

Такое поведение может не сильно нагружать процессор с точки зрения его реальной загрузки, но оно может ухудшить работу ввода-вывода. Каждый раз, когда goroutine блокируется для ввода/вывода (или вытесняется из-за прерывания), может пройти больше времени, прежде чем goroutine вернется в работу.

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

4. Настройка StarVault

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

В этих разделах по мере возможности приводятся рекомендации и примеры.

4.1. Размер кэша

StarVault использует кэш чтения с наименьшим количеством последних использованных записей (LRU) для физической подсистемы хранения с настраиваемым значением cache_size. Это значение представляет собой количество записей, и по умолчанию оно равно 131072.

Общий размер кэша зависит от размера хранимых записей.

Операции LIST не кэшируются.

4.2. Максимальная продолжительность запроса

StarVault предоставляет два параметра, которые можно настроить, чтобы ограничить максимально допустимую продолжительность запроса. Это можно использовать для развертывания систем со строгими соглашениями об уровне обслуживания, касающимися продолжительности запросов, или для принудительного установления определенной продолжительности запросов.

На уровне всего сервера есть default_max_request_duration со значением по умолчанию 90 секунд (90s). Опять же, настройка этого значения предназначена для конкретных случаев использования и влияет на каждый запрос, сделанный ко всему узлу, так что имейте это в виду.

Пример минимальной конфигурации StarVault, который показывает использование явного параметра default_max_request_duration.

api_addr = "https://127.0.0.8200"

default_max_request_duration = "30s"

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/etc/pki/starvault-server.crt"
  tls_key_file  = "/etc/pki/starvault-server.key"
}

storage "raft" {
  path = "/opt/starvault/data"
  node_id = "raft_node_1"
}

Второй вариант — установить аналогичный максимум на уровне слушателей. Вы можете настроить StarVault на использование более чем одного слушателя, добавив несколько блоков слушателей. Чтобы получить некоторую детализацию ограничения запросов, вы можете установить max_request_duration в пределах строфы слушателя. Значение по умолчанию также составляет 90 секунд (90s).

Пример минимальной конфигурации StarVault, который показывает использование явного параметра max_request_duration в TCP-приемнике.

api_addr = "https://127.0.0.8200"

listener "tcp" {
  address              = "127.0.0.1:8200"
  tls_cert_file        = "/etc/pki/starvault-server.crt"
  tls_key_file         = "/etc/pki/starvault-server.key"
  max_request_duration = "15s"
}

storage "raft" {
  path = "/opt/starvault/data"
  node_id = "raft_node_1"
}

Когда вы задаете max_request_duration в блоке TCP listener, это значение отменяет значение default_max_request_duration.

4.3. Максимальный размер запроса

StarVault позволяет контролировать глобальный максимально допустимый размер запроса, жестко заданный, в байтах у слушателя с помощью параметра max_request_size.

Значение по умолчанию — 33554432 байт (32 МБ).

Указание числа, меньшего или равного 0, полностью отключает ограничение размера запроса.

4.4. Таймауты HTTP

Каждый TCP-слушатель StarVault может определить четыре тайм-аута HTTP, которые напрямую связаны с базовыми параметрами http-сервера Go, определенными в пакете http.

4.4.1. `http_idle_timeout`

Используйте параметр http_idle_timeout для настройки максимального времени ожидания следующего запроса при использовании keep-alives. Если значение этого параметра равно 0, StarVault использует значение http_read_timeout. Если оба параметра имеют значение 0, таймаут не устанавливается.

Значение по умолчанию: 5m (5 минут)

4.4.2. `http_read_header_timeout`

Вы можете использовать параметр http_read_header_timeout, чтобы настроить количество времени, отведенное на чтение заголовков запроса. Если значение http_read_header_timeout равно 0, StarVault использует значение http_read_timeout. Если оба значения равны 0, таймаут отсутствует.

Значение по умолчанию: 10 с (10 секунд)

4.4.3. `http_read_timeout`

С помощью параметра http_read_timeout можно настроить максимальную продолжительность чтения всего HTTP-запроса, включая тело.

Значение по умолчанию: 30 с (30 секунд).

4.4.4. `http_write_timeout`

С помощью параметра http_write_timeout можно настроить максимальную продолжительность тайминга записи ответа.

Значение по умолчанию: 0 (ноль)

4.5. Истечение срока аренды и значения TTL

StarVault поддерживает аренды для всех динамических секретов и токенов аутентификации сервисного типа.

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

Важно следить за ростом числа аренд в кластере StarVault в боевой среде. Неограниченный рост аренды может привести к серьезным проблемам с базовым хранилищем и, в конечном счете, с самим StarVault.

По умолчанию StarVault использует значение time-to-live (TTL) 32 дня для всех аренд. Вы должны помнить об этом при определении сценариев использования и стараться выбирать как можно более короткое значение TTL, которое вы можете использовать.

Если вы развертываете StarVault без указания явных значений TTL и максимального TTL, вы рискуете сгенерировать чрезмерное количество аренд, поскольку TTL по умолчанию позволяет им легко накапливаться. Массовая или нагрузочная генерация и тестирование усиливают этот эффект. Это часто встречается у новых пользователей StarVault. Ознакомьтесь с разделами "Время жизни токена", "Периодические токены" и "Явные максимальные TTL", чтобы узнать больше.

4.5.1. Короткие TTL

Короткие TTL — хорошо для безопасности.

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

Короткие TTL — хорошая производительность.

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

4.5.2. На что обратить внимание

Что касается использования и перенасыщение, вы можете выявить проблемы, отслеживая метрику starvault.expire.num_leases, которая представляет собой количество всех аренд, срок действия которых подходит к концу.

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

4.6. Сертификаты PKI и списки отзыва сертификатов

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

Для максимальной производительности этого механизма секретов, следует учитывать следующее: пределы производительности зависят от доступной энтропии на сервере StarVault и высоких требований к процессору для вычисления пар ключей. Если в вашем случае StarVault выпускает сертификаты и ключи, а не подписывает запросы на подписание сертификатов (CSR).

Это может привести к линейному масштабированию. Наиболее универсальный способ избежать этого — заставить клиентов генерировать CSR и отправлять их в StarVault для подписания, а не заставлять StarVault возвращать пару сертификат/ключ.

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

Первая проблема связана с выбором нереалистично долгого времени жизни сертификата.

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

По-прежнему важно тщательно продумать каждый случай использования и определить идеальное минимальное время жизни для секретов StarVault, включая сертификаты PKI, созданные StarVault. Чтобы узнать больше, просмотрите документацию по механизму PKI-секретов, сосредоточившись на разделе "Поддерживайте короткие сроки жизни сертификатов, ради CRL".

Если время жизни сертификата несколько превышает требуемое, важно убедиться, что приложения используют сертификаты, полученные из StarVault, до истечения срока их действия, прежде чем запрашивать новые, и не запрашивают их на регулярной основе. Долгоживущие сертификаты часто становятся причиной быстрого роста CRL.

Вторая проблема является симптомом первой, поскольку создание нескольких сертификатов с длительным сроком службы приводит к быстрому росту списка отзыва сертификатов (Certificate Revocation List, CRL). Этот список внутренне представлен как один ключ в хранилище ключей/значений. Со временем CRL может насытиться этим значением при достаточно неправильном использовании и частом запросе сертификатов с большим сроком действия.

Типичные ошибки

Если CRL механизма секретов PKI стал больше, чем допускается максимальным размером значения ключа по умолчанию, вы можете столкнуться с ошибками об отзыве аренды в операционном журнале StarVault, похожими на этот пример:

[ERROR] expiration: failed to revoke lease: lease_id=pki/issue/prod/7XXYS4FkmFq8PO05En6rvm6m error="failed to revoke entry: resp: (*logical.Response)(nil) err: error encountered during CRL building: error storing CRL: Failed request: Request body too large, max size: 524288 bytes"

Если вы хотите увеличить производительность механизма секретов PKI и не нуждаетесь в CRL, вам следует определить свои роли так, чтобы они использовали параметр no_store.

StarVault не может перечислить или отозвать сертификаты, созданные ролями, для которых определен параметр no_store.

4.7. ACL в политиках

Если вашей целью является максимальная оптимизация производительности StarVault, вам следует проанализировать политики ACL и пути политик, чтобы минимизировать сложность путей, использующих шаблоны и специальные операторы.

4.7.1. Повышение производительности

Старайтесь по возможности минимизировать использование шаблонов в путях политики.
Старайтесь свести к минимуму использование обозначений сегментов пути + и * в синтаксисе пути политики.

4.8. Устройства аудита

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

Ознакомьтесь с документацией по исключению аудита, чтобы узнать больше о том, как работает исключение из устройства аудита.

4.9. Оценка политики

Для справки здесь приведены диаграмма и описание процесса оценки политик StarVault для ACL, EGP и RGP.

Если запрос был неаутентифицированным (например, starvault login), токен отсутствует, поэтому StarVault оценивает EGP, связанные с конечной точкой запроса.

Если в запросе есть токен, оцениваются политики ACL, прикрепленные к токену.

Если маркер имеет соответствующие возможности для работы на пути, StarVault оценивает RGPs. Затем StarVault оценивает EGPs, установленные на конечной точке запроса.

Если на каком-либо этапе оценка политики не удается, StarVault отклоняет запрос.

4.10. Токены

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

Обычно они имеют ограниченное время жизни в виде срока аренды или времени жизни (TTL).

Чаще всего токены используются для запросов на вход в систему и для отзыва. Эти взаимодействия с StarVault приводят к следующим операциям.

Взаимодействие	Операции StarVault
Запрос на вход в систему	Запись нового токена в хранилище токенов Запись нового договора аренды в хранилище договоров аренды
Отзыв токена (или истечение срока действия токена)	Удалить токен Удалить аренду токена Удалить все дочерние токены и аренды

Взаимодействие

Операции StarVault

Запрос на вход в систему

Запись нового токена в хранилище токенов
Запись нового договора аренды в хранилище договоров аренды

Отзыв токена (или истечение срока действия токена)

Удалить токен
Удалить аренду токена
Удалить все дочерние токены и аренды

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

При использовании пакетных токенов следует помнить о некоторых компромиссах и применять их с осторожностью.

[[less secure]] ==== Менее безопасно, чем сервисные токены

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

4.10.1. Лучшая производительность

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

5. Настройка системы хранения

Задержка запросов StarVault в основном ограничивается настроенным типом хранилища, а запись в хранилище обходится гораздо дороже, чем чтение.

Большинство операций записи в StarVault связано с этими событиями:

Вход в систему и создание токенов.
Динамическое создание секретов.
Продление.
Отзыв.

Существует ряд аналогичных настраиваемых параметров для поддерживаемых хранилищ. В этом руководстве рассматриваются параметры для Integrated Storage (Raft).

5.1. Integrated Storage (Raft)

В StarVault есть возможность Integrated Storage, которая использует Raft Storage. Оно реплицирует данные StarVault на все серверы, используя алгоритм консенсуса Raft.

Если вы еще этого не сделали, просмотрите контрольный список миграции для получения дополнительной информации об Integrated Storage.

Ниже перечислены настраиваемые элементы конфигурации для Integrated Storage.

5.1.1. `mlock()`

Отключите функцию mlock(), если в развертывании StarVault используется Integrated Storage. Integrated Storage плохо взаимодействует с файлами, отображаемыми в памяти, такими как файлы, созданные BoltDB, которые Raft использует для отслеживания состояния.

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

5.1.1.1. Рекомендации

Хотя данные StarVault в BoltDB остаются зашифрованными в состоянии покоя, рекомендуется использовать инструкции для вашей ОС, чтобы отключить swap на серверах StarVault, использующих Integrated Storage, чтобы предотвратить запись ОС на диск конфиденциальных данных StarVault, хранящихся в памяти.

5.1.1.2. Типичные ошибки

Если вы работаете с кластером StarVault с Integrated Storage и не отключили функцию mlock() для бинарного файла starvault (и, возможно, всех внешних плагинов), то вы можете наблюдать ошибки, подобные этой, когда данные StarVault превышают доступный объем памяти.

kernel: [12209.426991] Out of memory: Kill process 23847 (starvault) score 444 or sacrifice child
kernel: [12209.427473] Killed process 23847 (starvault) total-vm:1897491kB, anon-rss:948745kB, file-rss:474372kB

5.1.2. `performance_multiplier`

StarVault использует конфигурационный параметр performance_multiplier аналогичным образом в контексте Integrated Storage для масштабирования ключевых временных параметров алгоритма Raft.

Значение по умолчанию равно 0.

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

По умолчанию StarVault использует менее производительную синхронизацию, которая подходит для серверов StarVault со скромными ресурсами. Настройка по умолчанию равна установке значения 5. Установка значения 1 переводит Raft в режим максимальной производительности, рекомендуемый для производственных серверов StarVault. Максимально допустимое значение — 10.

Это значение по умолчанию может измениться в будущих версиях StarVault, если целевой минимальный профиль сервера изменится.

5.1.3. `snapshot_threshold`

Это низкоуровневый параметр, который редко нуждается в настройке.

Параметр snapshot_threshold управляет минимальным количеством записей коммита raft между снимками, сохраняемыми на диск.

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

Занятые кластеры, испытывающие избыточный дисковый ввод-вывод, могут увеличить это значение, чтобы уменьшить дисковый ввод-вывод и минимизировать вероятность того, что все серверы будут делать снимки одновременно. При увеличении этого значения происходит обмен дискового ввода-вывода на дисковое пространство, поскольку журнал будет расти намного больше, а StarVault не сможет освободить место в raft.db до следующего моментального снимка. При увеличении этого значения серверы могут дольше восстанавливаться после сбоев или обхода отказа, поскольку StarVault придется воспроизводить больше журналов.

6. Ограничения и максимумы ресурсов

6.1. Максимальное количество механизмов секретов

Не существует конкретного ограничения на количество включенных механизмов секретов.

В зависимости от типа используемого хранилища, при наличии нескольких тысяч (потенциально десятков тысяч) включенных механизмов секретов StarVault может ограничить (например) максимальный размер значения.

6.2. Максимальный размер значения при использовании Integrated Storage

Integrated Storage не устанавливает максимальный размер значения ключа. Это означает, что вам следует проявлять осторожность при развертывании на Integrated Storage сценариев использования, которые могут привести к неограниченному росту значения.

Integrated Storage не так сильно зависит от памяти и подвержено ее нехватке из-за того, как StarVault сохраняет данные на диск. Тем не менее, использование слишком больших значений для ключей может негативно сказаться на координации сети, голосовании и выбора лидеров. Помните, что StarVault Integrated Storage не предназначена для работы в качестве базы данных ключей/значений общего назначения. Если вы используете ключи с неоправданно большими значениями (в несколько раз больше, чем по умолчанию), это может привести к проблемам, в зависимости от вашего случая использования и окружения.

Настройка производительности

1. Исследование производительности

2. Инструменты для исследования производительности

3. Настройка операционной системы Linux

3.1. Пользовательские ограничения

3.1.1. Максимальное количество открытых файлов

3.2. Примечание о масштабировании процессора

4. Настройка StarVault

4.1. Размер кэша

4.2. Максимальная продолжительность запроса

4.3. Максимальный размер запроса

4.4. Таймауты HTTP

4.4.1. http_idle_timeout

4.4.2. http_read_header_timeout

4.4.3. http_read_timeout

4.4.4. http_write_timeout

4.5. Истечение срока аренды и значения TTL

4.5.1. Короткие TTL

4.5.2. На что обратить внимание

4.6. Сертификаты PKI и списки отзыва сертификатов

4.7. ACL в политиках

4.7.1. Повышение производительности

4.8. Устройства аудита

4.9. Оценка политики

4.10. Токены

4.10.1. Лучшая производительность

5. Настройка системы хранения

5.1. Integrated Storage (Raft)

5.1.1. mlock()

5.1.1.1. Рекомендации

5.1.1.2. Типичные ошибки

5.1.2. performance_multiplier

5.1.3. snapshot_threshold

6. Ограничения и максимумы ресурсов

6.1. Максимальное количество механизмов секретов

6.2. Максимальный размер значения при использовании Integrated Storage

4.4.1. `http_idle_timeout`

4.4.2. `http_read_header_timeout`

4.4.3. `http_read_timeout`

4.4.4. `http_write_timeout`

5.1.1. `mlock()`

5.1.2. `performance_multiplier`

5.1.3. `snapshot_threshold`