Настройка HP ProCurve 2810-24G для iSCSI?

8

У меня есть пара ProCurve 2810-24G, которые я буду использовать с Dell Equallogic SAN и Vmware ESXi. Поскольку ESXi поддерживает MPIO, я немного сомневаюсь в конфигурации соединений между коммутаторами. Является ли магистраль правильным путем между коммутаторами?

Я знаю, что порты для SAN и хостов ESXi должны быть без тегов, значит ли это, что я хочу помечать VLAN на портах магистрали?

Это более или менее конфигурация:

trunk 1-4 Trk1 Trunk 
snmp-server community "public" Unrestricted 
vlan 1 
    name "DEFAULT_VLAN" 
    untagged 24,Trk1 
    ip address 10.180.3.1 255.255.255.0 
    no untagged 5-23 
exit 
vlan 801 
    name "Storage" 
    untagged 5-23 
    tagged Trk1 
    jumbo 
exit 
no fault-finder broadcast-storm 
stack commander "sanstack" 
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree force-version RSTP-operation

Equallogic PS4000 SAN имеет два контроллера с двумя сетевыми интерфейсами каждый. Dell рекомендует подключать каждый контроллер к каждому из коммутаторов. Из документации vmware кажется, что рекомендуется создать одно vmkernel для pNIC. С MPIO это может обеспечить пропускную способность более 1 Гбит / с.

введите описание изображения здесь

3molo
источник

Ответы:

12

В комментариях к ответу Chopper3 были некоторые споры, которые недостаточно хорошо информированы из-за некоторых плохо понятых аспектов сетевых требований Equallogic и поведения при многолучевом распространении.

Во-первых, на стороне VMware. Для начинающих на стороне ESXi текущая рекомендация при использовании программного инициатора iSCSI от VMware (для ESX \ ESXi 4.1) и Dell состоит в том, что у вас должен быть один физический Nic, сопоставленный каждому порту VMkernel, который будет используется для iSCSI. Процесс привязки, который сейчас рекомендуется, обеспечивает это. Это требует, чтобы у вас был только один активный физический ник и никаких резервных сеток для каждого порта VMkernel. Не допускается склеивание. Теперь вы можете обмануть это, а потом вернуться назад и добавить отказоустойчивый ник, но намерение состоит в том, что MPIO будет обрабатывать аварийное переключение, так что это не приносит никакой пользы (по крайней мере, когда все работает так, как задумано VMware).

Политика многолучевого распространения по умолчанию разрешает активные, активные подключения к массиву Equallogic с использованием циклического перебора.

Вторая сторона Equallogic: массивы Equallogic имеют двойные контроллеры, которые работают в активном режиме ожидания. Для PS4000 у них есть два гигабитных Nics на каждом контроллере. Для активного контроллера обе эти сети активны и могут получать ввод-вывод от одного и того же источника. Конфигурация сети рекомендует подключать сетку к отдельным коммутаторам. Со стороны сервера у вас есть несколько ссылок, которые также должны быть распределены по отдельным коммутаторам. Теперь о странной части - массивы Equallogic ожидают, что все порты инициатора могут видеть все активные порты в массивах. Это одна из причин, по которой вам нужен транк между двумя коммутаторами. Это означает, что для хоста с двумя портами VMkernel iSCSI и одним PS4000 существует 4 активных пути между инициатором и целью - два являются «прямыми»

Для подключений резервного контроллера применяются те же правила, но эти функции будут активны только после аварийного переключения контроллера и применяются те же принципы. После отработки отказа в этой среде все еще будет четыре активных пути.

В-третьих, для более продвинутого многопутевого доступа : Equallogic теперь имеет модуль Multipath Extension Module, который подключается к архитектуре VMware Plugable Storage, которая обеспечивает интеллектуальное распределение нагрузки (с использованием минимальной глубины очереди, Round Robin или MRU) через порты VMkernel. Это не будет работать, если все восходящие каналы vmkernel не могут подключиться ко всем активным портам Equallogic. Это также гарантирует, что число фактически используемых путей остается разумным - в больших средах Equallogic число допустимых путей между хостом и Equallogic Group может быть очень большим, поскольку все целевые сети активны, и все исходные сети могут видеть все целевые сети.

В-четвертых, для более крупных сред Equallogic. По мере расширения среды Equallogic вы добавляете дополнительные массивы в общую группу. Все активные порты на всех членских массивах в группе должны видеть все другие активные порты на всех других массивах в той же группе. Это еще одна причина, по которой вам нужны толстые каналы, обеспечивающие межкоммутаторные соединения между всеми коммутаторами в вашей структуре Equallogic iSCSI. Такое масштабирование также значительно увеличивает количество действительных активных путей между инициаторами и целями. С Equallogic Group, состоящей из 3 массивов PS6000 (четыре nics на контроллер против 2 для PS4000), и хостом ESX с двумя портами vmkernel, будет 24 возможных активных пути для стека MPIO на выбор.

Пятое объединение \ агрегация ссылок и связи между коммутаторами в равноправной среде. Все соединения между массивами и массивами инициатора <-> являются одноточечными гигабитными соединениями (или 10 гигабит, если у вас есть массив 10 гигабайт). Нет необходимости и нет никакой выгоды от соединения на стороне сервера ESX, и вы не можете связать порты на массивах Equallogic. Единственная область, в которой агрегация ссылок \ соединение \ независимо от того, что вы хотите назвать, уместна в коммутационной матрице Equallogic с коммутацией каналов, - это межсоединения. Эти каналы должны иметь возможность переносить параллельные потоки, которые могут равняться общему количеству активных портов Equallogic в вашей среде - вам может потребоваться большая суммарная пропускная способность, даже если каждая точка-точка соединения между портами массива и портами инициатора ограничена 1 Гбит / с.

Наконец: в среде Equallogic трафик от хоста (инициатора) к массиву может и будет проходить по межсоединению. То, будет ли это делать конкретный путь, зависит от IP-адреса источника и назначения для этого конкретного пути, но каждый исходный порт может подключаться к каждому целевому порту, и по меньшей мере один из этих путей потребует пересечения ISL. В небольших средах (таких как этот) все эти пути будут использованы и активны. В больших средах используется только подмножество возможных путей, но такое же распределение будет. Общая пропускная способность iSCSI, доступная хосту (если он правильно настроен), представляет собой сумму всей пропускной способности порта iSCSI vmkernel, даже если вы подключаетесь к одному массиву и одному тому. Насколько это может быть эффективно - это еще одна проблема, и этот ответ уже слишком длинный.

Helvick
источник
1
Вы должны следовать этому совету! Я работаю в крупнейшем торговом посреднике EQL на Среднем Западе, я ежедневно подключаю эти системы. Маркировка / транки - это способ пойти и позволить плагину MEM создать вас для вас. Ваш ISL должен быть настолько большим, насколько вы можете себе позволить, чтобы он был подключен. Обычно мы используем стекируемые коммутаторы. Juniper EX4200 УДИВИТЕЛЬНЫ для iSCSI.
SpacemanSpiff
Вау, классный ответ. До сих пор не видел этого сообщения, но мне удалось все настроить и работать, как ожидалось, и результаты измерений показывают, что он работает так же хорошо, как и сейчас. Еще нужно проверить все резервирование. Большое спасибо за ваш чрезвычайно информативный ответ!
3моло
6
Since ESXi does MPIO, I am a little uncertain on the configuration for links between the switches. Is a trunk the right way to go between the switches?

ESX / i осуществляет свое собственное управление путями - он не будет активным / активным на своих каналах, если два или более каналов не будут подключены к одному и тому же коммутатору или коммутаторы находятся в режиме совместного использования CAM, например, VSS Cisco - что угодно иначе будет активная / пассивная конфигурация.

Во что бы то ни стало транк между коммутаторами, если вы хотите, но, вероятно, они оба имеют восходящие ссылки на какой-то основной коммутатор или маршрутизатор? если это так, то я не совсем уверен, почему вы будете соединяться между двумя коммутаторами таким образом, поскольку блоки ESX / i просто переключатся на второй коммутатор, если первый выйдет из строя (если все равно настроен правильно).

I know that the ports for the SAN and the ESXi hosts should be untagged, so does that mean that I want tagged VLAN on the trunk ports?

Я не знаю, откуда взялась эта гипотеза, ESX / i так же комфортно работает с тегами или без тегов, как для гостевого трафика, так и для трафика iSCSI. Тем не менее, у меня были проблемы со смешиванием тегов и тегов при использовании VLAN по умолчанию, поэтому я всегда помечаю все сейчас и у меня нет VLAN по умолчанию, это очень гибкая настройка и не имеет заметного снижения производительности в моем опыте.

Chopper3
источник
Я почти уверен, что в документации ESXi для хранилищ SAN говорится, что не следует связывать устройства, а вместо этого полагаться на MPIO как для повышения производительности, так и для преимуществ избыточности (независимо от того, идут ли ссылки на один и тот же коммутатор или нет). Конечно, не будет никаких связей с основными коммутаторами, это пара коммутаторов только для хранения. Я также заявляю, что я намерен использовать VLAN без тегов для хостов и SAN, так что мой вопрос остается в силе; я должен или не должен использовать TAGGED в магистральных связях?
3моло
1
Причина использования помеченных портов заключается в том, что вам нужно перенести более одной VLAN по ней. Маркировка VLAN дает вам возможность различать их. Вам также не нужно использовать LACP для создания агрегации каналов (транк для HP, Etherchannel для Cisco). Вы можете установить статическую группу агрегации и получить выгоду от балансировки на стороне коммутатора и отработки отказа. Тем не менее, также распространено оставлять сторону коммутатора в покое и позволять ESX управлять принятием решения о трафике.
Макмил
Макмил, пожалуйста, подумайте над реальным ответом. Это легче комментировать. Не уверен, как будет конфигурация межкоммутатора, если я позволю ESXi принимать решения?
3моло
-1 Чоппер, я чувствую, что вы либо недостаточно знаете о предмете, либо не совсем прочитали мой вопрос.
3моло
1
LAG работает как положено. У меня есть две ссылки по 1 Гбит, и эквалайзер подключен к одному коммутатору каждый. Я получаю до 235 МБ / с последовательного чтения и записи. Либо мы совсем не поняли друг друга, либо я был прав в своих утверждениях о настройке. Кстати, его циклический перебор, но он активен / активен.
3моло
1

Это контроллер массива SAN, который определяет, как вы должны это подключить. Это обеспечивает тот же LUN ​​на обоих портах на том же контроллере? Затем порт 0 переходит к коммутатору А, порт 1 - коммутатору В и то же самое со следующим контроллером.

Почему вы хотите использовать LACP / etherchannel против iSCSI SAN с портами восходящей линии связи 1 Гбит? Это никак не поможет вам. Создайте 2 vswitch с одним pNic в каждом vSwitch и подключите первый pNic к switchA, второй pNic к switchB. Это обеспечит вам полное резервирование против сбоев контроллера / коммутатора / никеля.

pauska
источник
Etherchannel / LACP только для межкоммутаторов, но это мне совсем не помогает? Я предполагал, что соединения могут проходить между коммутаторами из-за MPIO, в случае, скажем, порта на коммутаторе, к которому подключен один из контроллеров.
3моло
Зачем проходить соединения между коммутаторами? Это не имеет никакого смысла.
pauska
1
Каждый инициатор связывается с IP-адресом группы, который перенаправляет на IP-адрес одного из сетевых адаптеров в группе. Нет ничего, что могло бы остановить инициатор на коммутаторе A, подключенном к массиву на его сетевой плате, подключенной к коммутатору B. В зависимости от количества соединений, достаточно соединения LACP 4 Гб между коммутаторами, чтобы избежать каких-либо проблем. Я лично предпочитаю подключить все порты на контроллере к одному коммутатору. Когда вы разделяете их, вы вдвое уменьшаете пропускную способность массива в ситуации сбоя.
SpacemanSpiff
Отличный ответ SpacemanSpiff, я пошел с 2 ссылками LACP.
3моло