Почитавши свого часу «Cloudmouse видалив всі віртуальні сервери» і деякі коментарі в стилі «сам винен, треба було довіряти перевіреним хмарам», вирішив повідати свою історію жаху з вельми шанованою хмарою від Амазона (AWS). У подкасті радіо-т я коротко про це розповідав, але тут, як мені здається, важливі деталі і враження від всього події кошмару.
Я, відносно довго (більше 3х років) використовую AWS для робочих і особистих проектів і вважаю себе досить просунутим користувачем. З багатого списку сервісів AWS мені довелося попрацювати, або як мінімум випробувати більшу частину всього цього достатку, але кілька базових сервісів безсумнівно використовується найчастіше. Це EC2 (інстанси/віртуальні машини) в VPC (приватні мережі), пов'язані з ними EBS (томи), ELB (балансувальник навантаження) плюс Route53 (DNS). З цієї п'ятірки можна зібрати різні конфігурації віртуальних машин, об'єднаних в мережі, а якщо до цієї справи додати S3 для зберігання даних, то мабуть це і буде малий джентльменський набір найбільш популярних AWS сервісів.
Надійність цих систем різна, і на них даються різні SLA, в основному дуже вражаючі. З точки зору практичного використання, ніяких критичних проблем з AWS у мене не виникало. Це не означає, що там все абсолютно безперебійно, але при правильно організованій системі, де розумний користувач не складає всі яйця в один кошик і, як мінімум, розподіляє сервіси між AZ (зонами доступності) з усіх рідкісних падінь і проблем вдавалося вийти без особливих втрат і з мінімальним головним болем.
З того, з чим я стикався при реальному використанні, найчастіше зустрічалася ситуація із запланованим хлопцем («your Amazon EC2 instances are scheduled to be rebooted for required host maintenance») і з запланованою міграцією на нове обладнання («EC2 has detected degradation of the underlyware». В обох випадках нічого калічачого не відбувалося і інстанс був доступний після ребута з усіма даними на EBS. Пару разів відбувалося дивне з IP адресою (Elastic IP) і він раптом відв'язувався від інстансу, і один раз я повністю втратив раутинг до однієї з віртуальних машин. Всі ці випадки були з розряду "так, це трапляється, але рідко і не боляче" "і ніякого особливого страху/гніву у мене не викликали. Якщо відбувалося щось непередбачене, то я завжди міг звернутися в їх службу підтримки і отримати допомогу або, як мінімум, виразне пояснення.
І тут сталося. 26 січня один з інстансів, який мав автоматично піднятися в районі 5 години вечора, відмовився стартувати. Спроби запустити його з AWS консолі входили в стан «initializing» і через кілька секунд поверталися в безнадійне «stopped». Ніяких логів не створювалося, тому що до завантаження OS справа мабуть не доходила. При цьому жодних пояснень, що саме сталося, на перший погляд не виявлялося. При більш пильному огляді мені вдалося помітити підозріле повідомлення навпроти списку томів - «Internal error» з кодом помилки. Зайшовши в розділ, де видно всі мої EBS томи, я виявив обидва томи від померлого інстансу в «червоному стані» і з лаконічним повідомленням «Error».
Це було дивно, неприємно, але не смертельно. Адже як справжній параноїк я кожен день зберігаю снепшоти для кожного тому від кожного інстансу і зберігаю їх від тижня до 6 місяців. Відновити томи зі снепшотів в AWS це тривіальне завдання. Однак, тут виявилося по справжньому дивне і дуже страшне - всі снепшоти цих двох розділів теж перетворилися на «error» і використовувати їх було неможливо. Коли я кажу «все», то я маю на увазі всю історію, всі 7 днів які зберігалися. Не знаю, як вам, але мені було важко повірити своїм очам. Нічого подібного я раніше не бачив і ні про що подібне ніколи не чув. За ступенем нереальності це навіть не викликало паніки - я був упевнений, що це збій їх консолі і, звичайно, не може бути такого, щоб загубилися і EBS томи і снепшоти одночасно. Адже теорія про те, що все це зберігається поруч або навіть на одному дисковому масиві, який раптово помер, повністю суперечить їх опису того, як це господарство працює.
Зателефонувавши на підтримку (це окрема і платна послуга), я потрапив на індійського техніка. До цього всі мої звернення в службу підтримки потрапляли на місцевих і дуже грамотних фахівців, які зазвичай радували зрозумілістю. Цей теж був зрозумілий, але дуже повільний. Після того, як я пояснив, що саме не так, він пропав хвилин на 15, пішовши у свої перевірки. Час від часу повертався повідомити, що він і команда фахівців досліджують проблему. Таких глибоких занурень у дослідження було кілька, і я провів з ним на телефоні близько години. Кінцевий результат виявився невтішним - все пропало. Я, звичайно, зажадав пояснень і повного аналізу причин події, але все, що він мені міг сказати - це «прийміть наші вибачення, але нічого зробити не можна, ваші дані пропали». На моє запитання «як же так, я ж все робив правильно, у мене ж були снепшоти, як це сталося?», він запропонував повернути гроші за зберігання цих втрачених снепшотів, що звичайно сміх крізь сльози. Однак я продовжував вимагати пояснень, і він нехотя визнав, що проблема пов'язана зі збоєм нових типів інстасів (C4) і вона вже полагоджена. Як саме пов'язана і що саме полагоджено, він не пояснив, але пообіцяв надіслати email з повним звітом і всіма відповідями.
Зі звіту, який вони надіслали наступного дня:
During a recent integrity check we discovered unrecoverable corruption in 1
of your volumes. We have changed the state of the volume to “error.” In
addition, snapshots made from these volume are also unrecoverable, so we have
changed their status from “Completed” to “Error.” You will no longer be charged
for these volumes and snapshots and may delete them at your convenience.
Please note that you will no longer be able to launch instances using AMIs
referencing these snapshots. Instructions for removing AMIs is available here
(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html).
Although EBS volumes are designed for reliability, including being backed by
multiple physical drives, we are still exposed to durability risks when
multiple component failures occur. We publish our durability expectations on
the EBS detail page here (http://aws.amazon.com/ebs/details).
We apologize for the inconvenience this may have caused you. If you have any
further questions or comments regarding this matter, please contact us at:
aws.amazon.com/support.
Відповіддю тут і не пахне. Крім фактичної помилки («in 1 of your volumes» коли їх було 2) і стандартної відписки тут нічого корисного немає. Однак, з подібною відповіддю я мириться не міг і задіяв нашого PM з AWS (таких Амазон прикріплює до більш-менш вагомих замовників), розповівши йому про катастрофу, що сталася. Дзвонив я вже глибокої ночі і залишив повідомлення. При цьому слів особливо не вибирав і не приховував ступеня свого шоку і гранично ясно дав зрозуміти, що саме я про це думаю. Через 30 хвилин він мені передзвонив і запропонував з ранку організувати розмову між мною і всіма тими з AWS у кого є відповіді.
До речі, при всій суворості збою, ніяких болючих наслідків для наших бойових систем він не викликав. По-перше, цей нід не був єдиним, а по-друге він був повністю докерезованим і майже повністю immutable. Відновити, а по суті, побудувати новий, була справа 10 хвилин - ansible накотив все, що треба для запуску контейнерів і управління ними, а потім доставив і запустив всі потрібні контейнери. Оскільки цей інстанс є частиною системи обробки даних кінця дня, ніяких унікальних даних на ньому не було, і все, що потрібно для роботи він забирав із зовнішніх місць. Однак, якщо подібне станеться з інстансом на якому дійсно важливі і унікальні дані, а незалежний бекап ще не побудований, то тоді це може бути дуже великою проблемою.
На телефонну нараду з боку Амазона прибула значна команда. Крім PM і прикріпленого до нас solution architect там було кілька фахівців з групи, що займається EBS, пара інженерів зі служби підтримай (як мені здалося, той з ким я говорив і його начальник) і якась людина, яку представили тільки на ім'я. Розмова тривала близько години і проходила в заданому мною напрямку. Мене цікавили відповіді на 3 питання - що саме сталося, що вони роблять для того, щоб це не повторилося і що я можу зробити, щоб запобіжити свої системи від подібного в майбутньому. Ще я намагався для себе зрозуміти, чи поділяє амазон моє відчуття жаху від такої події.
Так, безсумнівно, вони чітко розуміли, що це щось надзвичайне. Заклопотаність і вкрай серйозне ставлення до події звучало в кожному слові, і вони не раз сказали прямим текстом, що це дійсно критична проблема і що такого ніяк не повинно було статися. З частини розбору події я зрозумів наступне - ця катастрофа сталася не 26го, але тиждень тому, при початковому створенні інстансу. І протягом усього тижня тому був частково зруйнований або, як мінімум, в ньому виявилося щось таке, після виявлення чого вони вирішили зробити його недоступним. Всі мої спроби прояснити що ж саме там було поламано до особливого успіху не призвели - все, що вони могли сказати, це те, що була зруйнована цілісність на логічному рівні і подібну проблему полагодити було неможливо. Тут став зрозумілий і зв'язок з загубленими снепшотами - всі вони були зняті з проблемних томів і тому були позначені як збійні.
Таким чином, виходить, що я протягом тижня використовував віртуальну машину з томами, з якими з самого початку було щось не так. І тиждень їх системи не виявляли ніяких проблем, як, втім, і я не спостерігав нічого дивного. Звичайно, а поставив резонне запитання - чому їхні системи виявлення цілий тиждень цього не помічали і що такого сталося, що вони її помітили? Ну і на додаток - якщо я жив на такому несправному сервісі цілий тиждень, навіщо така різкість і поспіх зараз? Чому б їм не попередити заздалегідь і не дати мені час вжити заходів до того, як дані і віртуальні машини будуть видалені?
Відповідь на питання про виявлення була дана в тому ключі, що саме це і було коренем всіх проблем, а зовсім не проблема з типом C4, як мені сказав інженер першої лінії підтримки. Треба сказати, що це твердження звучало дещо невпевнено, можливо щось там таке і було зав'язане на C4, але вони не зізналися. При цьому всі палко запевняли, що ці нові C4 цілком надійні, і я можу їх сміливо використовувати. Забігаючи вперед, скажу, що за минулі півроку я їх використовував багаторазово, вельми активно, в багатьох завданнях з великими вимогами до CPU і ці типи інстансів більше ніяких дивних проблем не викликали.
А ось відповіді на питання «до чого був весь цей поспіх» я не отримав взагалі. На мою думку, їм це було заборонено обговорювати із замовником через причини, про які я можу тільки гадати. У порядку чистої конспірології можу припустити якийсь витік чужих даних на мої томи, і тоді вся ця різка історія може бути хоч якось обґрунтована.
У вигляді відповіді на питання «що вони роблять для того, щоб це не повторилося» вони запевнили, що роблять все можливе, проте подробиць не дали, посилаючись на те, що я відмовився підписати угоду про нерозголошення, а більш докладні відповіді в такому випадку неможливі. Це, до речі, був не перший раз, коли вони пропонували підписати NDA, але я весь час відмовлявся через безглуздість саме тієї форми NDA, яку вони пропонували і за якою (якщо слідувати його букві буквально) я б не міг навіть залишити критичний відгук на сайті амазону, де продають книги і всяку всячину. Що стосується останнього розділу («що я можу зробити, щоб запобіжити свої системи»). Тут вони говорили багато, охоче і, в основному, банально. По суті нічого, я тут зробити не можу, але повинен завжди бути готовий до гіршого, що я розумів і без цієї команди фахівців.
Підводячи підсумок, в тій частині, де прийнято викладати щось повчальне, нагадаю ще раз - все на світі коли-небудь ламається і навіть кращі з хмарних провайдерів можуть підвести. І до цього треба бути готовим кожен день. У моєму випадку врятувала комбінація часткової готовності і везіння, але з цієї події я виніс кілька уроків, прокручуючи в голові «а як би я вижив, якби зламалася інша частина системи і в декількох місцях одночасно». За результатами події я зробив цілий ряд досить параноїдальних дій, типу багаторазового резервування певних даних на інші, не амазонівські хмари, переглянув всі унікальні вузли і зробив їх як мінімум дубльованими, сильно зрушив всю хмарну інфраструктуру в напрямку disposable, тобто все, що завгодно можна вбити і перебудувати без шкоди для загальної функціональності.
Ця подія могла б стати найсерйознішим ударом з моєї ініціативи переїзду з 3-х справжніх дата-центрів в хмару, якби до того моменту вся компанія не була б змучена підтримкою свого заліза до крайнього стану. За ті півтора року, що я працював у цій організації, ми пережили пожежу (реальний, з димом, вогнем і втратою цілої стійки), атаки від інших комп'ютерів у сусідніх стійках, численні збої заліза, дикі просідання швидкості із зовнішніх причин, запій сисадміна на тиждень та інші чудові пригоди. Тож навіть така серйозна подія не змогла похитнути нашої, а точніше моєї рішучості повного переїзду в хмари, що ми і завершили в квітні цього року.
