Комментарии 22
Блин, кто у вас рисует картинки? Радуют меня ваши динозавры.
Достойный пример привязки визуального ряда с компанией. Уже только вижу картинку, и уже понимаю кто пишет о о чем может пойти речь
Достойный пример привязки визуального ряда с компанией. Уже только вижу картинку, и уже понимаю кто пишет о о чем может пойти речь
Все же странно в конце 2014 видеть опенстек в публичных решениях, учитывая то, что весь рынок уже успел пощупать и поплеваться с него.
Действительно, вплоть до нескольких последних релизов, OpenStack был похож больше на песочницу для разработчиков, нежели на платформу, подходящую для промышленной эксплуатации.
При этом, нельзя не отметить, что платформа развивается и стабилизируется очень хорошими темпами — в последних релизах присутствует масса исправлений и нововведений, ориентированных на применение OpenStack для решения реальных задач, стоящих перед бизнесом.
К настоящему моменту наработано неплохое API, а также существует масса документации и программного обеспечения. На наш взгляд, за платформой есть немалый потенциал — при всех кажущихся недостатках OpenStack, альтернатив ему не видно. Отмечу, что последние саммиты также демонстрируют весьма активный интерес к платформе со стороны самой разнообразной публики.
И последнее: мы предлагаем не голую платформу, возлагая решение всех проблем на плечи клиентов, а полноценное решение на базе OpenStack. На мой взгляд решение получилось надежным и весьма функциональным при минимальных затратах времени, необходимых для освоения услуги конечным пользователем.
При этом, нельзя не отметить, что платформа развивается и стабилизируется очень хорошими темпами — в последних релизах присутствует масса исправлений и нововведений, ориентированных на применение OpenStack для решения реальных задач, стоящих перед бизнесом.
К настоящему моменту наработано неплохое API, а также существует масса документации и программного обеспечения. На наш взгляд, за платформой есть немалый потенциал — при всех кажущихся недостатках OpenStack, альтернатив ему не видно. Отмечу, что последние саммиты также демонстрируют весьма активный интерес к платформе со стороны самой разнообразной публики.
И последнее: мы предлагаем не голую платформу, возлагая решение всех проблем на плечи клиентов, а полноценное решение на базе OpenStack. На мой взгляд решение получилось надежным и весьма функциональным при минимальных затратах времени, необходимых для освоения услуги конечным пользователем.
Уже успели попробовать! Довольно интересное решение =)
Пробовал контейнеры с Win и Linux, проблем пока не возникало.
Об окончании бета-теста я надеюсь сообщите?
Пробовал контейнеры с Win и Linux, проблем пока не возникало.
Об окончании бета-теста я надеюсь сообщите?
Крупные компании сами разворачивают себе Openstack, т.к. есть свои датацентры.
Да, мы упоминали об этом в статье. Безусловно, крупным компаниям, имеющим собственный штат специалистов, проще развернуть собственное приватное облако.
Однако временные и денежные затраты на развертывание OpenStack на базе собственной инфраструктуры могут быть весьма велики даже с использованием готовых дистрибутивных вариантов — процесс подгонки под свои нужды и имеющееся аппаратное обеспечение может быть весьма длительным и трудоемким.
Наша же услуга позволяет избежать этих трат и сосредоточить свои силы на написание приложений, ориентированных на запуск в облаке — все заботы о поддержании инфраструктуры в рабочем состоянии мы берем на себя.
Однако временные и денежные затраты на развертывание OpenStack на базе собственной инфраструктуры могут быть весьма велики даже с использованием готовых дистрибутивных вариантов — процесс подгонки под свои нужды и имеющееся аппаратное обеспечение может быть весьма длительным и трудоемким.
Наша же услуга позволяет избежать этих трат и сосредоточить свои силы на написание приложений, ориентированных на запуск в облаке — все заботы о поддержании инфраструктуры в рабочем состоянии мы берем на себя.
Не совсем по теме, но реквест на услугу: виртуальный коммутатор для облачных серверов.
Чтобы все облачные сервера можно было объединить в одну сеть и поднять на коммутаторе VPN. Понятно, что можно взять отдельный сервер и сделать все самому (так и делаем), но
это требует VPN-клиента на сервере, что не всегда удобно. Было бы приятно увидеть на виртуальном сервер интерфейс в виртуальную локальную сеть. Вообще было бы замечательно, если бы можно было подключить туда ещё и физические сервера.
P.S. И ещё один реквест: разберитесь, пожалуйста, с ТКС Банком. У них в интернет-банке есть Селектел, но номер договора почему-то не принимается. Я составлял заявку в банк и оставлял свой номер договора, но сегодня мне пришло уведомление, что заявка не принята, т.к. такого номера договора не существует.
Чтобы все облачные сервера можно было объединить в одну сеть и поднять на коммутаторе VPN. Понятно, что можно взять отдельный сервер и сделать все самому (так и делаем), но
это требует VPN-клиента на сервере, что не всегда удобно. Было бы приятно увидеть на виртуальном сервер интерфейс в виртуальную локальную сеть. Вообще было бы замечательно, если бы можно было подключить туда ещё и физические сервера.
P.S. И ещё один реквест: разберитесь, пожалуйста, с ТКС Банком. У них в интернет-банке есть Селектел, но номер договора почему-то не принимается. Я составлял заявку в банк и оставлял свой номер договора, но сегодня мне пришло уведомление, что заявка не принята, т.к. такого номера договора не существует.
Спасибо за предложения, мы обязательно их учтем. Услуга VPN as a Service уже запланирована к реализации и в скором времени появится — с помощью данной услуги можно будет создавать VPN-соединения с помощью API без ручной настройки отдельных виртуальных машин.
Возможные варианты интеграции с выделенными серверами обдумаем. Вероятно, здесь также подойдет решение с организацией VPN.
Последнее замечание будет передано в коммерческий отдел. Просим вас иметь в виду, что такого рода вопросы лучше задавать с помощью тикет-системы по адресу: support.selectel.ru/tickets/ — в этом случае мы сможем уведомлять Вас о ходе решения проблемы.
Возможные варианты интеграции с выделенными серверами обдумаем. Вероятно, здесь также подойдет решение с организацией VPN.
Последнее замечание будет передано в коммерческий отдел. Просим вас иметь в виду, что такого рода вопросы лучше задавать с помощью тикет-системы по адресу: support.selectel.ru/tickets/ — в этом случае мы сможем уведомлять Вас о ходе решения проблемы.
Данная система в теории выглядит хорошо и удобно, но вот меня очень волнует вопрос с производительностью. Ведь для организации всей этой виртуализации и распределения ресурсов по требованию — наверное пришлось сделать множество прослоек между железом и софтом, не скажется ли переход от VDS или физического сервера на VPC потерей производительности (даже точнее назвать «отзывчивости») сервера?
Вы проводили какое-то сравнение производительности VPC с VDS, VPS и физическими серверами?
Интересует, например, следующее:
— скорость реакции на запросы чтения файлов — сравнение времени отклика у физического SAS, подключенного напрямую к серверу, с вариантом реализации распределенных дисков в VPC
— насколько быстро система выделит 100% процессора, если до этого процессор долго использовался на 1-2%? Не будет ли задержка на «прогрев» и перераспределение ресурсов перед реальным выделением? И что будет, если соседний сервер в облаке тоже захочет в это же время 100% процессора использовать — каждому достанется по 50% или сервера в онлайне быстро раскидаются на 2 разных физических процессора?
— сетевой интерфес — насколько заметны накладные расходы на проброс физического IP в виртуальную машину?
— на мониторинг потребления и другие процессы виртуализации и распределения наверно тоже немалый оверхед присутствует, который в итоге клиенту может дать значительно более слабую машину, чем физическое железо.
В общем хотелось бы какой-то отчет по сравнению услуги VPC с XEN, VPS, VDS, выделенным сервером, чтобы понимать, какие минусы и плюсы у этой технологии по сравнению с альтернативами.
Вы проводили какое-то сравнение производительности VPC с VDS, VPS и физическими серверами?
Интересует, например, следующее:
— скорость реакции на запросы чтения файлов — сравнение времени отклика у физического SAS, подключенного напрямую к серверу, с вариантом реализации распределенных дисков в VPC
— насколько быстро система выделит 100% процессора, если до этого процессор долго использовался на 1-2%? Не будет ли задержка на «прогрев» и перераспределение ресурсов перед реальным выделением? И что будет, если соседний сервер в облаке тоже захочет в это же время 100% процессора использовать — каждому достанется по 50% или сервера в онлайне быстро раскидаются на 2 разных физических процессора?
— сетевой интерфес — насколько заметны накладные расходы на проброс физического IP в виртуальную машину?
— на мониторинг потребления и другие процессы виртуализации и распределения наверно тоже немалый оверхед присутствует, который в итоге клиенту может дать значительно более слабую машину, чем физическое железо.
В общем хотелось бы какой-то отчет по сравнению услуги VPC с XEN, VPS, VDS, выделенным сервером, чтобы понимать, какие минусы и плюсы у этой технологии по сравнению с альтернативами.
Все компоненты OpenStack (а также наши дополнения) работают на уровне управляющей прослойки, и никакого влияния на итоговую производительность не оказывают. Выделяя, к примеру, 20 VCPU в проект, вы фактически определяете квоту, на основании которой API OpenStack позволит (или не позволит) вам создавать новые машины. После создания машины подсистемы управления не оказывают никакого влияния на работу машины, пока вам не потребуется выключить или поставить ее на паузу.
1) Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс (дополнительное время тратится на передачу данных по сети от хранилища до виртуальной машины).
2) Каких либо дополнительных задержек на выделение вычислительных мощностей нет. В любой момент времени мы гарантируем, что купленные мощности будут выделены в полном объеме (для уже созданных виртуальных машин ресурсы резервируются в нужном объеме). Если же вы захотите увеличить количество ядер виртуальной машины, то она, возможно, будет перенесена на новый хост (в зависимости от количества свободных ресурсов на текущем).
3) Накладные расходы, которые влечет за собой использование плавающих IP-адресов касаются только повышенных требований к нашему оборудованию, на уровне виртуальной машины они не заметны. Для консервативно настроенных клиентов будут доступны также целые публичные подсети, адреса которых пробрасываются в виртуальную машину без дополнительных преобразований.
4) Действительно, функционирование управляющей прослойки на гипервизорах влечет за собой некоторые накладные расходы (как и в любом другом облаке), однако они невелики. Все процессы, отвечающие за управление и мониторинг выполняются на уровне хоста, при этом мы резервируем некоторый запас по производительности специально под эти нужды — соответственно, служебные функции никак не затрагивают клиентские виртуальные машины.
В целом, мы постарались реализовать максимально открытую услугу, в которой пользователь получает то, за что платит, без подводных камней и скрытых условий (вроде упомянутого вами функционирования мониторинга за счет клиента). Например, мы не декларируем на словах огромную пиковую производительность (это актуально для дисковой подсистемы), зато гарантируем стабильный и низкий отклик, а также хорошую и предсказуемую скорость обмена данных.
1) Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс (дополнительное время тратится на передачу данных по сети от хранилища до виртуальной машины).
2) Каких либо дополнительных задержек на выделение вычислительных мощностей нет. В любой момент времени мы гарантируем, что купленные мощности будут выделены в полном объеме (для уже созданных виртуальных машин ресурсы резервируются в нужном объеме). Если же вы захотите увеличить количество ядер виртуальной машины, то она, возможно, будет перенесена на новый хост (в зависимости от количества свободных ресурсов на текущем).
3) Накладные расходы, которые влечет за собой использование плавающих IP-адресов касаются только повышенных требований к нашему оборудованию, на уровне виртуальной машины они не заметны. Для консервативно настроенных клиентов будут доступны также целые публичные подсети, адреса которых пробрасываются в виртуальную машину без дополнительных преобразований.
4) Действительно, функционирование управляющей прослойки на гипервизорах влечет за собой некоторые накладные расходы (как и в любом другом облаке), однако они невелики. Все процессы, отвечающие за управление и мониторинг выполняются на уровне хоста, при этом мы резервируем некоторый запас по производительности специально под эти нужды — соответственно, служебные функции никак не затрагивают клиентские виртуальные машины.
В целом, мы постарались реализовать максимально открытую услугу, в которой пользователь получает то, за что платит, без подводных камней и скрытых условий (вроде упомянутого вами функционирования мониторинга за счет клиента). Например, мы не декларируем на словах огромную пиковую производительность (это актуально для дисковой подсистемы), зато гарантируем стабильный и низкий отклик, а также хорошую и предсказуемую скорость обмена данных.
Благодарю за подробное описание! Основная цель вопроса — как раз не в поиске подводных камней, а в наглядном понимании что я потеряю в производительности и других возможностях, пересев с физического сервера или VDS на виртуальный, чтобы принять решение стоит ли идти на такой риск.
Например, недавно я перенес сайт на PHP с шаред-хостинга на физическом сервере (Intel® Xeon® CPU X3430 @ 2.40GHz) с локальными SSD-дисками на ваш облачный сервер (Intel® Xeon® CPU E5-2630 0 @ 2.30GHz), и по ощущениям стали наблюдаться периодические подлагивания сайта, особенно если сайт долгое время никто не посещал, то первое открытие страницы идет долго. Ну и просто время генерации главной страницы скачет от быстрого до очень медленного, хотя кроме одного сайта на сервере больше пока ничего и нет. С виду такое ощущение что система немного в слип уходит в моменты простоя, или иногда ресурсы процессора/диска достаются с задержкой.
Особенно волнует «Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс» — PHP чтобы отрендерить страницу сайта инклюдит огромное количество мелких файлов, поэтому если на каждом этапе инклюда будет по такой задержке, то в сумме задержка выйдет уже значительно выше. У меня просто уже был печальный опыт с работой сайта на сетевом диске по NFS — тормоза были очень жесткие. У вас, конечно, не NFS а более производительная технология, но опасения остаются ;(
Я не говорю что причина тормозов моего сервера именно в технологии облачного сервера, даже больше — скорее всего тут основная проблема в разных настройках моих локальных систем, поэтому пока претензий к технологии нет, просто описываю свои ощущения от переезда.
Но ведь большинство других клиентов, пересевших на облако, в первую очередь тоже так же будет грешить сначала на облачную технологию, а потом уже на себя и криво настроенную систему ;)
Поэтому тут больше в ваших интересах будет опубликовать на сайте такое сравнение с детальным описанием, чтобы минимизировать кол-во подобных обращений, и чтобы новые потенциальные клиенты сразу понимали что они получают от этой технологии, т.к. технология новая и для большинства клиентов наверное будет очень непонятная.
Например, недавно я перенес сайт на PHP с шаред-хостинга на физическом сервере (Intel® Xeon® CPU X3430 @ 2.40GHz) с локальными SSD-дисками на ваш облачный сервер (Intel® Xeon® CPU E5-2630 0 @ 2.30GHz), и по ощущениям стали наблюдаться периодические подлагивания сайта, особенно если сайт долгое время никто не посещал, то первое открытие страницы идет долго. Ну и просто время генерации главной страницы скачет от быстрого до очень медленного, хотя кроме одного сайта на сервере больше пока ничего и нет. С виду такое ощущение что система немного в слип уходит в моменты простоя, или иногда ресурсы процессора/диска достаются с задержкой.
Особенно волнует «Время отклика операций чтения в среднем превышает таковое для локальных дисков примерно на 0.5-1 мс» — PHP чтобы отрендерить страницу сайта инклюдит огромное количество мелких файлов, поэтому если на каждом этапе инклюда будет по такой задержке, то в сумме задержка выйдет уже значительно выше. У меня просто уже был печальный опыт с работой сайта на сетевом диске по NFS — тормоза были очень жесткие. У вас, конечно, не NFS а более производительная технология, но опасения остаются ;(
Я не говорю что причина тормозов моего сервера именно в технологии облачного сервера, даже больше — скорее всего тут основная проблема в разных настройках моих локальных систем, поэтому пока претензий к технологии нет, просто описываю свои ощущения от переезда.
Но ведь большинство других клиентов, пересевших на облако, в первую очередь тоже так же будет грешить сначала на облачную технологию, а потом уже на себя и криво настроенную систему ;)
Поэтому тут больше в ваших интересах будет опубликовать на сайте такое сравнение с детальным описанием, чтобы минимизировать кол-во подобных обращений, и чтобы новые потенциальные клиенты сразу понимали что они получают от этой технологии, т.к. технология новая и для большинства клиентов наверное будет очень непонятная.
Пожалуйста, учитывайте, что данные, которые будут читаться в рамках описанной вами задачи, после первого же прочтения будут кешированы, соответственно последующие обращения к ним будут производиться со значительно большей скоростью. Кеширование часто используемых данных производится как на уровне гостевой операционной системы (для этого полезно оставлять некоторое количество свободной оперативной памяти), так и на уровне инфраструктуры.
Кроме того, даже с учетом дополнительной сетевой задержки, время отклика используемого нами хранилища все равно значительно превосходит локальные жесткие диски с интерфейсом SAS (хотя и несколько уступает локальным SSD-дискам профессионального уровня).
Приглашаем Вас протестировать нашу услугу: для этого необходимо написать тикет по адресу support.selectel.ru/tickets/
В будущем мы опубликуем ряд статей, касающихся как технических моментов организации нашего нового облака, так и особенностей управления ресурсами.
Кроме того, даже с учетом дополнительной сетевой задержки, время отклика используемого нами хранилища все равно значительно превосходит локальные жесткие диски с интерфейсом SAS (хотя и несколько уступает локальным SSD-дискам профессионального уровня).
Приглашаем Вас протестировать нашу услугу: для этого необходимо написать тикет по адресу support.selectel.ru/tickets/
В будущем мы опубликуем ряд статей, касающихся как технических моментов организации нашего нового облака, так и особенностей управления ресурсами.
Про кеширование на уровне гостевой системы я в курсе, но когда проект большой — все что нужно читать ни в какой локальный кеш не влазит, поэтому надеяться на него смысла мало.
По поводу кеширования на уровне инфраструктуры — могли бы описать подробнее? Какого объема кеш, каким образом выбирается какие данные кешировать а какие нет.
По поводу статей — хотелось бы больше информации не о технических моментах, а о достигнутых результатов в производительности для клиентов, т.к. предложений по облачным серверам довольно много и по общему описанию у всех «все отлично», поэтому чтобы выбрать оптимальное решение — приходится у всех заказывать и тестировать вручную самому, а какой-либо общедоступной информации по результатам производительности серверов обычно никто не пишет. Например в вашей же услуге «Виртуальное приватное облако» предлагается аренда одного процессорного ядра VCPU, но какой именно VCPU я арендую — не узнаешь пока не спросишь лично в техподдержке.
По поводу кеширования на уровне инфраструктуры — могли бы описать подробнее? Какого объема кеш, каким образом выбирается какие данные кешировать а какие нет.
По поводу статей — хотелось бы больше информации не о технических моментах, а о достигнутых результатов в производительности для клиентов, т.к. предложений по облачным серверам довольно много и по общему описанию у всех «все отлично», поэтому чтобы выбрать оптимальное решение — приходится у всех заказывать и тестировать вручную самому, а какой-либо общедоступной информации по результатам производительности серверов обычно никто не пишет. Например в вашей же услуге «Виртуальное приватное облако» предлагается аренда одного процессорного ядра VCPU, но какой именно VCPU я арендую — не узнаешь пока не спросишь лично в техподдержке.
После наблюдения очередной проблемы с медленной скоростью работы облачного сервера (слишком медленно читаются файлы при последовательном чтении) на рабочем проекте все же пришлось более подробно поразбираться в проблеме. Основная проблема, насколько я понимаю, в том, что диски доступны по сети из общего хранилища, отзывчивость которого никаким образом не гарантируется. В результате мы имеем быструю скорость работы с некоторыми файлами, которые читаем постоянно (локальный кеш + кеш на стороне инфраструктуры), и очень медленную скорость работы с файлами, которые читаются не так часто. Поэтому все файловые операции (например rsync папки с кучей файлов) выполняются в 10-20 раз дольше, чем то же самое на каком-то хиленьком VDS с локальным диском или даже локальном компьютере.
В поисках методов измерения отзывчивости дисков я нашел статью habrahabr.ru/post/154235 и решил произвести измерения по этому методу — запускал гибридный тест на 30 секунд и получал результаты, которую публикую сюда:
Я не претендую на то, что этот тест оптимальный и показывает реальную производительность дисков, но он позволяет увидеть источник проблемы — несмотря на высокий IOPS облачные диски имеют крайне низкую отзывчивость (latency, в данном случае clat).
И привожу итоги в более наглядном виде, в одинаковых единицах измерения (вместо usec и msec):
По итогам видно, что у виртуального приватного облака даже «быстрый» диск получился значительно менее отзывчивым, чем у облачного сервера. Но по услуге «облачный сервер» больше нет возможности создать новый сервер, техподдержка предлагает переезжать на виртуальное частное облако, которое по результатам получается заметно медленнее со стороны работы с диском.
Если вы считаете данный тест не совсем оптимальным, то предложите ваш вариант тестирования. Результатом тестов хотелось бы видеть реальную разницу в скорости случайного последовательного чтения/записи множества мелких файлов в различных видах серверов на вашей инфраструктуре (VPC, VDS, VCS и т.п.).
Аналогичные тесты хотелось бы увидеть и для других важных параметров серверов (CPU, RAM, Network).
Опубликовав эти данные публично, у потенциальных клиентов будет больше доверия к вашим услугам, и им будет проще понять что они приобретут и потеряют при переезде от конкурентов к вам.
В итоге, если результаты тестов ваших решений будут лучше чем у конкурентов, то это приведет к вам больше новых клиентов. Сейчас, к сожалению, приходится выбирать оптимальные решения под задачи «в слепую», клонируя свои сервера на десятки разных решений от разных конкурентов, на что уходит очень много времени.
В поисках методов измерения отзывчивости дисков я нашел статью 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).
Опубликовав эти данные публично, у потенциальных клиентов будет больше доверия к вашим услугам, и им будет проще понять что они приобретут и потеряют при переезде от конкурентов к вам.
В итоге, если результаты тестов ваших решений будут лучше чем у конкурентов, то это приведет к вам больше новых клиентов. Сейчас, к сожалению, приходится выбирать оптимальные решения под задачи «в слепую», клонируя свои сервера на десятки разных решений от разных конкурентов, на что уходит очень много времени.
Судя по представленным результатам, для тестирования была выбрана избыточная глубина очереди (iodepth). Диски виртуального приватного облака в данный момент ограничены по количеству операций в секунду (обратите внимание на круглые числа) — соответственно, повышение глубины очереди сверх определенного значения приводит только к увеличению задержки.
В рамках услуги «Облачный сервер» операции чтения/записи тарифицировались отдельно — диск, в постоянном режиме нагруженный 2k IOPS обошелся бы в достаточно солидную для простого пользователя сумму. В виртуальном приватном облаке операции не оплачиваются (вы платите только за объем хранимых данных), отсюда возникла необходимость ограничивать производительность.
При количестве операций же до нескольких сотен отзывчивость дисков виртуального приватного облака ничуть не хуже, чем таковая у облачных серверов — вы можете убедиться в этом, использовав в тестах меньшую глубину очереди. В будущем будут добавлены и новые типы дисков (вероятно, что лимиты для текущих типов также могут быть пересмотрены в большую сторону).
В рамках услуги «Облачный сервер» операции чтения/записи тарифицировались отдельно — диск, в постоянном режиме нагруженный 2k IOPS обошелся бы в достаточно солидную для простого пользователя сумму. В виртуальном приватном облаке операции не оплачиваются (вы платите только за объем хранимых данных), отсюда возникла необходимость ограничивать производительность.
При количестве операций же до нескольких сотен отзывчивость дисков виртуального приватного облака ничуть не хуже, чем таковая у облачных серверов — вы можете убедиться в этом, использовав в тестах меньшую глубину очереди. В будущем будут добавлены и новые типы дисков (вероятно, что лимиты для текущих типов также могут быть пересмотрены в большую сторону).
Основная проблема, с которой я начал «копать» данную тему — в очень медленных операциях с большим количеством файлов на облачном сервере, в сравнении с 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 и подобных командах, которые пробегаются по куче файлов в куче папок.
Чем объясняется такая огромная разница в скорости выполнения данной команды?
Имею на сервере папку с 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 и подобных командах, которые пробегаются по куче файлов в куче папок.
Чем объясняется такая огромная разница в скорости выполнения данной команды?
По данному вопросу будет необходимо произвести тестирование — создайте, пожалуйста, тикет в панели управления по адресу: support.selectel.ru/tickets
Благодарю за содействие, создал тикет #316344, надеюсь совместными усилиями получится выявить проблему и придумать решение.
Murz, ну как? Получилось что-то?
Получилось уйти к другому провайдеру ;) Что-то цены совсем высокие у Selectel по сравнению с остальными.
В общем наиболее простой вариант проверки — команда ioping — показывает как раз то что нужно, пример на другом провайдере:
В общем наиболее простой вариант проверки — команда 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Новая услуга: виртуальное приватное облако