La arquitectura del sistema necesaria para instalar SaltStack Config depende de dos factores principales: 1) el método de instalación que utiliza para implementar SaltStack Config y 2) el rendimiento del entorno, es decir, la cantidad de trabajo que se realizará en el sistema mediante SaltStack Config.
Antes de comenzar
Para poder realizar una evaluación precisa de las necesidades de la arquitectura del sistema, primero debe asegurarse de estar familiarizado con lo siguiente:
- Los dos métodos de instalación disponibles para SaltStack Config
- Los cuatro componentes básicos de la arquitectura de SaltStack Config SaltStack (RaaS, el maestro de Salt, PostgreSQL y Redis)
Consulte Instalación y configuración de SaltStack Config para obtener una descripción general de estos conceptos, incluida una descripción general del proceso de instalación. Consulte también ¿Qué escenario de instalación se debe utilizar? para obtener instrucciones sobre cómo seleccionar un escenario de instalación.
SaltStack Config funciona con Salt, un motor de administración de la configuración y la automatización de código abierto. Si no está tan familiarizado con los términos clave que se utilizan en Salt (como el maestro de Salt y el minion de Salt), consulte Arquitectura del sistema de Salt para obtener más información.
Determinación de la arquitectura de minions
En el contexto de SaltStack Config, un minion generalmente hace referencia a un nodo en el entorno de producción que se conecta con SaltStack Config, el cual lo administra a través de uno o varios maestros de Salt.
Salt está diseñado para funcionar con cualquier sistema operativo que pueda estar ejecutándose en un minion. Además de los sistemas operativos estándar (Linux, Windows, MacOS), Salt proporciona software de minion especializado (generalmente denominado "minions nativos") para sistemas operativos que son exclusivos de varios dispositivos de red, como Arista, Juniper, AIX y Solaris.
En esta tabla se enumeran los requisitos mínimos de memoria para el servicio de minion de Salt por sistemas operativos:
| Sistema operativo | Requisitos mínimos de memoria |
|---|---|
| Minion de AIX | 512 MB de RAM |
| Minion de MacOS | 4 GB de RAM |
| Minion de Linux | 512 MB de RAM |
| Minion de Windows | 4 GB de RAM |
| Otros dispositivos de red, incluidos los minions de proxy | 40 MB de RAM por dispositivo controlado |
Determinar el escenario de instalación
Consulte ¿Qué escenario de instalación se debe utilizar? para obtener instrucciones sobre cómo seleccionar un escenario de instalación. Si no está seguro de cuál es el método de instalación más adecuado para su sistema, se recomienda realizar la instalación estándar. No se recomienda el método de instalación de Lifecycle Manager para sistemas de grado de producción con más de 1000 nodos.
Si elige una instalación de Lifecycle Manager, solo necesita un nodo y la siguiente arquitectura del sistema:
| Hardware | Hasta 1.000 nodos (minions) |
|---|---|
| Núcleos | 16 núcleos de CPU |
| RAM | 32 GB de RAM |
| Espacio de disco | 260 GB de espacio libre como mínimo |
En el resto de esta guía se explicarán las necesidades de arquitectura para el escenario de instalación estándar.
Calcular la cantidad de minions de Salt que administrará
Aunque el rendimiento del sistema es difícil de medir antes de la instalación, puede estimar sus necesidades en función de la cantidad de minions (nodos) del sistema que administrará SaltStack Config. En la última sección de esta guía se proporcionan mediciones adicionales para determinar el rendimiento del sistema.
A medida que incrementa la cantidad de minion de Salt que administra SaltStack Config, es posible que deba aumentar la arquitectura del sistema para estar a la par.
Calcular la cantidad de maestros de Salt que necesita
En esta tabla se enumera la cantidad recomendada de maestros de Salt que podría necesitar en función de la cantidad de minions (nodos) de Salt administrados en el sistema:
| Minions | Maestros de Salt (16 CPU/16 GB) |
|---|---|
| 5.000 | 1 |
| 10.000 | 2 |
| 15 000 | 3 |
| 20.000 | 4 |
| 25.000 | 5 |
| 30 000 | 6 |
| 35 000 | 7 |
| 40.000 | 8 |
| 45 000 | 9 |
| 50.000 | 10 |
| 55 000 | 11 |
| 60 000 | 12 |
| 65 000 | 13 |
| 70.000 | 14 |
| 75 000 | 15 |
| 80 000 | 16 |
| 85 000 | 17 |
| 90 000 | 18 |
| 95 000 | 19 |
| 100.000 | 20 |
En este documento se describe la arquitectura local de SaltStack Config. La nube de SaltStack Config actualmente solo puede ejecutar un maestro de Salt, lo que significa que está limitada a menos de 20 000 minions.
Calcule el número de nodos de RaaS que necesita
En esta tabla se enumera la cantidad recomendada de nodos de RaaS que podría necesitar en función de la cantidad de minions (nodos) de Salt administrados en el sistema:
| Minions | Nodos de RaaS con 16 CPU/16 GB | Nodos de RaaS con 32 CPU/32 GB |
|---|---|---|
| 5.000 | 1 | |
| 10.000 | 1 | |
| 15 000 | 1 | |
| 20.000 | 1 | |
| 25.000 | 2 | |
| 30 000 | 2 | |
| 35 000 | 2 | |
| 40.000 | 2 | |
| 45 000 | 1 | 1 |
| 50.000 | 1 | 1 |
| 55 000 | 1 | 1 |
| 60 000 | 1 | 1 |
| 65 000 | 2 | |
| 70.000 | 2 | |
| 75 000 | 2 | |
| 80 000 | 2 | |
| 85 000 | 1 | 2 |
| 90 000 | 1 | 2 |
| 95 000 | 1 | 2 |
| 100.000 | 1 | 2 |
Calcule el número de nodos de PostgreSQL que necesita
En las siguientes dos tablas se muestra la cantidad recomendada de nodos de base de datos de PostgreSQL que es posible que necesite en función de la cantidad de minions (nodos) de Salt administrados en el sistema:
| Minions | Nodos de PostgreSQL con 8 CPU/8 GB | Nodos de PostgreSQL con 16 CPU/16 GB | Nodos de PostgreSQL con 24 CPU/24 GB | Nodos de PostgreSQL con 32 CPU/32 GB |
|---|---|---|---|---|
| 5.000 | 1 | |||
| 10.000 | 1 | |||
| 15 000 | 1 | |||
| 20.000 | 1 | |||
| 25.000 | 1 | |||
| 30 000 | 1 | |||
| 35 000 | 1 | |||
| 40.000 | 1 | |||
| 45 000 | 1 | |||
| 50.000 | 1 | |||
| 55 000 | 1 | |||
| 60 000 | 1 |
| Minions | Nodos de PostgreSQL con 48 CPU/48 GB | Nodos de PostgreSQL con 56 CPU/56 GB | Nodos de PostgreSQL con 64 CPU/64 GB |
|---|---|---|---|
| 65 000 | 1 | ||
| 70.000 | 1 | ||
| 75 000 | 1 | ||
| 80 000 | 1 | ||
| 85 000 | 1 | ||
| 90 000 | 1 | ||
| 95 000 | 1 | ||
| 100.000 | 1 |
Calcular la cantidad de nodos de Redis que necesita
En las siguientes dos tablas se muestra la cantidad recomendada de nodos de base de datos de Redis que es posible que necesite en función de la cantidad de minions (nodos) de Salt administrados en el sistema:
| Minions | Nodos de Redis con 4 CPU/4 GB | Nodos de Redis con 8 CPU/8 GB | Nodos de Redis con 12 CPU/12 GB |
|---|---|---|---|
| 5.000 | 1 | ||
| 10.000 | 1 | ||
| 15 000 | 1 | ||
| 20.000 | 1 | ||
| 25.000 | 1 | ||
| 30 000 | 1 | ||
| 35 000 | 1 | ||
| 40.000 | 1 | ||
| 45 000 | 1 | ||
| 50.000 | 1 | ||
| 55 000 | 1 | ||
| 60 000 | 1 |
| Minions | Nodos de Redis con 16 CPU/16 GB | Nodos de Redis con 20 CPU/20 GB |
|---|---|---|
| 65 000 | 1 | |
| 70.000 | 1 | |
| 75 000 | 1 | |
| 80 000 | 1 | |
| 85 000 | 1 | |
| 90 000 | 1 | |
| 95 000 | 1 | |
| 100.000 | 1 |
Optimizar la arquitectura después de la instalación en función del rendimiento
Después de completar la instalación de SaltStack Config, puede utilizar métricas de supervisión del sistema para determinar mejor el rendimiento y las necesidades de arquitectura del sistema.
Al determinar qué supervisar, tenga en cuenta estos factores:
- Cantidad de tráfico en el sistema de eventos: el sistema de eventos (también denominado "bus de eventos") se utiliza para la comunicación entre procesos tanto por parte del maestro de Salt como de los minions de Salt. Si el bus de eventos está muy ocupado, considere la posibilidad de aumentar sus asignaciones de memoria.
- Resultados del trabajo por hora: SaltStack Config utiliza el término "trabajos" para hacer referencia a cada uno de los comandos, las tareas y las operaciones realizados por SaltStack Config. Cada trabajo envía sus resultados a SaltStack Config para fines de generación de informes y recopilación de datos. La cantidad de trabajos que devuelve el sistema en una hora determinada puede afectar sus necesidades de arquitectura.
- Cantidad de datos del pilar: los datos del pilar son datos que se deben almacenar en el maestro de Salt. El pilar se utiliza principalmente para almacenar secretos u otros datos altamente confidenciales, como credenciales de cuenta, claves criptográficas o contraseñas. El pilar también es útil para almacenar datos que no son secretos, pero que no desea colocar directamente en sus archivos de estado, como los datos de configuración. La cantidad de datos que se almacenan en el maestro de Salt (y a los que acceden posteriormente los minions según sea necesario) puede afectar las necesidades de memoria y almacenamiento de datos.
- Cantidad de granos personalizados: los granos se utilizan en Salt para dirigirse a los minions de un comando o un trabajo en particular. Los granos hacen referencia a los datos básicos y las características de cada minion. Salt incluye muchos granos predefinidos. Por ejemplo, puede dirigirse a minions según su sistema operativo, nombre de dominio, dirección IP, kernel, memoria y muchas otras propiedades del sistema. También puede crear datos de Grain personalizados para distinguir un grupo de minions de otro en función de una característica de destino exclusiva en su sistema. La cantidad de granos personalizados que cree puede afectar las necesidades de su arquitectura.
- Cantidad de señales y reactores: el sistema de señales es una herramienta de supervisión que puede escuchar una variedad de procesos del sistema en los minions de Salt. Las señales pueden activar reactores, lo que puede ayudar a implementar un cambio o solucionar un problema. Por ejemplo, si se agota el tiempo de espera de respuesta de un servicio, el sistema puede reiniciar el servicio. Cuando se combinan con los reactores, las señales pueden crear respuestas automatizadas escritas previamente para los problemas de infraestructura y aplicaciones. Los reactores amplían Salt con respuestas automatizadas mediante estados de corrección escritos previamente. Si el sistema tiene señales y reactores que se activan regularmente, esto podría aumentar las necesidades de arquitectura del sistema.
- Necesidades de tamaño de disco: es posible que deba aumentar el tamaño del disco en función de la cantidad de minions que se administran y de los datos que necesita conservar en el almacenamiento cada año. Por ejemplo, si tiene un sistema de alto rendimiento y su sistema se encuentra en un sector con regulaciones estrictas que requiere entre 7 y 8 años de conservación de los datos, es posible que requiera un mayor tamaño de disco y capacidad de almacenamiento.
- Ubicación geográfica y distancia entre componentes: es posible que experimente problemas si hay una latencia de 65 ms o más entre el maestro de Salt y el servidor que ejecuta SaltStack Config (RaaS). Afortunadamente, Salt es menos sensible a la latencia entre el minion de Salt y el maestro de Salt. Al colocar estos componentes, tenga en cuenta que es mejor ubicar el maestro cerca de RaaS y el minion más lejos si es necesario.
- Operaciones fundamentales para el negocio: cuando evalúe qué tan esencial es SaltStack Config en su entorno, pregúntese qué tan grave sería para su negocio el impacto de una interrupción de SaltStack Config. Si estuviera inactivo durante una hora o más, ¿causaría un impacto grave? Si es así, es posible que deba diseñar necesidades de alta disponibilidad en la arquitectura del sistema de SaltStack Config.
En función de estos factores, considere aumentar de forma incremental los recursos y supervisar el impacto en el rendimiento del sistema. Por ejemplo, aumentar las asignaciones de memoria en 4 GB de RAM con 4 CPU.
En la siguiente imagen se muestra un ejemplo de un diseño de arquitectura de alta disponibilidad de SaltStack Config:
Como se muestra en esta imagen, muchos sistemas de alta disponibilidad se conectan a varios maestros de Salt. Los sistemas de alta disponibilidad también suelen generar redundancia en la base de datos de PostgreSQL y en las bases de datos de Redis para que una pueda conmutar por error a otra. Tenga en cuenta que las soluciones de alta disponibilidad actuales para PostgreSQL y Redis solo admiten conmutaciones por error manuales.
