Faible performance à la fois iSCSI et AoE

Nous recherchons un stockage de vitesse résonable. En raison du faible budget, nous avons décidé d'utiliser des cibles logicielles iSCSI ou AoE. Avant de changer notre infrastructure de production, nous faisons des tests pour choisir la meilleure technologie.

Pour les tests, nous utilisons:

• Fujitsu Siemens RX200 S4 comme cible
• Fujitsu Siemens RX200 S4 comme initiateur
• Commutateur 1 Go géré par NetGear
• cartes réseau intégrées (Broadcom avec TOE), cartes réseau EdiMax, cartes réseau Broadcom avec TOE - tous 1 Go
• le serveur cible utilise un contrôleur QLogic avec 6 disques SATA WD Blue de 2 To.
• les systèmes d'exploitation cible et initiateur sont Ubuntu 16.04 LTS avec toutes les mises à jour. Le commutateur est dédié à des fins de stockage. Nous testons les liaisons et les chemins multiples.

Notre problème est la faible vitesse de lecture. Pour les tests, nous utilisons ddun fichier de 40 à 100 Go.

• la lecture et l'écriture locales sur un serveur cible dépassent 300 Mo / s.
• l'écriture sur le serveur par iSCSI ou AoE est supérieure à 200 Mo / s, ce qui nous satisfait.
• la lecture à partir du serveur est toujours de 95 à 99 Mo / s.

Nous avons essayé ietd, aoetools, LIO. Nous avons utilisé des liaisons de 2 NIC: balance-rr et LACP, multi-trajets avec rr. Trames normales et jumbo utilisées. Enfin, nous avons même fait une connexion Ethernet directe entre la cible et l'hôte (pas de commutateur).

Tous les tests donnent plus moins les mêmes résultats (bien sûr, l'utilisation de cartes réseau communes sans TOE et iSCSI a donné des résultats 20 à 30% moins bons).

Le test du réseau avec iperf a montré des transferts d'environ 200 Mo / s (2 Go). L'observation de l'utilisation des cartes réseau sur la cible avec bmon a montré une utilisation égale des deux appareils (chacun d'environ 50 Mo / s pour la lecture, environ 100 Mo / s pour l'écriture).

Comme nous n'avons pas eu de chance, nous avons décidé d'utiliser une troisième carte réseau (les deux côtés bien sûr). Les résultats ont été étranges:

• 2 cartes réseau - 50 Mo / s chacune
• 3 cartes réseau - 33 Mo / s chacune

Y a-t-il une limite sur le logiciel cible qui désactive la sortie supérieure à 1 Go / s?

Que faisons-nous de mal?

Pour réduire les performances maximales du stockage connecté iSCSI, vous devez utiliser des trames Jumbo et MPIO (pas LACP). RDMA / iSER est recommandé si vous pouvez le faire.

AOE (ATA sur Ethernet) est vieux et c'est de la merde. Nous nous sommes déjà débarrassés de Coraid il y a des années. Nous utilisons StarWind https://www.starwindsoftware.com/ comme cible iSCSI depuis un certain temps déjà et StarWind nous a demandé de migrer de Coraid vers le stockage que nous pourrions faire.

Donc en ce moment, nous sommes très bons avec iSCSI fourni par StarWind et en utilisant Windows, ESX et SCST http://scst.sourceforge.net/ sous Linux comme initiateurs. Avec RDMA / iSER, il fait jusqu'à 10 Gbit, très heureux jusqu'à présent.

Votre attente sur le fonctionnement de l'agrégation de liens Ethernet est incorrecte.

Toutes les méthodes d'agrégation autres que la balance rr (ex: toutes les méthodes dont le mode> 0) ne pas vous donner une plus grande unique connexion débit; ils augmentent plutôt la bande passante totale disponible lorsque plusieurs connexions sont établies depuis / vers les hôtes affectés. En d'autres termes, LAG / LACP ne vous offrira aucun avantage pour ce scénario à connexion unique.

La seule méthode d'agrégation qui peut vous donner un débit de session unique supérieur à ce que vous pouvez normalement avoir sur une seule interface est balance-rr , qui distribue les paquets de façon circulaire. Vous avez dû définir balance-rr à la fois sur l'initiateur et sur la cible. Cependant, un gros hic est que cela dépend largement des commutateurs.

Quoi qu'il en soit, si vous définissez la cible et l'initiateur sur balance-rr, la connexion directe des deux machines devrait vous donner des performances accrues. Sinon, pouvez-vous poster un iperfavec balance-rr et les deux machines directement connectées (pas de commutateur)? Veuillez également publier la ddcommande exacte que vous avez utilisée pour l'analyse comparative.

Remarque: je ne parle ici que d'iSCSI. Je n'ai aucune expérience avec AoE au-delà de la lecture à ce sujet, et je ne l'implémenterais de toute façon pas dans une nouvelle infrastructure (c'est à peu près disparu).

N'utilisez pas balance-rr pour autre chose que certains protocoles point à point très spécifiques. Il a des performances horribles lorsqu'il est sous presque n'importe quel type de charge du monde réel, et provoque une multitude de problèmes de réseau (comme beaucoup de gigue). Ne l'utilisez certainement pas avec un interrupteur.

Utilisez MPIO sans aucune liaison du côté initiateur pour réaliser l'équilibrage de charge et la tolérance aux pannes. Pour vous assurer que vos chemins ne sont pas mélangés en envoyant tout votre trafic sur un seul chemin, placez des chemins individuels (cartes réseau gigabit entre la cible et l'initiateur, dans votre cas) sur des sous-réseaux séparés.

N'hésitez pas à lier le côté cible avec LACP par chemin (comme dans deux liaisons pour deux chemins pour un total de quatre cartes réseau, comme exemple de configuration de port cible). Cela fonctionne très bien et peut équilibrer plusieurs connexions d'initiateur qui utilisent les mêmes chemins. Utilisez également des trames jumbo et iSER si possible. L'utilisation de LACP sur la cible équilibrera les connexions à chaque chemin entre plusieurs cartes réseau.

L'utilisation de LACP sur l'initiateur ne sera efficace que si elle établit de nombreuses connexions de portail cible avec une utilisation simultanée (ce qui n'est pas courant pour à peu près n'importe quelle charge de travail). Même si vous deviez mettre en œuvre efficacement LACP par chemin sur l'initiateur, cela deviendrait rapidement un cauchemar de câblage pour utiliser (par exemple) quatre tissus supplémentaires dans chaque boîtier. Si vous avez besoin de plus de ~ 2 Gib / s de débit vers un seul initiateur, pensez à Ethernet 10 Gio / s.

La plupart des réponses sur AoE sont totalement incorrectes, contrefactuelles et montrent un manque de connaissances et d'expérience en AoE. Tout d'abord, ce n'est pas disparu. CORAID est le fournisseur derrière AoE et ils ont redémarré en tant que «SouthSuite» tout en conservant la marque CORAID. Ce sont aussi les mêmes développeurs. Ils fabriquent de nouveaux produits et soutiennent la plupart des anciens. Ils font également avancer le développement AoE, comme le montrent clairement leurs listes de diffusion techniques ouvertes. Consultez le site Web, tout est à jour et raconte toute l'histoire sur leur page d'histoire.

Quelqu'un a dit que AoE ne bénéficierait pas des trames jumbo et était également plat. Il a été pris en charge après la sortie de la version 13 du «vbladed». Vous devez régler votre MTU pour prendre en charge la nouvelle taille de trame, mais sinon cela fonctionne très bien.

iSCSI s'exécute dans la couche 5 du modèle OSI. Son transport habituel est TCP. Cela vous donne une correction des erreurs (en raison des sommes de contrôle dans TCP) et vous permet d'acheminer le trafic sur IP à la couche 3. C'est là que s'arrêtent les avantages d'iSCSI. Ses performances dans le monde réel sont carrément horribles lorsque vous les comparez réellement à quelque chose comme FCP, AoE ou FCoE. Je vous invite à google "comparaison de performances iscsi" pour le spectacle d'horreur.

Votre problème de vitesse de lecture pourrait être dû à une mauvaise configuration du réseau, désactivez le contrôle de flux et assurez-vous d'utiliser un tampon de socket suffisamment grand. Vous n'avez pas non plus mentionné si votre système de fichiers sous-jacent avait été réglé pour la lecture anticipée en lecture ou non. En fonction de votre scénario, cela pourrait vous être très utile, mais veillez à ne pas l'utiliser avec certaines bases de données qui demandent que la mise en cache soit désactivée.

L'agrégation 802.3ad n'augmentera pas beaucoup le débit de votre flux unique, même dans un scénario à tour de rôle. Cela compliquera également la configuration de votre réseau et vous donnera quelques nouvelles opportunités de vous tirer dans le pied en faisant disparaître les intervalles PDU ou en configurant mal votre lien Cisco VPC pour prendre en charge l'état actif-actif. N'utilisez pas LACP avec AoE, laissez-le gérer ses propres multipathing et multiplexage. Les versions ultérieures d'AoE gèrent cela magnifiquement, et dans la plupart des cas, plus gracieusement que même FCP car elles sont toutes automatiques. Des ports Ethernet supplémentaires vous offrent plus de bande passante et plus de résilience. Si vous répartissez les ports Ethernet hôte et initiateur sur plusieurs commutateurs, cela peut fournir encore plus de redondance. Il n'est pas nécessaire de configurer un mode de liaison. N'exécutez pas non plus IP sur les mêmes interfaces que vous utilisez pour AoE.

En bref, n'écoutez pas les opposants AoE, ils semblent n'avoir pas beaucoup d'expérience et surfent simplement sur les ondes cérébrales à la mode. Évitez le troupeau. Allez configurer un magasin de sauvegarde avec une prélecture réglée à la main et vous verrez probablement votre débit de lecture augmenter. Abandonnez l'utilisation des protocoles d'agrégation et exécutez des cris à partir d'iSCSI. Une dernière chose, arrêtez d'utiliser 'dd' ce n'est pas un excellent test et est soumis à de mauvais effets de mise en cache. Utilisez un véritable outil de référence comme «fio», «iozone» ou «dbench». Cela donne des résultats beaucoup plus fiables.

Je sais que LACP est pour plusieurs connexions. Le tester était un acte de désespoir :)

Tous les tests ont été effectués avec balance-rr et deux NIC.

Écriture sur la cible iSCSI:
dd si = / dev / zero of = / mnt / zero.bin bs = 1M count = 2000
2000 + 0 przeczytanych recordów
2000 + 0 zapisanych recordów
2097152000 bytes (2,1 GB, 2,0 GiB) copied , 10,1093 s, 207 Mo / s

Lecture à partir de la cible iSCSI:
dd si = / mnt / zero.bin de = / dev / null bs = 1M
2000 + 0 enregistrement przeczytanych -
2000 + 0 enregistrement zapisanych -
2097152000 octets (2,1 Go , 2,0 Gio) copié, 16,1684 s, 130 Mo / s

Vitesse réseau:
iperf -c 172.16.10.80
------------------------ ------------------------------------
Client se connectant à 172.16.10.80, port
TCP 5001 Taille de la fenêtre TCP: 325 Koctets (par défaut)
--------------------------------------------- ---------------
[3] port local 172.16.10.70 37024 connecté au port 172.16.10.80 5001
[ID] Bande passante de transfert d'intervalle
[3] 0,0-10,0 s 2,30 Go 1,98 Gbits / s Les

tests avec iperf et trames jumbo ont donné les mêmes résultats.

J'ai gagné en vitesse de lecture en exécutant l'initiateur:
hdparm -a 2048 / dev / dm-1
Auparavant, il était de 256 et la vitesse de lecture était de 96 Mo / s
Mon objectif est d'atteindre une vitesse de lecture d'environ 200 Mo / s.

EDIT:
1. Nous n'utilisons pas LACP - c'était un test unique.
2. Les tests avec balance-rr et MPIO donnent exactement les mêmes résultats. Le multichemin a été testé avec des cartes réseau dans différents sous-réseaux.
3. L'ajout de NIC supplémentaires n'augmente pas la vitesse de lecture, mais réduit uniquement l'utilisation de chaque NIC.
4. Nous pensons que le problème est une limitation (pilote, module?) Qui ne permet pas de lire plus rapidement. Mais je ne sais pas si c'est du côté cible ou initiateur.


EDIT 2: vient de faire un test supplémentaire: configuré le même hôte en tant que cible et initiateur pour se débarrasser des problèmes de matériel réseau. J'ai été choqué: exactement la même vitesse de lecture! 130 Mo / s! L'écriture est de 227 Mo / s.

Comment avez-vous configuré votre NIC? Tous les tampons sont-ils correctement configurés? Avez-vous alloué suffisamment de RAM aux tampons réseau? n'utilisez pas non plus de liaison ici, vous pouvez utiliser 2 canaux iscsi et les multi-trajets sur l'initiateur, de même avec ATAoE les multi-trajets de l'initiateur via l'étagère et l'identifiant lun sur n'importe quel chemin.