Прогнозирование "тормозов" от включения прозрачного шифрования баз данных (TDE) в Microsoft SQL Server 2008

Введение

Есть в Microsoft SQL Server 2008 такая новая штука как прозрачное шифрование баз данных, в оригинале Transparent Data Encryption (TDE). Включаем шифрование для базы данных, и все данные надежно защищены от некоторых напастей (кстати,  далеко не от всех). При этом менять существующие приложения не нужно. Я уже писал в своем блоге про эту новую возможность:

Ссылка: SQL Server 2008 Transparent Data Encryption (Прозрачное шифрование баз данных)

Там были рассмотрены следующие вопросы:

• Основные принципы работы TDE
• Иерархия ключей в TDE
• Сценарии, в которых применение TDE имеет смысл с точки зрения повышения безопасности, а от каких угроз бесполезно защищаться с помощью TDE
• Настройка TDE (включение TDE для базы данных)
• Что именно шифруется?

Есть еще один интересный вопрос, который я намеренно вынес из того поста, так как хочу остановиться на нем подробнее. Этот вопрос: "Как включение TDE отразится на скорости работы приложения?". Вопрос производительности очень актуален в контексте TDE, так как значительные (а иногда очень значительные) дополнительные затраты на шифрование могут стать серьезным барьером на пути применения TDE в реальных проектах. Этому вопросу я решил посвятить сразу два поста - один с теорией, а другой с практикой. В теоретический части описываются нюансы реализации TDE в Microsoft SQL Server 2008, а также описана основанная на этих знаниях методика прогнозирования влияния TDE на производительность приложения. Практическая часть посвящена готовому решению для прогнозирования, которое реализует эту методику. Нельзя сказать, что теоретическая часть очень сложна, но, вспоминая озадаченность коллег, когда они видели на моем столе кучу исписанных формулами листков, я решил поменять части местами. В этом посте (в первом) на двух примерах рассматривается готовое решение для прогнозирования влияния TDE на производительность, а потом во второй части, я напишу как это все работает.

Решение для прогнозирования влияния TDE на производительность приложения

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

Процедуры прогнозирования влияния TDE на производительность приложения (TDE_Forecast_Procs.zip - 4,95 KB) 

Для чего предназначена каждая процедура описано в следующей таблице:

Схема использования этих процедур для прогнозирования

Шаг 1. На сервере, для которого требуется составить прогноз, сначала нужно измерить производительность различных криптографических операций, которые используются в TDE. Для этого предназначены следующие процедуры:

• dbo.spu_CryptSymAlg_TestSpeed - в параметре нужно указать имя алгоритма, которым планируется шифровать данные в базе данных (можно измерить производительность разных алгоритмов и разных длин ключей и посчитать на основе этих значений разные прогнозы).
• dbo.spu_CryptAsymAlg_TestSpeed - в параметре нужно указать имя алгоритма, которым будет зашифрован Database Encryption Key (DEK). Напомню, что этот ключ шифруется сертификатом, который должен быть предварительно создан в базе данных master. В SQL сервере  поддерживается только один ассиметричный алгоритм - RSA, соответственно выбирать можно только длину ключа - 512 / 1024 / 2048 (по умолчанию, сертификат создается с длиной ключа 1024 бит).
• dbo.spu_CryptAcquireContext_TestSpeed - измеряем скорость выполнения CryptoAPI функции CryptAcquireContext.

Шаг 2. Сохраняем с помощью процедуры dbo.spu_TDEForecast_SavePoint набор текущих значений из разных источников под некоторым именем (затем эти данные используются для составления прогноза). Например, это имя может быть 'test_start'.

Шаг 3. Запускаем нагрузку, для которой мы хотим составить прогноз. При этом нужно иметь в виду, что учитывается вся нагрузка на SQL севере, между начальной и конечной точками интервала. Прогноз строится для ситуации, когда TDE включается только для активной базы данных (это поведение можно легко изменить немного подправив код процедуры). Если нужно построить прогноз для некоторого запроса, то его нужно запустить. Другой активности на сервере в этот момент быть не должно.

Шаг 4. Опять сохраняем набор текущих значений из разных источников с помощью процедуры dbo.spu_TDEForecast_SavePoint, но под другим именем. Например под именем 'test_finish'.

Шаг 5. Считаем прогноз с помощью процедуры dbo.spu_TDEForecast_Result. Прогноз строится на основе данных о скорости выполнения криптографических операций полученных нами на шаге 1, и значений сохраненных нами с помощью процедуры dbo.spu_TDEForecast_SavePoint в начале исследуемого интервала (шаг 2) и конце интервала (шаг 4).

Подробное описание процедур

Процедура dbo.spu_CryptSymAlg_TestSpeed

Процедура dbo.spu_CryptAsymAlg_TestSpeed

Процедура dbo.spu_CryptAcquireContext_TestSpeed

Процедура dbo.spu_TDEForecast_SavePoint

Процедура dbo.spu_TDEForecast_Result

Пример 1. Много пишем

Давайте вспомним основной принцип работы TDE. Данные шифруются при их записи на диск, а расшифровываются при чтении с диска. Основываясь только на этом принципе можно сделать один важный вывод - объем дополнительных затрат на шифрование в TDE напрямую зависит от объема ввода/вывода порождаемого приложением. То есть для приложений порождающих большой объем операций ввода/вывода можно ожидать значительных дополнительных затрат на шифрование. Обратное тоже верно. Включение TDE для нетребовательных к дисковой подсистеме приложений, скорее всего не приведет к заметной деградации производительности (например, если приложение преимущественно читает и объема оперативной памяти на сервере достаточно, чтобы вместить большую часть данных, необходимых приложению).

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

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

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

На моей машине получился следующий результат:

Прежде чем переходить непосредственно к тестам, давайте создадим базу данных, в которой будем экспериментировать:

Теперь можно пускать тестовую нагрузку:

Вот, как выглядит наш тестовый запрос в Мониторе производительности (красная кривая характеризует загрузку процессора в процентах, а синяя кривая - запись на диск в МБ / сек):

Теперь запросим прогноз:

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

Теперь посмотрим как обстоят дела на самом деле. Для этого включим шифрование для тестовой базы данных:

Убеждаемся, что база данных теперь действительно зашифрована:

И опять запускаем тот же тест. В целях экономии места я не буду повторять листинг тестового запроса.

Далее приведен график из Монитора производительности. Для наглядности я совместил результаты с выключенным и включенным TDE на одном графике:

Небольшой комментарий: так как тестируемый запрос очевидно не может быть распараллелен, вся нагрузка, включая шифрование, ложится на один процессор (ядро). В силу этого, как видно из графика, загрузка процессора в секунду возросла не сильно (больше 100% никак). А вот длительность запроса возросла очень прилично, более чем в два раза. Это говорит о том, что на шифрование было потрачено много времени процессора. Сколько именно определяет площадь под красной кривой. Площадь под синей кривой определяет общий объем записи на диск сгенерированный запросом. Это значение, не должно было измениться и не изменилось, так как, очевидно, что на этот параметр TDE никак не влияет. Но так как длительность запроса возросла, объем записи в единицу времени заметно уменьшился (пропорционально).

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

И наконец сводная таблица. Она содержит всю собранную информацию о выполнении тестового запроса с выключенным и включенным TDE, а так же прогноз.

Как видно из таблицы, фактические значения попали в прогнозируемый интервал :)

Пример 2. Много читаем

Давайте рассмотрим еще один пример. В отличии от предыдущего примера, где было много записи, здесь будет большой объем чтения. Кроме того, тестовый запрос в этом примере, в отличии от того, что мы использовали ранее, может быть распараллелен.

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

Убеждаемся, что наша база данных действительно расшифрована:

Несмотря на то, что зашифрованных пользовательских баз данных на сервере больше нет, tempdb осталась зашифрована. Это не должно как-либо сказаться на результатах этого примера, так как ни явно, ни скрыто (план выполнения запроса этого не предусматривает) в tempdb мы ничего не пишем и не читаем.  Но для "чистоты эксперимента" можно перезапустить SQL сервер. После перезапуска tempdb уже не будет шифроваться.

Итак, выполняем тестовый запрос.

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

Смотрим какую нагрузку на сервер создал этот запрос:

Теперь запросим прогноз:

Вот что получилось (как и в первом примере, результат приводится в "разукрашенном" виде и c комментариями):

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

Включаем шифрование тестовой базы данных:

Убеждаемся, что база данных теперь опять зашифрована:

И повторяем тот же тест. Вот что получилось у меня:

Небольшой комментарий: можно констатировать, что здесь, как и в первом примере, включение TDE привело к появленью существенной дополнительной нагрузки на процессор (площадь под красной кривой). Однако в отличии от первого примера, за счет того, что план выполнения этого запроса допускает распараллеливание, загрузка процессора в секунду выросла очень прилично (ей было куда расти, так как в тестовой системе было установлено 2 ядра, и следовательно потолок - 200%).  За счет этого длительность запроса увеличилась не очень сильно. Как следствие объем чтения в единицу времени тоже снизился не очень сильно.

Точные значения в табличном виде:

Как и в первом примере, давайте сведем все вместе в одну таблицу:

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

Заключение

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

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

Несколько слов об ограничениях

SQL сервер - сложная система, способная на ходу подстраиваться под текущие условия. По этой причине один и то же запрос может выполняться совершенно по разному в разных условиях. Различные эффекты от взаимодействия множества запросов выполняющихся на одном сервере (блокировки и т.д.) тоже вносят элемент непредсказуемости. Представленное здесь решение этого не учитывает. При построении прогноза предполагается, что после включения TDE, запросы будут выполняться по той же схеме, что и без TDE. Чаще всего так оно и есть, но бывают и исключения.