Niezawodność platformy Azure Private 5G Core

W tym artykule opisano obsługę niezawodności w prywatnej sieci 5G Core platformy Azure. Obejmuje zarówno regionalną odporność ze strefami dostępności, jak i odzyskiwanie po awarii między regionami oraz zapewnienie ciągłości działania. Aby zapoznać się z omówieniem niezawodności na platformie Azure, zobacz Niezawodność platformy Azure.

Możesz również wdrożyć usługę Azure Private 5G Core jako usługę wysokiej dostępności (HA) na dwóch urządzeniach usługi Azure Stack Edge (ASE). Aby uzyskać więcej informacji, zobacz Wykonywanie zadań wstępnych dotyczących wdrażania prywatnej sieci komórkowej.

Obsługa strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w każdym regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Aby uzyskać więcej informacji na temat stref dostępności na platformie Azure, zobacz Co to są strefy dostępności?

Prywatna usługa Azure 5G Core jest automatycznie wdrażana jako strefowo nadmiarowa w regionach świadczenia usługi Azure, które obsługują strefy dostępności, jak pokazano w regionach świadczenia usługi Azure z obsługą stref dostępności. Jeśli region obsługuje strefy dostępności, wszystkie zasoby usługi Azure Private 5G Core utworzone w regionie mogą być zarządzane z dowolnej strefy dostępności.

Do skonfigurowania stref dostępności ani zarządzania nimi nie jest wymagana żadna dalsza praca. Przechodzenie w tryb failover między strefami dostępności jest automatyczne.

Wymagania wstępne

Zobacz Dostępność produktów według regionów dla regionów świadczenia usługi Azure, w których jest dostępna prywatna usługa Azure 5G Core.

Doświadczenie redukcji strefy

W scenariuszu awarii całej strefy użytkownicy nie powinni doświadczyć żadnych problemów, ponieważ usługa automatycznie przeniesie się do działającej strefy. Na początku przerwy w działaniu obejmującej całą strefę może wystąpić limit czasu lub niepowodzenie żądań modułu ARM, które są w toku. Nowe żądania będą kierowane do sprawnych węzłów bez wpływu na użytkowników, a wszelkie nieudane operacje powinny zostać ponowione. Nadal będzie można tworzyć nowe zasoby i aktualizować, monitorować istniejące zasoby i zarządzać nimi podczas awarii.

Bezpieczne techniki wdrażania

Aplikacja zapewnia, że cały stan chmury jest replikowany między strefami dostępności w regionie, dzięki czemu wszystkie operacje zarządzania będą kontynuowane bez przerwy. Rdzeń pakietów działa na brzegu sieci i nie jest dotknięty awarią strefy, więc będzie nadal świadczyć usługi użytkownikom.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług jesteś odpowiedzialny za skonfigurowanie planu odzyskiwania po awarii, który odpowiada na potrzeby twoich obciążeń. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Rdzeń Prywatnej Sieci 5G Azure jest dostępny tylko w wieloregionowych geografiach (3+N). Usługa automatycznie replikuje poświadczenia SIM do regionu kopii zapasowej w tej samej lokalizacji geograficznej. Oznacza to, że w przypadku awarii regionu nie ma utraty danych. W ciągu czterech godzin od awarii wszystkie zasoby w regionie, które zakończyły się niepowodzeniem, są dostępne do wyświetlenia za pośrednictwem witryny Azure Portal i narzędzi usługi ARM, ale będą dostępne tylko do odczytu do czasu odzyskania regionu, w którym wystąpił błąd. Rdzeń pakietów działający w przeglądarce Edge nadal działa bez przerwy, a łączność sieciowa zostanie zachowana.

Firma Microsoft jest odpowiedzialna za wykrywanie awarii, powiadamianie i obsługę aspektów chmury platformy Azure w prywatnej usłudze Azure 5G Core.

Wykrywanie, powiadamianie i zarządzanie awariami

Firma Microsoft monitoruje bazowe zasoby zapewniające prywatną usługę Azure Private 5G Core w każdym regionie. Jeśli te zasoby zaczną wyświetlać błędy lub alerty monitorowania kondycji, które nie są ograniczone do pojedynczej strefy dostępności, firma Microsoft przeniesie usługę do innego obsługiwanego regionu w tej samej lokalizacji geograficznej. Jest to wzorzec Aktywny-Aktywny. Kondycję usługi dla określonego regionu można znaleźć w usłudze Azure Service Health (prywatna sieć 5G Platformy Azure znajduje się w sekcji Sieć ). Otrzymasz powiadomienie o wszelkich awariach regionów za pośrednictwem normalnych kanałów komunikacyjnych platformy Azure.

Usługa automatycznie replikuje dane uwierzytelniające SIM przypisane do usługi do regionu zapasowego, korzystając z zapisów w wielu regionach obsługiwanych przez Cosmos DB, więc w przypadku awarii regionu nie ma utraty danych.

Zasoby usługi Azure Private 5G Core wdrożone w regionie, który uległ awarii, staną się dostępne tylko do odczytu, ale zasoby we wszystkich innych regionach będą działać bez zakłóceń. Jeśli chcesz mieć możliwość zapisywania zasobów przez cały czas, postępuj zgodnie z instrukcjami w temacie Konfigurowanie odzyskiwania po awarii i wykrywania awarii, aby wykonać własną operację odzyskiwania po awarii i skonfigurować usługę w innym regionie.

Rdzeń pakietów działający w przeglądarce Edge nadal działa bez przerwy, a łączność sieciowa zostanie zachowana.

Konfigurowanie odzyskiwania po awarii i wykrywania awarii

W tej sekcji opisano, jakie działania można podjąć, aby upewnić się, że masz w pełni aktywną płaszczyznę zarządzania dla usługi Azure Private 5G Core w przypadku awarii regionu. Jest to wymagane, jeśli chcesz mieć możliwość modyfikowania zasobów w przypadku awarii regionu.

Należy pamiętać, że spowoduje to awarię usługi podstawowej pakietu i przerwanie łączności sieciowej z interfejsami użytkownika przez maksymalnie osiem godzin, dlatego zalecamy użycie tej procedury tylko wtedy, gdy masz przyczynę krytycznego dla działania firmy, aby zarządzać zasobami, gdy region świadczenia usługi Azure nie działa.

Przed zdarzeniem odzyskiwania po awarii należy utworzyć kopię zapasową konfiguracji zasobów do innego regionu, który obsługuje platformę Azure Private 5G Core. Po wystąpieniu awarii w regionie można ponownie wdrożyć rdzeń sieci pakietów przy użyciu zasobów w regionie kopii zapasowej.

Przygotowywanie

Istnieją dwa typy danych konfiguracji usługi Azure Private 5G Core, których kopia zapasowa musi zostać utworzona na potrzeby odzyskiwania po awarii: konfiguracja sieci mobilnej i poświadczenia SIM. Zalecamy wykonanie następujących czynności:

• Aktualizuj poświadczenia SIM w regionie kopii zapasowej za każdym razem, gdy dodasz nowe karty SIM do regionu podstawowego
• Wykonaj kopię zapasową konfiguracji sieci komórkowej co najmniej raz w tygodniu lub częściej, jeśli wprowadzasz częste lub duże zmiany w konfiguracji, takie jak tworzenie nowej lokacji.

Konfiguracja sieci mobilnej

Postępuj zgodnie z instrukcjami w artykule Przenoszenie zasobów do innego regionu , aby wyeksportować konfigurację zasobów usługi Azure Private 5G Core i przekazać ją do nowego regionu. Zalecamy użycie nowej grupy zasobów dla konfiguracji kopii zapasowej, aby wyraźnie oddzielić ją od aktywnej konfiguracji. Należy podać nowe nazwy zasobów, aby odróżnić je od zasobów w regionie podstawowym. Ten nowy region jest pasywną kopią zapasową, więc aby uniknąć konfliktów, nie wolno jeszcze połączyć konfiguracji rdzenia pakietowego ze sprzętem brzegowym. Zamiast tego należy przechowywać wartości z pola packetCoreControlPlanes.platform dla każdego rdzenia pakietów w bezpiecznej lokalizacji, tak aby osoba, która wykona procedurę odzyskiwania, miała do tego dostęp (na przykład konto przechowywania przywoływane przez wewnętrzną dokumentację).

Dane SIM

Ze względów bezpieczeństwa usługa Azure Private 5G Core nigdy nie zwróci poświadczeń SIM dostarczonych do usługi w ramach tworzenia karty SIM. W związku z tym nie można wyeksportować konfiguracji sim w taki sam sposób jak inne zasoby platformy Azure. Zalecamy, aby za każdym razem, gdy nowe karty SIM są dodawane do usługi podstawowej, te same karty SIM były również dodawane do usługi tworzenia kopii zapasowych, powtarzając proces Aprowizowania nowych kart SIM dla sieci mobilnej kopii zapasowej.

Inne zasoby

Wdrożenie usługi Azure Private 5G Core może korzystać z usługi Azure Key Vault do przechowywania kluczy szyfrowania SIM lub certyfikatów HTTPS na potrzeby monitorowania lokalnego. Musisz postępować zgodnie z dokumentacją usługi Azure Key Vault, aby upewnić się, że klucze i certyfikaty będą dostępne w regionie kopii zapasowej.

Odzyskiwanie

W przypadku awarii regionu najpierw zweryfikuj, czy wszystkie zasoby w regionie tworzenia kopii zapasowej są obecne, wykonując zapytanie dotyczące konfiguracji za pośrednictwem witryny Azure Portal lub interfejsu API (zobacz Przenoszenie zasobów do innego regionu). Jeśli wszystkie zasoby nie są obecne, zatrzymaj się tutaj i nie postępuj zgodnie z resztą tej procedury. Odzyskiwanie usługi w lokacji brzegowej może nie być możliwe bez konfiguracji zasobu.

Proces odzyskiwania jest podzielony na trzy etapy dla każdego rdzenia pakietów:

1. Odłącz urządzenie Azure Stack Edge od regionu, w którym wystąpiło niepowodzenie, wykonując resetowanie
2. Łączenie urządzenia Azure Stack Edge z regionem tworzenia kopii zapasowych
3. Zainstaluj ponownie i zweryfikuj instalację.

Ten proces należy powtórzyć dla każdego rdzenia pakietów w sieci komórkowej.

Uwaga

Procedura odzyskiwania spowoduje awarię usługi rdzenia pakietu i przerwanie łączności sieciowej z urządzeniami użytkownika przez maksymalnie osiem godzin na każdy rdzeń pakietu. Zalecamy wykonanie tej procedury tylko w przypadku, gdy masz krytyczną dla działania firmę potrzebę zarządzania wdrożeniem usługi Azure Private 5G Core za pośrednictwem platformy Azure podczas awarii regionu.

Odłącz urządzenie Azure Stack Edge od regionu, w którym wystąpił błąd

Na urządzeniu Azure Stack Edge jest obecnie uruchomione oprogramowanie podstawowe pakietu i jest kontrolowane z regionu, w którym wystąpił błąd. Aby odłączyć urządzenie Azure Stack Edge od regionu, w którym wystąpił błąd i usunąć uruchomiony rdzeń pakietów, należy wykonać instrukcje resetowania i ponownego aktywowania w temacie Resetowanie i ponowne aktywowanie urządzenia Azure Stack Edge. Należy pamiętać, że spowoduje to usunięcie wszystkich oprogramowania aktualnie uruchomionego na urządzeniu Azure Stack Edge, a nie tylko oprogramowania podstawowego pakietów, dlatego upewnij się, że masz możliwość ponownego zainstalowania dowolnego innego oprogramowania na urządzeniu. Spowoduje to uruchomienie awarii sieci dla wszystkich urządzeń połączonych z rdzeniem pakietów na tym urządzeniu Azure Stack Edge.

Łączenie urządzenia Azure Stack Edge z nowym regionem

Postępuj zgodnie z instrukcjami w Commission the AKS cluster, aby ponownie wdrożyć klaster usługi Azure Kubernetes Service na urządzeniu Azure Stack Edge. Upewnij się, że używasz innej nazwy dla tej nowej instalacji, aby uniknąć starć po odzyskaniu regionu, w którym wystąpił błąd. W ramach tego procesu uzyskasz nowy identyfikator dostosowanej lokalizacji dla klastra, który warto zanotować.

Ponowne instalowanie i walidacja

Wykonaj kopię wartości packetCoreControlPlanes.platform, które przechowano w Przygotowaniu i zaktualizuj pole packetCoreControlPlane.platform.customLocation za pomocą identyfikatora lokalizacji niestandardowej zanotowanego powyżej. Upewnij się, że element packetCoreControlPlane.platform.azureStackEdgeDevice odpowiada identyfikatorowi urządzenia Azure Stack Edge, na którym chcesz zainstalować rdzeń pakietowy. Teraz postępuj zgodnie z instrukcjami Modyfikacja rdzenia pakietowego, aby zaktualizować zapasowy rdzeń pakietowy z wartościami platformy. Spowoduje to zainicjowanie wdrożenia infrastruktury sieci pakietowej na urządzeniu Azure Stack Edge.

Należy postępować zgodnie z normalnym procesem weryfikacji instalacji nowej lokacji, aby potwierdzić, że łączność urządzeń użytkownika została przywrócona. W ten sposób można upewnić się, że wszystkie funkcje sieciowe działają prawidłowo. W szczególności należy potwierdzić, że pulpity nawigacyjne w portalu Azure pokazują rejestracje użytkowników oraz że dane przepływają przez płaszczyznę danych.

Region przywrócono po niepowodzeniu

Po odzyskaniu regionu, który zakończył się niepowodzeniem, upewnij się, że konfiguracja w dwóch regionach jest zsynchronizowana, wykonując kopię zapasową z aktywnego regionu kopii zapasowej do odzyskanego regionu podstawowego, wykonując kroki opisane w temacie Przygotowanie.

Należy również sprawdzić i usunąć wszystkie zasoby w odzyskanym regionie, które nie zostały zniszczone w poprzednich krokach:

• Dla każdego urządzenia Usługi Azure Stack Edge przeniesionego do regionu kopii zapasowej (wykonując kroki opisane w temacie Odzyskiwanie) należy znaleźć i usunąć stary zasób klastra ARC. Identyfikator tego zasobu znajduje się w polu packetCoreControlPlane.platform.customLocation z wartości, które zostały zarchiwizowane podczas Przygotowania. Stan tego zasobu zostanie odłączony , ponieważ odpowiedni klaster Kubernetes został usunięty w ramach procesu odzyskiwania.
• Dla każdego rdzenia pakietów, który został przeniesiony do regionu kopii zapasowej (zgodnie z krokami w sekcji Odzyskiwanie), należy znaleźć i usunąć wszystkie obiekty NFM w odzyskanym regionie. Zostaną one wymienione w tej samej grupie zasobów co zasoby płaszczyzny kontroli rdzeni pakietów, a wartość regionu będzie zgodna z odzyskanym regionem.

Następnie możesz wybrać dwie opcje ciągłego zarządzania:

• Użyj regionu kopii zapasowej operacyjnej jako nowego regionu podstawowego i użyj odzyskanego regionu jako kopii zapasowej. Nie są wymagane żadne dalsze działania.
• Utwórz odzyskany region jako nowy aktywny region podstawowy, postępując zgodnie z instrukcjami w temacie Przenoszenie zasobów do innego regionu , aby przełączyć się z powrotem do odzyskanego regionu.

Testowanie

Jeśli chcesz przetestować plany odzyskiwania po awarii, możesz wykonać procedurę odzyskiwania dla pojedynczego rdzenia pakietów w dowolnym momencie. Należy pamiętać, że spowoduje to przerwę w działaniu usługi rdzenia pakietów i przerwanie łączności sieciowej z urządzeniami użytkownika przez maksymalnie cztery godziny, dlatego zalecamy wykonanie tej czynności tylko w przypadku wdrożeń rdzeni pakietowych w niestandardowych zastosowaniach lub w czasie, gdy taka przerwa nie wpłynie negatywnie na Twoją firmę.

Następne kroki

• Niezawodność na platformie Azure