Hello,
 
Nous avons fait l'acquisition de 2 Dell r720xd avec 15To (raid5 5*3To donc 12To effectif) par machines afin de mettre en place une architecture simple HA.
 
Nous avions dans l'idée d'installer Proxmox avec DRBD + heartbeat ou corosync .
Le mirroring réseau se fera à l'aide d'un lien cuivre doublé 2*10gb.
 
Les serveurs virtualisés seront de type Linux/Windows Server 2008.
Les services qui tourneront seront :
 
- Une machine LTSP et une autre avec un serveur NFS contenant les /home des utilisateurs
- DHCP
- DNS
- WSUS
- LDAP
- une appli métier pour gérer une bibliothèque, uniquement sous Windows.
 
Et plus tard :
- Plusieurs serveurs Web avec des bases de données MySQL <== des petites bases...
- OCS/GLPI
- ...
 
Les questions :
 
- Quel FS pour gérer tout ça ? On aimerait faire maitre/maitre mais c'est possible uniquement avec ocfs/gfs ...et au début nous étions partit pour lvm/ext4 . Actif/Passif nous irait aussi. Le quel serait le mieux adapté ? Un RTO de 24h est déjà pas mal.
- Le choix de proxmox vous parait ok ?
- Votre avis sur ce type d'infra avec 2 machines ?
 
 

DRBD possible en maitre/maitre, mais risqué en LVM sans cluster, donc cluster = donc complexe et pas terrible en perfs avec seulement deux nœuds.

L'Actif/Passif moins contraignant.

Cependant, un RTO de 24h, je dirai qu'il n'y a même pas besoin de HA. La HA c'est super quand c'est nécessaire, sinon ça introduit beaucoup de complexité qui peut (par effet de bord ou direct) causer de belles emmerdes (Stonith qui se passe mal, ou pire, Splitbrain). Bref, pour du RTO de 24h, si l'archi est bien documentée et backupée, la HA n'est pas nécessaire : plus de temps consacré aux procédures = plus de qualité, et moins de maintenance.

Concernant la virtu, je connais bien Xen, mais je suis pas sectaire. Le tout c'est de motiver ses choix de manière transparente. Donc répondre à la question : « pourquoi ProxMox plutôt qu'un autre ? » (ça peut être parce qu'il est maîtrisé en interne par exemple, c'est une bonne réponse).

edit 2 : et bencher l'archi de stockage pour avoir ses IOPS max, afin de voir venir si ça commence à taper la zone rouge.

edit 3 : lvm+ext4 est pratique pour snapshoter + backup. Même s'il na pas les perfs d'un ZFS avec la RAM en cache...  

Merci pour cette première réponse
 
- Concernant le RTO, nous n'avons pas encore évalué combien on se donnait, 24H c'était vraiment un premier chiffre un peu au pif...
 
- Oui on était déjà plus chaud pour du actif/passif, on ne connaît pas du tout ocfs/gfs...
 
- Pour la virtualisation, on veut simplement pouvoir y mettre du linux en 32/64, du windows server ou non en 32/64. Pouvoir gérer nos snapshots facilement, déployer une machine de test rapidement.
On recherche principalement la simplicité d'administration et à première vu, Proxmox s'y prête bien.

Ok, sur la virtu on est d'accord, aujourd'hui je me vois pas être incapable de mettre un peu de tout. De ce que j'ai pu en voir, Proxmox ira très bien tant que vos besoins resteront « basiques » en terme de perfs brutes

Pour le RTO, il est essentiel d'avoir les chiffres AVANT de te lancer dans l'architecture. Car c'est ça qui conditionne tout.

Pour info, voici notre choix d'infra :
 
- 2 Proxmox en cluster
- un volume DRBD de 12To en synchro sur les 2 machines
- LVM par dessus DRBD et Proxmox gère les LVs
- La HA n'est pas configuré mais on taff dessus.
 
Si vous voulez en savoir plus, bippez moi

Multimaître le DRBD ou maître/esclave ? Test des perfs ?

primary/primary
 
Un test rapide de clonage : ~500MB/s entre les 2 DRBD
 
Et pendant la synchro DRBD, on tapait dans du 600MB/s.
 
On en est encore aux tests...

 
Le débit ne me fait pas peur sur ce genre de conf, c'est plutôt les IOPS (pour avoir exploité des conf similaire jusqu'au bout du bout, ça finit par être mou du genoux). Bien sûr tout dépend de ce qu'il y a derrière tes volumes de 12To (cache SSD ? niveau de raid etc.)

Nop, aucun cache.  
 
On est en raid5, notre partition DRBD est aligné sur les cylindres et nous n'avons rien fait de plus pour l'instant
 
Tu peux m'en dire plus sur les IOPS ? Tu faisais tourner quelles types d'applications ?

De mémoire, l'ancienne infra c'était des serveurs DRBD reliés à des Dell MD1000, 6 disques en raid6 hard. Ça allait bien jusqu'à 20 VM et quelques, puis quand on est passé à plus (avec quelques BDD), on est monté en terme d'I/O par seconde, ça a finit par impacter le reste des VM (temps d'écriture et de lecture en augmentation sur les baies de disques).
Bon faut dire que ça tournait depuis 2009 sans pépins, donc un jour où l'autre

edit : les bases de données de qualif/test ont bien plombé l'ensemble. Et si c'est du Oracle je t'explique même pas. Maintenant on fait du Tiering de stockage en fonction des besoins, on a plusieurs SAN (et comme avec XenServer on peut migrer à chaud des VM d'un SAN à un autre, c'est impec)

Je crois avoir entendu qu'il y avait eu pleins de merde sur les MD1000
 
Après, je ne pense pas qu'on soit impacté vu que l'on va hébergé de petites VMs, certes certaines avec des BDDs mais vraiment très légères (et pas d'Oracle ^^).
 
Mais on va surveiller ça de près !
 

Oui, faut pas hésiter à grapher les temps HDD (temps de lecture et écriture). Ça m'a sauvé la vie pour trouver des bug (bug carte RAID, impact d'une VM sur le ressenti des autres etc.)

Chez nous on était parti en raidz2 avec 12 disques de 2TB sur un C2100, une MD1200 avec un peu l'équivalent, puis d'autres baies no-name derrière et c'est finalement les IO qui nous ont forcés à tout refaire en striped mirror. Avec un peu de perte d'espace, mais c'est le prix à payer pour les IO. On a fini par ajouter deux SSD de 500GB pour le cache. C'est des fous des IO chez moi.

Tu fais quoi si ton DRBD plante ou fout sa merde ? Moi ça m'intéresse, j'ai un peu la même problématique et ça me fait peur de partir sur un truc que je ne maitrise pas et qui a le potentiel de foutre en l'air toute mon infra. C'est pour ça que je reste sur de l'export NFS, du snapshot LVM, du rôdé quoi. C'est robuste.

Moi j'en suis arrivé à la conclusion que le coût d'une réplication est trop élevé pour la taille des infras que j'ai mis en place (coût en terme de scenarii à la splitbrain, coût en perfs, coût en euros avec Nexenta). Du coup, pour la virtu, je fais du tiering sur le stockage : un SAN rapide et bien blindé de cache et serveur double alim (prod), et un SAN plus basique pour mettre les VM qui ne sont pas critiques. Ensuite export régulier des VM sur le système de backup pour remonter rapidement en cas de pépin. Comme on peut migrer à chaud d'un SAN à l'autre avec XenServer, ça permet de pouvoir changer l'un des deux SAN quand je veux sans impact prod.  
 
La réplication « pure » est géré au niveau applicatif.

Et donc c'est du NFS sur du ext4 sur du LVM sur du raid ?

 
Les XenServer sont reliés en iSCSI, c'est du LVM derrière (et monté brut dans les VM, donc ext3/ext4/xfs/whatever ensuite). Dans un pool de virtu, les serveurs communiquent entre eux, donc pas besoin de cLVM, les hyperviseurs ont « conscience » qu'ils sont pas tout seul (ça simplifie grandement l'infra de stockage !). Par exemple, impossible de démarrer 2 fois une VM sur deux hyperviseurs différents, ou de monter ailleurs un LV occupé.

intéressant ! Perso on débute en virtu...on a pris le choix de DRBD car si on voulait un SAN ça explosait le budget...
 

 
Au début, je pensais partir sur un volume DRBD par VM et donc permettre de répliquer n'importe quel VM sur un autre serveur avec uniquement du stockage et DRBD...mais ça impliquait beaucoup plus de complexité pour mettre en place une VM.
 
Avez vous modifier des options au niveau de la carte raid? des options?

Pourquoi un SAN exploserai le budget ? Un SAN « hardware » oui, mais un SAN software c'est un serveur et des disques (ou une baie de disque).  
 
Oui, un volume par VM ça devient ingérable si ta pas un outil qui s'occupe de le créer automatiquement derrière quand tu fais la VM.  
 
Pour ma part, maintenant c'est ZFS qui gère le RAID, donc plus de carte RAID, que du soft avec des cartes HBA.

Pour info, nous avons donc modifier le cluster pour permettre le "HA" (pas de migration à chaud), nos VMs redémarrent sur l'autre noeud automatiquement (coupure max de 2 minutes).
 
Nous avons rajouter un serveur de quorum, une troisième machine avec un simple target iSCSI relié au cluster et mise en place du fencing. Nous sommes sous onduleur avec alimentation redondante sur chaque noeud.
 
Tout marche impeccablement bien, si je coupe le réseau sur un des noeuds, ce serveur défaillant est redémarré par IPMI, les VMs sur ce noeud sont redémarré sur l'autre noeud automatiquement.
 
Quand l'autre machine redémarre, la synchro DRBD s'effectue si tout est ok.
 
Pour rappeler, voici le stockage : DRBD ==> PV ==> VG ==> LV ==> VMs en LVM/Ext4
 
Reste maintenant à étudier toutes les possibilités de pannes...
 
- électrique: Vu notre infra avec onduleur et alimentations redondantes, tout devrait rouler (script d'extinction auto des VMs puis des noeuds si plus de jus pendant au moins XX minutes)
- disque défaillant/raid cassé : reconstruction du volume DRBD sur un des noeud
- FS défaillant: bah là, on compte sur les snapshots et backups...
- Vous pensez à autres choses ?
 
@Plam: désolé de ne pas avoir répondu...on a déjà assez de couche logiciels qui s'empilent pour y rajouter un SAN logiciels..