Dela endast upp Home Assistant-tjänster mellan värdar när upprepade mätningar visar att en arbetsbelastning, ett underhållsfönster, en säkerhetsgräns eller ett hårdvaruberoende försämrar en funktion som isolering kan förbättra.
Att flytta MQTT, en databas, kamerabearbetning, AI-inferens eller säkerhetskopieringar till en annan maskin kan skydda Home Assistant från resurskonkurrens, men det medför också DNS, autentiseringsuppgifter, nätverkslatens, övervakning och ytterligare en återställningssekvens. Identifiera först den felande gränsen, flytta en tjänst i ett reversibelt test och bevisa sedan att lokal styrning och återställning förbättras innan du accepterar den distribuerade designen.
Bekräfta att den delade värden faktiskt är begränsningen
Återskapa det missade målet medan du registrerar CPU, minne, disklatens, nätverksanvändning, databassvar, automationsfördröjning och aktiviteten hos varje samlokaliserad tjänst. Jämför ett normalt tidsfönster med felfönstret och identifiera den resurs som först når sin kapacitetsgräns.
Om stopp av en icke-kritisk tjänst tar bort symtomet under samma arbetsbelastning har du en stark kandidat för isolering. Om Home Assistant fortfarande är långsam medan värdresurserna är normala kommer uppdelning mellan värdar inte att lösa en integrationsloop, klientfördröjning, en dålig fråga eller ett problem med nätverksupptäckt.
Använd den relaterade ZimaSpace-guiden om kapacitetsgränser för Home Assistant för att skilja en återkommande plattformsbegränsning från en enstaka onormal topp innan du köper eller flyttar något.
Välj en tjänst med en tydlig ansvarsgräns
Bra kandidater har oberoende data, ett dokumenterat gränssnitt och ett tydligt felläge: en hanterad databas, en MQTT-mäklare, en tjänst för kameraanalys, en säkerhetskopieringsarbetare eller en tung AI-uppgift. Undvik att dela upp filer som är tätt kopplade till /config eller att placera latenskänsligt tillstånd bakom en opålitlig nätverksresurs.
Diskussioner i communityt om flera MQTT-distributioner påpekar att Home Assistant normalt ansluter som klient till en mäklare, medan flera mäklare kräver medveten bryggning eller en annan topologi. Den klientgräns med en enda mäklare är anledningen till att en flytt av MQTT kräver en planerad slutpunkt, inte att dubbla mäklare läggs till på måfå.
Välj en tjänst och skriv ner dess tillstånd, autentiseringsuppgifter, portar, namnupplösning, säkerhetskopieringsmetod, övervakning, startordning och återställning. Om ansvaret inte kan uttryckas tydligt bör tjänsten ligga kvar på den nuvarande värden tills tjänstegränsen har förenklats.
Jämför tillförlitlighetsvinster med nya nätverksberoenden
Modellera vad som händer när någon av värdarna, switchen, DNS eller länken mellan värdarna slutar fungera. En separat databas skyddar CPU- och lagringsresurser endast om Home Assistant kan nå den på ett tillförlitligt sätt och båda sidor kan återställas i en konsekvent ordning.
En Home Assistant-design med hög tillgänglighet visar att motståndskraft mellan flera värdar kräver samordnad datareplikering, tjänsteplacering och övertagningskontroll, inte bara en andra maskin. Använd den samordnade modellen för feldomäner som en varning mot oavsiktliga aktiva-aktiva-styrenheter.
Behåll helst radioenheter och styrvägen lokalt när ett nätverksavbrott inte får inaktivera viktiga automationer. Flytta först tunga tjänster som tål fördröjning. Avstå från uppdelningen om den förvandlar en synlig flaskhals på värden till ett oövervakat DNS-, autentiserings- eller nätverksberoende.
Genomför en reversibel uppdelning och fatta beslut utifrån resultaten
Klona eller säkerhetskopiera kandidattjänsten, tilldela en tillfällig slutpunkt och flytta först endast en testklient eller ett underhållsfönster. Upprepa den ursprungliga toppbelastningen och ett kontrollerat avbrott i ett beroende medan du mäter automationsfördröjning, databasutens svarstid, återställningstid och felbeteende.
En godkänd uppdelning minskar den uppmätta begränsningen, håller viktig lokal styrning inom målet, ger ett begripligt försämrat beteende vid länkförlust och återställs korrekt efter att båda värdarna har startats om. Observera minst en schemalagd säkerhetskopierings- och uppdateringscykel innan du tar bort den gamla vägen.
Rulla tillbaka om latens, omstartordning eller felåterställning blir sämre än utgångsläget på den delade värden. Gå vidare till en dokumenterad tjänstestacksdesign först när förbättringen är återkommande och varje värd har övervakning, säkerhetskopiering, ansvar för korrigeringar och en testad återställningsordning.
Support och tips
Mer att läsa

Home Assistant fungerar via Wi-Fi men inte via Ethernet eller VPN
Testa varje nätverkssökväg separat, verifiera gränssnittets och routingens status, skilj direktanslutning via IP-adress från upptäckt och reparera sedan endast det lager som har fallerat.

Så avvecklar du Home Assistant utan att lämna kvar oskyddade data
Bevisa utbytet eller arkiveringen, återkalla varje förtroendeväg, sanera varje databärande enhet och behåll endast dokumenterade skyddade återställningskopior.

Bör du använda automatiska uppdateringar för Home Assistant på en hemmaserver?
Välj manuella, endast aviserade eller stegvis automatiska uppdateringar utifrån påverkan på hushållet, kompatibilitetsrisk, observationstid och beredskap för återställning.

