Comments 20
Что то мне это напомнило презентацию с Win 2008 R2.
Про мягкое мигрирование в кластере.
Про мягкое мигрирование в кластере.
Количество орфографических ошибок просто вынуждает меня спросить:
«А там можно будет грабить корованы?» :)
«А там можно будет грабить корованы?» :)
UFO just landed and posted this here
Пост мне напомнил один феерический доклад про то как самому построить ютуб и как транслировать ролики. Главной идей было натыкать по всему миру серваков чтоб контент ближе к юзерам был.
На самом деле, не все так просто как Вы себе представляете.
Решения, для организации облачной платформы уже давно есть.
Например, eucalyptus — это OpenSource продукт частично повторяющий облачный функционал от Amazon. Облачное решение «инфраструктура+платформа+сервисы» организовать не сложно. Для этого потребуется мозг и прямые руки с напильником. В Вашей затее самое сложное — это биллинг. Биллинга для OpenSource облачных решений нет и врядли будет, иначе любой школьник смог бы сделать свой Амазон… Удачи! ;)
Решения, для организации облачной платформы уже давно есть.
Например, eucalyptus — это OpenSource продукт частично повторяющий облачный функционал от Amazon. Облачное решение «инфраструктура+платформа+сервисы» организовать не сложно. Для этого потребуется мозг и прямые руки с напильником. В Вашей затее самое сложное — это биллинг. Биллинга для OpenSource облачных решений нет и врядли будет, иначе любой школьник смог бы сделать свой Амазон… Удачи! ;)
Для билинга можно взять за основу github.com/maccman/saasy
Посмотрел на hetzner — а как вы будете облако строить, когда там 7.5 Гб (ГБ!!!) трафика всего (ну 30 максимум в плане Commerce)
Может вы не туда смотрели? Там 2ТБ трафика на сервер, дополнительные по 12евро за 2ТБ
Нашел :) хаха
Нет, я не собираюсь размещать сервера в северной африке, я про германский датацентр ( www.hetzner.de/en/hosting/produkte_rootserver/eq4/ )
Видать с интернетом в африке совсем плохо
Нет, я не собираюсь размещать сервера в северной африке, я про германский датацентр ( www.hetzner.de/en/hosting/produkte_rootserver/eq4/ )
Видать с интернетом в африке совсем плохо
Только не виртуалбокс а xen. А вот с биллингом далеко не все так просто…
Этот пост за гранью добра и зла, но ответье, пожалуйста, как предполагается наращивать мощность базы данных, учитывая что обычно оно таки упирается в диск?
На это у меня есть ещё одна сумасшедшая идея :) Можно сделать жесткий диск на котором будет несколько считывающих головок для каждого блина. Если их сделать серповидной формы и крепить под углом то можно поставить штук 20 для одного шпенделя :)
ДЦ дорого а завод по производству винтов на халяву?
Да, это конечно не выход если вы говорите о создании облачного хостинга амазона. Но щас только амазон и google app engine дают отдельное решение для базы, и я не слышал что-бы ими много пользовались, даже наоборот, амазон работает медленней из-за подсчета количества запросов.
Можно сделать отдельные инстансы с винтами на 10к оборотов или ssd. Универсального решения не придумать, кому-то нужно память для базы, кому-то жесткий, кому-то процессор.
Можно сделать отдельные инстансы с винтами на 10к оборотов или ssd. Универсального решения не придумать, кому-то нужно память для базы, кому-то жесткий, кому-то процессор.
Эм дык будущее рядом, всё описанное вроде давным давно реализовано. Виртуализаций и обложек для неё множество, управление ресурсами на лету давно придумано, т.е. всё что касается вертикальной масштабируемости есть давно. Продукты по автоматической миграции есть тоже уже как пару лет — т.е. когда на одном сервере не хватает ресурсов часть клиентов мигрируют на другой сервер. Продуктов с горизонтальной масштабируемостью тоже уже есть. Единственное чего пока не установилось на рынке окончательно это масштабирование базы данных без адаптации клиента — и то уже есть проприетарные решения. Всё есть, всё рядом, всё по доступным ценам. С одним минусом из трёх параметров — Качество Удобство Дешевизна — можно выбрать себе только два
По просьбе автора детализую свою выше изложенную мысль:
1. вертикальное масштабирование (scale up) — наращивание ресурсов конкретного контейнера. Т.е. когда сайт не посещают мы платим за минимальные ресурсы, пусть это будет 100mb RAM и 1% CPU, а во время хабраэффекта нам дают всё больше и больше ресурсов до максимума, который позволяет сервер. Инструменты изменения RAM/CPU на лету есть у всех интсрументов виртуализации
2. рано или поздно наступает момент когда мы не вмещаемся на текущем сервере — например на сервере два клиента, каждый отъедает 50% RAM и оба просят ещё чуть-чуть. Тут система обязана уловить затык и перенести нас на другой сервер где ресурсов больше (либо такой-же сервер но свободнее, либо сам сервер мощнее ). Это у нас миграция — тут всё не так просто, но многие продукты уже умеют, кто-то на лету, кто-то с задержкой.
3. когда мы съедаем весь ресурс мощного сервера остаётся только один вариант — брать больше серверов и раскидывать программу по ним. Это зовётся scale out. Первый шаг для стандартных приложений это разделение приложения и базы — это позволяет использовать уже 2 сервера без изменения логики приложения. Второй шаг это распределение каждого. И тут если для файлов тропинки знакомы — разослать файлы по всем серверам и распределить вызовы по серверам, то базы данных без изменения логики приложения нагрузку разделять практически не могут, хотя отлично реплицируются. Именно тут создаётся много костылей, как не изменяя скрипт разбросать его SQL запросы.
Хостинг это не просто предоставляемые ресурсы — их как раз в облако обращать не проблема — а это набор чужих приложений. Не зная приложения нельзя оптимизировать его работу, можно только дать ему ресурсов. То же касается и миграции — можно мигрировать кусок памяти, как он себя поведёт в новом месте можно только предполагать. А тупое давание ресурсов для многих-многих программ ничего не даст. Кроме того даже самый простой-простой мини сайтик визиточка использует кучу вещей которые в вашем случае подлежали бы распределению — DNS резолюция, нагрузка на канал, IP адресация, сетевая подсистема, вебсервер, интерпретатор языка, файловая система, база данных, уровень запросов к базе данных итд итп. И каждый из этих уровней абстракции требует своё решение для балансировки. А чтобы всё работало должно чётко отработать каждое звено — т.е. шанс ошибки сильно выше чем на обычном хостинге, а сложность разработки такой системы заоблачная
Что получается в сухом остатке — не зная приложения (кому-то нужен CPU, кому-то диск, кому-то важно наличие ресурсов а кому-то тайминги, итд итп ) эффективность такого «роста» из коробки низкая, а стоимость высокая. Сильно сокращает целевую аудиторию
Второй момент сильно его сокращающий это цели этой самой аудитории — мысль о том чтоб платить только за то что потребляешь интересна тем кто хочет платить очень мало (сайт не генерирует особой нагрузки, незачем платить XX $ в месяц) — это для хостера сразу мимо кассы. Тем кому надо редко но крепко — не интересны хостеру по той же причине, они хотят обычный хостинг с функцией выдержать хабраэффект разок в месяц, но не хоят за это платить. А те кому надо много и часто — тем не нужна вся эта автоматика, она вообще по-честному-то очень мало кому нужна. Я не так давно обозревал хостинг который позволяет кол-во ресурсов в админке ползунком тягать — вот это надо 90% юзеров и не более того, может минимум автоматики. Но уж точно не миграции
Те у кого нагрузки требуют того скалируются сами — для любителей автоматики есть например сервис scalr.net — он на амазоновских клаудах автоматически запускает/отключает сервера, устанавливает на них ваше приложение, балансирует нагрузку итд итп. Вам в своём приложении — если вы вышли на уровень того требующий — будет несложно добавить нужный для этого функционал
Вот и получается что переплачивать за выстраданный для массы продукт никто не хочет, те же проблемы умеючи вебмастер решит сам, а неумеючих впорос клаудов они почти не затрагивают, всё это в купе с высокой стоимостью владения ведёт к невосстребованности такого на рынке, а потому оно останется уделом спецов
А в массовый рынок выйдут системы где потребление ресурсов поддаётся исчислению, что позволяет понять нужды приложения и скалировать эффективно. В таких системах запрос ресурсов идёт не сам по себе а через API — тот же AppEngine или амазон — файл пиши через API, читай через API, в базу лезь по API. Каждый вызов можно посчитать, заставить оплатить, а главное имея статистику вызовов можно дать приложению чего оно хочет не вдаваясь в его логику
В общем миру не нужен клауд хостинг, нужен инструмент попроще — и их много, гибридов хостинга и dedicated/vps — grid хостинг, mosso-like хостинг к примеру для той же целевой группы. А для спецов будет куча продуктов менее похожих на массхостинг — можете поглядеть на хабле статью о типах SaaS, там подробно описано, что именно сейчас предлагают гиганты
1. вертикальное масштабирование (scale up) — наращивание ресурсов конкретного контейнера. Т.е. когда сайт не посещают мы платим за минимальные ресурсы, пусть это будет 100mb RAM и 1% CPU, а во время хабраэффекта нам дают всё больше и больше ресурсов до максимума, который позволяет сервер. Инструменты изменения RAM/CPU на лету есть у всех интсрументов виртуализации
2. рано или поздно наступает момент когда мы не вмещаемся на текущем сервере — например на сервере два клиента, каждый отъедает 50% RAM и оба просят ещё чуть-чуть. Тут система обязана уловить затык и перенести нас на другой сервер где ресурсов больше (либо такой-же сервер но свободнее, либо сам сервер мощнее ). Это у нас миграция — тут всё не так просто, но многие продукты уже умеют, кто-то на лету, кто-то с задержкой.
3. когда мы съедаем весь ресурс мощного сервера остаётся только один вариант — брать больше серверов и раскидывать программу по ним. Это зовётся scale out. Первый шаг для стандартных приложений это разделение приложения и базы — это позволяет использовать уже 2 сервера без изменения логики приложения. Второй шаг это распределение каждого. И тут если для файлов тропинки знакомы — разослать файлы по всем серверам и распределить вызовы по серверам, то базы данных без изменения логики приложения нагрузку разделять практически не могут, хотя отлично реплицируются. Именно тут создаётся много костылей, как не изменяя скрипт разбросать его SQL запросы.
Хостинг это не просто предоставляемые ресурсы — их как раз в облако обращать не проблема — а это набор чужих приложений. Не зная приложения нельзя оптимизировать его работу, можно только дать ему ресурсов. То же касается и миграции — можно мигрировать кусок памяти, как он себя поведёт в новом месте можно только предполагать. А тупое давание ресурсов для многих-многих программ ничего не даст. Кроме того даже самый простой-простой мини сайтик визиточка использует кучу вещей которые в вашем случае подлежали бы распределению — DNS резолюция, нагрузка на канал, IP адресация, сетевая подсистема, вебсервер, интерпретатор языка, файловая система, база данных, уровень запросов к базе данных итд итп. И каждый из этих уровней абстракции требует своё решение для балансировки. А чтобы всё работало должно чётко отработать каждое звено — т.е. шанс ошибки сильно выше чем на обычном хостинге, а сложность разработки такой системы заоблачная
Что получается в сухом остатке — не зная приложения (кому-то нужен CPU, кому-то диск, кому-то важно наличие ресурсов а кому-то тайминги, итд итп ) эффективность такого «роста» из коробки низкая, а стоимость высокая. Сильно сокращает целевую аудиторию
Второй момент сильно его сокращающий это цели этой самой аудитории — мысль о том чтоб платить только за то что потребляешь интересна тем кто хочет платить очень мало (сайт не генерирует особой нагрузки, незачем платить XX $ в месяц) — это для хостера сразу мимо кассы. Тем кому надо редко но крепко — не интересны хостеру по той же причине, они хотят обычный хостинг с функцией выдержать хабраэффект разок в месяц, но не хоят за это платить. А те кому надо много и часто — тем не нужна вся эта автоматика, она вообще по-честному-то очень мало кому нужна. Я не так давно обозревал хостинг который позволяет кол-во ресурсов в админке ползунком тягать — вот это надо 90% юзеров и не более того, может минимум автоматики. Но уж точно не миграции
Те у кого нагрузки требуют того скалируются сами — для любителей автоматики есть например сервис scalr.net — он на амазоновских клаудах автоматически запускает/отключает сервера, устанавливает на них ваше приложение, балансирует нагрузку итд итп. Вам в своём приложении — если вы вышли на уровень того требующий — будет несложно добавить нужный для этого функционал
Вот и получается что переплачивать за выстраданный для массы продукт никто не хочет, те же проблемы умеючи вебмастер решит сам, а неумеючих впорос клаудов они почти не затрагивают, всё это в купе с высокой стоимостью владения ведёт к невосстребованности такого на рынке, а потому оно останется уделом спецов
А в массовый рынок выйдут системы где потребление ресурсов поддаётся исчислению, что позволяет понять нужды приложения и скалировать эффективно. В таких системах запрос ресурсов идёт не сам по себе а через API — тот же AppEngine или амазон — файл пиши через API, читай через API, в базу лезь по API. Каждый вызов можно посчитать, заставить оплатить, а главное имея статистику вызовов можно дать приложению чего оно хочет не вдаваясь в его логику
В общем миру не нужен клауд хостинг, нужен инструмент попроще — и их много, гибридов хостинга и dedicated/vps — grid хостинг, mosso-like хостинг к примеру для той же целевой группы. А для спецов будет куча продуктов менее похожих на массхостинг — можете поглядеть на хабле статью о типах SaaS, там подробно описано, что именно сейчас предлагают гиганты
Sign up to leave a comment.
Сlouds hosting, полеты в облаках