L'architecture système requise pour installer SaltStack Config dépend de deux facteurs principaux : 1) la méthode d'installation que vous utilisez pour déployer SaltStack Config et 2) le débit de votre environnement, ce qui signifie la quantité de travail que vous effectuerez sur votre système à l'aide de SaltStack Config.
Avant de commencer
Pour effectuer une évaluation précise de vos besoins en architecture système, vous devez d'abord vous assurer que vous connaissez bien les éléments suivants :
- Les deux méthodes d'installation disponibles pour SaltStack Config
- Les quatre composants de base de l'architecture SaltStack SaltStack Config (RaaS, le master Salt, PostgreSQL et Redis)
Reportez-vous à Installation et configuration de SaltStack Config pour obtenir un aperçu de ces concepts, y compris un aperçu général du processus d'installation. Reportez-vous également à Quelle scénario d'installation devez-vous utiliser ? pour obtenir des conseils sur la sélection d'un scénario d'installation.
SaltStack Config sur site est alimenté par Salt, un moteur de gestion d'automatisation et de configuration open source. Si vous connaissez mal les termes clés utilisés dans Salt (tels que master et minion Salt), reportez-vous à Architecture du système Salt pour obtenir un complément d'informations.
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é |
Déterminer votre scénario d’installation
Reportez-vous à Quelle scénario d'installation devez-vous utiliser ? pour obtenir des conseils sur la sélection d'un scénario d'installation. En cas de doute sur la méthode d'installation la plus efficace pour votre système, l'installation standard est recommandée. La méthode d'installation de Lifecycle Manager n'est pas recommandée pour les systèmes de niveau production comptant plus de 1 000 nœuds.
Si vous choisissez une installation Lifecycle Manager, elle ne nécessite qu’un seul nœud et a besoin de l’architecture système suivante :
| Matériel | Jusqu'à 1 000 nœuds (minions) |
|---|---|
| Cœurs | 8 cœurs de CPU |
| RAM | 16 Go de RAM |
| Espace disque | Au moins 40 Go d'espace libre |
Le reste de ce guide vous expliquera les besoins en architecture du scénario d'installation standard.
Estimer le nombre de minions Salt que vous allez gérer
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.
Estimer le nombre de masters Salt dont vous avez besoin
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 |
Ce document décrit l'architecture SaltStack Config sur site. Actuellement, SaltStack Config Cloud ne peut exécuter qu'un seul master Salt, ce qui signifie qu'il est limité à moins de 20 000 minions.
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.
