Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 187
Мечта школьника =)
Хороший ликбез, согласен по каждому пункту. Порой так неприятно слышать даже от продвинутых ИТ-шников фразы про «облачные вычисления», видя, что понимания сути вопроса у них нет (был тут на прошлой неделе на Cisco Expo Learning Club, там как раз докладчики тихо фейлили по этому вопросу, аудитория хавала, хотя пришли в массе своей, прожженые ИТ-шники, цискари со стажем).
циска на UCS вообще забавные маретинговые слоганы придумывает =)
На презентации UCS было очень смешно слушать про то, что у них мегасистема, которая «заточена под облачные вычисления». По сути же — простой блейд-центр с PXE :)
… именно это я и имел в виду под «облачными антивирусами». Сейчас поправлю.
Просто «облачный» это сейчас такое модное словечко. Как «инновации» и «нанотехнологии» — звучит очень умно и очень непонятно.
Нет, «инновации» и «нанотехнологии» это нубский уровень. Вот изобрести TCO или RIA, или ещё что-то своё — это да. Одно время все бегали с тонкими клиентами и application delivery. Сейчас все бегают с облаками и IaaS… Важно вычленять из этого реальную составляющую. Она есть, она маленькая и простая. А маркетологов нафиг.
С одной стороны забавно, да. С другой стороны все зависит от того, что понимать под облачными вычислениями и облаком.
Я лично предпочитаю такой вариант: облако — это уровень абстракции от физической инфраструктуры, при котором осуществляется переход от выделения сервера к выделению ресурсов на уровне мегагерц процессора, мегабайт памятить и мегабит сети.
В этом случае все нормально, UCS изначально позиционируется Cisco как аппаратная платформа для построения облака.
Я лично предпочитаю такой вариант: облако — это уровень абстракции от физической инфраструктуры, при котором осуществляется переход от выделения сервера к выделению ресурсов на уровне мегагерц процессора, мегабайт памятить и мегабит сети.
В этом случае все нормально, UCS изначально позиционируется Cisco как аппаратная платформа для построения облака.
Э… UCS — это железо с перекеенными стикерами? Чем оно от обычного отличается?
Аппаратная платформа для построения облака нужна только в случае HVM (и основа платформы — интел). В случае PV специальное железо не нужно, потому что функционал реализуется софтом. И я не видел железных «акселераторов» процесса, например, live migration.
Аппаратная платформа для построения облака нужна только в случае HVM (и основа платформы — интел). В случае PV специальное железо не нужно, потому что функционал реализуется софтом. И я не видел железных «акселераторов» процесса, например, live migration.
Это вечная проблема, потому что технарь слушает менеджера, понимает как это круто, смотрит как это сделано, видит, что ничего не сделано и как это сделать не понятно, и махает рукой. Выживают только маркетологи.
Вот, например, частый миф с облаками: они позволяют использовать оперативной памяти больше, чем есть на хосте. Или, что программа распараллеливается по нескольким хостам.
Человек ожидает это увидеть — видит, что этого нет… Остаётся либо дальше нести ахинею, либо сваливать нафиг.
Вот, например, частый миф с облаками: они позволяют использовать оперативной памяти больше, чем есть на хосте. Или, что программа распараллеливается по нескольким хостам.
Человек ожидает это увидеть — видит, что этого нет… Остаётся либо дальше нести ахинею, либо сваливать нафиг.
А разве в облаках типа Azure, App Engine разные запросы не могут обрабатываться на физически разных машинах?
Для этого они должны быть запрограммированы. Reduce/Map и т.п.
Не говорите ерунды. С точки зрения разработчика, суть облачных вычислений и заключается в том, что мы пишем наш сервис таким образом, что мы не привязываемся к конкретной машине. В случае Google AppEngine, у нас нет доступа к диску, и поэтому запрос можно выполнить на любой машине, которая сейчас менее загружена; аналогично, используются HTTP запросы для доступа к хранилищам данных (всех типов).
Как следствие, если программа написана в «стиле AppEngine» — то есть небольшими операциями, которые делают только то, что должны делать а потом передают управление дальше, приложению вцелом совершенно пофигу, на каких машинах эти операции будут выполняться; если же какие-то операции помечены как асинхронные задачи, то выполнение можно будет прекрасно распараллелить.
Как следствие, если программа написана в «стиле AppEngine» — то есть небольшими операциями, которые делают только то, что должны делать а потом передают управление дальше, приложению вцелом совершенно пофигу, на каких машинах эти операции будут выполняться; если же какие-то операции помечены как асинхронные задачи, то выполнение можно будет прекрасно распараллелить.
Вот-вот. Мне кажется, это неправильный путь. Инфраструктура должна предоставлять среду, а не диктовать, как нужно программировать.
А если «небольшая операция» занимает 150Гб памяти и длится сутки?
А если «небольшая операция» занимает 150Гб памяти и длится сутки?
То это очень-очень неправильно даже с точки зрения здравого смысла. Если небольшую операцию разбить на много еще более небольших, фейл одной очень небольшой операции не приведет к фейлу просто небольшой операции при условии что очень небольшую операцию удастся успешно перезапустить (см. Hadoop).
И потом. Если ваша конкретная задача ну никак не параллелится, наверное, у вас есть ресурсы чтобы купить выделенные сервер(ы) и решать задачу на них, 99.9% же удовлетворяться описанным подходом.
И потом. Если ваша конкретная задача ну никак не параллелится, наверное, у вас есть ресурсы чтобы купить выделенные сервер(ы) и решать задачу на них, 99.9% же удовлетворяться описанным подходом.
>А если «небольшая операция» занимает 150Гб памяти и длится сутки?
то она бьется на много маленьких кусочков, выполняющихся на разных машинах.
>Инфраструктура должна предоставлять среду, а не диктовать, как нужно программировать.
инфраструктура и среда диктуют, как нужно программировать, чтобы это эффективно работало.
инкрементные id-шники, локальная память и последовательное выполнение не работают на сотнях данных и миллионах юзеров — не просто неэффективны, а вообще не работают.
то она бьется на много маленьких кусочков, выполняющихся на разных машинах.
>Инфраструктура должна предоставлять среду, а не диктовать, как нужно программировать.
инфраструктура и среда диктуют, как нужно программировать, чтобы это эффективно работало.
инкрементные id-шники, локальная память и последовательное выполнение не работают на сотнях данных и миллионах юзеров — не просто неэффективны, а вообще не работают.
и Map/Reduce здесь совершенно не при чем. Это всего лишь один из способов распараллелить большие объемы вычислений, к подавляющему большинство веб-сервисов это трудноприменимо (в первую очередь потому, что сама идеология заточена на обработку больших объемов данных, и нельзя гарантировать latency).
Я, конечно, ответил не совсем в тему, просто речь пошла о вычислениях, которые требуют больше ресурсов, чем есть на самом мощном узле облака. Можно просто оставить всё как есть, понадеявшись на авось и средства виртуализации ресурсов, предоставляемые облачным движком, но это менее эффективно, чем разбить задачу на составляющие подзадачи, которые смогут работать относительно независимо. Соответственно, map/reduce — лишь один из способов сделать это более-менее просто, а самое главное, с идеалогией, совместимой со стилем мышления опытного программиста на современных скриптовых и ФП-языках. Ну и то, что не для всех приложений он подойдёт, — очевидно.
Т.е. я поддерживаю то, что вы написали выше для amarao.
Т.е. я поддерживаю то, что вы написали выше для amarao.
в gae нет map-reduce. шкатанай, десу
Разные запросы к чему? Если у вас запросы к одной и той же таблице на 200Гб в одном и том же SQL, то как это будет сделано технически?
разные запросы к «веб-серверу». грубо говоря, обработчики POST/GET.
да, они могут обрабатываться на разных машинах.
да, они могут изменять данные в одной таблице. при этом, другие запросы на чтение могут еще и вернуть старые данные, которые былы до последнего обновления, если не использовался strong consistency.
если они одновременно меняют одну и ту же сущность, вылетает исключение.
при этом фронтенд, который принимает данные, машины, на которых исполняется обработчик http-запроса и машины, на которых живут данные, блобы и мемкеш — это все разные машины, которых тысячи.
да, они могут обрабатываться на разных машинах.
да, они могут изменять данные в одной таблице. при этом, другие запросы на чтение могут еще и вернуть старые данные, которые былы до последнего обновления, если не использовался strong consistency.
если они одновременно меняют одну и ту же сущность, вылетает исключение.
при этом фронтенд, который принимает данные, машины, на которых исполняется обработчик http-запроса и машины, на которых живут данные, блобы и мемкеш — это все разные машины, которых тысячи.
Если кратко, то могут. См мой ответ внизу.
>частый миф с облаками: они позволяют использовать оперативной памяти больше, чем есть на хосте
Облака нет. Но, скажем, VMware vSphere позволяет при определенных условиях за счет дедупликации памяти именно использовать памяти больше, чем есть физической.
Чуть больше IaaS платформ позволяют выделить виртуальным машинам памяти больше, чем есть физической за счет «баллона» в расчете на то, что все машины не будут использовать 100% выделенной памяти.
Облака нет. Но, скажем, VMware vSphere позволяет при определенных условиях за счет дедупликации памяти именно использовать памяти больше, чем есть физической.
Чуть больше IaaS платформ позволяют выделить виртуальным машинам памяти больше, чем есть физической за счет «баллона» в расчете на то, что все машины не будут использовать 100% выделенной памяти.
Распределить вам могут что угодно. Вы _ПРЕДОСТАВИТЬ_ можете? Нет. А многие ожидают. Мол, 100 серверов в облаке, в каждом из них 16Гб памяти, итого, мы можем иметь 1600Гб памяти для одного процесса! Круто, можно сортировать базу на 1Тб, грузя её в память целиком.
Самый задаваемый мне на конференциях вопрос: а можно сделать из двух физических машин одну большу виртуальную?
И ответ, разумеется, «нет». Это итог кривого маркетинга.
Не только. Есть еще вечное желание халявы и чуда.
Скажем так, у меня есть пара идей о том, как можно увеличить (физически дать пользовать) больше памяти, чем есть на хосте, но это очень сложно реализовать… И я не уверен в производительности. Даже 10Г явно по скорости не дотягивает до скорости FSB на порядки…
Infiniband не дотягивает, даже не 10G. Самая большая проблема даже не пропускной способности, а в задержке при доступе. На три-четыре порядка минимум.
Ну, если грубо говорить про идею, с которой я (даже пока не бегаю) — это вынесение малоиспользуемых страниц памяти на более медленную память. Этакое промежуточное состояние между свопом и нормальной оперативкой.
VMware в vSphere 4.1 обещает сделать Memory Compression — автоматическую компрессию малоиспользуемых страниц памяти. Тоже вполне себе способ.
Да, это второй метод…
Кстати… Если рассуждать оголтело. Что нам мешает сделать SMP из двух компьютеров? Хотя бы на пользовательском уровне? Нам нужно обеспечить прокидывание IPI между хостами для обоих половинок гостя. Но с PV ядром, почему бы нет?
Это будет следующая моя идея после поддержки TRIM в VBD…
Кстати… Если рассуждать оголтело. Что нам мешает сделать SMP из двух компьютеров? Хотя бы на пользовательском уровне? Нам нужно обеспечить прокидывание IPI между хостами для обоих половинок гостя. Но с PV ядром, почему бы нет?
Это будет следующая моя идея после поддержки TRIM в VBD…
В доисторическое время облака назывались кластерами :) Почитайте материалы по кластерам, начиная с 80-х годов. Там есть много как готовых продуктов (очень дорогих), так и просто хороших идей и опытных работ.
В разработках посвежее есть кластеры на линуксе, объединяющие процессы, IPC (сигналы, shared memory, сокеты) с адаптивным processor and machine affinity. Т.к. был межмашинный меппинг shared memory, то наверняка мог быть и мэппинг физической памяти с нескольких машин в один процесс.
В разработках посвежее есть кластеры на линуксе, объединяющие процессы, IPC (сигналы, shared memory, сокеты) с адаптивным processor and machine affinity. Т.к. был межмашинный меппинг shared memory, то наверняка мог быть и мэппинг физической памяти с нескольких машин в один процесс.
Облака и кластеры — разные вещи. Не путайте.
Кластер имеет инфраструктурную составляющую, чтобы управлять каждым узлом (MS HPC, или там что-нибудь вроде клиента BOINC). Под эту инфраструктуру уже пишется софтина, которая позволяет одновременно использовать мощности всех узлов.
Облако же — лишь способ отвязаться от хоста, на котором запущен сервис. Скажем, DRS-кластер VMware — вполне себе облако для виртуальных машин, которые в нем крутятся. Виртуалка не знает, что она виртуалка, она работает через свои привычные интерфейсы.
Кластер имеет инфраструктурную составляющую, чтобы управлять каждым узлом (MS HPC, или там что-нибудь вроде клиента BOINC). Под эту инфраструктуру уже пишется софтина, которая позволяет одновременно использовать мощности всех узлов.
Облако же — лишь способ отвязаться от хоста, на котором запущен сервис. Скажем, DRS-кластер VMware — вполне себе облако для виртуальных машин, которые в нем крутятся. Виртуалка не знает, что она виртуалка, она работает через свои привычные интерфейсы.
К слову, большинство «облачных» сервисов сейчас предлагается именно в виде «виртуалок с миграцией с выдачей пользователям логинов/паролей/IP к ним» — т.е. в терминах статьи, «переименованные VDS».
Т.е. большинство сервисов, рекламируемых как облачные — не настоящие облака с виртуализацией ресурсов (вроде GAE), а просто обычные виртуалки с автомиграцией в зависимости от требуемой/задействованной загрузки.
А терминологически, писать воркеры «под BOINC», «под GAE», или «под VDS — узлы» — небольшая разница, только под GAE, получается, как бы, библиотечки для IPC/гриддинга готовые встроены в платформу и весьма неплохи.
Т.е. большинство сервисов, рекламируемых как облачные — не настоящие облака с виртуализацией ресурсов (вроде GAE), а просто обычные виртуалки с автомиграцией в зависимости от требуемой/задействованной загрузки.
А терминологически, писать воркеры «под BOINC», «под GAE», или «под VDS — узлы» — небольшая разница, только под GAE, получается, как бы, библиотечки для IPC/гриддинга готовые встроены в платформу и весьма неплохи.
Всё уже есть — см. мой коммент ниже.
это не SMP, а NUMA.
Почему же нельзя? Сделать можно если реализовать на базе виртуальной машины, например, JVM допилить. При этом JVM сможет расшаривать память и даже при выполнении циклов проводить распараллеливание на несколько серверов. Разработчик просто будет писать программу под JVM и не парится о распараллеливании в ручную.
scalemp.com/ — можно, но там свои проблемы — например, потеря одного из серверов в кластере убьёт весь кластер; для связи нужен Infiniband; пока есть только поддержка Linux. Вроде обещают в будущем поддержку Windows Server Datacenter Edition, vSphere, XenServer и т. д. — у них честная аггрегация x86 серверов. Ну и цена на уровне.
да все хорошо и красиво расписано, НО в России «облачный» vds/хостинг стоит дороже обычного. У нас получается дешевле арендовать сервер и нагружать его как вздумается
А зашлите мне в личку ссылочку на «облачный» хостинг. Я если честно, ни одного не видел.
Естественно интересует «правильное облако», а не просто изменяемые параметры VDS по пользовательскому запросу.
habrahabr.ru/company/ispsystem/blog/95354/
не знаю насколько он облачный, мне просто нужен был дешевый хостинг без лишнего геморроя. в день натекает цпу на примерно 0,005 $.
не знаю насколько он облачный, мне просто нужен был дешевый хостинг без лишнего геморроя. в день натекает цпу на примерно 0,005 $.
Если нагрузка на сервер такова, что цена аренды ниже, чем месячный платёж за потребление ресурсов, то да. Ведь в стоимость ресурсов хостер закладывает ещё и прибыль. Вопрос возникает в тот момент, когда сумма потребления ресурсов НИЖЕ, чем стоимость аренды сервера и/или установки своего оборудования.
А рунете существуют «правильные» облака?
Существуют, но с их ценами на ЦП лучше брать VPS.
А для хранения статики — самое то.
А для хранения статики — самое то.
ох а ссылочку то забыл
ispserver.com/ru/products/cloud_hosting/index.html
закидывал к ним сайт на тестовый период, который потреблял 10% от VPS в Германии ( стоимость всего VPS 14 Евро/мес).
В облаке же он мне вышел в 15 евро/мес
ispserver.com/ru/products/cloud_hosting/index.html
закидывал к ним сайт на тестовый период, который потреблял 10% от VPS в Германии ( стоимость всего VPS 14 Евро/мес).
В облаке же он мне вышел в 15 евро/мес
Для того, чтобы это все работало, необходимо, чтобы у разных клиентов пики были в разное время. Если у большей части пики примерно в одно время, то хостеру надо либо закупать дополнительные машины под облако (которые «ночью» стоят и отнимают его прибыль/завышают цены для клиентов), либо оверселлить, как и раньше.
Именно. Т.е. по сути пользователь получит то же самое — стоимость «простоев» будет включена в стоимость собственно услуги.
Это решение хорошо (для хостера) только при распределённых вычислениях и большой клиентской базе, причём территориально распределённых Клиентов — т.е. с пиками как Вы и говорите, в разное время. И что-то реально-облачное могут сделать только очень крупные компании.
По верхнему графику отлично видно, как «гуляет» нагрузка. Так она так же гуляет на большинстве сервисов в рунете, у меня даже временами ощущение (глядя на «волны» нагрузок), что вся Россия живёт по московскому времени.
Это решение хорошо (для хостера) только при распределённых вычислениях и большой клиентской базе, причём территориально распределённых Клиентов — т.е. с пиками как Вы и говорите, в разное время. И что-то реально-облачное могут сделать только очень крупные компании.
По верхнему графику отлично видно, как «гуляет» нагрузка. Так она так же гуляет на большинстве сервисов в рунете, у меня даже временами ощущение (глядя на «волны» нагрузок), что вся Россия живёт по московскому времени.
Не то же самое. Стоимость простоя НЕ будет включена в стоимость услуги. Оплата-то по реальному времени предоставления услуги, а не за «обещанную полосу». Дальше там стоит QoS, но я для себя ещё не до конца сформулировал его концепции…
Я немного не о том. Т.е. да, стоимость рубль за литр. Вылил 10 литров — заплатил 10 рублей. Только вот стоимость простоя включена в этот рубль. Иначе ночью сервер ничего не зарабатывает, только днём (только на дисковом пространстве).
Ну как я уже ниже написал, облако на то и облако — что ресурсы в нем ни к чему конкретному не привязаны, в период когда ресурсы простаивают — их можно арендовать кому-то еще, кому они в данный момент нужны, тем самым понизив стоимость издержек на простой, и цену, которая в свою очередь является конкурентным преимуществом.
Кому ещё? Другим хостерам на другом континенте? Это утопия.
Идея то отличная, тоже обдумывал. Но по сути это больше маркетинг, чем реальная выгода для Клиента, если только компания не трансконтинентальная.
Грубо говоря, есть физический сервер. С него надо собрать 100 т.р. в месяц. Либо продав 20 VPS по 5, либо продав «поштучно» в облаке. Причём, не нужно даже оверселлить с VPS.
Идея то отличная, тоже обдумывал. Но по сути это больше маркетинг, чем реальная выгода для Клиента, если только компания не трансконтинентальная.
Грубо говоря, есть физический сервер. С него надо собрать 100 т.р. в месяц. Либо продав 20 VPS по 5, либо продав «поштучно» в облаке. Причём, не нужно даже оверселлить с VPS.
Ну поэтому пионерами в этой области выступили прямо скажем довольно таки крупные компании — Amazon, Microsoft, Google — которые могут себе позволить охватить большое количество часовых поясов, и у которых график загрузки не будет ограничиваться пиком с 9 до 5 по московскому времени.
Вы описали абсолютно Российский подход к бизнесу 90х годов. К сожалению сейчас очень мало компаний осознает истину и поступает именно так. Современный подход к бизнесу должен обуславливается клиентоориентированностью и качеством сервиса, ведь 100 довольных клиентов приведут к вам 1000, 1000 приведет к вам 10000 и т. д. да так, что к вам будут выстраиваться очереди. Не нужно будет ничего оверселлить, ведь простой оборудования ночью вы уже окупили «вчера».
Зачем быть г… нохостером, лучше быть «законодателем моды»!
Зачем быть г… нохостером, лучше быть «законодателем моды»!
Это менталитет :) С этих самых 90-ых годов у жителей нашей многострадальной державы отложилась мысль «не нае… шь — не проживешь», соот-но попытка извернуться и кого-нибудь нагреть предпринимается даже тогда, когда необходимость в этом отсутствует напрочь :) Так сказать палка о двух концах, «раз богатый — значит много воровал», и «чтобы быть богатым — нужно много воровать», хотя обе сентенции в корне неверны :)
Было бы интересно услышать какие есть варианты честных облаков. Amazon?
не совсем. там ресурсы instance'а ограничены жестко, но количество instance'ов в кластере может меняться, притом даже динамически, без вашего участия. Абы ваш софт умел динамически масштабироваться.
Для хранения файлов — Amazon S3. Оплата по факту за место и запросы на скачку/закачку
Пользуюсь, очень доволен.
Пользуюсь, очень доволен.
Как будет работать такой по всем параметрам облачный хостинг?
Скажем, у нас по-прежнему есть сервер (примеры из вашей же статьи) «2.5x16 ядер», провайдер продаст его на «70 человек». Завтра каждому из них в один момент потребуется «1 ГГц». Чем это будет отличаться от ситуации, которая есть сейчас? )
Скажем, у нас по-прежнему есть сервер (примеры из вашей же статьи) «2.5x16 ядер», провайдер продаст его на «70 человек». Завтра каждому из них в один момент потребуется «1 ГГц». Чем это будет отличаться от ситуации, которая есть сейчас? )
Вы такой предмет как статистика изучали?
Я уверен, что вероятность такого случая стремится куда-то далеко за горизонт.
Я уверен, что вероятность такого случая стремится куда-то далеко за горизонт.
Никуда она не стремится. А вот вероятность такого случая, что одинаковые графики (см.верхний график в посте) будут у всех — очень высока.
По идее должна быть «живая» миграция, которая будет вступать в работу именно в такие моменты и разносить виртуальные машины по различным серверам для снижения нагрузки.
А в остальное время эти машины будут простаивать… и включаться в счет клиента :(
Почему простаивающая машина будет включаться в счёт клиента? (на всякий случай, речь про облако или про полосу?)
Потому что хостер должен как-то окупить эти деньги. Да, он не может написать в счете неиспользованные часы работы, но он может поднять стоимость 1 часа, чтобы это компенсировать.
А тут уже срабатывает чистая ясная конкуренция.
При точно прописанной SLA появится возможность выбирать поставщика по параметрам:
SLA
Исполнение SLA
стоимость ресурсов
И тут уже кто сумеет ниже предложить цену при том же SLA, тот и получит the cake.
При точно прописанной SLA появится возможность выбирать поставщика по параметрам:
SLA
Исполнение SLA
стоимость ресурсов
И тут уже кто сумеет ниже предложить цену при том же SLA, тот и получит the cake.
ну так пусть продает время простоя на задачи нетребующие немедленной отдачи
Про облако, про облако.
опередил меня с ответом.
опередил меня с ответом.
Ага, вероятность стремится к Новому году, 8-му марта или выходу сборной России на какой-нибудь чемпионат.
Каждый из них получит свою долю. И оплатит именно долю, а не полосу. Грубо говоря, если полоса стоила 100р/сутки, а была предоставлена на 30%, то в случае полосы она будет стоить ровно те же 100р (или идти ругаться на некачественное оказание услуг), а в случае оплаты по потреблению 100*30% ~= 33р.
Причём, эти деньги потеряет объективно хостер. И у него будет очевидный стимул не доводить до подобного.
Причём, эти деньги потеряет объективно хостер. И у него будет очевидный стимул не доводить до подобного.
разница в том что платить вы будете только за те ресурсы, что реально использовали
А как на ваш взгляд провайдер облака сможет компенсировать затраты на простаивающее оборудование, которое используется, например, в основном только днем? :)
Включит в стоимость услуги, разумеется.
Когда где-то день, в это же время где-то ночь.
Судя по современным представлениям об устройстве мира — да.
А судя по серверам виртуального хостинга — нет. Сам в шоке.
А судя по серверам виртуального хостинга — нет. Сам в шоке.
Именно. Но для этого нужно активно продавать хостинг за рубеж, тогда у части клиентов будет день, а у части — ночь. И даже факт, что Россия занимает кучу часовых поясов не поможет — т.к. основные клиенты сосредоточены в европейской части то есть время у всех примерно одно и тоже ±3 часа.
(шёпотом) QoS и дешёвое машинное время.
Иными словами, есть уверенность, что платежеспособный спрос на дешевое машинное время ночью соразмерен спросу на обычное машинное время днем? А приведите, пожалуйста, пример такого ночного массового потребителя? Или какая это может быть вообще такая ночная нагрузка? При этом вы ведь понимаете, что если вы продаете дешевое машинное время, то чтобы сравняться по выручке с дневным, вам нужно продавать его больше, то есть, например, процессора, должно быть больше, чем днем?
ну из реальной практики по ночам сервис занимается перекодированием видео.
Ночью есть бэкапы, обновление индексов, ещё какие-то технические задачи, не требующие реального времени.
Откровенно говорю: там много проблем, я не все их для себя обдумал, так что говорить сырые варианты решения я сейчас не готов. Придумаю — напишу.
Откровенно говорю: там много проблем, я не все их для себя обдумал, так что говорить сырые варианты решения я сейчас не готов. Придумаю — напишу.
сайты знакомств имеют преимущественно вечернюю/ночную аудиторию.
У меня тоже есть старая идея.
В суперидеальном «ресурсы по требованию» облаке стоимость машинных ресурсов будет не фиксированная, а плавающая — в зависимости от времени суток и наличия свободных ресурсов.
Провайдер будет продавать ресурсы на аукционе, на котором закупки будут осуществлять автоматические агенты, определяя цену в соответствии со своими потребностями и возможностями. Кажется, что-то типа такого имел в виду Sun, продвигал концепцию Grid и продажу ресурсов.
Но этого мало, следующим шагом будут биржы по продаже выкупленных у провайдера ресурсов. Там уже будут фьючерсы и прочие деривативы. Будет вовсю процветать высокочастотный трейдинг. Это будет особенно выгодно для провайдеров, т.к. для для трейдинговых агентов будет требоваться больше и больше вычислительных ресурсов. Побочным эффектом может стать зарождение искусственного интеллекта из трейдинговых агентов.
Потом будет «облачный форекс для лохов» и межпровайдерская биржа ресурсов. Потом, наверное, все лопнет.
В суперидеальном «ресурсы по требованию» облаке стоимость машинных ресурсов будет не фиксированная, а плавающая — в зависимости от времени суток и наличия свободных ресурсов.
Провайдер будет продавать ресурсы на аукционе, на котором закупки будут осуществлять автоматические агенты, определяя цену в соответствии со своими потребностями и возможностями. Кажется, что-то типа такого имел в виду Sun, продвигал концепцию Grid и продажу ресурсов.
Но этого мало, следующим шагом будут биржы по продаже выкупленных у провайдера ресурсов. Там уже будут фьючерсы и прочие деривативы. Будет вовсю процветать высокочастотный трейдинг. Это будет особенно выгодно для провайдеров, т.к. для для трейдинговых агентов будет требоваться больше и больше вычислительных ресурсов. Побочным эффектом может стать зарождение искусственного интеллекта из трейдинговых агентов.
Потом будет «облачный форекс для лохов» и межпровайдерская биржа ресурсов. Потом, наверное, все лопнет.
Красиво :) Что-то такое я думал, но я остановился на банальном аукционе с ставками каждого из клиентов.
Аукцион, кстати, есть у амазона: aws.amazon.com/ec2/spot-instances/
А если программист накосячит или конкуренты взломают сервис и подложат форк бомбу? Тогда получается, что благодаря «Процессорные ресурсы — по запросу. Возможно, с динамическим подключением дополнительных ядер, автоматической миграцией виртуальной машины на более свободный/быстрый сервер, если ресурсов текущего сервера начинает не хватать. Оплата процессорного времени за тики (или секунды занятости процессора).» Каждая секунда превратится в золотую. И даже если администратор за пару минут успеет понять что что-то произошло, залогинится в админку управления и воспользоваться правом отключения виртуальной машины — компания попадёт на серьёзные деньги. Всётаки, наверное, сколько жрать сервису должен определять не сам сервис, а должен быть тарифный план, где есть чётко расписанный (желательно гарантированный) максимум услуг и оплата по факту потребления. Но это кажется утопией)
Важно установить допустимые лимиты потребления, т.к. в результате технической неисправности вместо сообщения о ошибке можно получить счета с большим количеством нулей.
Всякое бывает, вплоть до разбушевавшегося лога ошибок, за несколько дней съевшего 80 (!) Гб свободного места на хостинге, а также полностью загрузившего одно из ядер сервера.
Всякое бывает, вплоть до разбушевавшегося лога ошибок, за несколько дней съевшего 80 (!) Гб свободного места на хостинге, а также полностью загрузившего одно из ядер сервера.
Счет вы не получите, вы только израсходуете средства с лицевого счета, думаю что никто не будет предоставлять вам вычеслительные мощности, за которые вы заплатите (а заплатите ли?) потом…
Да, разумется. Лимиты это важно.
Ну почему же… если система предоплатная (а она должна быть предоплатная для такого сервиса), самым смелым надо дать возможность вообще снять лимиты. На здоровье.
Как вам Google App Engine?
Он как автоматически подключающий новые мощности при необходимости.
Пробовали считать стоимость его использования? Лучше на реальном проекте.
Он как автоматически подключающий новые мощности при необходимости.
Пробовали считать стоимость его использования? Лучше на реальном проекте.
Псевдоидиллия :D С точки зрения клиента — все описано шикарно. На практике — не решается ровным счетом ничего. Хостер столкнется все с теми же проблемами что и на ВДС: у него-то лимитированный ресурс, и соответственно либо он будет недополучать прибыль от простаивающих ресурсов (пусть и формально не принадлежащих ни одному клиентку), что отразится на конечной стоимости потребляемого ресурса для клиента. Либо опять же, возвращаемся к тому что было, цитирую: «В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства». Точнее, в случае облака, клиенту будет отказано в удовлетворении запроса по увеличению ресурса — наверное даже это не нарушит договор. Но разве это суть важно?
Резюмируя, по-моему облака нужны вовсе не для таких задач, какие им сейчас вырисовали маркетологи ;) Яркий пример — слайдербар. За почти минимальный набор ресурсов нужно выложить стоимость аренды полноценного сервера в месяц ;)
Важно. Подобный перевод выводит затраты, убытки или, наоборот, «неожиданную прибыль» из области скрытой, в область открытую. Решать задачу, сформулированную в форме «у нас есть моменты свободных ресурсов и нам надо их продать» честнее, чем продавать одни и те же ресурсы «дважды» в надежде «они там разберутся».
Я смотрю большинство комментариев упираются в «простаивающие ресурсы», и про то как за них будут платить клиенты, однако-же если говорить о развитии технологии облачных вычислений, когда будет некая стандартизация, какие-то ведущие платформы для построения такого рода систем — хостеры вполне себе смогут договариваться между собой чтобы взаимно арендовать ресурсы друг друга в интересный им временной период, если у российского хостера глухой период — ночь по московскому времени — он вполне может договориться предоставлять излишек этих ресурсов хостеру из страны где в этот момент разгар рабочего дня, и получать взамен ресурсы в период, интересный ему самому, в итоге будущее за облаками из облаков :)
Ммм… Мне кажется если это действительно может быть дёшево для хостеров, то гугл давно бы окучил этот рынок.
Так он ведь действительно уже давно окучил рынок :)
Ага. Метнуть 3 терабайта через океан, чтобы там с ними поработать 8 часов и домой. И все для того, чтобы сэкономить пару баксов клиенту.
А в чем проблема? 8 часов процессорного времени это мало? И откуда взялись волшебные 3 терабайта? :)
Разумеется, если речь идет о серверах БД и прочих прожорливых на дисковое пространство вещах, то обмен данными может убить на корню все преимущества.
Но может же быть и другой вариант. Например пользовательский сервер, раздающий статику. Или просто долгое время работающий с ограниченными ресурсами.
Хотя конечно, все это замечательно в теории, но еще есть целая куча неясных моментов.
Но может же быть и другой вариант. Например пользовательский сервер, раздающий статику. Или просто долгое время работающий с ограниченными ресурсами.
Хотя конечно, все это замечательно в теории, но еще есть целая куча неясных моментов.
Отличный подход. Но пройдет много времени… до этого момента…
Я, конечно, не инженер, а системный администратор, но, поверьте мне, эти графики и эти слова — это «живьём». То, что в _ЭТОЙ_ статье не описаны технические методы реализации означает, что я просто захотел описать задачу в общей форме.
Хотите технических деталей? Отлично, держите пример:
При изменении гостевой памяти необходимо учитывать мнение minimum_target балунинга, даже если он не используется, поскольку эта величина учитывается «пост-фактум» (можно сдвинуть dynamic_min ниже мнения этой фунции, но оно вернётся на место при первом же обращении к драйверу). В принципе, есть возможность использовать механизм балунинга с прямым контролем из dom0, однако, в этой ситуации возникает опасность race condition между функциями внутреннего и внешнего выделения памяти, так что механизм самоуправления памятью оказывается надёжнее.
Вы уверены, что если бы я это всё вывалил в статью, её было бы интересно читать?
… размерность nr_pages не соответствует размерности vm_managed_mem, но я решил эту проблему предварительным запросом величины PAGE_SHIFT на этапе ранней инициализации домена.
Хотите технических деталей? Отлично, держите пример:
При изменении гостевой памяти необходимо учитывать мнение minimum_target балунинга, даже если он не используется, поскольку эта величина учитывается «пост-фактум» (можно сдвинуть dynamic_min ниже мнения этой фунции, но оно вернётся на место при первом же обращении к драйверу). В принципе, есть возможность использовать механизм балунинга с прямым контролем из dom0, однако, в этой ситуации возникает опасность race condition между функциями внутреннего и внешнего выделения памяти, так что механизм самоуправления памятью оказывается надёжнее.
Вы уверены, что если бы я это всё вывалил в статью, её было бы интересно читать?
… размерность nr_pages не соответствует размерности vm_managed_mem, но я решил эту проблему предварительным запросом величины PAGE_SHIFT на этапе ранней инициализации домена.
Извините, но вы, когда решаете задачу транспортной развязки, оперируете вопросами устойчивости свай в почве и типом стали для двутавровых балок?
Любое описание концепции начинается с понимания того, что нужно сделать. И только потом уже идут технические детали того, как это сделать.
Наоборот — это… м… не очень правильный метод.
Любое описание концепции начинается с понимания того, что нужно сделать. И только потом уже идут технические детали того, как это сделать.
Наоборот — это… м… не очень правильный метод.
Про DDoS не стоит забывать, а могут столько вам напотреблять ресурсов
Эта проблема лежит в области математики. Та же задача — загрузка городских маршруток в час пик. Та же задача — транспортные развязки, «простаивающие» ночью. И так далее.
Задача не имеет решения.
Задача не имеет решения.
Не та же. Задача решаема «географически разнесёнными» клиентами и трансконтинентальными компаниями + распределёнными вычислениями. Там действительно можно добиться большого КПД и, следовательно, значительного снижения стоимости.
Так и представляю себе чтобы сайт Vanity Fair Magazine хостился в России чтобы заполнить ночное время российского хостера.
Так и представляю себе мастеров по ремонту холодильников, приезжающих к клиентам в три часа ночи, чтобы ехать в свободной маршрутке.
:)
Так и представляю себе мастеров по ремонту холодильников, приезжающих к клиентам в три часа ночи, чтобы ехать в свободной маршрутке.
:)
Облака эту задачу вскрывают из подспудного «как получилось, так получилось» и позволяют вывести как самостоятельную задачу. Т.е. облака — не панацея, а лишь инструмент для упорядочивания отношений заказчика и потребителя.
Дороги ночью не простаивают — их ремонтируют.
Так же по ним ездят тяжелые грузовики, которым вьезд днем внутрь ТТК запрещен.
У нас во дворе, например, мусор вывозится в 12-1 час ночи.
Это возможности использования ресурсов ночью.
Так же по ним ездят тяжелые грузовики, которым вьезд днем внутрь ТТК запрещен.
У нас во дворе, например, мусор вывозится в 12-1 час ночи.
Это возможности использования ресурсов ночью.
Я делал такой хостинг (и переезд с сервера на сервер когда ресурсов не хватает, и распределение виртуалок с упавшего сервера). Практически: оплата ресурсов процессора — почасовая, а дисков помесячная. Да, самая основная фича это автомасштабирование. Чтобы не вы «ползунок» крутили, а за вас, но в рамках которые указали вы. В России есть такие разработки, но я не знаю когда они выйдут на всеобщее обозрение.
>и переезд с сервера на сервер когда ресурсов не хватает, и распределение виртуалок с упавшего сервера
VMware DRS + HA.
VMware DRS + HA.
Сколько ж это удовольствие стоит?
нервов или денег?
3.5k$ за физический процессор (4 ядерник считается как один процессор)
Ну это мягко говоря не для всех.
Никто не спорит. Зато работает «из коробки».
Кто-то готов платить за софт, кто-то готов платить своим программистам и надеяться на их мозги и руки. И на то, что они не уйдут, как только представится возможность получать побольше.
Кто-то по принципиальным соображениям будет использовать открытый Xen или «бесплатный» Hyper-V. Кто-то посчитает деньги и будет использовать Xen или Hyper-V потому что в его случае это дешевле. А кому-то будет мало функционала и он купит VMware.
Кто-то готов платить за софт, кто-то готов платить своим программистам и надеяться на их мозги и руки. И на то, что они не уйдут, как только представится возможность получать побольше.
Кто-то по принципиальным соображениям будет использовать открытый Xen или «бесплатный» Hyper-V. Кто-то посчитает деньги и будет использовать Xen или Hyper-V потому что в его случае это дешевле. А кому-то будет мало функционала и он купит VMware.
Кстати, я когда смотрел на VMWare, то у меня не сложилось впечатления, что там всё так бело и пушисто, как хотелось бы… Например, онлайновое включение процессоров на ходу есть?
Для виртуальных машин, которые поддерживают Hot Add процессоров, такая функция есть.
включение куда?
добавить в виртуалку процессор можно, если ось поддерживает. убрать — нет.
добавить в виртуалку процессор можно, если ось поддерживает. убрать — нет.
В смысле, нет? Я обычно делаю xe vcpu-hotplug vm=… cpus=N. N любое, от 1 до числа ядер хоста.
А что мешает вынимать процессор? Тривиальная же процедура.
А что мешает вынимать процессор? Тривиальная же процедура.
отсутствие общего механизма unplug_cpu?
не знаю.
в xen можно?
какие операционки позволяют отнять цпу на ходу? про hp-ux не надо писать.
не знаю.
в xen можно?
какие операционки позволяют отнять цпу на ходу? про hp-ux не надо писать.
В зене это очень тривиальный механизм. Он как бы естественное представление того, как идёт работа с VCPU внутри PV. Работает в любом линуксе.
В остальных системах не тестил, не до того.
В остальных системах не тестил, не до того.
хм. что, у любого линукса можно вырубить на ходу процессор?
на двухпроцовой мамке просто отключить один на ходу?
на двухпроцовой мамке просто отключить один на ходу?
Э… Вообще-то xen использует паравиртуализированное ядро. Которое вполне согласно с переносимыми издевательствами, такими как изменение объёмов памяти на ходу, или появление-исчезновение процессоров.
А механизм очень простой — ядру меняют маску ядер, которые можно использовать. Т.е. где-то там, глубоко в потрохах число ядер то же, но некоторые из них строго не используются.
А механизм очень простой — ядру меняют маску ядер, которые можно использовать. Т.е. где-то там, глубоко в потрохах число ядер то же, но некоторые из них строго не используются.
что будет при запуске в вирт.машине операционки с родным ядром?
Я с HVM в зене вообще мало работал и его возможности пока что не знаю. Изучу поближе — скажу.
Вы уверены? Т.е. если я запущу её в виртуальной машине (например, в xen'е), то оно мне достанется бесплатно? Уточните, пожалуйста, действительно ли лицензирование ТОЛЬКО по ФИЗИЧЕСКИМ процессорам?
для реализации бесшовного облачного пространства необходимо привести все приложения работающие в облаке к единому виду, чтобы они наследовали общий абстрактный интерфейс. Это позволит безболезненно реализовать сколько угодно автомасштабируемое приложение, причем без вмешательства разработчиков и администраторов.
Имхо пользователь УТОНЕТ в этих настройках, большинство не знают, что и как они делают вообще.
Все бы хорошо в данной схеме resources on demand, но есть одно маленькое экономическое но.
Примем, что компании на рынке оказывают услуги одинакового качества (под качеством подразумевается соответствии реальных показателей показателям, ожидаемым клиентами).
Основной почвой для конкурирования становится ценообразование.
Чтобы снизить цену максимально, необходимо, чтобы в цену за единицу машинного времени минимально была включена цена простоя. Для этого надо сделать что? Максимально приблизить график распределения нагрузки к графику равномерного распределения.
Для этого необходимо иметь клиентов в разных часовых поясах, так как, как ни крути, максимум нагрузки все равно приходится на световой день.
Организовать подобное может только оооочень большая компания с ооочень большими первоначальными ресурсами, а таких компаний весьма ограниченное число.
Что, в свою очередь, приводит нас к мысли о монополизации. И, как следствие, диктовке весьма произвольных цен.
Под произвольными ценами я имею ввиду цены максимально, весьма слаборазличимо, приближенные к ценам закупки и эксплуатации собственного оборудования для каждой организации.
Задница?
Примем, что компании на рынке оказывают услуги одинакового качества (под качеством подразумевается соответствии реальных показателей показателям, ожидаемым клиентами).
Основной почвой для конкурирования становится ценообразование.
Чтобы снизить цену максимально, необходимо, чтобы в цену за единицу машинного времени минимально была включена цена простоя. Для этого надо сделать что? Максимально приблизить график распределения нагрузки к графику равномерного распределения.
Для этого необходимо иметь клиентов в разных часовых поясах, так как, как ни крути, максимум нагрузки все равно приходится на световой день.
Организовать подобное может только оооочень большая компания с ооочень большими первоначальными ресурсами, а таких компаний весьма ограниченное число.
Что, в свою очередь, приводит нас к мысли о монополизации. И, как следствие, диктовке весьма произвольных цен.
Под произвольными ценами я имею ввиду цены максимально, весьма слаборазличимо, приближенные к ценам закупки и эксплуатации собственного оборудования для каждой организации.
Задница?
Я бы это назвал не «задницей», а технологической проблемой. Да, она есть. Она есть у всех, у кого ресурсы доступны круглосуточно, а потребление сезонно. Начиная от гостиниц на пляжах и заканчивая водопроводом.
В отношении виртуальных машин, как мне кажется, основным решением должна быть «диверсификация» клиентов. Другими словами, вместо однотипных клиентов с одинаковым пиком нужно брать таких, у которых типы нагрузок различаются.
В принципе, эту проблему решают провайдеры, делая «ночной интернет». Они снижают линию и загружают мощности, пусть с меньшей прибылью, но более-менее полностью.
Аналогично может быть и с облаками. Продавать дешёвые ресурсы в удобное хостеру время? Почему нет? Там есть технические проблемы, и нужно искать, как их преодолевать…
В отношении виртуальных машин, как мне кажется, основным решением должна быть «диверсификация» клиентов. Другими словами, вместо однотипных клиентов с одинаковым пиком нужно брать таких, у которых типы нагрузок различаются.
В принципе, эту проблему решают провайдеры, делая «ночной интернет». Они снижают линию и загружают мощности, пусть с меньшей прибылью, но более-менее полностью.
Аналогично может быть и с облаками. Продавать дешёвые ресурсы в удобное хостеру время? Почему нет? Там есть технические проблемы, и нужно искать, как их преодолевать…
Очень понравилась часть про «ёпсы», единицы измерения доступа к IO.
Я 2 года ждал такой статьи!
На mediatemple.net есть тариф (gs) Grid-Service.
Вот там что-то среднее между облаком, виртуальным хостингом и VDS.
На месяц дают определенную квоту процессорных ресурсов и трафика.
Пользуюсь уже год — очень доволен. Перед этим перепробовал штуки 3-4 VDS.
Вот там что-то среднее между облаком, виртуальным хостингом и VDS.
На месяц дают определенную квоту процессорных ресурсов и трафика.
Пользуюсь уже год — очень доволен. Перед этим перепробовал штуки 3-4 VDS.
VDS вид сбоку — это облака IaaS.
а с PaaS, SaaS, картина всё-таки немного другая,
хотя в поалне учёта ресурсов тоже самое.
а с PaaS, SaaS, картина всё-таки немного другая,
хотя в поалне учёта ресурсов тоже самое.
Родненький munin)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Учёт ресурсов в облаках