Вариант стратегии быстрого и надежного резервного копирования-восстановления VLDB по сети

По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

^{Статья была опубликована рание на SQL.RU Публикуется повторно ввиду недоступности сайта.}

Автор: Томас Грохсер (Thomas H. Grohser)

При содействии: Линдсей Аллен (Lindsey Allen)

Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel

Перевод: Александр Гладченко,  Ирина Наумова

Дата издания: июнь 2009г.

Тематика статьи: SQL Server 2008

 Резюме: Размер базы данных непрерывно растёт, темп этого роста, а также её доступность и готовность фиксируется в соглашение о качестве сервиса - SLA. Одновременно с ростом повышается важность быстрого и надежного резервного копирования и планового восстановления в текущем окружении. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). На реальном примере, в этой статье демонстрируется, как лучше всего использовать резервное копирование и возможности по восстановлению, которыми обладает SQL Server 2008, что должно помочь при создании планов резервного копирования и восстановления VLDB по сети.

Введение

Резервное копирование и восстановление баз данных в SQL Server  похожи на многие другие, окружающие нас в реальном мире вещи; Вы не можете понять их ценность, пока не случится испытать нужды в таких вещах впервые. За эти годы все мы сталкивались с такими случаями, когда не оказывалось под рукой нужной резервной копии; следствием этого становилась потеря бизнеса компанией, потеря работы для людей и потери данных. Компании находят оправдания, чтобы не делать резервное копирование и не создавать план восстановления. Часто слышно фразы, подобные тем, что приведены в кавычках: «У нас есть кластер, так что нам не нужна резервная копия», или «Нам не нужен план восстановления, потому что мы делаем резервные копии каждый день». Что мы поняли за эти года, так это то, что резервные копии и план восстановления нужны во всех случаях.

Краткий обзор Решения

Соглашение о качестве сервиса

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

SLA должно ответить на следующие вопросы:

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

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

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

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

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

Для рассматриваемого в настоящей статье варианта стратегии, требования в SLA были следующие:

• Размер базы данных был 2 Терабайта, ожидаемый прирост доходил до 4 Терабайта за всё время жизни решения.

• Объем рабочей нагрузки был большой, 5 Гигабайт в минуту в пиках, и приблизительно 0.5 Гигабайта в минуту во время выделенного для резервирования окна.

• Время восстановления составляло не более четырёх часов.

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

Краткое описание

Резервное  копирование и восстановление в SQL Server можно рассматривать как «чёрный ящик» с очень простыми функциями. В реальных условиях основной задачей для проектируемых решений становится обеспечение исполнения всех требований бизнеса и заданный уровень эффективности даже в случае серьёзного отказа оборудования или программных систем.

Очень большие базы данных (VLDB) привносят свою специфику и дополнительные проблемы в процесс резервного копирования, особенно если эти операции порождают высокую дополнительную нагрузку. В целях обеспечения возможности восстановления после аварий вполне резонной мерой является размещение резервных копий баз данных в разных местах за счёт копирования их по сети, такая задача будет иметь более высокую сложность реализации, чем резервирование на локальные устройства долговременного хранения. Можно привести в пример задачу по резервному копированию OLTP базы данных, размером в два Терабайта; с высокой рабочей нагрузкой; с жёсткими требованиями к производительности обслуживания транзакций и доступности; с требованием не использовать для резервирования программные интерфейсы (API) виртуальных устройств резервирования (Virtual Backup Device Interface - VDI), позволяющие задействовать имеющиеся в современных системах хранения  (SAN) возможности резервирования, пригодные для использования с  SQL Server.  Кроме того, задача осложняется ещё и тем, что соглашение  о качестве сервиса требует полного восстановления менее чем через четыре часа (включая применение всех файлов копий журнала транзакций). Эта техническая статья как раз и посвящена описанию возможного варианта решения именно такой задачи, реализуемой с помощью средств SQL Server 2008.

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

Как лучше ознакомиться с представленными тут материалами

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

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

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

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

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

Когда резервную копию можно считать правильной?

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

• она должна находиться в другом месте, например, в другом центре данных.

• она должна успешно восстанавливаться.

• восстановленная база данных не должна показывать ошибки при запуске DBCC CHECKDB.

В итоге, полный  цикл резервирования состоит из следующих шагов:

1. Резервное копирование базы данных.

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

3. Восстановление базы данных в другом месте.

4. Выполнение проверки восстановленной базы средствами DBCC CHECKDB.

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

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

Основные опции встроенного механизма резервирования и восстановления

Для использования встроенных средств резервного копирования и команды восстановления в SQL Server 2008 возможны следующие варианты стратегии:

• Резервное копирование на локальный диск и последующее копирование файлов по сети.

• Резервное копирование непосредственно на ресурс для хранения резервных копий в сети.

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

Что может пойти не так, как надо?

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

• Не корректная запись бит данных в файл резервной копии во время исполнения команды резервного копирования.

• Обслуживающий базу данных сервер выходит из строя во время операции резервного копирования.

• Хранилище резервных копий выходит из строя во время операции резервного копирования.

• Сбои в работе хранилища резервных копий после завершения резервного копирования.

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

Выполнение надежного резервного копирования по сети

Давайте начнём наш пример стратегии. Допустим, имеется
база данных с именем MyVLDB, которую нужно резервировать. База данных MyVLDB находится на сервере с именем SQL01. Файл-сервер, на котором мы хотим разместить
резервную копию, называется BAK01. Полностью квалифицированное имя файлового ресурса  \backup. На рисунке 1 проиллюстрирована эта конфигурация.Следующая команда выполняет резервное копирование базы данных на файловый сервер.

BACKUP DATABASE MyVLDB 
       TO DISK = '\BAK01backupMyVLDB.bak'
       WITH INIT

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

Защита от  некорректной записи файл резервной копии

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

BACKUP DATABASE MyVLDB 
       TO DISK = '\BAK01backupMyVLDB.bak'
       WITH CHECKSUM, INIT;

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

Защита от отказа сервера баз данных во время резервирования

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

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

BACKUP DATABASE MyVLDB 
       TO DISK = '\BAK01backupMyVLDB<BackupSequenceNumber>.bak'
       WITH CHECKSUM, INIT;

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

/* использование GETUTCDATE() в качестве порядкового номера копии */
DECLARE @FileName AS nvarchar(4000) = '\BAK01backupMyVLDB' + 
       CONVERT(nvarchar(32), GETUTCDATE(), 112 )+ '.bak';
BACKUP DATABASE MyVLDB 
       TO DISK = @FileName
       WITH CHECKSUM, INIT;

Альтернативный пример представлен ниже, в нём порядковый номер резервной копии создаётся путём приращения единицы к текущему порядковому номеру каждый раз, когда выполняется резервное копирование:

/* для нумерации копий используется возрастающая последовательность чисел
   представленный ниже сценарий должен существовать отдельно для каждой БД, 
   каждая нумерация должна иметь свою создаваемую специально таблицу */

USE MyVLDB;
GO
CREATE SCHEMA DBBackup;
GO

CREATE TABLE DBBackup.Sequence(
       Number int  NOT NULL,
       ID     int  NOT NULL,
       CONSTRAINT PK_Seq PRIMARY KEY CLUSTERED (ID ASC)
);

ALTER TABLE DBBackup.Sequence WITH CHECK ADD CONSTRAINT CK_Seq CHECK (ID=1);
ALTER TABLE DBBackup.Sequence CHECK CONSTRAINT CK_Seq;
INSERT INTO DBBackup.Sequence (Number) VALUES (1,1);

/* это соответствующая команда резервного копирования */

DECLARE @SeqNumber AS int;
UPDATE MyVLDB.DBBackup.Sequence SET @SeqNumber= Number= Number+ 1 WHERE ID=1;
DECLARE @FileName AS nvarchar(4000) = '\BAK01backupMyVLDB' 
       RIGHT('0000000' + CAST(@SeqNumber AS NVARCHAR(8)), 8) + '.bak';
BACKUP DATABASE MyVLDB 
       TO DISK = @FileName
       WITH CHECKSUM, INIT;

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

Защита от отказа сервера хранения копий

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

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

Резервная копия делается поочерёдно на двух серверах, и после двух полных циклов резервного копирования становится устойчивой к катастрофе, поскольку будут существовать две полные резервные копии на двух разных серверах в разных центрах данных. Если запасного файлового сервера нет, желательно попробовать разделить логические диски (LUN) так, чтобы при хранении нескольких клонов резервной копии, частичный отказ дисковой подсистемы затронул бы только один набор файлов резервных копий.

Проверка восстановимости резервной копии

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

Восстановление в базу данных Test Backup

Для того чтобы восстановить из копии тестовую базу данных, нужно иметь ещё один экземпляр SQL Server, установленный на резервном сервере, и ещё один логический диск – LUN, доступный  серверу резервных копий. На втором сервере будут размещены файлы базы данных в процессе восстановления (диск должен быть достаточно большим, чтобы поместились файлы базы данных в её самом большом из хранимых размеров). Для этих целей дисковый массив RAID0 является приемлемым компромиссом между производительностью, уровнем затрат и доступностью. Избыточность дисковых массивов тут не нужна потому что, база данных будет существовать  временно. Уровень RAID 1/0 также допустим, впрочем, и удорожание решения за счёт лучшей избыточности будет также допустимо.

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

RESTORE FILELISTONLY FROM DISK = 'c:backupMyVLDB00000001.bak';

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

RESTORE DATABASE MyVLDB
       FROM DISK = 'C:backupMyVLDB00000001.bak'
       WITH 
       MOVE 'MyVLDB' TO 'C:restoreMyVLDB.mdf',
       MOVE 'MyVLDB_log' TO 'C:restoreMyVLDB.ldf',
       CHECKSUM;

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

Выполнение DBCC CHECKDB

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

DBCC CHECKDB(MyVLDB) WITH NO_INFOMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY

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

Автоматизация описанного процесса

Ниже представлен сценарий, который автоматически извлекает имена файлов из первого файла резервной копии и передаёт их на вход команды восстановления базы, выполняя затем инструкцию DBCC CHECKDB.

DECLARE @dbName            AS sysname =        'MyVLDB';
DECLARE @BackupFileName    AS nvarchar(4000) = 'C:backupMyVLDB00000001.bak';
DECLARE @DBFiles AS TABLE
(
       LogicalName                nvarchar(128), 
       PhysicalName               nvarchar(260), 
       Type                       char(1), 
       FileGroupName              nvarchar(128), 
       Size                       numeric(20,0), 
       MaxSize                    numeric(20,0), 
       FileID                     bigint ,
       CreateLSN                  numeric(25,0), 
       DropLSN                    numeric(25,0) NULL,
       UniqueID                   uniqueidentifier,
       ReadOnlyLSN                numeric(25,0) NULL, 
       ReadWriteLSN               numeric(25,0) NULL,
       BackupSizeInBytes          bigint, 
       SourceBlockSize            int,
       FileGroupID                int,
       LogGroupGUID               uniqueidentifier    NULL, 
       DifferentialBaseLSN        numeric(25,0) NULL,
       DifferentialBaseGUID       uniqueidentifier,
       IsReadOnly                 bit,
       IsPresent                  bit,
       TDEThumbprint              varbinary(32) NULL
);
INSERT INTO @DBFiles
       EXEC sp_executeSQL N'RESTORE FILELISTONLY FROM DISK = @FileName', 
             N'@FileName NVARCHAR(4000)', @FileName = @BackupFileName;
/* Ищем выполненную последней, завершонную резервную копию */
DECLARE @lastRestoreID AS bigint = ISNULL(
       (SELECT TOP(1) restore_history_id FROM msdb.dbo.restorehistory  
             WHERE restore_type = 'D' and destination_Database_Name = @dbName 
             ORDER BY restore_history_id DESC), 0);

/* Создаём сценарий проверки восстановимости */
DECLARE @sqlcmd AS nvarchar(4000) = 
'RESTORE DATABASE @RestoreName FROM DISK = @FileName WITH ';
DECLARE @IsFirst AS tinyint = 1;
WHILE ((SELECT COUNT(*) FROM @DBFiles) > 0) 
BEGIN
       DECLARE @LN AS sysname = (SELECT TOP(1) LogicalName FROM @DBFiles ORDER BY LogicalName);
       SET @SQLcmd += 'MOVE ''' + @LN + ''' TO ''C:Restore' + @dbname+@LN + '.dbf''';
       
       DELETE @DBFiles WHERE LogicalName = @LN;
       SET @SQLcmd += ', ';
END
SET @SQLcmd += ' CHECKSUM'; 
DECLARE @RC AS int;
EXEC @RC = sp_executeSQL @SQLCmd, 
N'@RestoreName sysname, @FileName nvarchar(4000)', 
       @RestoreName = @dbName, @FileName = @BackupFileName;
IF (@RC <> 0 OR NOT EXISTS(SELECT TOP(1) * 
             FROM msdb.dbo.restorehistory  
             WHERE restore_type = 'D'  
                    AND destination_Database_Name = @dbName 
                    AND restore_history_id > @lastRestoreID))
       RAISERROR ('Database restore NOT sucessfull', 16, 0);
DBCC CHECKDB(@dbName) WITH NO_INFOMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY
IF @@ERROR <> 0 RAISERROR ('Database restore NOT sucessfull', 16, 0);

Высокая производительность резервирования по сети

Копирование двухтерабайтной базы данных на локальные жесткие диски и затем восстановление её потребует не меньше времени, чем время, затрачиваемое на развертывание 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). В таблице ниже показана продолжительность резервного копирования обычным способом и два наиболее быстрых подхода к резервированию по сети. Подробности каждой из попыток описаны ниже.

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

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

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

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

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

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

BACKUP DATABASE MyVLDB 
       TO DISK = '\BAK01backupMyVLDB00000001_1.bak',
   DISK = '\BAK01backupMyVLDB00000001_2.bak'
       WITH CHECKSUM, INIT;

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

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

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

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

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

^{Таблица 1: Подсети}

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

BACKUP DATABASE MyVLDB 
       TO DISK = '\192.168.2.2backupMyVLDB00000001_1.bak',
   DISK = '\192.168.3.2backupMyVLDB00000001_2.bak'
       WITH CHECKSUM, INIT;

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

RESTORE DATABASE MyVLDB 
       FROM DISK = '\192.168.2.2backupMyVLDB00000001_1.bak',
     DISK = '\192.168.3.2backupMyVLDB00000001_2.bak'
       WITH CHECKSUM, NORECOVERY;

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

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

BACKUP DATABASE MyVLDB 
       TO DISK = '\192.168.2.2backupMyVLDB00000001_1.bak',
   DISK = '\192.168.3.2backupMyVLDB00000001_2.bak'
   DISK = '\192.168.2.2backupMyVLDB00000001_3.bak'
          DISK = '\192.168.3.2backupMyVLDB00000001_4.bak'
       WITH CHECKSUM, INIT;

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

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

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

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

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

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

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

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

Разнесение резервного копирования и задач доступа по разным сетям

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

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

Конфигурация на Рисунке 7 использует аппаратные средства сетевого коммутатора существенно эффективнее, чем на рисунке 8.

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

Максимальный размер пакета сети 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 = '\BAK01backupMyVLDB.bak'
       WITH CHECKSUM, INIT, COMPRESSION;

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

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

Есть один недостаток сжатия – повышение утилизации процессорных ресурсов.

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

Если используется прозрачное шифрование базы данных (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 является тот интервал времени, который закладывается на задачи резервного копирования, т.е. нужно будет рассчитать и запланировать время, которое займёт весь этот процесс. Это поможет выполнить требования спецификации ко времени-восстановления работоспособности, а также, это помогает сформировать другие важные моменты аварийного плана, такие как частота выполнения резервных копий и использование сжатия. Определение времени занимаемого процессами резервного копирования и восстановления выполняется в несколько шагов. Вначале необходимо вычислить объём копируемых  данных:

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

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

К полученному по формуле значению всегда стоит добавлять не меньше 10 процентов, в качестве буфера безопасности.

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

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

1. Производительность сетевого адаптера (МБ/сек);

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

3. Производительность логического диска хранилища копий при последовательной записи (МБ/сек);

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

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

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

Коэффициент сжатия резервной копии определяется так:

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

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

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

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

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

Если разрешена мгновенная инициализация файлов, а значение FileInitFactor равно коэффициенту сжатия резервной копии, мы получим следующую формулу:

И точно так же, как в случае с расчетом времени резервного копирования, вычислить оцененное время на восстановление из копии можно так:

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

Для расчета времени выполнения полного цикла резервирования (включая проверку), можно использовать следующую формулу:

Значение BackupTime тут используется такое, как было описано ранее, а две другие переменные вычисляются так:

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

Заключение

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

Эта техническая статья предоставляет только краткий обзор возможностей резервного копирования и восстановления, а также некоторых функциональных возможностей SQL Server 2008. Для получения более подробной информации, посетите посвящённый SQL Server сайт: http://www.microsoft.com/sqlserver/2008/ru/ru/

Более подробную информацию можно получить по следующим ссылкам:

• SQL Server TechCenter

• SQL Server DevCenter  

Приложение: Используемые аппаратные средства

Сервер баз данных:

• HP Superdome с 16 двуядерными процессорами, 1.6 ГГц, 24 Мб кэш, 256 Гб ОЗУ;

• 8 двухпортовых HBA для подключения к SAN файлов данных БД;

• 8 RAID контроллеров SAS для журнала транзакций;

• 32 сетевые платы;

• Логические диски SAN были каждый по 512Гб, составленные из 256 шпинделей 15K RPM, собранные в RAID10.

Файловые серверы копий:

• HP Integrity rx 7640 Servers с 8 двуядерными процессорами, 1.6 ГГц, 8 Мб кэш, 32Гб ОЗУ;

• 4 RAID контроллера SAS (каждый с кэшем 512 Мб);

• 96 SATA дисков 7,200 RPM, собранные в 32 логических диска RAID1;

• Остальные диски использовались для создания 4 логических дисков RAID0, использовавшихся для восстановления базы данных;

• 8 двухпортовых сетевых плат (8 портов использовались для файлового ресурса резервных копий).

Сетевое оборудование:

• Коммутатор Cisco C3750E с размером фрейма 4 088 байт

Параметры настройки резервного копирования:

• BLOCKSIZE: 65536

• BUFFERCOUNT: 256

• MAXTRANSFER: 4 Мб

• Число файлов резервной копии: 32 (по 4 на сетевую плату)

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

Рисунок 10: Конфигурация сети сервера баз данных для резервного копирования