Управление нештатными ситуациями в облачных сервисах

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

Мониторинг

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

ПРИМЕЧАНИЕ

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

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

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

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

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

± через предоставляемый вам API (в случае с Amazon это будет API Web-сервисов EC2);

± с помощью ваших собственных средств мониторинга за состоянием запущенных вами экземпляров;

± с помощью средств мониторинга состояния, встроенных в ваше приложение.

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

Мониторинг не просто следит за наступлением бедственных событий, в основном он следит за обыденными событиями. При помощи enStratus я помещаю на каждый сервер сервис Python, который наблюдает за различными показателями "здоровья" сервера (server health indicators) — в основном относящимися к управлению мощностями. Этот сервис уведомляет систему мониторинга о возникновении проблем с сервером или его конфигурацией и позволяет системе мониторинга предпринять соответствующие меры. Кроме того, этот сервис проверяет и показатели, относящиеся к приложениям, работающим на экземпляре.

Восстановление балансировщика нагрузки

Одной из причин, по которым компании часто платят абсурдные суммы денег за физические балансировщики нагрузки, является существенное снижение вероятности отказа балансировщика нагрузки. Благодаря облачным провайдерам, таким как GoGrid и в будущем — Amazon, вы можете оценить преимущества аппаратных балансировщиков нагрузки  без  необходимости  нести  такие  серьезные  расходы. В текущем состоянии AWS вы должны использовать менее надежные экземпляры EC2. Восстановление балансировщика нагрузки в облачной среде, тем не менее, происходит молниеносно. Поэтому влияние сбоя балансировщика нагрузки в облачной среде сведено к минимуму.

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

ровщика нагрузки в альтернативной зоне доступности и переназначении вашего статического IP-адреса при отказе основного балансировщика нагрузки.

Восстановление сервера приложений

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

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

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

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

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

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

± Том может оказаться поврежденным точно так же, как и экземпляр.

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

± Может случиться так, что вы не сможете запускать новые экземпляры в зоне доступности тома.

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

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

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

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

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

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

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

КАК ОПРЕДЕЛИТЬ, РАБОТОСПОСОБНЫ ЛИ РЕЗЕРВНЫЕ КОПИИ?

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

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 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