Rozdziel usługi Home Assistant między hosty tylko wtedy, gdy powtarzane pomiary pokażą, że jedno obciążenie, okno konserwacji, granica bezpieczeństwa lub zależność sprzętowa szkodzi funkcji, którą izolacja może poprawić.
Przeniesienie MQTT, bazy danych, przetwarzania obrazu z kamer, wnioskowania AI lub kopii zapasowych na inną maszynę może ochronić Home Assistant przed współzawodnictwem o zasoby, ale dodaje też DNS, dane uwierzytelniające, opóźnienia sieciowe, monitorowanie i kolejną sekwencję odzyskiwania. Najpierw zidentyfikuj granicę powodującą awarię, następnie przenieś jedną usługę w odwracalnej próbie i dopiero po potwierdzeniu poprawy lokalnego sterowania oraz odzyskiwania zaakceptuj rozproszoną architekturę.
Potwierdź, że współdzielony host jest rzeczywistym ograniczeniem
Odtwórz sytuację, w której cel nie został osiągnięty, rejestrując użycie procesora i pamięci, opóźnienia dysku, wykorzystanie sieci, czas odpowiedzi bazy danych, opóźnienie automatyzacji oraz aktywność każdej współdzielonej usługi. Porównaj normalne okno czasowe z oknem awarii i ustal, który zasób jako pierwszy osiąga nasycenie.
Jeśli zatrzymanie jednej niekrytycznej usługi usuwa objaw przy tym samym obciążeniu, jest to mocny kandydat do izolacji. Jeśli Home Assistant nadal działa wolno, gdy zasoby hosta są w normie, podział między hosty nie naprawi pętli integracji, opóźnienia klienta, nieprawidłowego zapytania ani problemu z wykrywaniem sieciowym.
Skorzystaj z powiązanego przewodnika ZimaSpace dotyczącego ograniczeń wydajności Home Assistant, aby przed zakupem lub przeniesieniem czegokolwiek odróżnić powtarzalne ograniczenie platformy od pojedynczego nietypowego skoku obciążenia.
Wybierz usługę z wyraźną granicą odpowiedzialności
Dobrymi kandydatami są usługi z niezależnymi danymi, udokumentowanym interfejsem i jasno określonym trybem awarii: zarządzana baza danych, broker MQTT, usługa analizy obrazu z kamer, proces tworzenia kopii zapasowych lub ciężkie zadanie AI. Unikaj rozdzielania ściśle powiązanych plików z katalogu /config albo umieszczania stanu wrażliwego na opóźnienia za zawodnym udziałem sieciowym.
W dyskusji społeczności dotyczącej wielu wdrożeń MQTT zauważono, że Home Assistant zwykle łączy się jako klient z jednym brokerem, a wiele brokerów wymaga świadomego zastosowania mostów lub innej topologii. Ta granica klienta jednego brokera sprawia, że przeniesienie MQTT wymaga zaplanowanego punktu końcowego, a nie przypadkowego dodawania zduplikowanych brokerów.
Wybierz jedną usługę i zapisz jej stan, dane uwierzytelniające, porty, rozpoznawanie nazw, metodę tworzenia kopii zapasowych, monitorowanie, kolejność uruchamiania oraz procedurę wycofania zmian. Jeśli odpowiedzialności nie da się jasno określić, pozostaw usługę na obecnym hoście do czasu uproszczenia jej granicy.
Porównaj zyski z niezawodności z nowymi zależnościami sieciowymi
Przeanalizuj, co stanie się w przypadku awarii któregokolwiek hosta, przełącznika, DNS-u lub łącza między hostami. Oddzielna baza danych chroni zasoby procesora i pamięci masowej tylko wtedy, gdy Home Assistant może niezawodnie się z nią połączyć, a obie strony można przywrócić w spójnej kolejności.
Projekt Home Assistant o wysokiej dostępności pokazuje, że odporność na awarie wielu hostów wymaga skoordynowanej replikacji danych, rozmieszczenia usług i kontroli przejmowania zadań, a nie tylko drugiej maszyny. Potraktuj ten skoordynowany model domen awarii jako ostrzeżenie przed przypadkowym tworzeniem kontrolerów active-active.
Preferuj lokalne pozostawienie urządzeń radiowych i ścieżki sterowania, jeśli awaria sieci nie może wyłączyć kluczowych automatyzacji. W pierwszej kolejności przenoś ciężkie usługi, które tolerują opóźnienia. Odrzuć podział, jeśli zamienia on widoczne wąskie gardło hosta w niemonitorowaną zależność od DNS-u, danych uwierzytelniających lub sieci.
Przeprowadź odwracalny podział i podejmij decyzję na podstawie wyników
Sklonuj usługę będącą kandydatem lub wykonaj jej kopię zapasową, przypisz tymczasowy punkt końcowy i najpierw przenieś tylko klienta testowego albo wykorzystaj okno konserwacji. Powtórz pierwotne obciążenie szczytowe oraz kontrolowaną awarię zależności, mierząc opóźnienie automatyzacji, czas odpowiedzi bazy danych, czas odzyskiwania i zachowanie w przypadku błędów.
Podział można uznać za udany, jeśli zmniejsza zmierzone ograniczenie, utrzymuje kluczowe lokalne sterowanie w założonych granicach, zapewnia zrozumiałe działanie ograniczone podczas utraty łącza i poprawnie przywraca usługę po ponownym uruchomieniu obu hostów. Zanim usuniesz starą ścieżkę, obserwuj co najmniej jeden zaplanowany cykl tworzenia kopii zapasowej i aktualizacji.
Wycofaj zmiany, jeśli opóźnienia, kolejność ponownego uruchamiania lub odzyskiwanie po awarii okażą się gorsze niż w konfiguracji współdzielonego hosta. Przejdź do udokumentowanego projektu stosu usług dopiero wtedy, gdy poprawa jest powtarzalna, a każdy host ma monitorowanie, kopie zapasowe, określoną odpowiedzialność za poprawki oraz przetestowaną kolejność odzyskiwania.
Wsparcie i wskazówki
Więcej do przeczytania

Home Assistant działa przez Wi-Fi, ale nie działa przez Ethernet ani VPN
Przetestuj każdą ścieżkę sieciową osobno, sprawdź stan interfejsów i routingu, rozróżnij bezpośrednie połączenie z adresem IP od wykrywania, a następnie napraw tylko uszkodzoną warstwę.

Jak wycofać Home Assistant z użycia, nie pozostawiając niechronionych danych
Udowodnij wymianę lub archiwizację, unieważnij każdą ścieżkę zaufania, wyczyść każde urządzenie zawierające dane i zachowaj wyłącznie udokumentowane chronione kopie zapasowe.

Czy warto używać automatycznych aktualizacji Home Assistant na serwerze domowym?
Wybierz aktualizacje ręczne, tylko z powiadomieniem lub etapowe aktualizacje automatyczne, uwzględniając wpływ na gospodarstwo domowe, ryzyko niezgodności, czas obserwacji i gotowość do przywrócenia działania.

