Почитав в свое время «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 underlying hardware»). В обоих случаях ничего калечащего не происходило и инстанс был доступен после ребута со всеми данными на EBS. Пару раз происходило странное с IP адресом (Elastic IP) и он вдруг отвязывался от инстанса, и один раз я полностью потерял раутинг к одной из виртуальных машин. Все эти случаи были из разряда “да, это случается, но редко и не больно" и никакого особого страха/гнева у меня не вызывали. Если происходило нечто непредвиденное, то я всегда мог обратиться в их службу поддержки и получить помощь или, как минимум, внятное объяснение.
И тут случилось. 26 января один из инстансов, который должен был автоматически подняться в районе 5 часов вечера, отказался стартовать. Попытки запустить его из AWS консоли входили в состояние «initializing» и через несколько секунд возвращались в безнадежное «stopped». Никаких логов не создавалось, т.к. до загрузки OS дело видимо не доходило. При этом никаких пояснений, что именно произошло, на первый взгляд не обнаруживалось. При более пристальном осмотре мне удалось заметить подозрительное сообщение напротив списка томов — «Internal error» с кодом ошибки. Зайдя в раздел, где видны все мои EBS тома, я обнаружил оба тома от умершего инстанса в «красном состоянии» и с лаконичным сообщением «Error».
Это было странно, неприятно, но не смертельно. Ведь как истинный параноик я каждый день сохраняю снэпшоты для каждого тома от каждого инстанса и храню их от недели до 6 месяцев. Восстановить тома из снэпшотов в AWS это тривиальная задача. Однако, тут обнаружилось по настоящему странное и очень страшное — все снэпшоты этих двух разделов тоже превратились в «error» и использовать их было невозможно. Когда я говорю «все», то я имею ввиду всю историю, все 7 дней которые хранились. Не знаю, как вам, но мне было трудно поверить своим глазам. Ничего подобного я раньше не видел и ни о чем подобном никогда не слышал. По степени нереальности это даже не вызвало паники — я был уверен, что это сбой их консоли и, конечно, не может быть такого, чтоб потерялись и EBS тома и снэпшоты одновременно. Ведь теория о том, что все это хранится рядом или даже на одном дисковом массиве, который внезапно умер, полностью противоречит их описанию того, как это хозяйство работает.
Позвонив в поддержку (это отдельная и платная услуга), я попал на индийского техника. До этого все мои обращения в службу поддержки попадали на местных и очень грамотных специалистов, которые обычно радовали понятливостью. Этот тоже был понятливый, но очень медленный. После того, как я пояснил, что именно не так, он пропал минут на 15, уйдя в свои проверки. Время от времени возвращался сообщить, что он и команда специалистов исследуют проблему. Таких глубоких погружений в исследование было несколько, и я провел с ним на телефоне около часа. Конечный результат оказался неутешительным — все пропало. Я, конечно, потребовал объяснений и полного анализа причин произошедшего, но все, что он мне мог сказать — это «примите наши извинения, но ничего сделать нельзя, ваши данные пропали». На мой вопрос «как же так, я ведь все делал правильно, у меня же были снэпшоты, как это случилось?», он предложил вернуть деньги за хранение этих потерянных снэпшотов, что конечно смех сквозь слезы. Однако я продолжал требовать пояснений, и он нехотя признал, что проблема связанна со сбоем новых типов инстасов (C4) и она уже починена. Как именно связана и что именно починено, он не пояснил, но пообещал прислать еmail с полным отчетом и всеми ответами.
Из отчета, который они прислали на следующий день:
Ответом тут и не пахнет. Кроме фактической ошибки («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-х настоящих дата-центров в облако, если бы к тому моменту вся компания не была бы измучена поддержкой своего железа до крайнего состояния. За те полтора года, что я работал в этой организации, мы пережили пожар (реальный, с дымом, огнем и потерей целой стойки), атаки от других компьютеров в соседних стойках, многочисленные сбои железа, дикие проседания скорости по внешним причинам, запой сисадмина на неделю и прочие замечательные приключения. Так что даже такое серьезное происшествие не смогло поколебать нашей, а точнее моей решимости полного переезда в облака, что мы и завершили в апреле этого года.
Я, относительно долго (больше 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 underlying hardware»). В обоих случаях ничего калечащего не происходило и инстанс был доступен после ребута со всеми данными на EBS. Пару раз происходило странное с IP адресом (Elastic IP) и он вдруг отвязывался от инстанса, и один раз я полностью потерял раутинг к одной из виртуальных машин. Все эти случаи были из разряда “да, это случается, но редко и не больно" и никакого особого страха/гнева у меня не вызывали. Если происходило нечто непредвиденное, то я всегда мог обратиться в их службу поддержки и получить помощь или, как минимум, внятное объяснение.
И тут случилось. 26 января один из инстансов, который должен был автоматически подняться в районе 5 часов вечера, отказался стартовать. Попытки запустить его из AWS консоли входили в состояние «initializing» и через несколько секунд возвращались в безнадежное «stopped». Никаких логов не создавалось, т.к. до загрузки OS дело видимо не доходило. При этом никаких пояснений, что именно произошло, на первый взгляд не обнаруживалось. При более пристальном осмотре мне удалось заметить подозрительное сообщение напротив списка томов — «Internal error» с кодом ошибки. Зайдя в раздел, где видны все мои EBS тома, я обнаружил оба тома от умершего инстанса в «красном состоянии» и с лаконичным сообщением «Error».
Это было странно, неприятно, но не смертельно. Ведь как истинный параноик я каждый день сохраняю снэпшоты для каждого тома от каждого инстанса и храню их от недели до 6 месяцев. Восстановить тома из снэпшотов в AWS это тривиальная задача. Однако, тут обнаружилось по настоящему странное и очень страшное — все снэпшоты этих двух разделов тоже превратились в «error» и использовать их было невозможно. Когда я говорю «все», то я имею ввиду всю историю, все 7 дней которые хранились. Не знаю, как вам, но мне было трудно поверить своим глазам. Ничего подобного я раньше не видел и ни о чем подобном никогда не слышал. По степени нереальности это даже не вызвало паники — я был уверен, что это сбой их консоли и, конечно, не может быть такого, чтоб потерялись и EBS тома и снэпшоты одновременно. Ведь теория о том, что все это хранится рядом или даже на одном дисковом массиве, который внезапно умер, полностью противоречит их описанию того, как это хозяйство работает.
Позвонив в поддержку (это отдельная и платная услуга), я попал на индийского техника. До этого все мои обращения в службу поддержки попадали на местных и очень грамотных специалистов, которые обычно радовали понятливостью. Этот тоже был понятливый, но очень медленный. После того, как я пояснил, что именно не так, он пропал минут на 15, уйдя в свои проверки. Время от времени возвращался сообщить, что он и команда специалистов исследуют проблему. Таких глубоких погружений в исследование было несколько, и я провел с ним на телефоне около часа. Конечный результат оказался неутешительным — все пропало. Я, конечно, потребовал объяснений и полного анализа причин произошедшего, но все, что он мне мог сказать — это «примите наши извинения, но ничего сделать нельзя, ваши данные пропали». На мой вопрос «как же так, я ведь все делал правильно, у меня же были снэпшоты, как это случилось?», он предложил вернуть деньги за хранение этих потерянных снэпшотов, что конечно смех сквозь слезы. Однако я продолжал требовать пояснений, и он нехотя признал, что проблема связанна со сбоем новых типов инстасов (C4) и она уже починена. Как именно связана и что именно починено, он не пояснил, но пообещал прислать еmail с полным отчетом и всеми ответами.
Из отчета, который они прислали на следующий день:
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-х настоящих дата-центров в облако, если бы к тому моменту вся компания не была бы измучена поддержкой своего железа до крайнего состояния. За те полтора года, что я работал в этой организации, мы пережили пожар (реальный, с дымом, огнем и потерей целой стойки), атаки от других компьютеров в соседних стойках, многочисленные сбои железа, дикие проседания скорости по внешним причинам, запой сисадмина на неделю и прочие замечательные приключения. Так что даже такое серьезное происшествие не смогло поколебать нашей, а точнее моей решимости полного переезда в облака, что мы и завершили в апреле этого года.
