Управление резервным копированием в облачных сервисах

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

РЕЗЕРВНОЕ КОПИРОВАНИЕ,

НЕПРЕРЫВНОСТЬ БИЗНЕСА И AMAZON WEB SERVICES

В данном разделе будет рассматриваться ряд технологий, предоставляемых Amazon Web Services (AWS) с тем, чтобы помочь вам эффективно управлять процессом резервного копирования. Если вы пользуетесь услугами другого облачного провайдера, то эта компания, вероятнее всего, предложит вам как средства, аналогичные описанным здесь, так и радикально отличающиеся. Однако концепция удаленного резервного копирования и хранения резервной копии за пределами вашего центра обработки данных играет ключевую роль в любой стратегии резервного копирования. Какой бы ни была ваша стратегия резервного копирования, вы должны выработать не только механизм выведения всех данных, имеющих критическое влияние на ваш показатель целевой точки восстановления (RPO), за пределы облачной инфраструктуры, но и разработать способ хранения этих данных в переносимом формате с тем, чтобы получить возможность их восстановления в любой среде, которая может радикально отличаться от среды, предоставляющейся вашим текущим облачным провайдером.

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

Таблица 6.1. Требования к резервному копированию в зависимости от типов данных

Тип данных

Описание

Неизменные данные (Fixed data)

Неизменные данные, такие как ваша операционная система и утилиты общего назначения, принадлежащие вашему AMI.

В облачной среде вам нет необходимости выполнять резервное копирование AMI, потому что они не имеют никакой ценности за пределами облачной среды1

1 Имейте в виду, что даже в случае полного выхода из строя Amazon S3, в результате которого вы теряете все ваши AMI, до тех пор, пока доступен сервис EC2 и в вашем распоряжении остаются экземпляры EC2, запущенные из утраченных AMI, вы все равно будете иметь возможность быстрой перестройки утраченных AMI. С другой стороны, в случае одновременного отказа EC2, S3 и полной потери всех данных S3 вам потребуется выполнять восстановление в другой облачной среде, которая в любом случае не сможет распознавать ваши AMI!

Таблица 6.1 (окончание)

Тип данных

Описание

Текущие данные (Transient data)

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

Конфигурационные данные (Configuration data)

Конфигурационные данные времени исполнения (Runtime configuration data), необходимые для обеспечения правильной работы вашей системы в специфическом контексте. Эти данные не являются текущими, поскольку они должны "переживать" такие события, как перезапуск машины. С другой стороны, эти данные должны предоставлять возможность быстрого переконфигурирования при "чистой" установке приложения. Такие данные требуют более или менее регулярного резервного копирования

Сохраняемые данные (Persistent data)

К сохраняемым данным относится состояние вашего приложения, в том числе критически важная клиентская информация (например, заказы на покупки). Эти данные постоянно изменяются, и наилучшим средством для управления ими является "движок" базы данных.

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

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

Стратегия в отношении неизменных данных

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

Стратегия в отношении конфигурационных данных

Хорошо продуманная стратегия резервного копирования для конфигурационной информации предусматривает двухуровневый подход. При этом первый уро-

вень представляет собой регулярный сброс дампа вашей файловой системы в ваше облачное хранилище или "моментальный снимок" вашей файловой системы. Для большинства приложений вы можете выполнять резервное копирование ваших данных ежедневно или раз в неделю (даже это будет уже неплохо). Но при этом вам необходимо иметь в виду ваш показатель целевой точки восстановления (Recovery Point Objective). Если ваши конфигурационные данные изменяются дважды в день, и при этом вы установили для себя значение RPO, равное 2 часам, вам потребуется выполнять резервное копирование ваших конфигурационных данных дважды в день. Если конфигурационные данные изменяются нерегулярно, возможно, вам потребуется выполнять их резервное копирование раз в час или "привязать" ваше расписание резервного копирования к изменениям в конфигурации приложения.

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

Не имеет значения, что вы предпочтете — выполнять моментальные снимки вашей файловой системы или просто держать запакованные архивы вашей файловой системы — эти данные будут находиться в режиме гибернации в недрах S3. Общая тенденция такова, что "моментальные снимки" представляют собой более эффективный и менее "назойливый" механизм выполнения резервного копирования, но зато он обеспечивает и гораздо меньший уровень переносимости. У вас нет прямого доступа к моментальным снимкам EC2, и даже если бы вы его имели, этот формат не может быть использован за пределами облачной среды Amazon. На определенном этапе вам все же понадобится вывести эти данные за пределы облачной инфраструктуры, поэтому вам понадобятся хранящиеся на стороне резервные копии в переносимом формате. Мои рекомендации сводятся к следующему.

± Регулярно (как минимум, ежедневно) создавайте моментальные снимки ваших конфигурационных данных.

± Периодически создавайте архивы вашей файловой системы (по крайней мере, периодичность должна быть меньше, чем ваш показатель RPO), упаковывайте его в форматы ZIP или TAR, и помещайте эти архивы на хранение в Amazon S3.

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

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

± Создавать моментальные снимки файловой системы раз в час, а всю файловую систему архивировать в переносимом формате и, как минимум, один раз в день копировать в Amazon S3.

± Я бы хранил недельный архив полных резервных копий в S3 на случай возникновения вопросов с повреждениями данных. В дополнение к этому я бы копировал каждую недельную резервную копию из S3 в другую облачную среду или на собственные физические файл-серверы внутренней инфраструктуры IT в заранее оговоренный момент времени сразу же после создания резервных копий.

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

Различные требования к показателю RPO и поведению приложений диктуют выбор различных стратегий. Подчеркнем еще раз: вам необходимо очень четко оценить ваш показатель целевой точки восстановления (RPO), потому что от него зависит выбор подходящей для вас стратегии резервного копирования. Если взять только что приведенный пример, то описанная в нем стратегия позволит создать рабочий план по развертыванию среды приложения в любом центре обработки данных в любой географической точке с потерей данных, не превышающей наработки за последние 24 часа, за исключением ситуации полного повреждения данных на всех резервных копиях и одновременной полной потери всех хранилищ (как Amazon, так и всех резервных копий, хранящихся за пределами рабочей площадки).

Стратегия в отношении сохраняемых данных (резервное копирование баз данных)

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

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

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

Первой "линией обороны", позволяющей избежать нарушения целостности данных, является применение или репликации с несколькими ведущими узлами (multimaster replication), или кластеризации (clustering). База данных с несколькими ведущими узлами представляет собой базу данных, в которой два ведущих сервера баз данных независимо друг от друга ведут запись транзакций, а затем реплицируют их на другой ведущий сервер. В кластерной среде обработки баз данных имеется множество серверов, которые действуют как единый логический сервер. При использовании обоих сценариев система остается работоспособной и внутренне непротиворечивой.

Кроме того, вы можете выполнять репликацию по сценарию "главный—подчиненный" (master-slave replication). Репликация по сценарию "главный—подчиненный" подразумевает настройку главного сервера, который управляет операциями записи и затем тиражирует транзакции на подчиненный сервер (slave). Каждый раз, когда на главном сервере что-то происходит, он реплицирует изменение на подчиненный сервер.

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

± устанавливаю и настраиваю главный сервер так, чтобы его данные хранились на устройстве блочного хранения;

± устанавливаю и настраиваю подчиненный сервер так, чтобы его файлы данных располагались на устройстве блочного хранения;

± регулярно создаю моментальные снимки устройства блочного хранения главного сервера, основываясь на выбранном значении показателя целевой точки восстановления (RPO);

± регулярно создаю дампы базы данных на подчиненном сервере и сохраняю их в S3;

± время от времени копирую дампы базы данных из S3 в хранилище, расположенное за пределами облака Amazon.

ПРИМЕЧАНИЕ

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

Эластичное блочное устройство Amazon (Elastic Block Storage, EBS) предлагается еще недостаточно долго для того, чтобы иметь полную уверенность в том, что вы сможете обнаружить повреждение базы данных в случае отказа сервера MySQL. Я исхожу из предположения, что повреждения имеют высокую вероятность, как и в случае с любой файловой системой, и соответствующим образом выстраиваю свою стратегию резервного копирования. В этом отношении я могу быть и неправ, но на данный момент я предпочитаю соблюдать осторожность.

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

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

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

1.      Заблокируйте базу данных.

2.      Синхронизируйте файловую систему (эта процедура зависит от файловой системы).

3.      Создайте моментальный снимок.

4.      Разблокируйте базу данных.

Весь процесс должен занимать около секунды.

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

ПРИМЕЧАНИЕ

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

Для создания дампа базы данных необходимо проделать следующие шаги:

1.      Осуществите сброс дампа базы данных.

2.      После завершения сброса дампа зашифруйте дамп и разбейте его на небольшие управляемые "цепочки".

3.      Переместите дамп в S3.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100