Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Есть пять регионов: очепяточка.
время простоя действительно поражает :(
время простоя действительно поражает :(
Интересно, компенсации будут? Просто интересно как это у западных компаний поставлено. Наш Clodo говорят компенсирует каждый чих.
А убытки у клиентов Amazon, думаю более чем ощутимые.
А убытки у клиентов Amazon, думаю более чем ощутимые.
Смотря, что в договоре написано, если прописаны все форс-мажоры и все нюансы, то конечно будут выплачивать простой и компенсацию прибыли.
В договоре прописано, uptime за последние 365 дней упал ниже 99,95% — пишите, ваш bill за месяц будет снижен на 10%. Думаю, я буду платить 90% еще месяца три.
Сервер лежит, я спокоен — сделать ничего не могу. Сначала он перестал отвечать, сайт выдавал ошибку подключения к БД (локальной), после перезагрузки перестало работать что-либо вообще и в логе после загрузки ошибки жесткого диска. Попробовал остановить — в состоянии остановки тот провисел часов восемь. Попробовал запустить — в этом состоянии он уже часов двадцать, я думаю.
Их инженеры не спали уже часов 40, я думаю, они воочию увидели пятилапого пса из Generation П.
Я никуда от них не уйду, дешево, удобно — разве что буду держать backup'ы snapshot'ов в другом регионе, к 15 долларам в месяц прибавится доллара два, не жалко. Да и, думаю, после такого — они из кожи вон вылезут, чтобы сохранить клиентов.
На всякий случай, еще раз: для них это катастрофа. Почитайте форум.
Сервер лежит, я спокоен — сделать ничего не могу. Сначала он перестал отвечать, сайт выдавал ошибку подключения к БД (локальной), после перезагрузки перестало работать что-либо вообще и в логе после загрузки ошибки жесткого диска. Попробовал остановить — в состоянии остановки тот провисел часов восемь. Попробовал запустить — в этом состоянии он уже часов двадцать, я думаю.
Их инженеры не спали уже часов 40, я думаю, они воочию увидели пятилапого пса из Generation П.
Я никуда от них не уйду, дешево, удобно — разве что буду держать backup'ы snapshot'ов в другом регионе, к 15 долларам в месяц прибавится доллара два, не жалко. Да и, думаю, после такого — они из кожи вон вылезут, чтобы сохранить клиентов.
На всякий случай, еще раз: для них это катастрофа. Почитайте форум.
Спасибо за разъяснение
Страшные вещи на форуме.
То, что причиной сбоя стали EBS — на самом деле забавно. Мы уже давно наблюдаем существенный спад IOPS'ов, но переезжать нам — это целая история. Вспоминаются «специалисты», которые для ускорения EBS советовали делать из 16 (!) дисков RAID0, мотивируя тем, что Amazon гарантирует их неубиваемость :)
36 часов простоя — еще один довод в выборе облачного провайдера. Год назад у гугла тоже были проблемы с доступностью, но из-за отключения электричества, правда масштаб бедствия сильно меньше. Поразила скорость реакции технического персонала. Ждем «ответа» амазона :)
amazon aws — это, да будет вам известно, мать и отец прародитель облачного хостинга. поверьте, google app engine то же страдает сбоями (как и microsoft azure), просто он не используется в таких масштабах, как amazon, поэтому его падения не вызывают таких бурных реакций.
Гугл статейку тиснул про data protection и reliability
googleenterprise.blogspot.com/2011/04/security-first-security-and-data.html
googleenterprise.blogspot.com/2011/04/security-first-security-and-data.html
Я кстати довольно быстро смог восстановиться.
Об этом не писали почему-то. Но запросы на генерацию снепшота с EBS вольюма проходили, но очень долго. У меня был затык с БД. Часов через 6 я таки смог сделать снепшот вольюма с базой и восстановить работу сервисов.
Но возможно мне просто повезло со снепшотом.
Об этом не писали почему-то. Но запросы на генерацию снепшота с EBS вольюма проходили, но очень долго. У меня был затык с БД. Часов через 6 я таки смог сделать снепшот вольюма с базой и восстановить работу сервисов.
Но возможно мне просто повезло со снепшотом.
Может из тех, кто попробовал разные облака, теперь подытожит, на чей сервис лучше смотреть-то? GAE? Rackspace? Clodo?
Практика показала, что упасть могут все. Вопрос в скорости поднятия и отношении хостера к своим клиентам (предоставлении информации об аварии, работа службы поддержки и т.д.).
зависит от круга поставленных задач.
селектел.
селектел.
Вообще если по принципу оплаты за закрепляемые ресурсы, то в этот ряд нужно добавить Slidebar, Scalaxy и Azure
Но все зависит от ваших задач, аудитории проекта, необходимости хранения и обработки персональных данных в России (эксклюзив у slidebar) и т.д.
Но все зависит от ваших задач, аудитории проекта, необходимости хранения и обработки персональных данных в России (эксклюзив у slidebar) и т.д.
В статью можно добавить неофициальный список пострадавших.
>Судя по всему, распределённая база данных Amazon RDS использует секретные API
Я бы так не сказал: status.aws.amazon.com/ И вчера и сегодня с RDS были проблемы. Возможно вы имели в виду SibmpleDB?
Кстати, кто точно может сказать какие зоны падали?
>Причиной сбоя на самом деле стали дисковые массивы EBS (Elastic Block Store)
Помнится, кто-то недавно тесты проводил. Доигрались?
Я бы так не сказал: status.aws.amazon.com/ И вчера и сегодня с RDS были проблемы. Возможно вы имели в виду SibmpleDB?
Кстати, кто точно может сказать какие зоны падали?
>Причиной сбоя на самом деле стали дисковые массивы EBS (Elastic Block Store)
Помнится, кто-то недавно тесты проводил. Доигрались?
Селектел и Скалакси — спонсоры перерывов обслуживания AWS. Их активная маркетинговая политика как минимум не опровергает этого замечания.
где-что надо почитать, чтобы
«хм… компания из Сиэттла, которая использует секретные API для получения конкурентного преимущества — звучит как-то знакомо?»
мне тоже стало занкомо?
«хм… компания из Сиэттла, которая использует секретные API для получения конкурентного преимущества — звучит как-то знакомо?»
мне тоже стало занкомо?
11:50 по МСК Только я в консоли добавил порт в Security Group и спустя 5 минут главный сервер и RDS пропали вникуда. Пол часа попыток выяснить в чём дело кроме седины ничего не дали. Повисшая Restore To Time RDS и снапшот диска наводили на мысль, что что то не так у Амазона. Но нормально работавшие m1.small вводили в заблуждение.
~12:40 по МСК — амазон обновил свой статус о том что «заметил увеличившийся error rate и latency». Поуспокоились.
У нас сотня Gb пользовательских данных на S3 и около 4 Gb база в RDS. На EBS данных не храним.
Есть ночной дамп базы на S3, но это 8 часов потери.
Ждём, ибо вера в Амазон крепка, за ~1.5 года работы с ним — была пара кратковременных «глюков», по чьей вине которые случились — так и осталось загадкой. Стоит ли торопиться, восстанавливать БД и потерять данные, если Амазон «вот-вот» должен восстановиться.
А время идёт. Foursquare поднялся. HootSuite и все остальные продолжают лежать.
~17:00 по МСК. Обдумываем переезд в Калифорнийский регион. Становится понятно, что перенос S3 и перенастройка DNS — это до завтра. Оставляем зашглушку на сайте и идём по домам жать F5 на status.aws.amazon.com
Вечером ничего не изменилось.
С утра следующего дня обнаружил сообщение амазона о том, что восстановлена работа в 3-х из 4-х регионах.
Естественно та единственная зона — us-east-1b — это наша. Попробовал restore to tim rds в другую зону — о чудо, 20 минут и инстанс восстановлен. Нужный нам инстанс в этой зоне также создался нормально. Скорей на работу — переезжать на новый сервер.
Около обеда переезд закончили, заодно обновили версию приложения (теперь со злосчастным IE9 всё в порядке и мобильная версия появилась), обновили дизайн сайта и переехали наконец на Win2008 R2.
www.teamlab.com/ru — это мы
Менять амазон на что то другое в мыслях нет.
Стабильность в течении 1,5 лет до этого и удобство пока перевешивают этот «невероятный» сбой.
Имей мы Multi-AZ размещение — поднялись бы быстрее. Так и сделаем.
Сlaim оформим само собой. Подождём, пока ребята починятся.
~12:40 по МСК — амазон обновил свой статус о том что «заметил увеличившийся error rate и latency». Поуспокоились.
У нас сотня Gb пользовательских данных на S3 и около 4 Gb база в RDS. На EBS данных не храним.
Есть ночной дамп базы на S3, но это 8 часов потери.
Ждём, ибо вера в Амазон крепка, за ~1.5 года работы с ним — была пара кратковременных «глюков», по чьей вине которые случились — так и осталось загадкой. Стоит ли торопиться, восстанавливать БД и потерять данные, если Амазон «вот-вот» должен восстановиться.
А время идёт. Foursquare поднялся. HootSuite и все остальные продолжают лежать.
~17:00 по МСК. Обдумываем переезд в Калифорнийский регион. Становится понятно, что перенос S3 и перенастройка DNS — это до завтра. Оставляем зашглушку на сайте и идём по домам жать F5 на status.aws.amazon.com
Вечером ничего не изменилось.
С утра следующего дня обнаружил сообщение амазона о том, что восстановлена работа в 3-х из 4-х регионах.
Естественно та единственная зона — us-east-1b — это наша. Попробовал restore to tim rds в другую зону — о чудо, 20 минут и инстанс восстановлен. Нужный нам инстанс в этой зоне также создался нормально. Скорей на работу — переезжать на новый сервер.
Около обеда переезд закончили, заодно обновили версию приложения (теперь со злосчастным IE9 всё в порядке и мобильная версия появилась), обновили дизайн сайта и переехали наконец на Win2008 R2.
www.teamlab.com/ru — это мы
Менять амазон на что то другое в мыслях нет.
Стабильность в течении 1,5 лет до этого и удобство пока перевешивают этот «невероятный» сбой.
Имей мы Multi-AZ размещение — поднялись бы быстрее. Так и сделаем.
Сlaim оформим само собой. Подождём, пока ребята починятся.
двое суток уже один из инстансов недоступен
Кстати, кто вменяемо объяснит преимущества облака? Судя по этой ситуации аптайм 100% не гаранирован и переезд не всегдаможно организовать по нажатию кнопки. Стоимость? Какие преимущества перед своим железом?
Стоимость. Очень тяжело нагрузить железку на 100%, чтобы использовать всё, за что заплатили. В случае же нормальных облаков вы платите только за то, что потребили (и поэтому, имхо, немного стрёмно, когда скалакси называет себя облаком при почасовой оплате инстансов).
Аптайм 100% вам не гарантирует нигде и не на каком железе никто, кроме Господа Бога, да и за него я сильно сомневаюсь.
Если бы у меня был бекап (3 клика с главной страницы и ввод имени бекапа) — я мог бы создать новую машину такой же конфигурации в любом из пяти регионов.
На все нужно смотреть сквозь призму решаемой задачи.
Мне нужен хостинг — наверное, можно было бы хостится у кого-либо от $2 в месяц, я предпочел иметь свой сервер — $15 в месяц, сейчас подумал, и купил за $82 reserved instance на три года, $2,27 в месяц, $0.007 в час (посчитал — прослезился, окупается мгновенно). А получаю, вместо хостинга, полноценную машинку с таким быстродействием, какого я ни в windows-серверах, которые администрировал, ни в своих домашних linux машинах, не видел. Например, удивляющая меня скорость доступа к дисками, даже на моей самой дешевой micro instance.
Другой практический пример — все приложения, архитектуру которых я умудрился узнать\выведать у разработчиков — хостятся в облаках, большинство тех, что видел лично я — Google App Engine. Замечательная по своему удобству штука, пиши код, и не думай о нагрузках — сколько бы не было пользователей, код будет корректно работать, только оплачивай счета.
И, да, в добавку к комментарию выше — в Амазоне я плачу за закрепленные за мной ресурсы, в GAE — только за потребляемые.
Если бы у меня был бекап (3 клика с главной страницы и ввод имени бекапа) — я мог бы создать новую машину такой же конфигурации в любом из пяти регионов.
На все нужно смотреть сквозь призму решаемой задачи.
Мне нужен хостинг — наверное, можно было бы хостится у кого-либо от $2 в месяц, я предпочел иметь свой сервер — $15 в месяц, сейчас подумал, и купил за $82 reserved instance на три года, $2,27 в месяц, $0.007 в час (посчитал — прослезился, окупается мгновенно). А получаю, вместо хостинга, полноценную машинку с таким быстродействием, какого я ни в windows-серверах, которые администрировал, ни в своих домашних linux машинах, не видел. Например, удивляющая меня скорость доступа к дисками, даже на моей самой дешевой micro instance.
Другой практический пример — все приложения, архитектуру которых я умудрился узнать\выведать у разработчиков — хостятся в облаках, большинство тех, что видел лично я — Google App Engine. Замечательная по своему удобству штука, пиши код, и не думай о нагрузках — сколько бы не было пользователей, код будет корректно работать, только оплачивай счета.
И, да, в добавку к комментарию выше — в Амазоне я плачу за закрепленные за мной ресурсы, в GAE — только за потребляемые.
А какой мощности вы получили «сервер» за 2.27 в месяц?
Думаю человек говорит о том, что заплатив 83 доллара на три года вперед он получает micro instance за 0.007$ в час.
24*0.007*30=5.04$/месяц. 2.27 правда у меня не получилось, может он выключает ее на ночь?:) Несмотря на то что он немного темнит(диски, операции io и траффик тоже платные), это все равно очень недорого.
Micro Instance — 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform
EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.
24*0.007*30=5.04$/месяц. 2.27 правда у меня не получилось, может он выключает ее на ночь?:) Несмотря на то что он немного темнит(диски, операции io и траффик тоже платные), это все равно очень недорого.
Micro Instance — 613 MB of memory, up to 2 ECUs (for short periodic bursts), EBS storage only, 32-bit or 64-bit platform
EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.
а HDD?
Там используется Elastic block store и он вроде как одинаковый для всех, независимо от тарифа(выше был коммент про то, что их можно объединять в рейды для увеличения скорости)
Micro instance. Почему-то не вставил ссылку, когда писал.
На счет цены — $82 / 3 года = $27,33 в год. $27,33 / 12 месяцев = $2,27 в месяц. Цена взята из ec2 pricing, я пересчитал — $82 / 3 года / 365 дней / 24 часа = $0,0031. Видимо, $0,007 указано для годового контракта, 54$.
На счет цены — $82 / 3 года = $27,33 в год. $27,33 / 12 месяцев = $2,27 в месяц. Цена взята из ec2 pricing, я пересчитал — $82 / 3 года / 365 дней / 24 часа = $0,0031. Видимо, $0,007 указано для годового контракта, 54$.
Ах так вы пока считатель, а не юзатель:) Тогда спешу вас разочаровать.
Reserved Instances give you the option to make a low, one-time payment for each instance you want to reserve and in turn receive a significant discount on the hourly usage charge for that instance
По-русски — 82 доллара — плата за скидочную цену 0.007$ за час(вместо 0.02 в случае micro instance).
Там же и калькулятор есть. calculator.s3.amazonaws.com/calc5.html
Reserved Instances give you the option to make a low, one-time payment for each instance you want to reserve and in turn receive a significant discount on the hourly usage charge for that instance
По-русски — 82 доллара — плата за скидочную цену 0.007$ за час(вместо 0.02 в случае micro instance).
Там же и калькулятор есть. calculator.s3.amazonaws.com/calc5.html
Вдогонку: если вам интересно, вот результат ab в 10000 запросов в 100 потоков. Загруженность процессора не поднималась выше 10%, подозреваю, время уперлось в скорость жесткого диска.
При таких настройках я могу выдержать хабраэффект, главное — грамотно пользоваться кешем (множество интересной информации по теме).
При таких настройках я могу выдержать хабраэффект, главное — грамотно пользоваться кешем (множество интересной информации по теме).
Сервер за 2.27 выдерживает хабраэффект? Напрашиваетесь на экперимент
Я напишу об этом, думаю, будет интересно. А сервер, как выяснилось выше, обходится мне в $7.44 в месяц ($89.28 в год, соответственно 208 и 2501 рубль по сегодняшнему курсу без учета трафика) при наличии резерва на три года.
Обязательно напишите!
Тщетно попытался заснуть, и вот, третий час сижу пишу. Обещаю статью в две недели, в эту либо следующую пятницу (протестировать нагрузку, да и нужно перелопатить сотни килобайт текста).
Единственное неудобство — почему-то теперь все блоги стали коллективными, и для написания в них нужно пять кармы — в итоге, я не могу даже сохранить черновик (что совсем странно), приходится писать в не очень хорошо работающем хабраредакторе и сохранять текст вручную в evernote.
Единственное неудобство — почему-то теперь все блоги стали коллективными, и для написания в них нужно пять кармы — в итоге, я не могу даже сохранить черновик (что совсем странно), приходится писать в не очень хорошо работающем хабраредакторе и сохранять текст вручную в evernote.
А по-моему ничего интересного не будет. У вас сейчас вдс с одним ядром и полугигом рам. Способна она ровно на то, на что способна вдс с одним ядром и полугигом рам. В отличие от клодо и др. она не будет scale-ится при нагрузке(амазон использует принцип запусти побольше инстансов, а не расширяй свой). Единственное чем вы сможете всех удивить это счетом за траффик:)
Что вы все называете эту маленькую вдску сервером? Ну хватит:)
облако — это такое место, которое наступает для вас, когда вы уже нифига не помещаетесь на шареде/слабеньком впс, но еще нифига не окупаете нормальный сервер + вы не знаете, как быстро будет расти клиентская база и нарузки.
с облака есть три выхода:
— на кучу своих серверов со своими матерыми админами
— на старое место
— /dev/null
с облака есть три выхода:
— на кучу своих серверов со своими матерыми админами
— на старое место
— /dev/null
какой-то желтушный заголовок и не отвечает содержимому, правильней было бы написать «что и как упали небеса». ответа на вопрос «почему» нет.
Нормальный заголовок. Там выше ссылка, что лежат, к примеру, сервера компании по мониторингу людей с сердечной недостаточностью. Для кого-то это трагедия.
Согласен, что это плохо, но причем тут мой камент?
(с технической точки зрения, подобные системы (имеющие непосредственное отношение к жизни и здоровью людей) должны проектироваться с учетом возможности отказа любой подсистемы, и уж тем более отказа удаленных систем со связью через каналы общего пользования (интернет), которые никакой надежности вообще не гарантируют. и их отказ не должен быть трагедией)
(с технической точки зрения, подобные системы (имеющие непосредственное отношение к жизни и здоровью людей) должны проектироваться с учетом возможности отказа любой подсистемы, и уж тем более отказа удаленных систем со связью через каналы общего пользования (интернет), которые никакой надежности вообще не гарантируют. и их отказ не должен быть трагедией)
Самое забавное, когда год назад были проблемы у макхоста, у hosting.ua и других — многие нахваливали Амазон в стиле «а я вот переехал в облако и не парюсь». Какая цикличная все-таки штука — история!
Один сбой произошёл у Амазона, а вы его уже загнобили. Просто загнобили до ужаса. Ваши макхосты и хостинг.уа курят в сторонке, их даже с Амазоном сравнивать смешно. Посмотрев на аптайм амазона, я думаю, они из кожи вон вылезут, лишь бы такого больше не повторилось. И я верю, что так будет.
Массивы EBS могут быть только в одной зоне доступности и доступ к ним может идти только из этой зоны. Судя по всему, распределённая база данных Amazon RDS использует секретные API, позволяющие получать доступ к EBS из других зон, но эти интерфейсы не доступны никому, кроме RDS (хм… компания из Сиэттла, которая использует секретные API для получения конкурентного преимущества — звучит как-то знакомо?)
Секретные API для Amazon RDS по использованю Amazon EBS? Вы, должно быть, шутите.
прим. пер.,
Я так понимаю, в качестве «пер.»-а выступил промпт? Или все-же гугл транслейт?
Не в обиду будет сказано, но вторую половину статьи читать просто невозможно. А жаль, тема интересная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AWS в дауне: почему небеса рухнули