Gerenciamento de configuração: topologia baseada em push versus pull

21

Os sistemas de gerenciamento de configuração (CM) mais estabelecidos, como o Puppet e o Chef, usam uma abordagem baseada em pull: os clientes pesquisam periodicamente um mestre centralizado para atualizações. Alguns deles também oferecem uma abordagem sem mestre (assim, baseada em push), mas declaram que 'não é para produção' (Saltstack) ou 'menos escalável' (Puppet). O único sistema que eu conheço é o push-based desde o começo, é o vice-campeão Ansible.

Qual é a vantagem específica de escalabilidade de um sistema baseado em pull? Por que é supostamente mais fácil adicionar mais mestres de tração do que agentes de pressão?

Por exemplo, agiletesting.blogspot.nl escreve:

in a 'pull' system, clients contact the server independently of each other, so the system as a whole is more scalable than a 'push' system

Por outro lado, a Rackspace demonstra que eles podem lidar com sistemas de 15K com um modelo baseado em push.

infastructures.org escreve:

We swear by a pull methodology for maintaining infrastructures, using a tool like SUP, CVSup, an rsync server, or cfengine. Rather than push changes out to clients, each individual client machine needs to be responsible for polling the gold server at boot, and periodically afterwards, to maintain its own rev level. Before adopting this viewpoint, we developed extensive push-based scripts based on ssh, rsh, rcp, and rdist. The problem we found with the r-commands (or ssh) was this: When you run an r-command based script to push a change out to your target machines, odds are that if you have more than 30 target hosts one of them will be down at any given time. Maintaining the list of commissioned machines becomes a nightmare. In the course of writing code to correct for this, you will end up with elaborate wrapper code to deal with: timeouts from dead hosts; logging and retrying dead hosts; forking and running parallel jobs to try to hit many hosts in a reasonable amount of time; and finally detecting and preventing the case of using up all available TCP sockets on the source machine with all of the outbound rsh sessions. Then you still have the problem of getting whatever you just did into the install images for all new hosts to be installed in the future, as well as repeating it for any hosts that die and have to be rebuilt tomorrow. After the trouble we went through to implement r-command based replication, we found it's just not worth it. We don't plan on managing an infrastructure with r-commands again, or with any other push mechanism for that matter. They don't scale as well as pull-based methods.

Isso não é um problema de implementação em vez de arquitetônico? Por que é mais difícil escrever um cliente de push encadeado do que um servidor de encadeamento encadeado?

    
por Willem 18.01.2014 / 11:13

2 respostas

8

O problema com sistemas baseados em push é que você precisa ter um modelo completo de toda a arquitetura no nó central de push. Você não pode empurrar para uma máquina que você não conhece.

Obviamente, pode funcionar, mas é preciso muito trabalho para mantê-lo em sincronia.

Usando coisas como o Mcollective, você pode converter Puppet e outros CM's em um push sistema baseado. Geralmente, é trivial converter um sistema pull em um push, mas nem sempre é simples fazer o contrário.

Há também a questão da política organizacional. Um sistema baseado em push coloca todas as mãos de controle dos administradores centrais. Pode ser muito difícil gerenciar a complexidade dessa maneira. Eu acho que a questão do escalonamento é um obstáculo, ou a abordagem é escalonada se você observar apenas o número de clientes. De muitas maneiras, o push é mais fácil de escalar. No entanto, a configuração dinâmica faz mais ou menos implicar que você tenha pelo menos uma versão pull do registro do cliente.

Por fim, é sobre qual sistema corresponde ao fluxo de trabalho e à propriedade em sua organização. Como regra geral, os sistemas pull são mais flexíveis.

    
por 19.01.2014 / 18:49
10

No caso de ser de interesse de qualquer pessoa, eu acho que, no mínimo, posso dar um relatório de experiência do usuário tendo feito meu primeiro uso do recurso de envio do Ansible no contexto de gerenciamento de patches de configurações de multi-host da missão sistemas críticos na nuvem da Amazon. Para entender meus preconceitos ou vieses, devo explicar que tenho uma preferência por Ruby no nível de script de automação e configurei projetos para usar configuração de puppet de agente mestre por projeto-Vpc no passado. Então minha experiência desmente preconceitos do passado, se houvesse algum.

Minha experiência recente foi muito favorável ao envio dinâmico para um estado de mudança de dezenas a centenas de servidores que podem ser ampliados ou desativados, finalizados e atualizados. Na minha situação, um simples comando ad hoc do Ansible 1.7 era tudo o que eu precisava para fazer o patch. No entanto, tendo em vista a eficácia da criação de um AnsibleController (em um t2.micro) por VPC para o efeito, no futuro, pretendo expandir a técnica para requisitos mais complexos.

Então deixe-me retornar à pergunta feita neste tópico: prós e contras de empurrar em uma propriedade que muda dinamicamente.

As suposições do tipo de propriedade de servidor que eu almejei eram:

  • Nenhuma suposição de que endereços IP ou nomes de host locais gerados pela Amazon sejam duradouros - eles podem entrar e sair
  • Todas as instâncias foram criadas a partir de imagens de máquinas que já tinham a capacidade de tornar o acesso ssh possível a partir de um único usuário administrativo privilegiado
  • Para individualizar servidores e particioná-los em grupos, de acordo com a função ou de acordo com o estágio de desenvolvimento (por exemplo, teste ou prod), isso seria feito através do lançamento de tags específicas da Amazon de nomes convencionais acordados
  • O patch seria administrar servidores Linux e Windows separadamente, com diferentes comandos ad hoc, portanto, permitir que os logins específicos do Linux falhem ao entrar em contato com um servidor Windows era perfeitamente aceitável

Com essas condições em mente, criar uma imagem de máquina de um AnsibleController para incluir vários Vpcs e configurar (com credenciais) in situ dentro das contas de servidor existentes é muito simples. Automatizado em cada instância criada a partir da imagem é

  1. Um cron job para enviar o patch para os servidores em execução em intervalos regulares, para que o estado necessário seja acessado continuamente em intervalos
  2. Uma maneira de calcular o inventário Ansible em cada intervalo.

O segundo item pode ser relativamente sofisticado, se necessário (através da estrutura Info do inventário Ansible). Mas, se a sofisticação não for necessária, aqui está um exemplo muito simples de um script para calcular todas as instâncias do Amazon EC2 em cada intervalo do cron e direcionar os resultados para um arquivo de inventário apropriado (por exemplo, /etc/ansible/hosts)…

#!/bin/bash
# Assumes aws-cli/1.3.4 Python/2.6.9 Linux/3.4.73-64.112.amzn1.x86_64 or greater
# http://aws.amazon.com/releasenotes/8906204440930658
# To check yum list aws-cli
# Assumes that server is equipped with AWS keys and is able to access some or all
# instances in the account within it is running.
# Provide a list of host IPs each on a separate line
# If an argument is passed then treat it as the filename, whether local or absolute 
# path, to which the list is written

function list-of-ips {
    /usr/bin/aws ec2 describe-instances --filters '[ {"Name": "instance-state-code", "Values": [ "16" ] } ]' | grep -w PrivateIpAddress | awk  '{x=$2; gsub("\"","", x); gsub(",","", x); if(x && FNR!=1){print x;}}' | uniq
 }

if [ -n "$1" ]; then
   list-of-ips > "$1"
else
   list-of-ips
fi

A única ressalva para o caso de uso é que o comando patch deve ser idempotente. É desejável fazer um pré-teste para garantir que isso seja satisfeito, como parte de garantir que o patch faça exatamente o que se pretende.

Então, para resumir, ilustrei um caso de uso em que o push dinâmico é eficaz contra as metas que defini. É uma solução repetível (no sentido de ser encapsulado em uma imagem que pode ser implementada em várias contas e regiões). Na minha experiência, até hoje, a técnica de push dinâmico é muito mais fácil de fornecer - e entrar em ação - do que as alternativas disponíveis nos conjuntos de ferramentas disponíveis no momento.

    
por 12.10.2014 / 17:20