Como dimensionar um servidor doméstico para o Home Assistant e falhas de Internet

Numa casa onde a iluminação, a climatização, a resposta a fugas ou as automações de acesso são importantes durante uma interrupção, o servidor desempenha apenas uma função. A comutação local, os coordenadores Wi-Fi ou de rádio, o armazenamento persistente, a alimentação por bateria e uma configuração recuperável têm de permanecer alinhados. A conceção deixa de estar preparada para falhas quando uma API de nuvem necessária, um router sem proteção ou um comportamento de reinício desconhecido interrompe o fluxo de trabalho antes de a capacidade de computação o fazer.

Defina o objetivo de aceitação para falhas

Separe uma falha do ISP de uma falha da rede elétrica. Durante uma perda do ISP, a LAN pode continuar saudável e os dispositivos locais podem continuar a comunicar. Durante um corte de energia, o anfitrião, o router, os switches, os pontos de acesso, os coordenadores, o NAS e os atuadores podem falhar em conjunto. Atribua a cada evento a sua própria duração e degradação aceitável.

Uma discussão da comunidade sobre planeamento para falhas de energia distingue o controlo de dispositivos locais da questão mais abrangente sobre o que permanece alimentado. Essa incerteza é o ponto de partida correto: faça um inventário das ações críticas, das respetivas dependências de rede e de nuvem e da alternativa manual. Um requisito genérico para “manter o Home Assistant online” é demasiado limitado para dimensionar a topologia.

Classifique cada fluxo de trabalho como deve continuar, pode degradar-se ou pode parar em segurança. Uma válvula de fuga e uma salvaguarda do aquecimento podem ter prioridade sobre gráficos históricos, notificações remotas e consultas de voz. A configuração protegida precisa de capacidade apenas para o conjunto que tem de continuar, mais uma margem de recuperação; o trabalho opcional pode ser pausado ou transferido para fora do anfitrião crítico.

Dimensione a computação a partir da carga de trabalho crítica

Meça a carga de trabalho principal das automações com a WAN desligada e a sequência de eventos locais mais exigente em execução. Registe a utilização sustentada e máxima do CPU, a pressão da memória, a espera do armazenamento e a latência de resposta. Inclua a base de dados e apenas os complementos necessários para as ações protegidas. Isto produz uma referência do servidor associada ao serviço, não à quantidade de dispositivos.

Mantenha os modelos de voz locais, a inferência de câmaras, o processamento multimédia e a compressão de cópias de segurança fora do caminho protegido, a menos que o requisito de falha os inclua explicitamente. Se partilharem o anfitrião, utilize limites de recursos ou agendamento e reproduza a sua pior sobreposição. Separe um serviço apenas quando o seu pico fizer com que uma ação crítica falhe o objetivo de aceitação.

Acrescente margem para atualizações, manutenção do gravador e crescimento, mas não transforme essa margem num nível arbitrário de processador. Um anfitrião é suficientemente potente quando a sequência crítica medida permanece responsiva e o comportamento de reinício é previsível. É demasiado potente para a função atual quando a capacidade não utilizada aumenta o consumo em inatividade e a carga da UPS sem reduzir uma falha identificada.

Construa um único caminho protegido de alimentação e rede

Desenhe um caminho único desde o sensor ou painel, passando pelo rádio ou Wi-Fi, pela comutação local, pelo Home Assistant e pelo atuador. Coloque todos os componentes de rede necessários e o anfitrião num circuito protegido por UPS e medido. Uma bateria apenas no servidor não consegue preservar o controlo quando o router, o switch, o ponto de acesso ou o coordenador perde alimentação.

Um operador descreve a proteção do equipamento de rede, do armazenamento e do servidor Home Assistant com pequenas UPS, desligando os servidores ao fim de alguns minutos e mantendo o equipamento de rede disponível durante mais tempo. Os tempos dependem da instalação, mas a separação de funções é valiosa: a computação pode desligar-se em segurança enquanto o caminho de comunicação local continua útil.

Meça a carga total das tomadas, selecione uma autonomia-alvo e teste-a durante a atividade normal de pico. Defina se o anfitrião continua em funcionamento, se é desligado corretamente ou se reinicia após o regresso da energia. Rejeite uma conceção que não consiga recuperar quando a energia regressa enquanto a UPS ainda tem carga, porque esse caso-limite pode deixar uma bateria saudável a proteger um serviço offline.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separe o estado ativo das cópias de recuperação

Mantenha a configuração e a base de dados ativa do gravador num armazenamento persistente monitorizado que arranque com o anfitrião protegido. Coloque as cópias de recuperação num destino separado cuja perda não impeça a automação local de arrancar. Um NAS pode ser um destino eficaz para cópias de segurança, mas não deve tornar-se um pré-requisito acidental para o serviço principal.

Uma sequência de falha do Home Assistant e Synology relatada mostra ambos os sistemas a desligarem-se perante um evento da UPS, mas sem acordarem automaticamente quando a energia regressou antes de a UPS ficar completamente descarregada. O caso demonstra por que motivo o armazenamento, o anfitrião e a recuperação da alimentação têm de ser testados como uma única sequência; componentes individualmente corretos podem, ainda assim, produzir um serviço indisponível.

Defina a frequência das cópias de segurança a partir da perda de dados aceitável e, em seguida, restaure uma cópia recente para suportes alternativos ou uma máquina suplente. Guarde as credenciais e os passos num local a que outro administrador do agregado familiar consiga aceder. RAID, armazenamento espelhado ou uma segunda partição não substituem uma cópia fora do anfitrião, porque preservam o mesmo domínio de falha do operador e do sistema.

Valide a topologia e defina os critérios de expansão

Execute quatro testes de aceitação: desligue a WAN, torne o destino das cópias de segurança indisponível, simule a ação de bateria fraca da UPS e faça uma restauração para hardware alternativo. Cronometre as automações críticas, o desligamento, o reinício e a restauração. Registe as falhas por ligação do grafo, para que uma atualização altere a função que falhou em vez de acrescentar capacidade em todo o lado.

O guia da ZimaSpace sobre medição do desempenho do Home Assistant para além da cache aquecida explica por que motivo testes repetidos com a cache aquecida podem ocultar limites de arranque a frio ou de pico. Aplique esse método à carga de trabalho protegida e compare depois o resultado com o consumo da UPS e o comportamento de recuperação, em vez de aumentar o anfitrião com base num teste confortável com a cache.

Aumente a computação quando a latência crítica medida falhar depois de excluir os restantes estrangulamentos. Aumente a capacidade da bateria quando a autonomia do caminho completo não atingir o objetivo. Separe serviços pesados quando o isolamento resolver a falha. Pare de comprar hardware de servidor quando um dispositivo dependente apenas da nuvem, um componente de rede sem proteção ou uma restauração não testada continuar a ser a primeira fronteira.

Regra final de configuração

A dimensão preparada para falhas é a topologia protegida mais pequena que passa os testes domésticos de perda de WAN, autonomia energética, reinício e restauração. Aumente a computação, a bateria ou o isolamento apenas quando a respetiva fronteira medida falhar. Se as dependências da nuvem ou as lacunas nos controlos manuais continuarem a dominar, resolva-as antes de expandir o servidor Home Assistant.