Тип маршрутизации LACP должен быть тем же на всех концах?
UEC действительно использует виртуализацию KVM однако! Я думал бы, что лучшее конкурентное преимущество VMware является доступностью сформировавшихся инструментов управления GUI, и лучшее конкурентное преимущество UEC является открытым исходным кодом и обеспечивает совместимый API-интерфейс EC2
LACP следует рассматривать как «механизм проверки» агрегации ссылок.
Вы не добьетесь лучшей производительности независимо от того, используете ли вы статическую LAG или LACP LAG. Что вы получите, так это более быстрое переключение при отказе и некоторый интеллект, который проверяет, что ссылки работоспособны , прежде чем вводить их в LAG.
Теперь ... в зависимости от вашего ТРАФИКА .... прямо ответил бы на ваш вопрос, что лучше. Каждый участник канала может использовать различные методы (IP-адрес / адрес, MAC-адрес / адрес), чтобы выбрать, как EGRESS трафик. В идеале оба конца ссылки будут делать то же самое, но это не обязательно.
У NetApp есть ЗАМЕЧАТЕЛЬНЫЙ документ по этому поводу, охватывающий несколько различных сценариев, но позвольте мне сразу перейти к делу:
1) Вы ' вы захотите иметь отдельную привязку LACP к каждому VIF, по одному на каждую головку NetApp.
2) Вам следует настроить статические LAG на стороне ESXi, если вы используете 5.0 или более раннюю версию, и LACP с поддержкой LAG, если вы: повторно работает 5.1 или новее.
Как только вы достигнете ограничений 1GbE для этого NetApp, вам нужно будет либо перейти на карты 10GbE, либо получить более мощный фильтр.
РЕДАКТИРОВАТЬ: Вот ссылка на документацию, теперь может быть исправление 5.1 http://media.netapp.com/documents/tr-3749.pdf
Нет, нет причин для совпадения алгоритмов хеширования на каждой стороне. LACP не знает и не заботится о стратегии удаленного хеширования. Одноранговые узлы LACP не согласовывают хеширование, потому что им все равно, как их одноранговый узел балансирует трафик. Отсутствует проверка того, что входящий фрейм пришел в "правильный" интерфейс.