Intel QuickAssist аппаратное ускорение криптографии и сжатия в процессорах Xeon

У криптографии и сжатия есть неприятное свойство: они честно съедают процессорное время, и на пиках TLS-рукопожатий или архивации потоков ядра занимаются арифметикой вместо полезной работы. Intel QuickAssist, QAT, это аппаратный ускоритель именно под такие задачи: симметричное шифрование, асимметричные операции и сжатие уходят на отдельные движки, освобождая процессор. В свежих поколениях Xeon ускоритель встроен прямо в чип, а раньше поставлялся картами расширения, и за годы существования вокруг него сложилась полная экосистема: драйвер в ядре, библиотека для приложений, провайдер для OpenSSL и утилиты сжатия. Механизм требует понимания, где он выигрывает, а где процессор с собственными инструкциями окажется быстрее, и именно это разграничение делает внедрение QAT осмысленным.

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

Поколения и место ускорителя на платформе

История QAT началась с карт расширения поколения Gen2, где десятки движков размещались на PCIe-карте, затем появились чипы семейства C62x, а переломным стал встроенный ускоритель четвёртого поколения, QAT 4xxx, входящий в состав серверных процессоров Sapphire Rapids. На шине он видится как криптографическое устройство, у которого физическая функция объявляет себя известным идентификатором, а виртуальные функции получаются включением SR-IOV и разносятся по машинам и контейнерам. Прошивка ускорителя живёт в комплекте микропрограмм системы и подгружается драйвером при старте функции, и расхождение версий прошивки и драйвера первое, что проверяется при странном поведении. Встроенный ускоритель делит термический бюджет процессора, и на предельных нагрузках его производительность связана с охлаждением узла, тогда как карты поколения Gen2 имели собственные бюджеты и потому вели себя предсказуемее на перегретых корпусах. Внутри живёт выделенная прошивка, и работоспособность ускорителя держится на согласовании версий драйвера, прошивки и пользовательской библиотеки, поэтому обновления этих трёх компонентов идут в связке.

Драйвер в ядре для семейства 4xxx появился в выпусках 5.8 и с тех пор разросся возможностями: sysfs-интерфейс состояния, механизм контроля сердцебиения прошивки, поддержка виртуальных функций и, в свежих ядрах, даже их живая миграция. Устройства перечисляются стандартно:

lspci -nn | grep -iE 'co-processor|qat'
modprobe qat_4xxx
cat /sys/bus/pci/devices/0000:6b:00.0/qat/state

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

Два пути доступа через ядро и приложения

Архитектурно у ускорителя два входа. Первый, криптографический API ядра: драйвер регистрирует реализации симметричных шифров и сжатия, и любые потребители ядра, от подсистем шифрования дисков до сжатия памяти, могут попасть на ускоритель прозрачно, если политика выбора алгоритмов позволит. Второй вход, пользовательский: библиотека qatlib даёт приложениям прямой доступ к функциям через очереди кольцевых буферов, и поверх неё построены интеграции с OpenSSL в виде отдельного движка и провайдера, с nginx через модули сжатия и TLS, а также утилита qzip, родственник привычного gzip, гоняющая архивацию через ускоритель.

Выбор пути зависит от приложения. Для сервисов, работающих с OpenSSL, самый короткий путь провайдер: строка конфигурации подключает аппаратные реализации, и измерения скорости показывают разницу сразу. Для собственных приложений на C qatlib даёт асинхронный API с кольцами, и его характерная черта, батчинг: выгодность растёт с размером порций работы, и одиночные мелкие операции туда отправлять обычно невыгодно. Библиотека оперирует экземплярами ускорителя, закреплёнными за ядрами и NUMA-узлами, и привязка потребителя к ближайшему экземпляру экономит и шину, и задержку. В поставке библиотеки есть каталог примеров, от простейших операций до телеметрии, и эти примеры удобнее всего использовать как эталон при первом знакомстве с поведением колец.

Различие движка и провайдера стоит проговорить отдельно, потому что в документах встречаются оба слова. Движок это механизм OpenSSL старой школы, провайдер это новый интерфейс версий 3, и обе обёртки существуют над одной библиотекой. Подключение провайдера делается разделами конфигурации:

[provider_sect]
default = default_sect
qat = qat_sect

[qat_sect]
module = /usr/local/lib64/ossl-modules/qatprovider.so

и после этого стандартные команды OpenSSL уже используют аппаратные реализации там, где они объявлены.

Включение, SR-IOV и раздача устройств

Включение виртуальных функций стандартно для PCIe-устройств с SR-IOV:

echo 16 > /sys/bus/pci/devices/0000:6b:00.0/sriov_numvfs
ls -l /sys/bus/pci/devices/0000:6b:00.0 | grep virtfn

Каждая виртуальная функция получает свою долю ресурсов ускорителя, раздаётся через vfio в виртуальные машины или по привязкам в контейнеры, и планирование ресурсов между функциями решается на уровне прошивки с указанием долей. Свежие ядра добавили живую миграцию виртуальных функций QAT, что снимает историческое ограничение, когда машины с ускорителями теряли мобильность, и эту возможность стоит проверять по версии ядра и прошивки, поскольку она появилась недавно и живёт в паре с поддержкой со стороны гипервизора. Число виртуальных функций зависит от исполнения устройства, и раздача в системах управления кластером идёт через плагины устройств, где функции передаются подам как ресурсы с привязкой к NUMA-топологии. Профиль служб функции задаётся отдельным атрибутом конфигурации служб: симметричное шифрование, асимметричное и сжатие включаются в комбинациях, и переключение профиля переразмечает движки внутри функции.

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

Компрессия и её нюансы

Сжатие на QAT работает в потоковом безгосударственном режиме: ускоритель берёт блок, отдаёт сжатый блок, и не хранит историю между вызовами, что идеально для независимых блоков и страниц, но требует от приложений согласованности словарей, если она нужна. Поддерживаются классический DEFLATE и в свежем поколении LZ4, и выбор алгоритма влияет на совместимость: DEFLATE даёт совместимый на выходе поток, LZ4 даёт скорость. На файловых сервисах и в конвейерах журналов сжатие через ускоритель окупается напрямую: архивация бэкапов, ротация журналов и доставка сжатых потоков перестают занимать ядра. Утилита qzip показывает механику наглядно:

qzip -k bigfile.bin

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

Криптография, где выигрыш и где процессор быстрее

Асимметричные операции, RSA и эллиптические кривые, естественная территория QAT: рукопожатия TLS создают пики этих операций, и вынос их на ускоритель сглаживает профиль нагрузки сервера, освобождая ядра под полезную работу. Симметричное шифрование тоньше: процессор с инструкциями AES-NI и собственным векторным кодом невероятно быстр на мелких сообщениях, и ускоритель выигрывает на больших объёмах и на фоне конкурентной нагрузки, когда ядра заняты чем-то другим. Проверка делается штатным измерителем OpenSSL с подключённым провайдером:

openssl speed rsa2048
openssl speed -provider qatprovider rsa2048

Разница между строками и есть вклад ускорителя на конкретном процессоре и конкретной версии библиотек, и измерять стоит оба случая, потому что после обновления процессора или OpenSSL раскладка меняется. Приложения уровня защищённых каналов получают двойную выгоду от выгрузки рукопожатий: пики соединений сглаживаются, а повторное использование сессий сокращает число тяжёлых операций. Перечень ускоренных алгоритмов ограничен, и современные потоковые шифры вне классического набора остаются на процессоре, поэтому список поддерживаемых наборов сверяют с фактическими потребностями приложения заранее. Через криптографический API ядра к ускорителю выходят и потребители вроде шифрования блочных устройств и стеков защищённых каналов, и там выбор реализации регулируется приоритетами алгоритмов в ядре. Отдельный нюанс, латентность: путь через шину и очередь стоит микросекунды, и на критичных к одиночной операции сценариях процессор остаётся выбором, тогда как QAT берёт масштабом и освобождением ядер.

Наблюдаемость ускорителя в эксплуатации

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

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

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

Внедрение QAT на узле умещается в шесть шагов:

1. сверить поддержку устройства и версии драйвера, прошивки и библиотек в матрице совместимости;
2. поднять физическую функцию, проверить состояние через sysfs и сердцебиение;
3. решить раздачу: целиком приложению узла, либо через виртуальные функции в машины и контейнеры;
4. подключить провайдер в OpenSSL и измерить выигрыш на целевых операциях, включая сценарий малых сообщений;
5. прогнать сжатие целевых данных и сравнить с процессорным путём по скорости и по освобождению ядер;
6. завести мониторинг состояния, сердцебиения и очередей и закрепить порядок обновления четвёрки компонентов.

Итог у QAT практичный: это способ вернуть ядрам работу, отдав арифметику шифрования и сжатия выделенным движкам, с честной оговоркой, что на мелких операциях процессор с инструкциями остаётся быстрее. На серверах с TLS-нагрузкой и постоянной архивацией ускоритель выравнивает профиль нагрузки и добавляет запас, и ключ к успеху здесь тот же, что и везде в оффлоаде, измерение на своих данных до и после, а не доверие к цифрам из презентаций.