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 на этих облачных решениях.
Комментарии
Любой софт от которого вы хотите прирост производительности от мультипроцессорности мультинодности или чем то подобным должен поддерживать паралелелизм сам. паралелить алгоритм который не подготовлен для выполнения на разных нодах/северах/VDS практически нерешаемая задача. Весь паралелизм сводится к в этом случае к спрасыванию таска/процесса на определенную ноду (ресурсы которой естественно ограничены) не более. Все остальное - кидалово от маркетологов.
да, оплата за ресурсы, и устойчивость еще обещают, сервер работает всегда и данные не пропадут
облако это оплата за потребленные ресурсы, и супер надежность как обещают
и насколько я понял если ресурсов не хватает, то они автоматом увеличиваются и потом счет больше будет
если возрастает нагрузка на сайт, то постепенно увеличивается счет, сайт не падает
в том и проблема что это лишь только обещания.
с точки зрения технологи VPS= облачным инстантам , которые сейчас предлагают.
И чисто технически гарантии у них будут одинаковые.
Сразу видно консультант по облачным технологиям, не так ли?
Просветите темного, что будет если вдска съест все ресурсы самого мощного физического сервера на котором она может крутиться ?
То-есть мигрировать ее уже на более мощный физический сервер некуда.
На сколько для себя уяснил, облачность хороша, когда есть сайт с нестабильной нагрузкой. Сегодня 100 в сутки, завтра - 20 000. И хороша только в финансовом плане. И только тогда, когда не потеря посещаемости в пиковых ситуациях выгодней оплаты VDS/VPS.
Странно читать такой вопиюще безграмотный пост от руководителя хостера
безграмотность техническая или орфографическая?
Ограничение на самом деле есть всегда и по любому из ресурсов, вопрос в его величине. VDS не паралелятся те кто Вам расказывает обратное менеджеры или не в теме.
Конечно, техническая.
Вообще, захотелось перестать читать на
Беды на самом деле 2:
1. Беда в том, что ваш проект тоже должен поддерживать вертикальное масштабирование, о ужас!
Если будут наращиваться различные ресурсы VDS - на это нужно реагировать множеству сервисов. MySQL - увеличивать innodb_buffer_pool_size или миллион буферов в случае с myisam(не забываем, что их надо согласовывать друг с другом), максимальный размер памяти, доступный php, лимит memcache - иначе это пшик, а не масштабирование. И это гораздо сложнее. А почему?
2. Беда в том, что по многим причинам возможно только горизонтальное машстабирование.
Как верно замечают в комментах, вырасти за предел физического сервера невозможно. Зато можно оптимизировать 2 узких места - хранилище файлов и базу данных.
Запомните, если вы рассматриваете облако без облачного хранилища файлов и облачный бд - это не облако. Но проблема не в маркетологах, а в вас - вы не понимаете, что такое облако.
Я не буду сейчас за вас гуглить и приведу пример того облака, доклад по которому я готовил - Azure.
Там к друпалу можно АВТОМАТИЧЕСКИ подключить облачное хранилище файлов blob storage и облачную базу SQL Azure(подозреваю, с амазоном тоже проблем не возникнет).
Это значит, что все ваши горизонтальные инстансы будут работать с одним файловым хранилищем и одной базой данных и о чудо! Никаких чудо-действий по горизонтальному масштабированию не нужно.
Второе главное отличие облака - возможность запустить несколько инстансов в разных географически разделенных зонах. НЕСКОЛЬКО! И в этом случае можно рассчитывать на сохранность данных и работу в случае сбоя. Хотя, я слышал, бывали проблемы. Но это все равно однозначно надежнее, чем несколько серваков говнохостера в одном дц. Вспомним украину - иногда ДЦ сгорают дотла.
Резюме.
Да, я сам не люблю маркетологов. У классического хостинга есть достоинства и недостатки. У облака есть достоинства и недостатки.
Но данный пост является банальным маркетингом классического хостинга, и написал его человек, который даже не стал разбираться с работой облачного. По сути, это было сравнение услуг просто vds и vds премиум класса, обернутых в фантик "облако". Сделан однозначный вывод, что услуги премиум класса дороже
Не хотел никого задеть, но реально перебор.
Артем, можно услышать от такого крупного спеца как ты КАК же все таки работает облачный хостинг и в чем глобальное отличие от vds ? Мне лично очень интересно услышать.
ну и как бы забыл пометить очевидную вещь. файлы будут уходить не напрямую с вашего сервера, а посредством CDN.
Артем, я рад слышать что у вас есть реальный опыт использования облачных решений и что вы даже делитесь им с сообществом посредством Докладов.
Значит вам есть реально что сказать по теме. И просьба поделится вашим мнением и опытом была написана в самом конце моего поста.
К сожалению , видимо изза предвзятости, вы не дочитали пост до конца и не прочитали последнее предложение.
Ничего страшного, я для вас это предложение повторю:
Рад буду услышать ваше мнение и опыт использования Облачных решений. В контексте использования 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.
Имхо, уважаемый Гор хотел подчеркнуть, что обычным пользователям не нужны облака. Сейчас на каждом углу кричат, что облака это круто, модно. И вот уже все говнобложики стремятся переехать на Амазон, Клодо и тд.
Если говорить в отношении it-patrol, то лучше, на мой взгляд, поддерживать и улучшать уже имеющуюся инфраструктуру, сохранять репутацию первоклассного Drupal-хостинга и не гоняться за облаками.
Важно понять, что большинство проектов — это не Гуглы/Фейсбуки, им не нужны ноды в разных географических точках. Про 2 узких места подмечено верно. Проблема решается просто: много статики -- выносим на S3 или отдаем через CloudFront, тормозит БД -- тюним сервер, оптимизируем запросы,
выкидываем друпал.Всем рекомендую http://teddziuba.com/2011/04/amazon-the-purpose-of-pain.html
В том виде как сейчас продают облака - это не товар. но я бы не хотел поднимать рекламу патруля в этом топике. Я действительно хочу разогнать туман вокруг этих облаков.
Раставить, в первую очередь для себя самого, все по местам - и назвать все вещи своими именами.
В свое время я так сделал с VDS - и в патруле нет такой услуги.
Автор достаточно эмоционален, по ссылке что вы дали.
И правильно подчеркивает ситуацию - реальный опыт важнее слов на странице услуг.
Именно реальный опыт других пользователей я бы и хотел прочитать в этом топике.
Было бы класно если Илья А. отписался. У него в свое время была тесная дружба с EC2.
Не люблю писать просто так.
Я достаточно много сказал о том, в каком направлении вам надо двигаться для изучения облаков. Судя по предпоследнему комменту, вы поняли, что упустили в первоначальных рассуждениях.
По поводу Druapl 7 - ну да, именно он. Вышеописанные модули работают, нюансов нет. Если есть желание получить от нас подробности - придется пару месяцев еще подождать.
Еще более обычным пользователям не нужно VDS
Ну а самым обычным пользователям не нужен даже хостинг! Потому что они не знают, что это такое.
Комментарий о том, что у каждой услуги есть своя аудитория - спасибо, кэп.
А зачем? При всем уважении к патрулю, реализовать облако компании такого масштаба не могут. Даже оверсан, "заимствующий" миллионы-миллиарды денег на космос смог сделать только VDS-премиум.
Технологии, про которые я написал, могут реализовывать Гугл, Амазон, Майкрсофт.
Немного подведу итог ваших слов:
- на рынке ТРУЪ облако только у 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.
Я бы посоветовал умерить ЧСВ и писать по существу.
Если начали про Azure -- то опишите, чем он так крут, во сколько выходит по деньгам, можно ли поднять на нем, скажем, Джанго/RoR-приложение, насколько сильно платформа привязывает разработчика -- в смысле, легко ли будет с этого облака потом съехать, не потеряв данные.
Докладом прошу не кормить.
Тут еще такой момент, что если на инстансе мы установим обычный MySQL-сервер, то это не будет облачная БД, и в этом плане сам EC2 не будет отличаться от VDS. У амазона есть настоящие облачные БД -- нереляционная SimpleBD и реляционная RDS, но для их использования нужно писать абстрактный слой для друпаловской БД или какой-то модуль. Год назад я искал на d.org на эту тему, но там дальше обсуждения дело не сдвинулось. Писал сам, но не осилил.
Я лично жду, когда гугловский Cloud SQL можно будет использовать из вне (не только в App Engine).
подпишусь
То есть, по сути сказать нечего
Видимо, кроме доклада пока практического опыта нет 
подпишусь
Появился практический опыт работы с "Облачным" решением амазона.
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/
cdn вроде активно перепилили, но тюнить под каждую задачу придется
а репликация баз всегда была и останется головной болью, какой-бы RDS не был обещан...
ЗЫЖ в 7ке, кстати, довольно много запросов написано с учетом slave базы, да и альтеров предостаточно, но в любом случае придется под-задачу-кодить %(
С самого начала было ясно, что облака это типичный маркетинговый булшит. Впрочем, булшит пошел в массы и теперь все вынуждены играть в эту игру.