Comportements attendus en cas de défaillance
Cette rubrique décrit les actions qui se produisent dans une configuration de cluster ThingWorx en réponse à une défaillance d'un ou de plusieurs composants.
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 du serveur ThingWorx
En cas d'échec d'un serveur ThingWorx, les opérations suivantes se produisent :
• Le serveur est supprimé de l'équilibreur de charge, car la commande ping de contrôle d'intégrité échouera. Le moment où le serveur est supprimé dépend de la fréquence de contrôle.
• ZooKeeper détecte l'échec du serveur, le supprime de la découverte de service interne et notifie les observateurs, tels que le serveur de connexion.
• Si le serveur est le serveur singleton, ZooKeeper avertit les autres serveurs et sélectionne un nouveau serveur singleton.
Les clients connectés au serveur peuvent recevoir des erreurs lors du basculement, mais parviendront à se reconnecter à un nouveau serveur.
La défaillance ou la suppression d'un serveur peut entraîner une perte de données. Dans ce cas, les données des files d'attente des traitements par lots seront perdues. Si le serveur est arrêté au lieu d'échouer, les opérations ci-dessus se produisent au moment de la désinscription du serveur et les files d'attente des traitements par lots sont purgées.
Noeuds ThingWorx Platform hors service
Tant qu'au moins une instance de Platform est en état de fonctionnement, les autres noeuds peuvent être redémarrés sans conséquence sur le système. Toutefois, si tous les noeuds Platform sont hors service ou défectueux, l'état stocké dans Ignite devient incohérent. Dans ce cas, il est nécessaire que tous les noeuds Platform et Ignite soient arrêtés, puis redémarrés.
1. Arrêter tous les noeuds Platform.
2. Arrêtez tous les noeuds Ignite.
3. Redémarrez tous les noeuds Ignite.
4. Redémarrez tous les noeuds Platform.
Si Ignite n'est pas redémarré, les tables de liaison et d'autres données stockées dans Ignite seront incorrectes, ce qui entraînera des comportements indésirables au fil du temps.
Défaillances de ZooKeeper
Défaillance d'un seul noeud
En cas de défaillance d'un noeud 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.
Défaillance de plusieurs noeuds
Si plusieurs noeuds échouent et que ZooKeeper perd son quorum, il passe en mode lecture seule et rejette les requêtes de modification.
• 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.
• Les instances restantes de ZooKeeper ne sont ni des noeuds leaders, ni des noeuds de secours.
• Tous les clients recevront l'état SUSPENDED, puis LOST.
Serveurs ThingWorx
• Avec l'état SUSPENDED, le rôle singleton n'est plus affecté. Pendant ce temps, aucun timer ou planificateur ne s'exécutera.
• Avec l'état LOST, tous les noeuds s'arrêtent.
• Si ZooKeeper récupère avant expiration du système, un nouveau singleton est promu et le traitement se poursuit.
Serveur de connexion
• Si ZooKeeper affecte l'état LOST au serveur de connexion, ce dernier s'arrête, car il ne connaît pas le statut des serveurs ThingWorx.
Ignite
• Il est supposé que le cluster ZooKeeper est toujours visible pour tous les noeuds du cluster. Si un noeud se déconnecte de ZooKeeper, il s'arrête et les autres noeuds le considèrent comme en échec ou déconnecté.
Défaillances d'Ignite
L'impact des défaillances d'Ignite dépend du niveau de réplication des données. Ignite doit toujours être configuré pour stocker les données sur au moins deux noeuds du cluster. Par conséquent, si un noeud est perdu, le système n'est pas impacté.
La perte de plusieurs noeuds peut entraîner une perte de données, ce qui peut affecter un état incohérent au système. Dans ce cas, nous vous recommandons de procéder à un arrêt complet d'Ignite et de l'ThingWorx. Vous pouvez ensuite redémarrer Ignite, puis ThingWorx. Ignite constitue la mémoire de l'application. Sa défaillance, le comportement de traitement peut devenir extrêmement incohérent.
En cas d'échec total d'Ignite où ThingWorx ne peut se connecter à aucun noeud Ignite, ThingWorx s'arrêtera.
Pour plus d'informations sur les sauvegardes de données, consultez les liens suivants :
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.
• La procédure et le comportement indiqués dans la section Défaillance du noeud leader ThingWorx s'appliquent.
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.