Стандартная статическая LAG vSwitch с аппаратными инициаторами iSCSI - невозможная конфигурация?
На одном сайте у нас есть хосты vSphere с 2 сетевыми картами 10G.
- Оба сетевых адаптера находятся в одном vSwitch
- Политика восстановления после отказа IP Hash для статической группы LAG (для балансировки / восстановления трафика виртуальной машины)
- На обеих сетевых платах (HPE 534FLR-SFP+/QLogic 57810) включены аппаратные инициаторы iSCSI
- Каждый инициатор связан с портом vmkernel один к одному.
- Одна подсеть iSCSI
- Оба HBA могут получить доступ ко всем целям SAN в стеке коммутаторов.
Коммутаторы серии Cisco C3850, а MPIO работает как проверенный временем (аварийное переключение на уровне пути и т. Д.).
Мы развернули аналогичную конфигурацию на другом сайте несколько дней назад. Та же конфигурация vSphere, те же сетевые карты. Однако на этот раз эта конфигурация не работает должным образом.
Инициаторы могут получать доступ только к Целям в портах того же коммутатора (к которому подключен инициатор), но не в портах другого коммутатора.
С помощью tcpdump я вижу, что порты vmkernel выполняют обнаружение для всех целей (выполняется vSphere в соответствии с документацией), цели статического обнаружения действительно появляются (SAN видит, что он был обработан), однако пути не создаются, и esxcli показывает ошибку 0x0004 (ошибка транспорта?) для целей в другом переключателе. Это довольно сложно исследовать, так как мы не можем напрямую видеть трафик HBA. Программное обеспечение iSCSI работает как шарм (привязанный к тем же портам vmkernel).
На этот раз коммутаторы - Cisco Nexus (я обновлю модель, когда я знаю это), и стекирование - VCP (?) Вместо родного C3850 (?). В остальном сайты в основном одинаковые, но ИМХО различия настолько незначительны, что не имеют значения. Просто чтобы указать на некоторые:
- HPE Proliant Gen9 против Gen10
- vSphere 6.5 против 6.7 - поскольку наша резервная копия теперь поддерживает 6.7, мы скоро обновим старый сайт.
Я искал документацию VMware и не нашел ничего, что говорило бы, что конвергентные сети не должны работать. Мы проконсультировались с нашим сетевым партнером, но они не поняли, как это работает в настоящее время, и подумали, что это не должно работать вообще.
Это нормальная конфигурация или мы зависим от какой-то особенности реализации C3850, которая не работает на других коммутаторах? Или что-то явно не так с выключателями?
1 ответ
Чтобы ответить на мой собственный вопрос... LAG не рекомендуется / не поддерживается ("не должен", "противопоказан" - слабая формулировка) с соединением портов:
Поддержка LACP не совместима с программным многолучевым распространением iSCSI. Многолучевое распространение iSCSI не должно использоваться с обычными статическими эфирными каналами или с LACP-связями.
Программная привязка портов iSCSI также противопоказана, когда LACP или другая агрегация каналов используются на восходящих каналах хоста ESXi к pSwitch.
По-видимому, Catalyst 3850 Stackwise работает совсем не так (он работает…) с Nexus Virtual Port Channel. Трафик никогда не пересекает межкоммутаторный канал при нормальных условиях, поэтому аппаратный iSCSI никогда не возвращает свои пакеты с портов SAN другого коммутатора. Решение состоит в том, чтобы вернуться к балансировке на основе идентификатора порта в vSwitch и отключить LAG. Балансировка трафика не так важна с 10G (хэш I P помог с легко перегруженными ссылками 1G).
Есть несколько слабых заявлений от Google о том, что для правильной работы VCP требуется LACP. У нас были некоторые потери пакетов в соединении Switch -> vSphere, которые исчезли, когда мы отключили LAG и переключились обратно на балансировку ID порта. Мне было известно, что vSwitch отбрасывает трафик, поступающий с неправильной восходящей линии связи (если виртуальная машина хэшируется на vmnic0, но трафик возвращается с vmnic1, он сбрасывается), но я не уверен, применимо ли это к балансировке хэша I P. С другой стороны, в документации говорится, что на стороне коммутатора поддерживается только IP-SRC-DST. Если VPC отправляет трафик в vSphere через локальный интерфейс коммутатора вместо правильного интерфейса на основе хеш-функции I P, это может считаться "неправильной" восходящей линией связи и отбрасываться. Опять же отключение LAG работало нормально.