Uma configuração de laboratório doméstico com dois nós para programadores que querem fazer experiências e manter serviços estáveis

Atribua a um nó uma função de serviços estável e previsível e torne o segundo suficientemente descartável para poder ser reconstruído após experiências sem interromper o trabalho diário.

Duas máquinas não criam automaticamente alta disponibilidade, armazenamento partilhado ou quórum seguro. O desenho prático é um par assimétrico: um nó estável, com alterações controladas e o estado das aplicações protegido, e um nó de laboratório onde os kernels, hipervisores, clusters, GPUs e redes podem mudar frequentemente. A recuperação continua a depender das cópias de segurança, a menos que cada serviço seja replicado deliberadamente.

Defina categorias de serviços estáveis e experimentais

Liste os serviços pelas consequências, não pela tecnologia. DNS, gestão de palavras-passe, alojamento Git, um registo de contentores, monitorização e domótica podem ser estáveis se outras pessoas ou tarefas do dia a dia dependerem deles. Um laboratório Kubernetes, um novo controlador de armazenamento, uma imagem de compilação noturna, uma base de dados de testes ou uma firewall desconhecida podem ser experimentais, mesmo que usem o mesmo ambiente de execução de contentores.

Uma discussão da comunidade sobre o esforço excessivo de manutenção de serviços autogeridos resumiu claramente a regra operacional: mantenha a produção e as experiências separadas. O padrão de servidor estável e servidor de experiências reduz a probabilidade de uma experiência à noite consumir a janela de recuperação da manhã seguinte.

Para cada serviço, indique um responsável, o tempo de indisponibilidade aceitável, a localização dos dados, a origem do restauro e a janela de atualização. Se estes aspetos forem desconhecidos, o serviço não está pronto para o nó estável. Se puder ser recriado a partir de código e dados descartáveis, deve ficar no nó de experiências até se conhecer o esforço de operação.

Atribua uma função permanente a cada nó

O nó estável deve usar atualizações conservadoras, um esquema de arranque e de dados das aplicações espelhado ou que permita a recuperação, DNS previsível e memória de reserva suficiente para suportar os picos normais. Não deve tornar-se o destino de todos os dispositivos USB ou experiências de passagem direta só por estar sempre ligado.

O nó experimental pode alojar virtualização aninhada, distribuições alternativas, executores de builds, bases de dados temporárias, passagem direta de GPU ou USB e agentes de cluster. Mantenha o aprovisionamento reproduzível com ficheiros de infraestrutura, scripts ou passos documentados. Reconstruí-lo deve ser um exercício planeado, não uma crise.

Um exemplo detalhado de planeamento de um laboratório doméstico também mantém as cargas de trabalho estáveis num anfitrião e o trabalho sujeito a falhas noutro. Essa separação entre armazenamento, computação e anfitriões experimentais também mostra por que motivo a monitorização e a segmentação de rede têm de abranger todo o sistema, em vez de existirem apenas no nó com maior probabilidade de ser reinstalado.

Separe os caminhos de rede, identidade e atualização

Use endereços de gestão fixos, nomes DNS locais e uma rede de gestão ou regras de firewall estritamente delimitadas. O nó experimental pode iniciar ligações a réplicas de pacotes, registos e redes de teste, mas não deve ter acesso irrestrito de escrita ao estado das aplicações estáveis. O acesso administrativo deve continuar disponível mesmo que uma ponte de laboratório, uma rede sobreposta ou uma configuração VPN deixe de funcionar.

Não faça do nó experimental o único router, servidor DNS, controlador de cópias de segurança ou repositório de segredos do nó estável. Isso inverte a dependência pretendida. A monitorização partilhada pode ficar no nó estável, mas exporte a respetiva configuração e envie os alertas para um local que continue acessível se qualquer uma das máquinas falhar.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Faça cópias de segurança do estado sem criar falhas partilhadas

Faça cópias de segurança da configuração estável dos serviços e das bases de dados para um armazenamento que não seja apagado com nenhum dos nós. Criar um instantâneo de uma VM no mesmo anfitrião é útil para reverter alterações, mas não protege contra a perda do anfitrião. Teste o restauro de, pelo menos, um ficheiro e de uma base de dados antes de considerar fiável o nó estável.

No nó experimental, proteja o código-fonte, as definições da infraestrutura, os ficheiros de licença e qualquer conjunto de dados de teste que seja dispendioso recriar. Por predefinição, evite fazer cópias de segurança de máquinas virtuais descartáveis completas; uma imagem reproduzível e um script de restauro tornam os limites mais claros e reduzem o crescimento dos dados retidos.

Também não se deve descrever dois nós como um cluster automático. A análise da ZimaSpace sobre um servidor grande versus vários nós pequenos explica por que motivo o quórum, a mobilidade dos dados e os percursos de falha independentes são importantes antes de várias máquinas poderem proporcionar disponibilidade.

Validar o isolamento de falhas e os fatores que justificam o crescimento

Encerre o nó experimental e confirme que o DNS, a autenticação, os repositórios, os painéis e as cópias de segurança estáveis continuam a funcionar. Depois, isole o nó estável e confirme que o laboratório pode ser administrado ou reconstruído sem consultar ficheiros não documentados nele. Por fim, restaure um serviço estável em capacidade de reserva ou numa VM temporária, para comprovar o procedimento de recuperação.

A conceção está validada quando a destruição do nó experimental não causa perda de dados nem interrupções nos serviços diários além das dependências declaradas, enquanto a aplicação de atualizações ao nó estável não exige desmontar a rede do laboratório. Registe com rigor as dependências partilhadas do switch, da UPS, do NAS e da Internet; dois servidores ligados à mesma régua elétrica não criam dois domínios de falha de energia.

Só acrescente um terceiro nó quando uma carga de trabalho específica precisar de quórum, manutenção progressiva ou failover testado. Acrescente armazenamento dedicado quando o crescimento dos dados ou o tempo de restauro exceder o que qualquer um dos anfitriões pode suportar. Até lá, mantenha o modelo assimétrico de dois nós: os serviços estáveis mudam lentamente, as experiências podem ser facilmente descartadas e são as cópias de segurança - não o número de máquinas - que permitem a recuperação.

Regra final de configuração

Trate o par como duas zonas de operação, não como um cluster de alta disponibilidade em miniatura: os serviços estáveis são responsáveis pelos dados protegidos e pelas alterações controladas, enquanto as experiências são responsáveis pela capacidade de computação descartável. Só acrescente complexidade quando um requisito de recuperação ou disponibilidade testado o exigir.