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.
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é.
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.
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.
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.
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.
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.
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.
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 |