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