Comportamento de failover de ferramentas de gerenciamento de configuração

Question

Atualmente, estou tentando vender "DevOps" para meu gerenciamento. Uma das coisas que estou investigando é o conjunto de ferramentas do Gerenciamento de Configurações. Uma das grandes coisas para nós é que temos um sistema com alta disponibilidade e um bom comportamento de failover.

• Para o CF-Engine, isso não é um problema, pois cada nó pode ser configurado para ser executado como um servidor e as execuções continuarão se o servidor não estiver disponível.
• Para o Puppet, você tem a opção de modos Master / Masterless e seus prós e contras.
• Para o Chef, a execução inicial requer que o servidor mestre busque a política, mas depois disso, qualquer execução continuará com a política atual, se o mestre não estiver disponível.
• Para o Salt, se o servidor principal ficar inativo, a configuração não será aplicada, pois todas as ações serão executadas no mestre
• Para Ansible (como o salt) se o servidor principal ficar inativo, as configurações não serão mais aplicadas, pois todas as ações são executadas novamente pelos servidores principais

Não estou incluindo o DSC do Windows PowerShell nessa lista, pois meu caso atual de usuário é usar o PowerShell DSC para ajudar no gerenciamento de sistemas Windows com o Puppet, Chef, Ansible, Salt ou CF-Engine como a ferramenta geral de gerenciamento

Eu quero saber se o meu entendimento está correto de cada um com as ferramentas e se não é por quê?

    

Answer 1

Primeiramente, quero agradecer ao jscott, Fredi, user378016 e coderanger por todas as respostas.

Para responder minha própria pergunta

• For CF-Engine this isn't an issue as every node can be configured to run as a server and the runs will continue if the server isn't available.

Tudo isso está bem documentado no site do CF-Engine. Um exemplo pode ser encontrado aqui: link

• For Puppet you have a choice of Master/Masterless modes and their pro's and cons.

O Puppet tem uma variedade de modos e, como Fredi indicou, o modo é um ou o outro. No entanto, depois de fazer mais escavações, o Puppet é muito flexível e possui boas características que podem ser suportadas para o modo master e masterless.

• For Chef the initial run requires the master server to fetch the policy but after that any run will continue with that current policy if the master isn't available.

Portanto, isso não estava correto, quando a execução é no modo de servidor (não usando chef-solo) uma execução requer uma conexão com o mestre para cada execução. Como já foi mencionado, há maneiras de se fazer um cache que tenha algum potencial interessante e talvez valha a pena investigar mais.

• For Salt if the master server goes down then configuration is not enforced as all actions are done on the master

Então, graças a user378016 para confirmação, eu acho que a resposta fornecida não responde muito bem (permalink: link )

• For Ansible (like salt) if the master server goes down then configurations are no longer enforced, as again all actions are done by the master servers

So Ansible é complicado (novamente graças a Fredi por sua resposta). Dá o strong benefício de ter apenas que instalar o software Ansible em um servidor. Os playbooks armazenados neste "master" não são necessariamente executados no master, mas podem ser aplicados em outros via SSH. Isso, é claro, requer que todas essas caixas que você deseja configurar sejam acessadas via SSH e atendam a certas condições prévias (como descrito em um playbook). Em certos casos nem sempre é desejável.

Edit: Eu deveria adicionar Ansible pode ser executado de uma maneira que é semelhante ao fantoche masterless, chef-solo, instalando o Ansible no nó a ser gerenciado e fazendo com que ele extraia a configuração de algum lugar como git e depois aplicar a configuração localmente.

Para aqueles que estão interessados na direção que estou indo em recomendar CF-Engine, Chef ou Puppet. Embora Ansible e Salt sejam interessantes, para meu caso de usuário, não é a melhor solução, já que preciso garantir que as políticas sejam aplicadas, independentemente de boas métricas de relatório. A confiança de que o SSH está sempre disponível não é realmente uma opção. (e sim, enquanto nós poderíamos instalar os componentes do servidor em cada caixa ou um agendador de algum tipo para forçar uma configuração, isso parece contra-intuitivo para a sua arquitetura original para começar).

Todos destes produtos são muito bons e têm diferentes pontos strongs e fracos, neste caso senti que o Ansible e o Salt não são adequados não apenas pela razão acima, mas também por várias outras razões. bem.

    

Answer 2

Eu vou comentar apenas sobre os que eu tenho experiência, que significa Puppet e Ansible. E estou omitindo alguns detalhes.

Ambos podem ser configurados para serem executados sem agente ou locais somente se necessário. Para usá-los localmente, você obviamente precisa de alguma maneira de transferir os manifestos / playbooks necessários para as máquinas de destino e executá-los lá.

Falando sobre o uso do Puppet com mestres, você pode ter redundância usando um balanceador de carga com os mestres reais por trás.

No Ansible, não há um conceito mestre, cada máquina que pode se conectar às máquinas gerenciadas com o ssh / powershell pode fazer, desde que você tenha uma maneira de acessar os playbooks. Talvez você quisesse dizer Ansible Tower, que usa um DB para sua operação, e você pode agrupá-lo se necessário.

Isso nos traz a redundância real em ambos os casos, ou seja, os scripts reais. Em quase todos os casos eu vi aqueles ficarem em um repositório git, então é inerentemente redundante, apenas clonando e você pode ter quantas cópias "master" você desejar.

Espero que isso ajude.

    

Answer 3

Se você olhar para o sal, a única informação que compõe uma conexão de trabalho entre mestre e minions é:

• o fato de que o servo pode resolver o ip mestre de alguma forma
• as chaves públicas dos minions nos diretórios / etc / salt / pki / master

Se o seu mestre de sal morrer, os sistemas continuarão funcionando sem efeito. Mas você está certo, você não pode executar nenhuma alteração em suas configurações enquanto o mestre estiver ausente. Então, uma pergunta é o quão rápido você pode recuperá-lo?

Você pode simplesmente reinstalar o mestre e iniciá-lo - você pode aceitar suas chaves de asseclas novamente (ou reinstalar um possível backup) e você está no mesmo local em que parou com o seu antigo mestre. Se você não pode reutilizar a mesma máquina, então você precisa apontar os subordinados para o novo mestre de alguma forma.

Nenhum dado de estado em um banco de dados que possa estar corrompido ou ter sido eliminado. Isso para mim é a beleza disso. É uma sobreposição, não se encaixa. Não - como um outro exemplo - como o juju, onde quando seu banco de dados é removido, seus sistemas agem como se fossem decapitados e você precisa reinstalar.

Há também Multimaster e Syndic em Salt - High Availability é uma longa data tópico em seu desenvolvimento.

    

Answer 4

Para resolver o problema acima, o Chef (se usar chef-client , chef-solo é puramente local e não tiver nenhum componente do servidor que possa falhar) exige o servidor em todas as execuções. Existem maneiras de usar os dados do cache no caso de uma indisponibilidade, mas definitivamente não é o comportamento padrão ou até mesmo fácil. Recomendamos que você execute o Chef Server em um sistema redundante / em cluster com um cluster por zona de falha. Confira o produto de backend do chef para agrupamento e a Entrega de mantimentos do Facebook para sincronização com vários servidores.