company_banner

Новая услуга: виртуальное приватное облако

    Open Stack

    Главная новость этого месяца: мы запустили публичное тестирование новой услуги — «Виртуальное приватное облако». Любой пользователь может получить в свое распоряжение собственную облачную инфраструктуру, гибкую, управляемую, легко масштабируемую и способную справиться с любыми нагрузками.

    О возможностях и преимуществах нового сервиса мы подробно расскажем ниже.


    Введение


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

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

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

    Сфера применения публичных облаков в корпоративной практике также весьма ограничена: на их основе можно создать корпоративный портал или организовать документооборот для небольшой компании, но в качестве среды для развертывания сложных бизнес-приложений их уже использовать сложно — возникают вопросы, связанные с разграничением прав между сотрудниками компании или удобством планирования. Вполне типична ситуация, когда фактическим владельцем учетной записи является один сотрудник, планированием использования ресурсов занимается другой, а настройкой серверов — вообще целый отдел. Доступ в облако при этом возможен только от имени того пользователя, на которого зарегистрирован аккаунт; для корпоративных пользователей это по вполне понятным причинам неприемлемо.

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

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

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

    Кроме того, вертикальное масштабирование в облаке иногда может оказаться очень невыгодным с финансовой точки зрения: оплата по принципу pay-as-you-go (т.е. по фактическому потреблению) при незапланированных нагрузках может обернуться весьма неприятными сюрпризами. Для корпоративных клиентов такой принцип оплаты существенно затрудняет планирование расходов — в большинстве случаев сложно предсказать, какой объем ресурсов будет потреблен машиной, работающей под реальной нагрузкой.

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

    Аргументом в пользу горизонтального масштабирования является широкое распространение систем управления конфигурацией, таких, как Puppet или Chef. Эти инструменты позволяют практически полностью автоматизировать добавление новых компонентов в кластер, тем самым наращивая его совокупную производительность без дополнительных затрат труда.

    Виртуальное приватное облако


    Технологии развиваются, требования к облакам растут, но на российском рынке пока что не появлялось продукта, в котором были бы учтены все актуальные тенденции. Работая над нашим новым сервисом, мы старались сфокусироваться на потребностях бизнеса и обеспечить максимальную гибкость и возможность построить облачное окружение, адаптируемое под любые задачи. Новая услуга называется «Виртуальное приватное облако».

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

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

    Перспективным вариантом использования сервиса является реселлинг. Реселлер может создавать проекты и передавать своим клиентам доступ к ним. Таким образом, клиент реселлера может даже не знать, что его виртуальные машины запускаются на базе нашей инфраструктуры — он работает со своим проектом с помощью отдельной внешней панели управления.

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

    Чтобы реализовать все описанные возможности, нам требовалась платформа с публичным API. Наш выбор пал на OpenStack — платформу, де-факто давно уже являющуюся стандартом для построения современных облачных сервисов.

    OpenStack: краткая справка


    OpenStack представляет собой совокупность сервисов с открытым исходным кодом для построения публичных и частных облаков.

    Работа над OpenStack началась в 2010 году, когда был объединен код двух платформ: Nebula (так называлась платформа, создававшаяся специально для NASA) и RackSpace CloudFiles (разработка компании RackSpace). Вскоре интерес к новому проекту стали проявлять разработчики различных дистрибутивов Linux: уже в 2011 году OpenStack стал основной облачной платформой для Ubuntu Server и Ubuntu Enterprise Cloud. В том же году OpenStack стал использоваться и в OC Debian. В 2012 году к проекту присоединилась компания RedHat и начала работу над собственным дистрибутивом.

    Cегодня в работе над проектами OpenStack принимают участие около 9000 индивидуальных разработчиков и 250 организаций, в том числе и такие известные компании, как IBM, EMC, HP, Canonical, Yahoo! и другие.

    OpenStack имеет модульную архитектуру и включает следующие компоненты (перечисляем только наиболее важные компоненты — на самом деле их гораздо больше):
    • Nova — контроллер для управления виртуальными машинами. Он выполняет такие функции, как обработка запросов на создание виртуальных машин, контроль работоспособности, распределение нагрузки на физические машины, реакция на сбои и т.п.;
    • Neutron — компонент для управления сетями. С его помощью пользователи могут определять сети, подсети и маршрутизаторы и конфигурировать внутреннюю топологию сетевой инфраструктуры. Neutron поддерживает механизм плавающих (floating) IP-адресов, которые можно динамически выделять виртуальным машинам;
    • Cinder — сервис блочных устройств. Обеспечивает функциональность дисков виртуальных машин;
    • Glance — компонент для управления образами виртуальных машин. Образы Glance используются для быстрого и согласованного развертывания новых серверов;
    • Keystone — модуль авторизации; ключевой компонент, обеспечивающий единую точку авторизации пользователей во всех сервисах;
    • Heat — модуль, отвечающий за оркестрацию. С его помощью можно автоматически разворачивать виртуальные серверы и приложения на базе шаблонов;
    • Swift — модуль объектного хранения данных, который мы уже на протяжении нескольких лет используем в нашей услуге «Облачное хранилище».

    Взаимодействие компонентов можно представить в виде следующей схемы:

    компоненты OpenStack

    Почему OpenStack стал, как это уже было сказано выше, фактическим стандартом для построения современных облачных сервисов? Этому способствовали в первую очередь следующие факторы:
    • Открытый исходный код, предоставляющий широкие возможности для доработки и усовершенствования существующих сервисов;
    • Гибкость. Облачная инфраструктура на основе OpenStack получается гибкой и управляемой. Настроенная система выдерживает любые изменения дизайна и в случае необходимости может быть легко переконфигурирована, к примеру, если планируется использование другой системы хранения данных;
    • Широкие возможности интеграции. OpenStack не является замкнутой системой и может взаимодействовать с другими продуктами. Доступна поддержка различных систем виртуализации, существуют плагины для подключения разнообразных устройств хранения данных и сетевого оборудования.

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

    Как устроено новое облако


    VPC схема

    Домены и проекты


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

    Ресурсы и квоты


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

    Управление доступом


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

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

    Гибкое создание виртуальных машин


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

    Сетевые подключения


    Виртуальные машины можно подключать к сети различными способами. Владелец облака может либо арендовать у нас выделенную публичную подсеть (аналогично тому, как это делается для выделенных физических серверов), либо воспользоваться механизмом «плавающих» IP-адресов (floating IP).

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

    Машины можно подключать и к изолированной локальной сети (если, например, она используется в качестве бэкенда, и непосредственный доступ к Интернету ей не нужен). В случае необходимости такую сеть можно подключить к роутеру и назначить некоторым машинам внешние IP-адреса — например, для удобства обслуживания.

    Загрузка образов


    В новом облаке поддерживается набор образов для самых распространённых дистрибутивов Linux (таких, как Ubuntu, Debian, CentOS, OpenSUSE), а также Windows Server 2012. Помимо стандартного агента cloud-init, в образах присутствует созданный нами агент, реализующий целый ряд полезных функций: переустановку пароля по запросу из панели управления, статическую конфигурацию сети (в случае отсутствия DHCP), управление SSH-ключами. Кроме того, клиенты могут загружать в проект собственные образы виртуальных машин. Поддерживаются форматы образов, используемых в системах виртуализации Virtualbox, KVM, VMware, а также формат Amazon EC2.

    Жесткие диски


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

    Прочие возможности


    Помимо всего прочего, поддерживается возможность добавления SSH-ключей, графическая консоль, генерация RC-файлов для работы с консольными клиентами и другие. В ближайшее время ожидается появление множества новых возможностей — следите за новостями!

    Панель управления


    Важным компонентом любого облака является пользовательская панель, с помощью которой осуществляется управление виртуальными машинами и другим ресурсами. Сообществом разрабатывается панель, которая называется Horizon — как правило, поставщики продуктов на базе Openstack включают ее в комплект в качестве основного средства доступа к инфраструктуре. Реализуя собственное облако, мы решили отказаться от Horizon и создали собственную панель. Чем было обусловено такое решение?

    Те, кто видит Horizon в первый раз, вряд ли заметят какие-либо неудобства. Недостатки становятся заметны лишь в процессе работы, когда привлекательность дизайна отходит на второй план. Создатели Horizon попытались уместить в одну панель все возможные операции по управлению облаком, в результате она получилась слишком громоздкой. Некоторые нужные функции зачастую «запрятаны» слишком глубоко (начинающий пользователь вряд ли сможет их найти), и это делает работу с Horizon достаточно неудобной.

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

    Еще один минус Horizon заключается в том, что он (будучи при этом созданным относительно недавно — в 2011 году) основывается на морально устаревшей схеме, предполагающей генерацию страниц на стороне сервера. В качестве примера недостатков такого подхода можно упомянуть, что все обновления статусов приходят в виде отрендеренных фрагментов HTML.

    Мы постарались сделать нашу панель более производительной и удобной в обращении, для чего реализовали ее на базе актуальных технологий — панель представляет собой одностраничное веб-приложение (Single Page Application), написанное на JavaScript. Такое решение позволило обеспечить быстрый отлик интерфейса, тем самым повышая комфортность и удобство работы с панелью управления для пользователя.

    VPC панель управления

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

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

    Заключение


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

    Сейчас виртуальное приватное облако функционирует в режиме бета-тестирования. Для дальнейшей работы по его усовершенствованию нам очень важно ознакомиться с мнением пользователей. Поэтому мы приглашаем вас принять участие в тестировании. Всем нашим зарегистрированным клиентам мы уже отправили приглашения по электронной почте. Краткая инструкция по основам работы с нашим новым сервисом опубликована здесь.

    Заявку на участие в тестировании можно отправить с помощью тикет-системы.

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

    Мы постараемся учесть все замечания, пожелания и предложения в дальнейшей работе.

    Читателей, которые по тем или иным причинам не могут оставлять комментарии здесь, приглашаем в наш блог.
    Selectel
    116,15
    ИТ-инфраструктура для бизнеса
    Поделиться публикацией

    Комментарии 22

      +21
      Блин, кто у вас рисует картинки? Радуют меня ваши динозавры.
      Достойный пример привязки визуального ряда с компанией. Уже только вижу картинку, и уже понимаю кто пишет о о чем может пойти речь
        +8
        А мне по почте на прошлый новый год мягкую игрушку динозаврика прислали, было оч. приятно и ребенка порадовал.
        Селектел вообще молодцы.
        0
        image
        Все же странно в конце 2014 видеть опенстек в публичных решениях, учитывая то, что весь рынок уже успел пощупать и поплеваться с него.
          +9
          Действительно, вплоть до нескольких последних релизов, OpenStack был похож больше на песочницу для разработчиков, нежели на платформу, подходящую для промышленной эксплуатации.

          При этом, нельзя не отметить, что платформа развивается и стабилизируется очень хорошими темпами — в последних релизах присутствует масса исправлений и нововведений, ориентированных на применение OpenStack для решения реальных задач, стоящих перед бизнесом.

          К настоящему моменту наработано неплохое API, а также существует масса документации и программного обеспечения. На наш взгляд, за платформой есть немалый потенциал — при всех кажущихся недостатках OpenStack, альтернатив ему не видно. Отмечу, что последние саммиты также демонстрируют весьма активный интерес к платформе со стороны самой разнообразной публики.

          И последнее: мы предлагаем не голую платформу, возлагая решение всех проблем на плечи клиентов, а полноценное решение на базе OpenStack. На мой взгляд решение получилось надежным и весьма функциональным при минимальных затратах времени, необходимых для освоения услуги конечным пользователем.
          +3
          Уже успели попробовать! Довольно интересное решение =)
          Пробовал контейнеры с Win и Linux, проблем пока не возникало.

          Об окончании бета-теста я надеюсь сообщите?

            +2
            Спасибо за отзыв! Будем рады увидеть ваши замечания и любые предложения по улучшению функциональности или повышению удобства работы.

            Разумеется, когда бета-тестирование подойдет к завершению, мы заранее оповестим всех участвующих.
            0
            Крупные компании сами разворачивают себе Openstack, т.к. есть свои датацентры.
              +3
              Да, мы упоминали об этом в статье. Безусловно, крупным компаниям, имеющим собственный штат специалистов, проще развернуть собственное приватное облако.

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

              Наша же услуга позволяет избежать этих трат и сосредоточить свои силы на написание приложений, ориентированных на запуск в облаке — все заботы о поддержании инфраструктуры в рабочем состоянии мы берем на себя.
              +1
              Не совсем по теме, но реквест на услугу: виртуальный коммутатор для облачных серверов.
              Чтобы все облачные сервера можно было объединить в одну сеть и поднять на коммутаторе VPN. Понятно, что можно взять отдельный сервер и сделать все самому (так и делаем), но
              это требует VPN-клиента на сервере, что не всегда удобно. Было бы приятно увидеть на виртуальном сервер интерфейс в виртуальную локальную сеть. Вообще было бы замечательно, если бы можно было подключить туда ещё и физические сервера.

              P.S. И ещё один реквест: разберитесь, пожалуйста, с ТКС Банком. У них в интернет-банке есть Селектел, но номер договора почему-то не принимается. Я составлял заявку в банк и оставлял свой номер договора, но сегодня мне пришло уведомление, что заявка не принята, т.к. такого номера договора не существует.
                +3
                Спасибо за предложения, мы обязательно их учтем. Услуга VPN as a Service уже запланирована к реализации и в скором времени появится — с помощью данной услуги можно будет создавать VPN-соединения с помощью API без ручной настройки отдельных виртуальных машин.

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

                Последнее замечание будет передано в коммерческий отдел. Просим вас иметь в виду, что такого рода вопросы лучше задавать с помощью тикет-системы по адресу: support.selectel.ru/tickets/ — в этом случае мы сможем уведомлять Вас о ходе решения проблемы.
                0
                Данная система в теории выглядит хорошо и удобно, но вот меня очень волнует вопрос с производительностью. Ведь для организации всей этой виртуализации и распределения ресурсов по требованию — наверное пришлось сделать множество прослоек между железом и софтом, не скажется ли переход от VDS или физического сервера на VPC потерей производительности (даже точнее назвать «отзывчивости») сервера?

                Вы проводили какое-то сравнение производительности VPC с VDS, VPS и физическими серверами?

                Интересует, например, следующее:

                — скорость реакции на запросы чтения файлов — сравнение времени отклика у физического SAS, подключенного напрямую к серверу, с вариантом реализации распределенных дисков в VPC

                — насколько быстро система выделит 100% процессора, если до этого процессор долго использовался на 1-2%? Не будет ли задержка на «прогрев» и перераспределение ресурсов перед реальным выделением? И что будет, если соседний сервер в облаке тоже захочет в это же время 100% процессора использовать — каждому достанется по 50% или сервера в онлайне быстро раскидаются на 2 разных физических процессора?

                — сетевой интерфес — насколько заметны накладные расходы на проброс физического IP в виртуальную машину?

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

                В общем хотелось бы какой-то отчет по сравнению услуги VPC с XEN, VPS, VDS, выделенным сервером, чтобы понимать, какие минусы и плюсы у этой технологии по сравнению с альтернативами.
                  +1
                  Все компоненты OpenStack (а также наши дополнения) работают на уровне управляющей прослойки, и никакого влияния на итоговую производительность не оказывают. Выделяя, к примеру, 20 VCPU в проект, вы фактически определяете квоту, на основании которой API OpenStack позволит (или не позволит) вам создавать новые машины. После создания машины подсистемы управления не оказывают никакого влияния на работу машины, пока вам не потребуется выключить или поставить ее на паузу.

                  1) Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс (дополнительное время тратится на передачу данных по сети от хранилища до виртуальной машины).

                  2) Каких либо дополнительных задержек на выделение вычислительных мощностей нет. В любой момент времени мы гарантируем, что купленные мощности будут выделены в полном объеме (для уже созданных виртуальных машин ресурсы резервируются в нужном объеме). Если же вы захотите увеличить количество ядер виртуальной машины, то она, возможно, будет перенесена на новый хост (в зависимости от количества свободных ресурсов на текущем).

                  3) Накладные расходы, которые влечет за собой использование плавающих IP-адресов касаются только повышенных требований к нашему оборудованию, на уровне виртуальной машины они не заметны. Для консервативно настроенных клиентов будут доступны также целые публичные подсети, адреса которых пробрасываются в виртуальную машину без дополнительных преобразований.

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

                  В целом, мы постарались реализовать максимально открытую услугу, в которой пользователь получает то, за что платит, без подводных камней и скрытых условий (вроде упомянутого вами функционирования мониторинга за счет клиента). Например, мы не декларируем на словах огромную пиковую производительность (это актуально для дисковой подсистемы), зато гарантируем стабильный и низкий отклик, а также хорошую и предсказуемую скорость обмена данных.
                    0
                    Благодарю за подробное описание! Основная цель вопроса — как раз не в поиске подводных камней, а в наглядном понимании что я потеряю в производительности и других возможностях, пересев с физического сервера или VDS на виртуальный, чтобы принять решение стоит ли идти на такой риск.

                    Например, недавно я перенес сайт на PHP с шаред-хостинга на физическом сервере (Intel® Xeon® CPU X3430 @ 2.40GHz) с локальными SSD-дисками на ваш облачный сервер (Intel® Xeon® CPU E5-2630 0 @ 2.30GHz), и по ощущениям стали наблюдаться периодические подлагивания сайта, особенно если сайт долгое время никто не посещал, то первое открытие страницы идет долго. Ну и просто время генерации главной страницы скачет от быстрого до очень медленного, хотя кроме одного сайта на сервере больше пока ничего и нет. С виду такое ощущение что система немного в слип уходит в моменты простоя, или иногда ресурсы процессора/диска достаются с задержкой.

                    Особенно волнует «Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс» — PHP чтобы отрендерить страницу сайта инклюдит огромное количество мелких файлов, поэтому если на каждом этапе инклюда будет по такой задержке, то в сумме задержка выйдет уже значительно выше. У меня просто уже был печальный опыт с работой сайта на сетевом диске по NFS — тормоза были очень жесткие. У вас, конечно, не NFS а более производительная технология, но опасения остаются ;(

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

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

                    Поэтому тут больше в ваших интересах будет опубликовать на сайте такое сравнение с детальным описанием, чтобы минимизировать кол-во подобных обращений, и чтобы новые потенциальные клиенты сразу понимали что они получают от этой технологии, т.к. технология новая и для большинства клиентов наверное будет очень непонятная.
                      +1
                      Пожалуйста, учитывайте, что данные, которые будут читаться в рамках описанной вами задачи, после первого же прочтения будут кешированы, соответственно последующие обращения к ним будут производиться со значительно большей скоростью. Кеширование часто используемых данных производится как на уровне гостевой операционной системы (для этого полезно оставлять некоторое количество свободной оперативной памяти), так и на уровне инфраструктуры.

                      Кроме того, даже с учетом дополнительной сетевой задержки, время отклика используемого нами хранилища все равно значительно превосходит локальные жесткие диски с интерфейсом SAS (хотя и несколько уступает локальным SSD-дискам профессионального уровня).

                      Приглашаем Вас протестировать нашу услугу: для этого необходимо написать тикет по адресу support.selectel.ru/tickets/

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

                        По поводу кеширования на уровне инфраструктуры — могли бы описать подробнее? Какого объема кеш, каким образом выбирается какие данные кешировать а какие нет.

                        По поводу статей — хотелось бы больше информации не о технических моментах, а о достигнутых результатов в производительности для клиентов, т.к. предложений по облачным серверам довольно много и по общему описанию у всех «все отлично», поэтому чтобы выбрать оптимальное решение — приходится у всех заказывать и тестировать вручную самому, а какой-либо общедоступной информации по результатам производительности серверов обычно никто не пишет. Например в вашей же услуге «Виртуальное приватное облако» предлагается аренда одного процессорного ядра VCPU, но какой именно VCPU я арендую — не узнаешь пока не спросишь лично в техподдержке.
                    0
                    После наблюдения очередной проблемы с медленной скоростью работы облачного сервера (слишком медленно читаются файлы при последовательном чтении) на рабочем проекте все же пришлось более подробно поразбираться в проблеме. Основная проблема, насколько я понимаю, в том, что диски доступны по сети из общего хранилища, отзывчивость которого никаким образом не гарантируется. В результате мы имеем быструю скорость работы с некоторыми файлами, которые читаем постоянно (локальный кеш + кеш на стороне инфраструктуры), и очень медленную скорость работы с файлами, которые читаются не так часто. Поэтому все файловые операции (например rsync папки с кучей файлов) выполняются в 10-20 раз дольше, чем то же самое на каком-то хиленьком VDS с локальным диском или даже локальном компьютере.

                    В поисках методов измерения отзывчивости дисков я нашел статью habrahabr.ru/post/154235 и решил произвести измерения по этому методу — запускал гибридный тест на 30 секунд и получал результаты, которую публикую сюда:
                    Облачный сервер:
                      read : io=276744KB, bw=9211.1KB/s, iops=2302, runt= 30042msec
                        clat (usec): min=313, max=231689, avg=13875.86, stdev=15443.12
                    
                      write: io=184556KB, bw=6149.3KB/s, iops=1537, runt= 30013msec
                        clat (usec): min=833, max=216877, avg=20795.36, stdev=18780.87
                    
                    Виртуальное приватное облако - быстрый диск:
                      read : io=99796KB, bw=3209.2KB/s, iops=802, runt= 31097msec
                        clat (usec): min=244, max=140717, avg=39278.48, stdev=7872.94
                    
                      write: io=49996KB, bw=1604.4KB/s, iops=401, runt= 31162msec
                        clat (usec): min=427, max=155474, avg=79289.17, stdev=9029.01
                    
                    Виртуальное приватное облако - медленный диск:
                      read : io=14696KB, bw=482701B/s, iops=117, runt= 31176msec
                        clat (msec): min=15, max=534, avg=267.07, stdev=38.65
                    
                      write: io=15016KB, bw=493196B/s, iops=120, runt= 31177msec
                        clat (msec): min=7, max=516, avg=264.20, stdev=33.61
                    
                    
                    Сервер Intel Xeon X3430 с SSD-диском  SSD2SC480GE4DA16
                      read : io=449MB, bw=15,334KB/s, iops=3,833, runt= 30011msec
                        clat (usec): min=195, max=314K, avg=8340.08, stdev=29320.30
                    
                      write: io=431MB, bw=14,706KB/s, iops=3,676, runt= 30018msec
                        clat (usec): min=167, max=310K, avg=8695.76, stdev=29247.78
                    
                    
                    Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS)
                      read : io=22872KB, bw=827097B/s, iops=201, runt= 28317msec
                        clat (msec): min=6, max=1608, avg=158.40, stdev=95.58
                    
                      write: io=16140KB, bw=585453B/s, iops=142, runt= 28230msec
                        clat (msec): min=6, max=1453, avg=223.82, stdev=164.04
                    


                    Я не претендую на то, что этот тест оптимальный и показывает реальную производительность дисков, но он позволяет увидеть источник проблемы — несмотря на высокий IOPS облачные диски имеют крайне низкую отзывчивость (latency, в данном случае clat).

                    И привожу итоги в более наглядном виде, в одинаковых единицах измерения (вместо usec и msec):
                    Облачный сервер
                    - read:  iops = 2302   latency =  13.87
                    - write: iops = 1537   latency =  20.79
                    
                    Виртуальное приватное облако - быстрый диск:
                    - read:  iops =  802   latency =  39.27
                    - write: iops =  401   latency =  79.28
                    
                    Виртуальное приватное облако - медленный диск:
                    - read:  iops =  117   latency = 267.07
                    - write: iops =  120   latency = 264.20
                    
                    Сервер Intel Xeon X3430 с SSD-диском  SSD2SC480GE4DA16
                    - read:  iops = 3833   latency =   8.34
                    - write: iops = 3676   latency =   8.69
                    
                    Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS)
                    - read : iops =  201   latency = 158.40
                    - write: iops =  142   latency = 223.82
                    


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

                    Если вы считаете данный тест не совсем оптимальным, то предложите ваш вариант тестирования. Результатом тестов хотелось бы видеть реальную разницу в скорости случайного последовательного чтения/записи множества мелких файлов в различных видах серверов на вашей инфраструктуре (VPC, VDS, VCS и т.п.).

                    Аналогичные тесты хотелось бы увидеть и для других важных параметров серверов (CPU, RAM, Network).

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

                    В итоге, если результаты тестов ваших решений будут лучше чем у конкурентов, то это приведет к вам больше новых клиентов. Сейчас, к сожалению, приходится выбирать оптимальные решения под задачи «в слепую», клонируя свои сервера на десятки разных решений от разных конкурентов, на что уходит очень много времени.
                      0
                      Судя по представленным результатам, для тестирования была выбрана избыточная глубина очереди (iodepth). Диски виртуального приватного облака в данный момент ограничены по количеству операций в секунду (обратите внимание на круглые числа) — соответственно, повышение глубины очереди сверх определенного значения приводит только к увеличению задержки.

                      В рамках услуги «Облачный сервер» операции чтения/записи тарифицировались отдельно — диск, в постоянном режиме нагруженный 2k IOPS обошелся бы в достаточно солидную для простого пользователя сумму. В виртуальном приватном облаке операции не оплачиваются (вы платите только за объем хранимых данных), отсюда возникла необходимость ограничивать производительность.

                      При количестве операций же до нескольких сотен отзывчивость дисков виртуального приватного облака ничуть не хуже, чем таковая у облачных серверов — вы можете убедиться в этом, использовав в тестах меньшую глубину очереди. В будущем будут добавлены и новые типы дисков (вероятно, что лимиты для текущих типов также могут быть пересмотрены в большую сторону).
                        0
                        Основная проблема, с которой я начал «копать» данную тему — в очень медленных операциях с большим количеством файлов на облачном сервере, в сравнении с VPS и другими предыдущими вариантами серверов. Приведу довольно простой, но наглядный пример, который показывает проблему.

                        Имею на сервере папку с 200 тыс. мелких файлов общим объемом около 4 гб, и стал замечать что команда «du -hs» (объем папки) на облачном сервере выполняется неприлично долго. Сейчас решил заморочиться и произвести тестирование.

                        Во обоих примерах система Ubuntu 14.04 AMD64, файловая система ext4, опции монтирования: rw,relatime,barrier=0,data=writeback,nobh (с опциями по-умолчанию результат практически тот же), папка полностью одинаковая (специально скопировал сейчас).

                        Тестирую с помощью команды «time du -hs /var/www» в холодном старте (запуск команды сразу после полной перезагрузки системы и ожидания запуска всех фоновых сервисов, т.е. без локального кеширования).

                        Фоновые сервисы, которые дают нагрузку, по-максимуму остановлены.

                        Для исключения случайностей проверял несколько раз, каждый раз при «чистом» эксперименте результаты примерно одинаковые плюсминус несколько секунд. Повторный запуск команды сразу после первой выдает уже неверные результаты (1-10 секунд), т.к. все выдается из локального кеша. Если очистить локальный кеш, то ещё иногда бывает какой-то другой кеш, при котором операция выполняется около 1 минуты.

                        Чтобы исключить кеширование на стороне инфраструктуры — делал паузу между тестами в несколько часов.

                        Итоги примерно следующие:

                        Облачный сервер: 5m42.279s

                        Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS): 0m47.148s

                        — Команда «du -hs» приводится чисто для примера, в реальных задачах тормоза проявляются в команде rsync и подобных командах, которые пробегаются по куче файлов в куче папок.

                        Чем объясняется такая огромная разница в скорости выполнения данной команды?
                          0
                          По данному вопросу будет необходимо произвести тестирование — создайте, пожалуйста, тикет в панели управления по адресу: support.selectel.ru/tickets
                            0
                            Благодарю за содействие, создал тикет #316344, надеюсь совместными усилиями получится выявить проблему и придумать решение.
                              0
                              Murz, ну как? Получилось что-то?
                                0
                                Получилось уйти к другому провайдеру ;) Что-то цены совсем высокие у Selectel по сравнению с остальными.
                                В общем наиболее простой вариант проверки — команда ioping — показывает как раз то что нужно, пример на другом провайдере:
                                # ioping /tmp
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=2 time=1.6 ms
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=3 time=693 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=4 time=657 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=5 time=3.1 ms
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=6 time=582 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=7 time=719 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=8 time=642 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=9 time=712 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=10 time=809 us
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=11 time=1.4 ms
                                4.0 KiB from /tmp (ext4 /dev/dm-4): request=12 time=1.5 ms
                                --- /tmp (ext4 /dev/dm-4) ioping statistics ---
                                87 requests completed in 1.4 min, 1.1 k iops, 4.4 MiB/s
                                min/avg/max/mdev = 468 us / 895 us / 4.9 ms / 672 us

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое