Clusters de serveur virtuel

La virtualisation permet de faire tourner sur un même serveur physique plusieurs systèmes d’exploitation différents avec leurs propres applications.

Par exemple, avec la virtualisation, on peut faire tourner sur un même serveur physique :

• un OS Windows 2000 avec son application Microsoft SQL server
• un OS Windows 2003 avec son application Active Directory
• un OS RedHat 3 Linux avec son application Apache/Tomcat

On parle alors de 3 OS guests (3 systèmes d’exploitation invités) pour les 3 serveurs virtuels : Windows 2000, Windows 2003 et RedHat 3 Linux.

Pour mettre en œuvre la virtualisation, le serveur physique doit être équippé d’un hyperviseur dont le rôle est de permettre la création et l’exécution de serveurs virtuels. L’hyperviseur est lui même mis en œuvre dans un OS, nommé l’OS host (le système d’exploitation hôte) dont le rôle est d’accueillir les OS invités (les OS guests). On notera que certains hyperviseurs s’exécutent sur machine nue sans OS hôte.

Clusters de serveur virtuel

Un cluster de serveur virtuel est caractérisé par :

• 2 serveurs physiques avec le même système hôte
• un hyperviseur installé dans les systèmes hôtes des 2 serveurs physiques
• SafeKit installé dans les systèmes hôtes des 2 serveurs physiques
• le module applicatif pour l’hyperviseur (hyperv.safe, vmwareserver.safe...) installé avec SafeKit sur les 2 serveurs physiques

Le module applicatif hyperviseur de SafeKit sera un module de type miroir. Ce module va contenir :

• la réplication complète du serveur virtuel. Dans le fichier de configuration SafeKit du module, sera définie la réplication du répertoire qui contient l’OS guest complet quel qu’il soit (avec ses applications et ses données)
• la reprise automatique du serveur virtuel en cas de panne. Dans les scripts de reprise du module, l’arrêt/démarrage de l’OS guest sera défini. Ainsi, l’OS guest avec son application et ses données sera relancé sur le serveur physique secondaire si le serveur physique primaire est défaillant.

Chaque serveur virtuel avec son OS guest pourra être isolé dans un module applicatif SafeKit indépendant.

Grace à la propriété multi-modules de SafeKit, il sera ainsi possible de réaliser des architectures active/active avec 2 serveurs physiques en reprise mutuelle ou N-1 avec N serveurs physiques actifs et 1 serveur physique de backup.

Exemple

Dans l’exemple suivant, vous pouvez voir une configuration multi-modules sur un cluster de 2 serveurs physiques en reprise mutuelle avec :

• un module miroir pour le serveur virtuel 1 :
  • Le serveur virtuel 1 s’exécute sur le serveur physique 1
  • Le module SafeKit réplique l’OS guest Windows complet avec l’application et ses données du serveur physique 1 vers le serveur physique 2
  • Et il assure la reprise du serveur virtuel 1 sur le serveur physique 2 si le serveur physique 1 est défaillant
• un module miroir pour le serveur virtuel 2 :
  • Le serveur virtuel 2 s’exécute sur le serveur physique 2
  • Le module SafeKit réplique l’OS guest Linux complet avec l’application et ses données du serveur physique 2 vers le serveur physique 1
  • Et il assure la reprise du serveur virtuel 2 sur le serveur physique 1 si le serveur physique 2 est défaillant

Pour en savoir plus

• Cliquez ici pour une liste complète des modules livrés avec SafeKit
• Cliquez ici pour comprendre une solution alternative : le clustering d'application
• Cliquez ici pour savoir comment choisir entre clustering de serveur virtuel et clustering d’application