Перевод статьи Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region

В конце апреля 2011 года не работал облачный сервис Амазона в США. После того, как амазоновцы всё починили, они выпустили постмортем, в котором рассказали о том, что именно произошло, и что они будут делать, чтобы такое больше не происходило.
Вот он: Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region
Я его перевела. Они там налили немного воды, постоянно норовят одну и ту же фразу повторить в нескольких формулировках, это не трудности перевода, оно вот такое. И некоторые детали явно опущены.
Однако этот постмортем полезно почитать, оттуда можно почерпнуть информацию об инфраструктуре облачных сервисов о том, с какого рода проблемами сталкивается распределенный сервис. Да и учиться лучше на чужих ошибках.
Обратите внимание, что они анализируют произошедшее, а не пытаются назначить виноватых.

---

Анализ сбоя сервисов Amazon EC2 и Amazon RDS в восточном регионе США

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

Сбой затронул пользователей облака EC2 в одной из Зон восточного региона США, проблемы были с частью хранилищ из Amazon Elastic Block Store (“EBS”), не обслуживались операции чтения и записи. В этом документе мы будем ссылаться на эти хранилища данных как на "зависшие диски". Те, кто пытался использовать эти сломанные диски, тоже подвисал, когда пытался читать с них или писать на них. Чтобы восстановить эти диски и стабилизировать кластер EBS в этой Зоне, мы практически все время держали отключенными все управляющие API (Create Volume, Attach Volume, Detach Volume, и Create Snapshot) для EBS в пострадавшей Зоне. Дважды в течение первого дня сбоя, деградировавший EBS кластер затронул EBS API, что привело к высокому числу ошибок и задержек при вызовах этих API во всем восточном регионе США. Как и любая сложна операционная проблема, эта была вызвана несколькими причинами, влиявшими друг на друга, и таким образом у нас есть несколько направлений, по которым надо работать, чтобы защитить наш сервис от повторения подобных проблем.

Обзор системы EBS
Понимание архитектуры EBS поможет вам лучше понять то, что произошло. EBS - это распределенное реплицированное блочное хранилище данных, которое оптимизировано под консистентность и чтение и запись с низкой латентностью из экземпляров EC2. В EBS два главных компонента. (1) Набор кластеров EBS (каждый из которых находится полностью в одной Зоне), который хранит пользовательские данные и обслуживает запросы экземпляров EC2. (2) - набор сервисов панели управления, которая используется для координации запросов пользователей и распространения их на EBS кластеры, которые работают в каждой Зоне каждого Региона.

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

Когда один узел теряет соединение с другим узлом, на который он копирует данные, он думает, что тот другой узел сломан. Чтобы сохранить надежность, он должен найти новый узел, на который он может реплицировать данные (этот процесс называется "перезеркалить"). Как часть процесса перезеркаливания, узел EBS ищет в своем кластере EBS другой узел с достаточными количеством свободного места, устанавливает с ним связь и передает данные. В нормально работающем кластере процесс поиска места для новой реплики занимает миллисекунды. В процессе перезеркаливания данных все узлы, которые имеют копии данных, будут хранить их до тех пор пока они не получат подтверждение, что другой узел теперь владеет их порцией. Это предоставляет новый уровень защиты от потери данных пользователей. Также, когда данные на диске пользователя перезеркаливаются, доступ к данным блокируется до тех пор пока система не идентифицирует новую первичную (или доступную для записи) реплику. Это требуется для обеспечения консистентности данных на диске EBS в случае возникновения ошибок. Пока происходит этот процесс, с точки зрения экземпляра EC2, пытающегося делать операцию ввода-вывода на диск, диск кажется "зависшим".

В дополнение к кластеру EBS, есть набор сервисов панели управления, который принимает запросы пользователя и передает их на нужный кластер EBS. Есть один набор сервисов панели управления EBS на один EC2-регион, но сама панель управления распределена по Зонам, чтобы обеспечить доступность и устойчивость к сбоям. Эти сервисы панели управления также являются авторитетами для кластеров EBS, когда те выбирают первичную реплику для каждого диска кластера (для консистентности, у каждого диска в каждый момент времени должна быть только одна первичная реплика). В панели управления несколько сервисов, мы будем на них на все ссылаться как на "панель управления EBS".

Первый сбой
21-го апреля в 0:47 по дневному тихоокеанскому времени в одной из Зон восточного региона США была произведена смена настроек сети, это была часть обычной работы по масштабированию AWS. Целью смены настроек было увеличение пропускной способности первичной сети. Один из стандартных шагов смены настроек - убрать трафик с одного из роутеров с резервированием в первичной сети EBS, чтобы можно было апгрейдиться. Переключение трафика было произведено некорректно и вместо того, чтобы перенаправить трафик на другой роутер в первичной сети, трафик был перенаправлен в сеть EBS с меньшей пропускной способностью. Для части кластера EBS в пострадавшей Зоне это означало, что у него теперь нет ни правильно функционирующей первичной сети, ни вторичной сети, потому что трафик был специально перенаправлен из первичной сети, а вторичная сеть не могла справиться со всем тем трафиком, что в нее пришел. В результате многие узлы EBS в пострадавшей Зоне были полностью изолированы от других узлов кластера EBS. В отличие от случая нормального прерывания работы сети, это изменение отключило одновременно и первичную, и вторичную сети, затронутые узлы были полностью изолированы друг от друга.

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

После вышеописанной цепочки событий деградация кластера EBS немедленно отразилась на панели управления EBS. Когда кластер EBS входит в шторм перезеркаливания и расходует все доступное свободное место, кластер больше не может отвечать на вызов API "CreateVolume". Так как панель управления EBS (а в особенности вызов функции API CreateVolume) была сконфигурирована с большим таймаутом, эти медленные API вызовы начали накапливаться, что привело к голоданию потоков в панели управления EBS. В панели управления EBS есть региональный пул потоков, которые можно использовать для обслуживания запросов. Когда все эти потоки были переполнены большим числом накопившихся запросов, панель управления EBS не могла больше обслуживать API запросы и начала также отказывать API запросам из других Зон этого Региона. 21 апреля в 2:40 команда накатила изменение, которое отключало все новые запросы CreateVolume в пострадавшей Зоне, и к 2:50 уровень ошибок и задержек для всех вызовов API, относящихся к EBS, был восстановлен.

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

К 5:30 увеличилось количество ошибок и задержек для вызовов EBS API в Регионе. Когда данные с дисков должны быть перезеркалены, начинаются переговоры между экземплярами EC2, узлами EBS с данными и панелью управления EBS (которая выступает главной в этом процессе), так что только одна копия данных является первичной репликой и экземпляр EC2 распознает ее как место, куда надо слать все запросы на доступ. Это обеспечивает консистентность дисков EBS. По мере того, как все больше узлов EBS начали отказывать из-за состояния гонки, описанного выше, объем переговоров с панелью управления EBS увеличился. Так как данные не были успешно перезеркалены, число подобных вызовов увеличивалось по мере прихода новых запросов. Нагрузка привела к отказу панели управления EBS и это опять затронуло вызовы EBS API по всему Региону. В 8:20 команда начала отключать все соединения между деградировавшим кластером EBS в пострадавшей Зоне и панелью управления EBS. Несмотря на то, что это заблокировало все доступы EBS API в Зоне (мы обсудим восстановление в следующей секции), в целом задержки и уровень ошибок вернулись к нормальным для EBS API данного Региона.

Подавляющее большинство дисков деградировавшего кластера EBS все еще функционировали нормально и нашей целью было восстановить кластер без того, чтобы затронуть еще больше дисков. В 11:30 команда нашла как прекратить бессмысленные попытки серверов EBS из деградировавшего кластера EBS связаться друг с другом (в тот момент на них все равно не было свободного места), не затрагивания при этом другие важные коммуникации между узлами кластера. После того, как это изменение было произведено, кластер прекратил деградировать дальше и ушел риск того, что еще какие-то диски повиснут. Перед тем как это изменение было произведено, серверы, отказавшие по причине состояния гонки, добавили еще 5% к общему числу зависших дисков в Зоне. Однако, хотя и медленно, но перезеркаливание дисков продолжилось, по мере того как место понемногу освобождалось и некоторые зависшие диски отвисли. Общим результатом того изменения было то, что общее количество зависших дисков в пострадавшей Зоне стало 13%.

До полудня 21 апреля пользователи замечали возросшее число ошибок при попытках запустить новые EBS-бакеты экземпляров EC2 в других Зонах, не в той, которая пострадала. Это продолжалось в течение примерно 11 часов, от начала отказа до полудня 21 апреля. Кроме периодов проблем с API, описанных выше, пользователи могли создать EBS-бакеты экземпляров EC2, но количество ошибок и задержки было больше обычного. Новые запуски EBS-бакетов зависят от одного API в панели управления EBS, которое нужно для того, чтобы подключать новые образы дисков. Изначально наша система мониторинга недостаточно хорошо умела работать с этим вызовом API панели управления EBS и ошибки запусков были закрыты общей ошибкой деградировавшего кластера EBS. В 11:30 изменение в панели управления EBS починило это проблему и задержки и уровень ошибок для новых EBS-бакетов экземпляров EC2 быстро снизились и вернулись к почти нормальному уровню к полудню.


Восстановление EBS в затронутой Зоне
К 12:04 21 апреля сбой был изолирован в одной пострадавшей Зоне и деградировавший кластер EBS был стабилизирован. Во всех остальных зонах API работали хорошо и больше не было новых зависших дисков. Теперь нашей целью было завершить восстановление. Примерно 13% дисков в Зоне оставались зависшими и API EBS были отключены в пострадавшей Зоне. Основным приоритетом стало подключение и выведение онлайн дополнительных объемов для хранения данных, что позволило бы зависшим дискам найти достаточно места для создания новых реплик.

Перед командой стояло две проблемы, которые не давали подключить дополнительные объемы. Первая, когда узел отказывает, кластер EBS не будет использовать отказавший узел до тех пор, пока каждая реплика не перезеркалена успешно. Это было осознанное решение, оно нужно было для того, чтобы мы могли восстановить данные, если кластер перестает вести себя как спроектирован. Так как мы не хотели использовать отказавшие диски в других целях до тех пор пока мы не будем уверены, что мы сможем восстановить данные пользователей, оказавшиеся на отказавших узлах, команде пришлось установить много новых дисков, чтобы заменить те отказавшие диски. Это довольно долгий процесс, надо было физически собрать все лишние диски по всему восточному региону США и установить их на деградировавший EBS кластер. И вторая: так как были произведены изменения с целью уменьшить количество коммуникаций между узлами, используемые этими узлами для того, чтобы найти свободное место (что в итоге стабилизировало кластер, как описано выше) у команды были проблемы с добавлением новых дисков в кластер. Команде пришлось очень аккуратно вносить изменения в каналы коммуникации, чтобы новые серверы заработали, не загружая при этом старые запросами, которые те все равно не могли бы обслужить. Этот процесс занял больше времени, чем мы ожидали, так как нашей команде пришлось решить ряд проблем при работе с отключенными коммуникациями. Примерно в два часа ночи 22-го апреля команда смогла добавить значительные дисковые объемы и начала просматривать невыполненные запросы на репликацию. Диски консистентно восстановились в течение последующих девяти часов и все, кроме 2.2% дискового объема затронутой Зоны были восстановлены к 12:30 22-го апреля. Пока восстановленные диски полностью реплицировались, не все они мгновенно становились отвисшими с точки зрения прикрепленных экземпляров EC2, потому что некоторые из них были заблокированы, ожидая пока можно будет подключиться к панели управления EBS, чтобы можно было переподключиться к экземпляру EC2 и выбрать новую копию для записи.

После того, как к кластеру были добавлены достаточные объемы, команда начала работать над тем, чтобы настроить доступ API к панели управления EBS затронутой Зоны и восстановить доступ к оставшимся зависшим дискам. Там накопилось много запросов на смену состояний, которые надо было передать из деградировавших узлов EBS на панель управления EBS и наоборот. Это пришлось делать постепенно, чтобы это не отразилось на восстановленных дисках и на панели управления EBS. Сначала мы пытались включить API в пострадавшей Зоне путем передачи этих состояний таким образом, чтобы не перегрузить панель управления EBS. Мы также начали создавать отдельный экземпляр панели управления EBS, который был бы отделен от пострадавшей Зоны и чтобы тогда передача состояний не отражалась на других Зонах Региона. Мы быстро настроили каналы, но не смогли передать через них правильные запросы и стабилизировать систему. С вечера 22 апреля по утро 23-го мы работали над улучшением этих каналов. К утру субботы мы закончили нашу работу над отдельный панелью управления EBS и над каналами. Первые тесты трафика по направлению к панели управления EBS были успешными и вскоре после 11:30 23-го апреля мы начали потихоньку обрабатывать накопившиеся запросы. К 15:35 мы закончили настраивать связь между панелью управления EBS и деградировавшей Зоной. Это позволило большинству оставшихся дисков, которые все еще ждали ответа панели управления EBS, определить в какую именно реплику будет производиться запись, и прикрепленные к ним экземпляры EC2 могли опять их использовать. В 18:15 23-го апреля, API доступ к ресурсам EBS в пострадавшей Зоне был восстановлен.

С открытием API доступа к пострадавшей Зоне, API теперь работали во всех Зонах Региона. Восстановление оставшихся 2.2% пострадавших дисков потребовало больше ручной работы. В самом начале команда скопировала эти диски в бэкапы S3, это было сделано в качестве меры предосторожности, чтобы не потерять информацию. К тому моменту, команда закончила разрабатывать и тестировать код, который восстанавливал данные из этих копий и запустила процесс восстановления на ночь. в 12:30 24 апреля мы закончили работы с данными, которые мы таким образом могли восстановить и восстановили все, кроме 1.04% пострадавших дисков. В этот момент команда начала изучать оставшиеся диски, которые показывали хардварные ошибки, и с которых мы не могли снять копии. В 15:00 команда начала восстанавливать и их. В итоге, 0.07% дисков в пострадавшей Зоне не могли быть восстановлены в консистентном состоянии.


Последствия для Реляционных сервисов базы данных Amazon (RDS)
Проблемы возникли не только с экземплярами EC2, также был затронут реляционный сервис баз данных (RDS). RDS хранит в EBS базы данных и логи, и в результате часть баз данных RDS, хостящихся в пострадавшей Зоне, была недоступна.

Пользователи могут выбирать, работать ли им с экземплярами RDS в одной Зоне ("одна-AZ") или копировать на несколько Зон ("мульти-AZ"). Сбои в Зоне затрагивают экземпляры базы данных типа одна-AZ. В данном случае, экземпляр базы данных типа одна-AZ был бы поврежден, если завис хотя бы один из дисков EBS, на которые он ссылается. В первой пострадавшей зоне, в пике 45% одна-AZ экземпляров были затронуты зависшим вводом-выводом. Пострадавшая часть RDS несколько больше пострадавшей части EBS, потому что экземпляр базы данных RDS может использовать несколько дисков EBS. Это увеличивает суммарную пропускную способностью ввода-вывода базы данных в нормальных условиях, но это же и означает, что зависший ввод-вывод на одном любом диске базы данных типа одна-AZ может сделать ее нерабочей до тех пор, пока диск не восстановлен. Процент зависших баз типа одна-AZ в пострадавшей Зоне постепенно уменьшался по мере восстановления EBS. Процент зависших экземпляров базы данных типа одна-AZ в пострадавшей Зоне снизился до 41.0% через 24 часа, до 23.5% через 36 часов, до 14.6% через 48 часов. В течение выходных все восстановилось до конца. Несмотря на то, что мы восстановили практически все пострадавшие базы данных, 0.4% экземпляров баз данных типа одна-AZ в пострадавшей Зоне располагались на диске EBS, который восстановить было нельзя. Для этих баз данных пользователи, у которых автоматический бэкап был включен (а он включен по умолчанию), имели опцию начать восстановление базы данных из бэкапа.

Базы данных типа мульти-AZ более устойчивы к сбоям, поскольку синхронно копируют данные между двумя репликами базы данных в различных Зонах. В случае, если первичная реплика недоступна, RDS автоматически это определяет и переключается на вторичную реплику. 2.5% экземпляров баз данных типа мульти-AZ в восточном регионе США не смогли автоматически переключиться, после того как завис ввод-вывод. Основной причиной этого было то, что отключение сети (той, что соединяла первичную от вторичную реплики) и произошедшее сразу после этого зависание ввода-вывода на первичной реплике вызвали к жизни ранее не замеченный нами баг. Этот баг оставлял первичную реплику в изолированном состоянии, в таком случае наш мониторящий агент не мог безопасно переключиться на вторичную реплику без риска потери данных, здесь требовалось вмешательство человека. Сейчас мы активно работаем над починкой этого бага.

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

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

Эффект на несколько Зон
EC2 предоставляет два важных базовых блока доступна: Регионы и Зоны. Согласно дизайну, Регионы совершенно отдельные инсталляции нашей инфраструктуры. Регионы полностью изолированы друг от друга и предоставляют самый высокий уровень независимости. Многие пользователи используют несколько Регионов EC2, чтобы получить устойчивость к ошибкам самого высокого уровня. Однако, если вы хотите переместить данные между Регионами, вам надо делать это самостоятельно с помощью ваших приложений, так как мы не копируем данные между Регионами по запросам пользователей. Вы также должны использовать различные наборы API для управления каждым Регионом. Регионы являются важными базовыми единицами доступности для пользователей, но со стороны разработчиков приложений требуются дополнительные усилия, чтобы использовать преимущества этой изоляции. Мы предоставляем Зоны внутри Регионов, чтобы помочь разработчикам легко строить приложения, устойчивые к ошибкам. Физически и логически инфраструктуры Зон отделены друг от друга, таким образом, чтобы они были независимыми и при этом предоставляли пользователям высокоскоростную сеть с низкой латентностью, простые пути репликации данных и полный и непротиворечивый набор управляющих API. Например, с приложений, запущенных внутри Региона, пользователи могут снимать EBS снэпшоты, которые могут быть восстановлены в любой Зоне и могут программно манипулировать EC2 и EBS ресурсами используя одинаковые API. Мы предоставляем эту слабую связность, потому что она позволяет пользователям легко строить высоконадежные приложения.

Случившиеся привело к двум последствиям. Во-первых, это отразилось на приложениях, запущенных в пострадавшей Зоне, потому что пострадавшие диски EBS зависли. Архитектура сервисов EBS устроена таким образом, что влияние на запущенные образы было ограничено Зоной. В результате пользователи, которые пишут свои приложения таким образом, чтобы использовать несколько Зон, практически ничего не заметили. Некоторые пользователи сообщали, что у них зависли диски EBS в других Зонах, не в той, которая пострадала в четверг. Наша система мониторинга явно показывает эффект шторма перезеркаливания на панели управления EBS и на дисках в пострадавшей Зоне, она не показывала значительного влияния этого на диски EBS в других Зонах Региона. Хотя мы действительно видим, что в не пострадавших Зонах было чуть больше зависших дисков чем обычно, но все равно это очень малое число. Пиковое значение зависших дисков в процентах, которое мы видели в Регионе за пределами пострадавшей Зоны было менее 0.07%. Мы расследовали число это зависших дисков. Чуть большее, чем обычно, число зависших дисков в этих не пострадавших зонах было вызвано задержками в восстановлении из нормального перезеркаливания, потому что возросла латентность и возросло число ошибок в панели управления EBS, как это описано выше; всегда есть какое-то число процессов перезеркаливания в каждый момент времени. Также мы думаем, что работа, описанная ниже, направленная на то, чтобы изолировать панель управления EBS, сможет предотвратить даже такой, не намного больше, чем обычно, уровень ошибок, если случится что-нибудь подобное.


Хотя приложения пользователей, которые использовали преимущества архитектуры нескольких Зон (мульти-AZ), не пострадали от этого сбоя, проблемы с панелью управления EBS повлияли на возможность создавать диски EBS в Регионе и управлять ими. Одно из преимуществ EC2 - это возможность быстро заменять сломанные ресурсы. Когда панель управления EBS деградировала до такого состояния, что стала недоступна, пользователям с пострадавшими дисками стало сложно заменять их диски или загруженные с EBS образы в других, здоровых, Зонах. Наша главная задача - предотвратить подобное в дальнейшем.

Несмотря на то, что мы предоставляем нашим пользователям определенный уровень слабой связности, нашей целью было сделать Зоны неотличимыми от совершенно независимых. Наша панель управления EBS разработана таким образом, чтобы пользователи могли иметь доступ к ресурсам в нескольких Зонах, при этом быть устойчивыми к ошибкам в отдельных зонах. Это событие показало нам, что мы должны и в дальнейшем работать над достижением этой цели. Мы сделаем три вещи, которые предотвратят влияние отдельных Зон на панель управления EBS нескольких Зон. Первое, что мы сделаем, - мы немедленно улучшим нашу логику таймаутов, чтобы предотвратить исчерпание потоков, когда один из кластеров в Зоне слишком долго обрабатывает запросы. Это могло бы предотвратить проблемы с API c 0:50 до 2:40 21 апреля. Чтобы решить вторую проблему, возникшую с API, мы добавим к нашей панели управления EBS возможность знать больше о Зонах и разумно сбрасывать лишнюю нагрузку, когда превышена максимальная нагрузка. Подобное уже есть в нашей системе. Также мы хотим перенести кое-что из нашей панели управления EBS в наши сервисы кластеров EBS. Перенеся часть функциональности из панели управления EBS и развертывая эти сервисы на кластерах EBS (которые работают в той же Зоне, что и кластер EBS, который они поддерживают), мы сможем предоставить лучшую изоляцию Зон от панели управления EBS.


Упростить использование преимуществ нескольких Зон
Мы также намерены упростить возможность использования нескольких Зон. Во-первых, мы предложим несколько Зон для всех наших сервисов, включая виртуальное приватное облако Amazon (VPC). Сегодня пользователи VPC имеют доступ только к одной Зоне. Мы пересмотрим наших планы и дадим пользователям VPC доступ к нескольким Зонам как можно быстрее. Таким образом пользователи VPC смогут строить приложения с выским уровнем доступности используя несколько Зон, точно так же как это EC2 пользователи, не использующие VPC.

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

С тем, чтобы продолжить более тесно работать с нашими пользователями и партнерами над лучшими практиками архитектуры в облаке, мы организуем ряд вебинаров стартуя со второго мая. Первая тема, которую мы затронем, будет "дизайн приложений, устойчивых к ошибкам", "архитектура в облаке", и "лучшие практики веб-хостинга". Мы собираемся добавить больше тем в течение ближайших недель и мы продолжим делать это часто и постоянно. В течение ближайших двух недель вебинары будут проводиться по нескольку раз за день для наших пользователей, работающих в различных часовых поясах. Отдельно мы проведем значительное количество вебинаров, посвященных ответам на ваши вопросы. Также будут организованы дискуссии для наших пользователей и партнеров. Это вебинары, а также серия статей по лучшим практикам дизайна архитектуры для AWS облака, доступны на нашем AWS сайте в разделе Архитектура. Мы также продолжим предоставлять дополнительные сервисы такие как S3, SimleDB и мульти-AZ RDS, которые предоставляют автоматическую балансировку для мульти-AZ таким образом, что пользователи могут получать пользу от нескольких Зон не делая ничего особенного сложного в их приложениях.


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


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

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

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


Компенсация пострадавшим пользователям
Пользователям, у которых в пострадавшей Зоне были диски EBS или базы данных RDS, вне зависимости от того, пострадали ли их ресурсы и приложения или нет, мы предоставляем десятидневный кредит равный 100% использования их дисков EBS, образов EC2 и баз данных RDS, которые были запущены в затронутой Зjне. Эти пользователи не должны ничего делать, чтобы получить этот кредит, он будет автоматически включен в их следующий счет AWS. Пользователи могут узнать, будет ли им предоставлен этот кредит или нет, залогинившись в их аккаунт AWS.

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

Искренне ваша,
команда AWS

---

Ссылки по теме:
Amazon Elastic Compute Cloud
Retrospect on recent AWS outage and Resilient Cloud-Based Architecture
Почему в конце декабря не работал Skype
Facebook - More Details on Today's Outage - про отключение Фейсбука в сентябре 2010.