Bonjour et bonne année,
 
Nous avons installé la maquette suivante :
 

• Serveur hôte Linux-KVM sous Scientific Linux 6.1 (clone de RedHat), Dell R710

+machine virtuelle sous Debian Squeeze, avec initiateur open-iscsi, pilotes virtio
 

• Serveur de stockage sous Scientific Linux 6.1, Dell R510 + baie DAS

avec cible iscsi (tgtd)
 
On monte un volume iSCSI de 100 Go sur la machine virtuelle.
 
Mesure basique du débit en écriture séquentielle :
en faisant un simple dd if=/dev/zero of=/iscsi/test10G.zer bs=1M count=10000 (création d'un fichier de 10 Go contenant des zeros) on obtient un timide 23 Mo/s
 
Pourtant

• utilisation CPU : moins de 5% aussi bien du côté de l'initiateur que de la cible
• Taux d'utilisation des ports concernés au niveau du switch : environ 12%
• en essayant directement depuis le serveur hôte KVM : pas mieux (25 Mo/s sur un fichier de 30 Go)
• en local sur le serveur de stockage :713 Mo/s  sur un fichier de 100 Go

Comment améliorer ces performances en iSCSI ? Dans quelle direction chercher ?
 
Pour info on refait un essai demain, avec de l'agrégation de liens LACP 802.3ad de bout en bout et un switch Cisco permettant de mesurer le CPU (du switch).
 
Merci et bonne soirée

la CPU du switch ne montera pas puisque c'est commuté en hardware.
 
Active les jumbo frame et le flowcontrol.

combien tu as de disques dans ton DAS ?  
 
tu pourrais pas mettre un cable croisé entre tes 2 machines ? (si tu dedie un lien au ISCSI)

un VLAN dédié au iSCSI ca peut améliorer un peu les choses

Hello,
 
En ce qui concerne les faibles performances en écriture sur ta cible iscsi Je commencerai par regarder si le writeback cache est activé.
Le mode par défaut est généralement write thru, c'est à dire que chaque écriture doit être finalisée sur les disques avant de passer à la suite.  
 
Attention avant d'activer le writeback il faut s'assurer que les risques inhérents à ce type de fonctionnement sont bien pris en compte.

Honnêtement se lancer dans l'etherchannel te servira a rien si avec un seul lien tu restes bloqué à 23Mo/s. Avec 1 seul lien Gigabit tu devrais être capable de voir de bien meilleurs performances.
Pour l'augmentation de performances en ISCSI , on préférera utiliser le multipath.
Par contre éviter d'activer les jumbo frame et le flow control en même temps dans un premier temps , il faut que tes commutateurs possèdent un buffer/port assez important et j'en ai vu pas mal qui
ne peuvent pas suivre la cadence. Le flow control dans un premier temps suffira . Activer les 2 sur un commutateur qui n'est pas capable de supporter les 2 à la fois te donneras des mauvaises performances.
 
Je connais pas trop cette distrib et KVM ,niveau support des drivers c peut être pas opti et certains paramètres sont peut être à modifier au niveau de la carte réseau.  
 

Merci pour vos réponses.
 
Le DAS est un RAID6 sur 10 disques + 2 HotSpare
 
Concernant la distrib : ScientificLinux c'est comme CentOS, cela se veut strictement compatible RHEL au niveau binaire (recompilation des mêmes sources). En pratique je n'ai jamais eu à m'en plaindre.
 
La raison d'être de l'EtherChannel (agrégation de liens LACP 802.3ad) est avant tout d'apporter de la redondance : physiquement les deux liens arrivent sur deux switches différents en stack. Cablé comme c'est, la chute de l'alimentation d'un switch ne fait pas tomber les liens iSCSI.
 
En en venant aux switches justement : j'ai remplacé le Dell Powerconnect 5224 (firmware 3.1.0.16 du 07/07/2005 - hélas il n'y a pas plus récent) par un stack de deux Cisco Catalyst 3750G (IPBASE 12.2.55-SE4(ED) du 13/09/2011) : et ça va beaucoup mieux !
 
Pas d'autre modification hormis le LACP de bout en bout.
 
Depuis une VM, j'atteins un respectable 111 Mo/s en copiant un fichier de 5.4 Go.
Le test précédent (dd if=/dev/zero of=/iscsi/test5G.zer bs=1M count=5120) atteint 117 Mo/s.
Sur du Gigabit, je ne vais pas chercher à faire plus rapide.
 
Concernant les Jumbo Frames : j'ai trouvé ce papier tout à fait intéressant http://www.boche.net/blog/index.ph [...] d-vmotion/ au sujet de l'avantage apporté par les jumbo frames pour du stockage IP (NFS et iSCSI) et du vMotion.
Selon ce papier donc, le gain en conditions réelles n'est pas flagrant pour le iSCSI.
 
De plus : apparemment pour faire les choses dans les règles de l'art, les jumbo frames devraient être activées sur tout le sous-réseau, ce qui ne m'arrange pas vraiment.
 
Concernant le flowcontrol : sur les Catalyst 3750G, on peut l'activer seulement "en réception" (flowcontrol receive on) mais pas en envoi. J'imagine qu'il faut aussi l'activer du côté serveur, mais ça je sais pas faire - et je trouve pas de doc accessible pour RedHat.
 
Donc pour l'instant, on reste en l'état, mais sur le principe l'activation du flowcontrol m'intéresse.
 
Bonne journée

Comme dit précédemment, en iSCSI tu as le multipath inclus. C'est bien mieux parce la redondance est gérée au niveau appli.

Pour activer le flow control sur le serveur , si tu l'active sur le switch et sur la baie , utilise ethtool .

L'activation du flowcontrol a été simple à réaliser :

• flowcontrol receive on sur les ports adéquats du switch
• et rien du tout sur les interfaces de SL (RedHat) : un ethtool -a em... permet de constater que par défaut, le flowcontrol est en "Autonegociate", et qu'il s'est bien auto-activé (RX on et TX on)

En revanche, les performances sur le petit test "dd" ne sont pas meilleures (toujours 117 Mo/s, ce qui est satisfaisant). Peut-être ce sera mieux dans des conditions plus "random" que séquentielles, et avec plus de VMs en simultané.
 
Pas eu le temps de me documenter sérieusement sur le mutlipath.

 
On les a eu d'occasion pour moins de 1000 euros pièce. Voir ce topic : http://forum.hardware.fr/hfr/syste [...] 0649_1.htm