J'utiliserai cette cible iSCSI pour un couple de machines virtuelles KVM basées sur Debian. Chacun des contrôleurs redondants de la cible dispose de 4 ports Ethernet, de même pour les initiateurs. J'utilise deux commutateurs (ZyXEL GS-2200-24) avec un trunk entre eux, et des VLAN isolent chaque chemin. J'ai également activé les trames jumbo et le contrôle de flux.
Le système MPIO de cette version de Debian est fabuleux : tant que dm-multipath est chargé avant de se connecter à la cible iSCSI, tout fonctionne simplement. TM sans aucun fichier de configuration, à condition que je charge scsi_dh_rdac au préalable.
C'est le premier hic : je peux modifier certaines des valeurs par défaut si je fournis un fichier /etc/multipath.conf fichier. J'ai testé avec use_friendly_names yes qui crée avec succès un mpath0 lien dans /dev/mapper/ - au lieu d'utiliser le WWID, qui n'a rien de sympathique. Mais si j'essaie de changer rr_min_io de la valeur par défaut de 1000 à 8, je suis ignoré ; alors je fais cette jolie danse :
dmsetup suspend mpath0
dmsetup table mpath0 | sed 's, 1000, 8,g' | dmsetup reload mpath0
dmsetup resume mpath0Cela change le nombre de requêtes envoyées sur l'un des liens quadruples avant que le round-robin n'intervienne et les envoie sur le lien suivant, de 1000 par défaut à 8. Cela modifie en fait la table multipath (selon la règle multipath -v3 | grep params ). Comment configurer cette valeur par défaut dans le nouveau code multipath ? Je suppose que cela fonctionnait avant que multipath ne devienne dynamique et auto-configurable... En tout cas, toutes les documentations des fournisseurs que j'ai lues, et d'autres discussions sur le web supposent que cela fonctionnait.
Une simple écriture séquentielle utilisant dd bs=100M count=50 if=/dev/zero of=/dev/mapper/mpath0-part1 & sync passe de ~135MB/s à ~260MB/s avec ce changement. Et c'est là le deuxième problème : cela représente environ 2 Gbps au lieu des 4 Gbps dont je dispose réellement entre l'initiateur et la cible. Exécution de iostat -kd 1 pendant 1 seconde, les mises à jour montrent que seulement 2 des 4 chemins sont remplis.
Ce LUN est court : ses 16 Go se trouvent au début d'une matrice RAID10 à 12 broches composée de 600 disques SAS 6Gbps tournant à 15 000 tr/min. Je m'attendais à ce que cela soit suffisant pour saturer les 4 Gbps dont je dispose ; ai-je raison ?
0 votes
Avez-vous essayé de lancer plusieurs
ddcommandes en parallèle ? Vous pourriez obtenir des résultats différents et mieux simuler les charges réelles de la VM. Et si vous voulez être encore plus proche, vous pouvez utiliser les benchmarks de SpecVIRT.0 votes
Bonne idée ; j'en ai fait tourner deux en parallèle et j'ai obtenu une forte augmentation des performances pour l'un d'entre eux, alors que le second avait approximativement le même temps de fonctionnement. Je suppose que l'un d'eux bénéficiait du cache en écriture.
0 votes
Le plus drôle, c'est que
iostat -kd 1ne montre toujours que 2 des 4 tuyaux qui sont proches de 100MB/s. J'ajoute qu'à ce stade, je veux saturer les liens : tant que je ne me rapproche pas de la barre des 500MB/s, il n'y a pas grand intérêt à bidouiller le reste. Pour autant que je puisse voir, la meilleure façon de remplir tous les liens est de réduire le round-robin à un très petit nombre comme 1, 3 ou 5. Et je n'ai toujours pas trouvé le moyen de faire persister ces changements de configuration de manière à ce qu'un rechargement de la configuration viamultipath -rne revient pas àround-robinavec unrr_min_iode 1000 !0 votes
Je ne pense pas que 1000 soit si mauvais, c'est un nombre d'entrées/sorties, pas des octets après tout. De plus, pour faire du benchmarking de disque, bonnie++ est la bonne solution, si vous voulez éviter d'utiliser une suite de benchmark complète.
0 votes
BTW, un autre endroit que vous pouvez essayer de modifier estcsi.conf
0 votes
Le problème est que deux concurrents
ddn'utilisez toujours pas plus que les deux câbles en même temps. Et c'est plus comme si un câble passait le relais au suivant, comme si on passait le relais.