Utilisez la configuration système requise pour SaltStack Config afin de déterminer ce que votre système peut prendre en charge.
Systèmes d'exploitation pris en charge pour Salt
SaltStack Config s'exécute sur Salt, un moteur de gestion d'automatisation et de configuration open source. Pour commencer à utiliser SaltStack Config pour la gestion de la configuration, vous devez également installer et exécuter le service de minion Salt sur les nœuds que vous souhaitez gérer à l'aide de SaltStack Config.
Salt est lui-même conçu pour ne pas dépendre des systèmes d'exploitation et peut gérer les nœuds de la plupart des systèmes d'exploitation standard. Pour obtenir la liste des systèmes d'exploitation pris en charge par Salt, consultez Prise en charge de la plate-forme Salt.
Systèmes d'exploitation pris en charge pour SaltStack Config
L'architecture de SaltStack Config est conçue pour mieux fonctionner sur :
- RHEL 7.4-7.9
- RHEL 8
- RHEL 9
- CentOS 7
Si votre version de RHEL 7 est antérieure à la version 7.4, vous devrez mettre à jour votre version d'OpenSSL vers la version 1.0.2k avant d'exécution du script d'installation. Si cette version n'est pas disponible via une mise à jour Yum ou si votre serveur ne dispose pas d'un accès direct à Internet, récupérez les packages suivants à partir de RedHat ou de votre miroir public préféré :
- openssl-1.0.2k-12.el7.x86_64.rpm
- openssl-libs-1.0.2k-12.el7.x86_64.rpm
Détermination de l’architecture de minion
Dans le contexte de SaltStack Config, un minion fait généralement référence à un nœud dans votre environnement de production qui se connecte à, et est géré par, SaltStack Config via un ou plusieurs masters Salt.
Salt est conçu pour fonctionner avec n'importe quel système d'exploitation pouvant s'exécuter sur un minion. En plus des systèmes d'exploitation standard (Linux, Windows, MacOS), Salt fournit un logiciel de minion spécialisé (généralement appelé « minions natifs ») pour les systèmes d'exploitation uniques à divers périphériques réseau tels qu'Arista, Juniper, AIX et Solaris.
Ce tableau répertorie la configuration minimale requise de mémoire pour le service de minion Salt par systèmes d’exploitation :
| Système d'exploitation | Configuration minimale requise de la mémoire |
|---|---|
| Minion AIX | 512 Mo de RAM |
| Minion MacOS | 4 Go de RAM |
| Minion Linux | 512 Mo de RAM |
| Minion Windows | 4 Go de RAM |
| Autres périphériques réseau, y compris les minions de proxy | 40 Mo de RAM par périphérique contrôlé |
Estimer le nombre de masters Salt et de minions dont vous avez besoin
Bien que le débit de votre système soit difficile à mesurer avant l'installation, vous pouvez estimer vos besoins en fonction du nombre de minions (nœuds) dans votre système qui seront gérés par SaltStack Config. La dernière section de ce guide fournit des mesures supplémentaires pour déterminer le débit de votre système.
Au fur et à mesure que vous gérez davantage de minions Salt à l'aide de SaltStack Config, vous devrez peut-être augmenter l'architecture de votre système pour qu'elle corresponde.
Ce tableau répertorie le nombre recommandé de masters Salt dont vous pouvez avoir besoin en fonction du nombre de minions Salt gérés (nœuds) dans votre système :
| Minions | Masters Salt (16 CPU/16 Go) |
|---|---|
| 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 |
Estimer le nombre de nœuds RaaS dont vous avez besoin
Ce tableau répertorie le nombre recommandé de nœuds RaaS dont vous pouvez avoir besoin en fonction du nombre de minions Salt (nœuds) gérés dans votre système :
| Minions | Nœuds RaaS avec 16 CPU/16 Go | Nœuds RaaS avec 32 CPU/32 Go |
|---|---|---|
| 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 |
Estimer le nombre de nœuds PostgreSQL dont vous avez besoin
Les deux tableaux suivants répertorient le nombre recommandé de nœuds de base de données PostgreSQL dont vous pouvez avoir besoin en fonction du nombre de minions Salt gérés (nœuds) dans votre système :
| Minions | Nœuds PostgreSQL avec 8 CPU/8 Go | Nœuds PostgreSQL avec 16 CPU/16 Go | Nœuds PostgreSQL avec 24 CPU/24 Go | Nœuds PostgreSQL avec 32 CPU/32 Go |
|---|---|---|---|---|
| 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 | Nœuds PostgreSQL avec 48 CPU/48 Go | Nœuds PostgreSQL avec 56 CPU/56 Go | Nœuds PostgreSQL avec 64 CPU/64 Go |
|---|---|---|---|
| 65 000 | 1 | ||
| 70 000 | 1 | ||
| 75 000 | 1 | ||
| 80 000 | 1 | ||
| 85 000 | 1 | ||
| 90 000 | 1 | ||
| 95 000 | 1 | ||
| 100 000 | 1 |
Estimer le nombre de nœuds Redis dont vous avez besoin
Les deux tableaux suivants répertorient le nombre recommandé de nœuds de base de données Redis dont vous pouvez avoir besoin en fonction du nombre de minions Salt (nœuds) gérés dans votre système :
| Minions | Nœuds Redis avec 4 CPU/4 Go | Nœuds Redis avec 8 CPU/8 Go | Nœuds Redis avec 12 CPU/12 Go |
|---|---|---|---|
| 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 | Nœuds Redis avec 16 CPU/16 Go | Nœuds Redis avec 20 CPU/20 Go |
|---|---|---|
| 65 000 | 1 | |
| 70 000 | 1 | |
| 75 000 | 1 | |
| 80 000 | 1 | |
| 85 000 | 1 | |
| 90 000 | 1 | |
| 95 000 | 1 | |
| 100 000 | 1 |
Optimiser votre architecture après l’installation en fonction du débit
Une fois l'installation de SaltStack Config terminée, vous pouvez utiliser les mesures de surveillance du système pour mieux déterminer le débit et les besoins architecturaux de votre système.
Lorsque vous déterminez ce qu'il faut surveiller, tenez compte des facteurs suivants :
- Quantité de trafic sur le système d'événements : le système d'événements (également appelé « bus d'événements ») est utilisé pour la communication entre processus par le master Salt et les minions Salt. Si le bus d'événements est très occupé, envisagez d'augmenter les allocations de mémoire.
- Retours de tâches par heure : SaltStack Config utilise le terme « tâches » pour faire référence à chacune des commandes, tâches et opérations effectuées par SaltStack Config. Chaque tâche envoie sa sortie à SaltStack Config à des fins de génération de rapports et de collecte de données. Le nombre de retours de tâches que produit le système pendant un temps donné peut avoir une incidence sur les besoins d'architecture.
- Quantité de données de Pillar : les données de Pillar sont des données qui doivent être stockées sur le master Salt. Elle est principalement utilisée pour stocker des secrets ou d'autres données hautement sensibles, telles que les informations d'identification du compte, les clés de chiffrement ou les mots de passe. Pillar est également utile pour stocker des données non secrètes que vous ne souhaitez pas placer directement dans vos fichiers d’état, telles que les données de configuration. La quantité de données stockées sur le master Salt (et accessibles ultérieurement par des minions, si nécessaire) peut avoir une incidence sur les besoins en mémoire et en stockage de données.
- Quantité de grains personnalisés : les grains sont utilisés dans Salt pour cibler les minions pour une tâche ou une commande particulière. Les grains font référence aux données de base et aux caractéristiques de chaque minion. Salt est fourni avec de nombreux grains prédéfinis. Par exemple, vous pouvez cibler des minions en fonction de leur système d’exploitation, nom de domaine, adresse IP, noyau, mémoire et de nombreuses autres propriétés système. Vous pouvez également créer des données de grain personnalisées pour distinguer un groupe de minions d'un autre en fonction d'une caractéristique que vous ciblez de façon unique dans votre système. Le nombre de grains personnalisés que vous créez peut avoir une incidence sur vos besoins en architecture.
- Nombre de balises et de réacteurs : le système de balises est un outil de surveillance qui peut écouter différents processus système sur des minions Salt. Les balises peuvent déclencher des réacteurs, lesquels peuvent ensuite aider à mettre en œuvre une modification ou à résoudre un problème. Par exemple, si le délai de réponse d'un service expire, le système du réacteur peut redémarrer le service. Lorsqu'elles sont associées à des réacteurs, les balises peuvent créer des réponses préécrites automatisées à des problèmes d'infrastructure et d'application. Les réacteurs étendent Salt avec des réponses automatisées utilisant des états de correction préécrits. Si votre système dispose de balises et de réacteurs qui sont activés régulièrement, cela peut augmenter vos besoins en architecture système.
- Besoins en taille de disque : vous devrez peut-être augmenter la taille de votre disque en fonction du nombre de minions gérés et des données que vous devez conserver dans le stockage chaque année. Par exemple, si vous disposez d'un système à haut débit et que votre système se trouve dans un secteur hautement réglementé qui nécessite 7 à 8 ans de rétention des données, cela peut nécessiter une taille de disque et une capacité de stockage plus élevées.
- Emplacement géographique et distance entre les composants : vous pouvez rencontrer des problèmes en cas de latence de 65 ms ou plus entre le master Salt et le serveur qui exécute SaltStack Config (RaaS). Heureusement, Salt est moins sensible à la latence entre le minion Salt et le master Salt. Lors du placement de ces composants, gardez à l'esprit qu'il est préférable de placer le master à proximité de RaaS et le minion plus loin, si nécessaire.
- Opérations stratégiques : lors de l'évaluation du niveau d'importance stratégique de SaltStack Config dans votre environnement, demandez-vous quelle incidence une panne de SaltStack Config aurait sur votre activité. S'il était inactif pendant une heure ou plus, cela pourrait-il avoir une incidence grave ? Si c'est le cas, vous devrez peut-être concevoir des besoins en haute disponibilité dans votre architecture système SaltStack Config.
En fonction de ces facteurs, envisagez d'augmenter progressivement les ressources et de surveiller l'incidence sur les performances de votre système. Par exemple, augmentez les allocations de mémoire de 4 Go de RAM avec 4 CPU.
L'image suivante présente un exemple de conception d'architecture SaltStack Config à haute disponibilité :
Comme l'illustre cette image, de nombreux systèmes haute disponibilité se connectent à plusieurs masters Salt. Les systèmes haute disponibilité génèrent également souvent de la redondance dans la base de données PostgreSQL et les bases de données Redis afin que l'une puisse basculer vers l'autre. Gardez à l’esprit que les solutions de haute disponibilité actuelles pour PostgreSQL et Redis ne prennent en charge que les basculements manuels.
