Utilizzare i seguenti requisiti di sistema di Automation Config per determinare ciò che il sistema può supportare.

Sistemi operativi supportati per Salt

Automation Config viene eseguito in Salt, un motore di gestione della configurazione e dell'automazione open source. Per iniziare a utilizzare Automation Config per la gestione della configurazione, è inoltre necessario installare ed eseguire il servizio dei minion Salt in qualsiasi nodo che si intende gestire utilizzando Automation Config.

Salt è progettato per essere indipendente dal sistema operativo e può gestire i nodi della maggior parte dei sistemi operativi standard. Per un elenco dei sistemi operativi supportati da Salt, vedere Supporto della piattaforma Salt.

Sistemi operativi supportati per Automation Config

L'architettura di Automation Config è stata progettata in modo da essere supportata in:

  • RHEL 7.4-7.9
  • RHEL 8
  • RHEL 9
  • Photon
Importante:

Se la versione di RHEL 7 è precedente alla 7.4, è necessario aggiornare OpenSSL alla versione 1.0.2k prima di eseguire lo script di installazione. Se questa versione non è disponibile tramite un aggiornamento yum o il server non dispone di accesso diretto a Internet, recuperare i seguenti pacchetti da RedHat o dal mirror pubblico preferito:

  • openssl-1.0.2k-26.rpm
  • openssl-libs-1.0.2k-26.rpm

Sistemi operativi aggiuntivi supportati

Automation Config supporta anche i seguenti sistemi operativi, anche se non è consigliabile utilizzarli:

  • Oracle Linux 7
  • SUSE Linux Enterprise Server 15 (SLES 15)
  • SUSE Linux Enterprise Server 12 (SLES 12)

L'installazione di Automation Config in questi sistemi operativi richiede un metodo di installazione manuale che dovrebbe essere completato solo con l'aiuto di un esperto di Automation Config.

Definizione dell'architettura dei minion

Nel contesto di Automation Config, un minion si riferisce in genere a un nodo dell'ambiente di produzione che si connette a e viene gestito da Automation Config tramite uno o più Salt Master.

Salt è progettato per funzionare con qualsiasi sistema operativo in esecuzione in un minion. Oltre ai sistemi operativi standard (Linux, Windows, MacOS), Salt fornisce software minion specializzati (in genere denominati "minion nativi") per sistemi operativi che sono univoci per vari dispositivi di rete come Arista, Juniper, AIX e Solaris.

Nella tabella sono elencati i requisiti di memoria minimi per il servizio minion di Salt in base ai sistemi operativi:

Sistema operativo Requisiti di memoria minimi
Minion AIX 512 MB di RAM
Minion MacOS 4 GB di RAM
Minion Linux 512 MB di RAM
Minion Windows 4 GB di RAM
Altri dispositivi di rete, inclusi i minion proxy 40 MB di RAM per dispositivo controllato

Stima del numero di Salt Master e minion di Salt

Anche se la velocità effettiva del sistema è difficile da misurare prima dell'installazione, è possibile stimare le esigenze in base al numero di minion (nodi) nel sistema che verranno gestiti da Automation Config. L'ultima sezione di questa guida fornisce misure aggiuntive per determinare la velocità effettiva del sistema.

Man mano che si aggiungono minion di Salt che devono essere gestiti da Automation Config, potrebbe essere necessario ampliare l'architettura di sistema di conseguenza.

In questa tabella viene indicato il numero consigliato di Salt Master che potrebbero essere necessari in base al numero di minion (nodi) Salt gestiti nel sistema:

Minion Salt Master (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

Stima del numero di nodi RaaS necessari

In questa tabella viene indicato il numero consigliato di nodi RaaS che potrebbero essere necessari in base al numero di minion (nodi) Salt gestiti nel sistema:

Minion Nodi RaaS con 16 CPU/16 GB Nodi 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

Stima del numero di nodi PostgreSQL necessari

Nelle due tabelle successive viene elencato il numero consigliato di nodi del database PostgreSQL che potrebbero essere necessari in base al numero di minion (nodi) Salt gestiti nel sistema:

Minion Nodi PostgreSQL con 8 CPU/8 GB Nodi PostgreSQL con 16 CPU/16 GB Nodi PostgreSQL con 24 CPU/24 GB Nodi 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
Minion Nodi PostgreSQL con 48 CPU/48 GB Nodi PostgreSQL con 56 CPU/56 GB Nodi 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

Stima del numero di nodi Redis necessari

Nelle due tabelle successive viene elencato il numero consigliato di nodi del database Redis che potrebbero essere necessari in base al numero di minion (nodi) Salt gestiti nel sistema:

Minion Nodi Redis con 4 CPU/4 GB Nodi Redis con 8 CPU/8 GB Nodi 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
Minion Nodi Redis con 16 CPU/16 GB Nodi 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

Ottimizzazione dell'architettura dopo l'installazione in base alla velocità effettiva

Dopo aver completato l'installazione di Automation Config, è possibile utilizzare le metriche di monitoraggio del sistema per determinare meglio la velocità effettiva del sistema e le esigenze dell'architettura.

Per decidere cosa monitorare, tenere presenti questi fattori:

  • Quantità di traffico nel sistema di gestione degli eventi: il sistema di gestione degli eventi (a volte denominato anche "bus di eventi") viene utilizzato per la comunicazione tra processi da Salt Master e dai minion Salt. Se il bus di eventi è molto occupato, è consigliabile aumentare le allocazioni della memoria.
  • Risultati dei processi all'ora: Automation Config utilizza il termine "processi" per fare riferimento a tutti i comandi, le attività e le operazioni eseguiti da Automation Config. Ogni processo invia il proprio output a Automation Config per la creazione di report e la raccolta di dati. Il numero dei risultati dei processi prodotti dal sistema in una determinata ora può influire sulle esigenze dell'architettura.
  • Quantità di dati del pillar: i dati del pillar devono essere archiviati nel Salt Master. Il pillar viene utilizzato principalmente per archiviare i segreti o altri dati estremamente sensibili, come le credenziali dell'account, le chiavi crittografiche o le password. La quantità di dati archiviati nel Salt Master (e successivamente accessibili dai minion in base alle esigenze) può influire sulle esigenze di memoria e di archiviazione dei dati.
  • Dati configurazione - File mappa - Questi file sono utili per archiviare dati non sensibili che non si desidera inserire direttamente nei file di stato. A differenza dei dati dei pillar, questi file mappa non pongono ulteriore carico di risorse sui Salt Master.
  • Quantità di grani personalizzati: i grani vengono utilizzati in Salt per individuare i minion per un processo o un comando specifico. I grani fanno riferimento ai dati di base e alle caratteristiche di ciascun minion. Salt include molti grani predefiniti. Ad esempio, è possibile selezionare i minion in base a sistema operativo, nome del dominio, indirizzo IP, kernel, memoria e molte altre proprietà del sistema. È inoltre possibile creare dati dei grain personalizzati per distinguere un gruppo di minion da un altro in base a una caratteristica di destinazione univoca nel sistema. Il numero di grani personalizzati creati può influire sulle esigenze dell'architettura.
  • Numero di beacon e reattori: il sistema di beacon è uno strumento di monitoraggio in grado di ascoltare una vasta gamma di processi di sistema nei minion Salt. I beacon possono attivare reattori che possono contribuire a implementare una modifica o risolvere un problema. Ad esempio, se si verifica il timeout della risposta di un servizio, il sistema del reattore può riavviare il servizio. Quando vengono abbinati ai reattori, i beacon possono creare risposte precompilate automatizzate ai problemi relativi all'infrastruttura e all'applicazione. I reattori ampliano Salt con risposte automatiche utilizzando gli stati di correzione precompilati. Se il sistema include beacon e reattori attivati regolarmente, le esigenze dell'architettura di sistema potrebbero aumentare.
  • Dimensioni disco necessarie: potrebbe essere necessario aumentare la dimensione del disco in base al numero di minion da gestire e al numero di anni di dati che devono essere conservati nello storage. Se ad esempio si dispone di un sistema che ha velocità effettiva elevata e appartiene a un settore regolato da molte norme che richiede 7-8 anni di conservazione dei dati, potrebbe essere necessario aumentare le dimensioni del disco e la capacità di storage.
  • Posizione geografica e distanza tra i componenti: potrebbero verificarsi problemi se è presente una latenza di 65 ms o più elevata tra il Salt Master e il server che esegue Automation Config (RaaS). Per fortuna, Salt è meno sensibile alla latenza tra il minion Salt e Salt Master. Quando si posizionano questi componenti, si tenga presente che è meglio collocare il master più vicino a RaaS e il minion più lontano, se necessario.
  • Operazioni business critical: è possibile che si verifichino problemi se è presente una latenza elevata (>200 ms) tra il Salt Master e il server in cui viene eseguito Automation Config (RaaS).

In base a questi fattori, è consigliabile aumentare in modo incrementale le risorse e monitorare l'impatto sulle prestazioni del sistema. Ad esempio, è consigliabile aumentare le allocazioni della memoria di 4 GB di RAM con 4 CPU.

L'immagine seguente illustra un esempio di progettazione dell'architettura ad alta disponibilità di Automation Config:

Come illustrato in questa immagine, molti sistemi ad alta disponibilità si connettono a più Salt Master. I sistemi ad alta disponibilità spesso creano anche ridondanza nel database PostgreSQL e nei database Redis in modo che uno possa eseguire il failover su un altro. Si tenga presente che le soluzioni ad alta disponibilità correnti per PostgreSQL e Redis supportano solo failover manuali.