Сlouds hosting, полеты в облаках

    Что особенного в cloud hosting? Основное преимущество выделяют: вы платите ровно столько, сколько используете; Вы можете быстро нарастить производительность если вам потребуется.
    По сути мы имеет веб-интерфейс к системе виртуализации. Мы получаем в распоряжение обычный vps только более просто и быстро. Так-же это можно автоматизировать, чтобы например днем, в нагруженные часы запускались дополнительные инстансы.

    Я думаю можно легко сделать аналог amazon\rackspace самому за относительно небольшое время. Берем систему виртуализации, это может быть virtualbox, xeh или любой другой и прикручиваем к нему веб-интерфейс, который будет запускать и останавливать виртуальные машины на нескольких серверах.
    К этому добавляем регистрацию и биллинг. Все, у нас свое облако.

    Затем можно добавить фичу cloud files: нужно чтобы можно было закинуть туда файлы и отдавать быстро и много. Думаю каждый сам придумает как это сделать :)

    Посчитаем финансы:


    Свой датацент это слишком сложно и дорого, я бы взял сервера в hetzner: за 40 евро ($53) имеем CORE i7 920, 8GB RAM, 750GB HDD RAID1.
    Думаю можно выделить 1GB RAM и 50GB HDD для оболочки которая контролирует запущенные инстансы.
    А остальное разделить на 14 частей (512mb ram, 50gb hdd) и продавать например по $20, в итоге получаем $280 с одного сервера, 53 отдаем в hetzner, остальное себе. Если так заправить 10 серверов, то имеем $2200 в месяц :)

    Если использовать сервера с 12gb ram и 1.5TB hdd то его можно разделить на 22 кусочка, продать их за $440 и $76 отдать hetzner.
    Получается немного выгодней, но процессора клиентам достанется меньше.

    Разрешите, немного пофантазирую


    Как сейчас масштабируется? Делаем application сервера, сервера для базы, сервера для статики.

    Мне-бы хотелось чтобы хостинг масштабировался просто и сам. Т.е. когда проекту требуется больше ресурсов он их получает. Вроде все просто, но возникает проблема когда 2 проекта на одном сервере хотят весь сервер. Если придумать механизм чтобы можно было переместить инстанс на другой физический сервер. Для этого нужно создать полную копию оперативной памяти на второй машине, и доступ к жесткому диску. Приостановить на долю секунды и все пакеты роутером перенаправить на новый сервер.

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


    Когда совершается «переезд» жесткий диск переходит под контроль нового сервера.

    Если ещё придумать что-бы один инстанс использовал ресурсы нескольких серверов, получается как-бы кластер (но об этом я совсем ничего не знаю). И у нас в распоряжении неограниченное вычислительное облако. Где можно запускать что-угодно. Думаю это будущее хостинга.

    Например идет соревнование геймеров и зашло много людей что-бы посмотреть, и облако выделит нужные ресурсы не прерывая процесс игры.
    Или если ваш сервис попал на mashable, то сайт не ляжет и вам не придется заморачиваться по поводу масштабирование (только заморочиться чтоб найти деньги :) )

    Комментарии 20

      0
      Что то мне это напомнило презентацию с Win 2008 R2.
      Про мягкое мигрирование в кластере.
        –1
        Количество орфографических ошибок просто вынуждает меня спросить:

        «А там можно будет грабить корованы?» :)
          +1
          По возможности исправил
          0
          В убунту, например, давно своё облако продвигают.
          Вы изобретаете велосипед?
            0
            Просто расмышления об идеальной площадке. Можно ссылку на облаке убунты?
              0
              А зачем ссылка? Берете образ Ubuntu 9.10 Server и там есть пункт типа Install Cloud server.
                0
                гениально. можите рассказать побольше об X? зачем? вон там касса. все же надо знать, что устанавливаешь. или это часть философии убунты? делай так как написано в хавте.
            0
            Пост мне напомнил один феерический доклад про то как самому построить ютуб и как транслировать ролики. Главной идей было натыкать по всему миру серваков чтоб контент ближе к юзерам был.
              0
              На самом деле, не все так просто как Вы себе представляете.

              Решения, для организации облачной платформы уже давно есть.

              Например, eucalyptus — это OpenSource продукт частично повторяющий облачный функционал от Amazon. Облачное решение «инфраструктура+платформа+сервисы» организовать не сложно. Для этого потребуется мозг и прямые руки с напильником. В Вашей затее самое сложное — это биллинг. Биллинга для OpenSource облачных решений нет и врядли будет, иначе любой школьник смог бы сделать свой Амазон… Удачи! ;)

              0
              Посмотрел на hetzner — а как вы будете облако строить, когда там 7.5 Гб (ГБ!!!) трафика всего (ну 30 максимум в плане Commerce)
                0
                Может вы не туда смотрели? Там 2ТБ трафика на сервер, дополнительные по 12евро за 2ТБ
                  +1
                  Нашел :) хаха
                  Нет, я не собираюсь размещать сервера в северной африке, я про германский датацентр ( www.hetzner.de/en/hosting/produkte_rootserver/eq4/ )
                  Видать с интернетом в африке совсем плохо
                  –1
                  Только не виртуалбокс а xen. А вот с биллингом далеко не все так просто…
                    0
                    Этот пост за гранью добра и зла, но ответье, пожалуйста, как предполагается наращивать мощность базы данных, учитывая что обычно оно таки упирается в диск?
                      0
                      На это у меня есть ещё одна сумасшедшая идея :) Можно сделать жесткий диск на котором будет несколько считывающих головок для каждого блина. Если их сделать серповидной формы и крепить под углом то можно поставить штук 20 для одного шпенделя :)
                        0
                        ДЦ дорого а завод по производству винтов на халяву?
                          0
                          Да, это конечно не выход если вы говорите о создании облачного хостинга амазона. Но щас только амазон и google app engine дают отдельное решение для базы, и я не слышал что-бы ими много пользовались, даже наоборот, амазон работает медленней из-за подсчета количества запросов.

                          Можно сделать отдельные инстансы с винтами на 10к оборотов или ssd. Универсального решения не придумать, кому-то нужно память для базы, кому-то жесткий, кому-то процессор.
                      0
                      Эм дык будущее рядом, всё описанное вроде давным давно реализовано. Виртуализаций и обложек для неё множество, управление ресурсами на лету давно придумано, т.е. всё что касается вертикальной масштабируемости есть давно. Продукты по автоматической миграции есть тоже уже как пару лет — т.е. когда на одном сервере не хватает ресурсов часть клиентов мигрируют на другой сервер. Продуктов с горизонтальной масштабируемостью тоже уже есть. Единственное чего пока не установилось на рынке окончательно это масштабирование базы данных без адаптации клиента — и то уже есть проприетарные решения. Всё есть, всё рядом, всё по доступным ценам. С одним минусом из трёх параметров — Качество Удобство Дешевизна — можно выбрать себе только два
                        0
                        По просьбе автора детализую свою выше изложенную мысль:

                        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, там подробно описано, что именно сейчас предлагают гиганты

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое