Amazon наконец-то опубликовала подробный отчёт о причинах сбоя в четверг 21 апреля, в результате которого одна из зон доступности на восточном побережье США почти полностью не работала в течение двух суток, а другие зоны в том же регионе глючили некоторое время.
Итак, первопричиной сбоя стала ошибка в сетевых настройках кластера Amazon Elastic Block Store (“EBS”) во время обычной работы по изменению масштабируемости. Сетевые настройки должны были увеличить ёмкость основной сети. Одним из стандартных этапов этой процедуры является снятие трафика с одного из перегруженных маршрутизаторов, чтобы сделать апгрейд. Трафик должен пойти в основную сеть. Но из-за ошибки изменение маршрутизации трафика произошло некорректно: вместо основной сети он пошёл в сеть низкой пропускной способности (в EBS используется две сети: основная для трафика и вторая для коммуникации EBS-узлов в кластере между собой и репликации).
Вторая сеть не рассчитана такие объёмы трафика, поэтому узлы EBS потеряли связь между собой. Если соседний узел не отвечает, то узел начинает искать другой для репликации. После восстановления сети это вызвало цепочку событий, включая лавину зеркального резервирования. Свободное место в кластере EBS закончилось почти мгновенно. Кроме того, из-за работы в экстремальном режиме некоторые узлы EBS начали выходить из строя, что опять же вызывало увеличение запросов.
Ещё один нюанс: поскольку в процессе зеркального резервирования инстанс временно блокируется на чтение и запись (для сохранения целостности данных), а целый кластер EBS в одной из зон оказался недоступен на чтение и запись, то в такой ситуации все инстансы EC2, которые обращались к этому хранилищу, тоже становились заблокированными.
Чтобы восстановить эти инстансы и стабилизировать кластер EBS в этой зоне, пришлось отключить все управляющие API (в том числе Create Volume, Attach Volume, Detach Volume, Create Snapshot) для EBS на протяжении почти всего срока, пока осуществлялись восстановительные работы.
В первые сутки были два периода времени, когда повреждённый кластер EBS в пострадавшей зоне негативно влиял на работу других зон в регионе восточного побережья, хотя такое не должно было случиться даже теоретически (согласно условиям предоставления сервиса Amazon, зоны доступности даже в одном регионе полностью независимы друг от друга). Но здесь случилось: из-за деградации EBS API вызовы EBS к этим API из других зон в течение двух упомянутых периодов времени работали с задержками и возвращали высокий уровень ошибок. Дело в том, что система управления EBS API во всём регионе на самом деле является единым сервисом, пусть и распределённым территориально среди всех зон доступности. Таким образом, пользователи в других зонах тоже получали сообщения об ошибках, когда пытались создать новые инстансы.
Ситуация усугубилась тем, что система Amazon Relational Database Service (RDS) тоже полагается на EBS для хранения баз данных и логов, так что после отказа одного кластера EBS часть базы данных RDS оказалась недоступна: на пике до 45% инстансов в этой зоне, выбравших “single-AZ” в настройках, то есть это имело гораздо более негативный эффект на клиентов хостинга, чем непосредственно отказ EBS (от которого на пике пострадали 18% разделов), потому что одна база RDS использует для хранения несколько узлов EBS для улучшения производительности.
Спустя 12 часов борьбы ситуацию удалось изолировать в одном кластере EBS, после чего началось скрупулёзное восстановление этого кластера, причём некоторые разделы пришлось восстанавливать вручную, а 0,07% вовсе оказались потеряны (0,4% “single-AZ” баз данных). Их можно было восстановить только из бэкапа. Хотя функционал API и доступ к кластеру был восстановлен уже 23 апреля (через двое суток после первоначального сбоя), восстановление последних разделов продолжалось до понедельника.
Amazon пообещала всем клиентам, чьи инстансы размещаются в пострадавшей зоне, независимо от того, попали они в отказавший кластер EBS или нет, 10 дней бесплатного использования объёмов EBS, инстансов EC2 и инстансов баз данных RDS в текущем объёме использования. Для получения компенсации ничего не нужно делать: он автоматически отразится в ближайшем счёте. О том, распространяется ли на вас компенсация, можно узнать на странице AWS Account Activity.
Независимые эксперты похвалили Amazon за максимальную открытость и чрезвычайно глубокое описание EBS и технической инфраструктуры EC2. Единственный недостаток в отчёте — некая недосказанность относительно первоначального сбоя, то есть какая именно была ошибка в сетевых настройках, об этом ничего не сказано. Хотя прямо не говорится, но из одной фразы в отчёте можно понять, что за ошибку нужно винить человеческий фактор: «Мы проведём аудит нашего процесса изменений [настроек] и увеличим уровень автоматизации, чтобы предотвратить подобные ошибки в будущем», — сказано в официальном заявлении.
Что касается проблем с работой EBS, то этот сбой назван «очень сложным операционным явлением, причиной которого стали несколько взаимовлияющих факторов, что даёт нам много вариантов, как защитить сервис от любого повторения подобных событий в будущем», — сказано в отчёте.
Итак, первопричиной сбоя стала ошибка в сетевых настройках кластера Amazon Elastic Block Store (“EBS”) во время обычной работы по изменению масштабируемости. Сетевые настройки должны были увеличить ёмкость основной сети. Одним из стандартных этапов этой процедуры является снятие трафика с одного из перегруженных маршрутизаторов, чтобы сделать апгрейд. Трафик должен пойти в основную сеть. Но из-за ошибки изменение маршрутизации трафика произошло некорректно: вместо основной сети он пошёл в сеть низкой пропускной способности (в EBS используется две сети: основная для трафика и вторая для коммуникации EBS-узлов в кластере между собой и репликации).
Вторая сеть не рассчитана такие объёмы трафика, поэтому узлы EBS потеряли связь между собой. Если соседний узел не отвечает, то узел начинает искать другой для репликации. После восстановления сети это вызвало цепочку событий, включая лавину зеркального резервирования. Свободное место в кластере EBS закончилось почти мгновенно. Кроме того, из-за работы в экстремальном режиме некоторые узлы EBS начали выходить из строя, что опять же вызывало увеличение запросов.
Ещё один нюанс: поскольку в процессе зеркального резервирования инстанс временно блокируется на чтение и запись (для сохранения целостности данных), а целый кластер EBS в одной из зон оказался недоступен на чтение и запись, то в такой ситуации все инстансы EC2, которые обращались к этому хранилищу, тоже становились заблокированными.
Чтобы восстановить эти инстансы и стабилизировать кластер EBS в этой зоне, пришлось отключить все управляющие API (в том числе Create Volume, Attach Volume, Detach Volume, Create Snapshot) для EBS на протяжении почти всего срока, пока осуществлялись восстановительные работы.
В первые сутки были два периода времени, когда повреждённый кластер EBS в пострадавшей зоне негативно влиял на работу других зон в регионе восточного побережья, хотя такое не должно было случиться даже теоретически (согласно условиям предоставления сервиса Amazon, зоны доступности даже в одном регионе полностью независимы друг от друга). Но здесь случилось: из-за деградации EBS API вызовы EBS к этим API из других зон в течение двух упомянутых периодов времени работали с задержками и возвращали высокий уровень ошибок. Дело в том, что система управления EBS API во всём регионе на самом деле является единым сервисом, пусть и распределённым территориально среди всех зон доступности. Таким образом, пользователи в других зонах тоже получали сообщения об ошибках, когда пытались создать новые инстансы.
Ситуация усугубилась тем, что система Amazon Relational Database Service (RDS) тоже полагается на EBS для хранения баз данных и логов, так что после отказа одного кластера EBS часть базы данных RDS оказалась недоступна: на пике до 45% инстансов в этой зоне, выбравших “single-AZ” в настройках, то есть это имело гораздо более негативный эффект на клиентов хостинга, чем непосредственно отказ EBS (от которого на пике пострадали 18% разделов), потому что одна база RDS использует для хранения несколько узлов EBS для улучшения производительности.
Спустя 12 часов борьбы ситуацию удалось изолировать в одном кластере EBS, после чего началось скрупулёзное восстановление этого кластера, причём некоторые разделы пришлось восстанавливать вручную, а 0,07% вовсе оказались потеряны (0,4% “single-AZ” баз данных). Их можно было восстановить только из бэкапа. Хотя функционал API и доступ к кластеру был восстановлен уже 23 апреля (через двое суток после первоначального сбоя), восстановление последних разделов продолжалось до понедельника.
Amazon пообещала всем клиентам, чьи инстансы размещаются в пострадавшей зоне, независимо от того, попали они в отказавший кластер EBS или нет, 10 дней бесплатного использования объёмов EBS, инстансов EC2 и инстансов баз данных RDS в текущем объёме использования. Для получения компенсации ничего не нужно делать: он автоматически отразится в ближайшем счёте. О том, распространяется ли на вас компенсация, можно узнать на странице AWS Account Activity.
Независимые эксперты похвалили Amazon за максимальную открытость и чрезвычайно глубокое описание EBS и технической инфраструктуры EC2. Единственный недостаток в отчёте — некая недосказанность относительно первоначального сбоя, то есть какая именно была ошибка в сетевых настройках, об этом ничего не сказано. Хотя прямо не говорится, но из одной фразы в отчёте можно понять, что за ошибку нужно винить человеческий фактор: «Мы проведём аудит нашего процесса изменений [настроек] и увеличим уровень автоматизации, чтобы предотвратить подобные ошибки в будущем», — сказано в официальном заявлении.
Что касается проблем с работой EBS, то этот сбой назван «очень сложным операционным явлением, причиной которого стали несколько взаимовлияющих факторов, что даёт нам много вариантов, как защитить сервис от любого повторения подобных событий в будущем», — сказано в отчёте.
