Сообщения
Вводная
У нас есть виртуальный коммутатор, у него несколько физических интерфейсов, через которые он подключен к двум физическим коммутаторам
(такая схема, с поправкой на число аплинков(физических сетевых контроллеров), видится мне типовой).
См. рис.1:
Левая часть этой схемы - связь от виртуальной машины до виртуального коммутатора.
Правая часть - от виртуального коммутатора до коммутаторов физических.
Обе эти части схемы, независимо друг от друга, периодически обсуждаются в контексте повышения производительности сети. Что об этом можно сказать:
1. Производительность и балансировка нагрузки для "виртуальной" стороны - vNIC <-> vSwitch
Тут ситуация довольно простая, и вариантов у нас не много. Сразу оговорка - все эти варианты предполагают увеличение скорости сети только "внутри" ESX(i). Если нас интересует быстрая сеть между ВМ и кем-то "снаружи", то в дело вступает еще и "физическая сторона", которая, при настройках по умолчанию, ограничит нашу ВМ производительностью одного аплинка, для большинства из нас это гигабит. Но обсудить варианты все равно важно - о физической стороне позже.
Вариант 1
Один виртуальный сетевой контроллер, и побыстрее В простом случае у виртуальной машины одна виртуальная сетевая карта, обычно типа e1000, vmxnet2 или vmxnet3. Сетевая карта последнего типа должна дать скорость до 8( или даже до 16, по данным некоторых тестов) гигабит\с на "виртуальной" стороне моей схемы, т.е. до виртуального коммутатора (вот тут см. подробности - vSphere network test - vmxnet3). Таким образом, если интенсивный трафик у нас между виртуальными машинами, и, важно!, эти виртуальные машины:
Нас может ограничить то, что не все ОС имеют драйвер для 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).
Тип группировки указывает:
Характеристики этого метода следующие:
Вывод - данный метод повышения производительности сети для виртуальных машин практически не применим, в варианте от Intel.
2. Производительность и балансировка нагрузки для "физической" стороны - vSwitch <-> pSwitch
Итак - если виртуальная машина хочет сеть с большой полосой пропускания до другой виртуальной машины на том же ESX(i), том же виртуальном коммутаторе и в том же VLAN - то предоставить ее ей можно за счет быстрого виртуального сетевого контроллера, в первую очередь vmxnet3.
А если эти условия не выполняются, т.е. трафик надо передавать через физический коммутатор? Это означает, что даже при наличии быстрого канала до виртуального коммутатора, бутылочным горлышком могут стать его гигабитные интерфейсы. Вернее, тот один, через который пойдет трафик при настройках по умолчанию.
Есть для ESX(i) такая настройка виртуального коммутатора, как Load Balancing, балансировка нагрузки (рис. 3)
Там есть два больше всего интересующих нас варианта:
От второго ожидают лучшего распределения трафика.
Мне хочется проговорить аккуратно и конкретно о второй настройке балансировки нагрузки для виртуального коммутатора, и связанных со всем этим вещах.
Итак - мы хотим большей производительности на "физической" стороне сети 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
Так вот – формально говоря, в контексте обсуждения балансировки нагрузки для виртуальных коммутаторов 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(как протокол автоматической настройки), и не смогут сами договориться с физическими коммутаторами об настройке агрегации каналов.
Итак, группа портов на физическом коммутаторе у нас есть. Но это еще не все.
Есть вот какой нюанс: при одной и той же группировке по стандарту 802.3ad на физических коммутаторах могут применяться разные алгоритмы непосредственно балансировки.
Как справочную информацию см. очень полезную, имхо, статью базы знаний - 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) можно дать хорошую скорость к соседней виртуальной машине, и неплохую, с определенными оговорками, к внешним машинам.
Оговорки:
На руборде я как-то вычитал следующий вариант организации сети, комбинированный -
от продакшн ВМ vmxnet3 до ВМ2(на одном вКоммутаторе),
а в ВМ2 поднят софт, умеющий делать более эффективную группировку группировку - выводящий трафик на физику через несколько аплинков сервера ESX(i).
Если продакшн ВМ шлет большую кучу трафика единственному клиенту - такой же ВМ, к примеру, но на другом ESX(i), то через промежуточные ВМ можно попробовать поднять "более толстый" канал.
Правда, реализуем ли такой вариант, и если да то как, - я сказать затрудняюсь, запомнилась сама идея.
За консультации и помощь в подготовке материала биг thx Денису Батурину и Евгению Ковальскому.
Комментарии приветствуются.
У нас есть виртуальный коммутатор, у него несколько физических интерфейсов, через которые он подключен к двум физическим коммутаторам
(такая схема, с поправкой на число аплинков(физических сетевых контроллеров), видится мне типовой).
См. рис.1:
 |
| Рис. 1. Иллюстрация компонентов сети |
Левая часть этой схемы - связь от виртуальной машины до виртуального коммутатора.
Правая часть - от виртуального коммутатора до коммутаторов физических.
Обе эти части схемы, независимо друг от друга, периодически обсуждаются в контексте повышения производительности сети. Что об этом можно сказать:
1. Производительность и балансировка нагрузки для "виртуальной" стороны - vNIC <-> vSwitch
Тут ситуация довольно простая, и вариантов у нас не много. Сразу оговорка - все эти варианты предполагают увеличение скорости сети только "внутри" ESX(i). Если нас интересует быстрая сеть между ВМ и кем-то "снаружи", то в дело вступает еще и "физическая сторона", которая, при настройках по умолчанию, ограничит нашу ВМ производительностью одного аплинка, для большинства из нас это гигабит. Но обсудить варианты все равно важно - о физической стороне позже.
Вариант 1
Один виртуальный сетевой контроллер, и побыстрее В простом случае у виртуальной машины одна виртуальная сетевая карта, обычно типа e1000, vmxnet2 или vmxnet3. Сетевая карта последнего типа должна дать скорость до 8( или даже до 16, по данным некоторых тестов) гигабит\с на "виртуальной" стороне моей схемы, т.е. до виртуального коммутатора (вот тут см. подробности - vSphere network test - vmxnet3). Таким образом, если интенсивный трафик у нас между виртуальными машинами, и, важно!, эти виртуальные машины:
- на одном сервере ESX(i)
- на одном виртуальном коммутаторе
- в одном VLAN
Нас может ограничить то, что не все ОС имеют драйвер для 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 этого не умеет на "внутренних" портах;
- кроме входящего трафика, только по одному интерфейсу группы ходит широковещательный и мультивещательный трафик.
Вывод - данный метод повышения производительности сети для виртуальных машин практически не применим, в варианте от Intel.
2. Производительность и балансировка нагрузки для "физической" стороны - vSwitch <-> pSwitch
Итак - если виртуальная машина хочет сеть с большой полосой пропускания до другой виртуальной машины на том же ESX(i), том же виртуальном коммутаторе и в том же VLAN - то предоставить ее ей можно за счет быстрого виртуального сетевого контроллера, в первую очередь vmxnet3.
А если эти условия не выполняются, т.е. трафик надо передавать через физический коммутатор? Это означает, что даже при наличии быстрого канала до виртуального коммутатора, бутылочным горлышком могут стать его гигабитные интерфейсы. Вернее, тот один, через который пойдет трафик при настройках по умолчанию.
Есть для ESX(i) такая настройка виртуального коммутатора, как Load Balancing, балансировка нагрузки (рис. 3)
 |
| Рис. 3. Варианты балансировки нагрузки для вКоммутатора |
Там есть два больше всего интересующих нас варианта:
- Load based original port ID - трафик от одного порта на "виртуальной" стороне выходит через какой-то один порт "физической" стороны, т.е. через какой-то один физический сетевой контроллер.
- 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 на физических коммутаторах могут применяться разные алгоритмы непосредственно балансировки.
Вот примерный список:И на стороне физического коммутатора обязательно должна быть балансировка нагрузки по IP (IP-Source-Destination) - потому что балансировку только лишь по такому алгоритму поддерживает коммутатор VMware, а алгоритм должен быть одинаков на "обоих концах" агрегированных каналов.
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
Как справочную информацию см. очень полезную, имхо, статью базы знаний - 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 Денису Батурину и Евгению Ковальскому.
Комментарии приветствуются.
