У меня за столом куча HP SAN и серверных ящиков.
Короче говоря, у меня будет 2 хоста vSphere, каждый с 12 pNIC, и один коммутатор Procurve 2910al (фактически два, но связанных), выделенный для трафика iSCSI / vMotion, и iSCSI SAN (P4000).
Некоторые сетевые адаптеры будут выделены моей производственной локальной сети в качестве сетевых адаптеров виртуальных машин, поэтому я могу получить доступ к серверу vCentre, а трафик iSCSI и все, что лучше всего сохранить в производственной локальной сети, будет передаваться на 2910al.
Я хочу представить iSCSI LUN некоторым гостям (Exchange / SQL /, возможно, файловый сервер) с помощью инициатора iSCSI Windows, чтобы я мог использовать встроенные в SAN моментальные снимки VSS.
Я также в идеале хочу иметь возможность управлять SAN из производственной сети, поэтому я предполагаю, что я бы использовал для этого функцию маршрутизации на коммутаторе?
Буду признателен за предложения по оптимальному способу настройки схемы коммутатора / VLAN.
С точки зрения vSphere вам нужна избыточность в Service console \ Management network. В идеале два отдельных разъема соединяются в два независимых переключателя. Итак, два сетевых устройства находятся в изолированной управляющей VLAN.
Vmotion \ Отказоустойчивость (если вы используете последний) как минимум два pnics, подключенных к двум независимым коммутаторам. Итак, два сетевых адаптера находятся в отдельной VLAN на procurve 2910 (s).
Для iSCSI, который будет представлен в среде vSphere, вам снова понадобится как минимум два, и в этом случае очень и очень важно, чтобы они подключались к независимым коммутаторам. С точки зрения cSphere рекомендуется настроить как можно больше отдельных vSwitches, с одним портом VMKernel на каждом и одним pnic. На каждом из этих портов vmKernel должен быть отключен трафик vMotion \ FT. Затем все порты iSCSI vmkernel необходимо привязать к стеку iSCSI, чтобы обеспечить переключение при отказе и переключение путей, если это вариант для вашего массива. Можно получить собственный многопутевый режим с балансировкой нагрузки без использования Enterprise Plus при условии, что у вашего поставщика есть модуль расширения Multipathing (MEM), если они предоставляют поставщика выбора пути (PSP), тогда требуется Enterprise Plus. Я не уверен, как LeftHand справляется с этим, в худшем случае вы получаете аварийное переключение, но без фактической балансировки нагрузки. На передней панели коммутатора сохраняйте подключения iSCSI в собственной VLAN на Procurves.
Для встроенного iSCSI, представленного виртуальным машинам, вам нужна такая же устойчивость, как минимум с двумя подключенными к отдельным физическим коммутаторам. В идеале вы должны повторить шаблон, используемый для коммутаторов vSphere iSCSI - один pnic на vSwitch и одну группу портов виртуальной машины на vSwitch. Это позволяет внутренним компонентам множественного пути в виртуальных машинах принимать разумные решения по управлению путями и дает им некоторую видимость состояния соединения на пути. Если для вас не важна балансировка нагрузки в виртуальной машине, тогда подойдет простое объединение и один vSwitch, но с учетом ваших планов, которые не кажутся оптимальными. Они снова подключаются к Procurves.
Я очень настоятельно рекомендую, чтобы ваши два Procurve не были настроены как единое логическое устройство (с использованием стекирования), если это вообще возможно. Лучше использовать множество межкоммутаторных каналов, сконфигурированных как одну группу LAG, если возможно, 10 ГБ с точки зрения управляемости и безопасности. Подумайте, как вы будете обновлять прошивку на этих коммутаторах или проводить другое обслуживание в дальнейшем.
В любом случае это использует до 8 из ваших 12 pnics на каждом хосте vSphere, оставляя вам четыре для производственного трафика, что кажется достаточно разумным.
Затем вы можете управлять средой iSCSI с виртуальных машин, у которых есть виртуальные узлы, подключенные к группам портов виртуальных машин iSCSI, если хотите, иначе вам нужно будет обеспечить некоторую связь между procurves и производственной средой. Определенно сделайте это на уровне 3 - вы хотите, чтобы среда iSCSI была максимально свободной от постороннего трафика на уровне 2.
Я предполагаю, что никто не сможет предоставить подробности без дополнительной информации о том, какая версия vSphere у вас есть (только Enterprise и Enterprise Plus поддерживают некоторые расширенные функции, такие как многопутевое хранилище), в дополнение к тому, что у вас требования для использования BW и отказоустойчивости. С учетом сказанного, при планировании этого материала я всегда разбиваю сетевые адаптеры на следующие четыре категории, затем определяю, какие у меня требования для каждой, а затем указываю, что на самом деле может быть выполнено:
Вам нужна избыточность для каждого? Вам нужно больше 1G для каждого? Достаточно ли у вас сетевых карт для обеспечения избыточности? (В этом случае вы это делаете, ИМХО.) После того, как вы примете эти решения, затем планируете, что на самом деле подключить, где должно быть проще простого (при условии, что вы собираетесь поддерживать разделение между четырьмя вышеуказанными сетями, что я рекомендую).
Похоже, вам понадобится как минимум
Хорошо, что у вас есть 12 сетевых карт на каждом хосте, потому что вы уже на пределе!
Предполагая, что коммутаторы ведут себя как единое целое, вам понадобится VLAN для управления, одна для vMotion и одна для хранилища, и вы подключите все так, чтобы каждая группа имела равные подключения к двум физическим коммутаторам.