Тестовый план шифрования дисков: BitLocker и LUKS на СУБД

Задача теста: какие цифры нужны для решения

Тест шифрования нужен не для того, чтобы сказать «стало медленнее», а чтобы получить цифры, по которым можно принять решение: включать шифрование на сервере с СУБД или менять конфигурацию. План должен отвечать на три вопроса:

• насколько меняются IOPS на чтении и записи;
• как растут задержки (latency), особенно p95 и p99;
• сколько дополнительного CPU забирает шифрование.

Без методики результаты не сравнимы. Сегодня вы смотрите среднюю задержку, завтра - 95-й процентиль. В одном прогоне включен кэш, в другом нет. В один день на сервере есть фоновые задачи, в другой - «чисто». В итоге цифры не отвечают на главный вопрос: что изменилось именно из-за BitLocker или LUKS, а не из-за шума.

Сразу договоритесь, что считается приемлемым ухудшением под вашу СУБД и SLA. Для OLTP часто важнее «хвост» задержек, чем пиковые IOPS: рост p95 чтения с 5 до 8 мс может быть критичнее, чем -10% IOPS. Для отчетных нагрузок иногда допустимо -15% пропускной способности, если ночное окно все равно укладывается.

Удобно заранее зафиксировать «порог боли» и формат решения. Например:

• IOPS: падение не более X% на чтении и записи.
• Задержка: рост p95 и p99 не более Y мс (или не более Y%).
• CPU: рост средней загрузки и CPU steal/ready не более Z%.
• Стабильность: без «пилы», провалов и деградации к концу длительного прогона.

По итогам теста выбор обычно шире, чем «включить или нет». Часто решение выглядит так: включить шифрование, но перейти на более быстрые NVMe, добавить ядра CPU, уточнить режимы шифрования, вынести журнал на отдельный том или пересмотреть лимиты СУБД. Важен принцип: каждое действие должно опираться на измеренные IOPS, задержки и CPU, а не на ощущения.

Что фиксируем до теста: железо, ОС и настройки СУБД

Чтобы сравнение BitLocker и LUKS было честным, зафиксируйте исходные условия. Этот шаг часто решает судьбу всего теста. Если меняется драйвер, кэш контроллера или настройки flush, цифры «прыгают», и сравнение теряет смысл.

Начните с железа. В отчете должна быть «паспортная карточка» сервера: модель, CPU (поколение, частоты), объем RAM, конфигурация дисков и контроллеров. Отдельно отметьте, где именно живет шифрование: на уровне ОС поверх RAID, на отдельном LUN в SAN или на каждом локальном диске.

Что обязательно записать и не менять между прогонами:

• CPU: модель, число ядер/потоков, включены ли Turbo и энергосбережение.
• RAM: общий объем и занятость в простое (до старта нагрузки).
• Хранилище: NVMe/SATA SSD/SAN, RAID/HBA, кэш и политика записи.
• Путь к хранилищу (если SAN): скорость, multipath, задержки.
• Температура и троттлинг: есть ли ограничения по питанию или охлаждению.

Дальше зафиксируйте ОС: версию Windows или дистрибутив Linux, версию ядра, драйверы накопителя и контроллера, патчи. Отдельно отметьте настройки, влияющие на запись: политики кэширования, scheduler/queue depth в Linux, параметры Storport и драйверов в Windows.

По СУБД запишите версию и ключевые настройки: размер буферов/кэша, модель журналирования, параметры flush (fsync/flush), частоту чекпоинтов, а также размер данных (общий объем, рабочий набор и долю «горячих» таблиц/индексов).

Пример: если тестируете на стойковом сервере уровня GSE S200 Series с локальными NVMe, важно явно указать, включен ли кэш контроллера и совпадает ли размер буфера СУБД с объемом RAM. Иначе один прогон станет «RAM-тестом», а другой - тестом диска, и сравнение шифрования будет неверным.

Метрики: как оценить IOPS, задержки и CPU без путаницы

Чтобы тест дал ответ в цифрах, заранее договоритесь о метриках и о том, как вы их считаете. Иначе легко получить «улучшение» только потому, что в одном прогоне смотрели среднее, а в другом - пики.

Что записывать

Смотрите на нагрузку как на три части: скорость операций, их задержки и «цену» в CPU.

Записывайте как минимум:

• IOPS отдельно для чтения и записи (по возможности - отдельно случайные и последовательные).
• Задержки: средняя и перцентили p95 и p99. Перцентили часто важнее среднего, потому что именно хвост задержек вызывает тормоза в СУБД.
• Пропускную способность (MB/s) отдельно для чтения и записи. Она может расти, даже если IOPS падают, поэтому эти показатели нельзя смешивать.
• CPU: общую загрузку, а также user и system. Полезно отдельно смотреть прерывания (interrupts), потому что шифрование и I/O часто увеличивают их.
• Признаки упора в I/O: длину очереди и iowait/ожидания диска.

Как сравнивать, чтобы было честно

Сравнивайте одну и ту же нагрузку в одинаковых условиях. Шифрование иногда почти не меняет средний отклик, но заметно ухудшает p99. Для СУБД это часто означает больше «залипаний» транзакций и скачки времени ответа.

Чтобы результат был устойчивым:

• Делайте минимум 3 повторения каждого сценария и фиксируйте не только «среднее», но и разброс.
• Отделяйте «прогрев» от стабильной части прогона.
• Следите за деградацией: если к концу прогона задержки растут, это важный сигнал.

Если после включения BitLocker или LUKS IOPS почти не меняются, но p99 и system CPU растут, обычно система платит за шифрование не скоростью, а предсказуемостью и процессорным временем.

Дизайн эксперимента: матрица тестов и правила сравнения

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

Сравнивайте ровно три конфигурации: без шифрования, BitLocker, LUKS (dm-crypt). Во всех трех режимах используйте тот шифр и те параметры, которые вы реально планируете в проде (например, XTS-AES), и фиксируйте их в протоколе.

Матрица нагрузок

Чтобы увидеть картину по IOPS и задержкам, достаточно ограниченного, но показательного набора тестов. Удобная логика: тип доступа (случайный/последовательный) x операция (чтение/запись) x размер блока.

Реалистичный минимум:

• Случайное 4K чтение и запись (типично для OLTP).
• Случайное 8K или 16K (часто ближе к реальности для данных).
• Последовательное 128K чтение и запись (бэкапы, сканы).
• Смешанный профиль 70/30 или 80/20 (чтобы увидеть компромисс).

Если у СУБД данные и журнал транзакций на разных томах, тестируйте их отдельно. Для журнала важнее последовательная запись и хвостовая задержка (p95/p99). Для данных важнее случайные операции и стабильность.

Порядок прогонов и простая статистика

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

Практичное правило:

• 1 прогревочный запуск, затем 5 измеряемых.
• Итог по метрикам берите по медиане, а не по среднему.
• Выбросы убирайте только по явной причине (например, сработало обновление) и фиксируйте это.
• Для наглядности добавьте диапазон (min-max или p25-p75).

Отдельно задайте режим CPU. Если возможно, сравните два состояния: энергосбережение включено и фиксированная частота. Шифрование может упираться в CPU, и без этого шага легко перепутать «диск медленный» с «процессор сбрасывает частоту».

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

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

Диски и файловая система

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

Запишите и не меняйте между прогонами: схему разделов, тип файловой системы, размер блока/кластера, параметры монтирования, размер тома и свободное место перед тестом. Для СУБД удобно иметь отдельный том под данные и отдельный под журналы (даже если физически это один накопитель) - так проще повторять сценарии.

Кэш и фон

Решите заранее, что вы измеряете: «холодный кэш» (как после перезагрузки) или «прогретый кэш» (типичная работа после часа нагрузки). Хорошая практика - делать оба варианта, но не смешивать.

Чтобы убрать шум, на время теста остановите или заморозьте фоновые активности: обновления, задания планировщика, антивирус/EDR-сканирования, бэкапы и снапшоты, индексаторы, дефрагментацию, тяжелые опросы мониторинга, миграции/репликации и автотюнинг СУБД.

Отдельно проверьте температуру: NVMe и CPU могут уходить в троттлинг, и вы увидите «падение от шифрования», которого на самом деле нет. Дайте системе остыть между прогонами и фиксируйте температуры и частоты.

Для воспроизводимости сохраняйте артефакты: конфигурацию BitLocker/LUKS (режим, алгоритм), состояние шифрования, логи ОС (Event Log/journal), сырые результаты тестов и системные счетчики CPU/диска (например, PerfMon или iostat). Это особенно важно, если результаты потом нужно защищать перед безопасниками и закупкой.

Пошагово: базовый прогон без шифрования

Базовая линия нужна, чтобы потом честно сравнить BitLocker и LUKS. Если цифры без шифрования «плавают», дальше сравнивать бессмысленно.

Сначала снимите метрики простоя (idle). Сервер должен быть в том же состоянии, в каком вы планируете тестировать дальше: те же службы, те же политики энергопотребления, тот же набор дисков.

Проверьте в простое:

• среднюю загрузку CPU и пики (например, за 10-15 минут);
• дисковую активность: IOPS, задержки, очередь;
• фоновые процессы, которые пишут на диск;
• температуры и частоты CPU;
• свободное место и заполненность тома.

Дальше сделайте два типа прогонов.

Первый - синтетика I/O с одинаковыми параметрами для всех режимов: размер блока, соотношение чтение/запись, глубина очереди, число потоков, длительность. Смысл не в рекорде, а в повторяемости. Снимайте не только среднее, но и p95/p99.

Второй - «похоже на СУБД». Выберите сценарий коротких транзакций с частыми коммитами и отдельным упором на журнал: много мелких синхронных записей плюс чтения. Если база уже есть, используйте типичный профиль: нагрузка 20-30 минут, затем 5 минут пауза, затем повтор.

После каждого прогона сохраняйте минимум: точные параметры нагрузки и время запуска, сырые логи метрик CPU и диска, настройки диска/контроллера, параметры файловой системы и настройки СУБД, влияющие на I/O.

Сделайте минимум 3 повтора каждого теста и берите медиану как baseline. Если разброс больше 5-10%, сначала устраняйте причину, и только потом переходите к шифрованию.

Пошагово: прогон с BitLocker

Цель этого прогона - включить BitLocker так, чтобы единственным новым фактором было шифрование. Все остальное (версия ОС, драйверы, схема питания, настройки СУБД, размер данных, нагрузки) должно совпасть с baseline.

Настройка BitLocker (что зафиксировать)

Перед включением запишите параметры, с которыми будете жить дальше: режим шифрования (например, XTS-AES), длину ключа (128 или 256) и наличие аппаратного ускорения AES (обычно AES-NI на CPU). Если на сервере есть само-шифрующийся диск, отдельно отметьте, используете ли вы шифрование диска или программное шифрование BitLocker. В тесте важно не смешивать режимы.

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

Проверьте, что шифрование реально работает

Перед нагрузкой убедитесь, что нужный том зашифрован и шифрование завершено. Если оно идет в фоне, цифры будут искажены.

manage-bde -status
Get-BitLockerVolume | Select MountPoint, VolumeStatus, EncryptionMethod, EncryptionPercentage

Дождитесь 100% EncryptionPercentage. Затем перезагрузите сервер (один раз, контролируемо), убедитесь, что том автоматически разблокируется, и только потом начинайте тесты.

Дальше повторите baseline один в один:

• те же синтетические тесты (те же очереди, блоки, read/write);
• те же «СУБД-похожие» прогоны в том же порядке и с той же длительностью;
• те же метрики, включая p95/p99 задержек;
• параллельный сбор CPU (общий и по ядрам) и системных ожиданий I/O.

Если видите рост p99 задержек при похожих IOPS, для СУБД это часто важнее, чем небольшое изменение среднего значения.

Пошагово: прогон с LUKS (dm-crypt)

Смысл этого шага тот же: повторить baseline, изменив только слой шифрования. Тогда результатам можно доверять.

Сначала зафиксируйте, как именно настроен LUKS/dm-crypt. В отчете это важнее, чем фраза «включили шифрование».

Запишите:

• Версию ОС, ядра и cryptsetup.
• Параметры: LUKS1/LUKS2, шифр (часто aes-xts-plain64), длина ключа (часто 512 для XTS), размер сектора (512 или 4096).
• Расположение LUKS в стеке: RAID -> LUKS -> LVM или LUKS -> LVM -> файловая система. Выберите один вариант и держите его неизменным.
• Опции, которые влияют на производительность (например, allow-discards - только если он осознанно нужен и вы одинаково учитываете его в сравнении).
• Настройки очереди I/O и планировщик диска, если вы их фиксировали в baseline.

Проверьте аппаратное ускорение AES. В Linux обычно достаточно убедиться, что в lscpu или /proc/cpuinfo есть флаг aes. Дополнительно можно прогнать cryptsetup benchmark и сохранить результаты.

Соберите том так, чтобы сравнение было честным: тот же RAID, те же диски, та же файловая система и те же параметры монтирования, что и без шифрования. Меняется только «прослойка» dm-crypt.

После этого повторите те же тесты и метрики, что в baseline: IOPS, задержки (средняя и p95/p99), загрузка CPU (общая и по ядрам), длина очереди и время ожидания I/O.

Для интерпретации удобно держать в голове три простых сигнала:

• IOPS падают, CPU растет: вероятен упор в шифрование.
• CPU почти не меняется, а растут задержки и очередь: скорее упор в диск/контроллер.
• Средние метрики похожи, но p99 растет: проверьте фоновые процессы, writeback и настройки очередей.

Так становится понятно, где именно появляется «цена» LUKS на сервере с СУБД, будь то типовой хост или стойка на базе серверов уровня GSE S200 Series.

Нагрузки, похожие на СУБД: что тестировать кроме синтетики

Синтетика (вроде «4K random read/write») полезна, но она не показывает поведение реальной базы: смешанные операции, всплески, фоновые задачи. Поэтому добавьте прогоны, похожие на работу СУБД.

Три профиля, которые часто меняют картину

Достаточно трех типов нагрузки. Во всех случаях фиксируйте те же метрики, что и в синтетике: среднюю задержку, p95/p99, IOPS/MB/s, CPU (user/system) и ожидания ввода-вывода.

• OLTP-профиль: много мелких операций и частые коммиты. Здесь решают хвосты задержек.
• Аналитика: длинные чтения и сканы. Часто виднее падение пропускной способности и рост CPU.
• Обслуживание: бэкап/восстановление, перестроение индексов, vacuum/checkpoint. Эти задачи нередко запускаются ночью и могут «съесть» CPU или I/O.

Практичный вариант - взять стандартный бенчмарк для вашей СУБД (например, pgbench для PostgreSQL или встроенные средства вендора) и добавить простой сценарий из реальных запросов, чтобы увидеть не только «голые» IOPS.

Данные и журнал тестируйте раздельно

Если у вас разные тома под файлы данных и под журнал транзакций (WAL/redo/log), прогоняйте тесты отдельно. Шифрование может сильнее ударить по журналу из-за постоянных последовательных записей и требований к низкой задержке.

Типичная ситуация: том журнала показывает рост p99 задержки записи с 2 мс до 6 мс после включения шифрования, а том данных почти не меняется. В OLTP это часто означает заметное падение TPS, даже если «общие IOPS» выглядят нормально.

Длительность прогона: не 1-2 минуты

Короткие тесты ловят разгон кэшей, а не устойчивую работу. Рабочее правило:

• 5-10 минут прогрев, результаты не учитывать;
• 20-40 минут замер в устоявшемся режиме;
• минимум 3 повтора и сравнение по медиане, а не по лучшему прогону.

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

Пример сценария: как превратить замеры в решение для бизнеса

Представьте сервер с СУБД, где днем работают 300-500 активных пользователей, а ночью идет бэкап и обслуживание. Запрос простой: включить шифрование дисков с данными и журналами, но не сорвать SLA по времени ответа и не получить очередь запросов в пиковые часы.

Ниже пример итоговой таблицы по одинаковым нагрузкам и одинаковым метрикам.

Дальше это переводится в решение без лишней техники. Например: задержка p95 по записи выросла на 0,8-1,1 мс, а пики CPU стали выше на 13-17 пунктов. Если ваш SLA к чувствительным операциям проходит до 5 мс, BitLocker еще укладывается с запасом, а LUKS уже ближе к границе, особенно во время ночного бэкапа.

Чтобы это было удобно для руководства, формулируйте рекомендации так:

• Выбираем режим, который укладывается в SLA по p95/p99 при дневной нагрузке и ночном бэкапе.
• Если упираемся в CPU, закладываем запас (например, +2-4 ядра) или переносим часть тяжелых задач.
• Если упираемся в задержки диска, рассматриваем более быстрые SSD/массив или разнос данных и журналов.
• Фиксируем, какой рост затрат принимаем (CPU, диски) и какой риск снижаем (утечки/утрата носителей).

Частые ошибки, из-за которых цифрам нельзя верить

Главный риск любого теста шифрования в том, что вы измеряете не BitLocker или LUKS, а случайные отличия в настройках. Тогда даже аккуратный план превращается в спор: кто что «чувствует», а не что видно в метриках.

Ошибки сравнения железа и хранилища

Самая частая ловушка - сравнить разные режимы RAID и кэширования. Например, в «базе» у контроллера включен write-back (с батарейкой/кэшем), а в «шифровании» из-за политики безопасности включили write-through. На графиках это будет выглядеть как «шифрование убило IOPS», хотя просадку сделал режим кэша.

Туда же относятся смена драйверов, прошивок, плана питания CPU или governor между прогонами. Любая такая смена может сдвинуть задержки сильнее, чем само шифрование.

Ошибки методики нагрузки

СУБД легко прячет проблемы за кэшем. Если один прогон сделан на «холодном» буферном кэше, а второй после прогрева, средняя задержка станет красивее, но сравнение будет нечестным. То же самое с состоянием самой СУБД: фоновые чекпоинты, автообслуживание, рост файлов и ребилды индексов добавляют шум.

Часто забывают про профиль для журнала транзакций. Для базы важно не только «быстро писать», но и сколько стоит подтверждение записи (fsync/flush). Если вы тестируете только большие последовательные записи без принудительной синхронизации, вы пропускаете самый чувствительный участок.

Короткий список того, что чаще всего ломает доверие к цифрам:

• разные политики кэша/RAID или разные уровни кэширования ОС;
• смешивание «холодного» и «прогретого» кэша без фиксации состояния СУБД;
• оценка только средней задержки без p95/p99;
• отсутствие отдельного теста для журнала транзакций с fsync/flush;
• изменение сразу нескольких параметров, после чего нельзя объяснить причину просадки.

Практический пример: команда включила LUKS, увидела рост p95 задержки в 2 раза и решила, что виновато шифрование. Позже выяснилось, что в том прогоне параллельно включили агрессивное энергосбережение на CPU, и база чаще уходила в фоновые паузы. Если бы меняли по одному фактору и фиксировали перцентили, спор закончился бы быстро.

Чеклист, отчет и следующие шаги после теста

Чтобы результаты были сопоставимыми, важнее всего дисциплина: одинаково запускать прогоны и одинаково собирать данные.

Перед стартом:

• Зафиксируйте конфигурацию: CPU, RAM, диски/RAID, версию ОС, версию СУБД, параметры шифрования (BitLocker или LUKS, режим, размер сектора).
• Проверьте частоты CPU, режимы NUMA и планировщик питания.
• Уберите фоновые задачи, которые создают I/O, и договоритесь о тишине на стенде.
• Определите, как учитываете кэши: ОС, контроллер, СУБД.
• Зафиксируйте критерии прогона: сколько минут прогрев, сколько минут замер, сколько повторов.

Во время каждого прогона:

• Записывайте точные параметры нагрузки (блок, чтение/запись, доля случайных, глубина очереди, число потоков).
• Фиксируйте состояние кэша (после перезагрузки или после прогрева - но одинаково для сравнения).
• Снимайте IOPS, среднюю задержку и p95/p99, плюс CPU (user/system/iowait) и ожидания I/O.
• Отмечайте температуры, троттлинг и любые предупреждения в логах ОС/СУБД.

Отчет удобно держать в одном файле: таблица результатов по режимам с повторами, графики p99 задержек и CPU, список допущений (кэши, настройки), риски (например, рост хвостов на пике), итоговый вывод «что теряем и что получаем».

Следующий шаг - пилот. Сначала на стенде, затем включение шифрования на части нагрузки (например, вторичные реплики или отдельные базы) и проверка, что цифры повторяются. Если упираетесь в CPU или хвосты задержек, стоит отдельно обсудить подбор серверной конфигурации и внедрение. В таких проектах обычно помогают интеграторы с опытом под СУБД и «железом» в одном контуре - например, GSE.kz (GSE) как производитель серверов и системный интегратор с поддержкой 24/7.