Quando é que o Home Assistant precisa de recursos dedicados de processamento, armazenamento ou rede?

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

Dedique recursos de processamento quando uma carga de trabalho identificada consome os recursos necessários ao controlo, separe o armazenamento quando os dados ativos e a capacidade em massa exigirem políticas diferentes de latência ou recuperação, e separe a rede quando um caminho partilhado criar um domínio de indisponibilidade comprovado. Cada separação acrescenta outra máquina, ligação, credencial, sequência de arranque e elemento de cópia de segurança, por isso valide o novo limite antes de transferir 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 conjunta cumprir os limites de latência p95 das ações, tempo de reinício, janela de cópia de segurança, reserva de armazenamento e objetivos de restauro.

Os debates sobre alta disponibilidade mostram repetidamente que os 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 gestão dos rádios da simples execução noutra máquina.

Não separe com base numa utilização média baixa nem por precaução para o futuro. Altere a topologia apenas quando a monitorização associar um recurso, limite de capacidade, janela de manutenção ou falha ao incumprimento de um objetivo de serviço.

Separe o processamento quando uma carga de trabalho consome os recursos necessários ao controlo

O processamento dedicado justifica-se quando um serviço complementar separável - análise de vídeo, reconhecimento de voz local, inferência de modelos, compilação ou uma tarefa de base de dados exigente - satura a capacidade do CPU, da memória ou térmica ao mesmo tempo que as automatizações críticas abrandam ou falham.

Comece por transferir o serviço mais pesado, não o Home Assistant por reflexo. Preserve o endpoint da API, as credenciais, os tempos limite e o comportamento de contingência e, em seguida, repita a mesma carga de trabalho mista. Se a latência entre o evento e a ação e a margem de recuperação melhorarem, a separação resolveu um problema de contenção medido.

Mantenha o processamento junto quando os picos de recursos não coincidirem com a latência, ou quando o caminho lento depender de rádio, cloud, DNS, cliente ou armazenamento. Um novo anfitrião não consegue corrigir uma dependência que não controla.

Separe o armazenamento quando a capacidade ou a recuperação tiver 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 ficheiros multimédia, as exportações de telemetria ou as gerações de cópias de segurança precisarem de capacidade económica e de políticas de retenção diferentes. Use pontos de montagem lógicos estáveis para que o caminho da aplicação se mantenha após uma mudança de dispositivo ou de conjunto de armazenamento.

Uma revisão da conceção do Docker Compose dá ênfase a volumes persistentes explícitos, modos de rede e fronteiras de cópia de segurança. As suas concessões na conceção do armazenamento persistente mostram por que motivo a separação tem de preservar as permissões e a ordem de restauro, em vez de apenas mudar os dados de local.

Use a fronteira de crescimento dos metadados interna para determinar se o estado ativo, o histórico ou os dados em massa estão realmente a causar o problema de capacidade, antes de criar uma dependência de NAS.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Divida a rede apenas para eliminar uma falha partilhada comprovada

A rede justifica hardware ou um segmento próprios quando a carga de difusão, o esgotamento de endereços, a falha do switch, a interferência de radiofrequência, a confiança insegura nos dispositivos ou uma janela de manutenção obrigatória provocam uma interrupção 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 pelo percurso mais curto que preserve a fronteira de segurança. Se forem introduzidas 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 estiverem disponíveis.

Não considere a segmentação fiável até que os testes de ação local, reinício, descoberta, notificação e recuperação sejam aprovados com cada dependência de rede não essencial removida, uma de cada vez.

Valide a nova fronteira antes de mover outra função

Implemente uma divisão de cada vez, com uma cópia de segurança atual e um plano de reversão. Registe a versão de origem, a identidade do serviço, os pontos de acesso, a propriedade dos pontos de montagem, 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 restauro, antes e depois da mudança.

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

Aceite a fronteira dedicada apenas quando melhorar o objetivo indicado mais do que aumentar o risco de rede e do ciclo de vida. Mantenha as restantes funções juntas até outra medição independente justificar a próxima alteração.