Le blog de Victor Héry
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

1.6 KiB

email: tranxene50@developpeur-neurasthenique.fr date: 2013-01-17T00:10+01:00 author: tranxene50 website: http://blog.developpeur-neurasthenique.fr/

Hello !

Ouh punaise... J'attends la suite (technique) avec impatience !

Je crois que je n'ai jamais lu un article aussi didactique (en français) et notamment en ce qui concerne la notion de quorum avec Proxmox.

Pour le fencing, c'est clair qu'une solution matérielle est a privilégier mais il est possible (me semble-t-il) de tricher avec un "fence device" virtuel (à creuser, cela implique quelques sacrifices).

Au niveau de DRBD, même si cela fonctionne correctement, je pense qu'il va y avoir un souci avec les applications qui utilisent massivement la mémoire (cache/buffer), par exemple MySQL.

Ce que je veux dire c'est que, répliquer les fichiers Innodb ne suffit pas pour garantir l'intégrité des bases : si le serveur de secours démarre, il y aura forcément un recovery des BDD. (A tester dans la vie réelle, MySQL se démerde plutôt bien dans ce cas de figure).

De tout ce que j'ai lire, pour migrer des containers OpenVZ sans aucune perte de données, il faut impérativement sauvegarder l'état de la mémoire (checkpointing).

Concernant les IP fail over, quand on utilise des serveurs dédiés via des prestataires différent, c'est clairement la plaie (marche pas...).

Je cherche toujours une solution a ce problème mais, de ce que j'ai pu comprendre, il faudrait passer un prestataire tiers qui reroute le trafic (donc c'est du transit) là où il faut. Le souci c'est qu'on utilise leur bande passante (logique) et donc, il facturent cela.

A+