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 jest zachowana nadmiarowość? Kiedy podsystem ulegnie awarii, czy aplikacja przejdzie w tryb failover do czegoś innego?

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 działać niezależnie i jednocześnie usuwać z puli
• mają identyczny stan lub brak stanu
• nie ma w toku pracy, która jest trwale utracona podczas awarii
• 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ść , można obliczyć ogólną dostępność Asystemu 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ć informowany przez wymagania biznesowe, takie jak cel czasu odzyskiwania (RTO) i cel punktu 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 w przypadku korzystania ze strefowo nadmiarowych usług w architekturze platforma Azure zapewnia automatyczną replikację danych i tryb failover między wystąpieniami oddzielonymi geograficznie, 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ń celu punktu odzyskiwania może być konieczne zaakceptowanie nieco niższej wydajności w celu włączenia replikacji danych między regionami. Dodatkowe koszty i złożoność mogą być uzasadnione w przypadku niektórych scenariuszy biznesowych.

Napiwek

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 do odczytu danych 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 rozwiązanie obsługujące replikację i tryb failover, takie jak zawsze włączone grupy dostępności programu SQL Server.

Utwórz partycje dla zwiększenia 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ść zapewnia wiele sposobów od uproszczenia, 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ć składniki w dobrej kondycji i w złej kondycji oraz bezpiecznie i szybko je usuwać z puli składników?
• Czy system może niezawodnie skalować w poziomie i w nadmiarowych składnikach?
• Czy twoje rutynowe, ad hoc i awaryjne operacje obciążeń mogą obsługiwać nadmiarowość?

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 przejść w tryb failover frontonu. Jeśli fronton stanie się niedostępny w jednym regionie, tryb failover będzie kierować nowe żądania do regionu pomocniczego. 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.

Zautomatyzuj tryb failover, ale używaj ręcznego powrotu po awarii. 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. Przed ręcznym powrotem po awarii sprawdź, czy wszystkie podsystemy aplikacji są w dobrej kondycji. 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, przejście w tryb failover oraz powrót po 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 końcowego kondycji, który może sprawdzić, czy wszystkie podsystemy są w dobrej kondycji. Zobacz wzorzec monitorowania punktu końcowego kondycji.

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