7 à 4 (!)

Un blog sur tout et sur rien

Affichage des articles publiés dans décembre, 2009

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’ai découvert à mes dépends que VMware Server 2 n’apprécie pas tellement le « port trunking/nic bonding/agrégation de ports réseau/quelque-soit-le-nom-qu’on-lui-donne », en mode « bridge » (c’est-à-dire quand on demande à utiliser une interface réseau directement, pas en NAT).

J’ai constaté que si on fait ça, l’accès distant à une machine virtuelle est très instable : on y parvient quelques secondes, puis on n’y parvient plus, puis on y parvient de nouveau, puis on y parvient plus, … En particulier, lorsque je fais un ping vers une machine virtuelle, j’obtiens des duplications de séquences (!). Alors pour un serveur dédié Counter Strike, c’est pas glop.

Alors que par ailleurs, les accès concurrents sur le serveur de fichiers (de plusieurs machines clientes, depuis une seule n’aurait pas sens…) fonctionnent très bien, toutes les interfaces sont (quasi-)pleinement utilisées.

Je ne suis pas sûr de bien comprendre pourquoi ça se comporte comme çà (j’ai mon idée sur le pourquoi, mais ne disposant pas du savoir absolu concernant le réseau, je vais éviter de me ridiculiser :-) ). C’est juste un peu frustrant. J’ai pensé au début à un souci avec le mode d’agrégation utilisé (la norme 802.3ad supportée par mon switch), mais j’ai essayé tous les modes proposés (aussi bien ceux qui nécessitent un switch compatible que les autres), et le comportement est le même.

J’ai donc enlevé une interface de l’aggrégation, reconfiguré VMware Server 2 pour ajouter cette interface en mode Bridge, puis reconfiguré les machines virtuelles pour utiliser ce nouveau Bridge. Depuis, plus de souci, les accès réseau sont stables. Cette unique interface réseau pour 6 machines virtuelles semble suffisante pour l’instant.

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).

Maintenant que les données stockées sur les 3 disques de 1 To externes ont été recopiées sur le serveur, il faut capitaliser sur cet espace disponible en ajoutant ces disques dans le serveur.

En théorie, rien de plus simple :

  1. On arrête le serveur
  2. On installe les disques
  3. On redémarre le serveur
  4. On définit une partition de la taille max sur chaque disque, au format « Linux Raid Auto-detect »
  5. On ajoute les disques au volume RAID6 existant

poursuivre la lecture…

Powered by WordPress Web Design by SRS Solutions © 2010 7 à 4 (!) Design by SRS Solutions