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, то цей збій названий «дуже складним операційним явищем, причиною якого стали кілька взаємовпливових факторів, що дає нам багато варіантів, як захистити сервіс від будь-якого повторення подібних подій в майбутньому», - сказано в звіті.