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.

    Pour un déploiement de la configuration de ServicePilot en cluster, il est nécessaire de contacter notre support technique afin de s'assurer que l'architecture demandée soit validée et compatible avec ServicePilot.

    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 désigner une partition 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 ServicePilot et une seule Base de données sur du matériel récent avec 8 vCores, 16 GB de 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 des Managers ServicePilot et des Bases de données supplémentaires au sein du même cluster, capables de prendre le relais en cas de panne ou de maintenance. Cela n'augmente pas la capacité de la solution.
    • Mise à l'échelle des Bases de données : en ajoutant davantage de services de Base de données, l'un dédié à l'écriture des données tandis que les autres se chargent uniquement de la lecture des 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 ServicePilot et de Bases de données, chacun avec des données séparées. Les utilisateurs peuvent se voir attribuer des droits différents par 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.

    Conditions requises pour un cluster ServicePilot

    Le déploiement d'un cluster ServicePilot nécessite un certain nombre de prérequis supplémentaires, en plus des prérequis standards pour les serveurs ServicePilot :

    1. Services du cluster ServicePilot.
    2. Les données ServicePilot sont stockées dans un ou plusieurs buckets de stockage d'objets compatibles S3 gérés par l'administrateur ServicePilot.
    3. Des définitions DNS round-robin pour les Managers ServicePilot afin de gérer le basculement, le partage de charge et la redirection pour les tenants hébergés sur d'autres Managers ServicePilot.

    Services SPCluster

    Les services SPCluster assurent la détection de la disponibilité et permettent de répliquer la configuration dans l'ensemble de la solution ServicePilot. Pour garantir la 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 Managers ServicePilot et Bases de données.

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

    La communication entre les services SPCluster et l'accès à ces services depuis d'autres services ServicePilot s'effectuent sur le port TCP 8980. Ce port doit être sécurisé afin de n'autoriser que le trafic provenant d'autres services SPCluster ainsi que des Managers ServicePilot et Bases de données.

    Stockage d'objets de données S3

    Le client est chargé de fournir des stockages d'objets compatibles S3 accessibles par tous les nœuds ServicePilot sur lesquels les Bases de données ServicePilot sont en cours d'exécution. Différents serveurs S3 peuvent être utilisés mais un seul stockage peut être utilisé par tenant.

    Des copies des données peuvent être envoyées vers des stockages d'objets S3 secondaires à des fins de sauvegarde.

    Configuration DNS

    Lorsque les utilisateurs et les Agents ServicePilot se connectent pour la première fois aux Managers ServicePilot, ils utilisent un nom de domaine complet (FQDN) au niveau du cluster qui désigne l'ensemble des Managers ServicePilot du cluster. Chaque Manager ServicePilot dispose également d'un nom de domaine complet (FQDN) et d'une adresse IP uniques.

    Exemple de configuration DNS

    |Composant|FQDN|Type|Valeur|
    |Cluster Node 1|spc1.company.com|A|10.1.1.10|
    |Cluster Node 2|spc2.company.com|A|10.1.2.10|
    |Cluster Node 3|spc3.company.com|A|10.1.3.10|
    |Manager Node 1|sp1.company.com|A|10.1.1.11|
    |Manager Node 2|sp2.company.com|A|10.1.2.11|
    |ServicePilot client access|sp.company.com|CNAME|sp1.company.com, sp2.company.com|

    Certificats

    Chaque Manager ServicePilot doit répondre aux requêtes initiales adressées au nom de domaine complet (FQDN) du cluster ainsi qu'à son propre FQDN. Il est donc nécessaire de disposer d'un seul certificat du Manager ServicePilot valide pour le cluster et tous les FQDN des nœuds. Par exemple : sp.company.com, sp1.company.com, sp2.company.com

    Managers ServicePilot

    Les Managers ServicePilot hébergent les tenants. Un seul Manager ServicePilot peut servir un tenant à la fois. En cas de défaillance du Manager, sa responsabilité est transférée à un Manager ServicePilot de secours, selon la configuration du cluster.

    Bases de données ServicePilot

    Un seul service de Base de données ServicePilot est chargé d'écrire les données d'un tenant à la fois. Si le service de Base de données est arrêté ou tombe en panne, une Base de données ServicePilot de secours prendra le relais pour l'écriture des données du tenant.

    Plusieurs services de Base de données ServicePilot peuvent être configurés pour lire les données d'un tenant afin de répartir la charge de lecture. Les données sont mises en cache localement par les services de Base de données afin d'accélérer les futures requêtes.

    Gestion de la configuration du cluster

    Un quorum des services du Cluster ServicePilot est toujours nécessaire pour faire fonctionner un cluster ServicePilot. La configuration initiale est téléchargée vers les services du cluster, définissant ainsi la structure du cluster et la configuration commune. Les Managers ServicePilot et les Bases de données sont ensuite configurés pour accéder aux services du cluster et se voient attribuer le nom du Cluster ainsi que leur ID de nœud au sein du cluster.