Utilice estos requisitos del sistema de SaltStack Config para determinar lo que su sistema puede admitir.

Sistemas operativos compatibles con Salt

SaltStack Config se ejecuta en Salt, un motor de administración de la configuración y la automatización de código abierto. Para comenzar a utilizar SaltStack Config para la administración de la configuración, también debe instalar y ejecutar el servicio de minion de Salt en cualquier nodo que tenga previsto administrar mediante SaltStack Config.

Salt está diseñado para ser independiente del sistema operativo y puede administrar los nodos de la mayoría de los sistemas operativos estándar. Para obtener una lista de los sistemas operativos de Salt admitidos, consulte Compatibilidad con la plataforma de Salt.

Sistemas operativos compatibles con SaltStack Config

La arquitectura de SaltStack Config está diseñada para funcionar mejor en uno los siguientes sistemas operativos:

  • RedHat 7.4 - 7.9 (RHEL 7)
  • CentOS 7 (CentOS7)
Importante:

Si su versión de RHEL 7 es anterior a 7.4, debe actualizar la versión de OpenSSL a la versión 1.0.2k antes de ejecutar el script de instalación. Si esta versión no está disponible a través de una actualización de yum o su servidor no tiene acceso directo a Internet, recupere los siguientes paquetes de RedHat o de su reflejo público preferido:

  • openssl-1.0.2k-12.el7.x86_64.rpm
  • openssl-libs-1.0.2k-12.el7.x86_64.rpm

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

Calcule la cantidad de minions y maestros de Salt

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.

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

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.