Clústeres y escalabilidad de ServicePilot

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

Para implementar una configuración de ServicePilot en clúster, es necesario ponerse en contacto con nuestro soporte técnico para asegurarse de que la arquitectura solicitada haya sido validada y sea compatible con ServicePilot.

¿Qué es un clúster 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 ServicePilot y Base de datos 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 ServicePilot Managers y Bases de datos en el mismo clúster, 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 Bases de datos, 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 ServicePilot y Bases de Datos, 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 ServicePilot y Bases de Datos 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.

Requisitos del clúster ServicePilot

La implementación de un clúster ServicePilot requiere una serie de requisitos previos adicionales, además de los requisitos estándar de los servidores ServicePilot:

Servicios del clúster ServicePilot.
Los datos de ServicePilot se almacenan en uno o varios buckets de almacenamiento de objetos compatibles con S3 gestionados por el administrador de ServicePilot.
Definiciones de DNS round-robin para que Managers ServicePilot gestionen la conmutación por error, el reparto de carga y la redirección de los inquilinos alojados en otros Managers ServicePilot.

Servicios SPCluster

Los servicios SPCluster proporcionan detección de disponibilidad y un medio para replicar la configuración en toda la solución ServicePilot. Para lograr una alta disponibilidad, se necesitan 3 o 5 servicios SPCluster en servidores diferentes. Los servicios SPCluster pueden alojarse junto con otros Managers ServicePilot y Bases de Datos.

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 solo seguirán funcionando mientras se mantenga el quórum.

La comunicación entre los servicios SPCluster y el acceso a los servicios SPCluster desde otros servicios de ServicePilot se realiza a través del puerto TCP 8980. Este puerto debe protegerse para permitir únicamente el tráfico procedente de otros servicios SPCluster, así como de los Managers ServicePilot y Bases de datos.

Almacenamiento de objetos de datos S3

El cliente es responsable de proporcionar almacenes de objetos compatibles con S3 a los que puedan acceder todos los nodos de ServicePilot en los que se ejecutan las Bases de datos ServicePilot. Se pueden utilizar diferentes servidores S3, pero solo se puede utilizar un almacén por tenant.

Se pueden enviar copias de los datos a almacenes de objetos S3 secundarios con fines de copia de seguridad.

Configuración de DNS

Cuando los usuarios y los Agentes ServicePilot se conectan por primera vez a los Managers ServicePilot, utilizan un nombre de dominio completo (FQDN) para todo el clúster que hace referencia a todos los Managers ServicePilot del clúster. Cada Manager ServicePilot tendrá también un nombre de dominio completo (FQDN) y una dirección IP únicos.

Ejemplo de configuración de DNS

Certificados

Cada Manager ServicePilot debe responder a las solicitudes iniciales realizadas en el FQDN del clúster, así como en su propio FQDN. Por lo tanto, se requiere un único certificado del Manager ServicePilot que sea válido para el clúster y para todos los FQDN de los nodos. Por ejemplo: sp.company.com, sp1.company.com, sp2.company.com

Managers ServicePilot

Los Managers ServicePilot alojan a los tenants. Solo un Manager ServicePilot atenderá a un tenant a la vez. Si el Manager falla, su responsabilidad pasará a un Manager ServicePilot de respaldo según la configuración del clúster.

Bases de datos de ServicePilot

Solo un servicio de Base de datos de ServicePilot se encarga de escribir los datos de un tenant a la vez. Si el servicio de Base de datos se detiene o falla, una Base de datos de ServicePilot de respaldo se hará cargo de escribir los datos del tenant.

Se pueden configurar varios servicios de Base de datos de ServicePilot para leer los datos de un tenant y compartir la carga de lectura. Los servicios de Base de datos almacenan los datos en caché localmente para acelerar las consultas futuras.

Gestión de la configuración del clúster

Para que ServicePilot funcione en modo clúster, siempre se requiere un quórum de los servicios de ServicePilot Cluster. La configuración inicial se carga en los servicios de Cluster, definiendo la estructura del clúster y la configuración común. A continuación, se configuran los Managers ServicePilot y las Bases de datos para que accedan a los servicios de Cluster, y se les asigna el nombre del Clúster y su ID de nodo dentro del clúster.