Może być automatyczny lub inicjowany przez operatora. Zamierzony wynik to przywrócona lub kontynuowana usługa, ale akceptowalna przerwa, pojemność, stan i poprawność muszą być zdefiniowane z góry.
Niezawodny failover zależy od godnych zaufania sygnałów zdrowia, reguł decyzyjnych, gotowości rezerwy, replikacji stanu, pokrycia zależności, zmian routingu lub nazw oraz zapobiegania konfliktującym aktywnym instancjom. Failback do odzyskanego systemu głównego to osobna kontrolowana zmiana i może nieść własne ryzyko.
Najważniejsze punkty
Ustal logikę wyzwalaniaZdefiniuj dowody awarii, timing wykrywania i potwierdzania, reguły kworum lub fencingu, autorytet dla akcji ręcznych i zabezpieczenia przed oscylacją lub fałszywym failoverem.
Pokryj zależnościUwzględnij dane, tożsamość, klucze, sieci, płaszczyzny sterowania, dostawców, pojemność, konfigurację, obserwowalność i ścieżki, którymi użytkownicy docierają do usługi alternatywnej.
Testuj przejściaĆwicz failover i failback pod obciążeniem i scenariusze częściowej awarii, weryfikuj transakcje i spójność danych, mierz cele odtwarzania i rejestruj zdegradowane funkcje.
Istotne ograniczenieUdane przełączenie komponentu nie dowodzi ciągłości end-to-end. Współdzielone zależności, nieaktualny lub uszkodzony stan, działanie split-brain, niekompatybilna konfiguracja, niewystarczająca pojemność lub atakujący obecny w obu środowiskach mogą uczynić failover nieskutecznym lub niebezpiecznym.