Ускорение резервного копирования БД

Копирование двухтерабайтной базы данных на локальные жесткие диски и затем её восстановление удовлетворяет временным требованиям на восстановление нашей системы SQL Server. Однако, этот простой процесс не может обеспечить адекватную защиту от сценариев полного отказа ,формализованных в соглашении SLA. С другой стороны, копирование базы данных по сети в удаленное хранилище защиту от полного отказа обеспечить может. Проблему может создать ограничение, накладываемое полосой пропускания сети, которое обычно не превышает обычно 1 Гигабита в секунду (Gbps). Когда мы изучали данную ситуацию, основным критерием для сравнения производительности было копирование данных по сети 1-Gbps на расстояние в 10 миль в другой центр данных. Этот процесс занимал более 24-х часов, что было совершенно неприемлемо. Необходимо было найти такое решение, которое давало бы возможность выполнять резервное копирование в рамках того окна времени восстановления, которое было указано в SLA.
Всесторонне переосмыслив все грани проблемы резервирования по сети и проведя множество испытаний, мы смогли сократить резервное копирование базы в 2Тб до 36 минут. Решение, которое мы назвали “многопоточным резервированием по сети” (в оригинале: “multistreamed backups over the network”), использовало восемь сетевых подключений, по 1-Gbps каждое. Увеличенный до гигантского размер фрейма был указан в настройках каждой сетевой платы, и каждая сетевая плата была соединена с задублированным по второму уровню коммутатором линией 10GE (10Gbit Ethernet), которая протянулась до второго сайта. Само резервное копирование заняло 2 часа 25 минут. Появившееся в SQL Server 2008 сжатие резервных копий позволило ещё сократить это время до 36 минут. База данных состояла из 32 файлов данных и одного файла журнала транзакций, которые занимали приблизительно 2,5 Терабайта на 9 логических дисках (файлы данных размещались на дисковом хранилище корпоративного класса – SAN, а журнал транзакций на локальных дисках – DAS). В таблице ниже показана продолжительность резервного копирования обычным способом и два наиболее быстрых подхода к резервированию по сети. Подробное описание каждой из реализаций приведено ниже.

Таблица 1: Продолжительность резервирования 2Tб на сервер в 10 милях по сети

Сокращение времени резервного копирования 

Есть два способа повышения скорости выполнения резервирования: оптимизация и распараллеливание.
Сначала давайте рассмотрим внутреннее устройство резервного копирования. Число потоков, обслуживающих резервное копирование, зависит от числа логических дисков – томов, используемых для файлов базы данных, и от числа устройств резервирования. Это – очень важно знать, потому что этот факт позволяет управлять степенью параллелизма резервного копирования. До сих пор мы опирались на ту схему размещения файлов, которая показана на рисунке ниже. Одним из способов повышения производительности этой схемы является увеличение числа дисков и размещаемых на разных дисках файлов, как это будет описано в следующем разделе.

Параллельное использование нескольких дисков и файлов. 

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

Ниже показана команда, которая выполняет резервное копирование в два файла.

BACKUP DATABASE MyVLDB
TO DISK = '\\BAK01\backup\MyVLDB00000001_1.bak',
   DISK = '\\BAK01\backup\MyVLDB00000001_2.bak'
WITH CHECKSUM, INIT;

Такое использование команды резервного копирования приводит к некоторому выигрышу в производительности, но не к четырехкратному её увеличению, которое можно было бы ожидать (двойной выигрыш при чтении плюс двойной выигрыш на записи). Чтобы полностью представить себе возможный выигрыш, нужно учесть пропускную способность сети.

Использование нескольких сетевых плат 

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

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

Таблица 2: Подсети

Каждая сетевая плата находится в своей подсети (192.168.1.0/24, 192.168.3. 0/24). Теперь можно внести небольшие изменения в команду резервного копирования, указав там IP – адреса вместо имён серверов. Таким способом становится легко управлять тем, какая подсеть, а, следовательно, и какая сетевая плата будет использоваться для транспортировки данных. Тот факт, что все логические подсети будут находиться на одном и том же втором физическом уровне сети, не будет иметь никакого отрицательного влияния на это решение.

BACKUP DATABASE MyVLDB
TO DISK = '\\192.168.2.2\backup\MyVLDB00000001_1.bak',
   DISK = '\\192.168.3.2\backup\MyVLDB00000001_2.bak'
WITH CHECKSUM, INIT;

В случае восстановления, это работает по той же схеме.

RESTORE DATABASE MyVLDB
FROM DISK ='\\192.168.2.2\backup\MyVLDB00000001_1.bak',
     DISK = '\\192.168.3.2\backup\MyVLDB00000001_2.bak'
WITH CHECKSUM, NORECOVERY;

Точно также всё будет работать и с большим числом сетевых плат. В описываемых в статье экспериментах проверялась параллельная работа 16 сетевых плат.

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

BACKUP DATABASE MyVLDB
TO DISK = '\\192.168.2.2\backup\MyVLDB00000001_1.bak',
   DISK = '\\192.168.3.2\backup\MyVLDB00000001_2.bak',
   DISK = '\\192.168.2.2\backup\MyVLDB00000001_3.bak',
   DISK = '\\192.168.3.2\backup\MyVLDB00000001_4.bak'
WITH CHECKSUM, INIT;

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

Рекомендации по общему числу используемых файлов 

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

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

Таблица 3: Сбалансированное распределение файлов по дискам

Дополнительные способы оптимизации и рекомендации 

Разделение сетей для резервного копирования и общего доступа 

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

Большие фреймы 

Максимальный размер пакета сети Ethernet в нормальных условиях составляет 15000 байт (равен размеру фрейма). Это означает то, что для передачи по сети 1 Мегабайта, его придётся разбить на 700 пакетов, которые будут переданы один за другим.
Сегодня можно приобрести такие сетевые платы и коммутаторы, которые поддерживают пакеты Ethernet с большими размерами фрейма. Для таких фреймов сетевых плат и коммутаторов даже существует специальное название – “jumbo frames“.
Чем больше размер фрейма, тем быстрее передача данных, потому что для обмена между серверами потребуется меньше итераций.
Наиболее распространёнными размерами больших фреймов являются величины около 4088 и 9016 Байт (включая заголовки Ethernet и большого фрейма). Например, если размер фрейма будет 9016 Байт, тогда для передачи 1 Мегабайта понадобится всего 117 пакетов.
Эмпирические исследования показали, что при увеличении размера фрейма до 9016 Байт, производительность сети практически удваивается.

BLOCKSIZE 

Параметр, который задаёт используемый командой BACKUP размер блока, должен соответствовать размеру блока записи устройств долговременного хранения. Когда запись осуществляется на отдельный диск, будет работать достаточно хорошо даже используемое по умолчанию для размера блока значение равное 512. Если же запись направлена на RAID – массив или на SAN, стоит убедиться в том, что используемое по умолчанию значение не окажется меньше, чем, например, 65536.
При резервном копировании по сети нужно подобрать такое значение, которое бы позволило заполнять сетевые пакеты наиболее плотно. Имейте также в виду, что разбиение данных на пакеты работает в обоих направлениях. Выбор в качестве размера блока 512 Байт приведет к тому, что в сетевой пакет будет помещаться два блока (принимая во внимание то, что размер фрейма Ethernet равен 1500 Байт). Т.о. для передачи одной страницы базы данных понадобится 8 сетевых пакетов. С другой стороны, запись блоками по 4096 Байт будет помещаться в 3 сетевых пакета, а для передачи одной страницы базы данных понадобится 6 сетевых пакетов.
Можно привести ещё дополнительные примеры, полученные в результате проводимых при написании настоящей статьи тестов; при использовании больших фреймов размером 9016 Байт наилучшие результаты получались при размере блока 8192 Байт, а при использовании больших фреймов размером 4088 Байт, наилучшие результаты получались при размере блока 65536 Байт.

BUFFERCOUNT и MAXTRANSFERSIZE 

Из параметров команды BACKUP можно выделить такие, которые также очень сильно влияют на производительность резервного копирования, это параметры BUFFERCOUNT и MAXTRANSFERSIZE. К сожалению, даже недели тестов не смогли помочь составить правило подбора оптимальных значений для этих параметров, поэтому Вам также необходимо будет выяснять оптимальные значения тестированием в Вашей среде. В качестве совета. для значения параметра MAXTRANSFERSIZE если у Вас система x64 или IA64 с достаточным объёмом оперативной памяти, можно начать тестирование со значения максимального размера буфера 4 Мб (4194304). Для получения более подробной информации о параметре BUFFERCOUNT и о других оптимизирующих параметрах, обратитесь к рекомендациям по настройке производительности сжатия резервных копий в технической статье: Tuning the Performance of Backup Compression in SQL Server 2008
В некоторых случаях, при проведении тестов для этой статьи, лучшие результаты получались при существенно меньших значениях параметров, но выбор значений был непредсказуем. Для промышленного применения стоит выполнить всестороннее тестирование разных вариантов, и убедиться, что лучшие результаты хорошо воспроизводятся. Если же нет возможности провести такую работу – лучше сохранить параметры по умолчанию.

Сжатие резервной копии

Сжатие резервных копий (новая функция, появившаяся в SQL Server 2008) предоставляет возможность увеличить производительность резервирования и в то же время существенно сократить потребляемое копией дисковое пространство, которое выделено для хранения резервных копий. Для включения сжатия резервной копии, в команде BACKUP нужно добавить опцию WITH COMPRESSION.
В представленном ниже примере запроса показано, как включить сжатие резервной копии.

BACKUP DATABASE MyVLDB
TO DISK = '\\BAK01\backup\MyVLDB.bak'
WITH CHECKSUM, INIT, COMPRESSION;

Степень сжатия в действительности зависит от данных, которые хранятся в базе. Для большинства баз данных (цифровая информация, денежно-кредитные операции, дата и время, простой текст), коэффициент сжатия будет находиться между 1:4 и 1:6. Для баз данных содержащих некоторые другие типы данных, например, картинки, которые уже в сжатом формате, можно ожидать результаты похуже. Для получения более подробной информации об использовании сжатия с разными типами данных, смотрите статью в SQL Server Books Online: Сжатие резервных копий.

В проводимых для этой статьи тестах, наблюдалось сокращение времени резервного копирования с 125 до 36 минут, при сжатии файла на 20 процентов от первоначального размера.
У сжатия данных есть один недостаток- повышение утилизации процессорных ресурсов.
SQL Server производитт сжатие в одном потоке, который пишет данные в файл резервной копии, так что число файлов резервных копий определяется числом процессорных ядер, которые будут выполнять сжатие параллельно. Чтобы ограничить использование процессоров для резервного копирования, можно использовать Регулятор Ресурсов (Resource Governor), с помощью которого можно отдавать другим подключениям больше ресурсов.
Если используется прозрачное шифрование базы данных (TDE), не следует пытаться использовать для шифруемой базы ещё и сжатие, потому что зашифрованные данные сжиматься достаточно плохо. Если указание опции сжатия при формировании каждой команды резервного копирования неудобно, можно с помощью системной хранимой процедуры sp_configure установить автоматическое сжатие при создании всех резервных копий на сервере:

sp_configure 'backup compression default', 1
reconfigure

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

Рекомендации по аппаратным средствам файловых серверов, предназначенных для хранения копий 

Дисковые устройства

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

Настройка RAID-контроллера 

Для создания массивов логических дисков, на которых решено хранить файлы резервных копий, стоит выбрать большой размер сегмента (64 Кб, 128 Кб, 256 Кб и выше). Также, стоит установить полное кэширование записи, а кэширование чтения можно полностью отключить. Можно ещё активизировать кэш записи отдельных шпинделей, так как если во время резервного копирования произойдёт сбой по питанию, резервная копия так и так станет непригодной, и в таком случае не имеет значения, были ли потеряны какие-либо байты в кэше записи или нет.
Для тех логических дисков, которые будут задействованы в пробном восстановлении базы из копии, размер сегмента устанавливается в 64 Кб, применяется политика 100-процентного кэширования записи, а кэширование чтения выставляется на 0 процентов.
Выбор уровня RAID (1, 10, 5, 6 …) зависит от возможностей используемого RAID-контроллера или используемой системы хранилища. Поскольку нагрузка на файловом сервере при резервном копировании/восстановлении является последовательной записью и чтением данных, контроллер будет кэшировать данные, пока он не закончит запись всего страйпа целиком, в этом случае можно использовать любой уровень RAID. Если контроллер ведёт себя по-другому, и производительность является критическим параметром, массивы RAID1 или RAID10 будут единственным возможным вариантом.

Настройка HBA 

Если в качестве дисков для файлов резервных копий используется дисковая подсистема типа SAN, максимальную глубину очереди для адаптеров, которые используются в подключении SAN, нужно увеличить настолько, насколько это возможно. Значение по умолчанию составляет 32, но резервное копирование и восстановление будут работать намного лучше при значениях близких к 256. Более подробную информацию можно найти в статье Настройка Windows Server 2008/2003 x64 для обслуживания SQL Server 2008 , в разделе “NumberOfRequests и MaximumSGList”.

Сетевые платы 

Следует очень разборчиво подходить к выбору сетевых плат, которые будут использоваться на серверах. Число портов ещё не гарантирует адекватную производительность ввода-вывода для всех этих портов в одно и то же время. Бывает так, что два четырехпортовых адаптера могут оказаться более производительными, чем один адаптер с четырьмя портами. Количество процессорного времени, используемого драйвером сетевого интерфейса, также очень важно. Бывают такие сетевые платы, которые используют до 50 процентов ресурсов одного процессора, и в то же время есть другие, которые используют всего 3 – 5 процентов.
Если для резервного копирования используется несколько сетевых плат, очень важно, чтобы они использовали разные процессоры, т.е. чтобы их прерывания были привязаны к разным процессорным ядрам.

Системы на основе NUMA 

Если сервер использует архитектуру с неоднородным доступом к памяти (NUMA), необходимо убедится в том, что все адаптеры ввода-вывода (например, NIC, RAID и HBA) распределены между всеми NUMA – узлами системы.

Вычисление времени, необходимого для резервного копирования и восстановления базы данных

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

Далее, нужно определить максимальную продолжительность параллельного, последовательного чтения и записи используемых дисковых подсистем. Для того чтобы измерить эти значения при тестировании резервного копирования и восстановления, можно использовать системную утилиту Performance Monitor (известную ещё в некоторых версиях операционной системы Windows как System Monitor).
В результате, должно получиться 5 значений. Если имеется несколько логических дисков и сетевых плат, эти значения могут отличаться, и всегда нужно использовать самые худшие результаты вычислений.

1. Производительность сетевого адаптера (МБ/сек);
2. Производительность логического диска хранилища копий при последовательном чтении (МБ/сек);
3. Производительность логического диска хранилища копий при последовательной записи (МБ/сек);
4. Производительность логического диска файла базы данных при последовательном чтении (МБ/сек);
5. Производительность логического диска файла базы данных при последовательной записи (МБ/сек).

После этого, опираясь на данные о числе логических дисков для параллельной работы с файлами базы данных, на число логических дисков, используемых для параллельной работы с файлами резервных копий и число используемых сетевых плат. Если сжатие не используется, это приведет к тому, что коэффициент сжатия станет таким: CompressionFactor = 1. 

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

Вычисления для расчета времени восстановления будут сложнее. Сначала нужно узнать, поддерживает ли используемая система мгновенную инициализацию файлов. Эта возможность позволяет SQL Server создавать файлы данных на томах NTFS без обнуления занимаемого файлами места во время создания или расширения файла. Поскольку у этого механизма существуют связанные с безопасностью риски, такой возможностью можно воспользоваться, только если учетной записи, под которой запущена служба SQL Server предоставить в локальных политиках право “Perform Volume Maintenance”. Если учетная запись пользователя входит в группу локальных администраторов, это право ей будет предоставлено по умолчанию (Примечание: время инициализации файла журнала транзакций может ограничивать производительность, так как занимаемое этим файлом место не может не заполняться нулями).

В случае если RestoreTime или BackupTime выше заданных SLA значений, можно воспользоваться изложенными ранее рекомендациями по уменьшению этих значений. Распараллеливание операций обычно ускоряет процесс больше чем попытка ускорить работу одного из компонент во всей цепочке. В сценариях с очень высокой производительностью стоит задуматься о применении обоих подходов.

Обратите внимание: на исполнение команды CHECKBD может потребоваться больше времени, чем время, которое необходимо для чтения с диска. Оно зависит от сложности схемы базы данных, и оно точно не будет меньше времени чтения.

Заключение 

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