«Изюмом» для VPC являются локальные сети, возможность загрузки собственных образов, разделение доступа и прочий функционал, который относится к платформе.
Возможность динамического выделения ресурсов (вертикального масштабирования) была удобна в некоторых простых ситуациях, но, вообще говоря, большой проект таким образом не вытянуть — в любом случае потребуется масштабировать инфраструктуру горизонтально, и, возможно, автоматизировать этот процесс.
Если Вам необходимы виртуальные машины, оптимизированные в первую очередь по стоимости, а указанные выше возможности не нужны — тогда лучше подойдет услуга Vscale. Даже с учетом возможной экономии средств на динамическом выделении ресурсов в «Облачном сервере», виртуальные машины в Vscale обойдутся дешевле. Разумеется, с поправкой на то, что цены в «Облачном сервере» не менялись несколько лет, как было указано выше.
Сделаем (на самом деле уже сейчас есть варианты — если необходимо, напишите нам тикет);
Очевидно, что если бы мы продолжили поддерживать «Облачный сервер», нам пришлось бы пересмотреть цены в связи со значительным подорожанием оборудования;
Можно подробнее, желательно в тикет?
Аналогично предыдущему. С ходу могу припомнить одну такую ошибку: образ пытается установить планировщик noop для дисков, что невозможно. Это будет исправлено после ближайшего обновления образов. Если есть другие — сообщите, мы исправим
Этот процесс необходим для обеспечения возможности смены пароля. Хотя Вы правы, пришла пора сменить его шуточное название на что-то менее неожиданное;
Сделаем, хотя в услуге «Облачный сервер» тем более ничего подобного не было и не могло быть.
Этот функционал пока не готов. Мы могли бы взять функционал, предлагаемый в OpenStack из коробки, и запустить услугу раньше — но такое решение, на наш взгляд, мало пригодно для продакшна, так как нагрузку будет держать достаточно условно.
Учитывая, что отказ высокоуровневой услуги такого рода приводит к весьма печальным последствиям для инфраструктуры клиента, мы предпочитаем потратить больше времени, но сделать хороший и надежный сервис. Как только услуга будет готова, мы опубликуем новость в нашем блоге.
Ресурсы, которые мы сейчас тратим на поддержку устаревшей инфраструктуры, целесообразнее потратить на улучшение актуальных услуг. Тем более, что новые услуги значительно лучше по всем параметрам.
Да, к сожалению, мы столкнулись с очень неприятной ошибкой в программном обеспечении, которая в сочетании с аппаратными проблемами повлекла за собой потерю части данных в одном из пулов базовых дисков. Ошибку локализовали.
Отмечу, что бекапы блочных устройств на уровне инфраструктуры — это весьма больная тема, так адекватных способов получить консистентную копию просто нет.
Я об этом и написал выше. Сonfig-drive по умолчанию включен для всех виртуальных машин, а наш агент умеет получать из него информацию — поэтому умеет настраивать сеть статически при первом запуске машины.
Все верно, агент умеет получать метаданные через config-drive, который по умолчанию включен. По сети тоже умеет (если в сети включен DHCP, либо сеть подключена к программному роутеру), но это на старте машины неприменимо по понятным причинам.
В самом начале мы пытались маршрутизировать белые подсети через программные роутеры (с выключенным snat), но отказались от этой идеи по причине недостаточной надежности. Теперь это честный VLAN, прописанный на аппаратном роутере.
Агент умеет прописывать адреса статикой внутри машины (используя метаданные). Иными словами, можно отключить DHCP и получить 5 рабочих адресов, аналогично выделенным серверам.
Делаем, но в данный момент позиционируем их как решение для ненагруженных машин (тестирование, отладка и тому подобное). Иногда плавающие адреса действительно бывают весьма удобны. На текущий момент реализация программная (аппаратная прорабатывается, но там есть свои сложности). Время отклика увеличивается относительно использования VLAN примерно на 20-30% в зависимости от вида нагрузки.
Для продакта предоставляются белые /29 в отдельном VLAN.
Мы будем продолжать поддерживать эту услугу, пока ей продолжают пользоваться. Такой час Х, вероятно, когда-нибудь настанет, но точно не в ближайшие месяцы. И мы постараемся предложить достойную альтернативу для всех наших клиентов.
Все верно, новая услуга получается немного дороже для слабонагруженных машин. Это плата за резервирование сети, дисковой подсистемы и серверов управляющей прослойки (то есть в целом за увеличение надежности сервиса).
При этом для средне- и высоконагруженных серверов новая услуга становится весьма выгодной, даже если не принимать во внимание дополнительные возможности оптимизировать суммарную стоимость проекта (к примеру, локальные сети с нетарифицируемым трафиком).
Для дисковой подсистемы изначально были заложены очень высокие требования к доступности и производительности. Как следствие, например, используется трехкратное резервирование данных. Кроме того, полностью продублированы все компоненты сети передачи данных.
1) В настоящий момент включение услуги «Облачный сервер» не планируется;
2) Используется гипервизор KVM;
3) Такое предложение уже было зафиксировано. В краткосрочных планах такого функционала нет, но он прекрасно впишется в общую концепцию услуги, поэтому, возможно, мы это реализуем чуть позже.
В целом, учитывая накопленный нами за годы эксплуатации облака опыт, мы смогли построить значительно более надежную инфраструктуру, в которой каждый критически важный компонент дублирован и устранены все проблемы, которые мы встречали ранее.
Кроме того, перед выходом услуги в свет мы провели тестирование как раз с целью устранения возможных инфраструктурных проблем. Услуга длительное время предоставлялась в тестовом режиме, в течение тестирования мы выявили большое количество проблем в управляющей прослойке (в частности, исправили множество ошибок в API OpenStack), но все основные компоненты облака (которые как раз и ответственны за отсутствие сбоев) проявили себя очень хорошо.
В первую очередь, отметим, что в Виртуальном приватном облаке полностью дублированы все критические компоненты инфраструктуры, что существенно повысило надежность.
Кроме того, обратите, пожалуйста, внимание, что в услуге «Облачный сервер», к примеру, помимо хранения данных, оплата взималась за запросы на ввод-вывод, а также за прочитанный и записанный объем. Эти параметры нередко представляли собой значительную часть от общего потребления. Вдобавок в облаке полностью тарифицируется весь трафик (а в Виртуальном приватном облаке мы представляем 3Тб трафика бесплатно каждый месяц). Таким образом, сравнивать стоимость Облака и Виртуальное приватного облака просто некорректно без конкретных цифр среднемесячного потребления в каждом рассматриваемом случае.
Дополнительным плюсом выбранной схемы оплаты является общее увеличение прозрачности (ради которой пришлось в некотором смысле пожертвовать красивыми цифрами). Вы всегда знаете, за что платите, и всегда можете явным образом спрогнозировать затраты.
F
Возможность динамического выделения ресурсов (вертикального масштабирования) была удобна в некоторых простых ситуациях, но, вообще говоря, большой проект таким образом не вытянуть — в любом случае потребуется масштабировать инфраструктуру горизонтально, и, возможно, автоматизировать этот процесс.
Если Вам необходимы виртуальные машины, оптимизированные в первую очередь по стоимости, а указанные выше возможности не нужны — тогда лучше подойдет услуга Vscale. Даже с учетом возможной экономии средств на динамическом выделении ресурсов в «Облачном сервере», виртуальные машины в Vscale обойдутся дешевле. Разумеется, с поправкой на то, что цены в «Облачном сервере» не менялись несколько лет, как было указано выше.
Учитывая, что отказ высокоуровневой услуги такого рода приводит к весьма печальным последствиям для инфраструктуры клиента, мы предпочитаем потратить больше времени, но сделать хороший и надежный сервис. Как только услуга будет готова, мы опубликуем новость в нашем блоге.
Отмечу, что бекапы блочных устройств на уровне инфраструктуры — это весьма больная тема, так адекватных способов получить консистентную копию просто нет.
В самом начале мы пытались маршрутизировать белые подсети через программные роутеры (с выключенным snat), но отказались от этой идеи по причине недостаточной надежности. Теперь это честный VLAN, прописанный на аппаратном роутере.
Для продакта предоставляются белые /29 в отдельном VLAN.
При этом для средне- и высоконагруженных серверов новая услуга становится весьма выгодной, даже если не принимать во внимание дополнительные возможности оптимизировать суммарную стоимость проекта (к примеру, локальные сети с нетарифицируемым трафиком).
2) Используется гипервизор KVM;
3) Такое предложение уже было зафиксировано. В краткосрочных планах такого функционала нет, но он прекрасно впишется в общую концепцию услуги, поэтому, возможно, мы это реализуем чуть позже.
Кроме того, перед выходом услуги в свет мы провели тестирование как раз с целью устранения возможных инфраструктурных проблем. Услуга длительное время предоставлялась в тестовом режиме, в течение тестирования мы выявили большое количество проблем в управляющей прослойке (в частности, исправили множество ошибок в API OpenStack), но все основные компоненты облака (которые как раз и ответственны за отсутствие сбоев) проявили себя очень хорошо.
Кроме того, обратите, пожалуйста, внимание, что в услуге «Облачный сервер», к примеру, помимо хранения данных, оплата взималась за запросы на ввод-вывод, а также за прочитанный и записанный объем. Эти параметры нередко представляли собой значительную часть от общего потребления. Вдобавок в облаке полностью тарифицируется весь трафик (а в Виртуальном приватном облаке мы представляем 3Тб трафика бесплатно каждый месяц). Таким образом, сравнивать стоимость Облака и Виртуальное приватного облака просто некорректно без конкретных цифр среднемесячного потребления в каждом рассматриваемом случае.
Дополнительным плюсом выбранной схемы оплаты является общее увеличение прозрачности (ради которой пришлось в некотором смысле пожертвовать красивыми цифрами). Вы всегда знаете, за что платите, и всегда можете явным образом спрогнозировать затраты.