Comportements attendus en cas de défaillance
Cette section décrit les actions qui se produisent dans une configuration ThingWorx en mode HA en réponse à une défaillance d'un ou de plusieurs composants.
Défaillances du serveur ThingWorx
Défaillance du noeud leader ThingWorx
Procédure HA définie
1. ZooKeeper ne reçoit aucune réponse du noeud leader.
2. ZooKeeper promeut un nouveau noeud leader dans le pool des serveurs de secours ThingWorx.
3. ZooKeeper signale au noeud de secours son nouveau statut de noeud leader.
4. Le nouveau noeud leader accède entièrement à la base de données et initialise le modèle ThingWorx.
5. Le nouveau noeud leader envoie une confirmation à l'équilibreur de charge pour que toutes les requêtes ThingWorx soient routées vers lui.
6. L'équilibreur de charge route tout le trafic ThingWorx vers le nouveau noeud leader.
Défaillances de l'équilibreur de charge
Les actions et les résultats dépendront de la solution HA de l'équilibreur de charge déployé. Les sessions actives ne devraient pas être interrompues si l'équilibreur de charge a la capacité de partager le contenu de la session sur tous les noeuds d'équilibreur de charge.
Défaillance du serveur HAProxy
En cas de défaillance du noeud HAProxy unique ou de l'ensemble des noeuds HAProxy :
• Le noeud leader ThingWorx est toujours accessible via son adresse IP, mais pas via l'adresse IP de HAProxy.
• ThingWorx ne reçoit pas les requêtes transmises via HAProxy.
En cas de défaillance d'un des noeuds HAProxy :
• Les sessions utilisateur existantes seront reconnues dans ThingWorx Composer une fois le noeud HAProxy de secours devenu le noeud maître. L'utilisateur ne devrait pas avoir à se reconnecter.
• Les applications composites ne sont pas chargées tant que le noeud HAProxy de secours n'est pas devenu le noeud maître.
• L'exploration des entités dans Composer est impossible tant que le noeud HAProxy de secours n'est pas devenu le noeud maître.
• Les requêtes ne sont pas transmises à ThingWorx tant que le noeud HAProxy de secours n'est pas devenu le noeud maître.
Défaillances des noeuds ZooKeeper
Défaillance d'un seul noeud ZooKeeper
En cas de défaillance d'un des trois noeuds ZooKeeper :
• Les autres noeuds ZooKeeper détectent l'absence de réponse.
• Un nouveau noeud leader ZooKeeper est promu si le noeud défaillant est le noeud leader actuel.
• Tous les serveurs ThingWorx ne devraient pas être affectés et demeureront actifs et accessibles.
Défaillance de deux noeuds ZooKeeper
• L'élection d'un noeud leader pour ZooKeeper est impossible, car, dans la configuration ZooKeeper à trois noeuds d'origine, deux serveurs doivent être disponibles pour former un quorum. Nombre maximal de défaillances autorisées = ceil(N/2) - 1.
• L'instance restante de ZooKeeper n'est ni un noeud leader, ni un noeud de secours.
• Le noeud leader ThingWorx est arrêté, car il ne peut pas communiquer avec ZooKeeper pour l'élection d'un noeud leader.
• Le serveur de secours ThingWorx tente de communiquer avec ZooKeeper jusqu'à ce qu'au moins un autre noeud ZooKeeper soit à nouveau disponible.
• Lorsqu'au moins deux noeuds ZooKeeper sont disponibles, il devient alors à nouveau possible de promouvoir un noeud leader ZooKeeper. Le noeud de secours ThingWorx se reconnecte à ZooKeeper et devient le nouveau noeud leader.
• Le noeud leader ThingWorx précédent doit être redémarré pour devenir le noeud de secours.
Défaillance de ThingWorx et ZooKeeper
En cas de défaillance des noeuds leader de ZooKeeper et ThingWorx :
• Toutes les actions répertoriées sous "Défaillance d'un seul noeud ZooKeeper" se produisent. Le nouveau noeud leader ZooKeeper doit être déterminé en premier, de sorte qu'il promeut le nouveau noeud leader ThingWorx.
• Toutes les actions répertoriées sous "Défaillance du noeud leader ThingWorx" se produisent.
Défaillances de PostgreSQL
Cette section relative aux défaillances de PostgreSQL est basée sur la configuration suivante :
• Trois noeuds PostgreSQL (d'écriture, de lecture et de secours)
• Utilisation de la réplication en streaming entre les noeuds PostgreSQL
• Deux noeuds Pgpool-II qui gèrent l'accès client aux noeuds PostgreSQL ainsi que les procédures de récupération PostgreSQL
En cas de défaillance d'un serveur PostgreSQL, le noeud Pgpool-II actif détecte la défaillance et ne route plus les requêtes vers ce serveur. Les données de l'utilisateur ou de l'appareil enregistrées au moment de la défaillance risquent d'être perdues si les informations n'ont pas été committées et répliquées sur d'autres noeuds avant la défaillance.
En cas d'échec du noeud maître PostgreSQL (en supposant que les noeuds de synchronisation et potentiels sont opérationnels) :
• Le basculement vers le noeud de synchronisation se produit via Pgpool-II. Le noeud potentiel devient alors le noeud de synchronisation du nouveau noeud maître. Les accès en écriture à la base de données sont toujours possibles (création de nouvelles entités et écriture de données dans BDWS, par exemple).
• Si le noeud maître d'origine est de nouveau disponible, vous devez nettoyer et configurer manuellement votre environnement de façon à utiliser ce noeud.
En cas de défaillance des deux noeuds de secours (en supposant que le noeud maître est toujours opérationnel) :
• Aucun basculement ne se produit et le noeud maître ne devrait disposer d'aucun noeud pour la réplication.
• Composer reste accessible. Les entités sont chargées et peuvent être affichées. Leur enregistrement est cependant impossible. Les journaux peuvent être consultés.
• Les actions nécessitant des accès en écriture à la base de données (création et enregistrement d'une entité, définition de valeurs sur des propriétés persistantes ou ajout d'une entrée de flux, par exemple) échoueront, car PostgreSQL doit répliquer les données sur un noeud de secours.
En cas de défaillance du noeud maître et du noeud de secours de synchronisation :
• Un basculement vers le noeud potentiel se produit. Le noeud potentiel est à présent le noeud maître et ne dispose d'aucun noeud pour la réplication.
• Composer reste accessible. Les entités sont chargées et peuvent être affichées. Leur enregistrement est cependant impossible. Les journaux peuvent être consultés.
• Les actions nécessitant des accès en écriture à la base de données (création et enregistrement d'une entité, définition de valeurs sur des propriétés persistantes ou ajout d'une entrée de flux, par exemple) échoueront, car les écritures sont mises en attente, puis échouent.
En cas de défaillance des trois noeuds :
• En l'absence de noeuds, aucun basculement ne se produit.
• Composer n'a pas accès à la base de données. Par conséquent, aucune entité ne doit être chargée, la plupart des services ne fonctionneront pas (les services de sous-systèmes, comme le sous-système de plateforme, pourront toujours fonctionner) et les fonctionnalités système seront limitées (les journaux, la surveillance du système et les applications composites pourront néanmoins fonctionner).
• Les accès en écriture à la base de données et en lecture par la base de données seront impossibles.
Défaillance de ThingWorx et PostgreSQL
En cas de défaillance du noeud leader ThingWorx et du noeud maître PostgreSQL :
• L'instance de secours ThingWorx devient le noeud leader en cas de défaillance du noeud leader ThingWorx et le noeud de synchronisation de la base de données PostgreSQL devient le noeud maître PostgreSQL.
◦ Le noeud potentiel de la base de données PostgreSQL devient le nouveau noeud de synchronisation.
◦ ThingWorx Composer est disponible et la base de données PostgreSQL est accessible en écriture (des entités peuvent être créées, modifiées et supprimées, et des données ajoutées).
• Si le noeud maître PostgreSQL d'origine doit être réinitialisé en tant que noeud maître, vous devez nettoyer manuellement les noeuds PostgreSQL et Pgpool-II.
Défaillance des noeuds Pgpool-II
Défaillance du noeud Pgpool-II actif
En cas de défaillance du noeud Pgpool-II actif, le noeud de secours le détecte et prend en charge toutes les requêtes vers les serveurs PostgreSQL. Les utilisateurs connectés au serveur ThingWorx actif peuvent constater des retards de traitement dans leurs applications ainsi qu'une perte des données d'utilisateur ou d'appareil en cours d'enregistrement au moment de la défaillance du noeud Pgpool-II.
Défaillance de l'ensemble des noeuds Pgpool-II
En cas de défaillance de toutes les instances de Pgpool-II, ThingWorx n'a plus accès au contenu PostgreSQL et la plupart des fonctions échouent. Certaines fonctionnalités limitées peuvent être disponibles dans les domaines suivants :
• Journalisation : les messages d'erreur peuvent toujours être consignés dans le journal de l'application.
• Surveillance du système (par exemple, l'application composite MonitoringPlatformStats).
• Applications composites : les widgets qui ne dépendent pas des services ou des données de la base de données peuvent toujours fonctionner.
• Valeurs de propriétés non persistantes.
• Services qui n'impliquent pas la base de données.
Défaillance de ThingWorx et Pgpool-II
En cas de défaillance du noeud leader ThingWorx et du noeud maître Pgpool-II :
• Le noeud leader ThingWorx perd la priorité, un des noeuds de secours prenant alors la relève.
• L'adresse IP virtuelle n'est plus affectée au noeud maître Pgpool-II. L'un des noeuds de secours Pgpool-II devient le noeud maître et l'adresse IP virtuelle lui est réaffectée.
• Le serveur de secours ThingWorx tente d'accéder entièrement à la base de données et réussira une fois le nouveau noeud maître Pgpool prêt.
Défaillance de Pgpool-II et PostgreSQL
En cas de défaillance de PostgreSQL et Pgpool-II :
• Le noeud de secours PostgreSQL devient le noeud maître.
• Le noeud de secours Pgpool-II devient le noeud maître et l'adresse IP virtuelle lui est transférée.
• Les services sont brièvement indisponibles pendant le basculement.