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

Резервное копирование информации

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

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

• требуемую функциональность сервисов ИС. Решение данной задачи осуществляется путем тщательного проектирования системы;
• требуемую производительность сервисов ИС. Решение данной задачи достигается правильным определением требуемых параметров технических средств (sizing). Для этого проводится технический аудит системы, замер производительности, моделирование нагрузок. Однако эти мероприятия не всегда осуществимы, например, когда система создается сначала;
• требуемый уровень доступности (availability) сервисов ИС. Задачи по обеспечению непрерывности бизнеса решаются не только правильным выбором производителя оборудования и программного обеспечения, но и в первую очередь грамотной проработкой архитектуры системы и разработкой комплекса специальных мер по обеспечению высокой доступности.

Помимо достижения требуемой функциональности, производительности и уровня доступности сервисов ИС, предприятие также стремится по возможности сократить совокупную стоимость владения системой (total cost of ownership — TCO). Внедрение системы эксплуатации ИС позволяет сократить издержки на администрирование системы и спланировать расходы на ее модернизацию. Консолидация технических средств и обслуживающего персонала в Центре обработки данных (ЦОД) также способствует сокращению расходов на эксплуатацию ИС.

Методы обеспечения высокой доступности сервисов

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

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

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

Архитектурные методы

Суть архитектурных методов можно охарактеризовать одним словом — дублирование. Дублирование сокращает время восстановления работы системы после сбоя и может осуществляться на всех уровнях ИТ-инфраструктуры:

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

Организационные методы

Организационные методы (мониторинг состояния вычислительных средств, разработка плана восстановления после аварий и тренинг персонала) предназначены для организации такого процесса эксплуатации, который свел бы до минимума время обнаружения и устранения неисправностей в системе. Организации процесса эксплуатации посвящено большое количество статей и работ, кроме того, существует «библиотека знаний» о том, как это делать наилучшим образом — ITIL. Поэтому здесь приводится лишь краткое перечисление основных организационных методов. Однако следует подчеркнуть, что применение организационных методов является необходимым и даже более важным, чем использование архитектурных методов.
Проактивный мониторинг состояния вычислительных средств и программного обеспечения ЦОД, являющийся составной частью системы эксплуатации, позволяет вовремя выявить сбои в системе и таким образом сократить время возможного простоя.

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

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

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

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

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

Централизованная система резервного копирования имеет многоуровневую архитектуру, которая включает:

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

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

*  Далее в тексте наряду с термином «компьютер-клиент» будет применяться термин «продуктивный сервер». Первый термин отражает роль и место любого компьютера (не только сервера) в системе резервного копирования, а второй термин — роль сервера по выполнению производственных задач в серверном комплексе.

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

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

- процесс резервного копирования не является критичным для решения задач ИС, т. е. сбой в системе резервного копирования не приводит к снижению доступности критичных информационных сервисов;
- нагрузка на вычислительные средства, которую создает процесс резервного копирования, не является полезной с точки зрения предоставления информационных сервисов ИС.
Поэтому систему резервного копирования не нужно резервировать, например, создавать кластер серверов резервного копирования. Однако, поскольку система резервного копирования предназначена для восстановления данных после сбоя или аварии, созданные резервные копии необходимо проверять на предмет целостности и работоспособности. Кроме этого, при построении системы резервного копирования необходимо:
- уложиться в сокращенное «окно» резервного копирования. Требование круглосуточной (24х7) работы информационных сервисов сокращает практически до нуля доступный временной интервал остановки приложений, необходимый для осуществления операции резервного копирования («окно» резервного копирования);
- уменьшить трафик данных резервного копирования в общей корпоративной ЛВС. Структура системы резервного копирования предполагает передачу данных с компьютеров-клиентов на сервера копирования через ЛВС. При наличии большого объема данных, подлежащих резервному копированию, использование общей корпоративной ЛВС для их передачи резко повысит трафик в сети и сделает ее недоступной для других приложений.

До появления сетей хранения данных (Storage Area Network — SAN) для сокращения трафика резервного копирования в основной сети применялась выделенная сеть резервного копирования (или выделенная VLAN), а также многоуровневая структура, включающая несколько серверов копирования. Выделение сервера копирования и расположение его в сети «ближе» к продуктивным серверам, обрабатывающим наибольшие объемы информации, позволяет локализовать трафик резервного копирования между сервером копирования и продуктивными серверами и сократить нагрузку на общую ЛВС.

С появлением SAN стало возможным передавать трафик резервного копирования не через ЛВС, а непосредственно с продуктивных серверов на устройства хранения данных (обычно такими устройствами являются ленточные библиотеки), подключенные к SAN. Такой метод получил название «LAN-free backup». При использовании этого метода продуктивный сервер одновременно с другими задачами выполняет функции сервера копирования резервируемых данных на доступные ему через SAN устройства хранения. При этом на сервер управления резервным копированием возлагается задача исполнения расписания резервного копирования путем выдачи через ЛВС (по протоколу TCP/IP) управляющих воздействий и контроля выполнения задач серверами копирования. Таким образом, решается задача уменьшения трафика данных резервного копирования в ЛВС.

Однако метод «LAN-free backup» не решает проблему «окна» резервного копирования. Более того, данный метод увеличивает нагрузку на продуктивные сервера, возлагая на них дополнительные функции серверов копирования резервируемых данных. Отчасти проблема «маленького окна» решается средствами приложений: ряд из них, например, СУБД Oracle, позволяет осуществлять резервное копирование, не прекращая выполнения основных задач, или с помощью специальных опций программ для резервного копирования , таких, как средства копирования открытых файлов. Однако применение подобных технологий не снижает нагрузку на продуктивные сервера, которая при больших объемах данных (терабайты и более) может увеличить время решения основных задач выше допустимого порога.

Идеальной была бы такая ситуация, когда данные продуктивного сервера копируются через SAN на устройство хранения каким-либо сторонним устройством (получившим название «data mover») «прозрачно» для продуктивного сервера, не используя при этом его вычислительные ресурсы и не прерывая его работу. Подобный метод резервного копирования получил название «serverless backup». Роль «data mover» может выполнять как выделенный для этой цели сервер, подключенный к тому же дисковому массиву, что и продуктивный сервер, так и специальное устройство — маршрутизатор. Бытует ошибочное мнение, что метод «serverless backup» предполагает использование только специальных устройств без участия серверов. На самом деле термин «serverless backup» означает, что в процессе резервного копирования не участвует продуктивный сервер, точнее, его вычислительные ресурсы либо вообще не используются, либо используются в минимальном объеме. Именно в этом состоит задача метода — снизить вычислительную нагрузку на продуктивный сервер.

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

• маршрутизатора, поддерживающего специальную команду Extended SCSI Copy Command (XCOPY). Команда XCOPY входит в семейство стандартов SCSI и позволяет передавать блоки данных с дисковых массивов на ленточные устройства записи, минуя серверы;
• моста, осуществляющего преобразование трафика Fibre Channel в SCSI (FC-SCSI) и обратно. Эта функция необходима для подключения ленточных устройств к SAN. В большинстве современных ленточных библиотек для предоставления внешних интерфейсов Fibre Channel применяют мосты FC-SCSI, выполненные в виде PCI-плат или монтируемых в шкаф библиотеки внешних устройств.

Независимо от того, каким способом реализован «Data Mover», данные продуктивного сервера необходимо подготовить для резервного копирования и передать в «Data Mover». Причем этот процесс должен происходить «прозрачно» для продуктивного сервера. Это обеспечивается встроенными в современные дисковые массивы средствами создания копий данных внутри массива. Данные, созданные такими средствами, носят название Point-In-Time (PIT)-копий, т. е. созданных (фиксированных) на определенный момент времени.

Существует две разновидности средств создания PIT-копий: клонирование и «моментальный снимок» («snapshot»). Клонирование — это полное копирование данных. Для его создания требуется столько же дискового пространства, сколько и для исходных данных, и некоторое время. При использовании такой копии нет нагрузки на дисковые тома, содержащие исходные данные, т. е. нет дополнительной нагрузки на дисковую подсистему продуктивного сервера.

Механизм работы «snapshot» иной и может быть реализован как программно на продуктивном сервере, так и аппаратно внутри массива. В момент, когда необходимо начать резервное копирование, программа-агент дает команду приложению завершить все транзакции и сохранить кэш на диск, затем создается виртуальная структура — «snapshot», представляемая для ОС и другого ПО как логический том и являющаяся картой расположения блоков данных. Приложение прерывает стандартный режим работы на очень короткое время (обычно на несколько секунд), необходимое для сохранения данных. После этого приложение продолжает работать в стандартном режиме и изменять блоки данных, при этом перед изменением старые данные блока с помощью драйвера «snapshot» копируются в область кэша «snapshot» и в карте расположения блоков данных указывается ссылка на новое местоположение блока. Таким образом, карта «snapshot» всегда указывает на блоки данных, полученные на момент завершения транзакций приложением. Блоки данных, которые не были изменены, хранятся на прежнем месте, а старые данные измененных блоков — в области кэша «snapshot». Программа-агент копирует непротиворечивые данные, полученные на момент завершения транзакций приложением, осуществляя доступ к ним через драйвер «snapshot», т. е. используя карту расположения блоков.

Создание копий с помощью «snapshot» экономит дисковое пространство, но увеличивает нагрузку на дисковую подсистему продуктивного сервера. Какой из методов создания PIT-копий выбрать, решается на этапе проектирования системы резервного копирования, исходя из требований, предъявляемых к системе.

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

Читать еще по этой теме:

Устройство комплексных систем резервного копирования