Quando é que o Home Assistant precisa de computação, armazenamento ou rede dedicados?

Mantenha o Home Assistant num único anfitrião enquanto a latência de controlo, a capacidade, o tempo de recuperação e as falhas de dependências permanecerem dentro de objetivos de serviço explícitos.

Dê capacidade de computação dedicada quando uma carga de trabalho identificada consumir a margem de controlo, armazenamento dedicado quando o estado ativo e a capacidade em massa exigirem políticas de latência ou recuperação diferentes, e rede dedicada quando um único caminho partilhado criar um domínio de indisponibilidade comprovado. Cada divisão acrescenta outra máquina, ligação, credencial, ordem de arranque e objeto de cópia de segurança, por isso valide o novo limite antes de mover qualquer outra coisa.

Mantenha as funções juntas até surgir um limite medido

Um único anfitrião mantém o Home Assistant Core, a base de dados, os rádios, os complementos, as cópias de segurança e a monitorização suficientemente próximos para arrancarem e recuperarem como um sistema conhecido. Essa simplicidade é valiosa enquanto a carga de trabalho combinada cumprir os objetivos de latência p95 das ações, tempo de reinício, janela de cópia de segurança, reserva de armazenamento e recuperação.

As discussões sobre elevada disponibilidade mostram repetidamente que nós adicionais não criam automaticamente disponibilidade ao nível da aplicação. Uma análise da comunidade sobre os limites dos domínios de falha do Home Assistant é útil porque distingue o estado do serviço e a propriedade dos rádios de simplesmente executar outra máquina.

Não divida por causa de uma utilização média baixa ou de uma preparação genérica para o futuro. Só altere a topologia quando a monitorização associar um recurso, uma capacidade, uma janela de manutenção ou uma falha ao incumprimento de um objetivo de serviço.

Divida a computação quando uma carga de trabalho consumir a margem de controlo

A computação dedicada justifica-se quando um serviço complementar separável — análise de vídeo, voz local, inferência de modelos, compilação ou uma tarefa pesada da base de dados — satura a capacidade de CPU, memória ou térmica ao mesmo tempo que as automatizações críticas ficam mais lentas ou falham.

Mova primeiro o serviço pesado, não o Home Assistant por reflexo. Preserve o respetivo endpoint de API, credenciais, tempos-limite e comportamento de recurso alternativo e, em seguida, repita a mesma carga de trabalho mista. Se a latência entre evento e ação e a margem de recuperação melhorarem, a divisão resolveu um limite de contenção medido.

Mantenha a computação junta quando os picos de recursos não estiverem correlacionados com o atraso ou quando o caminho lento for causado pela latência do rádio, da nuvem, do DNS, do cliente ou do armazenamento. Um novo anfitrião não consegue reparar uma dependência que não controla.

Divida o armazenamento quando a capacidade ou a recuperação tiverem um ciclo de vida diferente

Separe o armazenamento quando a configuração ativa e o estado do Recorder precisarem de baixa latência e instantâneos coerentes, enquanto os suportes multimédia, as exportações de telemetria ou as gerações de cópias de segurança precisarem de capacidade económica e de uma retenção diferente. Use montagens lógicas estáveis para que o caminho da aplicação sobreviva a uma alteração de dispositivo ou de conjunto de armazenamento.

Uma análise de arquitetura do Docker Compose salienta volumes persistentes, modos de rede e limites de cópia de segurança explícitos. Os seus compromissos do armazenamento persistente mostram por que motivo a separação deve preservar as permissões e a ordem de recuperação, e não apenas relocalizar os dados.

Use o limite de crescimento dos metadados interno para identificar se o estado ativo, o histórico ou os dados em massa são realmente responsáveis pelo problema de capacidade antes de criar uma dependência de NAS.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Divida a rede apenas para eliminar uma falha partilhada comprovada

A rede merece hardware ou um segmento próprio quando a carga de difusão, o esgotamento de endereços, a falha do switch, a interferência de RF, a confiança insegura nos dispositivos ou uma janela de manutenção necessária criarem uma indisponibilidade que a conceção atual não consegue tolerar. A segmentação também acrescenta dependências de encaminhamento, firewall, multicast, DNS e descoberta.

Mantenha o Home Assistant, os rádios e os dispositivos locais críticos acessíveis através do caminho mais curto que preserve o limite de segurança. Se forem introduzidos VLANs ou um switch dedicado, permita explicitamente o tráfego de descoberta e controlo necessário e documente o que continua a funcionar quando o encaminhamento, a Internet ou o DNS não estão disponíveis.

Não considere a segmentação fiável até que um teste de ação local, reinício, descoberta, notificação e recuperação seja bem-sucedido com cada dependência de rede não essencial removida à vez.

Valide o novo limite antes de mover outra função

Faça uma só divisão de cada vez, com uma cópia de segurança atual e um procedimento de reversão. Registe a versão de origem, a identidade do serviço, os endpoints, o proprietário das montagens, as regras da firewall, a ordem de arranque, a latência, a pressão sobre os recursos, o tempo da cópia de segurança e o tempo de recuperação antes e depois da mudança.

1. Reproduza a carga de trabalho da hora de maior utilização.
2. Remova uma dependência e registe o comportamento degradado.
3. Reinicie todos os serviços afetados pela ordem das dependências.
4. Recupere a função alterada num destino limpo.
5. Reverta a alteração dentro da janela de manutenção documentada.

Aceite o limite dedicado apenas quando este melhorar o objetivo identificado mais do que aumentar o risco de rede e de ciclo de vida. Mantenha as restantes funções juntas até que outra medição independente justifique a mudança seguinte.