Bugatt1
Enthusiast
Enthusiast

NIC teaming политики

Jump to solution

Привет!

Варя добавляет новых плюшек в свои продукты, иногда не успеваю во всём разобраться, потестить..

Допустим у нас есть шасси HP c7000 с блейдами, есть VC Flex Fabric, где можно нарезать NIC на уровне железа..

Как на это наложить все возможные технологии распределения/балансировки сетевой нагрузки в наше время?

т.е. это IP Hash teaming, LBT, несколько LAG групп, созданных через Web Client на dvSwitch. куда сюда приткнуть LACP? пока как-то плаваю в примерах, где что лучше применять с учетом указанного железа..насколько одни технологии устарели? что лучше использовать?

Пообсуждаем немного?)

0 Kudos
1 Solution

Accepted Solutions
Umlyaut
Expert
Expert

Bugatt1 wrote:

1. Файл по сети будет передаваться в два раза быстрее только при использовании LAG+LACP (объединяем два физических канала, сравниваем с LBT, IP hash), верно?

Нет.

На одной паре "src ip - dest ip" передача будет идти на скорости не выше скорости одного линка.

В случае нескольких пар "src ip - dest ip" они могут быть распределены на несколько линков LA(CP)-группы.

Передача файла по сети подпадает под первый вариант - будет идти со скоростью одного линка максимум.

Однако если файл пишется на iscsi-таргет, то MP раскидает блоки по нескольким путям, давая скорость выше, чем у одиночного линка - я лично проверял это на 4х1Gbit, получая скорость порядка двух сотен GB в секунду (видимо, упирался уже в дисковую хранилки).

View solution in original post

0 Kudos
4 Replies
Umlyaut
Expert
Expert

"Я тебе сейчас один умный вещ скажу!"(с) Smiley Happy

Блейды, фабрики, крылья, лапы... Проще надо быть. Не множить сущности, а глядеть в корень... Smiley Happy

Лично я использую балансировку L2 (LA на pSwitch, IP hashe на vSwitch) только для "клиентской" сети VM - там это оправданно нормальным распределением пар src ip - dest ip просто в силу множественности этих самых "src ip" кучи клиентских машин.

На сети передачи данных же (у меня iscsi до хранилок) строго штатный MP Сферы, никакого LA(CP).

После недавнего тюнинга - разнёс пути и, соответственно, ip-шники на vkernel`ах хостов и на NIC`ах хранилок по разным подсетям класса С, до того бывших в одной С-подсети - балансировка силами MP приблизилась к идеальной: трафф фасуется по путям с точностью до сотен байт.

Балансировка сети данных на L2, бывшая совсем ранее, и рядом не валается.

Как-то так...

0 Kudos
Finikiez
Champion
Champion

Не совсем понятно, что вы хотите обсудить Smiley Happy

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

LACP и LAG красиво описаны в KB VMware KB: Enhanced LACP Support on a vSphere 5.5 Distributed Switch

Ограничения LACP в 5.5 VMware KB: Limitations of LACP in VMware vSphere 5.5

Как включить LACP http://kb.vmware.com/kb/2034277

Как обычно, со стороны физических коммутаторов нужно правильно сконфигурировать порты VMware KB: Sample configuration of EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi...

0 Kudos
Bugatt1
Enthusiast
Enthusiast

1. Файл по сети будет передаваться в два раза быстрее только при использовании LAG+LACP (объединяем два физических канала, сравниваем с LBT, IP hash), верно?

2. Если у меня нет ограничений по дизайну/железу, то при наличии Ent. Plus всегда использовать LAG+LACP для продуктива? 

0 Kudos
Umlyaut
Expert
Expert

Bugatt1 wrote:

1. Файл по сети будет передаваться в два раза быстрее только при использовании LAG+LACP (объединяем два физических канала, сравниваем с LBT, IP hash), верно?

Нет.

На одной паре "src ip - dest ip" передача будет идти на скорости не выше скорости одного линка.

В случае нескольких пар "src ip - dest ip" они могут быть распределены на несколько линков LA(CP)-группы.

Передача файла по сети подпадает под первый вариант - будет идти со скоростью одного линка максимум.

Однако если файл пишется на iscsi-таргет, то MP раскидает блоки по нескольким путям, давая скорость выше, чем у одиночного линка - я лично проверял это на 4х1Gbit, получая скорость порядка двух сотен GB в секунду (видимо, упирался уже в дисковую хранилки).

View solution in original post

0 Kudos