Bonjour à tous,
 
Je suis face à un problème dans le cadre de l'implémentation d'une infra. virtualisée.
L'infra est composée de :

• 2 serveurs Dell R620 disposant chacun de 2 cartes réseau 4 ports (2 ports LAN, 2 ports Management et 4 ports ISCSI)
• 2 switch PowerConnect 6224 (24x 1Gb/s) avec un LAG de 4 ports pour les interconnecter
• 1 SAN EqualLogic PS6100X (4x 1Gb/s - 24x 600Go SAS 10k)
• 1 NAS Synology DS1813+ (4x 1Gb/s - 6x 500Go SATA 10k - 2x 256Go SATA SSD)

L'implémentation du réseau ISCSI à été réalisé en suivant les préco Dell :
Chaque Hyperviseur ESXi possède 4 ports VMkernel ISCSI adressé dans le même subnet : 192.168.100.X (chaque port est attaché à une interface dédiée)
Les 4 interfaces du SAN (4 interfaces par contrôleur en mode actif/passif) sont adressées dans le même subnet.
L'initiateur ISCSI logiciel est configuré pour accéder à l'IP du groupe EqualLogic et présente bien 4 chemins par LUN.
 
La problématique est la suivante :
Une des interface du NAS Synology est attachée au LAN et les autres 3 interfaces sont dédiées au ISCSI avec chacune IP (dans le même subnet).
En conséquences l'initiateur ISCSI détecte pour chaque LUN un très grand nombre de chemins : 4 (ports ESXI) x 3 (ports NAS) = 12 chemins par LUN !!!
Les ressources documentaires Synology préconisent l'utilisation de subnet différents pour chaque interface mais cela m'est impossible à cause des préco de Dell (si non respectées = pas de support).
 
Je n'ai pas encore fait de tests poussés mais d'après mes premières constatations il y a des chemins inactifs et les performances sont faibles ...
 
Des idées ou suggestions ?
Merci d'avance.

Un peu plus de détails sur la situation :

• ESXi à les 4 interfaces suivantes : 192.168.100.11 , 192.168.100.12 , 192.168.100.13 , 192.168.100.14
• SAN à les 3 interfaces suivantes : 192.168.100.102 , 192.168.100.103 , 192.168.100.104 ( + Groupe : 192.168.100.100)
• NAS à les 4 interfaces suivantes : 192.168.100.151 , 192.168.100.152 , 192.168.100.153 , 192.168.100.154

Chaque LUN de l'EqualLogic est attaché avec 1 chemin unique, par ex :

• 192.168.100.11 - 192.168.100.101
• 192.168.100.12 - 192.168.100.102
• 192.168.100.13 - 192.168.100.103
• 192.168.100.14 - 192.168.100.104

 
Chaque LUN du Synology est attaché avec des chemins croisés, par ex :

• 192.168.100.11 - 192.168.100.152
• 192.168.100.12 - 192.168.100.152
• 192.168.100.13 - 192.168.100.152
• 192.168.100.14 - 192.168.100.152
• 192.168.100.11 - 192.168.100.153
• 192.168.100.12 - 192.168.100.153
• 192.168.100.13 - 192.168.100.153
• 192.168.100.14 - 192.168.100.153
• 192.168.100.11 - 192.168.100.154
• 192.168.100.12 - 192.168.100.154
• 192.168.100.13 - 192.168.100.154
• 192.168.100.14 - 192.168.100.154

/question con
 
pas possible de créer un vlan différent pour le iscsi du synology et de respecter les préco de synology et de dell du coup?

Ce serait possible mais dans ce cas il faudrait faire du routage car les interfaces des ESXI sont utilisées pour le NAS et le SAN !
Je ne pense pas que ce type de configuration soit supportée...

ce sont les mêmes interfaces iscsi de esxi pour l'equalogic et le synology?

Oui !
Edit : mêmes interfaces physiques et même VMkernel

Ca te gène les chemins croisés ?

 
Non pas du tout, ce qui me gène c'est le résultat du test suivant :
 
Les tests ont été lancés à partir de 4VM disposés chacune sur 2 serveurs ESXI distincts placées dans le même datastore (SSD)
La configuration du test a pour objectif de tester la bande passante max.

 
Au niveau du NAS on voit clairement qu'il y a un problème : seule l'une des interfaces est utilisée à 100% (120Mo/s) alors que les autres sont inexploitées (< 500kb/s) ...

Exact.

Suite aux résultats étranges obtenus j'ai décidé d'implémenter les deux ports VMkernel par port réseau (afin de vérifier si les performances maximales variaient).
 
Les résultats parlent d'eux même :

 
Ceci me confirme donc qu'il y a un impact sur les performances lié à l'installation dans le même subnet !
 
Reste donc à définir si je conserve cette configuration au risque que le support de Dell me dise que c'est une implémentation non conforme.

Il y quelques jours j'ai lu un tweet du compte officiel @equallogic qui renvoyait sur un forum traitait justement de la cohabitation EqualLogic / MD31200 ...
 
Voici la réponse donnée :
http://en.community.dell.com/techc [...] x#20422928

 
Question : pourquoi créer des VLAN supplémentaires si on est déjà sur des subnet différents ?

les subnet c'est niveau 3, les vlan niveau 2, c'est pour rester cohérent et isoler à chaque niveau

Ok, pour les niveaux OSI je savais ça.
Par contre quel est le réel intérêt d'isoler entre les subnet (performances, sécurité, ...) car tout le réseau iSCSI est dans un VLAN et sur des switch 100% dédiés.
 
Ma problématique :
J'ai reproduit un schéma similaire (mais sans VLAN) sur mon infra et en particulier sur mon serveur de sauvegarde (Windows 2008 R2).
Ce dernier dispose de 1 port réseau connecté sur le LAN et de 2 ports réseau sur le réseau de stockage (sauvegarde hot-add depuis le SAN avec Veeam permettant de faire transiter les blocs à travers le réseau de stockage plutôt que sur le LAN).
Chacun de ces 2 ports dispose de 2 adresses IP afin de pouvoir sauvegarder directement l'EqualLogic et le Synology.
Je ne peux cependant pas tagger ces 2 IP dans des VLAN différents (non supporté par le driver de la carte Broadcom) !
Je ne peux pas non plus ajouter de liaisons iSCSI physiques supplémentaires...
 
L'implémentation sans VLAN m'arrange donc dans le sens ou elle ne m'apporte pas cette problématique.

Tu as pas testé avec les outils broadcom ? C'est avec eux que tu crées tes cartes réseaux virtuelles une dans chaque vlan.
 
Faut tester, ça peut marcher dans ton cas mais selon l'os, les drivers, il peut qu'il y ait embrouille sur l'ip à utiliser. Disons que la solution vlan est la plus propre

C'est moi qui fixe les chemins iSCSI alors pas de problème au niveau des IP. Je vais creuser un peu plus sur les outils broadcom mais il me semble que tu ne peux faire qu'une seule interface virtuelle par interface physique ...

Pour ceux qui sont intéressés, voici les performances obtenues avec l'infra que j'ai monté :
 
https://communities.vmware.com/message/2283573#2283573