Comments 8
Логика следующая: ВМ заглушено все то время когда не нужна клиенту; когда клиент ощутил потребность в использовании ВМ — он сообщает об этом Облаку предварительно за определенный промежуток времени, зависит от SLA и настраивается; после получения запроса на предоставление ВМ — она распаковывается (высвобождается/выделяется требуемое кол-во ядер цпу, памяти, диска и т.п.) на необходимый/запрошенный период времени.
1) Пример с обработкой сезонного наплыва клиентов вообще заставляет волосы дыбом вставать — началась, значит, у нас мегараспродажа, а яндекс решил нам половину (мы же половину машин перевели в прерываемые, всё по рекомендациям) машин вырубить и клиенты начали долго ждать загрузки страниц в магазине… ну и плюнули, ушли к конкурентам или просто отложили покупку (а ради этих суток маркетологи кучу бабок угробили)… нас точно директор за бережливость похвалит?
2) ценники такие кхм… нескромные, что выгодно использовать облако только если ресурсы нужны реально пол дня в неделю… в любом другом случае дешевле взять дедик у хетцнера или традиционную VPS под тот же тимсити для небольшой команды
3) абсолютно непонятно как экономия при переводе 50% машин на прерываемый тариф может составить 35-40%, если я вот на ваш калькулятор зашёл, потыкал и увидел, что впринципе экономия от перевода машины на прерываемую — 35% (т.е. если половину машин переведу — получу 22.5% экономии)
Вообщем — приводите реальные примеры клиентов, которым вы помогли… Я согласен, что зачастую экономия от облаков есть, но она сводится к тому, что «мы лучше яндексу/амазону/МС/гуглу переплатим пару килобаксов и получим „просто БД“, чем будем на своём железе сами БД администрировать и платить админу эти деньги, а он ведь ещё попросит доп.ресурсы на бэкапирование, с него налоги надо платить, место ему предоставлять и т.д. и т.п… ну и есть риск, что он окажется некомпетентным». Может геологам есть смысл купить сразу 100 виртуалок этих, чтобы раз в пару недель за 15 часов обсчитать задачу, продать результаты заказчику и идти дальше собирать данные. А вот если у меня CI нужно гонять, то я лучше куплю копеечный дедик у хетцнера и буду его использовать дополнительно как бэкап для какого-то другого сервера, как сервер мониторинга, VPN сервер и собственно CI — программисты то каждый день работают.
Я мог и раньше горизонтально масштабироваться через Instance Groups. Причём решать когда исключительно по своему собственному усмотрению.
Вы ввели фактически значительно более низкий тариф исключительно ради возможности самим остановить что решите.
В чем бизнес? Ценовая дифференциация богатых и нищих на страхе выключнния (замечу немотивированом для тех классов целевых нагрузок, что описаны в статье)? Манипуляции какие-то…
Бесплатный сыр он сами знаете.
сервис предлагает использовать свои свободные вычислительные ресурсы по меньшей цене при условии, что эти ресурсы могут быть отозваны в любой момент. В целом прерываемые виртуальные машины работают как обычные виртуальные машины, но для них установлен ряд ограничений...
Не надо искать подвох там, где его нет. Все прозрачно. Есть сценарии использования, для которых вполне достаточно прерываемых машин. И бизнес в том, что это дает пользователям Облака возможность существенно экономить.
Вы к чему цитату привели? Разве есть возможность использовать уже занятые ресурсы? Или для реализации описанных сценариев было недостаточно уже существовавших instance groups и LB?
Сбросьте цены на обычные инстансы до уровня прерываемых без навязывание дурацких условий и облака позволят экономить ещё больше и ещё проще.
0. Берем самую дешевую VPSку (или вообще пользуемся локальной машиной).
1. Пишем скрипт, который через API стартует выключенные ВМ.
2. Засовываем скрипт в cron раз в минуту (пять, десять… в зависимости от нужд).
3. Profit!
Как можно использовать прерываемые виртуальные машины Яндекс.Облака и экономить на решении масштабных задач