Учет Ресурсов В Облаках

Слова «облако», «облачные вычисления», «облако» используются практически для чего угодно.

Новое модное словечко, модное словечко.

Мы видим «облачные антивирусы», «облачные блейд-серверы».

Даже известные производители сетевого оборудования не стесняются выпускать коммутаторы с маркировкой «для облачных вычислений».

Это вызывает инстинктивное отвращение, очень похожее на «органическую» пищу.

Любой технарь, который попытается разобраться в технологиях, лежащих в основе «облака», после нескольких часов борьбы с потоком рекламного восторга обнаружит, что эти облака — те же самые VDS, вид сбоку.

Он будет прав.

Облака в том виде, в каком их делают сейчас, — это обычные виртуальные машины.

Однако облака — это не только маркетинг и переименование в VDS. В слове «облако» (точнее, словосочетании «облачные вычисления») есть своя техническая правда.

Он не такой жалкий и восхитительно инновационный, как говорят маркетологи, но он все же есть.

Его изобрели много десятилетий назад, но только сейчас инфраструктура (в первую очередь Интернет и технологии виртуализации x86) выросла до уровня, позволяющего его массово внедрять.

Итак, сначала о причине, породившей необходимость в облаках в первую очередь: Вот как выглядит предоставляемый сервис для обычного VDS (этим графиком может быть любой ресурс: процессор, память, диск):

Учет ресурсов в облаках

Обратите внимание: это недельный график.

Существующие технологии временного увеличения лимита потребления ресурсов (burst, Grace period) не способны решить эту проблему на столь длительных интервалах.

Те.

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

Вторая проблема — посмотрите на огромные интервалы (синий цвет), когда за ресурсы действительно нужно было заплатить, но их нельзя было использовать.

Виртуальной машине ночью просто не нужно столько ресурсов.

Она бездействует. И несмотря на это, собственник платит полностью.

Возникает проблема: человек вынужден заказывать больше ресурсов, чем нужно в среднем, чтобы без проблем пережить пики.

В остальное время ресурсы простаивают. Провайдер видит, что сервер не загружен и начинает продавать больше ресурсов, чем у него есть (это называется «перепродажа»).

В какой-то момент, например, из-за пиковой нагрузки на нескольких клиентов, провайдер нарушает свои обязательства.

Обещал 70 людям 1 ГГц - а у него всего 40 (2,5*16 ядер).

Не хорошо.

Продавать полосу честно (без перепродажи) невыгодно (да и цены нерыночные).

Oversell – снизить качество услуги, нарушить условия договора.

Эта проблема не связана с VDS или виртуализацией, это общий вопрос: как честно продать простаивающие ресурсы? Идея «облачных вычислений» стала ответом на эту проблему.

Хотя эти слова модны, их основа уходит корнями во времена больших мэйнфреймов, когда продавалось компьютерное время.

Облачные вычисления делают то же самое — вместо лимитов и квот, которые выплачиваются независимо от фактического потребления, пользователям предоставляется возможность использовать ресурсы без ограничений, с оплатой за реальное потребление (и только за то, что было фактически использовано).

В этом суть «облака».

Вместо продажи «диск 500 МГц 500 МБ памяти 3 ГБ» пользователю (точнее, его виртуальной машине) предоставляется все, что ему нужно.

Столько сколько нужно.

У вас пик потребления ресурсов перед 8 марта, а потом низкий сезон? Или вы просто не можете предсказать, когда у вас будут эти пики? Вместо поиска компромисса между лагами и деньгами на ветер предлагается другая модель оплаты: вы платите за то, что израсходовано.

Учет ресурсов Учитывается машинное время (его можно считать в тиках, но идеологически правильнее делать по старому стилю: считать секунды машинного времени), конечно, если у вас 3 ядра молотили при 50% нагрузке, то это составляет полторы секунды машинного времени в секунду.

Если ваша загрузка 3%, то в минуту вы потратите всего 2 секунды компьютерного времени.

Память выделяется «по требованию» — и ограничена только возможностями хостера и вашей жадностью.

Оплата тоже повременная — столько стоит мегабайт памяти в секунду.

(собственно на старых VDS было так, платил за «мегабайты в месяц», но они большую часть времени простаивали).

Дисковое пространство также выделяется по требованию – оплата помегабайтно в секунду.

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

Дисковое пространство Дисковое пространство — сложный ресурс: речь идет не только о «хранилище», но и о «доступе».

Оплата берется и за потребляемое пространство (мегабайт-секунды), и за iops (штуки), и за объем записанных и прочитанных данных.

Каждый из компонентов стоит денег.

Поскольку за один ресурс деньги берутся три раза, то цена фактически делится на три.

И вот здесь всё становится интереснее: человек, который выложил файлы, но не трогает их, платит меньше, чем тот, кто активно использует их для доставки клиенту.

И использование может быть разным - читать десять раз по мегабайту" и "читать десять раз по килобайту" - разница есть.

Или наоборот читать файл размером 10 МБ за 10 запросов на мегабайт, или долго и больно читать по килобайту в случайном порядке, да еще и вперемешку с записью.

Модель оплаты по фактическому потреблению является наиболее справедливой как для потребителя, так и для поставщика услуг: потребитель платит только за то, что он потребил, а поставщик больше не испытывает раздражения от «толстых» клиентов, съедающих все ресурсы.

Потребленный ресурс – это проданный ресурс.

Более того, действует и обратный принцип: ресурс, который не потребляется, не оплачивается.

Если хостер не смог обеспечить всех процессором «как надо» (произошёл затор), то тривиальным путём, без суда и нагоняев, без долгой переписки, он автоматически теряет деньги, потому что продал меньше, чем хотели купить.

Клиенты хоть и будут чувствовать дискомфорт из-за перегруженности, но, по крайней мере, получат удовлетворение — за это время они будут платить меньше.

У этой проблемы перегруженности есть еще более красивое, облачное решение, но об этом в следующий раз.



БАРАН

Вот, например, график использования памяти.

Обратите внимание — оранжевые области — это области, которые будут не просто «тормозить», а области, в которых oom_killer будет работать.

Со всеми вытекающими.

Если бы оплата основывалась на потреблении, то эти пики были бы не такими дорогими, но позволили бы без проблем решить «пиковую» ситуацию.



Учет ресурсов в облаках

И снова посмотрите, опять есть огромные простаивающие ресурсы, за которые совершенно не хочется платить.

Ведь эта память не используется? Нет. Зачем тогда за это платить? Облака позволяют вам забирать память, когда вам это нужно.

И отдать обратно, когда память уже не нужна.

И в отличие от других ресурсов (памяти/производительности диска), нехватка которых приводит лишь к некоторому замедлению работы, память является жизненно важным ресурсом.

Память не дали - кто-то видел страницу счастья от nginx "Плохой шлюз" или просто ничего не увидел, потому что соединение закрылось.



Сеть

Кстати, этот принцип применим и к сети.

Мы все привыкли к безлимитному доступу дома (безлимитный доступ на фиксированной максимальной скорости).

Но работа – это не дом.

И за стеснённую 30Мб платить жалко, а за 100Мб дорого (см.

первый график).

Или, возможно, есть еще отдельные пики до 500 МБ, но редко? Что делать в такой ситуации? Дешевый трафик стоит дешевле и обеспечивает лучшее качество обслуживания, чем полоса (безлимит), зажатая в узкие тиски экономии при том же реальном объеме трафика в месяц.

Большинство людей привыкли к мысли, что «платный трафик стоит дорого» (спасибо опсосам).

А если нет? Что делать, если гигабайт трафика стоит 80 копеек? (так на три порядка дешевле?) Зачем вам платить за трафик сотни (тысячи?) рублей, если ваша виртуальная машина потребляет менее ста рублей? Кстати, то же самое касается и локальной сети.

Да, гигабайт трафика там будет стоить копейки.

Но он существует, верно? Оно потребляет ресурсы, ради него ставятся быстрые коммутаторы.

Значит, за это надо платить.



Искусственные облака

Иногда для «обычных VDS» пользователю предоставляют возможность устанавливать ограничения на потребление ресурсов.

Мол, 500 МГц мало, поставьте на 600, вот вам плавный ползунок, пределы ставьте сами.

Однако это не решение проблемы.

Ну да, вместо 500 ставим 600 - и что получаем? Тот же VDS, с теми же (или даже большими) зонами простоя, за которые мы платим — но которых не получаем.

Мы не можем точно знать, сколько ресурсов необходимо серверу, обслуживающему клиентов (количество которых мы не можем предсказать).

Таким образом, оплата «по факту потребления» оказывается более справедливой.

Можно привести такую аналогию: есть автомобили с карбюратором.

И рукоятка дросселя.

Которому нужно регулировать подачу топлива.

Переполнено? Вы недолили? Все идет не очень хорошо.

А есть автомобили с инжекторными двигателями, которые берут столько бензина, сколько им нужно.

В этом разница между облаком и VDS с педальным управлением.

Бензина столько не надо - его продолжают лить в двигатель (за ваш счет!).

Вы ползете на гору и хотелось бы добавить - но вам этого не дают. Точнее, дают, но руками, руками.

Отрываясь от аналогии: в машине ты хотя бы сидишь за рулем.

А в VDS вы круглосуточно следите за потреблением ресурсов?

Предприятие и хостеры

Может показаться, что все написанное касается хостеров.

Это не верно.

Разница позиции хостера и администратора собственного парка корпоративных серверов в том, что провайдер оперирует деньгами, а администратор — имеющимися ресурсами.

Все соображения, касающиеся использования общих ресурсов, также применимы к серверам в «частном» облаке.

Вместо резервирования памяти методом квадратно-кластерного использования использование общего пула обеспечивает гораздо большую плотность размещения виртуальных машин и решает проблему «ой, sql сбился, я неправильно установил лимит памяти».



Идеальное облако

Попробую расписать, какими должны быть ресурсы в идеальном облаке:
  • Ресурсы процессора по запросу.

    Возможно с динамическим подключением дополнительных ядер, автоматической миграцией виртуальной машины на более свободный/быстрый сервер, если ресурсов текущего сервера станет недостаточно.

    Оплата процессорного времени за тик (или секунды занятости процессора).

  • Неограниченный объем памяти, оплата которого осуществляется по факту потребления и освобождения (учет в килобайт-секундах или кратных им).

  • Дисковое пространство учитывается по тем же принципам: оплата в гигабайт-часах.

    Я поставил терабайтный архив за два часа и заплатил за 2000 гигабайт часов.

    (главное не забыть стереть лишнее) Поставил на день 2Гб и заплатил за 48 гигабайт часов.

  • Дисковые операции - за штуку, дисковый трафик - за гигабайт
  • Сеть безлимитная, скорость гигабитная, а то и десятки.

    Оплата по трафику.

  • Полное законное право отключить виртуальную машину и платить только за «мертвый груз» содержимого ее дисков.

  • Возможность экспортировать/импортировать ваши виртуальные машины
  • Возможность иметь несколько виртуальных машин на одной учетной записи
  • Графики потребления ресурсов в реальном или близком к реальному времени
Теги: #Виртуализация #Облачные вычисления
Вместе с данным постом часто просматривают: