A arquitetura do sistema necessária para instalar o SaltStack Config depende de dois fatores principais: 1) o método de instalação que você está usando para implantar o SaltStack Config e 2) o rendimento do seu ambiente, o que significa a quantidade de trabalho que você executará no seu sistema usando o SaltStack Config.
Antes de começar
Para fazer uma avaliação precisa das suas necessidades de arquitetura de sistema, primeiro certifique-se de estar familiarizado com o seguinte:
- Os dois métodos de instalação disponíveis para o SaltStack Config
- Os quatro componentes básicos da arquitetura SaltStack do SaltStack Config (RaaS, o mestre Salt, o PostgreSQL e o Redis)
Consulte Instalando e configurando o SaltStack Config obter uma visão geral desses conceitos, incluindo uma visão geral do processo de instalação. Consulte também Qual cenário de instalação você deve usar? para obter orientação sobre como selecionar um cenário de instalação.
O SaltStack Config é acionado pelo Salt, um mecanismo de gerenciamento de configuração e automação de código aberto. Se você estiver menos familiarizado com os principais termos usados no Salt (como mestre Salt e subordinado Salt), consulte Arquitetura do sistema Salt para obter mais informações.
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 |
Determinar o cenário de instalação
Consulte Qual cenário de instalação você deve usar? para obter orientação sobre como selecionar um cenário de instalação. Se você não tiver certeza de qual método de instalação é melhor para o seu sistema, a instalação padrão é recomendada. O método de instalação do Lifecycle Manager não é recomendado para sistemas de nível de produção com mais de 1.000 nós.
Se você escolher uma instalação do Lifecycle Manager, precisará de apenas um nó e precisará da seguinte arquitetura de sistema:
| Hardware | Até 1.000 nós (subordinados) |
|---|---|
| Núcleos | 8 núcleos de CPU |
| RAM | 16 GB de RAM |
| Espaço em disco | Pelo menos 40 GB de espaço livre |
O restante deste guia explicará as necessidades de arquitetura do cenário de instalação padrão.
Estimar o número de subordinados Salt que você gerenciará
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.
Estimar o número de mestres Salt necessários
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 |
Este documento descreve a arquitetura local do SaltStack Config. No momento, o SaltStack Config Cloud pode executar apenas um mestre Salt, o que significa que ele está limitada a menos de 20.000 subordinados.
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 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 contas, chaves criptográficas ou senhas. O pilar também é útil para armazenar dados não secretos que você não deseja colocar diretamente nos seus arquivos de estado, como dados de configuração. 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 armazenamento de dados e memória.
- 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.
- Localização geográfica e distância entre componentes - Você poderá ter problemas se houver uma latência de 65 ms ou mais entre o mestre Salt e o servidor que está executando o SaltStack Config (RaaS). Felizmente, o Salt é menos sensível à latência entre o subordinado Salt e o mestre Salt. Ao colocar esses componentes, tenha em mente que é melhor localizar o mestre próximo do RaaS e dos subordinados, se necessário.
- 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. 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 no outro. Tenha em mente que as soluções de alta disponibilidade atuais para PostgreSQL e Redis oferecem suporte apenas a failovers manuais.
