среда, 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 Денису Батурину и Евгению Ковальскому.
Комментарии приветствуются.

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

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

    Всё равно собирался сказать: имхо, Etherchannel не может быть приравнен к 802.3ad в плане работы cо стандартным Вариным vSwitch`ем в режиме группировки портов (с IP hash balancing) - cобственно, сам 802.3ad появился вослед EtherChannel как отраслевой (вендоронезависимый!)стандарт.

    Коль скоро в TFM`е прописано требование на стандарт объединения линков как 802.3ad, то подсовывать хосту Сферы порты коммутатора, сгруппированные по EC будет столь же негуманно, сколь и бессмысленно.

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

    ОтветитьУдалить
  2. если я правильно понимаю, то VMware с вами не согласна :)

    можно и 802.3ad, и EC.

    ОтветитьУдалить
  3. Что-то я не припоминаю... может, плохо читал?

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

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

    ОтветитьУдалить
  4. да без проблем:
    http://kb.cmware.com/kb/1001938

    ОтветитьУдалить
  5. >да без проблем:

    "Не човчем!"(с)анек. :))

    Читал это уже раньше...
    Обратите внимание - термин "Ether-channel" употребляется там не как название проприетарной кошкиной технологии объединения портов, а как один из синонимов, описывающих это самое объединение - см.

    "Enable link aggregation (also known as Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) on physical switch"

    И далее, в описалове, явным по белому указывается, что для достижения этого самого "эзерченела" необходимо использовать 802.3ad:

    "The switch must be set to perform 802.3ad link aggregation in static mode ON and the virtual switch must have its load balancing method set to Route based on IP hash. "

    Т.е. если мы используем физ.цискосвитч, то должны его настроить на агрегацию портов не с помощью "ихнего" Etherchannel`а, а с помощью "всехнего" 802.3ad.

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

    ОтветитьУдалить
  6. тем не менее, термин Etherchannel в доке встречается, а в статье базы знаний приведенной в посте даже описывается как его настроить на коммутаторах Cisco.

    зачем?

    а по той причине, что для вКоммутаторов VMware что 802.3ad, что etherchannel все едино.

    я, конечно, могу ошибаться, но тут я вряд ли ошибаюсь.

    ОтветитьУдалить
  7. >тем не менее, термин Etherchannel в доке встречается

    Но не в разрезе технологии объединения портов, а как одна из (жаргонных) разновидностей обзывания такового объединения... :P

    >в статье базы знаний приведенной в посте даже описывается как его настроить на коммутаторах Cisco.

    Меня сильно смущает тот факт, что там речь идёт о ESX 3.x. А вот для "четвёрки" я пока не видел объявления поддержки FEC или GEC.

    >а по той причине, что для вКоммутаторов VMware что 802.3ad, что etherchannel все едино

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

    Собственно, можно было бы проверить экспериментально - жаль, что у меня в хозяйстве только старая добрая 2924, т.ч. проверить работу 4-й Сферы с FEC я бы, наверно, смог, а вот с GEC - увы...

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

    ОтветитьУдалить
  8. ну а вы на каком основании заявляете, что vmware под etherchannel понимает не etherchannel, а "Но не в разрезе технологии объединения портов, а как одна из (жаргонных) разновидностей обзывания такового объединения"???

    ОтветитьУдалить
  9. Вот на этом, в частности:

    "Enable link aggregation (also known as Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) on physical switch"

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

    ОтветитьУдалить
  10. что-то я потерял мысль.

    "Включите группировку портов, так же известную как etherchannel".

    как это коррелирует с
    "Т.е. если мы используем физ.цискосвитч, то должны его настроить на агрегацию портов не с помощью "ихнего" Etherchannel`а, а с помощью "всехнего" 802.3ad.
    "

    ОтветитьУдалить
  11. >"Включите группировку портов, так же известную как etherchannel"...

    "...Ethernet trunk, port channel, Multi-Link Trunking)".

    Идёт перечисление разных вариантов наз(ы)вания группировки портов, которую просят включить. И Etherchannel в данной фразе фигурирует как одно из названий группировки - не как технология таковой.

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

    ОтветитьУдалить
  12. 0_о

    пойду ка я спать, утро вечера мудренее.

    ОтветитьУдалить
  13. В кб все написано правильно - поддерживаются реализации link aggregation от разных вендоров - цисковский etherchannel, аваевский Multi-Link Trunking, Ethernet trunk кажется трикомвская технология.
    А если немного почитать документацию и подумать...
    Поскольку основная разница между EC и 802.3ad в алгоритмах распределения трафика и поддержке PAgP, то для esx, использующего static и один единственный алгоритм распределения - эти технологии вообще не различаются!

    ОтветитьУдалить
  14. Хм-мм... сказывается, что с ТриКомом расстался очень давно (а с Авайей вообще не игрался)...

    Насчёт симилярности основ EC и 802.3ad, пожалуй, соглашусь.
    Собственно, мне стОит дать задний ход, бо я уже нарыл на разных ресурсах (вплоть до форума иранских сисадминов!), что цыска всё же может использоваться в режиме ЕС с четвёртой Сферой, ага. Получается, я должен извиниться перед Михаилом за "наезд"... :)))

    Кстати, если в LA в нашем случае действительно задействован минимум-миниморум возможностей технологии, то такое упрощение, пожалуй, может объяснить и фиаско в попытке использования SLA на windows-Teaming`e NIC`ов - видимо, упростили со стороны vSwitch всё, что можно...

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

    P.S. Денис, мне показалось, или Вы опять выпендриваетесь? :D

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

    Кстати, Михаил, а Вы успели (до того как руборд лёг) заметить ссылку, которую я там давал? Вот эту - http://it-giki.ru/post/67.html
    Интересно человек поработал, буду думать и над этим тоже...

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

    ОтветитьУдалить
  16. то есть, если я правильно понимаю то

    получить между ДВУМЯ VM на ДВУХ ESXi скорость больше 1Гб нельзя ?
    (на любом количестве 1Гб сетевых карт)

    ОтветитьУдалить
  17. Обращайтесь :)

    Небольшое уточнение, почему Etherchannel это не вполне 802.3ad. Потому что Cisco Etherchannel уже был, когда 802.3ad еще не было. Так же Cisco называет Etherchannel'ом саму технологию объединения линков в целом. А простой etherchannel, lacp и pagp протоколами или реализациями, если угодно, в рамках этой технологии.

    По ходу обсуждения был вопрос работает ли Gigabit Etherchannel с четверкой (esx4), сообщаю работает замечательно (три раза тьфу).

    Так же на данный момент единственным вариантом подключения использующим объединения линков для связки Cisco-VMware без использования Nexus 1000v является именно etherchannel. LACP/PAGP просто не поднимается (пробовал). Если ставить Nexus 1000v - LACP на ура.

    Evgeny Kovalskiy
    CCNP, VCP, Team Lead.

    ОтветитьУдалить
  18. Вопрос
    Я использую LACP из 4 линков для подключения NFS Datastore. Я правильно понял, что это бесполезно и все равно скорость выше 1Gbps не поднимется?

    ОтветитьУдалить
  19. 2dimsoft: если я чего-то не упустил, то нет, нельзя.

    2sergey: если соединение устанавливается на 1 ip со стороны nfs, то не поднимется.

    ОтветитьУдалить
  20. 2umlyaut: Инфа по ссылке практически неприменима к виртуалкам, если я правильно понимаю. Группировка по 802.3ad не заработает, а то что заработает - не даст толком задействовать больше одного аплинка.

    ОтветитьУдалить
  21. 2michigun: ну да, один датастор = 1 IP, NFS же не поддерживает multipath. Жаль что так все плохо.

    ОтветитьУдалить
  22. Насколько я помню докцментацию netapp для настройки их схд при работе по nfs - разные датасторы предполагается вешать на разные ip с обеих сторон - как рах чтобы по разным линкам разнести трафик, пусть и вручную.

    ОтветитьУдалить
  23. Для адаптеров Intel есть родные драйвера для 64бит систем и Nic Teaming там работает, запускал тут на днях в 2008R2.

    ОтветитьУдалить
  24. Сегодня пытался запустить на Catalyst 3750-24T.
    Подтверждаю, работает, НО(!) только после
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022751

    ОтветитьУдалить
  25. Прошу прощения, ESXi 4.0.0 build 398348. Работает именно GEC, собрал 4 порта циски и 4 порта HP DL380G6, etherchannel, src-dst-ip. Собственно саму балансировку ещё не проверял, но связность появилась. Без вышеуказанной ссылки ip-связность терялась, как только порт добавлялся в порт-группу. Также пробовал запустить Jumbo frames, MTU 9000 настроилось, но пинги больше 1500 не проходили. Дальше мучать не стал, т.к. каталист старый, а выше стоит 6500-Е, у которого (почему-то) только 2 значения MTU 1500 и 9216. Даже между ними связность пакетами выше 1500 сделать не получилось, да и оба свича боевые, особо не поэкспериментируешь. :-)

    ОтветитьУдалить
  26. начиналась статья с dvSwitch, так и осталось неясным как же на его аплинках использовать IP Hash Balancing и другие приятные вещи

    ОтветитьУдалить
  27. Если вопрос задан всеръез, то вам нужен абзац вот с таким началом:

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

    Мы меняем настройку балансировки нагрузки на "Load based IP hash"."

    ну а какие "другие приятные вещи" вы имеете в виду - я не знаю.

    ОтветитьУдалить
  28. в твоей книге я наше ответы на все вопросы, спасибо :)

    ОтветитьУдалить
  29. Михаил добрый день!
    Мне откровенно говоря не понятен механизм балансировки по IP hash на распределенном коммутаторе.
    Для большей конкретики- есть следующее:
    * два esxi5 с сет.адаптером на 4 порта по гигабиту (есть еще vmnic но они уйдут на vmk и трафик ВМ)
    * сервер под SAN iSCSI с 2мя сет.адаптерами на 4 порта по гигабиту (итого 8 портов по гигабиту)
    * коммутатор с гигабитовыми портами
    * на ESXi поднят dvSwitch на 4 uplink
    * все оборудование поддерживает 802.3ad

    Предполагалось сделать SAN iSCSI, по 4 Гбит от каждого ESXi до коммутатора и от него 8 гигабит до iSCSI СХД. Сеть iSCSI SAN предполагалось физически изолировать от основной сети.

    Так вот не понятно следующее:

    * если dvSwitch,согласно вашей книге, это объект сугубо логический от vcenter, а фактически скрытые коммутаторы vSwitch на самих ESXi

    * если uplink это тоже абстракция к которой цепляются физические vmnic, при том что на каждый из четырех uplink будут цепляться по одному vmnic от каждого гипервизора

    * в случае падения vcenter dvSwitch продолжит работать

    Как это вообще работает?
    Кто координирует работу всех vmnic?
    Или идет взаимокоординация между гипервизорами?
    Принимает ли участие в координации работы dvSwitch vcenter, ведь согласно предложенной схеме, он не будет в подсети ESCi<=>iSCSI-СХД?
    Или uplink'ов на dbSwitch должно быть не 4, а 8, что бы получить 4 гигабита от каждого ESXi?

    ОтветитьУдалить
    Ответы
    1. вам правильнее задать этот вопрос на форуме - там и удобнее, и больше людей вам помогут.

      вкратце:
      >Как это вообще работает?
      Вкратце - работает хорошо :-)

      >Кто координирует работу всех vmnic?
      Вообще всех vmnic- никто не координирует. Координируется работа только vmnic одного сервера.

      >Или идет взаимокоординация между гипервизорами?
      нет. только от vCenter на каждый ESXi независимо идет конфигурация коммутатора\коммутаторов.

      >Принимает ли участие в координации работы dvSwitch vcenter, ведь согласно предложенной схеме,
      >он не будет в подсети ESCi<=>iSCSI-СХД?
      в координации нет. vCenter (общаясь по сети управления) создает на ESXi эти коммутаторы. Затем каждый коммутатор на каждом хосте работает независимо. просто настройки идентичные, если мы говорим про dvSwitch.

      >Или uplink'ов на dbSwitch должно быть не 4, а 8, что бы получить 4 гигабита от каждого ESXi?
      формально говоря достаточно 4х.
      Однако для iSCSI вам ip hash не надо использовать, для iSCSI надо использовать iSCSI multipathing.

      Удалить
    2. Спасибо за оперативный ответ. Почему MPIO понял из вашей книги, после того как перечитал раздел про него. Последнее, что бы довести разговор до логичного завершения, перед тем как уползти на комьюнити:
      правильно ли я понял что о связке dvSwitch и iSCSI в этой ситуации может пойти речь только в случае выполнения следующих условий:
      * создания 8 uplink
      * создание 8 vmk (по 4 на каждый гипервизор) и разнесения каждого vmk в свою portgroup на dvSwitch
      * настройка teaming - 1 активный uplink на каждую portgroup (как следствие на каждый vmk)
      * привязать vmk на vmhba

      Удалить
    3. не совсем так.
      dvUplink надо столько, сколько аплинков на одном сервере. У вас, видимо, 4.
      одному dvUplick соответствует один vmnic с каждого(!) сервера.

      таким образом, создав vmk по числу dvUplink (на каждом сервере) и привязав один к одному - вы и получите искомое.

      Удалить