Резервное копирование данных в среде SAN

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

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

До появления технологии SAN вопросы резервного копирования решались довольно просто. Устройство хранения данных подключалось локально к одному из серверов, известному также как медиа-сервер (media-server), а тот в свою очередь осуществлял резервное копирование клиентов в данном сетевом сегменте. Как правило, для этого использовались устройства с параллельными интерфейсами, например интерфейсом SCSI.

Как показывает статистика, подобная технология оправдана в тех случаях, когда объемы всей копируемой информации не превосходят величины 1 Тбайт. При больших величинах локальная сеть Ethernet на 10/100 Мбит/c становится узким местом и не способна передавать необходимый объем данных в пределах заданного временного окна.

Недостатки традиционных систем

Жесткие требования к системе резервного копирования влекут за собой необходимость ее частой модернизации. В качестве одного из способов ускорения резервирования данных было предложено создание на базе сети 100BaseT дополнительного изолированного сетевого сегмента, известного как выделенная магистраль резервного копирования (Dedicated Backup Backbone, DBB). Однако и в этом случае, согласно статистическим исследованиям, производительность увеличивается не более чем в два раза и в среднем составляет около 5 Мбайт/с. Причина заключается в наличии большого количества промежуточных каналов ввода/вывода, по которым осуществляется передача резервируемых данных, причем как на стороне клиента, так и на стороне сервера. К ним можно отнести: системную шину, SCSI и сетевые адаптеры. Заметим, что на каждом участке неизбежно происходит задержка передаваемых блоков данных, в результате чего средняя скорость их передачи снижается.

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

• Ограниченное количество контроллеров ввода/вывода, которые могут быть установлены в серверы. Ограничение накладывалось как со стороны аппаратных возможностей (по количеству свободных слотов на системной плате), так и программного обеспечения (по количеству поддерживаемых операционной системой каналов ввода/вывода).
• Ограниченное количество оборудования (дисковые массивы, устройства резервирования), которое могло бы быть подключено к контроллерам ввода/вывода (SCSI Host Bus Adapter, HBA).
• Ограниченная физическая емкость самих устройств хранения данных.

На число устройств может повлиять и другой фактор — максимальное поддерживаемое количество адресов SCSI для подключения дополнительных накопителей. Так, интерфейс Wide SCSI способен поддерживать до 15 целевых устройств (Target). В ряде случаев это количество может быть увеличено за счет использования номеров логических устройств (Logic Unit Number, LUN) — до 16 дополнительных номеров на каждое целевое устройство. Однако это не всегда осуществимо по причине того, что не все устройства хранения данных допускают подобное расширение в полном объеме. Вместе с тем, даже когда все свободные адреса, предоставляемые шиной SCSI, могут быть задействованы, работа подключенных к ней устройств с максимальной эффективностью вряд ли возможна, поскольку каждое из них будет иметь свой приоритет (определяемый номером целевого устройства) на захват и использование шины SCSI при передаче блоков данных.

Рисунок 1. Сравнение резервного копирования по а) локальной сети и б) сети SAN.

Архитектура SAN позволяет снять ограничения подобного рода и подойти к решению этих вопросов более гибко. На Рисунке 1 представлены главные отличия технологии резервного копирования с помощью SAN от популярной в настоящее время технологии копирования данных по локальной вычислительной сети, когда все устройства хранения информации подключаются к серверам через ту или иную шину (SCSI, IDE, EIDE).

В качестве очевидного преимущества можно отметить, что архитектура SAN не предполагает установку на серверы большого количества адаптеров шины хост (Host Bus Adapter, HBA). При этом даже единственное соединение узла со средой SAN дает ему возможность получить доступ к неограниченному количеству как дисковых накопителей, так и устройств резервирования данных. Кроме того, в архитектуре SAN заложена возможность ее масштабирования путем каскадного соединения оптических коммутаторов (Fibrе Channel Switch, SAN Switch, HUB) и добавления необходимого количества адресов (портов ввода/вывода).

Не говоря уже о том, что скорость передачи данных достигает 100 Мбайт/с, при работе в среде SAN отсутствует свойственная шинной архитектуре проблема приоритета доступа к конечным устройствам. При возникновении потребности в канале ввода/вывода между каким-либо узлом и дисковым накопителем, канал будет предоставлен независимо от того, какой приоритет по доступу имеет дисковый накопитель или ленточный привод. Он будет сформирован на базе изолированной оптической петли (Private Virtual Circuit, PVC), причем какие-либо другие устройства не могут к ней подключиться.

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

Резервное копирование в обход локальной сети

Как было отмечено, исключение сетевого сегмента из пути резервного копирования данных позволяет избежать излишних задержек на передачу трафика через сеть IP и платы ввода/вывода. В архитектуре SAN необходимость подключения устройств резервного копирования непосредственно к серверу хранения, порой используя большое количество кабелей SCSI, полностью устранена. Благодаря протоколу Fibre Channel несколько каналов передачи данных может быть организовано с помощью одного оптического кабеля. При этом весь объем резервируемых данных с медиасерверов хранения направляется на ленточное устройство, минуя локальную сеть.

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

В зависимости от требований политики резервного копирования, каждый сервер с соответствующим приложением и каждое устройство резервного копирования могут быть гибко и оперативно сконфигурированы без остановки приложений. Гибкость, благодаря возможности организации независимых зон внутри SAN, — одно из главных достоинств этой архитектуры. По сути, при передаче резервируемых данных формируются изолированные друг от друга каналы ввода/вывода между медиасервером и дисковым массивом или медиа-сервером и устройством резервного копирования (см. Рисунок 2).

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

На протяжении многих лет выбор ленточных библиотек в качестве устройств резервного копирования данных определялся низкой стоимостью хранения данных по отношению к другим альтернативным накопителям. Очевидно, что подобная тенденция сохранится и в ближайшее время. Для библиотечного устройства в архитектуре SAN характерно предоставление множественного доступа к нему со стороны нескольких серверов, входящих в одну зону. В результате ленточное устройство библиотеки сервера поступает в распоряжение того, кто первым подал запрос. При этом второй сервер получит сообщение от моста SCSI (FC/SCSI Bridge) о занятости устройства. Робот библиотеки будет ожидать освобождения ленточного привода.

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

Поэтому вторым этапом в создании политики резервного копирования является объединение ленточных носителей в отдельные комплекты (Media Pools), где в дальнейшем будут храниться данные соответствующих серверов.

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

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

Рисунок 3. Поэтапный процесс соединения сервера с библиотекой.

Каждый сервер сможет обратиться к ленточной библиотеке только после получения необходимого разрешения от посредника соединений. На Рисунке 3 представлен весь процесс поэтапного соединения. В начальный момент по локальной сети сервер отправляет запрос на соединение с библиотекой к посреднику (1). Тот проверяет локальную конфигурационную информацию о запрашивающем сервере, о ленточной библиотеке и ее ленточных приводах (2). Установив доступность библиотеки (3), посредник определяет путь к свободному ленточному приводу и передает его на запрашивающий сервер (4). С этого момента сервер получает канал ввода/вывода к соответствующему ленточному устройству (5). Одновременно он имеет право отправить команду роботу ленточной библиотеки на загрузку ленточного носителя в указанный ленточный привод.

Запросы на доступ к библиотеке со стороны других узлов будут обработаны или поставлены в очередь в зависимости от состояния ленточных приводов. В этом случае все конфликты на доступ к библиотеке разрешаются посредником.

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

В целом контроль за политикой резервного копирования, как правило, осуществляется с одного главного сервера (Master Server), причем для этого вполне достаточно обычного сегмента локальной сети (Ethernet на 10/100 Мбит/с).

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

Резервное копирование без участия сервера

Техническая мысль продолжает развиваться в направлении большей интеграции резервного копирования в архитектуру SAN. В целях максимального освобождения работающего сервера от участия в резервном копировании данных была предложена технология резервного копирования без участия сервера (Severless Backup). Ее суть состоит в привлечении для резервного копирования дополнительного третьего узла, полностью отвечающего за процесс копирования, отсюда и другое название этого подхода — копирование с участием третьей стороны (third-party copy).

Рисунок 4. Составление индекса.

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

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

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

Относительно к технологии резервного копирования без участия сервера может возникнуть резонный вопрос — какое из устройств при наличии доступа к индексу блоков данных способно непосредственно осуществить их перенос на ленточную библиотеку? В принципе это доступно любому устройству из состава SAN, лишь бы оно обладало достаточной интеллектуальностью для формирования SCSI-команды расширенного копирования (X-copy) на основании индексного листа блоков данных. Иными словами, от него потребуется стать той движущей силой, которая будет контролировать перемещение блоков данных с одного устройства на другое. Главная идея данной технологии представлена на Рисунке 5.

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

Каким образом происходит передача списка блоков данных с рабочего сервера? Для этой цели на сервере данных устанавливается программный агент: он обрабатывает запросы с сервера резервирования данных и подготавливает блоки данных, т. е. «замораживает» их на период резервного копирования (делает снимок). При этом он выполняет одну из важных ролей в технологии резервного копирования без участия сервера: непосредственно обращается к файловой системе работающего сервера данных и получает необходимый список блоков, относящийся к той или иной активной базе данных или файловой системе. Далее сгенерированный список передается на узел, выполняющий роль инициатора перемещения блоков данных (Data Mover), после чего тот берет под контроль все операции записи или чтения.

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

Сам процесс может быть условно разбит на три этапа:

• синхронизацию файловой системы;
• создание снимка файловой системы, файлы которой предстоит восстановить;
• процесс восстановления файлов.

Очевидно, что при восстановлении понятие «без участия сервера» в какой-то степени утрачивает свой смысл, так как сам сервер данных принимает непосредственное участие в восстановлении информации, однако это не умаляет основных достоинств этого подхода.

К преимуществам представленной выше технологии можно по праву отнести:

• устранение загрузки трафиком локальной сети предприятия;
• значительное снижение нагрузки на процессор и контроллеры ввода/вывода рабочего сервера данных;
• безопасное резервное копирование работающей файловой системы в режиме "снимка";
• высокую скорость передачи копируемых блоков с использованием среды SAN.

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

В Таблице 1 представлен сравнительный анализ трех основных технологий резервного копирования: по локальной сети, в обход локальной сети и без участия сервера.

Перспективы развития архитектуры SAN

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

Если заказчик стремится максимально использовать существующую сеть Ethernet, в особенности Gigabit Ethernet, то, как правило, он предпочитает решение на основе сетевых устройств хранения NAS. При этом в качестве NAS выступает сервер с установленным минимальным ядром операционной системы, специально адаптированным для облегчения доступа к файлам. Протоколами доступа чаще всего служат широко распространенные протоколы, ориентированные на работу с файлами: NFS, CIFS, или HTTP поверх TCP/IP. Доступ к хранящимся данным происходит через обращение к файлам.

Здесь-то и возникает одно из противоречий с архитектурой SAN, где применяется блочный доступ к хранимым данным. Для узлов, включенных в эту архитектуру, все дисковые устройства видны как локальные. Доступ осуществляется посредством протокола блочного доступа Fibre Channel. Вместе с тем, ограничение на максимальную длину оптических каналов в сетях SAN составляет 10 км. В результате при широком применении архитектуры SAN возникнет необходимость объединения разрозненных сегментов сетей, поддерживающих подобную архитектуру.

В качестве альтернативного решения не так давно был разработан и предложен протокол iSCSI. Его применение позволяет с помощью сети IP объединить территориально разнесенные серверы и рабочие станции, с одной стороны, и устройства хранения данных — с другой, решив тем самым проблему удаленного доступа, а впоследствии и резервного копирования из любого сегмента локальной или глобальной сети. Передача команды SCSI поверх TCP/IP сделала возможным удаленное управление и передачу данных через распределенную систему сетей Intranet. В этом случае отсутствует физическая привязка устройств хранения не только к какому-либо серверу (узлу), но и к сегменту любой вычислительной сети. Благодаря тому, что iSCSI функционирует поверх протокола TCP/IP, он позволяет одновременно организовать несколько каналов ввода/вывода между несколькими конечными устройствами при наличии всего одного порта Ethernet.

В ряде случаев применение протокола iSCSI возможно с минимальными затратами, так как он в состоянии работать в существующих сетях Ethernet, в том числе и Gigabit Ethernet. Более того, при необходимости трафик можно передавать через имеющиеся соединения Internet/Intranеt.

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

Говоря о резервном копировании больших объемов данных, нельзя не упомянуть и о серверах NAS. Общий объем хранимых на этих серверах данных может достигать десятков терабайт, поэтому для осуществления эффективного резервного копирования таких объемов был разработан протокол (Network Data Management Protocol, NDMP). Он, как и iSCSI, изначально предназначался для передачи команд резервного копирования на серверы NAS поверх протокола TCP/IP. В силу своего специфического назначения протокол NDMP на начальном этапе не нашел столь широкого применения, кроме решений указанного класса. Однако, с увеличением количества проектов с использованием архитектуры SAN, все большее число серверов, поддерживающих протокол NDMP, стало интегрироваться в окружение SAN, взяв на вооружение функции расширенного копирования команд SCSI.

В настоящее время все чаще приходится сталкиваться с необходимостью комбинированного применения двух технологий — как SAN, так и NAS. В этом случае сервер NAS становится своего рода шлюзом (NAS Gateway) для доступа к блокам данных, размещенным на дисковых массивах, входящих в окружение SAN. До появления iSCSI для доступа к блочным устройствам (к дискам и ленточным библиотекам) в сети SAN использовался протокол FC (FC SAN). Однако уже сейчас ряд производителей предлагают в качестве альтернативного решения устройства с поддержкой протокола iSCSI, позволяя тем самым создавать IP SAN.

Тем не менее широкое внедрение протокола iSCSI сдерживается рядом факторов. В ряде случаев пропускной способности существующих сетей IP может быть недостаточно для обеспечения доступа к хранимой информации с требуемыми параметрами. Исходя из этого, для снижения задержек и возможных ошибок для передаваемых блоков данных (команд SCSI) существующие сети должны быть адаптированы для работы со iSCSI. Несмотря на всю универсальность, лучшие результаты от применения iSCSI можно ожидать в сетях Gigabit Ethernet. Другим сдерживающим фактором может стать сетевая безопасность. Для удовлетворения соответствующих требований протокол обязан поддерживать как процедуру аутентификации, так и дополнительное шифрование данных.

В качестве иной альтернативы протоколу iSCSI, а также для преодоления ограничения в 10 км было предложено решение на базе протокола Fibre Channel поверх IP (Fibre Channel over IP, FCIP). В его основу заложена возможность объединения разрозненных сегментов сетей SAN в единую сеть путем их соединения посредством мостов между Fibre Channel и IP. В этом случае для передачи пакетов Fibre Channel между сегментами SAN формируется выделенный туннель, в результате чего устройства, принадлежащие одному сегменту, могут быть доступны узлам из других сегментов SAN. Очевидно, что применение данного протокола наиболее экономически оправдано, когда встает необходимость с минимальными затратами объединить существующие сети SAN с уже проложенными оптическими кабельными каналами.

Промежуточным решением между iSCSI и FCIP стало предложение на базе протокола iFCP. В противоположность двум перечисленным выше протоколам, iFCP предлагается как некий универсальный подход для объединения уже имеющихся сетей SAN и TCP/IP.

Подобно FCIP, протокол iFCP позволяет передавать пакеты Fibre Channel по имеющимся каналам TCP/IP. Отличие состоит в способе адресации. Если FCIP позволяет организовать туннели «точка-точка» для объединения разрозненных сегментов SAN в единую сеть, то при использовании iFCP за основу берется способ маршрутизации «от шлюза до шлюза», сочетающий как адресацию FC, так и адресацию IP, обеспечивая при этом передачу пакетов по заданному маршруту.

Другой разновидностью протокола iFCP является mFCP (Metropolitan FCP), где вместо TCP используется протокол UDP.

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

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

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

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