Я, относительно долго (больше 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-х настоящих дата-центров в облако, если бы к тому моменту вся компания не была бы измучена поддержкой своего железа до крайнего состояния. За те полтора года, что я работал в этой организации, мы пережили пожар (реальный, с дымом, огнем и потерей целой стойки), атаки от других компьютеров в соседних стойках, многочисленные сбои железа, дикие проседания скорости по внешним причинам, запой сисадмина на неделю и прочие замечательные приключения. Так что даже такое серьезное происшествие не смогло поколебать нашей, а точнее моей решимости полного переезда в облака, что мы и завершили в апреле этого года.
Комментарии (46)
khim
08.07.2015 20:52+3У «облаков» есть только одна проблема, которая суть продолжение их же достоинств: их офигительная гибкость и лёгкость в управлении обозначает, что достаточно потерять пару паролей — и никакое количество backup'ов не спасут. Злоумышленник сможет их все достаточно оперативно «извести». Недаром GMail вышел из беты только после того, как было налажено создание резервных копий на ленте и восстановление с них. Проблема даже не в том, что лента надёжнее жёстких дисков (это отдельный и очень сложный вопрос), проблема в том, что там вся процедура устроена так, что очень сложно потерять данные при самых чудовищных и самых непредвиденных сбоях в ПО и системах авторизации. Через физику не перепрыгнешь!
Понятно, что если у вас компания не очень большая, то такого вы себе позволить не сможете, но можно делать backup на физически отключаемые (и складываемые на полочку) винты… хотя всё от объёмов, конечно, зависит.
umputun Автор
08.07.2015 21:03+1А чем отличается опасность «потерять пару паролей» в случае настоящего железа? Все точно также, только в облаках даже самым ленивым и беспечным помогают в создании системы разделения привилегий, 2х факторной авторизации и прочего для минимизации вреда.
Я бы согласился, что облако привносит новый риск взлома самого вендора хотя и в случае своего железа в DC этот риск тоже есть, но несколько в другом виде.
По поводу «никакое количество backup'ов не спасут» — опять же, это никак не про облако. Чтоб бэкапы спасли от такого, их надо делать в внешнем месте и это внешнее место конечно должно быть инициатором процесса и быть недоступно из основного.khim
08.07.2015 21:12А чем отличается опасность «потерять пару паролей» в случае настоящего железа?
Там что оффллайновый backup запороть без физического доступа не удаcтся вообще, а для того, чтобы запороть backup на лентах потребуется немало времени. Остальное всё так же, конечно.
Данные на своём железе в DC могут точно также угробить, просто что-нибудь перепутав (есть личный опыт), так что «backup последнего уровня» нужно хранить у себя. Без особых вариантов.
Чтоб бэкапы спасли от такого, их надо делать в внешнем месте и это внешнее место конечно должно быть инициатором процесса и быть недоступно из основного.
Я собственно об этом. Если у вас объёмы данных меряются терабайтами, то можно просто у себя «на полке» несколько винтов хранить, если петабайтами — тут вопрос другой, тут вопрос сложнее. Просто потому что такие данные регулярно «переливать» через Internet просто дорого.
waleks
08.07.2015 21:09Есть Amazon S3 и Amazon Glacier, но опять же хранить все в одной корзине…
umputun Автор
08.07.2015 21:11+1А еще есть Google Cloud Storage и Nearline и (наверное) нечто подобное в azure. Я именно это и подразумевал под «внешним местом»
grossws
08.07.2015 21:30S3 они иногда теряют, так что лучше держать в нескольких регионах.
Ещё сейчас есть забавный вариант, когда в S3 policy указывается через сколько отправить в glacier, а потом можно при необходимости вытащить обратно в S3. Основная проблема — лимиты glacier'а к этому делу отношения не имеют и скорость восстановления не настраивается: оно идёт 3-4 часа. За 100 GiB получается $200-250.
grossws
08.07.2015 21:26+3В одной книжке упоминалась забавная статистика: примерно 10% проблем с СХД — это вытаскивание не того диска человеком при замене. Кажется, статистика была от IBM, но на сайте сходу не нашлось.
Особенно ненавистны вендоры, которые не делают нормальную индикацию сбойного диска (как отсутствие индикации, так и расположение её между дисками так, что по ошибке могут вытащить соседний диск).
vabolshakov
08.07.2015 21:51у меня есть один небольшой проект в AWS на джанге. так вот изначально я четко разделял — s3 для файлов, rds — для база данных и ec2 — инстансы приложений, которые при любой проблеме могут быть удалены и воссозданы. Был бы проект посерьезней, то там эти инстансы еще и постоянно мониторились и этот процесс был бы автоматизирован. Под это заточена архитектура амазона, отдельные инстансы там по идее не расчитаны жить вечно.
Хотя один инстанс у меня без единого ребута прожил года два, тем не менее потом я каким-то образом потерял к нему доступ и он продолжал дальше работать, а я не имел возможности обновить приложение. Потом просто создал новый, развернул на нем все нужное окружение и так как все данные — в базе и в s3, то никаких проблем.
А насчет утери сочувствуюumputun Автор
08.07.2015 22:32+5Во первых EBS тома не являются частью инстанса приложений. Т.е. наличие EBS тома никак не противоречит пункту «инстансы приложений, которые при любой проблеме могут быть удалены и воссозданы», но наоборот помогает. Во вторых пропавшие снэпшоты это и есть S3.
Вся суть этого поста как раз и состоит в том, что даже при правильном отношении к инстансам как к чему-то тому, что может упасть/пропасть может случится такое, что иногда надежда на «могут быть удалены и воссозданы» не работает, т.к. поломалось и то, из чего они могут выть воссозданы.vabolshakov
09.07.2015 02:34Но ведь физически снэпшоты были на s3, так ведь? может проблема оказалась, например, в AMI, с которой были связаны снэпшоты, нет?
А вообще да, EBS это не часть инстанса. Но я в свое время с ними поковырялся — и решил нигде и никак не использовать, не помню уже чем, но они мне не понравились.umputun Автор
09.07.2015 02:57+1Физически все снэпшоты в AWS хранятся на S3, выбора хранить их на S3 или где-то еще нет. И нет, проблемы с AMI не было, с этого образа строилось много чего разного и всегда (до и после происшествия) успешно.
Что касается «нигде и никак не использовать EBS» – сейчас это практически невозможно. Большая часть новых типов инстансов EBS-only.vabolshakov
09.07.2015 04:22ну так или иначе данные проекта ведь не обязательно хранить на EBS, не правда ли?
umputun Автор
09.07.2015 04:35+1не уверен, что понимаю вопрос. Данные где-то хранить надо, и особого выбора тут нет — либо на EBS, либо где? Понятно, что определенные данные, например архивы, можно держать в S3, но без EBS никак не получится. Я себе с трудом представляю где еще, например, монго может свои данные хранить. Речь ведь не идет об instance storage? Там слово «хранить» неприменимо.
vabolshakov
09.07.2015 04:42-2У джанги есть такое понятие как storage. Это не обязательно тот же компьютер, на котором работает приложение с его файловой системой.
Давным давно есть такое приложение как django-storages, с помощью которого все файлы (и статику и загружаемое пользователями) хранится в s3, оттуда и раздается. У амазона есть еще CDN cloud front, который актуален при распределенной нагрузке, но нужно прописывать хуки при обновлении данных на сброс кэшей CDN.
Вы вроде тоже с Джангой имеете дело — рекомендую.umputun Автор
09.07.2015 05:04+3тут какая-то путаница — EBS никакого отношения к «компьютеру» не имеет. Это амазоновский способ подключать высоко-производительные блочные устройства к любым инстансам в зоне.
Никакого отношения с django у меня нет и задачи раздачи статики (как впрочем и раздачи чего угодно прочего) из S3 и/или через CDN я не решаю. S3 в качестве хранилища я, конечно, использую, но для моих систем идея использовать S3 для чего-то более другого чем относительно медленные склады объектов, не подходит совсем.vabolshakov
09.07.2015 06:04-6господи, ну «компьютер», «сервер». понятное дело, что он (EBS), не жестко привязан, но пока он привязан, то связан с конкретным инстансом (поправьте если это не так и один и тот же EBS можно привязать к разным инстансам)
S3 совсем не медленный, с него отлично раздается видео, например.
Конечно это ваше дело как использовать S3 и уж тем более не мне вам говорить о том как организовывать вашу архитектуру и решать ваши задачи.
Все что я хотел — это поделиться собственным решением с конкретным примером в котором из-за косячного бэкапа ничего не накрывается медным тазом (по крайней мере пока что).
Мне кажется беседа свелась к беспредметному разговору где один про Фому, другой про Ерёму :-)
Я уважаю ваше и своё время и предлагаю за сим закончить.
P.S. Успехов!
glader
08.07.2015 23:12+1Спасибо, это было весьма поучительно.
По результатам происшествия я предпринял целый ряд довольно параноидальных действий, типа многократного резервирования определенных данных на другие, не амазоновские облака, пересмотрел все уникальные узлы и сделал их как минимум дублированными, сильно сдвинул всю облачную инфраструктуры в направлении disposable, т.е. все, что угодно можно убить и перестроить без ущерба для общей функциональности.
Не затруднит ли тебя как-нибудь при случае описать такую архитектуру, максимально приближенную к реальности? Посмаковать паранойю, так сказать :) А то whitepapers от AWS очень уж абстрактные.vabolshakov
09.07.2015 06:07На самом деле амазоновские рекомендации зачастую даже избыточны по отказоустойчивости в плане архитектуры. У автора, как я понял из нашего с ним треда, проблема возникла не архитектурного характера, а программного — косяк был в самом бэкапе (который все же делался амазоновскими средствами)
navion
08.07.2015 23:34Пора бы запомнить, что снепшоты — это не бекап, а то смеётесь над сисадминами не зная таких вещей. В блоге у Veeam отлично написали про правило «3-2-1»:
habrahabr.ru/company/veeam/blog/188544
habrahabr.ru/company/veeam/blog/188664umputun Автор
08.07.2015 23:41+1хм, амазон не солгасен:
You can back up the data on your EBS volumes to Amazon S3 by taking point-in-time snapshots. Snapshots are incremental backups, which means that only the blocks on the device that have changed after your most recent snapshot are saved. When you delete a snapshot, only the data exclusive to that snapshot is removed. Active snapshots contain all of the information needed to restore your data (from the time the snapshot was taken) to a new EBS volume.
Ну и кроме того, как это «особое знание сисадмина» относится к описанному прошествию?navion
09.07.2015 00:00Значит в Амазоне не следовали этому правилу, раз не смогли восстановить данные с навернувшегося сториджа.
navion
09.07.2015 00:05Кстати, а реплики снепшотов в других регионах тоже навернулись?
umputun Автор
09.07.2015 00:09+1Все сломались. Как я и написал — причина (из их объяснений) была не в плохих снэпшотах, но в плохом оригинале.
vabolshakov
09.07.2015 02:36так это получается у них всплыла ошибка алгоритма создания самого снэпшота, а не с хранением данных, так ведь?
umputun Автор
09.07.2015 03:01+1не факт. Снэпшоты это типа инкрементальных бэкапов, и видимо возможно получить поломанные снэпшоты если произошел сбой при создании первого, а они это проворонили. Вообще это чистой воды спекуляция, может быть еще дюжина теорий что именно пошло не так.
vabolshakov
09.07.2015 06:10ну лично мне очевидно по их ответу, что само создание бэкапа(ов) косячное (надеюсь, было)
ikormachev
09.07.2015 10:19Подскажите, а у амазона по договору предусмотрена ответственность за сохранность данных или нет? Насколько я понял, амазон палец о палец не ударил, чтобы выдать вам хоть в каком-то виде ваши данные, а только грустно пожал плечами и согласился с тем, что вам очень не повезло?
Каковы были бы ваши дальнейшие действия, если бы амазон грохнул действительно ценные данные?
achekalin
09.07.2015 12:59Не могу взять в толк: если у вас такие отношения с Амазоном, что у вас и PM есть, и к вам резво подключают людей, за что-то ответственных (пусть толком никто не может слова сказать по делу), то вроде как вас уважают как клиента.
На этом фоне 1) темнить и 2) не отдавать даже данные выглядит немного рискованно. Понятно, что один клиент им погоды не делает, сколько бы он не арендовал, но удар по престижу (пример: ваш пост на Хабре) может случиться заметный.
Компенсация — ерунда, согласен (если она не сопоставима по масштабу с упущенной выгодой), а вот заверения, что «дальше все будет ок», как-то немного голословно прозвучали, если я правильно понял.khim
09.07.2015 13:33+2На этом фоне 1) темнить и 2) не отдавать даже данные выглядит немного рискованно.
Клиент отказался подписать NDA. Всё. Точка. Больше говорить не о чем. В компаниях размера Amazon'а и соответствующего уровня паранойи правила, описывающие что можно делать с клиентом, не подписавшим NDA — святое. Ты можешь совершать кучу косяков, нанести убытков на миллионы долларов — и тебя не уволят «сходу». Будут «разбираться», прикрепят «наставников», etc. Но если ты скажешь кому-то что-то, что тебе было говорить нельзя — окажешься за дверью в кратчайшие сроки (зависит только от законов, не все страны позволяют тебя выставить «за дверь с вещами» за пару часов).
Понятно, что один клиент им погоды не делает, сколько бы он не арендовал, но удар по престижу (пример: ваш пост на Хабре) может случиться заметный.
Пост на Хабре — лишнее подтверждение правильности этих правил. По крайней мере с точки зрения тех, кто их утверждает :-)
а вот заверения, что «дальше все будет ок», как-то немного голословно прозвучали, если я правильно понял.
Ну а как ещё они могли прозвучать, если клиент сам отказался узнавать о деталях?
esudnik
09.07.2015 16:46Во первых очень рад что вы смогли восстановить продукциональный режим работы сервисов.
Во вторых это конечно смешно, что вам Amazon предложил вернуть деньги за backup-услугу (зачем тогда вообще нужны бэкапы?). Я бы на вашем месте связался с опытными юристами и потребовал бы возмещение ущерба, как минимум несколько миллионов долларов. Именно так поступила компания, где я работал, в подобной ситуации и смогли отсудить приличную сумму.khim
09.07.2015 17:13В какой стране это было и с какой компанией? Все подобные сервисы одним из пунктов включают отказ от гарантий, так что нужна юрисдикция где этот пункт договора будет признан ничтожным и потом ещё нужно будет доказать, что вы действительно пострадали от их действий, что в данном случае, судя по описанию, было бы сделать весьма и весьма непросто: я так понимаю что вы, в отличие от топикстартера, реально влетели в убытки, а у него всё окончилось «лёгким испугом».
Не знаю как Amazon, а Google известен тем, что в таких случаях готов идти до конца и защищаться всеми возможными способами. То есть готов вложить и десять миллионов долларов и сто в судебную тяжбу пока остаётся хоть какая-то малейшая вероятность «отбиться» — это просто вопрос выживания для них: если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют, а если будет известно что на то, чтобы выбить пару миллионов, нужно будет потратить лет пять-десять и вложить в судебные тяжбы миллионов 50-100, то… есть много гораздо более выгодных и надёжных способов заработка :-)
esudnik
09.07.2015 17:27> В какой стране это было и с какой компанией?
В Германии, судились с компанией IBM.
> и потом ещё нужно будет доказать, что вы действительно пострадали от их действий
Так это в данном случае Amazon вроде сам и подтвердил:
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…
> если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют
Да, это так. Создается претендент. Если кто то выиграет суд, то во всех аналогичных случаях компания должна будет уже без судебного разбирательства предоставить компенсацию. Поэтому в серьезных случаях компании стараются решить вопрос неофициально, но об этом не пишут в газетах.khim
09.07.2015 17:44В континентальной Европе с этим всё гораздо проблематичнее, да. Почему там никто обычно «облака» и не размещает. Странно, что IBM так глупо подставилась.
А насчёт убытков — там не всё просто: прямые убытки (затраты на сервис, которого не было предоставлено по факту) они ведь сразу обязались вернуть, а если вы хотите к ним привязать какие-то ещё другие убытки, то вам придётся доказывать, что они таки у вас есть и что вы их понесли не по собственному разгильдяйству.
dpatriot
13.07.2015 17:57А нельзя ли реплицировать данные в другую зону, в которой также делать снэпшот? Или никто не гарантирует, что 2 снэпшота не окажутся сбойными?
umputun Автор
13.07.2015 19:02Конечно данные можно реплицировать. Однако, в описанной катастрофе, это вероятно ничему бы не помогло т.к. была нарушена логическая целостность оригинала.
dpatriot
13.07.2015 21:00Тогда хранить «сырые» данные в S3 в разных регионах и в подобных случаях накатывать заново.
umputun Автор
13.07.2015 21:41Если бы говорим «как спастись от подобной потери» то, в определенных случаях, такой S3 для сырых данных и даже для «проваренных» бэкапов это хорошо, но мало, особенно в ситуации, когда накатывать обратно данные это долго, тяжело и дорого. Например, восстановление больших данных в монгу. При таком раскладе конечно иметь s3 бэкап для исходных данных и для дампов — это правильно на крайний случай (разрушена целостность, новая версия все сломала и т.п.), но гораздо более практично иметь реплику в нескольких зонах, где у каждого нода свой EBS том.
Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
powerman
14.07.2015 11:52Мотивация насчёт «измучена поддержкой своего железа» понятна, но интересно на сколько (порядок) дороже в конечном счёте обходится облако, по сравнению со своими серверами? Или для крупных клиентов амазон снижает цены в достаточной мере, чтобы было не сильно дороже своих серверов?
umputun Автор
14.07.2015 18:57почему дороже? У нас, одна из целей переезда была уменьшить цену. В результате, сейчас плата за AWS несколько ниже (процентов на 20%) чем то, что мы платили за «голые» дата центры. При этом я не учитываю того, что в ДЦ надо было где-то покупать железо и сопровождать его и то, что у нас в AWS примерно в 2 раза больше мощностей. Ну и конечно, некоторые сервисы из тех, что мы сейчас активно используем, нам были просто недоступны на своем железе.
Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.powerman
14.07.2015 19:10Странно. Последний раз, когда я сравнивал цены, стоимость работы одного сервера 24x7 в облаке получалась значительно дороже стоимости аналогичного по железу dedicated. Если нагрузка неравномерная, нужные мощности в разные моменты времени сильно отличаются, и при использовании своих серверов нужно держать довольно много серверов «про запас», то облако заметно дешевле (хотя в этом случае обычно получалось ещё дешевле комбинировать какое-то количество dedicated плюс облако для пиковых нагрузок, ценой усложнения управления этим хозяйством, конечно). Но из Вашей статьи у меня сложилось впечатление что используется достаточно много серверов именно в режиме 24x7, поэтому я и ожидал, что облако обходится значительно дороже.
umputun Автор
14.07.2015 19:21это, как мне кажется, не самый адекватный способ сравнения. Большое число реальных задач у меня требуют эластичной мощности и высокой доступности/надежности, и значит я могу арендовать эти мощности только тогда, когда они реально нужны. Для 24х7 есть RI, которые на 1/3 дешевле. И кроме того из за возможности гибко брать столько, сколько надо, плотность использования мощностей в AWS у меня получается значительно выше.
veam
Компенсацию дали?
В каком размере относительно месячной платы?
nochkin
В статье написано, что просто вернули деньги за часть сервиса, которая не была предоставлена. Уверен, что эта сумма очень далека от общего пережитого шока и новых седых волос.
vbabaev
Видимо они знали, что седых волос у umputun не прибавилось :)
grossws
Потому, что уже все волосы вырваны/выпали?