У моих хостов ESX по 8 сетевых адаптеров.
Я установил 2 сетевые карты для нашей iSCSI SAN - каждая подключена к другому коммутатору SAN. 2 сетевых адаптера настроены для vMotion и Service Console - каждая из них подключена к разному базовому коммутатору (порты соединены с VLAN, выделенными для vMotion и Management)
У меня осталось четыре порта. В настоящее время мы настроили их для каждого входа в нашу VLAN по умолчанию. Два сетевых адаптера подключены к одному коммутатору ядра, а два - к другому. Мы решили объединить подключения к каждому коммутатору, чтобы они были объединены в группу на конце vswitch, а порты были направлены на физическом конце коммутатора.
Я сейчас чтение тот порт, через который проходят эти соединения, не особенно полезен, возможно, даже слишком усложняет ситуацию.
Есть ли особая проблема с использованием каналов портов для VMware? Какой метод обеспечивает наилучший баланс между избыточностью и производительностью?
Сообщение, на которое вы ссылаетесь, подчеркивает пример неправильной конфигурации. Первый комментарий - это то, что мы сделали в нашей среде - 4 сетевых адаптера в эфирном канале через два стековых коммутатора Cisco. В этой конфигурации нет ничего плохого, и она отлично работает уже более года - просто имейте в виду, что вы получаете не канал 4 Гбит / с, а 4 канала 1 Гбит / с.
Изменить: я также хочу указать, что если вы хотите распределить каналы между двумя коммутаторами для резервирования, они должны быть каким-то образом сгруппированы - независимые коммутаторы не будут работать. Если у вас есть два независимых коммутатора, портканал не подходит.
Дункан Эппинг хорошо знаком со своими сетями VMware, и описанный им сценарий особенно неприятен, но немного необычен (четыре ника объединены в две отдельные группы Etherchannel). Однако его анализ верен - VMware не поддерживает агрегацию каналов так, как это требуется для настройки.
Агрегация портов не улучшает пропускную способность отдельного сеанса, а упрощает общее использование доступных каналов. Ваши четыре ссылки никогда не будут использоваться для предоставления одного сеанса с сервера с потенциальной пропускной способностью 4 Гбит / с, например, отдельные сеансы по-прежнему проходят через одну нишу на хосте VMware (или любой другой системе, если на то пошло) и проходят через ваши коммутаторы через один точка-точка соединения. Однако, если вы выберете алгоритм балансировки нагрузки, отдельные сеансы будут распределены по доступным ссылкам, что обеспечит вам лучшую общую производительность. С помощью VMware вы можете выбрать различные политики объединения (только аварийное переключение, маршрут по хешу исходного порта и маршрут по хешу IP источника \ назначения), и, если он не изменен недавно, он поддерживает только статическое транкинг, а не активный LACP. Балансировка нагрузки будет работать только на правильно настроенных коммутаторах, поэтому, если вы хотите ее использовать, вам придется выполнить какую-то конфигурацию объединения портов \ Etherchannel на ваших коммутаторах. Эта статья базы знаний VMware объясняет некоторую предысторию и дает пример конфигурации Cisco и HP.
Недостатком является то, что если вы хотите распределить свои сетевые адаптеры по отдельным коммутаторам и использовать IP-хеширование для балансировки нагрузки, они должны быть каким-то образом уложены в стек, иначе вы столкнетесь с проблемой, аналогичной описанной Дунканом. Это имеет некоторые очевидные риски с точки зрения возможности проблем с этим стеком, влияющих на все сетевые адаптеры одновременно. Тот факт, что VMware все еще не полностью поддерживает LACP для vSwitches, делает это намного сложнее, чем должно быть.