IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Contexte

Dans un contexte professionnel, il arrive que des décisions soient prises et qu’il faille s’y tenir coute que coute. Même si on se rend compte plus tard que ce n’était pas forcément le chemin le plus facile. La facilité, c’est le côté obscur, on le sait bien ;-).

Pour un client, on m’a donc demandé de concevoir une plateforme RedHat 5.X virtualisée hautement disponible, avec une durée d’interruption de service maximale de 30 minutes en toute circonstance (jusque là tout va bien), ET la possibilité de restaurer les disques des OS virtuels avec plusieurs points de restaurations par palliers de 30 minutes (RPO/RTO). Aie!

Tel le Mac Giver des temps modernes, je dispose des outils suivants pour y parvenir :

  • 1 licence vSphere Essential Plus
  • 2 serveurs physiques, installés en ESXi 5.5 et reliés en SAN
  • 2 baies de disques EMC² VNX5200
  • 2 souscriptions RedHat Datacenter – pour disposer d’autant de VMs RHEL qu’on le souhaite sur nos deux nœuds physiques
  • 2 souscriptions RedHat High Availability (anciennement RedHat Cluster Suite) en mode Datacenter – pour disposer d’autant de clusters RedHat qu’on le souhaite sur nos deux nœuds physiques

Lire la suite « IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication »

Publicités
IRL : RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Best Practices pour Quorum Redhat Cluster Suite

Si vous avez déjà installé un cluster RHCS, vous saurez surement qu’il y a un certain nombre de paramètres qui semblent un peu arbitraires, et qui sont surtout assez mal définis chez Redhat. Je parle du totem token, du quorum_dev_poll et surtout de comment ils dépendent les uns avec les autres. Ces différentes valeurs correspondent à des durées de timeout sur les différents composants qui régissent le cluster.

C’est pourtant d’autant plus important à comprendre que, si vous laissez les valeurs initiales, vous pourrez avoir de vilaines surprises en cas de bascule multipath d’un chemin.

Personnellement, j’ai eu le cas sur un cluster hébergé chez un prestataire. Celui ci a réalisé des opérations sur son SAN, normalement transparentes, qui ont eu la facheuse conséquence de mettre en carafe toute l’infrastructure.

Ce qui s’est réellement passé, c’est que le timeout de multipath étant autour des 45 secondes en dur, les valeurs par défaut de perte du quorum était trop courte et le serveur se sabordait, pensant avoir perdu la cohérence du cluster.

Lire la suite « Best Practices pour Quorum Redhat Cluster Suite »

Best Practices pour Quorum Redhat Cluster Suite