Uczyń wszystkie elementy nadmiarowymi

Wbudowanie nadmiarowości w aplikacji pozwala uniknąć powstawania pojedynczych punktów awarii.

Odporna aplikacja jest w stanie ominąć awarię. Zidentyfikuj krytyczne ścieżki w aplikacji. Czy w każdym punkcie na ścieżce występuje nadmiarowość? Kiedy podsystem ulegnie awarii, czy aplikacja przejdzie na inny system?

W idealnej implementacji dodanie jednolitej nadmiarowości może wykładniczo zwiększyć dostępność systemu. Załóżmy na przykład, że masz N równoważne, równo zrównoważone składniki, które:

• może ulegać awarii niezależnie, a jednocześnie być usunięty z puli
• mają identyczny stan lub brak stanu
• Należy upewnić się, że nie doszło do trwałej utraty pracy w toku podczas problemów technicznych.
• są identyczne w funkcjach
• nie mają zależności od siebie
• obsługuje zmniejszenie pojemności bez dodatkowej awarii

Jeśli każdy składnik ma dostępność A, wtedy można obliczyć ogólną dostępność systemu przy użyciu formuły 1 - (1 - A)^N.

Zalecenia

Uwzględnij wymagania biznesowe. Poziom nadmiarowości wbudowanej w systemie może mieć wpływ zarówno na koszt, jak i złożoność. Architektura powinna być informowana przez wymagania biznesowe, takie jak czas docelowy odzyskiwania (RTO) i punkt docelowy odzyskiwania (RPO). Należy również wziąć pod uwagę wymagania dotyczące wydajności oraz możliwość zarządzania złożonymi zestawami zasobów przez zespół.

Rozważ architektury wielostrefowe i wieloregionowe. Upewnij się, że rozumiesz, w jaki sposób strefy dostępności i regiony zapewniają odporność i różne zestawy kompromisów architektury.

Strefy dostępności platformy Azure to izolowane zestawy centrów danych w regionie. Korzystając ze stref dostępności, można być odporny na awarie jednego centrum danych lub całej strefy dostępności. Strefy dostępności umożliwiają kompromis między kosztami, ograniczeniem ryzyka, wydajnością i możliwościami odzyskiwania. Na przykład, gdy korzystasz ze strefowo redundantnych usług w architekturze, platforma Azure zapewnia automatyczną replikację danych i automatyczne przełączanie awaryjne między instancjami zlokalizowanymi w różnych regionach geograficznych, co ogranicza wiele różnych typów zagrożeń.

Jeśli masz obciążenie o znaczeniu krytycznym i musisz ograniczyć ryzyko awarii całego regionu, rozważ wdrożenie obejmujące wiele regionów. Podczas gdy wdrożenia w wielu regionach izolują Cię przed katastrofami regionalnymi, są one kosztowne. Wdrożenia w wielu regionach są droższe niż wdrożenie w jednym regionie i są bardziej skomplikowane do zarządzania. Do obsługi trybu failover i powrotu po awarii będą potrzebne procedury operacyjne. W zależności od wymagań dotyczących celu punktu odzyskiwania (RPO), może być konieczne zaakceptowanie nieco niższej wydajności, aby umożliwić replikację danych między regionami. Dodatkowe koszty i złożoność mogą być uzasadnione w przypadku niektórych scenariuszy biznesowych.

Wskazówka

W przypadku wielu obciążeń architektura strefowo nadmiarowa zapewnia najlepszy zestaw kompromisów. Rozważ architekturę obejmującą wiele regionów, jeśli wymagania biznesowe wskazują, że musisz ograniczyć mało prawdopodobne ryzyko awarii całego regionu, a jeśli chcesz zaakceptować kompromisy związane z takim podejściem.

Aby dowiedzieć się więcej na temat projektowania rozwiązania w celu korzystania ze stref dostępności i regionów, zobacz Zalecenia dotyczące korzystania ze stref dostępności i regionów.

Umieść maszyny wirtualne za modułem równoważenia obciążenia. Nie używaj jednej maszyny wirtualnej do obsługi obciążeń o kluczowym znaczeniu. Zamiast tego umieść wiele maszyn wirtualnych za modułem równoważenia obciążenia. Jeśli jakaś maszyna wirtualna stanie się niedostępna, moduł równoważenia obciążenia przekieruje ruch do maszyn wirtualnych pozostających w dobrej kondycji.

Replikuj bazy danych. Usługi Azure SQL Database i Azure Cosmos DB automatycznie replikują dane w regionie i można je skonfigurować do replikacji między strefami dostępności w celu uzyskania większej odporności. Możesz również włączyć replikację geograficzną w różnych regionach. Replikacja geograficzna dla usług Azure SQL Database i Azure Cosmos DB tworzy pomocnicze repliki danych z możliwością odczytu w co najmniej jednym regionie pomocniczym. Jeśli wystąpi awaria w regionie podstawowym, baza danych może przejść w tryb failover do regionu pomocniczego na potrzeby zapisu. W zależności od konfiguracji replikacji może wystąpić utrata danych z niereplikowanych transakcji.

Jeśli używasz rozwiązania bazy danych IaaS, wybierz takie, które obsługuje replikację i tryb failover, takie jak grupy dostępności Always On programu SQL Server.

Partycjonowanie dla dostępności. Partycjonowanie bazy danych często stosuje się do poprawy skalowalności, ale może ono także podnieść dostępność. Jeśli jeden fragment ulegnie awarii, pozostałe fragmenty wciąż będą dostępne. Błąd jednego fragmentu spowoduje zakłócenie obejmujące tylko podzbiór wszystkich transakcji.

Przetestuj i zweryfikuj nadmiarowe składniki. Niezawodność czerpie korzyści z prostoty na wiele sposobów, a dodanie nadmiarowości może zwiększyć złożoność. Aby upewnić się, że dodanie nadmiarowości rzeczywiście prowadzi do wyższej dostępności, należy zweryfikować następujące kwestie:

• Czy system może niezawodnie wykrywać zdrowe i niezdrowe redundantne komponenty oraz bezpiecznie i szybko je usuwać z puli komponentów?
• Czy system może niezawodnie skalować w poziomie i redukować w przypadku komponentów redundantnych?
• Czy twoje rutynowe, ad hoc i awaryjne obciążenie pracą może poradzić sobie z nadmiarowością?

Rozwiązania obejmujące wiele regionów

Na poniższym diagramie przedstawiono aplikację dla wielu regionów, w której obsługa trybu failover jest realizowana za pośrednictwem usługi Azure Traffic Manager.

Jeśli używasz usługi Traffic Manager lub Azure Front Door w rozwiązaniu z wieloma regionami jako mechanizmu routingu trybu failover, rozważ następujące zalecenia:

Zsynchronizuj tryb failover frontonu i zaplecza. Użyj mechanizmu routingu, aby wykonać failover front endu. Jeśli front end stanie się niedostępny w jednym regionie, failover przekieruje nowe żądania do regionu zapasowego. W zależności od składników zaplecza i rozwiązania bazy danych może być konieczne koordynowanie przełączania usług zaplecza i baz danych w tryb failover.

Używaj automatycznego przełączania awaryjnego, ale przełączaj ręcznie z powrotem. Użyj automatyzacji do pracy w trybie failover, ale nie w przypadku powrotu po awarii. Automatyczny powrót po awarii niesie ryzyko przełączenia się do regionu podstawowego, zanim powróci on w pełni do dobrej kondycji. Zamiast tego, sprawdź, czy wszystkie podsystemy aplikacji są w dobrej kondycji, zanim ręcznie przejdziesz z powrotem do poprzedniego stanu po awarii. Należy również sprawdzić spójność danych przed powrotem po awarii.

Aby to osiągnąć, wyłącz podstawowy punkt końcowy po przejściu w tryb failover. Należy pamiętać, że jeśli interwał monitorowania sond jest krótki, a tolerowana liczba awarii jest mała, przełączenie na tryb failover i powrót do stanu sprzed awarii nastąpi w krótkim czasie. W niektórych przypadkach wyłączenie nie zostanie ukończone w odpowiednim czasie. Aby uniknąć niepotwierdzonego powrotu po awarii, rozważ również zaimplementowanie punktu kontrolnego zdrowia, który może zweryfikować, czy wszystkie podsystemy są w dobrej kondycji. Zobacz wzorzec monitorowania punktu końcowego kondycji.

Uwzględnij nadmiarowość dla swojego rozwiązania routingu. Rozważ zaprojektowanie rozwiązania globalnej nadmiarowości routingu dla aplikacji internetowych o krytycznym znaczeniu.