O termo "trate seus servidores como gado, não animais de estimação" proliferou nos últimos anos, principalmente quando aplicado a contêineres do Docker e máquinas virtuais
O que isso realmente significa?
Respostas:
Randy Bias narra a história do termo, afirmando que provavelmente se originou em 2011 ou 2012, quando Bill Baker usou a analogia ao descrever estratégias arquitetônicas de "expansão" versus "expansão". Viés adotou isso em suas apresentações sobre padrões de arquitetura em nuvem:
No modo antigo de fazer as coisas, tratamos nossos servidores como animais de estimação, por exemplo, Bob, o servidor de correio. Se Bob cair, está tudo no convés. O CEO não pode receber seu email e é o fim do mundo. Na nova maneira, os servidores são numerados, como gado em um rebanho. Por exemplo, www001 a www100. Quando um servidor fica inoperante, ele é retirado, filmado e substituído na linha.
O viés continua a definir Pets como
Servidores ou pares de servidores que são tratados como sistemas indispensáveis ou exclusivos que nunca podem ser desativados. Normalmente, eles são criados, gerenciados e alimentados manualmente. Exemplos incluem mainframes, servidores solitários, balanceadores de carga / firewalls HA (ativo / ativo ou ativo / passivo), sistemas de banco de dados projetados como mestre / escravo (ativo / passivo) e assim por diante.
e gado como
Matrizes de mais de dois servidores, criadas usando ferramentas automatizadas e projetadas para falhas, em que nenhum, dois ou mesmo três servidores são insubstituíveis. Normalmente, durante eventos de falha, nenhuma intervenção humana é necessária, pois a matriz exibe atributos de "roteamento em torno de falhas", reiniciando servidores com falha ou replicando dados por meio de estratégias como replicação tripla ou codificação de apagamento. Os exemplos incluem matrizes de servidores da Web, armazenamento de dados multimestre, como clusters Cassandra, vários racks de equipamentos reunidos em clusters e praticamente qualquer coisa com balanceamento de carga e multimestre.
Fundamentalmente, o que Bias e Baker estão tentando transmitir é que deve haver uma transição de como tratamos os servidores de serem "flocos de neve exclusivos" com nomes e anexos emocionais, para um modelo pelo qual, se tivermos um problema com o servidor, criaremos um substituto e destrua o servidor problemático.
Finalmente, vale a pena mencionar que em ambientes regulamentados, retirar um servidor pelas costas e disparar pode não ser o ideal. Nesses casos, geralmente é vantajoso "congelar" o servidor, por exemplo, docker pausepara congelar um contêiner. Isso pode ser usado para executar uma Análise de Causa Raiz como parte do Processo de Gerenciamento de Incidentes ou Problemas.
Para adicionar à resposta de Richards, geralmente a analogia é útil em termos de considerar o impacto da perda de um servidor.
Se você sentir algum tipo de angústia com a perda de qualquer parte individual da infraestrutura, considere-a um animal de estimação (leia antipadrão).
Se você se sentir bem à vontade sabendo que se alguma frota parar de funcionar, não haverá um impacto real nas operações, então você está falando sobre gado.
Muitas vezes, é tentador usar a analogia para simplesmente classificar seus servidores, ou seja, "nossos nós de carga de trabalho são gado, mas nossos balanceadores de carga são animais de estimação", mas cair nessa armadilha é exatamente o problema. Não há lugar para animais de estimação em um ambiente de computação moderno (por exemplo, na nuvem, em hardware comum etc.) Se todos os seus servidores forem considerados bovinos e forem facilmente substituíveis, você poderá começar a considerar coisas como o macaco do caos para ajudar crie garantia de que sua infraestrutura é realmente resiliente.