среда, 30 марта 2011 г.

LACP, 802.3ad, load based IP hash и все такое

Вводная

У нас есть виртуальный коммутатор, у него несколько физических интерфейсов, через которые он подключен к двум физическим коммутаторам
(такая схема, с поправкой на число аплинков(физических сетевых контроллеров), видится мне типовой).
См. рис.1:

Рис. 1. Иллюстрация компонентов сети


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

1. Производительность и балансировка нагрузки для "виртуальной" стороны - vNIC <-> vSwitch

Тут ситуация довольно простая, и вариантов у нас не много. Сразу оговорка - все эти варианты предполагают увеличение скорости сети только "внутри" ESX(i). Если нас интересует быстрая сеть между ВМ и кем-то "снаружи", то в дело вступает еще и "физическая сторона", которая, при настройках по умолчанию, ограничит нашу ВМ производительностью одного аплинка, для большинства из нас это гигабит. Но обсудить варианты все равно важно - о физической стороне позже.

Вариант 1
Один виртуальный сетевой контроллер, и побыстрее В простом случае у виртуальной машины одна виртуальная сетевая карта, обычно типа e1000, vmxnet2 или vmxnet3. Сетевая карта последнего типа должна дать скорость до 8( или даже до 16, по данным некоторых тестов) гигабит\с на "виртуальной" стороне моей схемы, т.е. до виртуального коммутатора (вот тут см. подробности - vSphere network test - vmxnet3). Таким образом, если интенсивный трафик у нас между виртуальными машинами, и, важно!, эти виртуальные машины:
  • на одном сервере ESX(i)
  • на одном виртуальном коммутаторе
  • в одном VLAN
то пропускную способность порядка 8 гигабит (плюс-минус) дать несложно.
Нас может ограничить то, что не все ОС имеют драйвер для vmxnet3. Win2003\2008, RHEL, SUSE имеют.

От сетевых контроллеров e1000 и vmxnet2 производительности стоит ожидать меньшей, чем у vmxnet3, но больше номинального гигабита. Но и нагрузка на процессор от них должна быть побольше.

Важный пруфлинк - тесты от VMware - vmxnet 3.

Вариант 2
Еще можно попытаться использовать группировку контроллеров - выдать ВМ несколько виртуальных сетевых контроллеров, и объединить их в группу софтом в гостевой ОС. Обычно таким софтом выступает драйвер сетевого контроллера.

Очевидно, нужен драйвер, умеющий объединять контроллеры в группу. Из известных мне вариантов могу назвать только один - это драйвер от Intel для контроллера типа e1000, который эмулирует физический контроллер IntelPRO1000.Обратите внимание - есть драйвер от Microsoft, но вместо него можно поставить драйвер с intel.com.
(вроде бы, еще какие-то есть варианты организации nic teaming(bonding) для Linux\FreeBSD, но я в *nix не силен).

Плохая новость - для 64битных ОС Intel не сделала специального драйвера, мол - уже есть от Microsoft, его достаточно. Но группировки контроллеров в нем нет. Так что такой способ для Win-ВМ применим только для 32-битных ВМ.

Самая плохая новость: чтобы была эффективная балансировка нагрузки между vNIC в группировке на уровне драйвера - соответствующий алгоритм балансировки нагрузки должен поддерживаться коммутатором. В нашем случае - виртуальным коммутатором VMware. И он такой поддержкой не обладает.

Немного теории: для настройки nic teaming мы должны указать тип группировки (рис. 2).

Рис. 2. Варианты настройки группы интерфейсов

Тип группировки указывает:
  • сколько контроллеров группы будут активными;
  • по какому алгоритму будет балансировать трафик между адаптерами группы;
  • будет ли коммутатор принимать активное участие в работе группы. Коммутатор принимает и пересылает этот трафик, и сам выбирает - через какой порт(на какой интерфейс) этот трафик вернуть.
Вот насколько я понимаю текущую ситуацию -
  • варианты, требующие поддержки группировки портов от коммутатора нам не подходят - виртуальный коммутатор VMware не умеет 802.3ad на "внутренних" портах;
  • варианты "Fault Tolerance" нам не интересны - они не обеспечивают балансировки нагрузки;
  • остается только Adaptive Load Balancing.

Характеристики этого метода следующие:
  • драйвер анализирует TCP\IP, и по результатам анализа равномерно балансирует исходящий трафик между интерфейсами;
  • входящий трафик не балансируется - это работа коммутатора, виртуальный коммутатор VMware этого не умеет на "внутренних" портах;
  • кроме входящего трафика, только по одному интерфейсу группы ходит широковещательный и мультивещательный трафик.
Мне не удалось обнаружить упоминание алгоритма, по которому происходит балансировка нагрузки при группировке контроллеров типа Adaptive Load Balancing в драйвере Intel. Есть мнение, что по MAC адресу принимающей стороны. Если я не ошибся, то это означает что при передаче большого объема трафика одному клиенту - балансировка произведена не будет.

Вывод - данный метод повышения производительности сети для виртуальных машин практически не применим, в варианте от Intel. 

2. Производительность и балансировка нагрузки для "физической" стороны - vSwitch <-> pSwitch

Итак - если виртуальная машина хочет сеть с большой полосой пропускания до другой виртуальной машины на том же ESX(i), том же виртуальном коммутаторе и в том же VLAN - то предоставить ее ей можно за счет быстрого виртуального сетевого контроллера, в первую очередь vmxnet3.

А если эти условия не выполняются, т.е. трафик надо передавать через физический коммутатор? Это означает, что даже при наличии быстрого канала до виртуального коммутатора, бутылочным горлышком могут стать его гигабитные интерфейсы. Вернее, тот один, через который пойдет трафик при настройках по умолчанию.

Есть для ESX(i) такая настройка виртуального коммутатора, как Load Balancing, балансировка нагрузки (рис. 3)
Рис. 3. Варианты балансировки нагрузки для вКоммутатора


Там есть два больше всего интересующих нас варианта:
  1. Load based original port ID - трафик от одного порта на "виртуальной" стороне выходит через какой-то один порт "физической" стороны, т.е. через какой-то один физический сетевой контроллер.
  2. Load based IP hash - трафик от одного порта "виртуальной" стороны может выходить сразу через все порты "физической" стороны. Идентификатором условной "сессии", передаваемой через один pNIC, является не номер виртуального порта, как в первом случае, а хеш пары "IP-источник IP-получатель". Таким образом, трафик от одной ВМ к одному клиенту не займет больше одного pNIC, а вот трафик один-ко-многим - может занять сразу все.
Первый алгоритм хорош универсальностью - он работает всегда, и он используется по умолчанию. Однако весь трафик от одного виртуального контроллера будет выходить наружу только через один физический сетевой интерфейс.

От второго ожидают лучшего распределения трафика.

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

Итак - мы хотим большей производительности на "физической" стороне сети ESX(i) (рис.1).

Мы меняем настройку балансировки нагрузки на "Load based IP hash".
Если виртуальный коммутатор будет балансировать нагрузку по алгоритму «Load based IP Hash», то это означает, что виртуальный коммутатор трафик от любой одной ВМ может выпускать сразу по все аплинкам одновременно. MAC-адрес этой ВМ будет на нескольких портах физического коммутатора – без объединения этих портов в группу по стандарту 802.3ad( или EtherChannel) сеть работать не будет.

Так что чтобы сеть не перестала работать после включения "Load based IP hash" на виртуальном коммутаторе, к этому моменту на физическом коммутаторе должна быть настроена статичная группировка портов по стандарту 802.3ad. Вот об этом и хочу поговорить.

Обратите внимание - есть две аббревиатуры, часто (всегда?) употребляемых при обсуждении "Load based IP hash".
Первая - это выше упомянутый 802.3ad.
Вторая - LACP, Link Aggregation Control Protocol
Еще может быть «PAgP, Port Aggregation Protocol», но это примерно то же что и LACP, только LACP – отраслевой стандарт, а PAgP – закрытый стандарт от Cisco. Примерно та же разница между EtherChannel и 802.3ad – первое разработка Cisco, второе – отраслевой стандарт. Суть одна. В данном тексте и в данном контексте 802.3ad и EtherChannel означают одно и то же, как и LACP/PAgP.

Так вот – формально говоря, в контексте обсуждения балансировки нагрузки для виртуальных коммутаторов VMware термин LACP употреблять не следует. Вот почему:
  
1) 802.3ad(или EtherChannel в случае Cisco) - это стандарт группировки портов, он описывает как эта группировка должна быть устроена и чего от нее ожидать. Если коммутатор имеет группу портов, объединенную по этому стандарту, то он, в частности, нормально относится к тому, что один и тот же MAC-адрес может фигурировать в трафике сразу на всех портах этой группы.

2) LACP(PAgP) - это метод или протокол автоматической настройки(!) группировки портов. LACP - это часть 802.3ad (PAgP - EtherChannel).
Т.е. агрегация каналов может быть построена по 802.3ad без участия LACP (это называется static 802.3ad) - и такая группа портов на стороне коммутатора достаточна для работы виртуального коммутатора VMware с балансировкой нагрузки по методу "Load based IP hash".

Более того - только такая конфигурация и является рабочей(!) для ESX(i). Дело в том, что виртуальные коммутаторы VMware не поддерживают LACP(как протокол автоматической настройки), и не смогут сами договориться с физическими коммутаторами об настройке агрегации каналов.

В разных коммутаторах настройка группировки портов, может называться по разному. Например - Link Aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking.

Итак, группа портов на физическом коммутаторе у нас есть. Но это еще не все.
Есть вот какой нюанс: при одной и той же группировке по стандарту 802.3ad на физических коммутаторах могут применяться разные алгоритмы непосредственно балансировки.
Вот примерный список:
dst-ip Dst IP Addr
dst-mac Dst Mac Addr
dst-mixed-ip-port Dst IP Addr and TCP/UDP Port
dst-port Dst TCP/UDP Port
src-dst-ip Src XOR Dst IP Addr
src-dst-mac Src XOR Dst Mac Addr
src-dst-mixed-ip-port Src XOR Dst IP Addr and TCP/UDP Port
src-dst-port Src XOR Dst TCP/UDP Port
src-ip Src IP Addr
src-mac Src Mac Addr
src-mixed-ip-port Src IP Addr and TCP/UDP Port
src-port Src TCP/UDP Port
И на стороне физического коммутатора обязательно должна быть балансировка нагрузки по IP (IP-Source-Destination) - потому что балансировку только лишь по такому алгоритму поддерживает коммутатор VMware, а алгоритм должен быть одинаков на "обоих концах" агрегированных каналов.

Как справочную информацию см. очень полезную, имхо, статью базы знаний - http://kb.vmware.com/kb/1004048.

И, кстати, если сеть устроена так как на рис.1 - т.е. виртуальный коммутатор подключен к нескольким физическим, то для использования "Load based IP hash" на вКоммутаторе эти физические должны уметь static 802.3ad в стеке.
Это обычно называется Multichassis Etherchannel или, для не Cisco, MLAG - Multichassis Link Aggregation.

Выводы
Если нужна гарантированная полоса пропускания, близкая к 10 Гбит\с, в том числе к единому клиенту, то стоит задуматься или о невиртуализации такой задачи, или о пробросе выделенной 10Гбит сетевой карте при помощи VMDirectPath.

Кроме того, и выше я об этом не упоминал, иногда нам сможет помочь  виртуальный коммутатор от Cisco, см. сравнение по функционалу - Virtual Networking Features of the VMware vNetwork Distributed Switch and Cisco Nexus 1000V Switches.

Если по соотношению "гарантированность\производительность\бюджет" на выделенный сервер\виртуальную циску с бюджетом все не очень хорошо, то для виртуальной машины на ESX(i) можно дать хорошую скорость к соседней виртуальной машине, и неплохую, с определенными оговорками, к внешним машинам.
Оговорки:
  • внешняя машина не одна, а это много клиентов с разными IP
    (иначе алгоритм "Load based IP hash" не позволит задействовать больше одного физического контроллера);
  • у нас есть достаточное количество физических сетевых контроллеров на виртуальном коммутаторе, и физические коммутаторы, к которым они подключены,  поддерживают нужный режим 802.3ad (и он, соответственно, на них настроен).
Вне номинаций

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


от продакшн ВМ vmxnet3 до ВМ2(на одном вКоммутаторе),
а в ВМ2 поднят софт, умеющий делать более эффективную группировку группировку - выводящий трафик на физику через несколько аплинков сервера ESX(i).

Если продакшн ВМ шлет большую кучу трафика единственному клиенту - такой же ВМ, к примеру, но на другом ESX(i), то через промежуточные ВМ можно попробовать поднять "более толстый" канал.

Правда, реализуем ли такой вариант, и если да то как,  - я сказать затрудняюсь, запомнилась сама идея.


За консультации и помощь в подготовке материала биг thx Денису Батурину и Евгению Ковальскому.
Комментарии приветствуются.

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

VCAP DCD

Сегодня сдал vcap dcd.


- пост с мобильного устройства, сорри за краткость и опечатки.

vSphere network test - vmxnet3, Jumbo Frames

Недавно было опубликовано тестирование производительности виртуального сетевого контроллера vmxnet3 -vSphere network test - vmxnet3.

Сегодня - дополнения после разбирательств с активацией Jumbo Frames:


 Благополучно разобравшись с JF (всё указывает на то, что это всё же какая-то бага в настройках  VMXNET3),   продолжил тестирование.

Итак, часть вторая, переработанная и дополненная…

Стенд всё тот же: и хост, и тестовые виртуальные машины – разница с первой частью только в увеличении MTU второго (кадры ethernet) и третьего (пакеты IP) уровней (включаются, соответственно, командой "netsh interface ipv4 set subinterface "<10Gb>" mtu=9000" и добавлением параметрара MTU  в ветку HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<10Gb>\

- впрочем, коллеги в дискуссии по предыдущему отчету откопали-таки, что параметр реестра добавляется «сам», если команда «netsh … … …»  применяется с параметром «store=persistent».

Теперь собственно, сами тесты. Повторять я решил тесты №№3, 4, и 5 – как наиболее интересные. Напомню, что
№3 – это 1,2,4 и 8 тредов на одном vCPU;
№4 – 2,4 и 8 тредов на двух vCPU между одной парой «src-IP – dest-IP»;
№5 – 2,4 и 8 тредов на двух vCPU и между двумя парами IP.

№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)=9853.56 CPU=38.1% Cycles/Byte=1.48 Interrupts/Sec=22318
Throughput(Mbps)=12778.42 CPU=39.5% Cycles/Byte=1.19 Interrupts/Sec=15851
Throughput(Mbps)=15625.43 CPU=44.5% Cycles/Byte=1.09 Interrupts/Sec=12986
Throughput(Mbps)=16239.71 CPU=44.1% Cycles/Byte=1.04 Interrupts/Sec=9758
=========================================================================
 
№4:

= 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)=11836.07 CPU=39.7% Cycles/Byte=1.29 Interrupts/Sec=16122
Throughput(Mbps)=15048.95 CPU=47.3% Cycles/Byte=1.21 Interrupts/Sec=17219
Throughput(Mbps)=16300.43 CPU=46.5% Cycles/Byte=1.10 Interrupts/Sec=11597
======================================================================

№5:

= 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)=12963.54 CPU=43.8% Cycles/Byte=1.30 Interrupts/Sec=19375
Throughput(Mbps)=15019.10 CPU=48.0% Cycles/Byte=1.23 Interrupts/Sec=17054
Throughput(Mbps)=16153.00 CPU=44.9% Cycles/Byte=1.07 Interrupts/Sec=10771
======================================================================

Что тут скажешь – неплохо выстрелило. Почти вдвое лучшие показатели по сравнению с тестами без использования JF.
Причём загрузка vCPU0 (на который по-прежнему приходится львиная доля работы) вполне ожидаемо снизилась – теперь даже на максимальных показателях производительности она болтается в районе 75-80 %, не выходя на прямую линию на 100%-й отметке (как это было на стандартных сетевых пакетах).

Ну и сохраняется примерно такая же «мультипроцессоронезависимость» - тесты с раскладкой тредов по ядрам не дают какого-либо заметного преимущества.


Для сравнения же -  традиционный сравнительный прогон на «младшем» хосте C2Q:

№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)=3174.32 CPU=29.4% Cycles/Byte=4.20 Interrupts/Sec=6512
Throughput(Mbps)=4363.88 CPU=42.1% Cycles/Byte=4.37 Interrupts/Sec=5607
Throughput(Mbps)=4791.96 CPU=45.2% Cycles/Byte=4.28 Interrupts/Sec=3288
Throughput(Mbps)=4379.16 CPU=49.0% Cycles/Byte=5.08 Interrupts/Sec=2494
======================================================================

Такое впечатление, что 8 тредов на vCPU этой конфигурации уже стало многовато…

№4:

= 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)=4063.68 CPU=48.3% Cycles/Byte=5.39 Interrupts/Sec=5679
Throughput(Mbps)=4383.17 CPU=52.7% Cycles/Byte=5.45 Interrupts/Sec=3346
Throughput(Mbps)=4384.87 CPU=64.5% Cycles/Byte=6.66 Interrupts/Sec=2695
======================================================================

А тут как будто многоножка путается в своих лапах – попытки расфасовать несколько тредов по двум vCPU дают результаты не лучше предыдущего теста.

№5:

= 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)=3859.31 CPU=47.3% Cycles/Byte=5.56 Interrupts/Sec=5336
Throughput(Mbps)=4409.23 CPU=54.4% Cycles/Byte=5.60 Interrupts/Sec=3211
Throughput(Mbps)=4411.61 CPU=64.7% Cycles/Byte=6.66 Interrupts/Sec=2734
======================================================================

Ну и тут без особой доблести обошлось – практически как и с одной парой IP…

Справедливости ради нужно сказать, что большие пакеты и здесь показывают лучшую производительность, нежели без оных.


* * *



В довершение ко всему хотел бы выполнить одно обещание, данное коллеге Yuri - проверить данный тест на связке из двух Windows 7.

Все условия тестирования прежние (включая, пардон за каламбур, включенные JF и IP MTU=9000), за исключением ОС – вместо W2k8R2eeSP1 гонялись W7Profx64
(к сожалению по некоторым причинам пока без SP1).

Гонялся «базовый» тест - №3 (остальное среди ночи как-то заломало, если честно) – думаю, для оценки этого должно хватить:

№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)=8575.92 CPU=31.9% Cycles/Byte=1.43 Interrupts/Sec=16623
Throughput(Mbps)=10506.64 CPU=36.8% Cycles/Byte=1.34 Interrupts/Sec=14439
Throughput(Mbps)=13751.71 CPU=44.0% Cycles/Byte=1.23 Interrupts/Sec=13917
Throughput(Mbps)=16202.18 CPU=43.9% Cycles/Byte=1.04 Interrupts/Sec=8128
======================================================================

Как видим, результаты мало чем отличаются от таковых у w2k8r2. Почему у коллеги на его монстроОптеронах такие маленькие и смешные трафики – не знаю: «отсюда плохо видно»(с)моё.

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

пятница, 25 марта 2011 г.

vcap transcript

22 февраля я сдавал тест VMware Certified Advanced Professional: Datacenter Administrator.

10 марта пришли результаты.

А сегодня, 25 марта, эта сертификация была добавлена в мой транскрипт:

image

четверг, 24 марта 2011 г.

dcui through ssh

Офигенной штукой делится Михаил Коротько:
если подключиться к ESXi по ssh, и выполнить команду dcui,

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


Правда, черно-белая.

Выйти можно попробовать по Ctrl+C.


среда, 23 марта 2011 г.

ESX(i) pNIC speed and duplex default setting


С мест сообщают - вроде как ESX(i) начиная с версии 4.0 выставляет настройку скорости и дуплекса для физических сетевых контроллеров в значение "1000 Mb / full", а не в Auto negatiate.

В статье базы знаний VMware не рекомендуется разное значение этой настройки на коммутаторе и сетевом контроллере, вот картинка:

вторник, 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.

воскресенье, 20 марта 2011 г.

cloud, vcloud, vcloud director, it-grad


Облака, облачные вычисления, IaaS\SaaS\PaaS - многие источники утверждают, что за этими непонятными словами будущее.

Но что это такое?

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

Так что когда мне такая возможность предоставилась - я за нее ухватился.

А предложили мне попользоваться услугами компании, которая как раз специализируется на "Облаках", притом специализируется в том числе в облачных решениях VMware. Так вот - попользоваться, и описать впечатления. Забегая вперед - мне понравилось :-)

Так что, коллеги, вот тут - Как приручить облака: примеры практического использования. Начало - можно прочесть прикладную информацию про меняющие нашу отрасль облака. Это первый пост в серии (публиковаться они будут еще и на хабре).

Мне кажется уместным сделать оговорку -  это, разумеется, реклама - написано же про конкретную компанию и что там все здорово. Но я постарался сделать эту информацию полезной и обоснованной.

RTL 8169 + ESX 4

из переписки – со мной поделились инструкцией.

Портирование драйверов RTL 8169

  1. Открыть Datastore на сервере ESX:

clip_image001

clip_image002

clip_image003

  1. Подключиться к ESX через putty и войти в режим super user’а

clip_image004

  1. Переходим в каталог с файлом

clip_image005

  1. Распаковать архив: tar zxvf oem-r8169-esx4.1.tgz
  2. Скопировать файл: cp ./usr/lib/vmware/vmkmod/r8169.o /usr/lib/vmware/vmkmod/
  3. Проверьте правильность копирования

clip_image006

clip_image007

  1. Запускаем редактор vi для правки файла /etc/vmware/pci.xml

clip_image008

Нажимаем «/» вводим r8169

Удаляем эти сточки:

clip_image009

Удалять сточки: «d»

Выйти с сохранением: «:wd!»

  1. Создаем файл: touch /etc/vmware/pciid/r81xx.xml
  2. Редактируем файл: vi /etc/vmware/pciid/r81xx.xml и вставляем в файл текст:

<?xml version='1.0' encoding='iso-8859-1'?>
<pcitable>
<vendor id="10ec">
<short>Realtek Semiconductor Co., Ltd.</short>
<name>Realtek Semiconductor Co., Ltd.</name>
<device id="8168">
<vmware label="nic">
<driver>r8168</driver>
</vmware>
<name>RTL8111/8168B PCI Express Gigabit Ethernet controller</name>
<table file="pcitable" module="ignore" />
<table file="pcitable.Linux" module="r8168">
<desc>Realtek|RTL8111/8168B PCI Express Gigabit Ethernet controller</desc>
</table>
</device>
<device id="8169">
<vmware label="nic">
<driver>r8169</driver>
</vmware>
<name>RTL-8169</name>
<table file="pcitable" module="ignore" />
<table file="pcitable.Linux" module="r8169">
<desc>Realtek|RTL-8169</desc>
</table>
</device>
</vendor>
</pcitable>

  1. Проверяем правильность ввода

clip_image010

  1. Выполняем команду: vmkload_mod /usr/lib/vmware/vmkmod/r8169.o debug=5
  2. Проверяем правильность загрузки

clip_image011

  1. Выполняем команду: esxcfg-pciid
  2. Выполняем команду: esxcfg-module -e r8169
  3. Проверяем правильность создания

clip_image012

  1. Создаем файл: touch /etc/vmware/init/manifests/vmware-r8196.mf
  2. Редактируем файл: vi /etc/vmware/init/manifests/vmware-r8196.mf и вставляем текст:

copy /usr/lib/vmware/vmkmod/r8169.o

  1. Проверяем правильность ввода

clip_image013

  1. Перезагружаем ESX-сервер
  2. Проверяем наличие сетевой карты:

clip_image014

clip_image015

 

thx Дмитрий Пичугин

Настройка iSCSI hardware assisted с правильным выбором пути

Из переписки.

Со мной поделились инструкцией, возможна она будет полезна кому-то из читателей.

 

Есть сервер, в сервере сетевые контроллеры с поддержкой iSCSI hardware assisted.

Задача: настроить работу с iSCSI СХД под управлением MS Windows 2008 через двКоммутатор, через эти адаптеры.

Решение:

 

Начало

Допустим, уже имеется привязка виртуальных портов к физическим:

clip_image001

Необходимо настроить синий путь к СХД как предпочтительный, а оранжевый как запасной.

Настройка teaming’а:

Service

clip_image003

iSCSI A

clip_image004

iSCSI B

clip_image005

Настройка на стороне ESX

Заходим на ESX’е в настройки сети, выбираем управление физическими адаптерами:

clip_image007

Удаляем физический линк:

clip_image008

Выбираем вКоммутатор:

clip_image009

Создаем вКоммутатор:

clip_image010

Выбираем тип соединения VMkernel:

clip_image011

Выбираем привязку к физическому линку:

clip_image012

Задаём IP-адрес порта:

clip_image013

Создаем вКоммутатор:

clip_image014

Определяем какой vmhba принадлежит vmnic1.

Запоминаем MAC-адрес:

clip_image015

В свойствах iSCSI адаптера смотрим параметр:

clip_image017

clip_image018

Он должен соответствовать MAC-адресу сетевой карты vmnic1.

Заходим в CLI на ESX-сервер:

Запускаем команду: esxcli swiscsi nic add -n vmk1 -d vmhba36

Выполняем обновление:

clip_image019

Заходим в свойства iSCSI адаптера:

clip_image021

clip_image022

Добавляем iSCSI СХД:

clip_image023

Настраиваем безопасность:

clip_image024

Настройка на стороне Windows Storage Server

Заходим в оснастку Server Manager, выбираем Microsoft iSCSI Software Targets:

clip_image025

Создаем iSCSI Targets:

clip_image026

Префикс ph – означает соединение через физический iSCSI адаптеры, название соответствует имени ESX-сервера.

Вписываем идентификатор:

clip_image027

Идентификатор берем отсюда:

clip_image028

clip_image029

clip_image030

Должно появиться подключение:

clip_image031

Запускаем refresh и rescsn all

Должно появиться устройство.

clip_image033

Создаем datastores:

clip_image035

clip_image036

Повторяем действия для vmnic0

Проверяем наличие двух путей к СХД:

clip_image037

Производим миграцию портов с вКоммутатора на двКоммутатор:

Производить необходимо в два этапа, что бы не потерять связи с СХД.

Мигрируем сетевую карту и vmk-порт пути через который в данный момент не передаются данные.

Определяем путь в позиции status НЕ должно быть Active (I/O):

clip_image038

clip_image039

Переподключаем физическую сетевую:

clip_image040

clip_image041

clip_image042

На предупреждение отвечаем положительно

clip_image043

Производим миграцию виртуального порта:

clip_image044

clip_image045

Выбираем миграцию существующего порта:

clip_image046

Отмечаем только необходимый виртуальный порт и назначаем группу портов:

clip_image047

Проверяем доступность резервного пути к СХД:

clip_image048

Отмечаем мигрированный порт как предпочтительный:

clip_image049

Определяем, что переключение произошло и datastore доступен:

clip_image050

Производим аналогичные манипуляции для другого порта и сетевой карты.

Проверяем правильность переноса:

clip_image051

clip_image052

Производим переключение доступа к СХД на предпочтительный интерфейс.

clip_image053

Все.

 

thx Пичугин Дмитрий.