Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Компенсацию дали?
В каком размере относительно месячной платы?
В каком размере относительно месячной платы?
В статье написано, что просто вернули деньги за часть сервиса, которая не была предоставлена. Уверен, что эта сумма очень далека от общего пережитого шока и новых седых волос.
Видимо они знали, что седых волос у umputun не прибавилось :)
У «облаков» есть только одна проблема, которая суть продолжение их же достоинств: их офигительная гибкость и лёгкость в управлении обозначает, что достаточно потерять пару паролей — и никакое количество backup'ов не спасут. Злоумышленник сможет их все достаточно оперативно «извести». Недаром GMail вышел из беты только после того, как было налажено создание резервных копий на ленте и восстановление с них. Проблема даже не в том, что лента надёжнее жёстких дисков (это отдельный и очень сложный вопрос), проблема в том, что там вся процедура устроена так, что очень сложно потерять данные при самых чудовищных и самых непредвиденных сбоях в ПО и системах авторизации. Через физику не перепрыгнешь!
Понятно, что если у вас компания не очень большая, то такого вы себе позволить не сможете, но можно делать backup на физически отключаемые (и складываемые на полочку) винты… хотя всё от объёмов, конечно, зависит.
Понятно, что если у вас компания не очень большая, то такого вы себе позволить не сможете, но можно делать backup на физически отключаемые (и складываемые на полочку) винты… хотя всё от объёмов, конечно, зависит.
А чем отличается опасность «потерять пару паролей» в случае настоящего железа? Все точно также, только в облаках даже самым ленивым и беспечным помогают в создании системы разделения привилегий, 2х факторной авторизации и прочего для минимизации вреда.
Я бы согласился, что облако привносит новый риск взлома самого вендора хотя и в случае своего железа в DC этот риск тоже есть, но несколько в другом виде.
По поводу «никакое количество backup'ов не спасут» — опять же, это никак не про облако. Чтоб бэкапы спасли от такого, их надо делать в внешнем месте и это внешнее место конечно должно быть инициатором процесса и быть недоступно из основного.
Я бы согласился, что облако привносит новый риск взлома самого вендора хотя и в случае своего железа в DC этот риск тоже есть, но несколько в другом виде.
По поводу «никакое количество backup'ов не спасут» — опять же, это никак не про облако. Чтоб бэкапы спасли от такого, их надо делать в внешнем месте и это внешнее место конечно должно быть инициатором процесса и быть недоступно из основного.
А чем отличается опасность «потерять пару паролей» в случае настоящего железа?Там что оффллайновый backup запороть без физического доступа не удаcтся вообще, а для того, чтобы запороть backup на лентах потребуется немало времени. Остальное всё так же, конечно.
Данные на своём железе в DC могут точно также угробить, просто что-нибудь перепутав (есть личный опыт), так что «backup последнего уровня» нужно хранить у себя. Без особых вариантов.
Чтоб бэкапы спасли от такого, их надо делать в внешнем месте и это внешнее место конечно должно быть инициатором процесса и быть недоступно из основного.Я собственно об этом. Если у вас объёмы данных меряются терабайтами, то можно просто у себя «на полке» несколько винтов хранить, если петабайтами — тут вопрос другой, тут вопрос сложнее. Просто потому что такие данные регулярно «переливать» через Internet просто дорого.
Есть Amazon S3 и Amazon Glacier, но опять же хранить все в одной корзине…
А еще есть Google Cloud Storage и Nearline и (наверное) нечто подобное в azure. Я именно это и подразумевал под «внешним местом»
S3 они иногда теряют, так что лучше держать в нескольких регионах.
Ещё сейчас есть забавный вариант, когда в S3 policy указывается через сколько отправить в glacier, а потом можно при необходимости вытащить обратно в S3. Основная проблема — лимиты glacier'а к этому делу отношения не имеют и скорость восстановления не настраивается: оно идёт 3-4 часа. За 100 GiB получается $200-250.
Ещё сейчас есть забавный вариант, когда в S3 policy указывается через сколько отправить в glacier, а потом можно при необходимости вытащить обратно в S3. Основная проблема — лимиты glacier'а к этому делу отношения не имеют и скорость восстановления не настраивается: оно идёт 3-4 часа. За 100 GiB получается $200-250.
В одной книжке упоминалась забавная статистика: примерно 10% проблем с СХД — это вытаскивание не того диска человеком при замене. Кажется, статистика была от IBM, но на сайте сходу не нашлось.
Особенно ненавистны вендоры, которые не делают нормальную индикацию сбойного диска (как отсутствие индикации, так и расположение её между дисками так, что по ошибке могут вытащить соседний диск).
Особенно ненавистны вендоры, которые не делают нормальную индикацию сбойного диска (как отсутствие индикации, так и расположение её между дисками так, что по ошибке могут вытащить соседний диск).
у меня есть один небольшой проект в AWS на джанге. так вот изначально я четко разделял — s3 для файлов, rds — для база данных и ec2 — инстансы приложений, которые при любой проблеме могут быть удалены и воссозданы. Был бы проект посерьезней, то там эти инстансы еще и постоянно мониторились и этот процесс был бы автоматизирован. Под это заточена архитектура амазона, отдельные инстансы там по идее не расчитаны жить вечно.
Хотя один инстанс у меня без единого ребута прожил года два, тем не менее потом я каким-то образом потерял к нему доступ и он продолжал дальше работать, а я не имел возможности обновить приложение. Потом просто создал новый, развернул на нем все нужное окружение и так как все данные — в базе и в s3, то никаких проблем.
А насчет утери сочувствую
Хотя один инстанс у меня без единого ребута прожил года два, тем не менее потом я каким-то образом потерял к нему доступ и он продолжал дальше работать, а я не имел возможности обновить приложение. Потом просто создал новый, развернул на нем все нужное окружение и так как все данные — в базе и в s3, то никаких проблем.
А насчет утери сочувствую
Во первых EBS тома не являются частью инстанса приложений. Т.е. наличие EBS тома никак не противоречит пункту «инстансы приложений, которые при любой проблеме могут быть удалены и воссозданы», но наоборот помогает. Во вторых пропавшие снэпшоты это и есть S3.
Вся суть этого поста как раз и состоит в том, что даже при правильном отношении к инстансам как к чему-то тому, что может упасть/пропасть может случится такое, что иногда надежда на «могут быть удалены и воссозданы» не работает, т.к. поломалось и то, из чего они могут выть воссозданы.
Вся суть этого поста как раз и состоит в том, что даже при правильном отношении к инстансам как к чему-то тому, что может упасть/пропасть может случится такое, что иногда надежда на «могут быть удалены и воссозданы» не работает, т.к. поломалось и то, из чего они могут выть воссозданы.
Но ведь физически снэпшоты были на s3, так ведь? может проблема оказалась, например, в AMI, с которой были связаны снэпшоты, нет?
А вообще да, EBS это не часть инстанса. Но я в свое время с ними поковырялся — и решил нигде и никак не использовать, не помню уже чем, но они мне не понравились.
А вообще да, EBS это не часть инстанса. Но я в свое время с ними поковырялся — и решил нигде и никак не использовать, не помню уже чем, но они мне не понравились.
Физически все снэпшоты в AWS хранятся на S3, выбора хранить их на S3 или где-то еще нет. И нет, проблемы с AMI не было, с этого образа строилось много чего разного и всегда (до и после происшествия) успешно.
Что касается «нигде и никак не использовать EBS» – сейчас это практически невозможно. Большая часть новых типов инстансов EBS-only.
Что касается «нигде и никак не использовать EBS» – сейчас это практически невозможно. Большая часть новых типов инстансов EBS-only.
ну так или иначе данные проекта ведь не обязательно хранить на EBS, не правда ли?
не уверен, что понимаю вопрос. Данные где-то хранить надо, и особого выбора тут нет — либо на EBS, либо где? Понятно, что определенные данные, например архивы, можно держать в S3, но без EBS никак не получится. Я себе с трудом представляю где еще, например, монго может свои данные хранить. Речь ведь не идет об instance storage? Там слово «хранить» неприменимо.
У джанги есть такое понятие как storage. Это не обязательно тот же компьютер, на котором работает приложение с его файловой системой.
Давным давно есть такое приложение как django-storages, с помощью которого все файлы (и статику и загружаемое пользователями) хранится в s3, оттуда и раздается. У амазона есть еще CDN cloud front, который актуален при распределенной нагрузке, но нужно прописывать хуки при обновлении данных на сброс кэшей CDN.
Вы вроде тоже с Джангой имеете дело — рекомендую.
Давным давно есть такое приложение как django-storages, с помощью которого все файлы (и статику и загружаемое пользователями) хранится в s3, оттуда и раздается. У амазона есть еще CDN cloud front, который актуален при распределенной нагрузке, но нужно прописывать хуки при обновлении данных на сброс кэшей CDN.
Вы вроде тоже с Джангой имеете дело — рекомендую.
тут какая-то путаница — EBS никакого отношения к «компьютеру» не имеет. Это амазоновский способ подключать высоко-производительные блочные устройства к любым инстансам в зоне.
Никакого отношения с django у меня нет и задачи раздачи статики (как впрочем и раздачи чего угодно прочего) из S3 и/или через CDN я не решаю. S3 в качестве хранилища я, конечно, использую, но для моих систем идея использовать S3 для чего-то более другого чем относительно медленные склады объектов, не подходит совсем.
Никакого отношения с django у меня нет и задачи раздачи статики (как впрочем и раздачи чего угодно прочего) из S3 и/или через CDN я не решаю. S3 в качестве хранилища я, конечно, использую, но для моих систем идея использовать S3 для чего-то более другого чем относительно медленные склады объектов, не подходит совсем.
господи, ну «компьютер», «сервер». понятное дело, что он (EBS), не жестко привязан, но пока он привязан, то связан с конкретным инстансом (поправьте если это не так и один и тот же EBS можно привязать к разным инстансам)
S3 совсем не медленный, с него отлично раздается видео, например.
Конечно это ваше дело как использовать S3 и уж тем более не мне вам говорить о том как организовывать вашу архитектуру и решать ваши задачи.
Все что я хотел — это поделиться собственным решением с конкретным примером в котором из-за косячного бэкапа ничего не накрывается медным тазом (по крайней мере пока что).
Мне кажется беседа свелась к беспредметному разговору где один про Фому, другой про Ерёму :-)
Я уважаю ваше и своё время и предлагаю за сим закончить.
P.S. Успехов!
S3 совсем не медленный, с него отлично раздается видео, например.
Конечно это ваше дело как использовать S3 и уж тем более не мне вам говорить о том как организовывать вашу архитектуру и решать ваши задачи.
Все что я хотел — это поделиться собственным решением с конкретным примером в котором из-за косячного бэкапа ничего не накрывается медным тазом (по крайней мере пока что).
Мне кажется беседа свелась к беспредметному разговору где один про Фому, другой про Ерёму :-)
Я уважаю ваше и своё время и предлагаю за сим закончить.
P.S. Успехов!
Спасибо, это было весьма поучительно.
Не затруднит ли тебя как-нибудь при случае описать такую архитектуру, максимально приближенную к реальности? Посмаковать паранойю, так сказать :) А то whitepapers от AWS очень уж абстрактные.
По результатам происшествия я предпринял целый ряд довольно параноидальных действий, типа многократного резервирования определенных данных на другие, не амазоновские облака, пересмотрел все уникальные узлы и сделал их как минимум дублированными, сильно сдвинул всю облачную инфраструктуры в направлении disposable, т.е. все, что угодно можно убить и перестроить без ущерба для общей функциональности.
Не затруднит ли тебя как-нибудь при случае описать такую архитектуру, максимально приближенную к реальности? Посмаковать паранойю, так сказать :) А то whitepapers от AWS очень уж абстрактные.
Пора бы запомнить, что снепшоты — это не бекап, а то смеётесь над сисадминами не зная таких вещей. В блоге у Veeam отлично написали про правило «3-2-1»:
habrahabr.ru/company/veeam/blog/188544
habrahabr.ru/company/veeam/blog/188664
habrahabr.ru/company/veeam/blog/188544
habrahabr.ru/company/veeam/blog/188664
хм, амазон не солгасен:
Ну и кроме того, как это «особое знание сисадмина» относится к описанному прошествию?
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.
Ну и кроме того, как это «особое знание сисадмина» относится к описанному прошествию?
Значит в Амазоне не следовали этому правилу, раз не смогли восстановить данные с навернувшегося сториджа.
Кстати, а реплики снепшотов в других регионах тоже навернулись?
Все сломались. Как я и написал — причина (из их объяснений) была не в плохих снэпшотах, но в плохом оригинале.
так это получается у них всплыла ошибка алгоритма создания самого снэпшота, а не с хранением данных, так ведь?
Уважаемый umputun, расскажите пожалуйста подробнее о вашей архитектуре и средствах автоматизации облака.
Подскажите, а у амазона по договору предусмотрена ответственность за сохранность данных или нет? Насколько я понял, амазон палец о палец не ударил, чтобы выдать вам хоть в каком-то виде ваши данные, а только грустно пожал плечами и согласился с тем, что вам очень не повезло?
Каковы были бы ваши дальнейшие действия, если бы амазон грохнул действительно ценные данные?
Каковы были бы ваши дальнейшие действия, если бы амазон грохнул действительно ценные данные?
Не могу взять в толк: если у вас такие отношения с Амазоном, что у вас и PM есть, и к вам резво подключают людей, за что-то ответственных (пусть толком никто не может слова сказать по делу), то вроде как вас уважают как клиента.
На этом фоне 1) темнить и 2) не отдавать даже данные выглядит немного рискованно. Понятно, что один клиент им погоды не делает, сколько бы он не арендовал, но удар по престижу (пример: ваш пост на Хабре) может случиться заметный.
Компенсация — ерунда, согласен (если она не сопоставима по масштабу с упущенной выгодой), а вот заверения, что «дальше все будет ок», как-то немного голословно прозвучали, если я правильно понял.
На этом фоне 1) темнить и 2) не отдавать даже данные выглядит немного рискованно. Понятно, что один клиент им погоды не делает, сколько бы он не арендовал, но удар по престижу (пример: ваш пост на Хабре) может случиться заметный.
Компенсация — ерунда, согласен (если она не сопоставима по масштабу с упущенной выгодой), а вот заверения, что «дальше все будет ок», как-то немного голословно прозвучали, если я правильно понял.
На этом фоне 1) темнить и 2) не отдавать даже данные выглядит немного рискованно.Клиент отказался подписать NDA. Всё. Точка. Больше говорить не о чем. В компаниях размера Amazon'а и соответствующего уровня паранойи правила, описывающие что можно делать с клиентом, не подписавшим NDA — святое. Ты можешь совершать кучу косяков, нанести убытков на миллионы долларов — и тебя не уволят «сходу». Будут «разбираться», прикрепят «наставников», etc. Но если ты скажешь кому-то что-то, что тебе было говорить нельзя — окажешься за дверью в кратчайшие сроки (зависит только от законов, не все страны позволяют тебя выставить «за дверь с вещами» за пару часов).
Понятно, что один клиент им погоды не делает, сколько бы он не арендовал, но удар по престижу (пример: ваш пост на Хабре) может случиться заметный.Пост на Хабре — лишнее подтверждение правильности этих правил. По крайней мере с точки зрения тех, кто их утверждает :-)
а вот заверения, что «дальше все будет ок», как-то немного голословно прозвучали, если я правильно понял.Ну а как ещё они могли прозвучать, если клиент сам отказался узнавать о деталях?
Во первых очень рад что вы смогли восстановить продукциональный режим работы сервисов.
Во вторых это конечно смешно, что вам Amazon предложил вернуть деньги за backup-услугу (зачем тогда вообще нужны бэкапы?). Я бы на вашем месте связался с опытными юристами и потребовал бы возмещение ущерба, как минимум несколько миллионов долларов. Именно так поступила компания, где я работал, в подобной ситуации и смогли отсудить приличную сумму.
Во вторых это конечно смешно, что вам Amazon предложил вернуть деньги за backup-услугу (зачем тогда вообще нужны бэкапы?). Я бы на вашем месте связался с опытными юристами и потребовал бы возмещение ущерба, как минимум несколько миллионов долларов. Именно так поступила компания, где я работал, в подобной ситуации и смогли отсудить приличную сумму.
В какой стране это было и с какой компанией? Все подобные сервисы одним из пунктов включают отказ от гарантий, так что нужна юрисдикция где этот пункт договора будет признан ничтожным и потом ещё нужно будет доказать, что вы действительно пострадали от их действий, что в данном случае, судя по описанию, было бы сделать весьма и весьма непросто: я так понимаю что вы, в отличие от топикстартера, реально влетели в убытки, а у него всё окончилось «лёгким испугом».
Не знаю как Amazon, а Google известен тем, что в таких случаях готов идти до конца и защищаться всеми возможными способами. То есть готов вложить и десять миллионов долларов и сто в судебную тяжбу пока остаётся хоть какая-то малейшая вероятность «отбиться» — это просто вопрос выживания для них: если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют, а если будет известно что на то, чтобы выбить пару миллионов, нужно будет потратить лет пять-десять и вложить в судебные тяжбы миллионов 50-100, то… есть много гораздо более выгодных и надёжных способов заработка :-)
Не знаю как Amazon, а Google известен тем, что в таких случаях готов идти до конца и защищаться всеми возможными способами. То есть готов вложить и десять миллионов долларов и сто в судебную тяжбу пока остаётся хоть какая-то малейшая вероятность «отбиться» — это просто вопрос выживания для них: если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют, а если будет известно что на то, чтобы выбить пару миллионов, нужно будет потратить лет пять-десять и вложить в судебные тяжбы миллионов 50-100, то… есть много гораздо более выгодных и надёжных способов заработка :-)
> В какой стране это было и с какой компанией?
В Германии, судились с компанией 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…
> если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют
Да, это так. Создается претендент. Если кто то выиграет суд, то во всех аналогичных случаях компания должна будет уже без судебного разбирательства предоставить компенсацию. Поэтому в серьезных случаях компании стараются решить вопрос неофициально, но об этом не пишут в газетах.
В Германии, судились с компанией 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…
> если будет известно, что из них легко вынуть миллион, то их судебными исками просто засыплют
Да, это так. Создается претендент. Если кто то выиграет суд, то во всех аналогичных случаях компания должна будет уже без судебного разбирательства предоставить компенсацию. Поэтому в серьезных случаях компании стараются решить вопрос неофициально, но об этом не пишут в газетах.
В континентальной Европе с этим всё гораздо проблематичнее, да. Почему там никто обычно «облака» и не размещает. Странно, что IBM так глупо подставилась.
А насчёт убытков — там не всё просто: прямые убытки (затраты на сервис, которого не было предоставлено по факту) они ведь сразу обязались вернуть, а если вы хотите к ним привязать какие-то ещё другие убытки, то вам придётся доказывать, что они таки у вас есть и что вы их понесли не по собственному разгильдяйству.
А насчёт убытков — там не всё просто: прямые убытки (затраты на сервис, которого не было предоставлено по факту) они ведь сразу обязались вернуть, а если вы хотите к ним привязать какие-то ещё другие убытки, то вам придётся доказывать, что они таки у вас есть и что вы их понесли не по собственному разгильдяйству.
А нельзя ли реплицировать данные в другую зону, в которой также делать снэпшот? Или никто не гарантирует, что 2 снэпшота не окажутся сбойными?
Конечно данные можно реплицировать. Однако, в описанной катастрофе, это вероятно ничему бы не помогло т.к. была нарушена логическая целостность оригинала.
Тогда хранить «сырые» данные в S3 в разных регионах и в подобных случаях накатывать заново.
Если бы говорим «как спастись от подобной потери» то, в определенных случаях, такой S3 для сырых данных и даже для «проваренных» бэкапов это хорошо, но мало, особенно в ситуации, когда накатывать обратно данные это долго, тяжело и дорого. Например, восстановление больших данных в монгу. При таком раскладе конечно иметь s3 бэкап для исходных данных и для дампов — это правильно на крайний случай (разрушена целостность, новая версия все сломала и т.п.), но гораздо более практично иметь реплику в нескольких зонах, где у каждого нода свой EBS том.
Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
Если речь идет о ноде, который только обрабатывает данные, то даже для него не всегда возможна предложенная выше схема «берем все с S3 и туда же кладем». Для некоторых задач объектное хранилище не подходит, но может подойти dynamodb или RDS или, как в моем случае, монга.
Мотивация насчёт «измучена поддержкой своего железа» понятна, но интересно на сколько (порядок) дороже в конечном счёте обходится облако, по сравнению со своими серверами? Или для крупных клиентов амазон снижает цены в достаточной мере, чтобы было не сильно дороже своих серверов?
почему дороже? У нас, одна из целей переезда была уменьшить цену. В результате, сейчас плата за AWS несколько ниже (процентов на 20%) чем то, что мы платили за «голые» дата центры. При этом я не учитываю того, что в ДЦ надо было где-то покупать железо и сопровождать его и то, что у нас в AWS примерно в 2 раза больше мощностей. Ну и конечно, некоторые сервисы из тех, что мы сейчас активно используем, нам были просто недоступны на своем железе.
Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.
Короче говоря, трудно сравнить лоб-в-лоб, но по моим подсчетам нам жить в облаке обходится процентов на 50 дешевле.
Странно. Последний раз, когда я сравнивал цены, стоимость работы одного сервера 24x7 в облаке получалась значительно дороже стоимости аналогичного по железу dedicated. Если нагрузка неравномерная, нужные мощности в разные моменты времени сильно отличаются, и при использовании своих серверов нужно держать довольно много серверов «про запас», то облако заметно дешевле (хотя в этом случае обычно получалось ещё дешевле комбинировать какое-то количество dedicated плюс облако для пиковых нагрузок, ценой усложнения управления этим хозяйством, конечно). Но из Вашей статьи у меня сложилось впечатление что используется достаточно много серверов именно в режиме 24x7, поэтому я и ожидал, что облако обходится значительно дороже.
это, как мне кажется, не самый адекватный способ сравнения. Большое число реальных задач у меня требуют эластичной мощности и высокой доступности/надежности, и значит я могу арендовать эти мощности только тогда, когда они реально нужны. Для 24х7 есть RI, которые на 1/3 дешевле. И кроме того из за возможности гибко брать столько, сколько надо, плотность использования мощностей в AWS у меня получается значительно выше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безвозвратная потеря EC2 инстанса, EBS томов и всех снэпшотов