Utilizzare i seguenti requisiti di sistema di SaltStack Config per determinare ciò che il sistema può supportare.
Sistemi operativi supportati per Salt
SaltStack Config viene eseguito in Salt, un motore di gestione della configurazione e dell'automazione open source. Per iniziare a utilizzare SaltStack Config per la gestione della configurazione, è inoltre necessario installare ed eseguire il servizio dei minion Salt in qualsiasi nodo che si intende gestire utilizzando SaltStack 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 SaltStack Config
L'architettura di SaltStack Config è stata progettata in modo da essere supportata in:
- RedHat 7.4 - 7.9 (RHEL 7)
- CentOS 7 (CentOS7)
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-12.el7.x86_64.rpm
- openssl-libs-1.0.2k-12.el7.x86_64.rpm
Definizione dell'architettura dei minion
Nel contesto di SaltStack Config, un minion si riferisce in genere a un nodo dell'ambiente di produzione che si connette a e viene gestito da SaltStack 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 SaltStack 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 SaltStack 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 SaltStack 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: SaltStack Config utilizza il termine "processi" per fare riferimento a tutti i comandi, le attività e le operazioni eseguiti da SaltStack Config. Ogni processo invia il proprio output a SaltStack 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. È inoltre utile per archiviare dati non segreti che non si desidera inserire direttamente nei file di stato, ad esempio i dati di configurazione. La quantità di dati archiviati nel Salt Master (e successivamente accessibili per i minion in base alle esigenze) può influire sulle esigenze di memoria e di storage dei dati.
- 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 SaltStack 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: quando si valuta l'importanza di SaltStack Config nell'ambiente, è necessario chiedersi quanto sarebbe grave un'interruzione di SaltStack Config per la propria azienda. Se rimanesse inattivo per un'ora o più tempo, causerebbe problemi gravi? Se la risposta è affermativa, potrebbe essere necessario implementare l'alta disponibilità nell'architettura di sistema di SaltStack Config.
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 SaltStack 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.
