Сегодня мы поговорим о тестировании производительности облачных сервисов и систем виртуализации, а также сделаем полезные выводы.
Но прежде чем говорить о бенчмаркинге, давайте подумаем, как правильно проводить тесты в виртуальной среде? На самом деле в этом вопросе есть свои хитрости и свои, уже проверенные методы.
Большинство людей, впервые тестирующих виртуальные среды, делают это неправильно, до такой степени, что VMware включила в свое пользовательское лицензионное соглашение запрет на публикацию таких материалов по тестированию без одобрения VMware. А все потому, что им обязательно нужно оценить методику тестирования.
Действительно, какой подход приходит на ум первым? Создаем виртуальную машину, устанавливаем в нее популярный софт для тестирования диска, памяти, процессора и видеокарты.
И мы сравним его результаты, например, с физической системой или другой виртуальной машиной.
Такой подход, хотя и не без оговорок, имеет право на жизнь, если мы говорим о ноутбуке или рабочей станции, когда виртуальная машина почти всегда одна, и хочется получить от нее максимум — запустить игру или офисное приложение.
«без тормозов».
Увы, когда речь идет о серверах с множеством виртуальных машин, этот метод совершенно бесполезен, поскольку на его основе невозможно сделать практически никаких выводов.
Почему? Во-первых, никто не использует сервер для запуска одной виртуальной машины, их почти всегда много; а если, например, у одного окажется высокая производительность в ущерб другому (это вполне возможно при плохо работающем планировщике задач), то платформа в принципе очень плохая - но тест этого не покажет! Во-вторых, виртуальная машина на сервере практически всегда имеет ограниченные ресурсы — и речь идет не о 90%, а зачастую лишь о нескольких процентах ресурсов сервера.
При этом две разные платформы на одной, пяти или десяти машинах виртуализации могут показывать одинаковые результаты.
Означает ли это, что системы одинаково хороши или плохи? Абсолютно не обязательно! Ведь разные решения могут по-разному работать с памятью, использовать процессорное время или виртуализировать дисковые операции.
И пока на сервере есть свободные ресурсы, разница между разными платформами будет незаметна.
Но ресурсы всегда заканчиваются, потому что по сути смысл виртуализации — использовать ресурсы по максимуму.
И решение, у которого они исчерпаются раньше, в реальной жизни покажет худшие результаты, но узнать это с помощью изложенного метода мы не сможем.
В-третьих, у гипервизоров есть свой набор «ахиллесовых пят» — определенные схемы нагрузки, при которых каждый из них будет работать особенно плохо.
В зависимости от того, насколько нагрузочное тестирование предполагает использование таких шаблонов, результаты могут существенно отличаться.
Нетрудно выбрать или написать тест, который покажет «нужные» результаты — хорошие или плохие — и гораздо сложнее создать тест, который будет давать полезные и объективные результаты.
Как мы будем это проверять, господа? Однако виртуализация на базе архитектуры Intel существует уже почти 20 лет, и для людей, работающих в этой области, тема бенчмаркинга вовсе не нова.
За последние годы уже выработан некий «золотой стандарт» такого тестирования.
Опуская некоторые детали, подход можно сформулировать следующим образом: • Создать систему из нескольких виртуальных машин с типовыми серверными приложениями (обычно это сервер с базой данных, сервер для какого-то тяжелого Java-приложения, почтовый сервер, файловый сервер и т. д.), • Получите интегральные баллы от этих приложений, которые характеризуют производительность каждой из этих систем.
• При добавлении новых аналогичных систем суммируйте баллы.
• Оценить решение по сумме баллов для равных конфигураций (когда разница только в одном параметре — в самой системе виртуализации).
Такое тестирование, конечно, не дает ответов на все вопросы.
Например, потому, что набор эталонных нагрузок может сильно отличаться от того, что на самом деле нужно клиенту — а реальные нагрузки могут давать совершенно другие результаты (вспомните «ахиллесовы пяты» инструментов виртуализации).
Но это все равно намного лучше, чем тот «подход в лоб», о котором мы говорили в самом начале.
В Virtuozzo мы занимаемся в первую очередь облачными сервисами и знаем, что о них думают клиенты, а не только поставщики услуг (которые выбирают поставщика платформы виртуализации).
Их часто не волнует, какая система виртуализации использовалась, поскольку их волнует только производительность купленного виртуального сервера.
И как это достигается — с помощью более производительного гипервизора, более производительного железа или просто размещением меньшего количества клиентов на каждом сервере — заказчику совершенно не важно.
С точки зрения клиента, «десктопный» подход имеет право на существование — тот же процессор, диск и прочие «попугаи», которых призваны показать подобные тесты, — они показывают, насколько купленный сервер стоит своих денег.
Получается, что поставщику услуг нужно одно, а потребителю — другое.
Золотая середина? Но недавно мы с партнерской компанией Cloud Spectator запустили небольшой проект, где нам нужно было разобраться, можно ли сделать тест, который бы проверял виртуализацию серверов, но с точки зрения клиента? Нам кажется, что мы нашли подход – если не идеальный, то он имеет право на существование.
Для справки.
Cloud Spectator тестирует производительность облачных серверов, причем делает это, по существу, «настольным» способом — запуская такие тесты, как geekbench и fio, внутри одной виртуальной машины и собирая их результаты в течение длительного периода времени (например, целый день на одной виртуальной машине).
рабочий день).
Вы можете прочитать аналогичный отчет, где один из облачных сервисов от 1&1 показал лучшую производительность.
Наш эксперимент, в котором мы протестировали две разные платформы виртуализации, используя схожий метод, дал интересные результаты.
Сначала нам нужно было довести тестируемые серверы до «производственной нагрузки» (назовем эту нагрузку «балластом»).
Его единственная цель — равномерно загрузить серверы, создавая «при прочих равных условиях».
Сами серверы были вполне типичными для современных провайдеров — не самого высокого класса, но цель была не в максимальном количестве, а в получении данных, которые можно было бы сравнивать между собой.
Процессор: 2 x Intel Xeon E5-2620 Оперативная память: 64 ГБ (4 x 16 ГБ DDR4-2133 ECC REG) Хранилище: LSI 9271-8i (8 портов SAS2, 1 ГБ), RAID0 более 8 x HGST, 450 ГБ, 15 000 об/мин.Чтобы создать одинаковую балластную нагрузку на обоих серверах, мы использовали еще один тест, который уже проводился ранее.
Он эмулирует работу веб-сервера, к которому обращаются клиенты.
Обычно мы используем этот тест для измерения максимально достижимой плотности виртуальных серверов на физический сервер, используя следующую методологию: добавляя все больше и больше виртуальных серверов, мы измеряем скорость ответа и останавливаем тест, когда 95-й процентиль превышает 4 секунды, учитывая достигается максимальная плотность.
Вот пример графиков, которые строит этот тест для разных систем виртуализации: 
Но сегодня мы решили использовать этот тест по-другому — зафиксировать количество виртуальных серверов, но изменить частоту запросов в секунду.
Готовясь к тестированию, мы создали равное количество таких виртуальных серверов (по 50 штук) на обоих хостах и начали одинаково загружать их с нескольких клиентов, постепенно увеличивая частоту входящих запросов.
Когда оба сервера начали показывать загрузку ЦП, близкую к 100%, мы остановились и зафиксировали балластную нагрузку на этом уровне (мотивация - большинство провайдеров хотят загружать серверы почти на 100%, но чтобы не страдали клиенты).
Далее мы создали 51-й сервер на обоих хостах и передали его Cloud Spectator для проверки «клиентского представления производительности».
То есть тестовый «стенд» выглядел примерно так: 
Как вы уже догадались, по результатам тестирования победила наша система виртуализации (полный отчет можно посмотреть здесь).
связь ), но суть статьи не в этом.
Главное, что мы разработали методологию, позволяющую поставщику облачных услуг оценить, как изменение одного из параметров системы, «при прочих равных условиях», отражается на уровне производительности, которую получает его клиент. Интересные факты… 1. Производительность может резко упасть В ходе теста нам удалось узнать несколько интересных фактов.
Например, мы узнали, что небольшие изменения балластной нагрузки могут привести к значительному падению производительности тестового клиента.
Причем она действительно невелика — увеличение примерно на 10-15% приводит к значительному ухудшению результатов испытаний, ведь существует определенный предел нагрузки, превышение которого приводит к отказу.
Вот диаграмма производительности Geekbench, которую мы взяли при регулировке балластной нагрузки.
Как видите, при увеличении количества клиентских запросов на балластной нагрузке примерно со 125 до 135 запросов в секунду производительность тестируемой среды на «первой вышедшей из строя» платформе падает в несколько раз.
Такое падение невозможно воспроизвести при увеличении нагрузки на один или несколько клиентов — ресурсная изоляция виртуализации не позволит им использовать все ресурсы.
Но если это произойдет на многих или всех клиентах одновременно, такое падение производительности вполне возможно.
Отсюда следует вывод: если вы используете облачный сервер и ваш сайт в определенные часы работает очень медленно, возможно, ваш провайдер создал слишком много клиентов на одном сервере — и это не было заметно лишь «до поры до времени».
2. Хотите производительности? Его нужно постоянно измерять! Это должен делать как провайдер, который хочет, чтобы его клиенты не жаловались, так и сам клиент. В реальной жизни нагрузка на физический сервер варьируется в разное время суток, поэтому Cloud Spectator обычно тестирует сервер непрерывно в течение 24 часов, чтобы охватить полный 24-часовой цикл.
Для разового теста этого может быть достаточно (если, конечно, эти 24 часа не приходятся на выходные), но в реальной жизни ситуация может измениться в более отдаленной перспективе.
Ваш виртуальный сервер может попасть на физический сервер одним из первых — и все будет «летать», пока там не будут созданы сервера для других клиентов.
Вокруг вас могут быть «пустые» облачные серверы, которые через месяц-два заполнятся реальными нагрузками.
В конце концов, продуктивность может сохраняться до тех пор, пока не наступит сезон праздничных покупок в Интернете.
3. И последнее – «быстро и дешево» не существует. Оборудование, сеть, дата-центры, электричество — все стоит денег.
«Стандартные» способы оптимизации затрат, такие как использование оборудования с максимальным соотношением производительность/цена, используются практически всеми провайдерами, но особой выгоды от этого не будет. Единственный способ продать свои услуги дешевле рынка и не уйти в минус — запустить больше клиентов на одном сервере.
Но такой подход всегда идет в ущерб производительности — либо сейчас, либо в ближайшем будущем.
Поэтому, если для вас важна производительность облачных услуг, цена не должна быть единственным фактором при выборе поставщика услуг.
Теги: #Виртуализация #Хостинг #тестирование #бенчмаркинг
-
Обзор Hp Compaq-8510P-Gb955Ea
19 Oct, 24 -
Adium: Icq Не Работает
19 Oct, 24 -
3Cx Для Linux: Облачная Атс Своими Руками
19 Oct, 24 -
Поддержка Php 5.2.7 Прекращена
19 Oct, 24 -
В Беларуси Насчитали 1300 Киберпреступников
19 Oct, 24
