Отключение Amazon Cloud затронуло множество стартапов, малых и средних предприятий и компаний корпоративного уровня. Тем не менее, многие компании все еще внедряют облачные решения. Сервисы Amazon Cloud специально предлагают гибкий доступ к инфраструктуре и оборудованию класса A, а также модель с оплатой по факту.
К сожалению, то, что можно считать небольшим затруднением на стороне Amazon, может привести к кошмару для DevOps и ИТ-менеджеров. Ситуация может легко усложниться, когда веб-сайты и компании с высокой видимостью (например, Quora) внезапно прекратят работу из-за перебоев в работе, и ответственные за их облако начнут задумываться о перемещении поставщиков решений или тратить время и деньги на погоню за хвостами.
В Newvem Analytics мы провели мониторинг сотен учетных записей Amazon Cloud — на некоторые из них повлияло как отключение в апреле 2011 года, так и отключение AWS на прошлой неделе. Наблюдая за использованием AWS нашего пользователя, мы обнаружили, что более 35% наших бета-партнеров используют облако, которое очень уязвимо к сбоям.
Но так не должно быть.
Хорошей новостью является то, что вам не нужно быть гуру Amazon AWS, чтобы защитить облако от возможного сбоя. Наша аналитическая команда собрала этот список из пяти обязательных методов ведения бизнеса сделать облако AWS лучше защищенным от перебоев в обслуживании.
1. Используйте преимущества нескольких зон доступности при использовании эластичной балансировки нагрузки. Балансировка нагрузки входящего трафика вашего приложения между несколькими экземплярами делает его более отказоустойчивым. Кроме того, вы можете еще больше повысить отказоустойчивость, включив упругую балансировку нагрузки (ELB) в нескольких зонах доступности. В случае выхода из строя одной зоны доступности ELB по-прежнему будет обеспечивать работоспособность за счет распределения трафика между экземплярами в других зонах доступности.
2. Знайте о нездоровых случаях позади ELBs . Нездоровые экземпляры не получают трафик от ELB. Это означает, что даже если у вас достаточно экземпляров за ELB (даже в нескольких зонах доступности), нездоровый экземпляр вообще не будет получать трафик.
3. Сохраняйте своевременные снимки ваших EBS. В случае, если сбой повреждает том EBS, пользователь может воссоздать том из моментального снимка в том же состоянии, что и момент моментального снимка. Если зона доступности, в которой EBS был активен, остается недоступной в течение длительного времени, пользователь может подготовить том EBS из моментального снимка в другой зоне доступности. Тома привязаны к зонам доступности, но снимки привязаны только к региону. Если ваши тома недоступны в одной зоне доступности, вы можете восстановить последний сохраненный снимок в другой зоне доступности.
4. Храните критически важные копии данных в облаке AWS. Очень важно хранить удаленные копии важных данных. Мы также рекомендуем использовать сторонние сторонние службы для резервного копирования ваших данных. Однако здесь следует соблюдать осторожность, поскольку некоторые из этих служб могут работать поверх AWS.
5. Используйте внешний инструмент для мониторинга вашей системы. AWS CloudWatch — это удобный сервис для мониторинга ваших ресурсов AWS, однако уровень взаимозависимости сервисов AWS не всегда ясен — иными словами, он может быть ненадежным в случае сбоя. По этой причине, хотя CloudWatch может быть вашей обычной системой мониторинга для AWS, вы должны рассмотреть внешнюю систему мониторинга, отдельную от AWS, которая будет оповещать вас о сбое независимо.
Существует множество инструментов и рекомендаций, которые могут повысить ваши шансы на бесперебойную работу во время сбоя AWS. Это простые шаги, которые вы можете предпринять для защиты ваших данных и повышения их шансов на выживание в случае сбоя.
Хотя это ценные советы, которые помогут вам пережить сбой, они являются лишь началом планирования аварийного восстановления и, конечно, не гарантируют, что ваше облако все еще будет работать после сбоя.