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

Dimensione o percurso protegido de controlo local - não apenas o processo do Home Assistant - para as falhas de Internet e de energia que a sua casa tem de suportar.

Numa casa onde a iluminação, a climatização, a resposta a fugas ou as automações de controlo de acessos são importantes durante uma interrupção, o servidor é apenas uma das peças. Os interruptores locais, o Wi-Fi ou os coordenadores de rádio, o armazenamento persistente, a alimentação por bateria e uma configuração recuperável têm de funcionar em conjunto. A conceção deixa de estar preparada para falhas quando uma API obrigatória na nuvem, um router sem proteção ou um comportamento de reinício desconhecido interrompe o fluxo de trabalho antes de se esgotar a capacidade de processamento.

Definir o objetivo de aceitação durante uma falha

Distinga uma falha do ISP de uma falha da rede elétrica. Durante uma falha do ISP, a LAN pode continuar funcional e os dispositivos locais podem continuar a comunicar. Durante um corte de energia, o anfitrião, o router, os comutadores, os pontos de acesso, os coordenadores, o NAS e os atuadores podem falhar em simultâneo. Defina uma duração e um nível de degradação aceitável para cada situação.

Uma discussão na comunidade sobre o planeamento para falhas de energia distingue o controlo local dos dispositivos da questão mais abrangente do que permanece alimentado. Essa incerteza é o ponto de partida certo: faça o inventário das ações críticas, das respetivas dependências da rede e da nuvem e das alternativas manuais. Um requisito genérico de «manter o Home Assistant online» é demasiado limitado para dimensionar a topologia.

Classifique cada fluxo de trabalho como obrigatório, passível de funcionar com limitações ou passível de parar em segurança. Uma válvula de deteção de fugas e um sistema de segurança do aquecimento podem ter prioridade sobre os gráficos do histórico, as notificações remotas e os comandos de voz. A configuração protegida só precisa de capacidade para o conjunto obrigatório, acrescido de uma margem de recuperação; as tarefas opcionais podem ser suspensas ou transferidas para fora do anfitrião crítico.

Dimensionar a capacidade de computação para a carga de trabalho crítica

Meça a carga de trabalho principal de automação com a WAN desligada e a sequência de eventos locais mais intensa em execução. Registe os valores sustentados e de pico da CPU, a pressão sobre a 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. Assim, obtém uma referência do servidor associada aos serviços, não ao número de dispositivos.

Mantenha os modelos de voz locais, a inferência das câmaras, o processamento multimédia e a compressão das cópias de segurança fora do percurso protegido, salvo se os requisitos da interrupção de serviço os incluírem explicitamente. Se partilharem o anfitrião, use limites de recursos ou agendamento e reproduza a sobreposição de carga mais exigente. Separe um serviço apenas quando o seu pico fizer com que uma ação crítica não cumpra o objetivo de aceitação.

Reserve margem para atualizações, manutenção do gravador e crescimento, mas não transforme essa margem num nível de processador arbitrário. Um anfitrião tem capacidade suficiente quando a sequência crítica medida continua a responder e o comportamento após o reinício é previsível. É demasiado potente para a função atual quando a capacidade não utilizada aumenta o consumo em repouso e a carga da UPS sem reduzir um risco de falha identificado.

Criar um percurso de energia e rede protegido

Trace um percurso desde o sensor ou painel de controlo, passando pelo rádio ou Wi-Fi, pela comutação local e pelo Home Assistant, até ao atuador. Ligue todos os componentes de rede necessários e o anfitrião a um circuito protegido por uma UPS com autonomia medida. Uma bateria apenas no servidor não mantém o controlo se o router, o switch, o ponto de acesso ou o coordenador ficar sem energia.

Um operador descreve como proteger equipamento de rede, armazenamento e o servidor Home Assistant com pequenas unidades UPS, encerrando os servidores ao fim de poucos 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 é útil: o equipamento informático pode encerrar em segurança enquanto o percurso de comunicação local continua disponível.

Meça a carga total das tomadas, escolha uma autonomia pretendida e teste-a durante a atividade de pico normal. Defina se o anfitrião deve continuar a funcionar, encerrar corretamente ou reiniciar quando a energia regressar. Rejeite qualquer solução que não consiga recuperar quando a energia regressa enquanto a UPS ainda tem carga, pois esse caso limite pode deixar uma bateria em bom estado a proteger um serviço offline.

Featured

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

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

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

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

Um caso relatado de uma sequência de falha do Home Assistant e do Synology sequência de falha de energia mostra que ambos os sistemas se desligaram após um evento da UPS, mas não voltaram a ligar automaticamente quando a energia regressou antes de a UPS ficar completamente sem bateria. O caso demonstra por que razão a recuperação do armazenamento, do servidor e da alimentação tem de ser testada como uma única sequência; componentes que funcionam corretamente de forma isolada podem, ainda assim, deixar o serviço indisponível.

Defina a frequência das cópias de segurança com base na perda de dados aceitável e, depois, restaure uma cópia recente para um suporte alternativo ou uma máquina suplente. Guarde as credenciais e os passos num local acessível a outro administrador da casa. RAID, armazenamento em espelho ou uma segunda partição não substituem uma cópia fora do servidor, pois mantêm o mesmo domínio de falha do operador e do sistema.

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

Faça quatro testes de aceitação: desligue a ligação WAN, torne o destino da cópia de segurança indisponível, simule a ação da UPS quando a bateria está fraca e restaure o sistema em hardware alternativo. Cronometre as automações críticas, o encerramento, o reinício e o restauro. 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 medir o desempenho do Home Assistant para além da cache já aquecida explica por que razão os 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, depois, compare o resultado com o consumo da UPS e o comportamento de recuperação, em vez de aumentar a capacidade do servidor com base num teste confortável com a cache.

Aumente a capacidade de computação quando a latência crítica medida exceder o limite, depois de excluir outros estrangulamentos. Aumente a capacidade da bateria quando a autonomia de todo o percurso não atingir o objetivo. Separe os serviços mais exigentes quando o isolamento resolver a falha. Deixe de comprar hardware para servidores quando um dispositivo que depende apenas da cloud, um componente de rede sem proteção ou um restauro não testado continuar a ser o primeiro ponto de falha.

Regra final de configuração

A configuração preparada para falhas é a topologia protegida mais pequena que passa nos testes de perda da ligação WAN, autonomia da alimentação, reinício e restauro da casa. Aumente a capacidade de computação, a bateria ou o isolamento apenas quando os resultados medidos revelarem uma falha. Se as dependências da cloud ou as limitações do controlo manual continuarem a ser o principal problema, resolva-as antes de expandir o servidor Home Assistant.