Мне до сих пор не встречались надежные/научные методы определить будет ли продукт успешным на рынке, свободные от кучи «если» меняющих результат на противоположный… приходите что ли к нам на собеседование )
Не совсем так
под гиперконвергентностью обычно понимают построение системы из блоков которые с помощью програмного обеспечения объеденяют ресурсы (compute, network, storage) в общий кластер, и ресурсы эти приносятся унифицированными серверами, добавляя их в общий пул ресурсов
Этому наше решение вполне соответствует
Но что подобные платформы не умеют делать — это предоставлять монолитному (не распределенному) приложению больше ЦПУ и памяти, чем имеется в одном сервере
Там другая методология, она дает другие результаты.
В нашей методике на обоих тестовых виртуалках стоят сравнимые ресурсные ограничения (разница только в имплементации на конкретной платформе). до тех пор пока ресурсов хватает — виртуалка показывает в основном их, а не «остаточную производительность» сервера
Боюсь, в своем методе тестирования вы просто поменяли местами переменные.
Грубо говоря, на первом графике видно уравнение: время = запросы * число_виртуалок
Не совсем так, там другой механизм роста времени (отклика).
До тех пор пока ресурсов хватает, это время отклика в основном определяется суммой latency различных процессов — прохождение запроса по сети, его анализ-обработка, формирование ответа, отсылка ответа и прохождение его по сети.
Анализ, обработка, формирование ответа — эти процессы последовательны по отношению друг к другу, конкретные обработчики как правило однотредовые (таких обработчиков может быть много, но один запрос обрабатывается одним тредом). В результате горизонтальное скалирование ресурсов помогает ему мало — то есть если добавить еще CPU сокетов — время почти не упадет; если увеличить тактовую частоту CPU в два раза — время обработки упадет (почти) в два раза (за вычетом фиксированных latency вроде сетевой).
Поэтому время ответа почти не отличается в ситуациях используется ли 30% или 70% CPU — то есть на начальном этапе нет линейного роста времени ответа с добавлением виртуалок — и на первом графике это видно, скажем при росте от 10 до 80 контейнеров время отклика остается в пределах 0.8 секунды (на KVM за это время растет примерно с тех же 0.8 до 1.1 секунды — опять же, совсем не линейно
Т.е. чем меньше виртуалок, тем больше score, что в общем-то логично :)
Там есть ограничение которое делает график нелинейным — на всех виртуалках стоят ресурсные ограничения сверху. То есть тестируемая виртуалка никогда не покажет производительности сервера целиком. в идеальном мире ее производительность вообще не будет меняться до определенного количества «балластных соседей» (в реальности чуть падает, но нелинейно). И только когда общие ресурсы заканчиваются — на ней это становится заметно.
По поводу зависимости score от количества виртуалок — вот в этой статье есть интересный график
https://virtuozzo.com/performance-expectations-containers/
это vConsolidate (SPECvirt ведет себя аналогично). Его общий score растет (с ростом к-ва VM) пока есть CPU/disk IO ресурсы. Когда они кончаются — score перестает расти и остается относительно линейным. Когда кончается память — score начинает падать из того что система начинает тратить значительно больше ресурсов на resource management (складывание-доставание из swap — типичный пример)
Поэтому ваш метод тестирования дает график на третьей картинке, примерно как на первой картинке, только перевернутый по оси X.
Да, вот это наблюдение очень похоже на правду. Хотя механизмы формирования нагрузок и снятия параметров по сути очень разные — в первом случае мы добавляем соседей и меряем их среднюю производительность; во втором мы плавно увеличиваем «аппетит» соседей, их производительность не меряем но смотрим на производительность одной виртуалки
Но при этом важный для нас параметр — это «эластичность» системы при росте нагрузки. Если нагрузки на всех соседях выросли например на 30% от «рабочей» — насколько упала производительность эталонной системы? это позволяет понять насколько сервера готовы к пиковым или сезонным нагрузкам.
Тут есть параметр который зависит от конкретной системы — то что в статье которую вы привели описано как «борьба с перегрузками». Чем позже наступает момент когда эта борьба становится ресурсоемкой задачей — тем более эластична система по отношению к росту нагрузки
По какой ссылке, простите?
Прошу прощения, ссылку потеряли когда из драфта перетаскивали статью. Поправим. Вот ссылка
У нас не было целей «испортить» конкурентов, мы точно не применяли никаких настроек чтобы сделать их хуже. Вроде бы у инженера который ставил систему есть аккаунт на хабре — я попрошу его зайти и прокомментировать от своего имени
C player/Workstation сравнивать не очень полезно. Это не серверная платформа — она не расчитана на запуск и управление множеством машин на одном сервере, у нее основные оптимизации производительности вокруг других вещей (вроде виртуальной графики), из за этих вещей она заведомо покажет плохие результаты для серверных приложений. Никто серьезно не рассматривает этот продукт для серверов.
С ESX история чуть сложнее — как кстати и написано в статье, по EULA VMware результаты бенчмаркинга нельзя публиковать без согласования с VMware. Мы на самом деле меряли их платформу, но результаты были не очень интересные (не было никаких сюрпизов, производительность отличалась от KVM только в деталях), поэтому решили не тратить ресурсы на эти согласования и убрали их упоминания из финального отчета
Павел, спасибо за отзыв
Онлайн миграция будет в 7ке, когда мы перейдем на ядро с CRIU
Проблема в том что докер поднимает пачку подсистем в ядре которые сейчас check point/resume не покрывает. При этом объем работы такой что писать его сейчас, при том что паралельно делается новое ядро в котором эта часть не используется — работа насмарку — поскольку по оценкам это сойдется почти одновременно
И еще — я бы рекомендовал подождать с продакшеном пока не выйдет апдейт на graph driver с поддержкой нормальных snapshots (мы его делаем прямо сейчас и отдаем в общий код docker ). Текущий vfs создает копии — для тестирования и ограниченного использования (нескольк images, несколько snapshots) годится, но если не ограничивать создание snapshots — съедается неразумное количество места на диске
под гиперконвергентностью обычно понимают построение системы из блоков которые с помощью програмного обеспечения объеденяют ресурсы (compute, network, storage) в общий кластер, и ресурсы эти приносятся унифицированными серверами, добавляя их в общий пул ресурсов
Этому наше решение вполне соответствует
Но что подобные платформы не умеют делать — это предоставлять монолитному (не распределенному) приложению больше ЦПУ и памяти, чем имеется в одном сервере
В нашей методике на обоих тестовых виртуалках стоят сравнимые ресурсные ограничения (разница только в имплементации на конкретной платформе). до тех пор пока ресурсов хватает — виртуалка показывает в основном их, а не «остаточную производительность» сервера
Спасибо кстати за ссылку, интересно
Не совсем так, там другой механизм роста времени (отклика).
До тех пор пока ресурсов хватает, это время отклика в основном определяется суммой latency различных процессов — прохождение запроса по сети, его анализ-обработка, формирование ответа, отсылка ответа и прохождение его по сети.
Анализ, обработка, формирование ответа — эти процессы последовательны по отношению друг к другу, конкретные обработчики как правило однотредовые (таких обработчиков может быть много, но один запрос обрабатывается одним тредом). В результате горизонтальное скалирование ресурсов помогает ему мало — то есть если добавить еще CPU сокетов — время почти не упадет; если увеличить тактовую частоту CPU в два раза — время обработки упадет (почти) в два раза (за вычетом фиксированных latency вроде сетевой).
Поэтому время ответа почти не отличается в ситуациях используется ли 30% или 70% CPU — то есть на начальном этапе нет линейного роста времени ответа с добавлением виртуалок — и на первом графике это видно, скажем при росте от 10 до 80 контейнеров время отклика остается в пределах 0.8 секунды (на KVM за это время растет примерно с тех же 0.8 до 1.1 секунды — опять же, совсем не линейно
Там есть ограничение которое делает график нелинейным — на всех виртуалках стоят ресурсные ограничения сверху. То есть тестируемая виртуалка никогда не покажет производительности сервера целиком. в идеальном мире ее производительность вообще не будет меняться до определенного количества «балластных соседей» (в реальности чуть падает, но нелинейно). И только когда общие ресурсы заканчиваются — на ней это становится заметно.
По поводу зависимости score от количества виртуалок — вот в этой статье есть интересный график
https://virtuozzo.com/performance-expectations-containers/
это vConsolidate (SPECvirt ведет себя аналогично). Его общий score растет (с ростом к-ва VM) пока есть CPU/disk IO ресурсы. Когда они кончаются — score перестает расти и остается относительно линейным. Когда кончается память — score начинает падать из того что система начинает тратить значительно больше ресурсов на resource management (складывание-доставание из swap — типичный пример)
Да, вот это наблюдение очень похоже на правду. Хотя механизмы формирования нагрузок и снятия параметров по сути очень разные — в первом случае мы добавляем соседей и меряем их среднюю производительность; во втором мы плавно увеличиваем «аппетит» соседей, их производительность не меряем но смотрим на производительность одной виртуалки
Но при этом важный для нас параметр — это «эластичность» системы при росте нагрузки. Если нагрузки на всех соседях выросли например на 30% от «рабочей» — насколько упала производительность эталонной системы? это позволяет понять насколько сервера готовы к пиковым или сезонным нагрузкам.
Тут есть параметр который зависит от конкретной системы — то что в статье которую вы привели описано как «борьба с перегрузками». Чем позже наступает момент когда эта борьба становится ресурсоемкой задачей — тем более эластична система по отношению к росту нагрузки
Прошу прощения, ссылку потеряли когда из драфта перетаскивали статью. Поправим. Вот ссылка
С ESX история чуть сложнее — как кстати и написано в статье, по EULA VMware результаты бенчмаркинга нельзя публиковать без согласования с VMware. Мы на самом деле меряли их платформу, но результаты были не очень интересные (не было никаких сюрпизов, производительность отличалась от KVM только в деталях), поэтому решили не тратить ресурсы на эти согласования и убрали их упоминания из финального отчета
Онлайн миграция будет в 7ке, когда мы перейдем на ядро с CRIU
Проблема в том что докер поднимает пачку подсистем в ядре которые сейчас check point/resume не покрывает. При этом объем работы такой что писать его сейчас, при том что паралельно делается новое ядро в котором эта часть не используется — работа насмарку — поскольку по оценкам это сойдется почти одновременно
И еще — я бы рекомендовал подождать с продакшеном пока не выйдет апдейт на graph driver с поддержкой нормальных snapshots (мы его делаем прямо сейчас и отдаем в общий код docker ). Текущий vfs создает копии — для тестирования и ограниченного использования (нескольк images, несколько snapshots) годится, но если не ограничивать создание snapshots — съедается неразумное количество места на диске