Haute disponibilité ThingWorx

Présentation de la haute disponibilité ThingWorx

Pour réduire la durée des arrêts des systèmes IoT critiques, vous pouvez configurer ThingWorx pour qu'il fonctionne dans un environnement haute disponibilité (HA). Ce guide décrit les considérations relatives à la haute disponibilité requises pour un système ThingWorx et les composants qui constituent un déploiement haute disponibilité de ThingWorx.

Tous les déploiements haute disponibilité nécessitent des ressources supplémentaires par rapport à un déploiement conçu uniquement pour répondre à des exigences fonctionnelles et de dimensionnement. Ces ressources supplémentaires sont de type matériel (serveurs, disques, équilibreurs de charge, etc.) et logiciel (services de synchronisation et équilibreurs de charge). Les ressources supplémentaires sont ensuite configurées pour s'assurer qu'il n'existe point de défaillance unique dans le déploiement haute disponibilité.

Tous les déploiements haute disponibilité doivent être basés sur un accord de niveau de service (SLA) dans lequel vous avez analysé les exigences de disponibilité de l'application pour votre déploiement. Par exemple, combien d'heures par mois le système peut-il être hors ligne ? Cette période d'indisponibilité est-elle autorisée pour les défaillances système, les mises à niveau d'application ou les deux ? Le nombre de ressources supplémentaires requises pour un système HA dépend du SLA conclu. En général, plus le SLA est exigeant, plus le nombre de ressources requises pour y répondre est élevé.

Définitions

• haute disponibilité

Système ou composant opérationnel en permanence pendant (de préférence) une longue durée.

• actif/actif

Instances de la même application pouvant fonctionner simultanément.

• actif/passif

Une seule instance d'une application fonctionne. D'autres instances sont disponibles et peuvent prendre en charge le service selon les besoins.

• leader ou maître

Dans une configuration haute disponibilité active/passive, serveur actif vers lequel l'ensemble du trafic est routé.

• secours

Dans une configuration haute disponibilité active/passive, serveur en attente pour prendre en charge le service en cas de défaillance du serveur leader actuel.

• adresse IP virtuelle

Adresse IP qui représente une application. Les clients qui utilisent l'adresse IP virtuelle sont généralement routés vers un équilibreur de charge qui dirige ensuite la requête vers le serveur exécutant l'application.

• équilibreur de charge

Périphérique qui reçoit le trafic réseau et le distribue à l'application disponible. Dans une configuration haute disponibilité active/passive, l'équilibreur de charge dirige le trafic vers le leader actuel. Dans une configuration haute disponibilité active/active, l'équilibreur de charge dirige le trafic vers l'une des nombreuses applications.

• basculement

Mode de fonctionnement de secours dans lequel les fonctions d'un composant système (comme un processeur, un serveur, un réseau ou une base de données) sont prises en charge par des composants système secondaires lorsque le composant principal est indisponible en raison d'une défaillance ou d'une période d'arrêt programmée.

Architecture de référence pour un environnement ThingWorx haute disponibilité

L'image ci-après illustre une configuration ThingWorx haute disponibilité.

La section ci-après décrit les composants de cette configuration et leur rôle dans un déploiement haute disponibilité :

• Utilisateurs et appareils : ces composants ne jouent aucun rôle dans une configuration haute disponibilité. A ce niveau, rien ne change. Les URL et les adresses IP qu'ils utilisent restent inchangées, même en cas de changement de serveur ThingWorx principal.

• Pare-feu : aucune fonction HA ne peut être considérée comme facultative. Les pare-feu sont souvent présents pour répondre aux exigences de sécurité.

• Equilibreurs de charge : les équilibreurs de charge gèrent une adresse IP virtuelle pour l'application qu'ils prennent en charge. Tout le trafic routé vers cette adresse IP virtuelle est dirigé vers l'application active qui peut le recevoir.

• Serveurs de connexion ThingWorx : ces composants reçoivent le trafic de sockets Web des actifs et le routent vers ThingWorx Platform. Les serveurs de connexion peuvent fonctionner dans une configuration active/active. Une fois dirigé vers un serveur de connexion spécifique, un actif doit toujours l'utiliser. Si ce serveur se déconnecte, l'actif doit être redirigé vers un autre serveur de connexion disponible.

• ThingWorx Foundation : reçoit l'ensemble du trafic des utilisateurs et des actifs. ThingWorx Foundation fonctionne dans une configuration active/passive avec un serveur leader et un ou plusieurs serveurs de secours. Le serveur leader est en ligne et reçoit le trafic. Les serveurs de secours s'exécutent dans un état de secours semi-automatique lorsque l'application est en cours d'exécution. Ils ne disposent cependant d'aucune connexion active à la base de données et ne reçoivent pas de trafic. Un équilibreur de charge route l'ensemble du trafic vers le leader. Si le leader se déconnecte, le serveur de secours est promu leader et le trafic y est alors routé.

• Référentiels ThingWorx : il s'agit des emplacements de stockage requis tels que ThingworxPlatform, ThingworxStorage et ThingworxBackupStorage, ainsi que des autres emplacements de stockage ajoutés pour la prise en charge de votre implémentation. Dans un environnement haute disponibilité, les référentiels ThingWorx doivent se trouver dans un emplacement de stockage commun auxquels tous les serveurs ThingWorx (leader et de secours) ont équitablement accès.

• Apache ZooKeeper : ZooKeeper est un service de coordination centralisé utilisé par ThingWorx pour promouvoir comme leader l'un des serveurs ThingWorx lorsque cela est nécessaire. Un client ZooKeeper est intégré à chaque serveur ThingWorx afin de conserver une pulsation et de réagir aux modifications apportées à la configuration, par exemple en cas de défaillance du leader ThingWorx.

• PostgreSQL : dans une configuration haute disponibilité, PostgreSQL fonctionne via au moins deux noeuds de serveur dans une configuration de serveur de secours (Hot Standby). Un noeud reçoit tout le trafic d'écriture et l'un des autres noeuds peut recevoir tout le trafic de lecture. La réplication en streaming est activée entre tous les noeuds pour que chaque noeud reste à jour.

• Pgpool-II : utilisé uniquement dans les configurations de PostgreSQL haute disponibilité. Les noeuds Pgpool-II reçoivent les requêtes ThingWorx (lecture et écriture) et les dirigent vers le noeud PostgreSQL approprié. Il contrôle également l'intégrité de chaque noeud PostgreSQL et peut lancer le basculement et le reciblage des tâches lorsque l'un des noeuds se déconnecte.

• Microsoft SQL Server (non illustré) : le basculement Microsoft est utilisé pour s'assurer qu'au moins un serveur MS SQL est en ligne et disponible.

• DataStax Enterprise (DSE) : une implémentation DSE n'est pas requise pour une configuration ThingWorx en mode HA. S'il est nécessaire de respecter les exigences d'ingestion de l'implémentation, assurez-vous qu'elle est configurée pour un environnement HA. L'implémentation DSE typique répond à la plupart des exigences de haute disponibilité. Elle comporte plusieurs noeuds Cassandra, qui collectent du contenu, et au moins deux noeuds Solr. L'implémentation DSE réplique l'ensemble du contenu sur au moins un autre noeud.

A compter de la version 8.5.0 de ThingWorx Platform, DataStax Enterprise n'est plus disponible à la vente et ne sera plus pris en charge dans les prochaines versions. Pour plus d'informations, reportez-vous à l'article concernant la fin de sa commercialisation.

Exigences avant l'installation

Notes et avertissements :

• Cette procédure de déploiement haute disponibilité doit être réalisée par un administrateur de base de données (DBA) possédant une expérience préalable des bases de données relationnelles en configuration HA (PostgreSQL, Microsoft SQL Server et DataStax Enterprise). Les connaissances requises concernent l'installation, l'optimisation et le clustering haute disponibilité.

• Les instructions fournies ici permettent de déployer des environnements en mode HA. Dans un environnement de production, un réglage supplémentaire des performances pourra s'avérer nécessaire, aspect qui n'est pas abordé ici.

• Les étapes détaillées constituent de simples exemples fournis à titre indicatif et sont uniquement destinées à un environnement de QA/sandbox. Les commandes et paramètres sont susceptibles de devoir être modifiés pour une performance optimale en environnement de production.

• Toutes les configurations de basculement doivent être entièrement testées et validées avant d'être utilisées en production.

• Cette procédure n'aborde pas les scénarios de retour arrière, dans lesquels un leader défaillant est corrigé, puis rétablit dans sa position de leader. Il est considéré à cet égard que le composant défaillant est corrigé, puis remis en service en tant que composant non leader.

Systèmes d'exploitation pris en charge

Consultez la rubrique Configuration requise pour ThingWorx.

Exigences générales concernant la haute disponibilité

Adresses IP virtuelles

• Utilisateurs et actifs aux serveurs de connexion (si des serveurs de connexion sont utilisés)

• Serveurs de connexion à ThingWorx Foundation

• ThingWorx Foundation à l'environnement HA PostgreSQL (si PostgreSQL est utilisé)

• ThingWorx Foundation à l'environnement HA Microsoft SQL Server (si Microsoft SQL Server est utilisé)

Configuration matérielle requise

Dans cette procédure, il est supposé qu'une redondance matérielle complète est utilisée dans une configuration de ThingWorx en mode HA.

• Chaque instance d'une application doit être exécutée sur un matériel distinct afin d'éviter les points de défaillance uniques au niveau du matériel. Par exemple, les serveurs ThingWorx, qu'ils soient physiques, virtuels ou basés sur le Cloud, ne doivent pas fonctionner sur le même matériel physique.

• Cette exigence est attendue pour toutes les applications de la configuration ThingWorx en mode HA (ThingWorx, PostgreSQL, DataStax Enterprise, ZooKeeper, etc.) afin de limiter le risque de défaillances matérielles.

• Dans cette procédure, il est supposé que vous utilisez des routeurs, des commutateurs ou encore des alimentations redondants.

Propriétés de ThingWorx dans une configuration HA

Les propriétés de ThingWorx doivent être persistantes pour éviter toute perte de données en cas de basculement. Si tel n'est pas le cas, un basculement du serveur principal vers un serveur secondaire entraînerait l'effacement des valeurs en mémoire.

Exigences PostgreSQL

• Pgpool-II et PostgreSQL DB installés dans les environnements RHEL ou Ubuntu.

• Au moins deux serveurs hôtes de base de données exécutant une version prise en charge de PostgreSQL. Il est recommandé d'en utiliser trois.

• L'utilisation de deux serveurs exécutant Pgpool-II 3.7.<dernière version> avec une fonctionnalité de surveillance configurée est répandue. Ce document propose un exemple de configuration. D'autres configurations HA qui n'utilisent pas Pgpool-II sont cependant envisageables.

Exigences Microsoft SQL Server

• Au moins deux serveurs hôtes de base de données exécutant une version prise en charge de Microsoft SQL Server.

• Microsoft SQL Server est configuré de façon à fonctionner via l'une des méthodologies HA de Microsoft suivantes :

◦ Instances de cluster de basculement AlwaysOn

◦ Groupes de disponibilité AlwaysOn

Exigences DataStax Enterprise

• Au moins cinq noeuds pour un cluster DataStax Enterprise :

◦ Trois noeuds Cassandra

◦ Deux noeuds Solr

◦ (facultatif) Un noeud DSE OpsCenter pour les tâches administratives, OpsCenter n'étant pas essentiel à l'activité et ne nécessitant pas une configuration haute disponibilité.

Exigences InfluxDB

• Au moins deux méta-noeuds (trois recommandés pour la plupart des cas d'utilisation)

• Au moins deux noeuds de données (nombre pair recommandé)

• Un déploiement type doit comporter trois méta-noeuds, et un nombre pair de noeuds de données.