Этим летом у AWS был сбой в одном из их центров обработки данных. В отличие от прошлого года , отключение в этом году оказало меньшее влияние только на одну зону доступности в восточно-американском регионе AWS. Ни один из клиентов, для которых мы настроили их инфраструктуру в AWS, не пострадал во время простоя. Один из клиентов запаниковал и сообщил, что экземпляры становятся недоступными только для того, чтобы обнаружить, что экземпляры в других AZ работают нормально, а веб-сайт продолжает оставаться доступным. Еще интереснее было то, что на следующий день один из ведущих индийских поставщиков развлекательного контента связался с нами и попросил нас оценить их существующую инфраструктуру AWS. Пока я разговаривал с клиентом, я случайно спросил основную причину этой оценки. Он упомянул, что их веб-сайт полностью размещен в AWS, и он отключился во время простоя. И он не знал, что веб-сайт был закрыт, пока кто-то из их команды случайно не обнаружил, что веб-сайт не работает.
Вот обновление от AWS о том, что пошло не так. Полная информация доступна на странице панели мониторинга работоспособности службы AWS, но к ней может быть затруднен доступ к следующей неделе, так как виджет даты перемещается вперед.
»
Примерно в 8:44 вечера по ФДТ произошла неисправность кабеля в высоковольтной распределительной сети. Две служебные подстанции, которые питают затронутую зону доступности, отключились, в результате чего вся зона доступности переключилась на питание генератора. Все экземпляры EC2 и тома EBS успешно переведены на резервное питание генератора. В 8:53 PM PDT один из генераторов перегрелся и отключился из-за неисправного охлаждающего вентилятора. В этот момент экземпляры EC2 и тома EBS, поддерживаемые этим генератором, переключаются на свою вторичную резервную мощность (которая обеспечивается полностью отдельной цепью распределения мощности с дополнительной мощностью генератора). К сожалению,один из выключателей в этой конкретной резервной цепи распределения питания был неправильно настроен на размыкание при слишком низком пороговом значении мощности и размыкался при передаче нагрузки на эту цепь. После того, как этот автоматический выключатель отключился в 8:57 вечера PDT, затронутые экземпляры и тома остались без первичного, резервного или вторичного резервного питания. Те клиенты с уязвимыми экземплярами или томами, которые работали в конфигурациях зоны доступности, избежали значительного нарушения работы своих приложений; однако пострадавшие, которые работали только в этой зоне доступности, должны были ждать, пока питание не будет восстановлено, чтобы оно полностью функционировало.Те клиенты с уязвимыми экземплярами или томами, которые работали в конфигурациях зоны доступности, избежали значительного нарушения работы своих приложений; однако пострадавшие, которые работали только в этой зоне доступности, должны были ждать, пока питание не будет восстановлено, чтобы оно полностью функционировало.Те клиенты с уязвимыми экземплярами или томами, которые работали в конфигурациях зоны доступности, избежали значительного нарушения работы своих приложений; однако пострадавшие, которые работали только в этой зоне доступности, должны были ждать, пока питание не будет восстановлено, чтобы оно полностью функционировало.»
Используйте несколько зон доступности
или кратко AZ. AWS предоставляет несколько зон доступности в каждом регионе. Зоны доступности — это отдельные местоположения, которые спроектированы таким образом, чтобы их можно было изолировать от сбоев в других зонах доступности и обеспечить недорогое сетевое подключение с низкой задержкой к другим зонам доступности в том же регионе. Дополнительно в этом FAQ ответAWS четко заявляет, что общие точки отказов, такие как генераторы, системы охлаждения, не распределяются между AZ, и каждый AZ физически отделен и независим. Это недавнее отключение произошло в основном из-за неисправности в системе распределения электроэнергии, и поскольку AZ изолированы, пострадала только одна из AZ (us-east-1c) в регионе США-Восток. Остальные АЗ работали без сбоев. Следовательно, разумно иметь инфраструктуру, распределенную по нескольким AZ. Распределите свои экземпляры EC2 по нескольким AZ и увеличьте коэффициент HA.
Примечание. Вам не нужно беспокоиться о каких-либо проблемах с производительностью, поскольку экземпляры развернуты на разных АЗ. Все AZ имеют очень низкую задержку в сети между ними и могут быть проигнорированы для веб-приложений.
Настройте ELB для использования Multi AZ
AWS Elastic Load Balancer (ELB) можно настроить для работы с несколькими AZ. Таким образом, вы можете запускать инстансы EC2 в нескольких AZ и привязывать их к одному ELB. В случае выхода из строя одного AZ, у вас по-прежнему будут работать экземпляры других AZ, и ELB переключится на них, и ваш веб-сайт продолжит работать. При создании ELB через Консоль управления AWS у вас не будет возможности указать распределение AZ. Однако, когда вы добавляете экземпляры, работающие в нескольких AZ, в ELB, ELB автоматически настраивается для работы с несколькими AZ.
Если вы используете интерфейс командной строки или
API , при создании самого ELB вы можете упомянуть AZ, которые ELB должен обрабатывать:
elb-create-lb LoadBalancerName --availability-zones value[,value...] --listener "protocol=value, lb-port=value, instance-port=value, [cert-id=value]" [ --listener "protocol=value, lb-port=value, instance-port=value, [cert-id=value]" ...] [General Options]
Кроме того, вы создаете AutoScalingGroup и упоминаете тот же список зон доступности, вы автоматизируете весь процесс отработки отказа.
as-create-auto-scaling-group AutoScalingGroupName --availability-zones value[,value...] --launch-configuration value --max-size value --min-size value [--cooldown value ] [--load-balancers value[,value...] ] [General Options]
В этом случае, когда инстансы в одном AZ вышли из строя,
- AutoScaling попытался бы запустить новые экземпляры, чтобы заменить неисправные
- API-интерфейсы AWS вызвали бы ошибки из-за недоступности AZ
- AutoScaling запустил бы новые экземпляры в другом AZ
RDS Multi AZ
Использовать функцию Multi-AZ RDS, где RDS будет запускать резервный экземпляр базы данных в другом AZ в дополнение к первичному экземпляру базы данных. В случае первичного сбоя RDS внутренне инициирует аварийное переключение в резервный режим, и база данных будет продолжать обслуживать трафик. AWS упомянула в панели мониторинга состояния RDS, что во время сбоя ни одно из их развертываний Multi-AZ не было затронуто (аварийное переключение сработало). Команда AWS должна была восстановить только Single AZ RDS.
»
Как описано в посте EC2, было затронуто несколько томов EBS в затронутой зоне доступности, что привело к отключению многих экземпляров RDS с единой зоной доступности (Single-AZ). Экземпляры Multi-AZ RDS смогли немедленно начать переключение на другие здоровые зоны доступности. Мы начали процесс восстановления для затронутых экземпляров Single-AZ RDS после того, как API EBS стали доступны примерно в 22:40 PST. После завершения проверок томов хранилища мы начали обработку томов восстановления EBS и восстановили большинство поврежденных экземпляров RDS к 5:00 утра PDT 15 июня. «
Здесь есть пара вещей, на которые стоит обратить внимание:
- В отличие от ELB, отработка отказа RDS не происходит мгновенно. Проще говоря, приложение переднего плана, которое подключается к RDS, увидит время простоя, когда произойдет аварийное переключение. Во время полного переключения RDS в режим ожидания подключение к конечной точке RDS будет недоступно. Мы видели, что на 100 ГБ данных уходит примерно 5-7 минут. Но с большим количеством данных, вероятно, это может занять немного больше времени.
- Когда дело доходит до базы данных, влияние отличается по сравнению, скажем, с веб-серверами. С базой данных можно больше беспокоиться о согласованности и долговечности данных, чем о доступности. Таким образом, когда AWS говорит выше о восстановлении Single RDS, это фактически восстановление EBS за RDS. Эти Single RDS EBS стали недоступны, и из-за сбоя питания это могло привести к повреждению записи. Поэтому клиентов попросили восстановить к ближайшему моменту моментальный снимок. С Multi-AZ такая проблема повреждения данных не возникнет, так как на другом AZ будет полная реплика, а данные записываются на оба одновременно при фиксации.
- Конечно, Multi-AZ поставляется с дополнительной оплатой. Вероятно, в два раза. Стоимость запуска одного экземпляра единого RDS на востоке США составляет около 300 долл. США в месяц. В случае установки Multi-AZ эта стоимость удвоится, и AWS будет стоить около 600 долларов в месяц. Доступность, согласованность и надежность данных в сравнении с затратами — это то, что владельцы отдельных приложений должны решить
Помимо постоянного хранилища (базы данных) приложения, рекомендуется сделать все остальные уровни инфраструктуры без сохранения состояния. В частности, веб-серверы и серверы приложений должны быть спроектированы так, чтобы они не сохраняли состояния. Большинство приложений хранят данные веб-сессии в самой памяти веб-сервера. Аналогичным образом существуют другие ресурсы, такие как загруженные пользователем файлы, файлы журналов сервера и приложения, которые обычно находятся на веб-серверах / серверах приложений. Все эти активы должны быть перемещены в центральное хранилище. Например, информация о сеансе может храниться на серверах кэширования или базах данных, а файлы могут периодически вращаться, например, в Amazon S3. После того, как мы разработаем такое приложение, можно легко вносить изменения в инфраструктуру для поддержки высокой доступности, а также для масштабирования по требованию. Распространение инфраструктуры на несколько AZ ‘Это определенно может помочь вам достичь HA. Но аварийное переключение не будет прозрачным для пользователя, если информация о сеансе хранится в памяти. Если в экземплярах в AZ1 поддерживается 100 сессий состояния сеанса пользователей, и AZ становится недоступным, то балансировщик нагрузки внешнего интерфейса немедленно переключается на экземпляры, работающие в AZ2. Но состояние сеанса пользователей будет недоступно в этих экземплярах AZ2, и, вероятно, его попросят войти снова.
С этими простыми принципами в сочетании с эффективным использованием строительных блоков AWS можно определенно создать инфраструктуру, которая будет действительно высокой доступности. Конечно, это уроки, которые можно выучить по мере того, как созревает модель облачной доставки, и, как архитекторам, нужно поддерживать и точную настройку архитектуры.