Documentation
Descubre el modo de configuración cero

ServicePilot Clustering y Scaling

A continuación se explica la configuración de ServicePilot Clustering y Scaling para despliegues ServicePilot On Premise.

¿Qué es un clúster de ServicePilot?

La solución ServicePilot puede ser clusterizada por razones de rendimiento o de partición de datos. Para particionar la configuración, la autenticación y los datos, se utiliza la noción de tenant para indicar una instancia independiente de ServicePilot con sus propios usuarios, equipos supervisados y almacén de historial de datos. Los Agentes ServicePilot están asociados a un único tenant.

Un solo Manager y Database ServicePilot en equipo reciente con 8 vCores, 16GB RAM y almacenamiento SSD pueden manejar hasta:

  • 500.000 a 1.000.000 indicadores por minuto
  • de 50.000 a 80.000 objetos
  • 500 a 1.000 Hosts Full-Stack

La solución ServicePilot puede ser clusterizada de varias maneras:

  • Alta disponibilidad: Mediante el despliegue de más Manager y Database ServicePilot, en el mismo cluster, que pueden tomar el relevo en caso de fallo o mantenimiento. Esto no aumenta la capacidad de la solución.
  • Escalado de bases de datos: Al añadir más servicios de Database, uno dedicado a la escritura de datos mientras que otros sólo a la lectura de datos. Se mejora el rendimiento con grandes conjuntos de datos y grandes consultas a la base de datos.
  • Partición y escalado multi-tenants: Desplegando varios clústeres de Managers y Bases de Datos ServicePilot, cada uno con datos separados. Cada tenant puede otorgar derechos diferentes a los usuarios, y el inicio de sesión único funciona entre tenants.
  • Clustering multi-regional: Al desplegar múltiples clústeres de Managers y Bases de Datos ServicePilot geográficamente, los datos recibidos se mantienen dentro de la región del clúster por requisitos legales o de otro tipo. Se puede dar acceso a los usuarios a diferentes regiones con diferentes derechos en cada región con inicio single sign-on automático entre las regiones.

Los datos se reciben de uno o más Agentes ServicePilot que pueden estar conectados directamente a los Managers ServicePilot o a través de Proxies ServicePilot y Equilibradores de carga. El cluster de Managers ServicePilot dirigirá el tráfico de los Agentes ServicePilot a la partición correcta del Manager ServicePilot y del tenant.

Un Cluster ServicePilot proporciona detección de disponibilidad de servicios y un medio para replicar la configuración en toda la solución ServicePilot. Un Cluster ServicePilot requiere 1, 3 o 5 servicios SPCluster. Para alta disponibilidad se necesitan 3 o 5 servicios SPCluster en diferentes servidores. Los servicios SPCluster pueden ser co-alojados con otro software ServicePilot.

Los servicios SPCluster forman un quórum cuando más de la mitad de los servicios SPCluster pueden comunicarse entre sí. Otros servicios de ServicePilot pueden entonces iniciarse y sólo continuarán funcionando mientras se mantenga el quórum.

Una vez configurado el clúster, la Alta disponibilidad y el Escalado de base de datos no requieren más configuración.

Servicio SPCluster

Todos los servicios SPCluster de un cluster requieren el mismo Cluster ID y otras configuraciones. Sin embargo, cada servicio SPCluster necesita ser configurado con un único Node ID. Otros servicios de ServicePilot que hagan uso del cluster utilizarán un Node ID único para el nodo en el que está instalado el servicio. El nodo activo con el número más bajo se considera el Líder.

La comunicación entre los servicios SPCluster y el acceso a los servicios SPCluster desde otros servicios ServicePilot se realiza en el puerto TCP seguro 8980. Sugerimos definir las direcciones IP remotas de todos los servicios de cluster en reglas de firewall.

Para los servicios de cluster de Linux, se utilizan las siguientes variables de entorno:

Variable de entorno Notas
sp_cluster
sp_node_id
sp_cluster_id

Para los servicios de cluster de Windows, se utiliza la ServicePilot Setup Console para establecer la configuración del cluster. El servicio SPCluster puede ser iniciado automáticamente por el Manager ServicePilot de Windows.

Ficheros de configuración del cluster

Una vez que la configuración por nodo ServicePilot Cluster está configurada, la configuración del cluster se gestiona en archivos en el Node ID 1. Estos archivos de configuración del cluster se replican a otros nodos cuando se realiza una recarga de configuración o reinicio en el nodo 1.

WorkFolder Archivo Contenido
cluster.conf Configuración de cluster
servicepilot.conf Configuración de ServicePilot común a todos los nodos e tenants
servicepilotdb.conf Configuración de la base de datos
storage.conf Configuración de almacenamiento

Cada tenant tiene la siguiente configuración:

WorkFolder Archivo Contenido
tenant.conf Configuración por tenant
provisioning.conf Por recursos del tenant
Packages, Pictures Packages e imágenes personalizados para el tenant

Redundancia de Managers ServicePilot

Si múltiples Managers ServicePilot están corriendo con el mismo Cluster ID, entonces el que tenga el Node ID más bajo será el leader y tomará el control. Otros Managers ServicePilot redirigirán el tráfico al leader.

Cada ServicePilot Manager en un cluster requiere una licencia de ServicePilot separada.

Métodos de acceso a los Managers ServicePilot

Los usuarios de ServicePilot con redundancia configurada necesitarán una forma fiable de acceder a la interfaz web de ServicePilot cuando uno de los nodos deje de estar disponible.

Esto puede lograrse con un balanceador de carga que deberá instalarse por separado. Un balanceador de carga puede ser configurado para comprobar la URL /ping.html en cada Manager ServicePilot. Si la respuesta es un código de retorno 302 esto indica que el servicio no es un leader. Un código de retorno 200 indica que el servicio es el leader.

Redundancia de la base de datos ServicePilot

Si varias Databases ServicePilot se están ejecutando con el mismo Cluster ID, entonces la que tenga el Node ID más bajo será el leader y manejará el acceso de lectura/escritura a los archivos de la base de datos. Otros servicios de Database ServicePilot estarán en espera hasta que el antiguo leader ya no esté disponible.

La conmutación por error a Databases ServicePilot en un segundo nodo proporcionará una experiencia degradada, ya que los nuevos datos añadidos al segundo nodo no se replicarán en el primer nodo. Cuando se restablezca el servicio en el primer nodo, cabe esperar un vacío en los datos históricos.

Alta disponibilidad de la base de datos con almacenamiento compartido

Si los nodos que contienen los servicios Database ServicePilot comparten un archivo común, la WorkFolder de ServicePilot puede colocarse en este dispositivo. Esto permite el almacenamiento común de datos históricos.

Las Databases ServicePilot que corren con el mismo Cluster ID pueden ser configuradas para que la que tenga el Node ID más bajo sea la leader y maneje el acceso de lectura/escritura a los archivos de la base de datos. Otros servicios de Database ServicePilot con el mismo Cluster ID pueden proporcionar acceso de sólo lectura a los archivos de la base de datos para mejorar el rendimiento.

Tenga en cuenta que el rendimiento del almacenamiento debe especificarse con un rendimiento equivalente al almacenamiento SSD local.

Alta disponibilidad

Una configuración mínima de ServicePilot Cluster consiste en:

  • 3 servicios SPCluster
  • 2 servicios SPManager
  • 2 servicios SPDB

Cada nodo debe estar en una zona de disponibilidad separada en el centro de datos. Esta configuración proporcionará redundancia en caso de que un nodo no esté disponible o no se pueda acceder a él.

Variable de entorno común Notas
sp_cluster https://spus1.company.com:8980|https://spus2.company.com:8980|https://spus3.company.com:8980
Node Servicios configurados sp_node_id sp_cluster_id
SP1 SPCluster,SPManager,SPDB 1 USA
SP2 SPCluster,SPManager,SPDB 2 USA
SP3 SPCluster 3 USA

Escalado de la base de datos

Para escalar el rendimiento de la base de datos, configura un segundo nodo con un servicio Database ServicePilot y un almacenamiento de archivos común entre los servidores para los archivos de la base de datos.

Variable de entorno común Notas
sp_cluster https://spus1.company.com:8980
Node Servicios configurados sp_node_id sp_cluster_id
SP1 SPCluster,SPManager,SPDB 1 USA
SP2 SPDB 2 USA

Partición y escalado multi-tenants

Para particionar o escalar una solución ServicePilot cree un cluster de Managers ServicePilot y de Databases ServicePilot independientes con un mínimo de 3 servicios SPCluster.

Los Node IDs son únicos para cada nodo entre todos los nodos que utilicen los mismos servicios SPCluster independientemente del Cluster ID al que pertenezcan.

|Node|Servicios configurados|sp_node_id|sp_cluster_id|
|--|--|
|sp_cluster|https://sp1.company.com:8980|https://sp2.company.com:8980|https://sp3.company.com:8980|

Node Servicios configurados 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-regional

Los servicios SPCluster, una vez desplegados, pueden ser utilizados por varios clusters de Managers ServicePilot y de Databases ServicePilot distintos. En este escenario, cada cluster separado de servicios redundantes es definido por su propio Cluster ID.

Los Managers ServicePilot en clusters separados soportan single sign-on, lo que significa que si un usuario inicia sesión en un Manager ServicePilot en un cluster, puede abrir páginas web en Managers ServicePilot en otros clusters sin tener que iniciar sesión de nuevo siempre y cuando el ID del usuario esté definido en el otro cluster.

Variable de entorno común Notas
sp_cluster https://spus1.company.com:8980|https://speu3.company.com:8980|https://spaz5.company.com:8980
Node Servicios configurados 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