7 à 4 (!)

Alors que je suis en train de mettre en place mon nouveau serveur de virtualisation, j'ai décidé de déplacer les images ISO qui me servent principalement pour les machines virtuelles de mon serveur de fichiers vers l'espace de stockage du serveur de virtualisation.

Tout se passe bien sauf pour 4 fichiers, et je ne comprends pas pourquoi. La copie démarre, mais à la fin, le Finder m'insulte en m'indiquant que je ne dispose pas des droits nécessaires pour terminer l'opération, et cela provoque la suppression des fichiers transférés alors même qu'ils étaient totalement transférés.

poursuivre la lecture…

Bon, je sais, mon Lab a déjà beaucoup évolué, mais ça va continuer.

Un petit rappel de l’état des lieux :

• Un serveur de fichiers sous OpenFiler, qui sert aussi de serveur de virtualisation avec VMware Server 2.0.2
• Un MacMini sous Mac OS X Serveur, qui sert de serveur Subversion, de serveur de stockage pour certains de mes projets, …, de plate-forme de formation à Mac OS X Serveur (je ne maîtrise pas encore cette bêbête…).
• Un routeur sous pfSense
• Une Freebox

A part la Freebox, tout le reste est cousu-main.

poursuivre la lecture…

Si vous suivez mon blog depuis assez longtemps (ou si vous avez été assez curieux pour consulter les articles plus anciens), vous savez que j’ai récemment consolidé 2 serveurs en 1 seul, dans le but d’économiser sur la consommation électrique (avec succès).

Il y a cependant un effet de bord constaté au fil du temps : les performances en écriture du nouveau serveur ont chuté par rapport à celles de l’ancien serveur de fichiers. Rien de chiffré, mais un ressenti net. Après avoir pensé à un problème réseau sur le serveur, levé par l’utilisation de iperf (qui permet de mesurer le débit brut possible entre 2 machines sur le réseau), j’en ai conclu que c’est le sous-système disque qui a un souci.

J’ai pris une demi-journée ce Week-End pour formaliser cette impression, avec l’aide de 2 excellents outils, iozone pour les mesures et OpenOffice pour les graphes, et cela aboutit aux 2 séries de résultats ci-dessous.

poursuivre la lecture…

Au hasard de mes recherches pour résoudre mes problèmes de stabilité de réseau pour les machines virtuelles, je suis tombé sur cet article (en anglais).

Pour faire simple, le principe est de modifier le lancement du noyau Linux des machines virtuelles pour utiliser le « I/O Scheduler » appelé « noop » (pour no operation). Quel est l’intérêt ?

D’abord, j’explique rapidement ce qu’est un I/O Scheduler. Il s’agit d’un mécanisme qui va tenter d’optimiser au maximum les accès disques, afin de limiter autant que possible les situations où des écritures vont empêcher des lectures, ou les situations où un processus de haut niveau serait en train d’accaparer le disque.

Il existe plusieurs ordonnanceurs (schedulers en anglais donc), avec chacun leurs particularités propres. En standard sont disponibles les ordonnanceurs appelés CFQ (le défaut actuel), Deadline, Anticipatory et Noop. Je ne détaillerai pas les 3 premiers, la particularité de l’ordonnanceur « noop » est de ne quasiment rien faire.

poursuivre la lecture…

J’utilise sur mon serveur 4 interfaces réseau « agrégées » ensemble pour fournir un semblant d’interface à 4 Gbits/s. Ca n’a évidemment de sens que dans un contexte où plusieurs clients accèdent simultanément à ce serveur bien entendu.

Jusqu’à il y a une heure, tout fonctionnait bien. Plus maintenant. Enfin si, depuis 5 mn. J’explique.

J’ai voulu jouer avec les « Jumbo Frames ». C’est une fonctionnalité (plus ou moins bien) supportée par les matériels réseau. Mon switch le supporte, les cartes réseau de mon serveur le supportent (en théorie, comme je l’explique ci-dessous…), le MacBookPro le supporte, …

Le but des « Jumbo Frames » est d’améliorer la bande passante en validant les « Jumbo Frames » de 9000 octets. Cela veut dire qu’on demande à faire circuler sur le réseau des paquets de (plus ou moins…) 9000 octets, plutôt que des paquets de 1500 octets (le réglage par défaut en général). L’avantage de n’émettre qu’un paquet plutôt que 6, c’est d’éviter de « consommer » 6x les entêtes IP (ou TCP, je ne sais plus; peu importe) et d’éviter d’imposer 6x plus de traitements aux systèmes d’exploitation.

Donc en théorie (et en pratique, j’ai testé par le passé), sur des transferts de données conséquents (plus de 9 Ko donc), on gagne en bande passante.

Sauf que.

Sur mes 4 interfaces, 3 sont des Intel Gigabit/s, la 4ème (intégrée sur la carte mère) est une Realtek. Et c’est elle qui pique. En fait, bien que l’activation du mode Jumbo Frame ne lui pose pas de problème, elle s’en fout complètement. Et du coup, 3 interfaces en 9000 et une en 1500, sur une agrégation, ça gazouille plus… Problème de driver sous Linux ou mauvaise implémentation chez Realtek, peu importe. J’affectionnais pas tellement Realtek, maintenant je suis conforté dans mon (res)sentiment…

Pour contourner le problème, j’ai rétrogradé l’interface Realtek comme interface d’accès au serveur, pour l’administration Openfiler par exemple, et j’ai agrégé les 3 interfaces Intel, qui elles acceptent sans broncher les Jumbo Frames. J’ai récupéré ainsi ma bande passante améliorée ( 3Gbits/s, c’est pas si mal) vers/depuis mon serveur tout en améliorant légèrement la bande passante grâce aux Jumbo Frames.