Documentation
Découvrez le mode zéro configuration
Non trouvé

    ServicePilot Clustering et Scaling

    Ce qui suit explique la configuration de ServicePilot Clustering et Scaling pour les déploiements de ServicePilot On Premise.

    Qu'est-ce qu'un cluster ServicePilot ?

    La solution ServicePilot peut être mise en cluster pour des raisons de performance ou de partitionnement des données. Pour partitionner la configuration, l'authentification et les données, la notion de tenant est utilisée pour indiquer une instance distincte de ServicePilot avec ses propres utilisateurs, ses équipements supervisés et son historique de données. Les Agents ServicePilot sont associés à un seul tenant.

    Un seul Manager et une Database ServicePilot sur un matériel récent avec 8 vCores, 16GB RAM et un stockage SSD peuvent gérer jusqu'à :

    • 500 000 à 1 000 000 d'indicateurs par minute
    • 50 000 à 80 000 objets
    • 500 à 1 000 Hosts Full-Stack

    La solution ServicePilot peut être mise en cluster de plusieurs manières :

    • Haute disponibilité : en déployant d'autres Managers et Databases ServicePilot, dans le même cluster, qui peuvent prendre le relais en cas de défaillance ou de maintenance. Cela n'augmente pas la capacité de la solution.
    • Mise à l'échelle de la base de données : en ajoutant plus de services Database, l'un dédié à l'écriture des données tandis que les autres ne font que lire les données. Cela améliore les performances avec les grands ensembles de données et les grandes requêtes de base de données.
    • Partitionnement et mise à l'échelle multi-tenants : en déployant un certain nombre de clusters de Managers et de bases de données ServicePilot, chacun avec des données séparées. Les utilisateurs peuvent se voir attribuer des droits différents par chaque tenant, avec une connexion unique fonctionnant entre les tenants.
    • Clustering multi-régions : en déployant géographiquement plusieurs clusters de Managers et de bases de données ServicePilot, les données reçues sont conservées dans la région du cluster pour des raisons légales ou autres. Les utilisateurs peuvent avoir accès à différentes régions avec des droits différents dans chaque région avec une connexion single sign-on automatique entre les régions.

    Les données sont reçues d'un ou plusieurs Agents ServicePilot qui peuvent être directement connectés aux Managers ServicePilot ou via des Proxies ServicePilot et des Load-balancers. Le cluster de Managers ServicePilot dirigera le trafic des Agents ServicePilot vers le Manager ServicePilot et la partition du tenant appropriés.

    Un Cluster ServicePilot permet de détecter la disponibilité des services et de répliquer la configuration à travers la solution ServicePilot. Un Cluster ServicePilot nécessite 1, 3 ou 5 services SPCluster. Pour une haute disponibilité, 3 ou 5 services SPCluster sont nécessaires sur différents serveurs. Les services SPCluster peuvent être hébergés conjointement avec d'autres logiciels ServicePilot.

    Les services SPCluster forment un quorum lorsque plus de la moitié des services SPCluster peuvent communiquer entre eux. Les autres services ServicePilot peuvent alors démarrer et ne continueront à fonctionner que si le quorum est maintenu.

    Une fois le cluster installé, la haute disponibilité et l'échelonnement de la base de données ne nécessitent pas de configuration supplémentaire.

    Service SPCluster

    Tous les services SPCluster d'un cluster ont besoin du même Cluster ID et d'autres configurations. Cependant, chaque service SPCluster doit être configuré avec un Node ID unique. Les autres services ServicePilot qui utilisent le cluster utiliseront un Node ID propre au nœud sur lequel le service est installé. Le nœud actif ayant le numéro le plus bas est considéré comme le Leader.

    La communication entre les services SPCluster et l'accès aux services SPCluster à partir d'autres services ServicePilot se fait sur le port TCP sécurisé 8980. Nous suggérons de définir les adresses IP distantes de tous les services de cluster dans les règles de pare-feu.

    Pour les services de cluster Linux, les variables d'environnement suivantes sont utilisées :

    Variable d'environnement Notes
    sp_cluster Une liste d'URLs séparées par des |, une pour chaque service SPCluster
    sp_node_id Le Cluster ID de ce service, SPCluster ou autre. Pour les services SPCluster, cela indique quelle URL de la liste sp_cluster est la sienne.
    sp_cluster_id Pour les services SPCluster, cela indique quelle URL de la liste sp_cluster est la sienne. Les Cluster IDs sont composés de 1 à 4 caractères alphanumériques.

    Pour les services de cluster Windows, la ServicePilot Setup Console est utilisée pour définir la configuration du cluster. Le service SPCluster peut être démarré automatiquement par le Manager ServicePilot de Windows.

    Fichiers de configuration du cluster

    Une fois que la configuration du ServicePilot Cluster par noeud est établie, la suite de la configuration du cluster est gérée dans des fichiers sur Node ID 1. Ces fichiers de configuration du cluster sont ensuite répliqués sur les autres nœuds lorsqu'un rechargement de configuration ou un redémarrage est effectué sur le nœud 1.

    Dossier WorkFolder Contenu
    cluster.conf Configuration de la grappe d'entreprises
    servicepilot.conf Configuration de ServicePilot commune à tous les nœuds et tenants
    servicepilotdb.conf Configuration de la base de données
    servicepilotdb.conf Storage.conf``Configuration de la base de données

    Chaque tenant a la configuration suivante :

    Dossier WorkFolder Contenu
    tenant.conf Par configuration du tenant
    provisioning.conf Pour les ressources du tenant
    Packages, Pictures Pour les packages et les images personnalisés du tenant

    Redondance du Manager ServicePilot

    Si plusieurs Managers ServicePilot fonctionnent avec le même Cluster ID, celui qui a le Node ID le plus bas sera le leader et prendra le contrôle. Les autres Managers ServicePilot redirigeront le trafic vers le leader.

    Chaque Manager ServicePilot d'un cluster nécessite une licence ServicePilot distincte.

    Méthodes d'accès au Manager ServicePilot

    Les utilisateurs de ServicePilot dont la redondance est configurée auront besoin d'un moyen fiable d'accéder à l'interface web de ServicePilot lorsque l'un des nœuds devient indisponible.

    Ceci peut être réalisé avec un load-balancer qui devra être installé séparément. Un équilibreur de charge peut être configuré pour vérifier l'URL /ping.html sur chaque ServicePilot Manager. Si la réponse est un code de retour 302, cela indique que le service n'est pas un leader. Un code de retour 200 indique que le service est le leader.

    Redondance de la Database ServicePilot

    Si plusieurs Database ServicePilot fonctionnent avec le même Cluster ID, celle qui a le Node ID le plus bas sera le leader et gérera l'accès en lecture/écriture aux fichiers de la base de données. Les autres Databases ServicePilot seront en attente jusqu'à ce que l'ancien leader ne soit plus disponible.

    Le basculement vers les Databases ServicePilot sur un deuxième nœud offrira une expérience dégradée car les nouvelles données ajoutées au deuxième nœud ne seront pas répliquées sur le premier nœud. Lorsque le service est rétabli sur le premier nœud, il faut s'attendre à un écart dans les données historiques.

    Haute disponibilité de la base de données avec stockage partagé

    Si les nœuds contenant les services Database ServicePilot partagent un fichier commun, le WorkFolder de ServicePilot peut être placé sur ce dispositif. Cela permet un stockage commun des données historiques.

    Les Databases ServicePilot fonctionnant avec le même Cluster ID peuvent être configurées de manière à ce que celle ayant le Node ID le plus bas soit le leader et gère l'accès en lecture/écriture aux fichiers de la base de données. D'autres Database ServicePilot avec le même Cluster ID peuvent fournir un accès en lecture seule aux fichiers de la base de données pour améliorer les performances.

    Notez que la performance du stockage doit être spécifiée avec une performance équivalente au stockage SSD local.

    Haute disponibilité

    Une configuration minimale de ServicePilot Cluster consiste en :

    • 3 services SPCluster
    • 2 services SPManager
    • 2 services SPDB

    Chaque nœud doit se trouver dans une zone de disponibilité distincte du centre de données. Cette configuration fournira une redondance si un nœud devient indisponible ou inaccessible.

    Variable d'environnement commune Notes
    sp_cluster https://spus1.company.com:8980|https://spus2.company.com:8980|https://spus3.company.com:8980
    Node Services configurés sp_node_id sp_cluster_id
    SP1 SPCluster,SPManager,SPDB 1 USA
    SP2 SPCluster,SPManager,SPDB 2 USA
    SP3 SPCluster 3 USA

    Mise à l'échelle de la base de données

    Pour augmenter les performances de la base de données, configurez un deuxième noeud avec un service Database ServicePilot et un stockage commun entre les serveurs pour les fichiers de la base de données.

    Variable d'environnement commune Notes
    sp_cluster https://spus1.company.com:8980
    Node Services configurés sp_node_id sp_cluster_id
    SP1 SPCluster,SPManager,SPDB 1 USA
    SP2 SPDB 2 USA

    Partitionnement et mise à l'échelle multi-tenants

    Pour partitionner ou mettre à l'échelle une solution ServicePilot, créez un cluster de Managers ServicePilot et de Databases ServicePilot indépendants avec un minimum de 3 services SPCluster.

    Les Node ID sont uniques pour chaque nœud entre tous les nœuds qui utilisent les mêmes services SPCluster indépendamment du Cluster ID auquel ils appartiennent.

    Variable d'environnement commune Notes
    sp_cluster https://sp1.company.com:8980|https://sp2.company.com:8980|https://sp3.company.com:8980
    Node Services configurés sp_node_id sp_cluster_id
    SP1 SPCluster,SPManager,SPDB 1 SRV1
    SP2 SPCluster,SPManager,SPDB 2 SRV2
    SP3 SPCluster,SPManager,SPDB 3 NET1
    SP4 SPManager,SPDB 4 NET2
    SP5 SPManager,SPDB 5 VOIP
    SP# SPManager,SPDB # Tenant#

    Clustering multi-régions

    Les services SPCluster, une fois déployés, peuvent être utilisés par plusieurs clusters de Managers ServicePilot et de Databases ServicePilot distincts. Dans ce scénario, chaque groupe distinct de services redondants est défini par son propre Cluster ID.

    Les Managers ServicePilot de clusters distincts supportent le single sign-on, ce qui signifie que si un utilisateur se connecte à un Manager ServicePilot dans un cluster, il peut ouvrir des pages web sur des Managers ServicePilot d'autres clusters sans avoir à se connecter à nouveau, tant que l'ID de l'utilisateur est défini dans l'autre cluster.

    Variable d'environnement commune Notes
    sp_cluster https://spus1.company.com:8980|https://speu3.company.com:8980|https://spaz5.company.com:8980
    Node Services configurés sp_node_id sp_cluster_id
    SP1 SPCluster,SPManager,SPDB 1 USA
    SP2 SPManager,SPDB 2 USA
    SP3 SPCluster,SPManager,SPDB 3 EU
    SP4 SPManager,SPDB 4 EU
    SP5 SPCluster 5 Azure