Облачные решения. Разгоняем туман

Главные вкладки

Аватар пользователя gor gor 27 февраля 2012 в 22:27


Облачные решения буквально витают в воздухе. Многие хостинг провайдеры бросились предлагать свои варианты. Ажиотаж вокруг словосочетания "Облачный хостинг" просто носится по форумам так или иначе связанные с хостингом.

Я соответственно тоже не мог оставить эту тему в стороне. Все таки спрос порождает предложение. И лучшие технические достижения я буду рад внедрить на патруле.

Начав копать тему по глубже, я был удивлен на сколько разошлись мои ожидания с реальностью предложения.
Но буду писать по порядку.

Начал я, как и многие, с изучения предложения от Amazon - EC2

И первое что я обнаружил это параметры instance - http://aws.amazon.com/ec2/instance-types/

И у меня возник вопрос - а в чем отличие от VDS/VPS ?

Наверно можно както увеличивать возможности ВДС на лету?
http://aws.amazon.com/autoscaling/
оказалось нет - можно автоматически запускать новые инстансы через API.

Упущу дальнейшие разборы, перейду сразу к выводу.
Amazon EC2 - это горизонтальное маштабирования. По сути вы можете подключать новые instance (читать ВДС) по мере потребности.

Беда в том, что ваш проект должен поддерживать горизонтальное масштабирование!

Дальше я стал искать другие облачные решения, отличные от EC2 Amazon.

Попал на clodo.ru
Обратите просто на две страницы внимание:
http://www.clodo.ru/virtual-server/technology/
http://www.clodo.ru/scale-server/technology/

Без коментариев.

Основное отличие конкурентов Amazon в том, что они дают вам возможность самому выбрать параметры вашего ВДС! У некоторых их можно менять на лету.

Больше технологических отличий нет.

И без лимитных ресурсов за любые деньги - тоже нет.
Вы не можете увеличить ресурсы вашего "Облака" (читать ВДС) больше чем физические параметры сервера. И учтите на этом сервере еще кто-то кроме вас есть. Значит минимум еще в 50% меньше.

Итого если у вас будет пиковая посещаемость - вы не сможете накинуть процессора, памяти, дисков и чтоб все было быстро и сейчас.
Вы должны внедрить в свой проект поддержку более чем одного инстанса (читать ВДС) и ваш проект должен уметь "распаралеливать" нагрузку.

Частично это можно решить покупкой кластерных облачных решений - стоимость которых выше на порядок.

Так же отказ самого железа не исключает проблем с вашим ВДС. У одного моего знакомого вырубился инстанс на Amazon. Его так и не врубили. Сказали - подключайте новый и восстанавливайте с бекапа. Железка сгорела. К слову он платит больше $1000 в месяц.

Выводы:
- основная разница между "облачными инстансами" и привычными уже VDS - в способе оплаты. За облака надо платить за час использования ресурсов. Вместо фиксированной цены за месяц.
- если ваш проект не поддерживает "мульти серверность" то вам не доступно горизонтальное масштабирование. Попросту говоря - ваше облако просто ВДС, который умрет от большой нагрузки и ничем не помочь. В контексте друпала - горизонтальное масштабирование очень трудно реализовать.
- надо иметь опыт администрирования ОС. Вам самостоятельно прийдется настраивать "Облако" (читать ВДС). И не факт что у вас это получится оптимально, а значит прийдется платить больше.

Рад буду услышать ваше мнение и опыт использования Облачных решений. В контексте использования Drupal на этих облачных решениях.

Комментарии

Аватар пользователя niko niko 27 февраля 2012 в 23:00

Любой софт от которого вы хотите прирост производительности от мультипроцессорности мультинодности или чем то подобным должен поддерживать паралелелизм сам. паралелить алгоритм который не подготовлен для выполнения на разных нодах/северах/VDS практически нерешаемая задача. Весь паралелизм сводится к в этом случае к спрасыванию таска/процесса на определенную ноду (ресурсы которой естественно ограничены) не более. Все остальное - кидалово от маркетологов.

Аватар пользователя GAVR100 GAVR100 27 февраля 2012 в 23:56

"gor" wrote:
- основная разница между "облачными инстансами" и привычными уже VDS - в способе оплаты. За облака надо платить за час использования ресурсов. Вместо фиксированной цены за месяц.

да, оплата за ресурсы, и устойчивость еще обещают, сервер работает всегда и данные не пропадут
облако это оплата за потребленные ресурсы, и супер надежность как обещают

и насколько я понял если ресурсов не хватает, то они автоматом увеличиваются и потом счет больше будет

если возрастает нагрузка на сайт, то постепенно увеличивается счет, сайт не падает

Аватар пользователя gor gor 28 февраля 2012 в 0:10

в том и проблема что это лишь только обещания.
с точки зрения технологи VPS= облачным инстантам , которые сейчас предлагают.
И чисто технически гарантии у них будут одинаковые.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 28 февраля 2012 в 0:05

"GAVR100" wrote:

да, оплата за ресурсы, и устойчивость еще обещают, сервер работает всегда и данные не пропадут
облако это оплата за потребленные ресурсы, и супер надежность как обещают


Сразу видно консультант по облачным технологиям, не так ли?

Аватар пользователя niko niko 28 февраля 2012 в 0:15

"GAVR100" wrote:
если возрастает нагрузка на сайт, то постепенно увеличивается счет, сайт не падает

Просветите темного, что будет если вдска съест все ресурсы самого мощного физического сервера на котором она может крутиться ?
То-есть мигрировать ее уже на более мощный физический сервер некуда.

Аватар пользователя faraon faraon 28 февраля 2012 в 0:22

На сколько для себя уяснил, облачность хороша, когда есть сайт с нестабильной нагрузкой. Сегодня 100 в сутки, завтра - 20 000. И хороша только в финансовом плане. И только тогда, когда не потеря посещаемости в пиковых ситуациях выгодней оплаты VDS/VPS.

Аватар пользователя gor gor 28 февраля 2012 в 1:11

Stalker-g2 wrote:
Странно читать такой вопиюще безграмотный пост от руководителя хостера

безграмотность техническая или орфографическая?

Аватар пользователя niko niko 28 февраля 2012 в 1:24

"GAVR100" wrote:
если есть ограничения по RAM

Ограничение на самом деле есть всегда и по любому из ресурсов, вопрос в его величине. VDS не паралелятся те кто Вам расказывает обратное менеджеры или не в теме.

Аватар пользователя Stalker-g2 Stalker-g2 28 февраля 2012 в 1:34

Конечно, техническая.

Вообще, захотелось перестать читать на

gor wrote:

Наверно можно както увеличивать возможности ВДС на лету?
http://aws.amazon.com/autoscaling/
оказалось нет - можно автоматически запускать новые инстансы через API.

Упущу дальнейшие разборы, перейду сразу к выводу.
Amazon EC2 - это горизонтальное маштабирования. По сути вы можете подключать новые instance (читать ВДС) по мере потребности.

Беда в том, что ваш проект должен поддерживать горизонтальное масштабирование!


Беды на самом деле 2:
1. Беда в том, что ваш проект тоже должен поддерживать вертикальное масштабирование, о ужас!
Если будут наращиваться различные ресурсы VDS - на это нужно реагировать множеству сервисов. MySQL - увеличивать innodb_buffer_pool_size или миллион буферов в случае с myisam(не забываем, что их надо согласовывать друг с другом), максимальный размер памяти, доступный php, лимит memcache - иначе это пшик, а не масштабирование. И это гораздо сложнее. А почему?
2. Беда в том, что по многим причинам возможно только горизонтальное машстабирование.
Как верно замечают в комментах, вырасти за предел физического сервера невозможно. Зато можно оптимизировать 2 узких места - хранилище файлов и базу данных.
Запомните, если вы рассматриваете облако без облачного хранилища файлов и облачный бд - это не облако. Но проблема не в маркетологах, а в вас - вы не понимаете, что такое облако.
Я не буду сейчас за вас гуглить и приведу пример того облака, доклад по которому я готовил - Azure.
Там к друпалу можно АВТОМАТИЧЕСКИ подключить облачное хранилище файлов blob storage и облачную базу SQL Azure(подозреваю, с амазоном тоже проблем не возникнет).
Это значит, что все ваши горизонтальные инстансы будут работать с одним файловым хранилищем и одной базой данных и о чудо! Никаких чудо-действий по горизонтальному масштабированию не нужно.

Второе главное отличие облака - возможность запустить несколько инстансов в разных географически разделенных зонах. НЕСКОЛЬКО! И в этом случае можно рассчитывать на сохранность данных и работу в случае сбоя. Хотя, я слышал, бывали проблемы. Но это все равно однозначно надежнее, чем несколько серваков говнохостера в одном дц. Вспомним украину - иногда ДЦ сгорают дотла.

Резюме.
Да, я сам не люблю маркетологов. У классического хостинга есть достоинства и недостатки. У облака есть достоинства и недостатки.
Но данный пост является банальным маркетингом классического хостинга, и написал его человек, который даже не стал разбираться с работой облачного. По сути, это было сравнение услуг просто vds и vds премиум класса, обернутых в фантик "облако". Сделан однозначный вывод, что услуги премиум класса дороже Smile
Не хотел никого задеть, но реально перебор.

Аватар пользователя niko niko 28 февраля 2012 в 1:37

Артем, можно услышать от такого крупного спеца как ты КАК же все таки работает облачный хостинг и в чем глобальное отличие от vds ? Мне лично очень интересно услышать.

Аватар пользователя Stalker-g2 Stalker-g2 28 февраля 2012 в 1:53

ну и как бы забыл пометить очевидную вещь. файлы будут уходить не напрямую с вашего сервера, а посредством CDN.

Аватар пользователя gor gor 28 февраля 2012 в 2:56

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

Значит вам есть реально что сказать по теме. И просьба поделится вашим мнением и опытом была написана в самом конце моего поста.

К сожалению , видимо изза предвзятости, вы не дочитали пост до конца и не прочитали последнее предложение.
Ничего страшного, я для вас это предложение повторю:

Рад буду услышать ваше мнение и опыт использования Облачных решений. В контексте использования Drupal на этих облачных решениях.

Теперь когда вы поняли что я не рекламирую свои услуги этим постом, а действительно пытаюсь разобраться в том что же продают под видом облачного хостинга - вы сможете отбросить всю вашу предвзятость и рассказать ваш опыт использования Azure?

Я так понял,с ваших слов, что для создания реально облачного проекта надо подключить следующий набор услуг:

- Compute (там будет IIS с нужным нам ПО вроде php)
- SQL Azure (для базы данных)
- Azure Blob Storage (работает с Azure CDN)
- траффика немножно.

Я к сожалению не имел возможности протестировать такую связку. Надеюсь у вас осталась информация после ваших тестов?
Наверняка вы меряли хотя бы через devel скорость работы такой связки.
Не подскажите где можно почитать ваши результаты?

Так же было бы интересно узнать - какую версию Drupal вы использовали для интеграции с SQL Azure? Наверно Drupal 7?

Я вот нашел документацию установки друпала на azure: http://azurephp.interoperabilitybridges.com/articles/deploying-drupal-7-...

К сожалению ее автор был не в курсе что надо использовать SQL Azure и поставил MySQL сервер на сам Compute. Этим создав себе на будушее проблемы для горизонтального масштабирования.

Видимо надо использоват модуль http://drupal.org/project/sqlsrv - он правда только для Drupal7. Но опять же ньансы инсталяции. У вас все просто получилось?

А по интеграции с Blob Storage есть модуль: http://drupal.org/project/azure. Жаль он правда еще не стабильный и только для Drupal 7.

Буду с нетерпением ждать информацию о вашем опыте работы с Azure. Особенно технические моменты связывания с SQL Azure и Blob Storage.

Аватар пользователя kyky kyky 28 февраля 2012 в 2:38

"Stalker-g2" wrote:
Но данный пост является банальным маркетингом классического хостинга, и написал его человек, который даже не стал разбираться с работой облачного.

Имхо, уважаемый Гор хотел подчеркнуть, что обычным пользователям не нужны облака. Сейчас на каждом углу кричат, что облака это круто, модно. И вот уже все говнобложики стремятся переехать на Амазон, Клодо и тд.

Если говорить в отношении it-patrol, то лучше, на мой взгляд, поддерживать и улучшать уже имеющуюся инфраструктуру, сохранять репутацию первоклассного Drupal-хостинга и не гоняться за облаками.

Важно понять, что большинство проектов — это не Гуглы/Фейсбуки, им не нужны ноды в разных географических точках. Про 2 узких места подмечено верно. Проблема решается просто: много статики -- выносим на S3 или отдаем через CloudFront, тормозит БД -- тюним сервер, оптимизируем запросы, выкидываем друпал.

Всем рекомендую http://teddziuba.com/2011/04/amazon-the-purpose-of-pain.html

Аватар пользователя gor gor 28 февраля 2012 в 3:09

В том виде как сейчас продают облака - это не товар. но я бы не хотел поднимать рекламу патруля в этом топике. Я действительно хочу разогнать туман вокруг этих облаков.
Раставить, в первую очередь для себя самого, все по местам - и назвать все вещи своими именами.

В свое время я так сделал с VDS - и в патруле нет такой услуги.

Автор достаточно эмоционален, по ссылке что вы дали.

И правильно подчеркивает ситуацию - реальный опыт важнее слов на странице услуг.
Именно реальный опыт других пользователей я бы и хотел прочитать в этом топике.

Было бы класно если Илья А. отписался. У него в свое время была тесная дружба с EC2.

Аватар пользователя Stalker-g2 Stalker-g2 28 февраля 2012 в 10:58

Не люблю писать просто так.
Я достаточно много сказал о том, в каком направлении вам надо двигаться для изучения облаков. Судя по предпоследнему комменту, вы поняли, что упустили в первоначальных рассуждениях.
По поводу Druapl 7 - ну да, именно он. Вышеописанные модули работают, нюансов нет. Если есть желание получить от нас подробности - придется пару месяцев еще подождать.

"kyky" wrote:
Имхо, уважаемый Гор хотел подчеркнуть, что обычным пользователям не нужны облака

Еще более обычным пользователям не нужно VDS
Ну а самым обычным пользователям не нужен даже хостинг! Потому что они не знают, что это такое.

Комментарий о том, что у каждой услуги есть своя аудитория - спасибо, кэп.

"gor" wrote:
Раставить, в первую очередь для себя самого, все по местам - и назвать все вещи своими именами.
В свое время я так сделал с VDS - и в патруле нет такой услуги.

А зачем? При всем уважении к патрулю, реализовать облако компании такого масштаба не могут. Даже оверсан, "заимствующий" миллионы-миллиарды денег на космос смог сделать только VDS-премиум.
Технологии, про которые я написал, могут реализовывать Гугл, Амазон, Майкрсофт.

Аватар пользователя gor gor 28 февраля 2012 в 21:44

Немного подведу итог ваших слов:
- на рынке ТРУЪ облако только у Microsoft, Amazon и Google - все остальные нагло врут и продают VPS Premium.
- c облачным решением Microsoft будет работать Drupal7 только и с дополнительными модулями. Не все из них стейбл.
- у вас или нет данных тестов Drupal7 на облаке, или вам влом делится с сообществом этой информацией.

Немного добавлю по Amazon, который похоже вы какраз и не пытались надкусить. Иначе бы знали эти ньансы.

У амазона есть предложение http://aws.amazon.com/rds/ и там не все так просто как кажется. Надо вовремя заказывать Инстансы - если не хватает производительности. А для этого ваш проект должен быть интегрирован по API.
При этом вы должны разбираться что такое Multi-AZ Deployments и Read Replicas. Это большая разница в использовании по сравнению с SQL Azure.

Вообще вот интересную статью нашел:
http://buytaert.net/drupal-in-the-cloud

Приведу короткую цитату Дриса:
... Amazon doesn't make it easier to scale Drupal. Frankly, all it does is making capacity planning a bit easier ...
... Amazon не делает проще масшатбирование Drupal. Откровенно говоря, все что он делает - это делает немного проще планирование мощности...

Так что вынужден вас разочаровать. На амазоне проблемы с базой какраз возникнут. И возникнут они потому, что надо будет запускать новые Инстансы для Базы даных. При чем запускать правильные для вашей нагрузки, и не забывать их запускать вовремя.
Тоесть надо освоить API и дописать свой код. Готового нет даже для Drupal 7.

Аватар пользователя kyky kyky 28 февраля 2012 в 12:30

"Stalker-g2" wrote:
Комментарий о том, что у каждой услуги есть своя аудитория - спасибо, кэп.

Я бы посоветовал умерить ЧСВ и писать по существу.
Если начали про Azure -- то опишите, чем он так крут, во сколько выходит по деньгам, можно ли поднять на нем, скажем, Джанго/RoR-приложение, насколько сильно платформа привязывает разработчика -- в смысле, легко ли будет с этого облака потом съехать, не потеряв данные.
Докладом прошу не кормить.

Аватар пользователя kyky kyky 29 февраля 2012 в 2:18

"gor" wrote:
Так что вынужден вас разочаровать. На амазоне проблемы с базой какраз возникнут.

Тут еще такой момент, что если на инстансе мы установим обычный MySQL-сервер, то это не будет облачная БД, и в этом плане сам EC2 не будет отличаться от VDS. У амазона есть настоящие облачные БД -- нереляционная SimpleBD и реляционная RDS, но для их использования нужно писать абстрактный слой для друпаловской БД или какой-то модуль. Год назад я искал на d.org на эту тему, но там дальше обсуждения дело не сдвинулось. Писал сам, но не осилил.
Я лично жду, когда гугловский Cloud SQL можно будет использовать из вне (не только в App Engine).

Аватар пользователя _Igor_ _Igor_ 29 февраля 2012 в 5:39

"Stalker-g2" wrote:
По поводу Druapl 7 - ну да, именно он. Вышеописанные модули работают, нюансов нет. Если есть желание получить от нас подробности - придется пару месяцев еще подождать.

То есть, по сути сказать нечего Biggrin Видимо, кроме доклада пока практического опыта нет Biggrin

Аватар пользователя gor gor 10 марта 2012 в 1:09

Появился практический опыт работы с "Облачным" решением амазона.

1. Когда делаете новый инстант, обратите внимание что за RHEL, SUSE инстанты надо платить больше.
http://aws.amazon.com/rhel/
например t1.micro обычно $0.085 вместо $0.025
На моменте выбора варианта ОС, про разницу в цене ничего не пишет.

2. Есть много публичных вариантов ОС но выбирать надо осторожно,обращайте внимание на описание.

3. Если вы сломали grub и у вас не грузится система, прийдется помучаться - никакого механизма прямого доступа к EBS или к "instance storage" нет. Надо создавать новый instance, передавать ему раздел (это возможно только с EBS) и править. Если вы "убили" систему на instance storage - можно попрощаться с данными. Вы их не вытянете.

4. У t1.micro очень интересныый режим работы. Вы не получаете гарантированный CPU. Они его лимитируют при длительной нагрузке. Подробнее можно почитать тут:
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/concepts_micro...

Если коротко, то после того как у вас пойдет пик нагрузки - вам ограничат частоту инстанса.

5. EBS не смотря на всю свою "облачность" не может быть просто увеличен ползунком.
Вам надо добавить новый EBS большого размера, отформатировать его, и перенести на него данные. Со всеми вытекающими.

6. Обращайте внимание на region в котором создаете instance - EBS можно будет перекинуть только между instance в одном регионе. Тоесть если у вас был в штатах, а диск надо перекинуть на другой в европе - копируйте по сети сами. Система этого не позволит сделать.
Она не позволит этого сделать даже в одном ДЦ но разных регионах. EBS привязан к региону.

7. Если вам надо увеличить ресурсы, перейти с t1.mini на m1.small например. Тоесть по сути увеличить память и процессор сделать гарантированным, то будьте готовы к следующему:
- потребуется остановить instance перед этим. Работы займут до 10 минут простоя.
- привязанный IP отвалится. надо переприцепить.
- hostname не подцепится сразу сам - потребуется ребут дополнительный. Не смотря на ваши настройки.

Итого подводя итог на моем личном опыте:
- ваш instance и ваши данные привязаны не только к конкретному ДЦ но и конкретному региону в ДЦ. Хотите облачность - поднимайте несколько копий в разных ДЦ и настраивайте репликацию. За вас это никто делать не будет. Кластерные instance не помогут. Читайте ограничения: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using_cluster_...

Остался вопрос еще по RDS (облачная база). Все что знаю - это они сами делают репликацию между разными инстансами. Но цены такой репликации сотни $/месяц. Расчет идет не в количестве запросов или нагрузке на базу, а в количестве установленых инстансов. При этом если вам надо многостороняя репликация - это еще дороже. читайте описание тут: http://aws.amazon.com/rds/

Аватар пользователя andypost@drupal.org andypost@drupal.org 10 марта 2012 в 4:54

cdn вроде активно перепилили, но тюнить под каждую задачу придется
а репликация баз всегда была и останется головной болью, какой-бы RDS не был обещан...

ЗЫЖ в 7ке, кстати, довольно много запросов написано с учетом slave базы, да и альтеров предостаточно, но в любом случае придется под-задачу-кодить %(

Аватар пользователя Crea Crea 10 марта 2012 в 15:26

С самого начала было ясно, что облака это типичный маркетинговый булшит. Впрочем, булшит пошел в массы и теперь все вынуждены играть в эту игру.