History of Linux-VServer-Paper-08-French

Le but premier de ce projet est de permettre la création de serveurs virtuels > partageant les ressources d'une même machine physique. Un Serveur Virtuel fonctionne > comme un serveur Linux normal, et peut lancer des services traditionnels comme telnet, > service de mail, service web, service SQL.

== 08.0. Séparation Administrative ==

Un provider intelligent peut donc vendre un serveur virtuel, > qui, en utilisant moins de ressources que d'autres techniques > de virtualisation, permet de lancer plus d'instances sur une > même machine.

La liste des providers qui fournissent un tel service est assez > longue, et on peut donc considérer que c'est l'application principale > de vserver.

== 08.1. Séparation des Services ==

Pour séparer plusieurs services identiques ou de nature différente, > qui auraient autrement des interférences entre eux, est une chose > facile à mettre en oeuvre avec Vserver. Plusieurs raisons peuvent > vous pousser à faire cela; un service mal écrit, ou simplement deux > services qui ne savent pas co-exister pour de multiples raisons.

Même sur une machine à l'ancienne mode, placer un service très exposé > ou non sécurisé car inconnu ou propriétaire dans une prison chroot > peut améliorer grandement la sécurité et la maintenabilité.

== 08.2. Améliorer la Sécurité ==

Bien que l'idée de lancer plusieurs serveurs sur une seule machine > soit en elle même très interessante, d'autres concepts sont encore > plus interessants. Imaginez un serveur physique sur lequel tourne un > seul vserver. Le but est d'isoler l'environnement principal de n'importe > quel service, n'importe quel réseau. Vous démarrerez dans l'environnement > principal, lancez très très peu de services, puis continuez dans le serveur > virtuel.

Le service de l'environnement principal sera:

* > Injoignable depuis le reseau.

* > En mesure de logger tous les messages du virtual serveur, d'une manière > sécurisée. Rien dans le serveur virtuel ne permet d'effacer les logs, ou > de les modifier. Même un serveur virtuel cracké ne permet pas de changer > les logs.

* > En mesure de faire tourner un système de détection d'intrusion, qui > espionnera l'état du serveur virtuel sans être accessible ou même détecté. > Par exemple, vous pouvez installer et faire tourner tripwire depuis l'environnement > principal, et impossible de modifier son fonctionnement ou de le tromper.

Une autre option consiste à mettre le firewall dans un serveur virtuel, puis > étirer la DMZ sur un ensemble de VPS séparés. Moyennant une configuration bien > faite, ce genre d'installation peut réduire substantiellement le nombre de machines > requises, sans pour autant impacter les performances.

== 08.3. Maintenance Facile ==

Une fonctionnalité clef d'un serveur virtuel est son indépendance vis à vis du > matériel. La plupart des problèmes matériels sont inconnus au fonctionnement > d'un serveur virtuel.

Le serveur principal agit comme un système hôte, et s'occupe de tous les détails. > Le serveur virtuel est simplement un client, et ignore tous les détails. De cette > manière, le client peut être déplacé vers un autre serveur physique avec très peu > de manipulations.

Par exemple, pour déplacer un serveur virtuel depuis un ordinateur physique vers > un autre, il suffit de procéder aux étapes suivantes:

* stopper le serveur virtuel

* le copier sur l'autre machine

* copier sa configuration

* lancer le serveur virtuel sur la nouvelle machine

Pas de mise à jour des utilisateurs, pas de configuration matérielle, > tant que les machines sont compatibles au niveau de leurs binaires.

== 08.4. Scénarios Fail-over ==

En repoussant les limites un peu plus loin, on peut utiliser des technologies > de réplication pour conserver une copie identique à la minute près du système > de fichier d'un serveur virtuel en fonctionnement. Cela peut servir à un basculement > très rapide si le serveur en fonction tombe pour n'importe quelle raison.

Toutes les methodes connues sont utilisables dans ce but, en commancant par la > réplication réseau comme rsync, ou drdb, en passant par NBD (les Network Devices), > les disques partagés, ou un système de fichier distribué. Toutes ces méthodes > sont utilisables pour réduire le temps d'indisponibilité d'un système et améliorer > l'efficacité globale.

== 08.5. Pour Tester ==

Vous avez besoin de construire un logiciel pour plusieurs versions d'une distribution > particulière. (Mandrake 8.2, 9.0, 9.1, 9.2, 10.0), ou bien même pour plusieurs > distributions différentes.

Ce problème est résolu d'une manière très simple par Vserver. Avec pas mal d'espace > disque, ces différentes distributions peuvent être installées et lancées en parallèle, > simplifiant la tache de passer de l'une à l'autre.

Biensur, vous pouvez faire cela simplement avec chroot() et rien d'autre, mais > Vserver offre une simulation bien plus réaliste.

[Index] [Précédent] [Suivant]