Raid virtualisé, virtualisation du raid... ou les deux ?

[jibe]

Salut,

Suite à une question de sibsib, je m'interroge...

Supposons que je veuille monter un serveur virtualisé. Pour en augmenter la fiabilité, je voudrais du raid. Mais où le mettre ?

1 - Je peux le mettre au niveau matériel (voire éventuellement logiciel ?) sur la machine hôte, et mon serveur en VM n'aura qu'un seul disque virtuel et donc pas de raid, sauf que son disque virtuel reposera sur un disque hôte en raid.

2 - Je peux aussi faire l'inverse : pas de raid sur l'hôte, mais deux disques physiques. Mon serveur en VM aura deux disques virtuels, que je m'arrangerai pour être chacun sur un disque physique différend, et je ferai du raid avec ces deux disques.

3 - Enfin, je peux faire du double raid en combinant les disques physiques et les array raid sur l'hôte et dans la VM...

Quelle est la meilleure solution ? Y a-t-il des cas où l'une est meilleure que l'autre, et des cas inverses ?

La solution double raid (en 3) présente-t-elle vraiment des avantages, ou est-ce une usine à gaz inutile ?

Et LVM, dans tout ça ?

Mon serveur m'offre aussi la possibilité d'avoir LVM en plus du raid. Ai-je intérêt à le mettre en place en plus ?

Voilà... Petit débat ouvert !

Pour ma part, je n'aime pas trop les usines à gaz (il faut aussi avouer que les installations que je fais ne nécessitent généralement pas de choses sophistiquées). J'aurais donc tendance à mettre le raid sur l'hôte, et laisser les VM avec un disque géré tout à fait normalement : ni raid, ni LVM (d'ailleurs, je n'ai jamais bien saisi l'utilité de LVM ! )

[jibe]

Question apparue sur le sujet de sibsib cité précédemment : Ne peut-on pas faire du raid logiciel sur la machine hôte ? Peut-être que c'est lié au "virtualiseur" : ESXI dans le cas de sibsib. Pour ma part, j'avais à une époque pas mal étudié qemu, et là je ne vois pas ce qui l'empêcherait ?

[sibsib]

Hello,

Comme tu as double posté ta question, je double poste la réponse (mais que font les modos, ou pire, les admins ??? )

A mon sens, la virtualisation dans un environnement pro ne s'envisage qu'avec du raid matériel, et de préférence en disque hot plug : si on virtualise, en principe c'est pour mettre plus d'un serveur virtuel, et donc l'arrêt du serveur hôte est de plus en plus impactant.

Ensuite, le deuxième choix naturel serait le raid logiciel au niveau de l'hôte. Là, les ESXi qui sont des hôtes de virtualisation de niveau 1 (et je pense plus généralement les hyperviseurs de niveau 1) ne gèrent tout simplement pas le raid logiciel. En effet, ces hyperviseurs cherchent à avoir une empreinte logicielle la plus légère possible, et ont également une liste de drivers (très !) limitée.
Sur un hyperviseur de niveau 2 ou 3, il sera préférable d'utiliser le RAID sur l'hôte.

Enfin, le pire choix (le mien, donc ) est le raid logiciel au niveau de chaque machine virtuelle. Gestion machine par machine, qui ne prend pas forcément en compte les 'vraies' contrainte de l'hébergeur.

Mais je confirme que ce pire choix fonctionne Le prix de gestion est par contre élevé.

Pour le LVM, par contre, il me semble que pour que cette fonctionnalité ait un sens, elle doit être présente au niveau de la machine virtuelle. En effet, quel intérêt d'étendre dynamiquement un FS sur un hôte, si la prise en compte par la VM n'est possible qu'à froid ? L'inverse par contre : ajout d'un nouveau FS sur l'hôte, création de nouveaux 'disques' pour la VM, puis, depuis la VM, utilisation du LVM pour agréger ce nouveau volume à un volume existant, ça me semble avoir un sens, et en tout cas, j'ai déjà fait

A+,
Pascal

[jibe]

Salut,

Comme tu as double posté ta question, je double poste la réponse (mais que font les modos, ou pire, les admins ??? )

C'est un peu vrai

Mais bon, je pensais que tu ne répondrais qu'ici, puisque j'indiquais ce fil Je n'aurais peut-être pas dû poser deux fois la question et me contenter de renvoyer ici

Bon, cela dit, tes explications me satisfont pleinement. C'est un sujet que je connais très mal, et j'étais assez étonné de voir ta réalisation : venant de toi, je ne savais plus si c'était la bonne manière de faire ou pas ! Je comprends tout maintenant.

Merci pour ces précisions

[ccnet]

J'irai (je vais en pratique) nettement plus loin dans ce contexte.
Le stockage est pratiquement independant des esx. Pas (boot san) ou tres peu de disques sur les esx. Dans l'ordre en terme de performances decroissantes : fiber channel, iScsi, nfs. Dans tous les cas le systeme disque est externe et independant dans le sens oú il est accessible au travers de son propre reseau (iscsi) avec son propre commutateur gigabit permettant la mutualisation totale de l'espace de stockage. Idealement la redondance est assuree par deux baies de disques a l'interieur desquels on fait du raid 5+1 en plusieurs sous ensembles de chacun 6 disques (4+1+1), 6, 12, 18, ...Dans certains systemes les disques de spare (le +1) sont mutualisés. La baie elle meme est redondée et c'est le systeme disque qui gere son clustering. Les esx voient les datastore selon le decoupage que l,on souhaite. Dans ce contexte avec un systeme de stockage basé sur Openfiler on fera du lvm. J'ai monté recement openfiler sur des Cenera SN3 de chez Emc. Pas de raid materiel mais logiciel. C'est une autre façon de faire. Openfiler pouvant realiser des snapshoots. Dans cette solution 3 esx vont partager 2 sn3 au travers d'un switch gigabit, en iscsi. Les interfaces Vmotion de vmware sont dediées et hors du reseau de stockage.

[jdh]

Pour compléter ccnet, il est clair que le stockage au sein d'un hôte de virtualisation est à proscrire puisque cela empêche la 'high availability' à partir de 2 hôtes ...

Quand on veut virtualiser, une baie de disques s'impose (ou deux).

Il faut rajouter la connectivité SAS à celle cité par ccnet.
L'usuel, en entreprise, est la très onéreuse fibre (fiber chanel) : il faut 2 (ou 1) hba (host base adapter) par serveur, 2 switchs optiques, les câbles qui vont bien (lc-lc), et des baies doubles contrôleurs fibre, la vitesse de transit va jusqu'à 8 Gbit.
La connectivité SAS est très peu onéreuse mais ne permet pas le switch : par exemple, on peut trouver des baies avec 2x 4 ports SAS permettant 4 hôtes en redondance, la vitesse va jusqu'à 6 Gbit et cela correspond à la vitesse maxi d'un disque (inatteignable).
En connexion iSCSI, on utilise juste des économiques ports ethernet (dont on peut activer les fonctions TOE et jumbo frame sur un réseau physique dédié = switch dédié). Avec l'arrivée prochaine du 10 Gigabit, cela devrait dépasser la fibre et SAS, alors qu'en 1 Gigabit, c'est forcément loin derrière les 2 autres connectivités.
La disponibilité de stockage NFS est loin derrière, en terme de performance.

Dans une baie, il y a lieu de créer des volumes comportant N disques pour les présenter (comme LUN) aux hôtes de virtualisation.
Ces volumes peuvent être en raid 5 ou raid 10 pour le plus usuel. On trouve du raid 6 (moins performant que raid 5), raid 50 (améliore le raid 5 comme raid 10 améliore le raid 1). Le choix de raid impacte directement la performance (et la perte d'espace).
Il est probable que l'avenir est aux baies de disques 2,5", plus lent mais plus économe et surtout en plus grand nombre.
(Je n'ai pas pu tester une baie 24 disques 2,5" en 300G à 10.000t contre une baie 12 disques 3,5" en 600G à 15.000t : il est possible que la première soit plus rapide = débit plus à même de saturer le lien fibre ou SAS malgré des disques plus lents.)

Il est considérer les fonctions complémentaires de la baie : snapshot ou copie, ainsi que la sauvegarde (par exemple sur réseau fiber channel)

Pour une PME, il est à considérer les baies NAS qui proposent (pour certaines) des volumes iSCSI "à pas cher" (mais assez lent = un disque SATA 7.200t ne délivre pas le débit d'un SAS 15.000t).

[jibe]

Salut,

Merci pour ces précisions

Effectivement : la virtualisation prend tout son sens dans le cadre que vous décrivez, et n'est pas vraiment adaptée à des besoins plus modestes, ou doit dans ce cas être employée dans des conditions bien précises, et par quelqu'un sachant bien ce qu'il fait et pourquoi...

[fesch]

Salut

J'aimerais rajouter mon petit grains de sel (bien que tout a été dit ): En résumé je conclue que si on veut implémenter de façon efficace et redondante un environnement de virtualisation, cela reviens très, très cher ... surtout au niveau matériel.

Par contre une virtualisation assez simpliste sans redondance peut aussi déjà apporter des avantages non négligeables (mot clé: PROXMOX). C'est commme toujours et pour tous les cas: la solutions dépend fortement des besoins!

salutations
Fesch

[jdh]

Je plussoie PROXMOX qui est remarquable de légèreté et de puissance.

PROXMOX propose 2 virtualisations : OpenVZ pour la virtualisation de VM de type Linux seulement sur la base de template, et KVM pour la virtualisation complète de VM Windows ou BSD.

L'interface est très légère puisque directement en mode web (pas de client lourd du type vSphere Client ou XenCenter).

De plus, il est facile de réaliser un cluster de hôtes, et de transférer une VM d'un hôte vers un autre.
Mais cela ne fait pas encore de 'high availabity' (prévu pour la 2.0)

Pour le stockage externe, Proxmox supporte iSCSI et NFS.
(Il est conseillé d'utiliser LVM sur une LUN iSCSI).

De base (via l'iso Bare-Metal), le raid soft n'est pas supporté, mais il est possible d'installer une Debian (Lenny actuellement) Amd 64 sur des disques avec du raid soft puis d'ajouter Proxmox (par dessus).


Pour une machine seule, c'est agréable de disposer de raid soft et d'une interface web simple.
Ce qui n'est ni le cas d'ESXi ou XEN ...

NB : mon hôte perso de virtualisation tourne sous proxmox avec 4 disques en raid 5.

[jibe]

Salut

C'est commme toujours et pour tous les cas: la solutions dépend fortement des besoins!

toutafé ! (comme dirait sibsib)

Et s'il arrive que les besoins puissent avoir plusieurs solutions, on ne peut jamais (enfin... On ne devrait jamais ) choisir une solution "à priori" et voir comment l'adapter aux besoins !

La virtualisation est je pense quelque chose de très intéressant... dans certains cas bien précis, dont les deux principaux sont probablement :
- La réalisation d'un système le plus indépendant possible du matériel, largement décrite ici en particulier par ccnet et jdh, solution effectivement très coûteuse en matériel,
- L'économie de matériel, pour faire tourner plusieurs serveurs sur une même bécane. Mais dans ce cas, c'est une solution économique et il ne faut pas trop en demander et bien réfléchir à la mise en oeuvre, en particulier si on veut du raid !

On a beau être en 2012, il est toujours impossible d'avoir en même temps le beurre et l'argent du beurre, et tout choix implique des renoncements !