Trzy serwery mogą nie dawać prawdziwej redundancji, jeśli wszystkie zależą od tego samego punktu awarii
Redundancja nie polega wyłącznie na policzeniu kopii. Trzy serwery w tej samej szafie mogą dzielić zasilanie, chłodzenie, przełącznik i łącze. Jedna awaria wspólnego elementu może wyłączyć wszystkie naraz. Dlatego chmury organizują infrastrukturę w failure domains, takie jak Availability Zones. AWS opisuje strefy jako fizycznie oddzielone lokalizacje z odrębną i redundantną infrastrukturą zasilania oraz sieci, projektowane tak, aby ograniczać skorelowane awarie. Prawdziwa redundancja wymaga niezależności przyczyn awarii, nie tylko wielu kopii.
Kopie chronią tylko przed awariami, które nie dotykają wszystkich kopii
Jeśli mamy trzy dyski w trzech serwerach, awaria jednego dysku nie niszczy danych. Jeśli jednak wszystkie serwery zasilane są przez ten sam PDU, awaria zasilania może zgasić całą trójkę. Redundancja sprzętowa jest więc względna wobec konkretnego scenariusza.
Wspólna zależność tworzy common-mode failure
Dwie instancje mogą być niezależne procesowo, ale współdzielić switch, rack, system chłodzenia, oprogramowanie sterujące albo operatora wdrażającego tę samą wadliwą zmianę. Takie zależności sprawiają, że prawdopodobieństwa awarii nie są niezależne.
Availability Zone jest próbą zbudowania granicy awarii
AWS definiuje AZ jako jedną lub więcej odrębnych centrów danych z oddzielnym i redundantnym zasilaniem, siecią i łącznością. Strefy są rozmieszczane tak, aby ograniczać współdzielony los związany m.in. z zasilaniem, wodą, światłowodami czy lokalnymi katastrofami.
Rozmieszczenie kopii jest równie ważne jak ich liczba
Trzy repliki w jednej strefie świetnie chronią przed awarią pojedynczego hosta, ale słabo przed awarią całej strefy. Repliki rozłożone na kilka stref lepiej pokrywają ten scenariusz, choć kosztują więcej komunikacji i mogą mieć inne kompromisy wydajności.
Failure domain trzeba dobierać do zagrożenia
Nie ma jednej idealnej jednostki redundancji. Dla awarii procesu wystarczy drugi proces. Dla awarii hosta potrzebny jest drugi host. Dla pożaru budynku — inna strefa. Dla awarii regionu — inny region. Projektowanie niezawodności zaczyna się więc od pytania „co może paść razem?”, a nie „ile kopii mamy?”.
Redundancję może zepsuć także wspólne oprogramowanie
Dwie maszyny w różnych budynkach mogą być fizycznie niezależne, ale dostać ten sam wadliwy deployment w tej samej minucie. AWS wspomina nawet o rozdzielaniu w czasie wdrożeń pomiędzy Availability Zones, aby ograniczać skorelowane awarie. Failure domain może być więc geograficzny, sprzętowy, sieciowy albo operacyjny.
Niezależność zwykle zwiększa koszt i opóźnienie
Rozłożenie replik pomiędzy strefy lub regiony poprawia odporność na lokalne awarie, ale wymaga dalszej komunikacji i dodatkowych zasobów. System nie powinien maksymalizować separacji bez końca. Trzeba zdecydować, jakie awarie rzeczywiście są w modelu zagrożeń i ile latencji oraz kosztu warto zapłacić za ich tolerowanie.
Domeny awarii można modelować hierarchicznie: proces < host < rack < strefa < region < dostawca lub globalna zależność. Kopie rozłożone na jednym poziomie nadal mogą współdzielić poziom wyższy. Na przykład trzy strefy w jednym regionie chronią przed wieloma lokalnymi incydentami, ale niekoniecznie przed problemem kontrol plane obejmującym cały region. Architektura powinna świadomie wskazać, do którego poziomu chce zachować działanie, zamiast zakładać absolutną niezależność.
Można mieć także logiczny single point of failure ukryty w systemie zarządzania. Jeśli wszystkie strefy zależą od jednego błędnego rekordu konfiguracji lub jednego globalnego mechanizmu autoryzacji, fizyczna separacja nie wystarczy. Dlatego najbardziej odporne systemy analizują dependency graph i próbują unikać wspólnych krytycznych zależności na ścieżce obsługi. Failure domain to nie tylko mapa budynków, lecz mapa wspólnego losu. Im wyżej w hierarchii znajduje się wspólna zależność, tym więcej pozornie niezależnych kopii może zawieść razem. Sama liczba replik bez tej analizy może dawać fałszywe poczucie bezpieczeństwa.