Pull to refresh

Comments 25

Вот что меня удивляет — почему если кто-то неизвестный, кто еще не успел поучаствовать в ИТ-пузомерках, выложит подобные бенчи, то над ним посмеются

А если это выложил Дейв Винер — все, истина в последней инстанции.

Ни слова про то, какого рода у него нагрузка, какое используется ПО, ни слова обо всех этих немаловажных факторах.

ЗЫ: то, что RackSpace дешевле амазона — известный факт, и связано это не с косяками тех, кто настраивает сервера амазона, а с из высокой нагруженностью.

Ну я то же наблюдал подобные результаты, а все потому, что у амазона caped инстанцы и вы не получите больше, чем заплатили, а у rackspace cap'а по сути нет, и там если повезет получите burst. По мне на rackspace больше нравится, но сродни русской рулетке, а на amazon'е более надежно с точки зрения ресурсов, но и стоимость существенно выше.
>Дэйв Винер

Кто такой?

Вообще не секрет, что Ракспэйс мощнее Амазона, это можно и прямо по тарифам понять. Опять же, если нам нужна просто облачная VPS'ка, то rackspace гораздо лучше. Но у амазона есть множество других сервисов, + API. AWS ≠ EC2. У ракспейса же просто виртуалки да файловый стораж.
У Амазона самый дешевый инстанс под винду это микро, а не мини. И выйдет он что-то порядка 22х долларов в месяц.
UFO just landed and posted this here
Микро дают бесплатно на амазоне.
Дешевле некуда.
Только не с виндой (а у автора именно она на серваках)
На год и только для новых пользователей :(
Ага, но только если не зарегистрировался за неделю до акции. ☹
прекрасная статья, апофеоз маркетинга облакостроения.

правильный перевод таков:
мы видим что облако быстрее чем облако в несколько раз
мы не можем определить почему оно быстрее и в каких величинах, поэтому мы будем использовать величину «Работа»
обычные тесты не показывают разницы, но вот мы нашли какие-то графики, которые подтверждают нашу теорию.
итак, оно быстрее и дешевле на этом облаке, чем на другом облаке
Добро пожаловать в новый мир, мир облаков, *aaS и меряний «работами».
Кто хотел shared hosting с виртуалками? :)
Имхо, даже школьник сделает более адекватные тесты.
У нас преподаватели на экзаменах, за слова: «больше»,«меньше»....«активней» отдали зачетку обратно без оценки!
Предлагаю сходить к гадалке пусть тоже проведет тест облачных провайдеров на картах!
Расскажу я вам ребята, наш опыт работы с Rackspace.
Мы Highload сервер рекламы с множеством подсистем аналитики и статистики, ранее обитали на Mosso Rackspace.
Бесспорно Rackspace быстрее и предоставляет больше возможностей, но есть несколько НО!!! И эти НО перегибают все на свете.
– Сервера регулярно падают (раз в неделю, раз в месяц)

– История. Январь 2010. Сидим себе спокойно, живем, все мирно тихо. Ба-бах!!! Все упало и не поднимается. Звоним в Mosso, говорят что ищут проблему. Через 5 часов включили, а ночью опять все рухнуло. Звоним, спихивают все на нас и говорят что это мы перегружаем. Пришлось доказать, что это все таки они шалят. Поднялись. Через день звонит Mosso и говорит что «У нас технические неполадки, и мы вас отключаем на неопределенный срок дабы снизить нагрузку на нашу систему» (и видимо не только нас, они долго извинялись в twitter). Оказалось Rackspace у себя химичил с каким-то железом и все падало благодаря этому.
Итого: переехали в EC2 за выходные (!!!), т.к. такая политика сервиса губительна для любого бизнеса. Они потом звонили и долго извинялись. В последующие 3 месяца на e-mail несколько раз в неделю приходили письма о падениях и плановых работах с отключением сервиса, но мы уже были на Amazon EC2 и смотрели на весь этот цирк с радостной улыбкой. К тому же, благодаря Rightscale мы стали платить в 2 раза меньше!!!

Если сранивать по производительности, то Rackspace быстрее, и CDN у него тоже быстрее. Лирическое отступление: я думаю это связано с топологией сети и шумными соседями Amazona. С другой стороны Amazon намного круче в стабильности, к тому же есть такие классные штучки как Rightscale, Elastic MapReduce (Hadoop), EBS.

Мы до сих пор поглядываем за развитием Mosso Cloud Computing, но плохой опыт работы с ними и бессонные ночи пока что увы не забыты.

Далее судите сами…

А расскажите заодно уж и про Rightscale в таком же стиле, спасибо пожалуйста.
Rightscale это отдельня от Amazon'а система автоскейлинга. только что посмотрел, они и Rackspace тоже поддерживают. Позволяет автоматически поднимать и опускать сервера, в зависимости от нагрузки. Тобиш, вы экономите деньги на малой нагрузке. Но, оно подойдет не всем. Например, если у вас апликейшн-сервера независимы друг от друга и являются просто единицой мощности, то это ваш выбор. Если же вы строите социальную сеть с шардированием данных по серверам, то вам это не поможет никак. Все дело в выборе архитектуры.
Любой может построить такую же систему на nginx+wsgi+app-server
Rightscale – это готовое решение с красивыми меню и заготовками образов и т.д. И не дорогое.

Как появится время, я чуть больше расскажу.
Amazon падает не хуже. У нас регулярно «залипали» EBS, что невозможно их было удалить. Инстансы так подвисали, что нельзя было их не только перегрузить, но и отмонтировать EBS — только новый инстанс поднимать, а если это сервер БД с единственными актуальными данными — это есть проблема.

Но самая большая проблема у амазона — это IO. Производительность ввода-вывода не то что не гарантирована, она просто кошмарная. Можен неделю работать нормально, потом ни с того ни с сего сразу падает в разы. По графикам munin, сразу видно как сваливается пропускная способность и сделать что-то с этим тяжело. Иногда помогало создание нового EBS volume или сервера, но это головная боль. Не пробовал правда их готовое решение для БД RDS.

С Амазон нужно строить все так, чтобы не бояться потерять инстанс в любой момент времени и навсегда. Если сохранность данных на EBS еще более менее гарантируется, то данные хранимые в разделе самого инстанса гарантировано не сохраняются при падении инстанса.

На Rackspace правда тоже один раз сервер так глюкнул, что больше 8 часов данные были недоступны. Суппорт объяснил тем, что сразу 2 хранилища в рейде загнулись! Не очень себе этого представляю, но факт даунтайма на лицо, благо что это было в не самое активное время и на небольшом проекте. Но производительность IO на rackspace намного лучше. Последнее время он довольно стабильно работает для меня.

Минусом Rackspace есть то, что он негибкий по сравнению с Амазоном. Он больше похож на класический dedicated, но только очень отзывчивый: хочешь сервер сейчас — вот тебе!
У EBS есть очередь на запись данных, т.е. если у вас запись больше чем пропускная способность, то после отключения записи данные еще какое-то время будут приходить из backlog'a. Естественно он не очень предназначем для DB. Вы и сами ответили на свой вопрос, о том что надо использовать RDS.

По поводу того чтобы не боятся потерять инстанс. Разве не в этом заключается «thinking cloud» и cloud computing??? Если вы чрезмеру нагрузили инстанс или EBS, то он со временем отвалится, перезагрузится, сломается. Ну да, всегда надо быть готовым, что он умрет и не вернется никогда… Это как данность при работе с любым Cloud.

В Rackspace меня напрягали детские оправдания «сразу 2 хранилища в рейде загнулись!». Звучит как «у нас щенок глупенький Duddley съел будильник». Бред! Если и правда рухнули, то архитектура у них лажевая и падения повторятся.
Детские или нет… но факт остается фактом:

«Hello Andrly,

I do apologize for any issues you have been experiencing on your Cloud Server host. At 12:05 PM CST we had a audible RAID alert on your server host. In most cases we resolve this issue fast. In this case two drives failed at the same time the audible RAID alert came through. In this case our engineers are working this issue and will update you as soon as the problem is resolved. Your issue is a Cloud Server host failure. We have 1 hour to resolve the issue at which point we start the timer for SLA requests. The issue started at 12:05 PM CST at 1:05 PM CST we start the clock for 5% of your Cloud Server fee for the host for each additional hour of downtime up to 100% of your fees.

… и так далее…
А вот насчет RDS можно подробнее… Очень интересно.

Пока не вижу подверждения на амазоне, что IO на RDS инстансах чем-то отличается от IO на обычных инстансах. Вы из своего опыта?
Выйгрыш в производительности небольшой, а головомороки много. За инстанс+RAID0 EBS надо упорно следить. RDS легко управляется, реплицируется и снепшотится. К тому же есть transaction logs, если обвалилось, можно повторить. Стабильность важна не меньше производительности. Все равно вы упретесь в порог и будете придумывать извращенные способы кеширования, так что I/O на DB не самое главное. Если же делать простой сайт или магазин, то тут все отталкивается от цены за сервис.
Знаем мы этот Burst. Это пока всем просто везло что в час-пик ресурсов хватало.
Под давлением акционеров оверсел будет все больше, пока оно не начнет дичайше тормозить в часы-пик…
Sign up to leave a comment.

Articles