Comments 45
Это все конечно хорошо. Но хотелось бы понимать чем мотивированы ваши цены?
В сравнении с вашим старым облаком цена выше чуть ли не в три раза. Я не пытаюсь сравнивать услуги, в новом частном облаке конечно больше плюшек, но все же.
В сравнении с вашим старым облаком цена выше чуть ли не в три раза. Я не пытаюсь сравнивать услуги, в новом частном облаке конечно больше плюшек, но все же.
В первую очередь, отметим, что в Виртуальном приватном облаке полностью дублированы все критические компоненты инфраструктуры, что существенно повысило надежность.
Кроме того, обратите, пожалуйста, внимание, что в услуге «Облачный сервер», к примеру, помимо хранения данных, оплата взималась за запросы на ввод-вывод, а также за прочитанный и записанный объем. Эти параметры нередко представляли собой значительную часть от общего потребления. Вдобавок в облаке полностью тарифицируется весь трафик (а в Виртуальном приватном облаке мы представляем 3Тб трафика бесплатно каждый месяц). Таким образом, сравнивать стоимость Облака и Виртуальное приватного облака просто некорректно без конкретных цифр среднемесячного потребления в каждом рассматриваемом случае.
Дополнительным плюсом выбранной схемы оплаты является общее увеличение прозрачности (ради которой пришлось в некотором смысле пожертвовать красивыми цифрами). Вы всегда знаете, за что платите, и всегда можете явным образом спрогнозировать затраты.
Кроме того, обратите, пожалуйста, внимание, что в услуге «Облачный сервер», к примеру, помимо хранения данных, оплата взималась за запросы на ввод-вывод, а также за прочитанный и записанный объем. Эти параметры нередко представляли собой значительную часть от общего потребления. Вдобавок в облаке полностью тарифицируется весь трафик (а в Виртуальном приватном облаке мы представляем 3Тб трафика бесплатно каждый месяц). Таким образом, сравнивать стоимость Облака и Виртуальное приватного облака просто некорректно без конкретных цифр среднемесячного потребления в каждом рассматриваемом случае.
Дополнительным плюсом выбранной схемы оплаты является общее увеличение прозрачности (ради которой пришлось в некотором смысле пожертвовать красивыми цифрами). Вы всегда знаете, за что платите, и всегда можете явным образом спрогнозировать затраты.
Цена на гигабайт SSD в восемь раз выше чем на том же амазоне. В чем разница?
Для дисковой подсистемы изначально были заложены очень высокие требования к доступности и производительности. Как следствие, например, используется трехкратное резервирование данных. Кроме того, полностью продублированы все компоненты сети передачи данных.
На сколько я помню, такие диски у AWS локальные, и ВМ с ними не поддерживают миграцию — то есть при падении хоста ВМ будет недоступна до восстановления работоспособности хоста.
Могу предложить сравнение по цене для моего мелкого сервера, который работает в старом облаке у кушает 650 рублей в месяц.
Потребление процессора в среднем около 10 % от одного ядра. В пиках больше 1 ядра не жрет, так что можно рассчитывать на 1 ядро для VPC, хотя может это и не корректно, учитывая что в старом облаке мне были доступны 8 ядер в любой момент времени, а тут будет только одно, чего может оказаться мало при резкой нагрузке.
Память. Используется MoD, но в среднем на 1 Гб висит.
Диск — 8 Гб. Запросы к диску и трафик с ним значения для сравнения цены с VPC не имеют, но так как нагрузка малая, сравнивать буду с базовым диском. Впрочем, это тоже не совсем корректно, потому что скорость диска в старом облаке явно выше скорости базового диска в новом.
Сетевой трафик — ~10 Гб, использовался 1 IP.
Этот сервер, напомню, ежемесячно обходится в среднем в 650 рублей.
Теперь рассмотрим во что обойдется аналогичный сервер (только менее резиновый) в случае VPC.
1 ядро CPU — 370 руб.
1 Гб памяти — 148 руб.
8 Гб диск — 54 руб. (для 323 руб. для быстрого)
10 Гб трафика — 0 руб.
(Цены я округлил до рублей.)
Итог — 570 рублей с базовыми дисками. Т.е. получается чутка дешевле, чем в старом облаке, но заметно медленнее, особенно (я предполагаю по диску). С быстрым диском получается 840 рублей. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.
Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные, получается даже ниже, чем в старом, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
Потребление процессора в среднем около 10 % от одного ядра. В пиках больше 1 ядра не жрет, так что можно рассчитывать на 1 ядро для VPC, хотя может это и не корректно, учитывая что в старом облаке мне были доступны 8 ядер в любой момент времени, а тут будет только одно, чего может оказаться мало при резкой нагрузке.
Память. Используется MoD, но в среднем на 1 Гб висит.
Диск — 8 Гб. Запросы к диску и трафик с ним значения для сравнения цены с VPC не имеют, но так как нагрузка малая, сравнивать буду с базовым диском. Впрочем, это тоже не совсем корректно, потому что скорость диска в старом облаке явно выше скорости базового диска в новом.
Сетевой трафик — ~10 Гб, использовался 1 IP.
Этот сервер, напомню, ежемесячно обходится в среднем в 650 рублей.
Теперь рассмотрим во что обойдется аналогичный сервер (только менее резиновый) в случае VPC.
1 ядро CPU — 370 руб.
1 Гб памяти — 148 руб.
8 Гб диск — 54 руб. (для 323 руб. для быстрого)
10 Гб трафика — 0 руб.
(Цены я округлил до рублей.)
Итог — 570 рублей с базовыми дисками. Т.е. получается чутка дешевле, чем в старом облаке, но заметно медленнее, особенно (я предполагаю по диску). С быстрым диском получается 840 рублей. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.
Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные, получается даже ниже, чем в старом, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
Забыл сразу посчитать стоимость за публичный IP, так что вношу изменения в калькуляцию и итоговый текст. :(
1 ядро CPU — 370 руб.
1 Гб памяти — 148 руб.
8 Гб диск — 54 руб. (для 323 руб. для быстрого)
10 Гб трафика — 0 руб.
1 IP — 101 руб.
(Цены я округлил до рублей.)
Итог — 681 рубль с базовыми дисками. Т.е. получается цена примерно то на то как и в старом облаке, но заметно медленнее, особенно (я предполагаю) по диску. С быстрым диском получается 941 рублей, что уже на 30 % дороже, чем старое облако. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.
Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные более-менее, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
1 ядро CPU — 370 руб.
1 Гб памяти — 148 руб.
8 Гб диск — 54 руб. (для 323 руб. для быстрого)
10 Гб трафика — 0 руб.
1 IP — 101 руб.
(Цены я округлил до рублей.)
Итог — 681 рубль с базовыми дисками. Т.е. получается цена примерно то на то как и в старом облаке, но заметно медленнее, особенно (я предполагаю) по диску. С быстрым диском получается 941 рублей, что уже на 30 % дороже, чем старое облако. Т.е. уже ощутимо дороже, но по эластичности машины только по процессору просадка. А если брать 2 ядра (для обеспечения работы на пиках), то получится совсем некрасивая цифра больше 1000.
Вот это мне и не нравится больше всего в новом облаке. Т.е. цены там нормальные более-менее, НО эластичность машины намного хуже. Т.е. отсутствует очень клевая фича — масштабирование слабой машины без участия пользователя. Понятно, что когда у вас парк машин, вы просто включаете и выключаете машины для масштабирвоания. А вот когда машина одна, нужно уже внутри нее регулировать нагрузку. С VPC это невозможно.
Все верно, новая услуга получается немного дороже для слабонагруженных машин. Это плата за резервирование сети, дисковой подсистемы и серверов управляющей прослойки (то есть в целом за увеличение надежности сервиса).
При этом для средне- и высоконагруженных серверов новая услуга становится весьма выгодной, даже если не принимать во внимание дополнительные возможности оптимизировать суммарную стоимость проекта (к примеру, локальные сети с нетарифицируемым трафиком).
При этом для средне- и высоконагруженных серверов новая услуга становится весьма выгодной, даже если не принимать во внимание дополнительные возможности оптимизировать суммарную стоимость проекта (к примеру, локальные сети с нетарифицируемым трафиком).
Не могу не отметить, что теперь недоступна для заказа услуга "облачный сервер".
Вопрос: насколько безопасно переводить облачные сервера в VPC с точки зрения возможных простоев с вашей стороны?
Облачные сервера сейчас стабильно работают, но на момент запуска услуги было много проблем. Не возникнут ли такие проблемы с VPC?
Вопрос: насколько безопасно переводить облачные сервера в VPC с точки зрения возможных простоев с вашей стороны?
Облачные сервера сейчас стабильно работают, но на момент запуска услуги было много проблем. Не возникнут ли такие проблемы с VPC?
В целом, учитывая накопленный нами за годы эксплуатации облака опыт, мы смогли построить значительно более надежную инфраструктуру, в которой каждый критически важный компонент дублирован и устранены все проблемы, которые мы встречали ранее.
Кроме того, перед выходом услуги в свет мы провели тестирование как раз с целью устранения возможных инфраструктурных проблем. Услуга длительное время предоставлялась в тестовом режиме, в течение тестирования мы выявили большое количество проблем в управляющей прослойке (в частности, исправили множество ошибок в API OpenStack), но все основные компоненты облака (которые как раз и ответственны за отсутствие сбоев) проявили себя очень хорошо.
Кроме того, перед выходом услуги в свет мы провели тестирование как раз с целью устранения возможных инфраструктурных проблем. Услуга длительное время предоставлялась в тестовом режиме, в течение тестирования мы выявили большое количество проблем в управляющей прослойке (в частности, исправили множество ошибок в API OpenStack), но все основные компоненты облака (которые как раз и ответственны за отсутствие сбоев) проявили себя очень хорошо.
Жалко, что убиваете «Облачный сервер». Для вас эта услуга, наверное, не сильно выгодна. А вот для клиента как раз наоборот — выгодна. Оплата только за фактические потребленные ресурсы — очень хорошая штука для машин с малой степенью утилизации, но с большими пиковыми нагрузками. Там было 8 ядер на машину доступны, а в VPC если машину на 8 ядер брать, это будет просто золотая машина — будет дороже более чем в 10 раз при малом потреблении. Т.е. «Облачный сервер» — это была ниша. И было бы круто ее оставить. Но, повторюсь, для вас (как и для других облачных провайдеров — я не знаю, у кого еще такое есть) скорее всего такой сервис малорентабелен. MoD тоже хорошая штука.
Не зря я в свое время задавал этот вопрос…
Вчера диск на виртуальном сервере в VPC полетел.
По сообщению службы поддержки это было связано с аппаратным сбоем, обновлением ПО и отсутствием бэкапов.
Вчера диск на виртуальном сервере в VPC полетел.
По сообщению службы поддержки это было связано с аппаратным сбоем, обновлением ПО и отсутствием бэкапов.
Да, к сожалению, мы столкнулись с очень неприятной ошибкой в программном обеспечении, которая в сочетании с аппаратными проблемами повлекла за собой потерю части данных в одном из пулов базовых дисков. Ошибку локализовали.
Отмечу, что бекапы блочных устройств на уровне инфраструктуры — это весьма больная тема, так адекватных способов получить консистентную копию просто нет.
Отмечу, что бекапы блочных устройств на уровне инфраструктуры — это весьма больная тема, так адекватных способов получить консистентную копию просто нет.
Правильно ли я понимаю, что скоро настанет час X, когда услугу Облачный сервер полностью прикроют, и уже сейчас пора думать о переезде?
Мы будем продолжать поддерживать эту услугу, пока ей продолжают пользоваться. Такой час Х, вероятно, когда-нибудь настанет, но точно не в ближайшие месяцы. И мы постараемся предложить достойную альтернативу для всех наших клиентов.
на год вас хватило )
Ресурсы, которые мы сейчас тратим на поддержку устаревшей инфраструктуры, целесообразнее потратить на улучшение актуальных услуг. Тем более, что новые услуги значительно лучше по всем параметрам.
однако.
в вашем VPC проблем сейчас больше чем с облаком:
* ipv6 нет
* все стоит дороже. особенно, если сервер простаивает
* UUID дисков в версии отличаются от тех UUID, которые видятся системой
* странные ошибки при старте.
* подозрительный процесс rundll32.exe!
* для vscale пишете всякие модули для ansible, например, а для vpc — нет. в итоге заставляете клиентов тратить еще ресурсы на написание велосипедов.
отстой, в общем.
в вашем VPC проблем сейчас больше чем с облаком:
* ipv6 нет
* все стоит дороже. особенно, если сервер простаивает
* UUID дисков в версии отличаются от тех UUID, которые видятся системой
* странные ошибки при старте.
* подозрительный процесс rundll32.exe!
* для vscale пишете всякие модули для ansible, например, а для vpc — нет. в итоге заставляете клиентов тратить еще ресурсы на написание велосипедов.
отстой, в общем.
- Сделаем (на самом деле уже сейчас есть варианты — если необходимо, напишите нам тикет);
- Очевидно, что если бы мы продолжили поддерживать «Облачный сервер», нам пришлось бы пересмотреть цены в связи со значительным подорожанием оборудования;
- Можно подробнее, желательно в тикет?
- Аналогично предыдущему. С ходу могу припомнить одну такую ошибку: образ пытается установить планировщик noop для дисков, что невозможно. Это будет исправлено после ближайшего обновления образов. Если есть другие — сообщите, мы исправим
- Этот процесс необходим для обеспечения возможности смены пароля. Хотя Вы правы, пришла пора сменить его шуточное название на что-то менее неожиданное;
- Сделаем, хотя в услуге «Облачный сервер» тем более ничего подобного не было и не могло быть.
тикеты созданы. ваша ТП знает о них.
кстати, для «Облачного сервера» автоматизация в меньшей степени нужна, тк там ресурсы и так выделялись динамически. что и было вашей киллер фичей.
а сейчас у вас обычный облачный хостинг без изюма.
кстати, для «Облачного сервера» автоматизация в меньшей степени нужна, тк там ресурсы и так выделялись динамически. что и было вашей киллер фичей.
а сейчас у вас обычный облачный хостинг без изюма.
«Изюмом» для VPC являются локальные сети, возможность загрузки собственных образов, разделение доступа и прочий функционал, который относится к платформе.
Возможность динамического выделения ресурсов (вертикального масштабирования) была удобна в некоторых простых ситуациях, но, вообще говоря, большой проект таким образом не вытянуть — в любом случае потребуется масштабировать инфраструктуру горизонтально, и, возможно, автоматизировать этот процесс.
Если Вам необходимы виртуальные машины, оптимизированные в первую очередь по стоимости, а указанные выше возможности не нужны — тогда лучше подойдет услуга Vscale. Даже с учетом возможной экономии средств на динамическом выделении ресурсов в «Облачном сервере», виртуальные машины в Vscale обойдутся дешевле. Разумеется, с поправкой на то, что цены в «Облачном сервере» не менялись несколько лет, как было указано выше.
Возможность динамического выделения ресурсов (вертикального масштабирования) была удобна в некоторых простых ситуациях, но, вообще говоря, большой проект таким образом не вытянуть — в любом случае потребуется масштабировать инфраструктуру горизонтально, и, возможно, автоматизировать этот процесс.
Если Вам необходимы виртуальные машины, оптимизированные в первую очередь по стоимости, а указанные выше возможности не нужны — тогда лучше подойдет услуга Vscale. Даже с учетом возможной экономии средств на динамическом выделении ресурсов в «Облачном сервере», виртуальные машины в Vscale обойдутся дешевле. Разумеется, с поправкой на то, что цены в «Облачном сервере» не менялись несколько лет, как было указано выше.
Ссылку бы хоть дали, на тарифы, описание услуги на сайте и т.п.
Описание и тарифы представлены на странице: selectel.ru/services/vpc
Давно слежу за темой VPC в Селектеле, пробовал бету, всё очень интересно, но:
- Не хочу
трахацца с роботамилишних сложностей с OpenStack & Co, хочу просто развернуть сервер — ранее отключенная услуга «Облачный сервер» будет включена или её закопали? - Гипервизор Xen или KVM?
- Возможно ли сейчас или в обозримом будущем заводить не просто пользователей для управления серверами в VPC, но и юрлиц-плательшиков с привязкой к определнёмм ресурсам или серверам? Пример использования — большая управляющая компания с общими проектами, а также с проектами филиалов, которые должны оплачиваться непосредственно филиалами, но управляться головной компанией.
Да, расскажите подробнее про виртуализацию. Непонятно на чем сделано.
А LBaaS (облачные балансировщики) будут?
Обязательно, и уже очень скоро. Это одна из первоочередных целей по расширению функционала Виртуального приватного облака.
и как? можно ссылки?
Этот функционал пока не готов. Мы могли бы взять функционал, предлагаемый в OpenStack из коробки, и запустить услугу раньше — но такое решение, на наш взгляд, мало пригодно для продакшна, так как нагрузку будет держать достаточно условно.
Учитывая, что отказ высокоуровневой услуги такого рода приводит к весьма печальным последствиям для инфраструктуры клиента, мы предпочитаем потратить больше времени, но сделать хороший и надежный сервис. Как только услуга будет готова, мы опубликуем новость в нашем блоге.
Учитывая, что отказ высокоуровневой услуги такого рода приводит к весьма печальным последствиям для инфраструктуры клиента, мы предпочитаем потратить больше времени, но сделать хороший и надежный сервис. Как только услуга будет готова, мы опубликуем новость в нашем блоге.
Всё-таки floating'и делаете? С софтовым NAT'ом? И какая latency получается сквозь NAT?
Делаем, но в данный момент позиционируем их как решение для ненагруженных машин (тестирование, отладка и тому подобное). Иногда плавающие адреса действительно бывают весьма удобны. На текущий момент реализация программная (аппаратная прорабатывается, но там есть свои сложности). Время отклика увеличивается относительно использования VLAN примерно на 20-30% в зависимости от вида нагрузки.
Для продакта предоставляются белые /29 в отдельном VLAN.
Для продакта предоставляются белые /29 в отдельном VLAN.
Ага, то есть всё-таки без этой хипстерской мути с nat'ом. Да, одобряю.
ЗЫ Если вы /29 per tenant предоставляете, то из этих 6 адресов один съедается шлюзом, один DHCP-агентом, остаётся 4. Не маловато?
ЗЫ Если вы /29 per tenant предоставляете, то из этих 6 адресов один съедается шлюзом, один DHCP-агентом, остаётся 4. Не маловато?
Агент умеет прописывать адреса статикой внутри машины (используя метаданные). Иными словами, можно отключить DHCP и получить 5 рабочих адресов, аналогично выделенным серверам.
metadata agent обычно же работает посредством перехвата запросов внутри namespace'а у dhcp-агента? Или у вас софтовые роутеры с l3-агентом, но без nat'а? Третий вариант — это config drive.
Все верно, агент умеет получать метаданные через config-drive, который по умолчанию включен. По сети тоже умеет (если в сети включен DHCP, либо сеть подключена к программному роутеру), но это на старте машины неприменимо по понятным причинам.
В самом начале мы пытались маршрутизировать белые подсети через программные роутеры (с выключенным snat), но отказались от этой идеи по причине недостаточной надежности. Теперь это честный VLAN, прописанный на аппаратном роутере.
В самом начале мы пытались маршрутизировать белые подсети через программные роутеры (с выключенным snat), но отказались от этой идеи по причине недостаточной надежности. Теперь это честный VLAN, прописанный на аппаратном роутере.
Так вы отдаёте настройки cloud-init через config drive? Я просто не понимаю, как такое сделать без config drive. Если это сеть, то запросы от cloud-init'а перехватываются в namespace'е l3-agent'а, либо dhcp-agent'а.
Я могу себе представить хардварный роутер, маршрутизирующий сетку для metadata, но бегать по маршрутизатору за тенантом и тонко поправлять роуты — это очень рисковано, и я не думаю, что вы такое делали.
Плюс остаётся вопрос начального появления адреса на виртуалке.
Значит, остаётся config-drive.
Я могу себе представить хардварный роутер, маршрутизирующий сетку для metadata, но бегать по маршрутизатору за тенантом и тонко поправлять роуты — это очень рисковано, и я не думаю, что вы такое делали.
Плюс остаётся вопрос начального появления адреса на виртуалке.
Значит, остаётся config-drive.
Я об этом и написал выше. Сonfig-drive по умолчанию включен для всех виртуальных машин, а наш агент умеет получать из него информацию — поэтому умеет настраивать сеть статически при первом запуске машины.
А, ок. Да, довольно раузмное решение. Единственный потенциальный неприятный момент возникнет при переключении инстанса между сетями. Насколько я знаю, текущие версии cloud-init'а не умеют обрабатывать появление/исчезновение сетевых интерфейсов на ходу, а сам neutron/nova позволяет тыкаться интерфейсами. DHCP в этой ситуации позволил бы конфигурировать(ся) динамически (без участия метаданных).
Но, для статической конфигурации инстансов вполне хорошее и стабильное решение.
Но, для статической конфигурации инстансов вполне хорошее и стабильное решение.
А есть ли в вашем новом облаке API и документация?
Да, ведь оно полностью построено на OpenStack о чем можно прочитать в блоге
Sign up to leave a comment.
Запуск услуги «Виртуальное приватное облако»