Восстановление после аварий в облачной среде

Планирование действий на случай полного прерывания обслуживания вашим поставщиком облачных услуг

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

Билл Роббинс, инженер-системотехник, Educopia Institute

Bill RobbinsБилл Роббинс работает системным администратором в институте Educopia — некоммерческой организации, которая использует инфраструктуру на основе Linux® в облаке Amazon EC2. Билл получил степень магистра точных наук в области электротехники и степень бакалавра по той же дисциплине в Технологическом институте штата Джорджия. До поступления на работу в Educopia в 2008 г. Билл работал в сфере управления ИТ и сетями в компании BellSouth и университете Emory, а также в качестве инженера-разработчика в телекоммуникационных компаниях штатов Флорида и Джорджия. Он работал со многими разновидностями операционных систем UNIX еще до появления графических терминалов.



09.10.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри Облачные вычисления: общие сведения о концепции «Инфраструктура как сервис»

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

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

Часто используемые сокращения

  • DNS: система доменных имен
  • SSL: протокол защищенных сокетов

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

Виртуальность по определению

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

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

Миграция в пределах облака Amazon EC2

В разделе Загрузить представлен пример команды ec2-migrate-manifest command [описание | синтаксис | параметры], которую использовала моя организация для переноса нашей инфраструктуры в пределах облака Amazon EC2.

Моя организация использует облако Amazon Elastic Compute Cloud (Amazon EC2), и осуществить перенос из одного центра обработки данных Amazon в другой относительно просто. В облаке Amazon это делается волшебной командой ec2-migrate-manifest. Однако если вы осуществляете перенос из центра обработки данных одного поставщика в центр обработки данных другого поставщика, это сопряжено с бóльшими сложностями, чем когда вы выполняете перенос из одного центра обработки данных в другой центр обработки данных того же поставщика. Существует много поставщиков сред облачных вычислений; вам необходимо самостоятельно определить наилучший вариант для восстановления в аварийных ситуациях. В любом случае, независимо от того, используете ли вы Amazon EC2 или облако другого поставщика, вам необходимо сначала провести небольшое пробное испытание, прежде чем начинать полноценное тестирование восстановления в аварийных ситуациях.


Проведение пробного испытания

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

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

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


Что должно работать на вашей резервной площадке

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

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

Как узнать обо всем, что фактически содержится в вашем облаке? Возможно, эти сведения задокументированы; убедитесь в том, что документация содержит актуальную информацию. Войдите в оболочку на своем работающем производственном сервере и убедитесь в том, что он работает нормально. Выполните указанные ниже действия для создания файлов, которые помогут вам зарегистрировать элементы на сервере (приведенные команды должны работать в любой версии операционной системы Red Hat Linux®):

  1. Зарегистрируйте выполняемые процессы:
    ps –ef  > /tmp/procs.txt
  2. Определите активные соединения на сервере:
    netstat -an > /tmp/connects.txt
  3. Определите файловые системы на сервере:
    df -ah > /tmp/mounts.txt
  4. Зарегистрируйте выполняемые задания cron:
    cd /var/spool/cron
    
    more * > /tmp/crons.txt

Поскольку вы переносите виртуальный сервер, а не производите восстановление «с нуля» физического сервера, определять каждый пакет программ и каждый модуль (например, модули Apache или Perl) или Ruby GEM в вашей системе не требуется. Все эти элементы будут на месте, так как вы копируете виртуальные образы.

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

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

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

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

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

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


Поддержание резервной площадки в актуальном состоянии

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

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

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


Проведение комплексного тестирования

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

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

Новые идентификационные данные сети

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

Хотя методы, используемые для обновления A-записи, могут быть разными, в целом требуется знать идентификатор и пароль учетной записи у вашего поставщика DNS, а также порядок изменения записей. Зарезервируйте на постоянной основе какой-либо IP-адрес на своей резервной площадке и введите данный IP-адрес в качестве записи DNS. Присвоение ему какого-либо имени гарантирует, что при поиске данного IP-адреса будет возвращаться действительная запись.

Например, если адрес вашего Web-сайта www.agreatsite.com, назначьте резервному серверу постоянно действующую запись DNS типа alt-www.agreatesite.com или drwww.agreatesite.com. При проведении тестирования восстановления после аварий (и при фактическом возникновении аварийных ситуаций) вам просто нужно зайти на сайт своего поставщика DNS и переключить IP-адрес сайта www.agreatsite.com на IP-адрес резервного сайта: никаких причин изменять или удалять запись для alt-www.agreatsite.com не существует. Наличие записи DNS может помочь, когда другим сайтам или серверам также потребуется ввести данные о вашем резервном сервере в свои настройки безопасности.

Настройки безопасности для новых идентификационных данных

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

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

Изменения на резервной площадке

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

  • Часовой пояс.
  • Хранилище для резервных копий и архивов.
  • Функции среды облачных вычислений, которые необходимо воспроизвести.
  • Изменения сценариев или программного кода, связанных с такими функциями.
  • Изменения сценариев или программного кода, которые используют IP-адреса вместо имен хостов.

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


Тестирование восстановления после аварий

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

Подчеркну: это будет единственный раз, когда вы точно будете знать об аварии!

Начало тестирования

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

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

Вперед к резервному облаку

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

После начальной загрузки сервера, возможно, потребуется «нанести последние штрихи». Например, для использования средств хранения данных на резервной площадке может быть необходимо изменить сценарии, выполняемые на сервере. Безусловно, вам придется удалить или изменить задачу, которая регулярно создает ваши резервные образы. Возможно, вам также потребуется изменить время выполнения заданий cron.

Проведение функциональной проверки

После того как изменения настроек DNS будут переданы (по нашему опыту, это занимает от 2 до 4 часов) вы можете приступать к тестированию. Здесь следует идти по прямому пути и немного заняться инженерным анализом. В первую очередь проверьте самое очевидное, например, работают ли Web-сайты. У вас уже должна быть лента RSS, в которой указываются все сайты, работающие в вашем облаке. Если такой ленты нет, создайте ее сейчас. Лента должна включать информацию как об общедоступных сайтах, так и о сайтах, используемых вами для администрирования сервера, например сайтах входа в систему пользователей phpMyAdmin и Drupal. Точно так же проверьте мониторинг своих процессов. Нет ли чего-либо, что было введено в действие временно и теперь может быть отменено? Может быть, какой-либо процесс на другой площадке пришлось отключить, а теперь его можно включить снова.

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

Документирование информации

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


Возврат к основной площадке и повторное выполнение всех действий

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

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

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


Заключение

Действия по восстановлению в аварийных ситуациях для каждой организации и каждой площадки будут разными. В этой статье приводится хорошая начальная информация, а также говорится об аспектах, требующих внимания. Разумеется, можно изучить и некоторые другие вопросы. Например, может потребоваться больше времени или расходов, если к вашим IP-адресам привязаны сертификаты SSL. Возможно, вы сможете избежать изменения сценариев, выполняемых на основной площадке, по сравнению со сценариями, выполняемыми на резервной площадке сайте, просто добавив в сценарии программный код для определения места выполнения. Я планирую сделать это в следующий раз; рекомендую изучить полезный сайт www.whatismyip.com. Вы можете использовать следующую команду:

wget http://www.whatismyip.com/automation/n09230945.asp -O public_ip.txt

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

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

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


Загрузка

ОписаниеИмяРазмер
Пример использования команды ec2-migrate-manifestec2-ami.zip1 КБ

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Information Management
ArticleID=839704
ArticleTitle=Восстановление после аварий в облачной среде
publish-date=10092012