Configuration de HP ProCurve 2810-24G pour iSCSI?

J'ai une paire de ProCurve 2810-24G que j'utiliserai avec un SAN Dell Equallogic et Vmware ESXi. Depuis ESXi fait MPIO, je suis un peu incertain sur la configuration des liens entre les commutateurs. Un coffre est-il la bonne voie à suivre entre les commutateurs?

Je sais que les ports pour le SAN et les hôtes ESXi doivent être non balisés, donc cela signifie-t-il que je veux un VLAN balisé sur les ports de jonction?

C'est plus ou moins la configuration:

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

Le SAN Equallogic PS4000 possède deux contrôleurs, avec chacun deux interfaces réseau. Dell recommande que chaque contrôleur soit connecté à chacun des commutateurs. D'après la documentation de vmware, il semble qu'il soit recommandé de créer un vmkernel par pNIC. Avec MPIO, cela pourrait permettre un débit supérieur à 1 Gbit / s.

Il y a eu un débat dans les commentaires de la réponse de Chopper3 qui n'est pas bien informé en raison de certains aspects mal compris des exigences de mise en réseau d'Equallogic et du comportement de multiacheminement.

D'abord du côté VMware: Pour les débutants du côté ESXi, la recommandation actuelle, lors de l'utilisation de l'initiateur logiciel iSCSI, de VMware (pour ESX \ ESXi 4.1) et Dell est que vous devez avoir un seul Nic physique mappé à chaque port VMkernel qui sera utilisé pour iSCSI. Le processus de liaison qui est maintenant recommandé applique cela. Cela nécessite que vous ayez un seul nic physique actif et aucune carte réseau de secours pour chaque port VMkernel. Aucune liaison autorisée. Vous pouvez maintenant tricher et revenir en arrière et ajouter un nic de basculement, mais l'intention est que MPIO gère le basculement afin que cela ne serve à rien (au moins lorsque tout fonctionne comme prévu par VMware).

La stratégie de multiacheminement par défaut autorisera des connexions actives et actives à un tableau Equallogic à l'aide du round robin.

Deuxièmement, le côté Equallogic: les baies Equallogic ont deux contrôleurs qui agissent en mode actif \ veille. Pour la PS4000, ceux-ci ont deux cartes réseau Gigabit sur chaque contrôleur. Pour le contrôleur actif, ces deux cartes réseau sont actives et peuvent recevoir des E / S de la même source. La configuration réseau recommande que les cartes réseau de la baie soient connectées à des commutateurs séparés. Du côté serveur, vous disposez de plusieurs liens qui doivent également être distribués sur des commutateurs séparés. Maintenant, pour la partie étrange - les tableaux Equallogic s'attendent à ce que tous les ports initiateurs puissent voir tous les ports actifs sur les tableaux. C'est l'une des raisons pour lesquelles vous avez besoin d'une jonction entre les deux commutateurs. Cela signifie qu'avec un hôte avec deux ports iSCSI VMkernel et une seule PS4000, il y a 4 chemins actifs entre l'initiateur et la cible - deux sont "directs"

Pour les connexions du contrôleur de secours, les mêmes règles s'appliquent, mais ces cartes réseau ne deviennent actives qu'après un basculement du contrôleur et les mêmes principes s'appliquent. Après le basculement dans cet environnement, il y aura toujours quatre chemins actifs.

Troisième pour des trajets multiples plus avancés: Equallogic dispose désormais d'un module d'extension à trajets multiples qui se connecte à l'architecture de stockage enfichable VMware qui fournit un équilibrage de charge intelligent (en utilisant la profondeur de file d'attente la plus faible, Round Robin ou MRU) sur les ports VMkernel. Cela ne fonctionnera pas si toutes les cartes réseau montantes vmkernel ne peuvent pas se connecter à tous les ports Equallogic actifs. Cela garantit également que le nombre de chemins réellement utilisés reste raisonnable - dans les grands environnements Equallogic, le nombre de chemins valides entre un hôte et un groupe Equallogic peut être très élevé car toutes les cartes réseau cibles sont actives et toutes les cartes réseau source peuvent voir toutes les cartes réseau cibles.

Quatrièmement pour les environnements Equallogic plus grands: lorsque vous développez un environnement Equallogic, vous ajoutez des tableaux supplémentaires dans un groupe partagé. Tous les ports actifs de toutes les baies membres d'un groupe doivent pouvoir voir tous les autres ports actifs de toutes les autres baies du même groupe. C'est une autre raison pour laquelle vous avez besoin de gros tuyaux fournissant des connexions inter-commutateurs entre tous les commutateurs de votre structure Equallogic iSCSI. Cette mise à l'échelle augmente également considérablement le nombre de chemins actifs valides entre les initiateurs et les cibles. Avec un groupe Equallogic composé de 3 baies PS6000 (quatre cartes réseau par contrôleur contre 2 pour la PS4000) et un hôte ESX avec deux ports vmkernel, il y aura 24 chemins actifs possibles pour la pile MPIO.

Cinquième liaison / agrégation de liens et liens Inter Switch dans un environnement Equallogic: Toutes les connexions inter-baies et initiateur <-> sont des connexions Gigabit point à point (ou 10Gig si vous avez une baie 10Gig). Il n'y a aucun besoin et aucun avantage à tirer de la liaison côté serveur ESX et vous ne pouvez pas lier les ports sur les baies Equallogic. Le seul domaine où l'agrégation de liens \ liaison \ quel que soit le type d'appel que vous souhaitez appeler est pertinent dans une structure Ethernet commutée Equallogic se trouve sur les liens entre les commutateurs. Ces liens doivent pouvoir transporter des flux simultanés pouvant égaler le nombre total de ports Equallogic actifs dans votre environnement - vous pouvez avoir besoin de beaucoup de bande passante globale même si chaque lien point à point entre les ports de baie et les ports d'initiateur est limité à 1 Gbit / s.

Enfin: dans un environnement Equallogic, le trafic d'un hôte (initiateur) vers une baie peut et traversera la liaison entre les commutateurs. Le fait qu'un chemin particulier le fasse ou non dépend de l'adresse IP source et de destination pour ce chemin particulier, mais chaque port source peut se connecter à chaque port cible et au moins un de ces chemins nécessitera de traverser l'ISL. Dans des environnements plus petits (comme celui-ci), tous ces chemins seront utilisés et actifs. Dans les environnements plus grands, seul un sous-ensemble de chemins possibles est utilisé, mais la même distribution se produira. La bande passante iSCSI agrégée disponible pour un hôte (si elle est correctement configurée) est la somme de toute sa bande passante de port vmkernel iSCSI, même si vous vous connectez à une seule baie et à un seul volume. Son efficacité est un autre problème et cette réponse est déjà beaucoup trop longue.

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 fait sa propre gestion des chemins - il ne sera pas actif / actif sur ses liens à moins que deux ou plusieurs de ses liens ne se dirigent vers le même commutateur ou que les commutateurs soient en mode de partage CAM tel que le VSS de Cisco - n'importe quoi sinon sera une configuration active / passive.

Par tous les moyens de jonction entre les commutateurs si vous voulez, mais ils ont probablement tous les deux des liaisons montantes vers un commutateur ou un routeur principal? Si tel est le cas, je ne sais pas exactement pourquoi vous tronceriez entre seulement deux commutateurs de cette manière, car les boîtes ESX / i passeront simplement au deuxième commutateur si le premier tombe en panne (s'il est configuré correctement de toute façon).

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?

Je ne sais pas d'où vient cette hypothèse, ESX / i est tout aussi à l'aise de travailler dans une configuration balisée ou non balisée, que ce soit pour le trafic invité ou iSCSI. Cela dit, j'ai eu des problèmes avec le mélange de balises et de balises lors de l'utilisation de réseaux locaux virtuels par défaut, donc je marque toujours tout maintenant et je n'ai pas de réseau local par défaut, c'est une configuration très flexible et aucune performance perceptible n'est atteinte dans mon expérience.

C'est le contrôleur de baie SAN qui définit comment vous devez vous connecter. Fournit-il le même LUN sur les deux ports du même contrôleur? Ensuite, le port0 va au commutateur A, le port1 au commutateur B et la même chose avec le contrôleur suivant.

Pourquoi voudriez-vous utiliser LACP / etherchannel contre un SAN iSCSI avec des ports de liaison montante 1 Gbit? Cela ne vous aide en aucune façon. Créez 2 vswitches avec un seul pNic dans chaque vSwitch et connectez le premier pNic au switchA, le deuxième pNic au switchB. Cela vous donnera une redondance complète contre les pannes de contrôleur / commutateur / nic.