вторник, 22 марта 2011 г.

vSphere network test - vmxnet3

Со мной и с вами поделились очень интересным исследованием.
Из переписки:
 
 
По следам вот этой дискуссии на Вареруссишгруппенфоруме - Агрегирование каналов на стороне гостевой ос.
Топикстартер интересовался толстым-толстым каналом "для виртуальной машины". По ходу дела выяснилось, что Team-vNIC на vSwitch`e SLA не отрабатывает (как это заявлено для Team-pNIC, т.е. физ.аплинков).
Сошлись на том, что можно использовать VMXNET3 и всё будет ОК.
А я вдруг подумал - а насколько ОК? Что он может, этот самый VMXNET3? И решил погонять эту тему на стенде... Итак...

Стенд:

хост Сферы - 2 x Xeon 5620, 32GB RAM, ESXi 4.1U1 standalone
VM`ки - пара 2008R2 EE SP1 (2 vCPU, 6GB vRAM) с VMXNET3-интерфейсом на каждой (c IP MTU=1500); vNIC`и подключены к vSwitch1 c MTU=1500 без физ.аплинков.
clip_image002
Методика:
Тестирование проводилось с помощью известной утилиты NTttcp (v.30) в 64-битном варианте (NTttcp_x64.exe).
Каждый тест запускался пятикратно, в зачёт шёл лучший результат.
 

Часть I.

1.

Сначала провёл тестирование, запуская утилиту с такими же параметрами, что и в большинстве опубликованных ранее в инете тестов:
ntttcpr -m 1,0,192.168.1.58 -a 4 -l 256K -n 100000 -f s.txt
Единственное, что позволил себе изменить - это на порядок увеличить к-во тестового траффика ("-n 100000"),
бо при "-n 10000" ("те" тесты делались на гигабите) тест проскакивал слишком быстро, а мне хотелось, чтобы трафф "устоялся".
Получил вот что:
================================================================================
Date: 3-20-2010
Time: 20:40:0
Parameters: Number_Of_Threads=1 Number_Of_Buffers=100000 Length_Of_Buffers=262144 IOs=4 Realtime=33.750
Network Characteristics I: Pkts/Intr=30 Total_Bytes=26214.2 Avg_Frame_Size=1460
Network Characteristics II: Pkts_Sent=766253 Pkts_Received=17954923 Rexmits=0 Errors=0
Throughput(Mbps)=6213.73 CPU=42.4% Cycles/Byte=2.62 Interrupts/Sec=17506
================================================================================
В дальнейшем, чтобы не загромождать отчёт, буду приводить только последнюю строчку - с собственно скоростью линка.

2.

Далее прогнал этот же тест, только с несколькими тредами ("-m 2, -m 4, -m 8"). Получил следующие результаты:
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 4 -l 256K -n 100000 -f s.txt
======================== 1, 2, 4, 8 ============================================
Throughput(Mbps)=6213.73 CPU=42.4% Cycles/Byte=2.62 Interrupts/Sec=17506
Throughput(Mbps)=7515.01 CPU=44.1% Cycles/Byte=2.25 Interrupts/Sec=12579
Throughput(Mbps)=7983.15 CPU=45.5% Cycles/Byte=2.19 Interrupts/Sec=8685
Throughput(Mbps)=8256.33 CPU=47.9% Cycles/Byte=2.23 Interrupts/Sec=7318
===========================================================================
Первой строкой я повторил результат для одного треда - для наглядности.
Здесь видно, как растёт пропускаемый траффик - в восьмитредовом варианте он уже доходит до 1ГБайта/сек.
Одновременно растёт и загрузка процессора (CPU 0 - по условию теста) - почти 50% это суммарная для обоих vCPU, а применительно к vCPU 0 она доходит почти до 100%.
Отмечу, что это на стороне приёмника (на передатчике загрузка процессоров (суммарная) болтается в районе 10-11% (в интервале от 9 до 12)) - что и понятно, т.к. приёмнику приходится выполнять все "offload"-операции VMXNET3 силами собственного процессора.

3.

Вчитавшись как следует в документацию к утилите NTttcp, обнаружил там интересную рекомендацию - для тестирования 10-гигабитных линков использовать бОльшее к-во "received buffers" - а именно 16.
Повторил тест №2 (точно так же с 1,2,4 и 8 тредами) с пар-ром "-а 16":
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 16 -l 256K -n 100000 -f s16.txt =
======================== 1, 2, 4, 8 === -a 16 ===================================
Throughput(Mbps)=6805.93 CPU=46.0% Cycles/Byte=2.60 Interrupts/Sec=27097
Throughput(Mbps)=7633.75 CPU=45.6% Cycles/Byte=2.29 Interrupts/Sec=14933
Throughput(Mbps)=8251.03 CPU=46.5% Cycles/Byte=2.16 Interrupts/Sec=9107
Throughput(Mbps)=8615.52 CPU=48.3% Cycles/Byte=2.15 Interrupts/Sec=6966
==========================================================================
Что тут сказать - видимо, иногда RTFM не роскошь, а средство передвижения (в сторону лучшей производительности, ага!)...:)

4

Все предыдущие тесты делались на одном vCPU 0 (включая и мультитредовые) - параметр "-m x,0,IP".
Тот же TFM на утилиту, в частности, говорит о возможности разделения тредов по нескольким ядрам - для этого нужно параметр "-m" прописать по-другому:
ntttcpr -m 1(2,4),0,IP 1(2,4),1,IP ... ...
Тогда на каждое ядро должно приходиться по 2(4,8) тредов:
= ntttcpr -m 1(2,4),0,192.168.1.58 1(2,4),1,192.168.1.58 -a 16 -l 256K -n 100000 -f s16m.txt =
======================== -, 2, 4, 8 === -a 16 === -m IP IP ======================
-
Throughput(Mbps)=7593.38 CPU=49.0% Cycles/Byte=2.48 Interrupts/Sec=15911
Throughput(Mbps)=8341.46 CPU=51.3% Cycles/Byte=2.36 Interrupts/Sec=10253
Throughput(Mbps)=8775.02 CPU=53.5% Cycles/Byte=2.34 Interrupts/Sec=7234
=======================================================================
М-да, разница не сказать чтоб очень разительная - один-полтора процента (и не ясно - то ли скудный прирост, то ли погрешность эксперимента).
Да и по таскменеджеру машины-приёмника видно было, что львиная доля нагрузки по-прежнему падает на vCPU 0 - нагрузка на vCPU 1 подросла, но не сильно.
На машине передатчике суммарная загрузка стала 12-13%, но "перекос" в сторону vCPU 0 по-прежнему никуда не делся.

5.

Строго говоря, "мультипроцессорное" распределение тредов в TFM`е к утилите предполагает использование не одного, а нескольких IP:
ntttcpr -m 1(2,4),0,IP1 1(2,4),1,IP2 ... ...
Присвоил VMXNET3-интерфейсам машин вторые IP-адреса (57 приёмнику и 59 передатчику) и повторил тест №4:
= ntttcpr -m 1(2,4),0,192.168.1.58 1(2,4),1,192.168.1.59 -a 16 -l 256K -n 100000 -f s16mm.txt =
======================== -, 2, 4, 8 === -a 16 === -m IP1 IP2 ====================
-
Throughput(Mbps)=7695.32 CPU=50.0% Cycles/Byte=2.49 Interrupts/Sec=15678
Throughput(Mbps)=8365.41 CPU=51.2% Cycles/Byte=2.35 Interrupts/Sec=9841
Throughput(Mbps)=8830.10 CPU=53.7% Cycles/Byte=2.34 Interrupts/Sec=7546
======================================================================
В общем, примерно то на то и выходит - в том числе и с загрузкой на vCPU приёмника и передатчика.
То ли я чего-то не понимаю в реализации multiprocessor-multithreding у данной утилиты, то ли в моём случае почти без разницы раскладка тредов по процессорам.
Собственно, первую часть тестирования на этом можно было бы и завершить, но я решил сделать сравнение – прогнать те же тесты на тех же виртуалках, но на другом железе: entry-level-хосте Сферы на C2Q Q9550 (4x2.83GHz) / 16GB RAM.
Остальные условия те же (включая отдельный vSwitch NETTEST без физ.аплинков).
Вначале повторил тест №3:
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 16 -l 256K -n 100000 -f s16.txt =
======================== 1, 2, 4, 8 === -a 16 ===================================
Throughput(Mbps)=3388.43 CPU=43.7% Cycles/Byte=5.85 Interrupts/Sec=9172
Throughput(Mbps)=3717.48 CPU=47.5% Cycles/Byte=5.79 Interrupts/Sec=6746
Throughput(Mbps)=3702.41 CPU=49.0% Cycles/Byte=5.99 Interrupts/Sec=3960
Throughput(Mbps)=3566.10 CPU=49.7% Cycles/Byte=6.31 Interrupts/Sec=4913
==========================================================================
Сразу видно, насколько показатели скромнее предыдущих – десктопное железо даже при номинально большей частоте CPU проигрывает серверному.
Причём на четырёх тредах мы упёрлись (вышли на плато), а при восьми – даже слегка потеряли (на таск-менеджере у vCPU 0 в этом месте график загрузки практически слился с линией 100% - скрин я делать поленился, но и так ясно должно быть).
Похоже, много тредов весьма хорошо прогружают десктопный проц.
Для сравнения прогнал 4 и 8 тредов по-другому – с распределением по IP и vCPU (как в тесте №5):
= ntttcpr -m 2(4),0,192.168.1.58 2(4),1,192.168.1.59 -a 16 -l 256K -n 100000 -f s16mm.txt =
======================== -, -, 4, 8 === -a 16 === -m IP1 IP2 ====================
-
-
Throughput(Mbps)=3567.30 CPU=61.1% Cycles/Byte=7.77 Interrupts/Sec=4078
Throughput(Mbps)=3693.90 CPU=66.3% Cycles/Byte=8.13 Interrupts/Sec=3435
=====================================================================
Ясности это, правда, не прибавило, хотя этот тест я прогнал дважды (по пять итераций для каждого к-ва тредов, согласно условию). Решил для себя, что много тредов – это не для такого хоста… J
И промежуточный вывод по итогам первой части – всё-таки откровенно пренебрегать мощностью/производительностью аппаратной части не стОит: как мы видим, потребность в той же «процессорной дури» может быть весьма высокой.
Это я к тому, что на форуме и в блоге периодически встречаю высказывания о желании устроить (пусть даже и тестовый, но не только) хост Сферы на, стыдно сказать, «атомных» системах…

Часть II.

UPD. Новая часть 2 - vSphere network test - vmxnet3, Jumbo Frames

Во второй части тестирования я решил проверить влияние Jumbo Frame`ов на производительность сети – а конкретно в том же акцепте, что и в первой части, т.е. между двумя виртуалками на 10Gb-ном линке (между двумя VMXNET3).
Понятно, что для проверки нужно задать режим JF=ON (9000) на vNIC`ах VMXNET3 (в свойствах драйвера сетевого подключения АКА карты) и включить JF на тестовом vSwitch1 (NETTEST) командой esxcfg-vswitch –m 9000 vSwitch1.
(После этого можно ещё сравнить производительность при стандартном и увеличеннном IP MTU в виртуалках, но вначале, всё же, хотелось разобраться с JF).
ОК, JF включен и на vNIC`ах, и на vSwitch1, делаю проверку (как указано в Книге) с передатчика (1.58) на приёмник (1.56):
ping –f –l 8972 192.168.1.56
и получаю облом:
Packet needs to be fragmented but DF set
Пробую обратно - с 1.56 на 1.58 – то же самое.
Пробую без флага f (без запрета фрагментации) – пинги проходят.
Т.е. большие (8972) ICMP-пакеты без фрагментации идти между виртуалками не хотят.
Переключаю обе тестовые виртуалки на vSwitch0 (VM Network) с аплинком и включаю JF на этом свитче. Пробую
pingfl 8972 192.168.1.56(58)
с физ.машины из этой же подсети (JF на pNIC`е этой физ.машины включен (9014).
Нефрагментированные большие пинги проходят от физ.машины до каждой из тестовых виртуалок.
Пробую пингануть обратно – из тестовой виртуалки физ.машину:
ping –f –l 8972 192.168.1.13
и опять получаю
Packet needs to be fragmented but DF set
Ещё раз делаю пинг с виртуалки на «физику», но уже без запрета фрагментации – всё прекрасно проходит.
По всему выходит так, что JF на Вирт.коммутаторе работают как-то криво – vSwitch пропускает без фрагментации пакеты, входящие в vSwitch из pNIC`ов и не пропускают входящие из vNIC`ов.
Беглая проверка показала, что на хосте ESXi 4.0U1 JF ведут себя абсолютно так же.
Лично у меня этому объяснения пока нет – констатирую голый факт.
Если кто-то сможет объяснить это явление – вэлкам! :)
* * *
Собственно после облома с JF тестирование было прекращено – ну какой интерес лупить большими фреймами, если они всё-равно будут фрагментированы.
Вот как-то так…
С уважением,
Umlyaut.

83 комментария:

  1. День добрый, могу ошибаться, но JF нормально работают если включать в момент создания виртуального свитча, в уже созданном включить JF можно, но не работает. Хотя мы долго не разбирались почему не заработало и списали на ошибку в конфигурации :). Проверил сейчас большие пинги нормально ходят как между виртуалками так и к физическому оборудованию. Попробуйте пересоздать свитч, интересно же чем все закончится. Заранее спасибо.

    ОтветитьУдалить
  2. Yuri wrote:
    >могу ошибаться, но JF нормально работают если включать в момент создания виртуального свитча, в уже созданном включить JF можно, но не работает

    Пруфлинком не поделитесь?

    Дело в том, что в Книге этого нет.
    Есть описание особенности использования JF на VMkernel - ага, там велено создавать его (из командной строки) с явным указанием MTU (9000). Но речь идёт именно о VMkernel, а не о vSwitch.

    >Попробуйте пересоздать свитч, интересно же чем все закончится.

    Ни разу не приходилось "создавать свитч" из CLI. Напомните команду или пошлёте в Гугель? ;)

    С уважением,
    Umlyaut.

    P.S. В любом случае это не фичя, а бага. ИМХО.

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

    1. esxcfg-vsvitch -a vSwitchX
    2. esxcfg-vswitch -m 9000 vSwitchX
    3. Из клиента добавить/настроить портгруппы

    ОтветитьУдалить
  4. ссылки на "Книгу" как на великую книгу мне конечно льстят, но как истину в последней инстанции воспринимать ее неправильно.

    судя по описанию - действительно похоже на багу.

    создание коммутатора из командной строки:
    esxcfg-vswitch -a vSwitch10:56, а как mtu сразу указать не помню, что то вроде -m 9000

    ОтветитьУдалить
  5. Yuri, ваш алгоритм (1,2,3) по сути ничем не отличается от того, что делал я, только шаг №1 был сделан из гуя Сферического Клиента. Ладно, ща попробую создать vSwitch консольно сразу с mtu=9000 и посмотреть, есть ли разница...

    * * *
    Михаил, не сомневайтесь - Книга действительно неплохая получилась (хотел написАть "хорошая", но Вы ведь опять начнёте опускать голову и смущённо ковырять пол носком туфли). :D:D:D

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  6. UPD:

    Так, создал на тестовом хосте ещё один vSwitch - vSwitch2. Создавал, по совету ув.Yuri, из командной строки (ssh-сессия непосредственно на хост):

    esxcfg-vswitch -a vSwitch2:56

    Замечу в скобках, что СРАЗУ задать ещё и размер MTU на "новорождённом" vSwitch`е команда не даёт (на попытку скоманодовать "esxcfg-vswitch -a -m 9000 vSwitch2:56" ругается, что, мол,
    "Error, only one command can be performed at a time."). Поэтому размер MTU пришлось задавать второй командой - esxcfg-vswitch -m 9000 vSwitch2.
    После этого на новом вкоммутаторе гуём была создана портгруппа NETTEST2, тестовые виртуалки были подключены к ней... и ничего не изменилось - "большой" пинг между тестовыми VM`ками по-прежнему ругается:

    Packet needs to be fragmented but DF set

    ===
    Я готов признать, что делаю что-то не так - если мне кто-нибудь скажет, как сделать "так".
    Не смею подозревать ув.Yuri в том, что ему показалось, будто у него JF в такой же ситуации работают (без фрагментации), но мне отсюда плохо видно, в чём у нас с ним разница.

    Может, коллеги попробуют JF между VM`ками у себя и что-то прояснят?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  7. Так сказать длинный пинг между VM'ками

    c:\>ping -f -l 8970 192.168.140.253

    Pinging 192.168.140.253 with 8970 bytes of data:
    Reply from 192.168.140.253: bytes=8970 time=2ms TTL=128
    Reply from 192.168.140.253: bytes=8970 time<1ms TTL=128
    Reply from 192.168.140.253: bytes=8970 time<1ms TTL=128
    Reply from 192.168.140.253: bytes=8970 time=1ms TTL=128

    Ping statistics for 192.168.140.253:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 0ms

    ОтветитьУдалить
  8. Yuri, а что у Вас за хосты? Ну, там, ESX/ESXi, версия, патчи, может, вендорообточенные?

    А VM`ки какие?

    И, кстати, у Вас размер пакета не 8972 (как в Книге), а 8970. А с 8972 попробуйте?

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

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  9. Этот комментарий был удален автором.

    ОтветитьУдалить
  10. ping -f -l 8972 192.168.140.253

    Reply from 192.168.140.253: bytes=8972 time<1ms TTL=128

    Ping statistics for 192.168.140.253:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 17ms, Average = 8ms

    хосты - ESX 4.1.0 260247
    машинки на данный момент находятся на разных хостах

    ОтветитьУдалить
  11. щас попробую воспроизвести ваш тест, только поставлю на вторую машинку vmxnet3 :)

    ОтветитьУдалить
  12. Umlyaut, попробуйте после настроки jumbo frames на "физике" (vNIC,vSwitch) увеличить IP MTU на vNIC. Плюс, буду банально занудным, но попробовать этот вариант с перезагрузкой виртуалки.

    bond_jimme

    ОтветитьУдалить
  13. Да, и спасибо за опыты/статью: очень интересно было знать, обеспечивает ли VMXNET3 в реальных условиях честные 10Gbps. Cудя по "Throughput(Mbps)=8830.10" - да.

    bond_jimme

    ОтветитьУдалить
  14. Yuri>хосты - ESX 4.1.0 260247

    Ага, до U1. Неужели в этом разница?

    >машинки на данный момент находятся на разных хостах

    У-ууу, так нечестно... :)))
    А между хостами что - "физика" 10GBit?

    Попробуйте-ка по-моему: обе VM`ки на один хост, VMXNET3 на них, повключать JF - и гонять между ними большие пинги...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  15. 2 bond_jimme:

    >попробуйте после настроки jumbo frames на "физике" (vNIC,vSwitch) увеличить IP MTU на vNIC

    не совсем понял, отчего Вы называете vNIC и vSwitch "физикой"...

    По поводу "увеличить IP MTU"... что-то я сильно сомневаюсь в необходимости такого колдунства.

    Это лишь увеличит размер IP-пакета, но при чём тут наличие или отсутствие фрагментации на втором уровне (ethernet-фреймы) при использовании JF ?
    При стандартном IP-пакете (~1500) каждый JF будет содержать шесть таких пакетов, а при IP MTU = 9000 получим "1 фрейм - 1 пакет". Но ведь в данной ситуации проблема в том, что система vNIC-vSwitch не пропускает JF без фрагментации - какая разница, сколько (и каких) IP-пакетов будет содержаться во фрагментированном фрейме?

    Не, мне, конечно, не жалко пошаманить, но хотелось бы получить от Вас чуть более развёрнутое обоснование именно такого решения... :)

    С уважением,
    Umlyaut.

    P.S. И спасибо на добром слове - ага, 10Gbit-линки "внутри" Сферы действительно достойно выступают... на достаточно мощном железе... :D

    ОтветитьУдалить
  16. Все работает без фрагментации, в независимости от того,как создаешь свич(пробовал и руками и клиентом)

    ОтветитьУдалить
  17. 2 eworm:

    Условия теста те же ("внутри" или "изнутри", VMXNET3, флаг -f)? Версия Сферы?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  18. все внутри, флаг стоит
    версию написал.

    ОтветитьУдалить
  19. 2 eworm:
    Странная закономерность вырисовывается: и у Вас, и у Yuri одна и та же версия - 4.1 260247 (ДО U1), а я проверял на 4.1 U1 (348481). Прямо впору откатиться назад и перепроверить... :(

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  20. А на официальном форуме не хотите тему создать?

    ОтветитьУдалить
  21. Прошу прощения за неформатированный вывод,
    признаться честно ожидал большего :)

    ntttcpr -m 1,0,192.168.140.253 -a 4 -l 256K -n 100000
    Thread Realtime(s) Throughput(KB/s) Throughput(Mbit/s) Avg Bytes per Completion
    ====== =========== ================ ================== ========================
    0 148.547 176470.368 1411.763 122874.959
    Total Bytes(MEG) Realtime(s) Average Frame Size Total Throughput(Mbit/s)
    ================ =========== ================== ========================
    26214.143744 148.547 8951.426 1411.763
    Total Buffers Throughput(Buffers/s) Pkts(recv/intr) Intr(count/s) Cycles/Byte
    ============= ===================== =============== ============= ===========
    99999.022 673.181 7 2794.02 17.1
    Packets Sent Packets Received Total Retransmits Total Errors Avg. CPU %
    ============ ================ ================= ============ ==========
    239041 2928488 3 7 50.33
    ntttcpr -m 2,0,192.168.140.253 -a 4 -l 256K -n 100000
    Thread Realtime(s) Throughput(KB/s) Throughput(Mbit/s) Avg Bytes per Completion
    ====== =========== ================ ================== ========================
    0 174.750 150009.535 1200.076 112339.366
    1 174.750 149822.549 1198.580 112650.229
    Total Bytes(MEG) Realtime(s) Average Frame Size Total Throughput(Mbit/s)
    ================ =========== ================== ========================
    52395.656704 174.750 8952.764 2398.657
    Total Buffers Throughput(Buffers/s) Pkts(recv/intr) Intr(count/s) Cycles/Byte
    ============= ===================== =============== ============= ===========
    199873.568 1143.769 8 3910.43 10.2
    Packets Sent Packets Received Total Retransmits Total Errors Avg. CPU %
    ============ ================ ================= ============ ==========
    632025 5852456 3 7 51.16
    ntttcpr -m 8,0,192.168.140.253 -a 4 -l 256K -n 100000
    Thread Realtime(s) Throughput(KB/s) Throughput(Mbit/s) Avg Bytes per Completion
    ====== =========== ================ ================== ========================
    0 594.625 43909.634 351.277 112885.130
    1 594.625 44047.854 352.383 112503.082
    2 594.625 44085.232 352.682 112390.483
    3 594.625 44043.852 352.351 112655.933
    4 594.625 43983.889 351.871 112780.055
    5 594.625 44031.810 352.254 112774.544
    6 594.625 43998.972 351.992 112688.499
    7 594.625 44074.772 352.598 112589.728
    Total Bytes(MEG) Realtime(s) Average Frame Size Total Throughput(Mbit/s)
    ================ =========== ================== ========================
    209412.662784 594.625 8954.295 2817.408
    Total Buffers Throughput(Buffers/s) Pkts(recv/intr) Intr(count/s) Cycles/Byte
    ============= ===================== =============== ============= ===========
    798845.912 1343.445 13 2834.16 9.7
    Packets Sent Packets Received Total Retransmits Total Errors Avg. CPU %
    ============ ================ ================= ============ ==========
    2780012 23386840 17 29 56.82

    ОтветитьУдалить
  22. машинки на одном хосте, вот только помимо них там еще с 4 десятка машин занятых непонятным полезным делом :), как и говорил автор основная нагрузка на первый vCPU хотя второй тоже не курит.

    ОтветитьУдалить
  23. коллеги, доблестный первоиспытатель уже создал тему на форуме -
    http://communities.vmware.com/thread/307418?tstart=0

    думаю там будет удобнее чем в местных комментариях.

    вопрос только удобства - мне не жалко, разумеется :)))

    ОтветитьУдалить
  24. 2Umlyaut:

    Вот это сообщение "Packet needs to be fragmented but DF set" может выдать либо локальный хост, либо какой-нибудь машрутизатор по пути следования.

    Маршрутизаторов нет. Остается локальный стек TCP/IP

    bond_jimme

    ОтветитьУдалить
  25. как ни странно общую пропускную способность больше 3Gb/s так и не удалось выжать :(

    ОтветитьУдалить
  26. 2 bond_jimme:

    Что это сообщение может выдать "либо хост, либо хоп на маршруте" - согласен.
    Что это выдаёт "локальный стек TCP/IP" - нет.

    Напомню немного, что утилита ping работает не с IP, а с другим протоколом сетевого уровня - ICMP. Размер пакета ICMP регулируется опцией "-l", запрет фрагментации пакета - опцией "-f".

    Вы же предлагали изменить (в ОС виртуалок) MTU для IP, что никак не связано ни с проверкой по ICMP, ни с собственно уровнем 2 (канальным) с его настройками размера кадра ethernet...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  27. Yuri>как ни странно общую пропускную способность больше 3Gb/s так и не удалось выжать :(

    А что за хосты у Вас? И чем они ещё в это время занимались? У меня столько даёт однопроцовый хост на Q9550 (см.заметку).

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  28. UPD:


    На том же самом стенде попробовал иначе

    - добавил в каждую из тестовых машинок по адаптеру E1000, задизейблил VMXNET3-и интерфейсы и прогнал большие пинги. Всё отлично!
    Пинги идут и снаружи к VM, и внутри между VM`ок, и наружу от VM`ок на "физику". Уже теплее - значит, дальше буду грешить на VMXNET3...

    Надо попробовать VMXNET3 на гигабите, VMXNET2, ну и повторить исходный тест (VMXNET3-10G-JF) на "доапдейтном" ESXi4.1

    //... ушёл думать... :) //

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  29. 2Umlyaut:
    >Напомню немного, что утилита ping работает не >с IP, а с другим протоколом сетевого уровня - >ICMP

    Ээээ... Вы точно в этом уверены? Вы не путаете IP c TCP/UDP/IPSec?

    bond_jimme

    ОтветитьУдалить
  30. 2 bond_jimme:

    да, я, возможно, немного неуклюже выразился... :)

    Конечно, ICMP-пакет есть IP-пакет со специфическим заголовком.
    Я же хотел сказать, что не уверен в том, что настройка IP MTU имеет смысл - в данном ("мгновенном") случае роль таковой настройки играет флаг -l.
    Ну и повторюсь - у нас сейчас проблема не в размере пакета 3-го уровня (IP или ICMP-IP), а в том, что в качестве "транспорта" канального уровня "большим" пакетам 3-го уровня "подают" стандартные пакеты уровня 2-го - да ещё и не разрешают "3-м" пакетам расфасоваться по "2-м".

    BTW, чуть выше я уже указал, что "большие пинги" нормально проходят во всех направлениях, если я использую вместо VMXNET3 адаптер Е1000 - причём IP MTU я со стандартных 1500 при этом НЕ менял... :)

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  31. 2Umlyaut:

    Прошу прощения за занудство, а можете показать
    netsh interface ipv4 show interfaces с машин в проблемной конфигурации (с VMXNET3)?

    bond_jimme

    ОтветитьУдалить
  32. Что-то вообще странное творится:
    у меня jumbo frames w2k8-64 нормально заработало на vSwitch c MTU=1500.

    C:\Users\Administrator>ping 192.168.0.1 -l 8500 -f

    Pinging 192.168.0.1 with 8500 bytes of data:
    Reply from 192.168.0.1: bytes=8500 time<1ms TTL=128
    Reply from 192.168.0.1: bytes=8500 time<1ms TTL=128
    Reply from 192.168.0.1: bytes=8500 time<1ms TTL=128
    Reply from 192.168.0.1: bytes=8500 time<1ms TTL=128

    Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

    C:\Users\Administrator>


    Версия ESX - 4.0.0.261974

    bond_jimme

    ОтветитьУдалить
  33. 2 bond_jimme:

    Пожалуйста:

    Idx Met MTU State Name
    --- ---- ------ ---------- -----------
    1 50 4294967595 connected Loopback Pseudo-Interface 1
    10 10 1500 connected Local Area Connection

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  34. 2Umlyaut:

    Ничего не делал. "Раскатал" w2k8 из темлейтов и изменил параметр jumbo frames в свойствах VMXNET.
    Результат постом выше. А вот что по поводу IP MTU

    C:\Users\Administrator>netsh interface ipv4 show interfaces

    Idx Met MTU State Name
    --- ---------- ---------- ------------ ---------------------------
    1 50 4294967295 connected Loopback Pseudo-Interface 1
    17 5 9000 connected Local Area Connection 2


    C:\Users\Administrator>


    Види

    bond_jimme

    ОтветитьУдалить
  35. Ваше
    10 10 1500 connected Local Area Connection

    Мое

    17 5 9000 connected Local Area Connection 2


    Думаю, у остальных коллег также как и у меня.

    IP MTU...

    bond_jimme

    ОтветитьУдалить
  36. 2eworm, Yuri:

    Коллеги, покажите, пожалуйста,
    netsh interface ipv4 show interfaces


    bond_jimme

    ОтветитьУдалить
  37. 2 bond_jimme:
    >Версия ESX - 4.0.0.261974

    А с ESX я вообще не готов сравнивать - у меня ESXi...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  38. 2 bond_jimme:

    >Мое
    >17 5 9000 connected Local Area Connection 2
    >Думаю, у остальных коллег также как и у меня.
    >IP MTU...

    Тогда Вам пара вопросов (уже задававшихся, правда)

    - почему с таким же штатным IP MTU=1500 нормально гоняются "большие пинги" на адаптерах (VM`ок) Е1000 ???

    - почему с таким же штатным IP MTU=1500 "большие пинги" проходят с "физики" на VMXNET3, но не обратно?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  39. 2Umlyaut:

    - почему с таким же штатным IP MTU=1500 нормально гоняются "большие пинги" на адаптерах (VM`ок) Е1000 ???

    У меня для E1000 c jumbo frames

    C:\Users\Administrator>netsh interface ipv4 show interfaces

    Idx Met MTU State Name
    --- ---------- ---------- ------------ ---------------------------
    1 50 4294967295 connected Loopback Pseudo-Interface 1
    11 10 9000 connected Local Area Connection

    - почему с таким же штатным IP MTU=1500 "большие пинги" проходят с "физики" на VMXNET3, но не обратно?

    А можно посмотреть?


    bond_jimme

    ОтветитьУдалить
  40. 2Umlyaut:

    > - почему с таким же штатным IP MTU=1500 "большие пинги" проходят с "физики" на VMXNET3, но не обратно?

    > А можно посмотреть?

    Имеется в виду, можно ли увидеть netsh interface ipv4 show interfaces с физической машины?

    bond_jimme

    ОтветитьУдалить
  41. bond_jimme>У меня для E1000 c jumbo frames


    А у меня для Е1000 MTU 1500, но (при включенных JF на Е1000 и vSwitch`е между ними) "большие пинги" без фрагментации проходят. Попробуйте сменить IP MTU на 1500 и проверить "большие пинги" между Е1000-ми...

    bond_jimme>А можно посмотреть?

    Что именно?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  42. У меня физ.машина - 2003ЕЕ (собственно, 2008-й "физики" у меня вообще нет).
    Но IP MTU у 2003-й "физики" - базовая, 1500. JF на сетевушке "физики" - 9014. Большой Пинг с "физики" на другую "физику" и на VM`ку проходит, с VM`ки на любую "физику" или на другую VM`ку - нет (т.е., "нет без фрагментации - с ней проходит).

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  43. 2Umlyaut:

    >А у меня для Е1000 MTU 1500, но (при включенных JF на Е1000 и vSwitch`е между ними)

    Давайте уточним: данной фразой имеется в виду, что значение "1500" показывает команда "netsh interface ipv4 show interfaces", или, что после
    включения JF Вы не делали никаких дополнительных действий для увеличения IP MTU и считаете, что оно осталось прежним?


    bond_jimme

    ОтветитьУдалить
  44. 2 bond_jimme:

    Ага, я понял, куда Вы клоните... :)

    Да, при переключении параметра JF в свойствах адаптера Е1000 VM`ки (2008R2EESP1) команда netsh... показывает выставленное значение пар-ра.

    А вот в случае VMXNET3 я переключаю пар-р JF в 9000, но команда по-прежнему выводит MTU для этого интерфейса равное 1500. Может, тут собака порылась?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  45. 2Umlyaut:

    Как и ожидалось, после принудительной смены IP MTU у E100 на 1500


    C:\Users\Administrator>ping 192.168.0.1 -l 1600 -f

    Pinging 192.168.0.1 with 1600 bytes of data:
    Packet needs to be fragmented but DF set.
    Packet needs to be fragmented but DF set.

    Ping statistics for 192.168.0.1:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),


    PS: хотелось бы заметить, что я, кроме последнего раза, никогда принудительно не менял IP MTU: оно автоматически менялось при включении jumbo frames


    bond_jimme

    ОтветитьУдалить
  46. 2Umlyaut:

    А вот в случае VMXNET3 я переключаю пар-р JF в 9000, но команда по-прежнему выводит MTU для этого интерфейса равное 1500. Может, тут собака порылась?


    Вот поэтому и было высказано предложение попробовать после включения JF выставить руками IP MTU



    bond_jimme

    ОтветитьУдалить
  47. Дискуссия в комьюнити смех и слезы... Сложилось ощущение, что никто даже не подозревает что-такое LACP.

    А тест очень занимательный ... К сожалению, в нем не хватает самого главного - вывода. С моей точки зрения, вывод должен быть примерно следующий - виртуальные адаптеры не предназначены для 10Гбит. Требуются такие скорости - нужно использовать реальные физические ресурсы - passthrough карту, а лучше отдельный физический сервер.

    ОтветитьУдалить
  48. ну так вроде же выжали из vmxnet3 порядка 7-8Гбит?

    чем плохо?

    ОтветитьУдалить
  49. bond_jimme>Вот поэтому и было высказано предложение попробовать после включения JF выставить руками IP MTU

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

    Я сделал (на обеих тестовых VM`ках) "netsh interface ipv4 set subinterface "<10Gb>" mtu=9000" - и большие пинги пошли!

    Получается, что наличествует какая-то бага, которая не переключает MTU интерфейса при выборе значения через гуй драйвера VMXNET3. На Е1000 всё, вроде, срабатывает штатно.
    Возможно, я уговорю себя проверить на наличие этого казуса упоминавшуюся в треде доапдейтовую версию ESXi4.1... если не поленюсь, а то мне ещё, видимо, предстоит повтор тестирования уже со включенными во весь рост JF. :D

    * * *

    Кстати, коллега - имею Вас поправить на предмет "выставить руками IP MTU"... это не совсем так.

    Дело в том, что "netsh ... set ... mtu=xxxx" выставляет вовсе не IP MTU, а MTU второго уровня (для ethernet-кадров/фреймов) - то, что, собственно и называется JF.

    IP MTU же выставляется добавлением соответствующего параметра (MTU) с нужным значением в ветку реестра

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -

    если хотим единый MTU для всех адаптеров, или в ветку

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ -

    если для конкретного адаптера.

    В предыдущих версиях можно было задавать MTU и для различных протоколов (в частности актуально было для PPP), но для 2003/2008 я, признаться, этот вопрос для протоколов не рассматривал на практике (незачем было)...

    Когда я сейчас включал MTU=9000 на интерфейсе командой netsh и проверял "большие пинги", то специально заглядывал в реестры VM`ок - нет там пар-ра MTU ни в интерфейсах, ни выше (для всех адаптеров).

    Ergo, netsh отвечает именно за JF aka level2-MTU, а IP MTU тут не причём.
    :-P

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  50. Denis Baturin wrote:
    >Дискуссия в комьюнити смех и слезы... Сложилось ощущение, что никто даже не подозревает что-такое LACP.

    Денис, а что именно в той дискуссии не устроило лично ВАС? Что-то не наблюдалось там ни Вашего смеха, ни Ваших слёз?

    И, кстати о птичках - в контексте треда (агрегация vNIC`ов) LACP вообще не при чём, бо не должен поддерживаться vSwitch`ами. Так что абсолютно непонятен Ваш выпад... :(

    >С моей точки зрения, вывод должен быть примерно следующий - виртуальные адаптеры не предназначены для 10Гбит. Требуются такие скорости - нужно использовать реальные физические ресурсы - passthrough карту, а лучше отдельный физический сервер.

    Вывод верен... примерно наполовину.

    Как показал опыт, на чахлом хосте (C2Q) у нас банально не хватает мощности железа для достойной загрузки VMXNET3 - эмуляция offload-фич vNIC`а силами CPU хоста обязывает...

    Но уже на двухXeon`ной машинке имеем восемь гигабит - и это ещё без использования больших пакетов (что ещё предстоит опробовать), которые, по идее, должны требовать меньше прерываний относительно стандартных. Полагаю, что для большинства сетеёмких приложений этого должно хватать.

    Собственно, в конце первой части я и огласил этот вывод... в доступной форме... :)))

    // Dream mode on - представил себе драйвер для Сферы, возлагающий нагрузку по сетевым прерываниям на GPU ... облизнулсо... :)) //

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  51. Миша, это так же как вшилд - про который я тебе вчера мозк промывал. ;)
    Сам результат прекрасный, вот только использовать его маловероятно.
    Сугубо имхо:
    - кому нужна такая пропускная способность за счет процессора?
    - в тесте траффик был синтетический, те до диска скорее всего не доходил(Umlyaut поправит, если ошибаюсь). В реальном мире под такой поток с/на СХД отдельную пару fc надо.
    - грузится сеть, процессор, диск - что будет с остальными виртуалками? DRS попытается убрать их на другие серверы.

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

    Повторюсь, нужен такой поток = отдельный физический сервер. Хочется виртуалку = прокинутые карточки. Очень хочется расхлебывания проблем = пользуем vmxnet3.

    ОтветитьУдалить
  52. 2Umlyaut: как вы когда-то заметили, мне нимб не жмет. Поэтому ЛИЧНО МЕНЯ все устраивает. ;)

    Если вопрос был не про LACP, то странно, что его (не)поддержка обсуждается в каждом третьем сообщений.

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

    Но самые бурные эмоции вызвали перлы типа:
    - "агрегация у вСвича работает с двух сторон"
    - "накатил Интеловый драйвер, сделал Team (статику). Работает."
    Ну и конечно - "чем вас не устраивает VMCI?" ;)

    ОтветитьУдалить
  53. Не успел к разбору полетов :) флаг Do not Fragment ставится в заголовке IP пакета, то есть ICMP Packet упаковывается в IP, потом пытается уложить его в Ethernet frame, но он не помещается. Пытается разбить его на части, но там DF флаг и выкидывается ошибка. Вобщем было понятно, что bond_jimme сразу же указал на самую вероятную причину проблемы.

    Sydney

    ОтветитьУдалить
  54. Денис, я каждый курс интересуюсь у слушателей примерной нагрузкой на сервера.
    1) процессорной производительности часто (почти всегда) завались.
    2) сеть часто (почти всегда) не является узким местом даже близко, но!, в редких случаях приложения с интенсивным трафиком таки есть.

    выборка не абсолютная, разумеется, но если в твоей практике не попадаются такие задачи - не значит что их нет вообще.

    выделение отдельного 10Гбит контроллера под отдельную ВМ это все супер, но ты не хуже меня знаешь ограничения directpath.

    ОтветитьУдалить
  55. Denis Baturin wrote:

    >как вы когда-то заметили, мне нимб не жмет.

    Но это ещё не повод вставать в позу высокомерного самодовольного сноба, нес па?

    >Поэтому ЛИЧНО МЕНЯ все устраивает. ;)

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

    >Если вопрос был не про LACP, то странно, что его (не)поддержка обсуждается в каждом третьем сообщений.

    Ну, ТС либо не знал, либо забыл об этом - ему и намекали разные собеседники толсто на данное обстоятельство. Так что Ваше "НИКТО не подозревает, что такое LACP" совсем мимо тазика - Вы как-то умудрились проморгать тот факт, что НЕ ВСЕ настолько не искушены в сетевых технологиях.

    >С интересом читал и ждал, чем закончится поиск подтверждения, что на уровне портгруппы тиминг сделать не получится. Кстати, подобный тиминг теоретически возможен только в статике.

    Угу. Теоретически.
    На практике вышло, что vSwitch не обеспечивает поддержку SLA, требуемую драйвером (Intel) для работы Team.

    >Но самые бурные эмоции вызвали перлы типа:
    - "агрегация у вСвича работает с двух сторон"

    Неправда. Брешете Вы, Денис, как сивый мерин.
    эта конструкция употреблялась в предположительной:

    >>Полагаю, он (vSwitch - Uml.) должен быть устроен симметрично с обеих сторон

    и в отрицательной:

    >>Вот я не нашел подтверждения, что агрегация у вСвича работает с двух сторон...

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

    >"накатил Интеловый драйвер, сделал Team (статику). Работает."

    И что Вас подвигло на бурные эмоции в этой фразе?

    "Работает" - это значит Team сформировалась, линк есть. Правда, поковырявшись далее, я обнаружил, что Team у нас есть чисто номинально и без поддержки SLA со стороны vSwitch`a. О чём и отписал честно в хвост ветки.
    Или Вы вычитываете только то, что Вам удобно, а итог не подбиваете? Что ж, Ваше право... только противоканделябровый чепчик не забывайте носить...

    >Ну и конечно - "чем вас не устраивает VMCI?" ;)

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

    В общем, Вы, Денис, конечно, наверное уже большой мальчик и воспитывать Вас поздно (да и не по чину мне), но всё же не выставляйтесь уж так-то одиозно, ради бога! :)

    * * *
    Umlyaut.

    ОтветитьУдалить
  56. 2 Denis Baturin:

    Теперь по делу...

    >Сугубо имхо:
    - кому нужна такая пропускная способность за счет процессора?

    "За счёт" она скорее будет на плюшевом хосте. И то сказать - у меня на хосте C2Q (таком, как использовался для сравнительного теста в конце первой части) работает почти два десятка VM`ок. Память они практически всю расписали, что пулю, а вот четыре физ.ядра своими тремя с лишним десятками vCPU они нагружают максимум наполовину в пике. Т.е. для стандартной инфраструктуры первый насущный ресурс - память, а проц остаётся позади, его хватает с запасом.

    Да и на основном хосте ядер уже 8/16 - хватит и на такое богоугодное дело, как сетевые операции.

    >- в тесте траффик был синтетический, те до диска скорее всего не доходил(Umlyaut поправит, если ошибаюсь). В реальном мире под такой поток с/на СХД отдельную пару fc надо.

    Верно - это именно тест сети. Однако не вижу противоречий.

    VMXNET3 у VM`ки может обслуживать суммарный поток обращений к VM со стороны клиентов "снаружи", через LA-группу - как выясняется, его пропускной способности должно хватить на пропуск траффика даже с полной LA-группы - 8 портов по гигабиту. При этом сама VM`ка, ага, может лежать на быстрой СХД. Плюс при развитом кешировании (в OS VM или в БД) основные сетевые операции через VMXNET3 могут как раз приходиться на кеш.

    >- грузится сеть, процессор, диск - что будет с остальными виртуалками? DRS попытается убрать их на другие серверы.

    Это уже надо будет смотреть по месту. Может да, а может и нет.
    Например, хост на четыре сокета и с памятью в разы большей моей тестовой машины может спокойно позволить себе выделять часть ресурсов на максимальное использование VMXNET3 какой-либо виртуалки.

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

    С уважением (к Вашей квалификации, но никак не к поведению),
    Umlyaut.

    ОтветитьУдалить
  57. 2 Sydney:
    >Вобщем было понятно, что bond_jimme сразу же указал на самую вероятную причину проблемы.

    Ув. bond_jimme настаивал на увеличении IP MTU, как мне помнится.
    Я же в конце концов включил JF, т.е. MTU level2 - IP MTU остался стандартным 1500. С увеличенным мне ещё предстоит тестироваться... :)

    Но да, прямая и непосредственная заслуга коллеги в решении проблемы неоспорима - я бы даже сказал, что он сыграл в этом ключевую роль! Но и всем конструктивно и дружелюбно участвовавшим тоже большое спасибо! :)

    С уважением,
    Umlyaut.

    P.S. А Вы правда у антиподов? ;)

    ОтветитьУдалить
  58. Господа, прошу прощения, за возможно глупый вопрос,но после проведения двух дней в тестах (кстати по совету своего сетевого админа даже воспользовался утилитой jperf, по сути тоже только с gui), мне так и не удалось переступить планку 2.8Gb/s.
    Сервер SunFire X4600 M2 6CPU Quad-Core AMD Opteron 8384
    VM'ки MS WIN 7 x64, 2vCPU 6GB vmxnet3 JF9000
    отдельный vSwitch
    Собственно вопрос куда посмотреть, чтоб найти причины столь низких показателей ?
    Заранее всем спасибо

    ОтветитьУдалить
  59. 2 Yuri:

    Могу сегодня-завтра попробовать Ваш вариант тестирования (W7 x64 + jperf) на своём стенде - если результат подтвердится. значит дело в "семёрке"/утилите, если будет больше - значит в железе хоста. Только киньте, пожалуйста, методику - с какими пар-рами запускали утилиту.

    BTW, я нарочно использую консольную утилиту - ею удобнее и быстрее делать серии тестов, чем гуёвой...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  60. на самом-то деле я повторял группу тестов указанную в топике, поэтому результаты от ntttcp тоже подойдут. по jperf менял только количество потоков.

    ОтветитьУдалить
  61. 2 Yuri:

    А версия W7 какая? С SP, без?

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  62. Umlyaut с частичным уважением вы не правы. Позволю себе процитировать: "Уважение ... означает в соответствии с корнем слова (геspicere = to look at) способность видеть человека таким, каков он есть, осознавать его уникальную индивидуальность."
    Так что, либо целиком, либо никак! ;-)
    Чепчик надел, но свет все-равно пробивается ;)

    Миша, сорри за оффтоп, картинки отправил...

    ОтветитьУдалить
  63. 2 Umlyaut.

    Мне кажется, коллега, вы что-то чуток напутали. В данном случае что netsh, что регистр меняет значение MTU второго уровня. Я правда сейчас тут чуток занят, но завтра наверняка погляжу как это правильно рулится в W2003 и W2008. Максимальнгый размер IP пакета обычно определяется либо дефолтным значением типа лина, либо механизмом PMTU. Раз ICMP ходит, значит проблема не с PMTU, а скорей всего баг в драйвере VMXNET3, когда изменение значение MTU интерфейса в настройках NIC (то бишь включение JF) не влечет за собой действительное изменение размера размера MTU второго уровня.

    вот же у вас есть время общаться на отвлеченные темы :) пока вы тут личные качества выясняли я продвинулся еще на один маленький шажок к VCAP-DCA :)

    Syndey.

    PS Нет, я еще не в Австралии, но на пути к ней. Если пустят, а то у них последние два года сплошные изменения в миграционном законодательстве.

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

    ОтветитьУдалить
  64. 2 Sydney:

    >Мне кажется, коллега, вы что-то чуток напутали. В данном случае что netsh, что регистр меняет значение MTU второго уровня.

    Ничего подобного.

    Вот сейчас на обеих тестовых VM`ках поменял командой netsh на интерфейсе MTU (2-Го уровня) на дефолтные 1500, в реестре добавил пар-р MTU с десятичным значением 9000, перезагрузился для контроля. Пробую 'ping -f -l 8972 ... " - облом-с - "Packet needs to be fragmented..."

    Ergo - netsh действительно меняет MTU level 2, а вот пар-р реестра НЕ меняет MTU level 2.

    Собственно, это закономерно, бо в ветке реестра в явном виде указано - HKLM\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters - TCPIP!

    C уважением,
    Umlyaut.

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

    ОтветитьУдалить
  65. 2 Umlyaut

    Это может доказывать мое предположение, что если PMTU не обнаруживает MTU больше 1500, то ничего вручную выставленное в регистре больше 1500 не принимается. :)

    Sydney

    ОтветитьУдалить
  66. 2 Umlyaut:

    Коллега, Technet говорит нам ( http://technet.microsoft.com/en-us/library/cc770948(WS.10).aspx )

    "You can use commands in the Netsh Interface context and subcontexts to configure the TCP/IP version 4 protocol (including addresses, default gateways, Domain Name System (DNS) and WINS servers) and to display configuration and statistical information for IPv4.
    "

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

    bond_jimme

    ОтветитьУдалить
  67. Коллеги, думаю трения по поводу netsh можно закрыть:
    команда 'netsh interface ipv4 set interface "14" mtu=9000 store=p
    ersistent' честно прописала в реестре в ветке SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\Interfaces\"нужный интерфейс" клюс MTU=9000


    bond_jimme

    ОтветитьУдалить
  68. ...store=persistent'...

    bond_jimme

    ОтветитьУдалить
  69. bond_jimme>Коллеги, думаю трения по поводу netsh можно закрыть:


    Не вполне согласен - думаю, тут MS чего-то намутил.
    Скорее всего, просто прописАл жёстко создание пар-ра в реестре при задействовании netsh с ключом persistent исключительно из благих намерений - мол, какой дурак будет использовать с большими (9000) кадрами level 2 маленькие (1500) пакеты level 3 ??? Ясный перец, выставляя JF, админ должен позаботиться и о IP MTU - а вдруг забудет? Поможем же ему!!! :)))

    За это говорит тот факт, что я обнародовал чуть выше - при IP MTU в реестре = 9000 и MTU на интрерфейсе (по netsh) = 1500 большие пинги без фрагментации не ходят.

    Т.е. размер кадра ethernet определяется через MTU интерфейса с помощью гуя/netsh, а пар-р MTU в реестре возникает тогда, когда мы хотим сделать этот выбор постоянным (возможные резоны я уже обрисовал).

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  70. Ok, netsh ставит Interface MTU, то бишь hard limit для интерфейса.
    в регистре можно выставить PATH MTU, которое в принципе динамическое значение

    PATH MTU берется из драйвера (то что мы задаем через свойства NIC-а или netsh), потом проверяется с помощью Path MTU Discovery.
    Но в нашем случае четко видно, что вроде JF включены, а MTU интерфейса не изменилось. То бишь баг в драйвере VMXNET3.

    кстати, я только что протестировал JF на моей VM с Windows 2003 - все работает :)пинги правда не пускал, ибо у меня свитчи и всвитчи не сконфигурены для JF сейчас, но netsh показало 9000 MTU.

    ОтветитьУдалить
  71. опять агент bond обскакал - точно, persistent :)
    2 Umlayut, я почему то уверен, что если вы измените значение в регистре, не трогая при этом Netsh, а потом перегрузите машину, то netsh покажет вам ваши 9000 :)

    Sydney

    ОтветитьУдалить
  72. 2Umlyaut:

    MTU из реестра подхватывактся после перезагрузки

    bond_jimme

    ОтветитьУдалить
  73. уф, ну слава богу, значит все таки нет никакого IP MTU. :)

    Sydney

    ОтветитьУдалить
  74. >Ok, netsh ставит Interface MTU, то бишь hard limit для интерфейса. в регистре можно выставить PATH MTU, которое в принципе динамическое значение

    М-мммм...
    Во-первых, разница между MTU по netsh и MTU в реестре, имхо, не в том, что первый есть некий "hard limit", а второй "в приниципе динамический" - подобная лексическая конструкция кагбэ уравнивает их. У них иной дискриминатор: первый MTU - второго уровня, а второй - третьего. Умоляю, не смешивайте их в своих аргументах! :)))

    >кстати, я только что протестировал JF на моей VM с Windows 2003 - все работает :)пинги правда не пускал, ибо у меня свитчи и всвитчи не сконфигурены для JF сейчас, но netsh показало 9000 MTU.

    Пока не проверены пинги, говорить о том, что "всё работает" я бы не стал - а то будет, как с SLA vNIC-ов на vSwitche: с вижу всё устроилось, а по факту - пшик!

    Насчёт свитчи не сконфигурены... я так понимаю, Вы хотели (бы) проверить между VM 2003 и внешней "физикой"? Ну дык об чём спичЪ? Включение JF на физ.коммутаторе - операция прозрачная и не ребутабельная ни разу. А уж на вирт.коммутаторах - тем паче.
    Либо можно проверить вообще на отдельном vSwitsh`e между двумя виртуалками (как я)...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  75. 2 Umlayut

    я проверю, но вечером, после работы, на домашней лабе.

    я уверен, что нет такого понятия как IP MTU. Размер IP пакета ограничен только 16 битной длиной поля Total Length в IP заголовке и максимальным размером кадра второго уровня.

    увы, Я ошибался, думая, что значение в регистре и есть PATH MTU.

    Sydney

    ОтветитьУдалить
  76. Sydney>2 Umlayut, я почему то уверен, что если вы измените значение в регистре, не трогая при этом Netsh, а потом перегрузите машину, то netsh покажет вам ваши 9000 :)

    bond_jimmey>MTU из реестра подхватывактся после перезагрузки

    Господа, вы будете смеяться, но НЕТ!
    Первое, что я сделал после перезагрузки - это проверил netsh: там было по-прежнему 1500, хотя в реестре стояло MTU 9000.

    Но даже если и предположить, что у вас это каким-то боком выполняется, то это ничего не доказывает - кроме того, что MS (как я уже говорил) делает вполне себе логичную увязку - если хотим JF, то надо выставлять iP в 9000, а если не хотим, то оба пар-ра в 1500 "добровольно-принудительно" (и верно - нафига нам лишняя фрагментация?).

    Судите сами - при MTU в реестре =9000 и MTU на интерфейсе =1500 большие пинги не ходят. А при 1500 в реестре и 9000 на интерфейсе - ходят.

    Вот и выходит, что на интерфейсе MTU L2, а в реестре MTU L3. А уж как MS завязывает друг на друга изменение данных пар-ров - то дело десятое...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  77. 2 Umlayut

    действительно, не подхватывает. но я все равно отказываюсь верить в то, что MS придумала какой то свой IP MTU..

    ОтветитьУдалить
  78. Sydney>я уверен, что нет такого понятия как IP MTU. Размер IP пакета ограничен только 16 битной длиной поля Total Length в IP заголовке и максимальным размером кадра второго уровня.

    Вот как раз IP MTU (что в реестре) и ограничивает сверху значение Total Length. А вот размер кадра второго уровня размера IP пакета не ограничивает (в должном смысле этого слова).

    Т.е. при ограничении IP MTU значение Total Length не сможет выйти за определённый предел - мы не получим IP-пакет больше заданного размера.
    А при ограничении на размер кадра L2 (L2 MTU) нам ничто не мешает формировать IP-пакеты бОльшего размера - просто при инкапсуляции в протокол канального уровня (L2) будет происходить фрагментация IP-пакетов (а на другом конце канала - их сборка).

    Простой пример - протокол PPP (канального уровня, как и Ethernet) имеет MTU (размер кадра) равный 576 байт. Именно поэтому во времена диал-апа крайне рекомендовалось изменять IP MTU в операционках компов на такое же значение - чтобы избежать накладных расходов на фрагментацию IP-пакетов при отправке и на сборку их у провайдера при получении.

    Так что не соглашусь с Вами, коллега - IP MTU ест объективная реальность. :)))

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  79. >действительно, не подхватывает. но я все равно отказываюсь верить в то, что MS придумала какой то свой IP MTU..

    MS ничего не придумывала - я только что отписал. Просто она принудительно увязала выставление L3 MTU в реестре (для IP) при выставлении L2 MTU на интерфейсе (для ethernet). Ну а для того, чтобы нам не лазить в консоль, команду "netsh ... set ..." завязали на гуй, на пар-р JF в свойствах NIC`а (что, как выяснилось в моём случае, срабатывает не всегда)...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  80. коллеги, наверное у меня особенный w2k8, но еще раз изменив в реестре и тут же перегрузив машину, увидел по netsh то, что перед этим сконфигурироал.

    >Судите сами - при MTU в реестре =9000 и MTU на >интерфейсе =1500 большие пинги не ходят. А при >1500 в реестре и 9000 на интерфейсе - ходят.

    Кстати, Ваша фраза подтверждает необходимость перезагрузки: по netsh показывает актуальное значение, в реестре - сконфигурированное, но не примененное. Поэтому в первом случае все работало, во втором - нет. Почему в Вашем случае при перезагрузке компьютера значение из реестра не "переносятся" в netsh - не знаю.

    В вы точно прописываете в SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\Interfaces\"interface ID"\
    а не просто в SYSTEM\CurrentControlSet\Services\TCPIP\Parameters\ ?

    bond_jimme


    bond_jimme.

    bond_jimme

    ОтветитьУдалить
  81. 2 bond_jimme:
    Не знаю, что у Вас за w2k8, а у меня - w2k8r2ee sp1 en

    Да, я прописываю именно в интерфейсы, в \"interface ID"\

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

    С уважением,
    Umlyaut.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.