Слова «облако», «облачные вычисления», «облачный» используются для чего попало. Новое модное слово, buzzword. Мы видим «облачные антивирусы», «облачные блейд-сервера». Даже именитые вендоры сетевого оборудования, не стесняются выставлять коммутаторы с ярлыком «for cloud computing». Это вызывает инстинктивную неприязнь, примерно, как «органические» продукты питания.
Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.
Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.
Итак, сначала о причине, которая вообще породила потребность в облаках:
Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):
Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.
Вторая проблема — посмотрите на огромные интервалы (голубой цвет), когда ресурсы, фактически, пришлось оплатить, но использовать не удалось. Виртуальной машине ночью просто не нужно столько ресурсов. Она простаивает. И не смотря на это — владелец платит по полной.
Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.
Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.
Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?
Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.
Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».
Вместо того, чтобы продавать «500МГц 500Мб памяти 3Гб диска», пользователю (точнее, его виртуальной машине), дают всё, что ей нужно. Столько, сколько нужно.
У вас пик потребления ресурсов перед 8 марта, а потом мёртвый сезон? Или вы просто не можете предсказать, когда у вас будут эти пики? Вместо того, чтобы искать компромисс между лагами и деньгами на ветер, предлагается иная модель оплаты: оплачивается то, что было потреблено.
Учитывается машинное время (его можно считать в тиках, но идейно правильнее это делать в старинном стиле: считать секунды машинного времени), разумеется, если у вас молотило 3 ядра с 50% загрузкой, это полторы секунды машинного времени в секунду. Если же у вас загрузка 3%, то за минуту вы потратите лишь 2с машинного времени.
Память выделяется «по требованию» — и ограничивается только возможностями хостера и вашей жадностью. Оплачивается она тоже на повременной основе — мегабайт памяти стоит столько-то в секунду. (на самом деле на старых VDS так и было, вы оплачивали «мегабайты в месяц», но они большую часть времени простаивали).
Место на диске выделяется тоже по требованию — оплата за мегабайт в секунду. Если вам потребовалось место для временного дампа на терабайт, вам не нужно оплачивать терабайт на целый месяц — достаточно на час-полтора (главное не забыть потом стереть лишнее).
Дисковое пространство — сложный ресурс: это не только «хранение», но и «доступ». Оплата берётся и за потреблённое место (мегабайто-секунды), и за иопсы (штуки), и за объём записанного-считанного. Каждая из составляющих стоит денег. Поскольку за один ресурс деньги берутся трижды, то цена, фактически, делится на три.
И вот тут уже начинается интересное: человек, который положил файлы, но не трогает их, платит меньше, чем тот, кто их активно использует для отдачи клиенту. И использование бывает разное — десять раз прочитал по мегабайту" и «десять раз прочитал по килобайту» — есть разница. Или, наоборот — прочитал файл в 10Мб за 10 запросов по мегабайту, или же долго и мучительно читал по килобайту в произвольном порядке, да ещё и вперемешку с записью…
Модель с оплатой по фактическому потреблению — самая честная, и для потребителя, и для поставщика услуг: потребитель платит только за то, что потребил, поставщик же больше не испытывает раздражения от «жирных» клиентов, которые выжирают все ресурсы. Потреблённый ресурс — проданный ресурс. Более того, действует и обратный принцип: не потреблённый ресурс не оплачивается. Если хостер не сумел обеспечить всех процессором «по потребности» (возник затор), то он банальным образом, без суда и ругани, без долгой переписки, автоматически теряет деньги, потому что было продано меньше, чем хотели купить. Клиенты же, хоть и ощутят неприятность из-за затора, но получат, хотя бы, сатисфакцию — они заплатят за это время меньше… У этой проблемы затора есть ещё более красивое, облачное решение, но о нём в следующий раз.
Вот, например, график использования памяти. Обратите внимание — оранжевые области — это области, которые не просто «будут тормозить», но области, в которых сработает oom_killer. Со всеми вытекающими. Если бы оплата была по потреблению, то эти пики бы стоили бы не так уж дорого, зато позволили бы решить «пиковую» ситуацию без каких-либо проблем.
И опять посмотрите, опять огромные простаивающие ресурсы, которые совершенно не хочется оплачивать. Ведь эта память не используется? Нет. Зачем же тогда за неё платить?
Облака позволяют брать память тогда, когда она нужна. И отдавать назад, когда память перестала быть нужной. И в отличие от остальных ресурсов (память/производительность диска), нехватка которых приводит лишь к некоторому замедлению, память — жизненно-важный ресурс. Не дали памяти — кто-то увидел страничку счастья от nginx'а «Bad gateway» или просто ничего не увидел, потому что соединение закрыли…
Кстати, этот принцип касается и сети. Мы все привыкли дома к анлиму (неограниченному доступу на фиксированной максимальной скорости). Но работа — не дом. И платить за тесную полосу в 30Мб жалко, за 100Мб — дорого (см первый график). А, возможно, там дальше единичные пики под 500Мб, но редко? Как быть в такой ситуации? Дешёвый трафик обходится дешевле и предоставляет качество сервиса лучше, чем зажатая в узкие тиски экономии полоса (анлим) с тем же фактическим объёмом трафика в месяц. Большинство людей привыкли, что «платный трафик это дорого» (спасибо опсосам). А если нет? А если гигабайт трафика будет стоить копеек 80? (этак на три порядка дешевле?)
Зачем вам платить сотни (тысячи?) рублей за трафик, если ваша виртуальная машина съест меньше, чем на сто рублей?
Кстати, то же касается и локальной сети. Да, там гигабайт трафика будет стоить копейки. Но ведь он есть? Он потребляет ресурсы, ради него ставятся быстрые коммутаторы… Значит, он должен быть оплачен.
Иногда, для «обычных VDS» предоставляют возможность пользователю самому задать лимиты на потребление ресурсов. Мол, не хватает 500МГц, поставь 600, вот тебе плавный ползунок, выстави лимиты себе сам. Однако, это не решение проблемы. Ну да, вместо 500 мы ставим 600 — и что получаем? Тот же VDS, с теми же (а то и большими) областями простоя, за которые мы платим — но которые мы не получаем. Мы не можем точно знать, сколько нужно ресурсов для сервера, который обслуживает клиентов (число которых мы не можем предсказать). Таким образом, оплата «по факту потребления» оказывается более справедливой.
Можно назвать такую аналогию: есть машины, у которых карбюратор. И ручка подсоса. Которой нужно регулировать подачу топлива. Перелил? Недолил? Плохо едет. А есть машины с инжекторными двигателями, которые сами берут столько бензина, сколько им нужно.
Вот это и есть разница между облаком и VDS с педальным приводом. Вам не нужно столько бензина — в двигатель льют и льют (за ваш счёт!). Вы ползёте в гору и вам бы добавить — а не дают. Точнее дают, но руками, руками… Отрываясь от аналогии: в машине вы, хотя бы, за рулём сидите. А в VDS — вы круглосуточно мониторите потребление ресурсов?
Может показаться, что всё написанное, касается хостеров. Это не так. Разница между положением хостера и администратором своего собственного парка серверов предприятия в том, что провайдер оперирует деньгами, а администратор — доступными ресурсами. Все рассуждения, касающиеся общего использования ресурсов применимы и к серверам в «частном» облаке. Вместо резервирования памяти квадратно-гнездовым методом, использование общего пула даёт куда большую плотность размещения виртуальных машин, решает проблемы «ой, sql упал, я лимит памяти неправильно выставил».
Попробую выписать, какими должны быть ресурсы в идеальном облаке:
Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку. Он будет прав. Облака, в том виде, как их делают сейчас — обычные виртуальные машины.
Однако, облака, это не только маркетинг и переименованные VDS. У слова «облако» (или, точнее у фразы «облачные вычисления») есть есть своя техническая правда. Она не такая патетичная и восхитительно-инновационная, как рассказывают маркетологи, но она всё-таки есть. Придумана она была много десятилетий назад, но только сейчас инфраструктура (в первую очередь, Интернет и технологии виртуализации x86) доросла до уровня, который позволяет реализовать её в массовом порядке.
Итак, сначала о причине, которая вообще породила потребность в облаках:
Вот как выглядит предоставляемая услуга для обычного VDS (на месте этого графика может быть любой ресурс: процессор, память, диск):
Обратите внимание: это недельный график. Существующие технологии временного увеличения лимита потребления ресурса (burst, grace period) не способны решить эту проблему на таких длинных интервалах. Т.е. машина недополучает ресурсы тогда, когда они ей больше всего нужны.
Вторая проблема — посмотрите на огромные интервалы (голубой цвет), когда ресурсы, фактически, пришлось оплатить, но использовать не удалось. Виртуальной машине ночью просто не нужно столько ресурсов. Она простаивает. И не смотря на это — владелец платит по полной.
Возникает проблема: человек вынужден заказывать ресурсов больше, чем нужно в среднем, для того, чтобы переживать без проблем пики. В остальное время ресурсы простаивают. Провайдер видит, что сервер не нагружен, начинает продавать ресурсов больше, чем есть (это называют «оверселл»). В какой-то момент, например, из-за пика нагрузки на нескольких клиентов, провайдер нарушает свои обязательства. Он обещал 70 человекам по 1Ггц — но у него есть только 40 (2.5*16 ядер). Нехорошо.
Продавать полосу честно (без оверселла) невыгодно (и цены нерыночные получаются). Оверселлить — снижать качество сервиса, нарушать условия договора.
Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продавать простаивающие ресурсы?
Именно ответом на эту проблему и стала идея «облачных вычислений». Слова хоть и модные, но своей основой уходящие во времена больших мейнфреймов, когда продавалось машинное время.
Облачные вычисления делают то же самое — вместо лимитов и квот, которые оплачиваются вне зависимости от реального потрбления, пользователям предоставляется возможность использовать ресурсы без ограничения, с оплатой реального потребления (и только того, что было реально использовано). Это и есть суть «облака».
Вместо того, чтобы продавать «500МГц 500Мб памяти 3Гб диска», пользователю (точнее, его виртуальной машине), дают всё, что ей нужно. Столько, сколько нужно.
У вас пик потребления ресурсов перед 8 марта, а потом мёртвый сезон? Или вы просто не можете предсказать, когда у вас будут эти пики? Вместо того, чтобы искать компромисс между лагами и деньгами на ветер, предлагается иная модель оплаты: оплачивается то, что было потреблено.
Учёт ресурсов
Учитывается машинное время (его можно считать в тиках, но идейно правильнее это делать в старинном стиле: считать секунды машинного времени), разумеется, если у вас молотило 3 ядра с 50% загрузкой, это полторы секунды машинного времени в секунду. Если же у вас загрузка 3%, то за минуту вы потратите лишь 2с машинного времени.
Память выделяется «по требованию» — и ограничивается только возможностями хостера и вашей жадностью. Оплачивается она тоже на повременной основе — мегабайт памяти стоит столько-то в секунду. (на самом деле на старых VDS так и было, вы оплачивали «мегабайты в месяц», но они большую часть времени простаивали).
Место на диске выделяется тоже по требованию — оплата за мегабайт в секунду. Если вам потребовалось место для временного дампа на терабайт, вам не нужно оплачивать терабайт на целый месяц — достаточно на час-полтора (главное не забыть потом стереть лишнее).
Дисковое пространство
Дисковое пространство — сложный ресурс: это не только «хранение», но и «доступ». Оплата берётся и за потреблённое место (мегабайто-секунды), и за иопсы (штуки), и за объём записанного-считанного. Каждая из составляющих стоит денег. Поскольку за один ресурс деньги берутся трижды, то цена, фактически, делится на три.
И вот тут уже начинается интересное: человек, который положил файлы, но не трогает их, платит меньше, чем тот, кто их активно использует для отдачи клиенту. И использование бывает разное — десять раз прочитал по мегабайту" и «десять раз прочитал по килобайту» — есть разница. Или, наоборот — прочитал файл в 10Мб за 10 запросов по мегабайту, или же долго и мучительно читал по килобайту в произвольном порядке, да ещё и вперемешку с записью…
Модель с оплатой по фактическому потреблению — самая честная, и для потребителя, и для поставщика услуг: потребитель платит только за то, что потребил, поставщик же больше не испытывает раздражения от «жирных» клиентов, которые выжирают все ресурсы. Потреблённый ресурс — проданный ресурс. Более того, действует и обратный принцип: не потреблённый ресурс не оплачивается. Если хостер не сумел обеспечить всех процессором «по потребности» (возник затор), то он банальным образом, без суда и ругани, без долгой переписки, автоматически теряет деньги, потому что было продано меньше, чем хотели купить. Клиенты же, хоть и ощутят неприятность из-за затора, но получат, хотя бы, сатисфакцию — они заплатят за это время меньше… У этой проблемы затора есть ещё более красивое, облачное решение, но о нём в следующий раз.
Оперативная память
Вот, например, график использования памяти. Обратите внимание — оранжевые области — это области, которые не просто «будут тормозить», но области, в которых сработает oom_killer. Со всеми вытекающими. Если бы оплата была по потреблению, то эти пики бы стоили бы не так уж дорого, зато позволили бы решить «пиковую» ситуацию без каких-либо проблем.
И опять посмотрите, опять огромные простаивающие ресурсы, которые совершенно не хочется оплачивать. Ведь эта память не используется? Нет. Зачем же тогда за неё платить?
Облака позволяют брать память тогда, когда она нужна. И отдавать назад, когда память перестала быть нужной. И в отличие от остальных ресурсов (память/производительность диска), нехватка которых приводит лишь к некоторому замедлению, память — жизненно-важный ресурс. Не дали памяти — кто-то увидел страничку счастья от nginx'а «Bad gateway» или просто ничего не увидел, потому что соединение закрыли…
Сеть
Кстати, этот принцип касается и сети. Мы все привыкли дома к анлиму (неограниченному доступу на фиксированной максимальной скорости). Но работа — не дом. И платить за тесную полосу в 30Мб жалко, за 100Мб — дорого (см первый график). А, возможно, там дальше единичные пики под 500Мб, но редко? Как быть в такой ситуации? Дешёвый трафик обходится дешевле и предоставляет качество сервиса лучше, чем зажатая в узкие тиски экономии полоса (анлим) с тем же фактическим объёмом трафика в месяц. Большинство людей привыкли, что «платный трафик это дорого» (спасибо опсосам). А если нет? А если гигабайт трафика будет стоить копеек 80? (этак на три порядка дешевле?)
Зачем вам платить сотни (тысячи?) рублей за трафик, если ваша виртуальная машина съест меньше, чем на сто рублей?
Кстати, то же касается и локальной сети. Да, там гигабайт трафика будет стоить копейки. Но ведь он есть? Он потребляет ресурсы, ради него ставятся быстрые коммутаторы… Значит, он должен быть оплачен.
Фальшивые облака
Иногда, для «обычных VDS» предоставляют возможность пользователю самому задать лимиты на потребление ресурсов. Мол, не хватает 500МГц, поставь 600, вот тебе плавный ползунок, выстави лимиты себе сам. Однако, это не решение проблемы. Ну да, вместо 500 мы ставим 600 — и что получаем? Тот же VDS, с теми же (а то и большими) областями простоя, за которые мы платим — но которые мы не получаем. Мы не можем точно знать, сколько нужно ресурсов для сервера, который обслуживает клиентов (число которых мы не можем предсказать). Таким образом, оплата «по факту потребления» оказывается более справедливой.
Можно назвать такую аналогию: есть машины, у которых карбюратор. И ручка подсоса. Которой нужно регулировать подачу топлива. Перелил? Недолил? Плохо едет. А есть машины с инжекторными двигателями, которые сами берут столько бензина, сколько им нужно.
Вот это и есть разница между облаком и VDS с педальным приводом. Вам не нужно столько бензина — в двигатель льют и льют (за ваш счёт!). Вы ползёте в гору и вам бы добавить — а не дают. Точнее дают, но руками, руками… Отрываясь от аналогии: в машине вы, хотя бы, за рулём сидите. А в VDS — вы круглосуточно мониторите потребление ресурсов?
Энтерпрайз и хостеры
Может показаться, что всё написанное, касается хостеров. Это не так. Разница между положением хостера и администратором своего собственного парка серверов предприятия в том, что провайдер оперирует деньгами, а администратор — доступными ресурсами. Все рассуждения, касающиеся общего использования ресурсов применимы и к серверам в «частном» облаке. Вместо резервирования памяти квадратно-гнездовым методом, использование общего пула даёт куда большую плотность размещения виртуальных машин, решает проблемы «ой, sql упал, я лимит памяти неправильно выставил».
Идеальное облако
Попробую выписать, какими должны быть ресурсы в идеальном облаке:
- Процессорные ресурсы — по запросу. Возможно, с динамическим подключением дополнительных ядер, автоматической миграцией виртуальной машины на более свободный/быстрый сервер, если ресурсов текущего сервера начинает не хватать. Оплата процессорного времени за тики (или секунды занятости процессора).
- Нелимитируемый объём памяти, который оплачивается по факту потребления-освобождения (учёт в килобайто-секундах или кратных им единицах).
- Дисковое пространство, учитываемое по тем же принципам: оплата в гигабайто-часах. Положил терабайтный архив на два часа — оплатил 2000 гигабайто-часов. (главное, не забыть лишнее стереть) Положил 2Гб на сутки — оплатил 48 гигабайто-часов.
- Дисковые операции — поштучно, дисковый трафик — погигабайтно
- Сеть нелимитируется, скорость в гигабит, а то в десятку. Оплата по трафику.
- Полное законное право выключить виртуальную машину и платить только за «лежащее мёртвым грузом» содержимое её дисков
- Возможность экспортировать/импортировать свои виртуальные машины
- Возможность иметь несколько виртуальных машин на одном аккаунте
- Графики потребления ресурсов в реальном или близком к нему времени
