Nouveau serveur, les détails

Comme promis, quelques détails concernant le nouveau serveur de Hippopota.me : il est donc opérationnel depuis la semaine dernière, la migration s’est très bien faite (hormis deux-trois bêtises de ma part, c’était prévisible :D ) et tout tourne parfaitement.

Comparé à l’ancien (un petit P3 1Ghz avec 256Mo de RAM et un disque de 250Go IDE, sous Ubuntu Server 7.10), j’ai fait les choses en grand ;)

Un nouveau hardware

Laissez-moi donc vous le présenter :

Son hostname est « hippo », pour la base il s’agit d’un PC constitué d’un processeur Core 2 Duo E4400 et de 4 Gio de PC2-6400, montés sur une carte mère Gigabyte GA-EP35-DS3.

C’est tout simplement mon ancien PC desktop, que j’ai reconverti ;)
(et dans un nouveau boîtier)

Concernant la partie « disques » :

  • Un binôme de deux disques de 250 Gio (Samsung Spinpoint P120 & Hitachi P7K500) forme un RAID-1 soft qui a pour mission d’héberger le système et les machines virtuelles (j’y reviendrai ;) ). Le but étant d’assurer une continuité en cas de défaillance d’un disque, et éviter de perdre toute la configuration.
  • Un disque de 320 Gio (Samsung Spinpoint F1) s’occupe pour l’instant du stockage de nos fichiers persos. « Pour l’instant » car il est amené à être remplacé prochainement par du plus gros, normalement un 1 Tio.

Petite parenthèse « software » : j’ai tout partitionné en LVM, je peux donc repartitionner à loisir, ajouter et retirer des disques, faire des snapshots, … dans la joie et l’allégresse.

Niveau réseau, je profite de la puce Realtek 1Gbps intégrée, et j’ai ajouté une Intel PRO/100 PCI qui s’occupe du trafic sortant vers Internet (le port 1Gbps étant réservé au réseau local).
Je vais bientôt ajouter une deuxième Intel PRO/100 (le temps de la retrouver) qui sera dédiée à l’administration du serveur.
Il y a enfin une carte Leadtek DTV 1000 T que j’utiliserai pour faire du streaming TNT en local.

Pas de carte graphique ni d’écran ou de clavier, tout est administré par SSH.

Le tout est alimenté pour l’instant par une Seasonic S12 550W (bientôt remplacée par une Corsair CX400W) et assemblé à l’intérieur d’un Antec Three Hundred.

(l’OCZ Vendetta n’est là que temporairement)

Donc une configuration plutôt puissante pour l’usage, mais bon, le but est aussi de se faire plaisir, et c’est également le cas pour la partie software :D

Du software qui arrache

Le système d’exploitation devient donc Debian, en version 5.0 (Lenny) et x86_64 mais, grosse subtilité, il tourne derrière l’hyperviseur libre Xen, en version 3.2-1 :D

De la virtualisation avec un hyperviseur

Sur ce qu’est un hyperviseur, je ne vais pas réinventer la roue, en me contentant de citer Wikipedia :

En informatique, un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de travailler sur une machine physique en même temps.

L’hyperviseur est un noyau hôte allégé et optimisé pour ne faire tourner que des noyaux d’OS invités adaptés et optimisés pour tourner sur cette architecture spécifique, les OS invités ayant conscience d’être virtualisés.

Concrètement, ça me permet de faire fonctionner plusieurs OS en même temps sur le même serveur, de les affecter par exemple à telle ou telle carte réseau (ou utiliser des vlan), afin d’obtenir le même résultat qu’en ayant plusieurs machines, mais avec les contraintes d’une seule (consommation électrique, encombrement, …).

La différence avec un logiciel comme VirtualBox, c’est qu’il s’agit ici de para-virtualisation (PV) : l’OS invité est modifié pour pouvoir tourner au dessus de l’hyperviseur.
On comprend donc bien que cela n’est possible qu’avec des OS libres : actuellement on peut faire tourner du Linux, NetBSD, OpenSolaris et FreeBSD (expérimentalement pour l’instant).

Xen supporte également la virtualisation complète (HVM), mais :

  • Il est nécessaire de posséder un processeur disposant des instructions de virtualisation hardware (VT chez Intel, AMD-v chez AMD)
  • Les performances sont bien inférieures à du PV

Alors qu’en PV, n’importe quel processeur x86 ou x86_64 est supporté, et les performances sont de l’ordre de 80-90% du natif.

Néanmoins, cela permet de faire fonctionner un Windows comme machine virtuelle de Xen.
(c’est se donner beaucoup de mal pour faire tourner un mauvais OS, vous en conviendrez :D)

Sous Xen, il existe deux types de machines virtuelles, qui sont appelées « domaines » :

  • Le Domaine 0 (Dom0) : Il ne faut pas le confondre avec l’OS hôte, ici l’OS hôte c’est Xen, le Dom0 n’est qu’un système invité, une machine virtuelle, même si il est un peu spécial.
    Il ne peut y en avoir qu’un sur la machine (et il est indispensable), c’est la machine virtuelle principale, celle à laquelle l’hyperviseur accorde tous les privilèges liés au matériel et la seule qui peut gérer les autres machines virtuelles. C’est aussi à l’intérieur du Dom0 que sont transmises toutes les tâches d’I/O liées aux disques et au réseau, entre autres.
    Sa sécurité est capitale, quiconque prend la main sur le Dom0 peut administrer toutes les autres machines virtuelles.
  • Les DomU : ce sont les machines virtuelles qui n’ont aucun privilège matériel accordé par Xen, elles ne peuvent accéder qu’aux ressources qu’on leur accorde dans leur fichier de configuration.

Typiquement, pour des impératifs de sécurité et de performance, il faut faire tourner le moins de choses possible dans le Dom0 (et même rien du tout, si possible) et blinder le plus possible sa sécurité, pour faire tourner les services dans différents DomU, que l’on segmentera selon ses besoins.
Il est théoriquement possible de faire tourner autant de DomU que l’on veut, les seules limites seront matérielles (la mémoire est en général le facteur limitant).

Chaque DomU est un système indépendant (un kernel propre à chacun, et la possibilité de faire tourner des systèmes différents). Pour la sécurité, c’est un gros avantage, car si l’on a bien conçu son réseau et ses domaines, la perte d’un DomU n’entame pas la sécurité des autres.
De la même manière, diversifier ses DomU (OpenSolaris, NetBSD, Linux) permet de ne pas « mettre tous ses oeufs dans le même panier », encore un avantage du point de vue sécurité.

En pratique

Sur mon serveur, il y a donc deux DomU différents pour la partie web : un DomU pour la base de données, et un autre pour Apache/PHP. Ils sont situés sur la partie « exposée » (DMZ) de mon réseau.

J’ai également un autre DomU qui me sert de NAS (NFS & Samba), situé directement sur mon réseau local.

Pour l’instant, tous mes DomU sont des Debian Lenny x86_64.

En lançant diverses commandes depuis le Dom0, on peut gérer ses domaines, ici par exemple pour afficher l’état des domaines qui tournent :

hippo:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   946     1     r-----   6105.4
hippo-mysql                                 13   512     1     -b----     29.8
hippo-nas                                   11  1024     1     -b----     32.4
hippo-web                                   12  1024     1     -b----    193.5

(on peut observer dans l’ordre mon Dom0, puis mes 3 DomU, leur ID à ce moment-là, leur quantité de RAM allouée, le nombre de CPU virtuels affectés à chacun, leur état (ici « blocked » c’est à dire en idle) et l’utilisation totale CPU pour chacun.)

Pour se logger sur un domaine, on le fait soit classiquement par SSH (ou un autre moyen type VNC, …), soit directement depuis le Dom0 avec un « xm console <nomdudomU> ».

Il y a aussi un « top » spécifique, qui affiche en temps réel l’occupation en ressources de chaque domaine, etc … toutes les commandes sont décrites dans le manuel.

Les possibilités sont vraiment immenses, pour peu que l’on prenne le temps de lire la doc et de regarder un peu comment tout fonctionne.

Au final

Bref, ayant mis tout ça en place, j’en suis bien content, ça tourne à merveille et c’est vraiment sympa à faire :)
(en plus c’est un truc de nerd, ce qui ne gâche rien)

A l’avenir ça va évoluer, le nombre de DomU augmentera avec l’ajout de services de streaming, réseau, internet, mail, …

Cet article pourrait faire des pages entières, je pense pour l’instant me contenter de cette présentation succinte, et sûrement faire des articles au fur et à mesure sur des points précis de la configuration, mais n’hésitez pas à me demander des choses plus précises dans les commentaires (en même temps je ne fais que débuter dans le domaine …)

Cet article était surtout une manière de vous présenter ma jolie machine et de vous faire part de ma satisfaction quant à la manière dont je l’ai réalisée :)

Ah, j’allais oublier, la petite tradition pour chaque nouvelle machine, un petit « uname -a » s’impose :

Linux hippo 2.6.26-2-xen-amd64 #1 SMP Wed May 13 18:43:45 UTC 2009 x86_64 GNU/Linux

Longue vie à lui ! ;)


Quelques références sur Xen :

8 réflexions au sujet de « Nouveau serveur, les détails »

  1. Salut,
    je viens de voir ton articule sur Xen, c est clair et bien expliqué. Je voulait juste te dire qu effectivement c est tres puissant, dans le cadre de mon boulot on a un Xen, meme deux, et il te suffit d’avoir un NAS et quelques serveurs de virtualisation, et tu peux quasi tout virtualiser ! Parfait aussi pour faire du cluster fail/over ou meme load/balancing
    bref vive XEN !
    Je parle de serveurs libres… Pour windows c est autre chose ^^

    Et bravo pour ton serveur

  2. Merci m’sieur :D

    Je commence seulement à découvrir tout ça, c’est vraiment épatant niveau possibilités, c’est certes un peu gros pour un serveur@home, mais tant qu’à se faire plaisir … ;)

  3. Salut!
    Je viens de voir ton article sur Xen, c’est bien fait, sa répond à pas mal de questions que je me posais. Par contre, aurais tu des documentations en FR sur le sujet?

    Merci

  4. Mmh en français ça ne se bouscule pas, je dois dire que là je n’ai pas grand chose à te proposer :/

    Mais le tutorial de Howtoforge est quand même très accessible ;)

  5. Ping : Ma nouvelle machine principale — Hippopota.me/blog : le blog de deK

  6. J’ai une petite question, quelle est l’utilité d’utiliser plusieurs cartes réseaux étant donné qu’elles sont sûrement toutes reliées au même switch ?

  7. Justement, elles ne sont pas reliées au même switch ;)

    L’une d’entre elle est reliée à mon LAN, au même titre que mes autres machines, l’autre à ma DMZ.
    C’est sur cette dernière que passent les services vers l’extérieur, comme le serveur web par exemple ;)

  8. A l’usage, comment se comporte le NAS virtualisé ?
    Je suis en train de faire la meme chose chez moi, et j’ai des gros souci de réactivité sur les accès disque du NAS .
    un « iotop » sur la VM du nas me donne des résultat effrayant: lors des accès disque un peu important, j’ai un temps en wait supérieur à 60% et mes débits s’écroulent…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


sept − = 2

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>