Сообщения
Помните не очень давно камрад Umlyaut рассказывал о достижении скоростей порядка 16 Gbps между двумя ВМ на одном ESX(i) - vSphere network test - vmxnet3, Jumbo Frames
А теперь сама VMware рассказывает о достижении аж 27 Gbps - VMware vSphere 4.1 Networking Performance.
Правда, не при любых условиях и не для любой ОС:
Одна из идей документа - если есть приложение, которое генерит трафик в нереальных объемах, то можно воткнуть в ESX(i) до 4х контроллеров 10 Гбит Ethernet, выпустить через них ВМ с этим приложением, и при совпадении некоторых условий она получит канал с пропускной способностью до 36 Гбит\с, что близко к рассчетным значениям для современного железа.
Притом, этот канал можно и разделить между несколькими ВМ - накладных расходов от деления нет или почти нет.
А теперь сама VMware рассказывает о достижении аж 27 Gbps - VMware vSphere 4.1 Networking Performance.
Правда, не при любых условиях и не для любой ОС:
Одна из идей документа - если есть приложение, которое генерит трафик в нереальных объемах, то можно воткнуть в ESX(i) до 4х контроллеров 10 Гбит Ethernet, выпустить через них ВМ с этим приложением, и при совпадении некоторых условий она получит канал с пропускной способностью до 36 Гбит\с, что близко к рассчетным значениям для современного железа.
> 16 Mbps между двумя ВМ
ОтветитьУдалить> 27 Mbps
Опять в порядках ошибка? ;)
ой! спасибо.
ОтветитьУдалитьсделаю вид, что это проверка на внимательность чтения :)
Ну, Михаил, я дождался, пока Вас поймают на "мегабитах-гигабитах", после чего решил и свою лепту внести. :)))
ОтветитьУдалить>Umlayt
Мой ник (и подпись) обычно выглядят несколько иначе... :D:D:D
С уважением,
Umlyaut.
быстро поднятое не считается упавшимм!
ОтветитьУдалитьЗабавный документик... :)
ОтветитьУдалить27Gb/s Варя получает между линуховыми VM-ками c использованием LRO (Large Receive Offload) - фактически, функциoнального аналога увеличения MTU:
получаем при равных pps (Packets per second) бOльший трафф на интерфейсе.
Немного удивило вот это (см. under Figure 3):
===
In the Windows VM-to-VM rests, up to 1500-byte (standard Ethernet MTU size) packets are transferred from one VM to other.
In contrast, LRO allows packets up to 64KB in size to be transferred from one Linux VM to the other.
===
У меня создалось впечатление, что тесты гонялись без включения JF на vSwitch`ах (т.е. на стандартных полуторакилобайтных пекетах), что, собственно,
как-бы подтверждается получением на 2008R2 результата в районе 8-9Gb/s
(я в своём тесте намерил столько же на стандартных фреймах на хосте того же класса (только чуточку "экстенсивнее" устроенном).
Соответственно, линух-VM-ки, использующие некоторое (проприетарное?) Варевское LRO, покрыли вин-VM-ки, как бык овцу.
Однако было бы небезынтересным посмотреть на результат этого же теста, но с включенными JF на хосте (и, соответственно, VMXNET3).
И совсем любопытственно было бы "подкрутить" LRO на 9К-пакеты (буде таковое возможно) и сравнить (для линух-VM) результаты - "9К-LRO w/o JF" vs. "9K-JF w/o LRO".
* * *
Ещё немного размышлений подкинул блок Figure 5 (VM-to-native).
Во-первых, результат в 36Gb/s на мультифизике может свидетельствовать о том, что одиночной VM-ке хватает ресурсов хоста (данной конфигурации)
для максимальной скорострельности, а вот на пару VM-ок (и обеспечении траффика между ними) такого хоста уже маловато (трафф съезжает до 27Gb/s).
По идее более скоростной хост (по гигагерцам и ПСП) мог бы показать больше на VM-to-VM.
Во-вторых, ОЧЕНЬ интересуют детали теста - в частности, метод балансировки траффика в варианте VM-to-native.
Этот интерес связан с тем, что результат в 36Gb/s косвенно даёт понять, что используются все четыре pNIC`a,
а наблюдаемое масштабирование при использовании 2-х и 4-х vNIC на VM-ках - что и vNIC-и тоже нагружаются все.
* * *
Вообще некоторое послевкусие после прочтения данного документа остаётся.
Например, в одном месте (там, где похваляются результатом лин-Vm с LRO) мелькает ссылка на то, что эти достижения сравнимы
с показателями траффика между VM`ками через VMCI-интерфейс... и даже даётся ссылка на Варин документ 10075 (VMCI Socket Perfomance).
Однако в помянутом документе фигурирует тест с помощью портированного под VMCI-сокет Netperf/Netserver.
А про то, как использовать данный интерфейс без написания специальных "шлюзов" (как это модно говорить - "прозрачным образом") индустрия пока не знает...
Опять же, упоминая LRO, нелишним было бы в референсах дать ссылу на соответствующую Варину доку по этой технологии.
Короче, маркетоложеством каким-то отдаёт... :)
С уважением,
Umlyaut.
по поводу балансировки - у меня сложилось впечатление что давали каждой ВМ по 4 vNIC, биндили с pNIC один к одному, получается балансировка была средствами гостя.
ОтветитьУдалить>балансировка была средствами гостя
ОтветитьУдалитьВопрос терминологии... :)
"Гость" (согласно схеме стенда) - это физ.машина в к-ве двух штук. На каждого "гостя" идёт пара линков по 10Gb от pNIC`ов хоста Сферы.
Соответственно, в тесте с 4-мя vNIC-ами на single VM (по Fig.5) должны участвовать все pNIC`и хоста - т.е. обе физ.машины-гости.
Видимо, на каждом "госте" находился генерирующий траффик Netperf, а на VM-ке стоял принимающий Netserver - и балансировк, скорее всего, задавалась жёстко по нескольким тредам и парам IP Netserver - IP Netperf (1,2).
Я же говорю - мутная дока, невнятная... :D
С уважением,
Umlyaut.
про мутность соглашусь - есть вопросы к документу.
ОтветитьУдалить