Comme évoqué dans l’article d’hier, les évolutions majeures de XenServer dans sa version 5 se portent essentiellement sur les fonctionnalités de haute disponibilité. Voici donc naturellement un petit détail sur le fonctionnement de XenServer HA. Etant donné que de nombreux lecteurs connaissent VMware HA, je me permets de comparer les deux solutions afin de mieux comprendre le fonctionnement de XenServer HA.

La première différence est que la solution XenServer HA maintient des liens vie non seulement sur le réseau, mais aussi sur d’autres éléments comme le stockage. C’est un avantage certain par rapport à VMware HA. En contre partie, XenServer HA ne peux pas garantir le redémarrage des machines virtuelles, c’est une solution de type “best effort”. En effet, contrairement à VMware HA, il n’y a pas de possibilité de mettre une contrainte pour rendre impossible l’exécution d’une machine virtuelle si le cluster ne dispose pas de suffisamment de ressources pour pouvoir assurer le redémarrage des machines virtuelles en cas de défaillance d’un hôte.

J’avais déjà écris un article sur Marathon Technologies. En effet, le rapprochement avec Citrix n’est pas nouveau. Depuis, ceux-ci ont collaboré afin de développer XenServer HA. Marathon a donc joué un rôle important dans l’évolution de XenServer.

Marathon continue aussi à mettre à disposition une solution permettant d’aller plus loin que Citrix, il s’agit du produit everRun VM. Il apporte un niveau au dessus de XenServer appelé “Component Level Fault Tolerance”. Qui permet apparemment de dupliquer les entrées / sorties sur deux serveurs virtuels au travers d’un lien privé. Il permet aussi de garantir la disponibilité car il réserve des ressources. Au premier trimestre 2009, Marathon mettra à disposition un niveau encore plus important avec un objectif de zéro arrêt de service en offrant des fonctionnalités de type miroir d’exécution de machine virtuelle, comme VMware Fault Tolerance lui aussi prévu prochainement.