Il s'agit d'une question canonique sur iSCSI que nous pouvons utiliser comme référence.

iSCSI est un protocole qui place les commandes SCSI comme charge utile dans les paquets réseau TCP. En tant que tel, il est soumis à un ensemble de problèmes différent de celui, par exemple, de Fibre Channel. Par exemple, si un lien est encombré et que les tampons du commutateur sont pleins, Ethernet abandonnera par défaut les trames au lieu de dire à l'hôte de ralentir. Cela conduit à des retransmissions qui entraînent une latence élevée pour une très petite partie du trafic de stockage.

Il existe des solutions à ce problème, en fonction du système d'exploitation client, y compris la modification des paramètres réseau. Pour la liste d'OS suivante, à quoi ressemblerait une configuration client iSCSI optimale? Cela impliquerait-il de modifier les paramètres des commutateurs? Et le stockage?

• VMWare 4 et 5
• Windows Hyper-V 2008 et 2008r2
• Windows 2003 et 2008 sur du métal nu
• Linux sur du métal nu
• AIX VIO
• Tout autre système d'exploitation que vous pensez être pertinent

Je ne connais pas VMWare, mais j'utilise Xenserver et j'ai utilisé Hyper-V (R2).

Avec ma configuration actuelle de Xenserver, j'ai:

• 8 serveurs Dell Poweredge 29xx
• 2 commutateurs Dell Powerconnect 6248
• 2 SAN Dell MD3000i (iSCSI)

J'ai installé mes commutateurs dans une configuration à trajets multiples et optimisé pour iSCSI en:

• Séparation de mes commutateurs en 3 VLAN (2 pour le trafic iSCSI et 1 pour la gestion)
• Utilisation de JumboFrames
• Appliquer les optimisations "iSCSI" que le powerconnect a

Chaque serveur dispose de plusieurs cartes réseau pour fournir une connexion à chaque commutateur, assurant à son tour la redondance via le multicheminage entre les serveurs et le SAN iSCSI. Les VLAN iSCSI ne contiennent aucun autre trafic que iSCSI.

Je suis heureux d'annoncer qu'avec cette configuration, le "cluster" Xenserver fonctionne à merveille.

Sur une note latérale, j'ai un serveur Windows 2008 connecté directement par iSCSI à un HP SAN (ancien serveur de fichiers). Il exécutait Windows 2003 et interrompait régulièrement la connexion (même après une réinstallation de 2003); cependant, dès que je suis passé à Windows 2008, il reste connecté.

Je serai heureux de répondre à toute question concernant ma configuration.

Ce n'est pas une réponse ... pour le moment. Ceci est le cadre de la réponse générique. Si vous avez le temps, veuillez remplir tout ce que vous savez. En ce qui concerne la configuration de matériel spécifique, veuillez publier une réponse distincte pour chaque fournisseur afin que nous puissions conserver ces informations organisées et séparées.

Profil de QoS pour les ports, ainsi que désactivation du contrôle de tempête, configuration de MTU sur 9000, activation du contrôle de flux et mise en portfast des ports

Débit et latence

Micrologiciel, pilotes et autres systèmes mis à jour

MPIO

Cadres Jumbo / MTU

À mesure que la vitesse des liaisons réseau augmente, le nombre de paquets potentiellement générés augmente également. Cela produit de plus en plus de temps CPU / interruption consacré à la génération de paquets, ce qui a pour effet à la fois de surcharger indûment le système de transmission et de prendre une quantité excessive de bande passante de liaison avec le tramage.

Les trames dites "jumbo" sont des trames Ethernet qui dépassent la limite canonique de 1518 octets. Bien que les nombres puissent varier en fonction des fournisseurs de commutateurs, des systèmes d'exploitation et des cartes réseau, les tailles de paquets jumbo les plus typiques sont 9000 et 9216 octets (ce dernier étant le plus courant). Étant donné qu'environ 6X les données peuvent être placées dans une trame 9K, le nombre de paquets réels (et d'interruptions) est réduit d'une quantité similaire sur l'hôte. Ces gains sont particulièrement prononcés sur les liaisons plus rapides (c.-à-d. 10GE) qui envoient de gros volumes de données (c.-à-d. ISCSI).

L'activation des trames jumbo nécessite la configuration de l'hôte et du commutateur Ethernet et un soin considérable doit être pris avant la mise en œuvre. Plusieurs lignes directrices doivent être suivies:

1.) Dans un segment Ethernet (VLAN) donné, tous les hôtes et routeurs doivent avoir la même MTU configurée. Un appareil sans configuration appropriée verra les trames plus grandes comme des erreurs de liaison (en particulier des "géants") et les supprimera.

2.) Dans le protocole IP, deux hôtes avec des tailles de trame différentes ont besoin d'un mécanisme pour négocier une taille de trame commune appropriée. Pour TCP, il s'agit de la découverte de chemin MTU (PMTU) et repose sur la transmission de paquets ICMP inaccessibles. Assurez-vous que PMTU est activé sur tous les systèmes et que toutes les ACL ou règles de pare-feu autorisent ces paquets.

Contrôle de flux Ethernet (802.3x)

Bien qu'il soit recommandé par certains fournisseurs iSCSI, le contrôle de flux Ethernet 802.3x simple ne doit pas être activé dans la plupart des environnements, sauf si tous les ports de commutateur, les cartes réseau et les liaisons sont entièrement dédiés au trafic iSCSI et rien d'autre. S'il y a un autre trafic sur les liens (comme le partage de fichiers SMB ou NFS, les battements de cœur pour le stockage en cluster ou VMware, le contrôle d'association des cartes réseau / surveillance du trafic, etc.), le contrôle de flux 802.3x simple ne doit pas être utilisé car il bloque des ports entiers et tout autre trafic non iSCSI sera également bloqué. Les gains de performances d'Ethernet Flow Control sont souvent minimes ou inexistants, une analyse comparative réaliste doit être effectuée sur l'ensemble des combinaisons OS / NIC / commutateur / stockage envisagées pour déterminer s'il existe un avantage réel.

La vraie question du point de vue des serveurs est la suivante: est-ce que j'arrête le trafic réseau si ma carte réseau ou réseau est saturée, ou est-ce que je commence à supprimer et retransmettre des paquets? L'activation du contrôle de flux permettra de vider les tampons de la carte réseau du côté du récepteur, mais mettra les tampons du côté de l'expéditeur en tension (normalement, un périphérique réseau tamponnera ici).

Contrôle de congestion TCP (RFC 5681)

TOE (moteurs de déchargement TCP / IP)

iSOE (moteurs de déchargement iSCSI)

LSO (Segmentation TCP / Déchargement d'envoi important)

Isolement du réseau

Une meilleure pratique courante pour iSCSI consiste à isoler les initiateurs et les cibles des autres trafics réseau hors stockage. Cela offre des avantages en termes de sécurité, de facilité de gestion et, dans de nombreux cas, d'allocation de ressources au trafic de stockage. Cet isolement peut prendre plusieurs formes:

1.) Isolement physique - tous les initiateurs ont un ou plusieurs NIC dédiés uniquement au trafic iSCSI. Cela peut impliquer ou non un matériel réseau dédié en fonction des capacités du matériel en question et des exigences spécifiques de sécurité et d'exploitation au sein d'une organisation donnée.

2.) Isolation logique - La plupart du temps, dans les réseaux plus rapides (c.-à-d. 10GE), les initiateurs ont un étiquetage VLAN (voir 802.1q) configuré pour séparer le trafic de stockage et le non-stockage.

Dans de nombreuses organisations, des mécanismes supplémentaires sont utilisés pour garantir également que les initiateurs iSCSI ne peuvent pas s’atteindre sur ces réseaux dédiés et que, en outre, ces réseaux dédiés ne sont pas accessibles à partir de réseaux de données standard. Les mesures utilisées pour y parvenir comprennent des listes de contrôle d'accès standard, des VLAN privés et des pare-feu.

Quelque chose à propos du fond de panier et du tissu de commutation ici aussi.

QoS (802.1p)

vLAN (802.1q)

STP (RSTP, MSTP, etc.)

Suppression du trafic (Storm Control, Multi / Broad-cast Control)

Sécurité

Authentification et sécurité

TYPE

IPSec

Cartographie des LUN (meilleures pratiques)

Une certaine considération et recherche que vous devriez être prises subjectivement en ce qui concerne:

1) Trajets multiples - Votre solution SAN et votre système d'exploitation, qu'il s'agisse d'un hyperviseur ou d'un système d'exploitation nu, peut nécessiter un logiciel spécifique au fournisseur pour que cela fonctionne correctement.

2) Initiateurs - Vous devez vérifier si l'initiateur logiciel est suffisamment performant en fonction des demandes. De nombreuses cartes réseau ont des capacités de déchargement iSCSI qui peuvent améliorer considérablement le débit, mais certains hyperviseurs plus anciens sont connus pour être assez énervés avec leur prise en charge. Les offres plus matures (ESXi 4.1+) semblent bien placées.

3) Sécurité / autorisations - Assurez-vous de bien vérifier quels initiateurs ont besoin d'accéder à quels LUN ... vous serez dans une mauvaise journée si un administrateur sur l'une de vos machines Windows fait un "disque d'initialisation" sur un disque qui est réellement utilisé par un autre serveur comme magasin de données VMware.