On Wed, 25 Apr 2012 14:35:55 +0200, Jean-Charles de Longueville
<[email protected]> wrote:
> Salut,

Salut,
 
> Je suis en train de réfléchir à une bonne solution 100% libre à mettre 
> en oeuvre pour déployer une architecture permettant de lancer des VM 
> connectées à des cibles iscsi. Là ou je n'ai pas encore choisi de 
> solution et propose le débat est de savoir quelle serait une bonne 
> solution pour assurer la redondance des informations (des disques).

La distribution linux Proxmox VE V.2.0 est ton amie .....   ;-)

> Mon idée est de déployer des serveurs physiques, d'y installer un socle 
> minimal exportant TOUS ses disques (selon une méthode à discuter 
> ci-dessous) et d'y permettre le démarrage de VM connectées à des disques

> exportés mais pas nécessairement depuis la même machine physique. Ainsi 
> si une VM tombe on peut la relancer sur n'importe quel autre socle 
> disposant des ressources (processeur, mémoire et réseau) nécessaires en 
> la connectant aux cibles iSCSI par définition encore disponibles au 
> moins sur une autre machine.

C'est pas mal. Il faudra veiller à ce que les autres serveurs disposent du
même paramétrage des VM
pour pouvoir les redémarrer à l'identique.

> J'ai beau lire pas mal sur le sujet, je n'ai pas encore d'avis arrêté 
> (et en outre, je serais prêt à le revoir si de bons arguments sortent 
> d'un débat).
> 
> Pensez vous qu'il est préférable de faire de la réplication au niveau 
> bloc (je pense à DRDB sous linux ou HAST+CARP sous freebsd) puis 
> d'exporter le résultat par iSCSI?

Je suis en train de monter une solution de virtualisation basée sur la
distribution Proxmox VE V.2.0
appuyée par un SAN exportant ces disques via iSCSI ou AoE (Ata Over
Ethernet).

La question fondamentale à se poser est la suivante :
    * réplication synchrone,
    * réplication asynchrone.
De la réponse découle le choix de technologie à employer.

Si tu as besoin d'une réplication synchrone :
    --> soit tu optes pour un DRDB en mode synchrone.
    --> soit, si tu as un SAN derrière, tu laisses faire le matos (mais
j'ai pas trop confiance.... qu'en est-il de la consistance des VM en cas de
crash),
Attention toutefois aux temps de latence car il faudra que tu attendes
l'écriture sur les 2 disques, pour chaque écriture de bloc, pour que DRDB
te rende la main.
Nécessairement il faudra que tu aies un super bon lien entre les 2 espaces
de stockage.

Si tu n'as pas besoin de réplication synchrone, tu as le choix entre :
    --> un freeze de VM : une bonne copie consistante de ta VM puis un
de-freeze de VM (simple mais très efficace)
    --> un freeze de ta VM, une snapshot de ton système de fichier (LVM ou
autre), un de-freeze de VM
L'enjeu est de faire les VM les plus minimalistes possibles afin que la
copie se fasse le plus rapidement possible.
En ce qui me concerne, je m'oriente vers des VM composées de plusieurs
disques virtuels.
Sur le premier disque : l'OS le plus petit possible (distribution
archlinux).
Sur les autres disques, la data pure (log, fichiers, etc ....)
Pour réduire au maximum l'OS, tu peux utiliser une VM destinées aux
syslogs par exemple.
Je n'utilise pas ça pour les databases, c'est trop sensibles.....


Il n'y as pas de solutions miracle à mon avis.
Il y a des avantages et des inconvénients dans chaque solution.

> Ou vaut-il mieux faire du RAID1 entre 2 cibles iSCSI? Cette seconde 
> piste à le défaut de ne pas être transparente pour la VM si celle-ci 
> doit gérer ce RAID1 ce qui complique grandement le déploiement des VM. 
> Passer par une couche intermédiaire faisant ce RAID1 pour réexporter le 
> résultat en nouvelle cible iSCSI vers la VM est sans doute un surcoût 
> non négligeable (en termes de performances) et surtout introduit un 
> "single-point-of-failure".

Je ne tenterai pas sur un système de prod une telle solution, elle me
semble compliquée, coûteuse
en ressources et comme tu l'as dit, elle ajoute un single point of
failure.

> Suggèreriez vous encore une autre piste?
> 
> Cordialement,
> Jean-Charles
> 
> %%% Merci de respecter ces consignes
> http://www.linux-azur.org/savoir-vivre %%%
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This message has been scanned with Sophos Pure Message

-- 
-------------------------

Sébastien Cottalorda
Chef de Section Informatique

Monaco Parkings
24 rue du Gabian
B.P. 623
98013 Monaco Cedex
Tel. +377 98982077
Fax. +377 92057496
%%% Merci de respecter ces consignes http://www.linux-azur.org/savoir-vivre %%%








<<attachment: vcard.vcf>>

Répondre à