Use estes requisitos de sistema do SaltStack Config para determinar o que é compatível com o seu sistema.
Sistemas operacionais com suporte para o Sal
O SaltStack Config é executado no Salt, um mecanismo de gerenciamento de configuração e automação de código aberto. Para começar a usar o SaltStack Config para gerenciamento de configuração, você também precisa instalar e executar o serviço de subordinados Salt em todos os nós que você pretende gerenciar usando o SaltStack Config.
O próprio Salt foi projetado para ser independente do sistema operacional e pode gerenciar os nós da maioria dos sistemas operacionais padrão. Para obter uma lista de sistemas operacionais Salt com suporte, consulte Suporte à plataforma Salt.
Sistemas operacionais com suporte para o SaltStack Config
A arquitetura do SaltStack Config é melhor projetada para operar em:
- RHEL 7.4–7.9
- RHEL 8
- RHEL 9
- CentOS 7
Se a sua versão do RHEL 7 for inferior a 7.4, você deverá atualizar sua versão do OpenSSL para 1.0.2k antes de executar o script de instalação. Se essa versão não estiver disponível para você por meio de uma atualização do yum ou se o seu servidor não tiver acesso direto à Internet, recupere os seguintes pacotes do RedHat ou do seu espelho público preferido:
- openssl-1.0.2k-12.el7.x86_64.rpm
- openssl-libs-1.0.2k-12.el7.x86_64.rpm
Determinando a arquitetura dos subordinados
No contexto do SaltStack Config, um subordinado geralmente se refere a um nó no seu ambiente de produção que se conecta ao SaltStack Config e é gerenciado por ele por meio de um ou mais mestres Salt.
O Salt foi projetado para funcionar com qualquer sistema operacional que possa estar em execução em um subordinado. Além dos sistemas operacionais padrão (Linux, Windows, MacOS), o Salt fornece softwares de subordinados especializados (geralmente chamados de "subordinados nativos") para sistemas operacionais exclusivos de vários dispositivos de rede, como Arista, Juniper, AIX e Solaris.
Esta tabela lista os requisitos mínimos de memória para o serviço de subordinados Salt por sistema operacional:
| Sistema operacional | Requisitos mínimos de memória |
|---|---|
| Subordinado AIX | 512 MB de RAM |
| Subordinado MacOS | 4 GB de RAM |
| Subordinado Linux | 512 MB de RAM |
| Subordinado Windows | 4 GB de RAM |
| Outros dispositivos de rede, incluindo subordinados proxy | 40 MB de RAM por dispositivo controlado |
Estime o número de mestre e subordinados Salt
Embora a taxa de transferência do seu sistema seja difícil de ser medida antes da instalação, você pode estimar suas necessidades com base no número de subordinados (nós) no seu sistema que serão gerenciados pelo SaltStack Config. A última seção deste guia fornece medidas adicionais para determinar o rendimento do seu sistema.
À medida que você colocar mais subordinados Salt sob o gerenciamento do SaltStack Config, talvez seja necessário aumentar a arquitetura do sistema para corresponder às alterações.
Essa tabela lista o número recomendado de mestres Salt que podem ser necessários com base no número de subordinados Salt (nós) gerenciados no seu sistema:
| Subordinados | Mestres Salt (16 CPUs/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 |
Estimar o número de nós RaaS necessários
Essa tabela lista o número recomendado de nós RaaS que podem ser necessários com base no número de subordinados Salt (nós) gerenciados no seu sistema:
| Subordinados | Nós RaaS com 16 CPUs/16 GB | Nós RaaS com 32 CPUs/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 |
Estimar o número de nós PostgreSQL necessários
As duas próximas tabelas listam o número recomendado de nós do banco de dados PostgreSQL que podem ser necessários de acordo com o número de subordinados Salt (nós) gerenciados no seu sistema:
| Subordinados | Nós PostgreSQL com 8 CPUs/8 GB | Nós PostgreSQL com 16 CPUs/16 GB | Nós PostgreSQL com 24 CPUs/24 GB | Nós PostgreSQL com 32 CPUs/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 |
| Subordinados | Nós PostgreSQL com 48 CPUs/48 GB | Nós PostgreSQL com 56 CPUs/56 GB | Nós PostgreSQL com 64 CPUs/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 |
Estimar o número de nós Redis necessários
As duas próximas tabelas listam o número recomendado de nós de banco de dados Redis que podem ser necessários de acordo com o número de subordinados Salt (nós) gerenciados no seu sistema:
| Subordinados | Nós Redis com 4 CPUs/4 GB | Nós Redis com 8 CPUs/8 GB | Nós Redis com 12 CPUs/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 |
| Subordinados | Nós Redis com 16 CPUs/16 GB | Nós Redis com 20 CPUs/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 |
Otimizar sua arquitetura após a instalação com base no rendimento
Após concluir a instalação do SaltStack Config, você pode usar métricas de monitoramento do sistema para determinar melhor o rendimento e as necessidades de arquitetura do seu sistema.
Ao determinar o que monitorar, considere estes fatores:
- Quantidade de tráfego no sistema de eventos - O sistema de eventos (também conhecido como "barramento de eventos") é usado para comunicação interprocessos pelo mestre Salt e pelos subordinados Salt. Se o seu barramento de eventos estiver muito ocupado, considere aumentar suas alocações de memória.
- Retornos de trabalho por hora - O SaltStack Config usa o termo "trabalhos" para se referir a cada um dos comandos, tarefas e operações executados pelo SaltStack Config. Cada trabalho envia sua saída ao SaltStack Config para fins de relatório e coleta de dados. O número de eventos que o seu sistema produz em uma determinada hora pode afetar suas necessidades de arquitetura.
- Quantidade de dados de pilares - Dados de pilares são dados que devem ser armazenados no mestre Salt. O pilar é usado principalmente para armazenar segredos ou outros dados altamente confidenciais, como credenciais de conta, chaves criptográficas ou senhas. A quantidade de dados que estão sendo armazenados no seu Mestre Salt (e, posteriormente, acessados por subordinados, conforme necessário) pode afetar suas necessidades de memória e armazenamento de dados.
- Dados de configuração - Mapear arquivos: esses arquivos são úteis para armazenar dados não confidenciais que você não deseja colocar diretamente nos seus arquivos de estado. Ao contrário de dados de Pilares, esses arquivos de mapa não colocam pressão adicional sobre os mestres Salt.
- Quantidade de grãos personalizados - Grãos são usados no Salt para direcionar os subordinados para um determinado trabalho ou comando. Grãos referem-se aos dados e às características básicas de cada subordinado. O Salt vem com muitos grãos pré-criados. Por exemplo, você pode direcionar subordinados por sistema operacional, nome de domínio, endereço IP, kernel, memória e muitas outras propriedades do sistema. Você também pode criar dados de grains personalizados para distinguir um grupo de subordinados de outro com base em uma característica que você define como destino exclusivamente no seu sistema. O número de grãos personalizados que você cria pode afetar suas necessidades de arquitetura.
- Número de beacons e reatores - O sistema de beacons é uma ferramenta de monitoramento que pode escutar uma variedade de processos do sistema em subordinados Salt. Beacons podem disparar reatores, que então podem ajudar a implementar uma alteração ou solucionar um problema. Por exemplo, se a resposta de um serviço atingir o tempo limite, o sistema de reatores poderá reiniciar esse serviço. Quando combinados com reatores, os beacons podem criar respostas pré-gravadas automatizadas para problemas de infraestrutura e aplicativos. Os reatores expandem o Salt com respostas automatizadas usando estados de correção pré-gravados. Se o seu sistema tiver beacons e reatores que são ativados regularmente, isso poderá aumentar as necessidades de arquitetura do sistema.
- Necessidades de tamanho do disco - Talvez seja necessário aumentar o tamanho do disco com base no número de subordinados que estão sendo gerenciados e na reserva de dados de cada ano que você precisa manter em armazenamento. Por exemplo, se você tem um sistema de alto rendimento e esse sistema está em um setor altamente regulamentado que exige de 7 a 8 anos de retenção de dados, isso pode exigir maior tamanho de disco e capacidade de armazenamento.
- Operações essenciais aos negócios - Ao avaliar como o SaltStack Config é crítico para os negócios no seu ambiente, pergunte a si mesmo qual seria a gravidade do impacto de uma falha do SaltStack Config para os seus negócios. Se o disco estivesse inativo por uma hora ou mais, isso causaria um grave impacto? Em caso afirmativo, pode ser necessário projetar necessidades de alta disponibilidade na sua arquitetura de sistema do SaltStack Config.
Com base nesses fatores, considere aumentar incrementalmente seus recursos e monitorar o impacto sobre o desempenho do seu sistema. Por exemplo, aumentar suas alocações de memória em 4 GB de RAM com 4 CPUs.
A imagem a seguir mostra um exemplo de um projeto de arquitetura do SaltStack Config alta disponibilidade:
Como essa imagem ilustra, muitos sistemas de alta disponibilidade se conectam a vários mestres Salt. Os sistemas de alta disponibilidade também costumam criar redundância no banco de dados PostgreSQL e nos bancos de dados Redis para que um possa fazer failover para outro. Tenha em mente que as soluções de alta disponibilidade atuais para PostgreSQL e Redis oferecem suporte apenas a failovers manuais.
