L'architettura di sistema necessaria per installare SaltStack Config dipende da due fattori principali: 1) il metodo di installazione utilizzato per distribuire SaltStack Config e 2) la velocità effettiva dell'ambiente, ovvero la quantità di lavoro che verrà eseguito nel sistema tramite SaltStack Config.
Prima di iniziare
Per eseguire una valutazione accurata delle esigenze dell'architettura di sistema, è innanzitutto necessario assicurarsi di conoscere:
- I due metodi di installazione disponibili per SaltStack Config
- I quattro componenti di base dell'architettura SaltStack di SaltStack Config (RaaS, Salt Master, PostgreSQL e Redis)
Vedere Installazione e configurazione di SaltStack Config per una panoramica di questi concetti, inclusa una panoramica generale del processo di installazione. Vedere anche Quale scenario di installazione è necessario utilizzare? per istruzioni sulla selezione di uno scenario di installazione.
SaltStack Config viene eseguito da Salt, un motore di gestione della configurazione e dell'automazione open source. Se non si ha familiarità con i termini chiave utilizzati in Salt (ad esempio Salt Master e minion di Salt), consultare Architettura del sistema Salt per ulteriori informazioni.
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 |
Definizione dello scenario di installazione
Consultare Quale scenario di installazione è necessario utilizzare? per istruzioni sulla selezione di uno scenario di installazione. Se non si è certi del metodo di installazione più adatto al proprio sistema, è consigliabile utilizzare l'installazione standard. Il metodo di installazione di Lifecycle Manager non è consigliato per i sistemi a livello di produzione con più di 1.000 nodi.
Se si sceglie l'installazione di Lifecycle Manager, richiede un solo nodo e la seguente architettura di sistema:
| Hardware | Fino a 1.000 nodi (minion) |
|---|---|
| Core | 16 core CPU |
| RAM | 32 GB di RAM |
| Spazio su disco | Almeno 260 GB di spazio libero |
La parte rimanente di questa guida spiega le esigenze dell'architettura per lo scenario di installazione standard.
Stima del numero di minion di Salt che verrà gestito
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.
Stima del numero di Salt Master necessari
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 |
Questo documento descrive l'architettura locale di SaltStack Config. SaltStack Config Cloud può attualmente eseguire solo un Salt Master. Ciò significa che non può includere più di 20.000 minion.
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.
