Haute disponibilité

Grâce à sa haute disponibilité, WebSphere eXtreme Scale garantit une grande fiabilité dans la redondance des données et la détection des échec.

WebSphere eXtreme Scale organise les grilles de données machines virtuelles Java dans une arborescence fédérée souple. Le service de catalogue à la racine et dans les groupes centraux contenant les conteneurs sont les feuilles de l'arbre. Pour plus d'informations, voir Architecture de la mise en cache : mappes, conteneurs, clients et catalogues.

Chaque groupe central est automatiquement créé par le service de catalogue en groupes d'environ 20 serveurs. Les membres de ce groupe assurent la surveillance de la santé des autres membres. Chaque groupe central choisit un membre qui aura la responsabilité de communiquer les informations relatives au groupe au service de catalogue. Lorsque la taille du groupe central est limitée, la surveillance de la santé et l'évolutivité de l'environnement s'améliorent.
Remarque : Dans un environnement WebSphere Application Server, dans lequel la taille du groupe central peut être modifiée, eXtreme Scale ne prend pas en charge plus de 50 membres par groupe central.

Signaux de présence

  1. Les sockets restent ouverts entre les machines virtuelles Java et si un socket se ferme de manière inattendue, cette fermeture est détectée comme un incident de la machine virtuelle Java homologue. Cette détection intercepte les incidents tels que l'arrêt très rapide d'une machine virtuelle Java. Une telle détection permet généralement une reprise en ligne de moins d'une seconde après ces types d'incident.
  2. Les autres types d'incident incluent : un blocage du système d'exploitation, un problème de serveur physique ou une panne réseau. Ces incidents sont détectés par l'intermédiaire des signaux de présence.
Des signaux de présence sont envoyés de manière périodique entre des paires de processus : Si un nombre donné de signaux de présence sont manquants, un incident est supposé. Cette méthode détecte les erreurs en N*M secondes. N est le nombre de pulsations manquées et M correspond à la fréquence des pulsations. La définition directe de M et N n'est pas prise en charge. Un mécanisme mobile est utilisé pour permettre d'utiliser une plage de combinaisons M et N.

Echecs

Il existe plusieurs types d'échecs des processus. Un processus peut échouer car la limite des ressources (par exemple la taille maximale des segments de mémoire) a été atteinte ou parce qu'une logique de contrôle de processus a mis fin à un processus. Ceci risque alors d'entraîner un échec du système d'exploitation et la perte des processus en cours d'exécution. Moins fréquemment, une défaillance du matériel, par exemple de la carte d'interface réseau, peut se produire : le système d'exploitation est alors déconnecté du réseau. D'autres échecs peuvent survenir et entraîner l'indisponibilité du processus. Dans ce contexte, les échecs peuvent être classés en deux types : échec de processus et perte de connectivité.

Echec de processus

WebSphere eXtreme Scale réagit rapidement aux erreurs de processus. Lorsqu'un processus échoue, le système d'exploitation est responsable du nettoyage des ressources utilisées par celui-ci. Ce nettoyage comprend l'allocation de port et la connectivité. Lorsqu'un processus échoue, un signal est envoyé via les connexions utilisées par ce processus pour fermer celles-ci. Ce signal permet aux autres processus connectés au processus ayant échoué de détecter instantanément cet échec.

Perte de connectivité

Une perte de connectivité se produit lorsque le système d'exploitation est déconnecté. Il ne parvient alors plus à envoyer des signaux à d'autres processus. Plusieurs raisons peuvent expliquer la perte de connectivité. Elles peuvent être classées en deux catégories : échec de l'hôte ou îlotage.

Echec de l'hôte

Si la prise d'alimentation est débranchée, la machine cesse immédiatement de fonctionner.

Ilotage

Ce scénario constitue l'échec le plus complexe à gérer par le logiciel car le processus est censé être indisponible, alors qu'il ne l'est pas. Plus simplement, un serveur ou un autre processus semble avoir échoué alors qu'il s'exécute correctement.

Défaillances de conteneur

L'échec d'un conteneur est généralement identifié par des conteneurs homologues via le mécanisme du groupe central. Lorsqu'un conteneur ou un jeu de conteneurs échoue, le service de catalogue migre les fragments hébergés par ce ou ces conteneurs. Le service de catalogue commence par rechercher un fragment réplique synchrone avant de procéder à la migration vers un fragment réplique asynchrone. Une fois les fragments primaires migrés vers les nouveaux conteneurs, le service de catalogue recherche de nouveaux conteneurs hôtes pour les fragments réplique manquants.

Remarque : Isolement de conteneur : le service de catalogue migre les fragments d'un conteneur lorsque le conteneur est réputé être indisponible. S'il redevient disponible, le service de catalogue considèrent que des fragments peuvent à nouveau y être positionnés, comme dans le flux de démarrage normal.

Latence de détection des défaillances de conteneur

Les échecs peuvent être classés en deux catégories : les échecs liés aux logiciels et les échecs liés au matériel. Les échecs liés aux logiciels se produisent généralement lorsqu'un processus échoue. De tels incidents sont détectés par le système d'exploitation qui peut récupérer les ressources utilisées, par exemple les sockets réseau, rapidement. Cette détection se fait en général en moins d'une seconde. Les défaillances matérielles peuvent nécessiter un délai de détection de 200 avec l'optimisation par défaut des pulsations. Ces problèmes incluent les blocages des machines physiques, les déconnexions de câbles réseau ou les défaillances de système d'exploitation. Ce délai repose sur des signaux pour détecter les problèmes matériels qui peuvent être configurés.

Echec du service de catalogue

La grille du service de catalogue étant aussi une grille eXtreme Scale, elle utilise le mécanisme de regroupement central de la même manière que le processus d'échec des conteneurs, à cette différence près : le domaine de service de catalogue utilise une sélection d'homologue pour définir le fragment primaire plutôt que l'algorithme de service de catalogue utilisé pour les conteneurs.

Le service de placement et le service de regroupement central sont des services Un sur N. Un service Un sur N ne s'exécute que sur un seul membre du groupe haute disponibilité. Le service de localisation et l'administration s'exécutent, quant à eux, sur tous les membres de ce groupe. Le service de positionnement et le service de regroupement central sont des singletons car ils sont responsables de l'agencement du système. Le service de localisation et d'administration sont des services en lecture seule qui existent partout à des fins d'évolutivité.

Le service de catalogue utilise la réplication pour garantir sa tolérance aux erreurs. Si un processus de service de catalogue échoue, le service redémarre pour restaurer le système au niveau de disponibilité souhaité. Si tous les processus qui hébergent le service de catalogue échouent, la grille de données a une perte de données critique. Cet échec entraîne un redémarrage systématique de tous les serveurs de conteneur. Comme le service de catalogue peut s'exécuter sur plusieurs processus, cet échec est improbable. Toutefois, si vous exécutez tous les processus sur un même sous-système de stockage, sur un même châssis lame ou à partir d'un même commutateur réseau, un échec est très probable. Essayez de supprimer les modes d'échecs les plus communs des sous-systèmes de stockage qui hébergent le service de catalogue pour limiter les risques d'échec.

Echec de plusieurs conteneurs

Un fragment réplique n'est jamais placé dans le même processus que le fragment primaire, car en cas de perte du processus, les deux fragments seraient perdus. Dans un environnement de développement ne comprenant qu'une machine, vous pouvez prévoir deux conteneurs afin de procéder à des fragments réplique. Vous pouvez définir l'attribut du mode de développement de la stratégie de déploiement pour configurer une réplique à placer sur la même machine qu'un fragment primaire. Cependant dans un environnement de production, une seule machine n'est pas suffisante, car la perte de cet hôte entraînerait la perte des deux serveurs de conteneur. Pour passer d'un environnement de développement comptant une seule machine à un environnement de production comprenant plusieurs machines, désactivez le mode de développement dans le fichier de configuration de la règle de déploiement.

Tableau 1. Récapitulatif de la reconnaissance d'échec et de la reprise en ligne
Type de perte Mécanisme de reconnaissance (détection) Méthode de récupération
Perte de processus E-S Redémarrage
Perte de serveur Signal de présence Redémarrage
Indisponibilité du réseau Signal de présence Rétablissement du réseau et de la connexion
Blocage côté serveur Signal de présence Arrêt et redémarrage du serveur
Serveur occupé Signal de présence Attendre que le serveur soit disponible