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…

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.

La première phase de l’évolution du Lab, la consolidation de 2 serveurs en un seul, est terminée. Le serveur est en ligne, configuré, fonctionnel, tous les services proposés par les 2 serveurs initiaux sont restaurés (et même plus, comme le lecteur de bande).

Au niveau consommation, avant de brancher le nouveau serveur, j’en étais à 141 W instantané. Après connexion du serveur, je suis grimpé à 286 W après le boot (login affiché sur la console), et à 320 W en pleine charge (tous les cœurs du processeur à 100 %, tous les disques et le lecteur de bande au boulot).

Je rappelle qu’avant l’opération, je dépassais les 450 W, sans particulièrement mettre les serveurs au travail (et j’avais pas branché le lecteur de bande). J’économise donc déjà un peu plus de 160 W en fonctionnement normal. Sur 24h, c’est pas rien (ça me fait grosso-modo 135 € d’économie par an, au tarif EDF actuel, pour un fonctionnement 24/7).

Je peux facilement (enfin, facilement, ça va coûter un peu…) diminuer d’au moins 40 W instantané, en changeant mon routeur pfSense pour une plate-forme ATOM. Ce sera l’étape suivante. Je pense pouvoir aussi réduire encore la consommation de mon serveur, en changeant le processeur (actuellement un Q6600 avec un TDP de 95 W) pour un Q9400s (ou un Q9550s, mais en tout cas « s » pour avoir un TDP de 65 W), mais l’investissement est plus lourd (plus de 200 €) pour une économie pas forcément si importante que ça en réalité (un TDP ne présage pas d’une consommation maximale, mais d’un dégagement de chaleur maximal, d’après ce que j’ai compris).