Niezawodność platformy Azure Private 5G Core

W tym artykule opisano obsługę niezawodności w prywatnej sieci 5G Core platformy Azure. Obejmuje ona zarówno regionalną odporność ze strefamidostępności, jak i odzyskiwaniem po awarii między regionami oraz 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 platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.

Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.

Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.

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, zgodnie z opisem w temacie Usługa strefy dostępności i obsługa regionalna. 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.

Środowisko strefowe w dół

W scenariuszu awarii całej strefy użytkownicy nie powinni mieć żadnego wpływu, ponieważ usługa zostanie przeniesiona w celu automatycznego korzystania ze strefy w dobrej kondycji. Na początku awarii całej strefy może zostać wyświetlony limit czasu lub niepowodzenie żądań usługi ARM w toku. Nowe żądania będą kierowane do węzłów w dobrej kondycji z zerowym wpływem 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.

Sejf technik 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 jest uruchomiony w przeglądarce Edge i nie ma to wpływu na awarię strefy, więc będzie nadal zapewniać usługę dla użytkowników.

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

Odzyskiwanie po awarii dotyczy 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. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.

Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie 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 regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.

Prywatna 5G Platformy Azure jest dostępna tylko w lokalizacjach geograficznych obejmujących wiele regionów (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 poświadczenia SIM należące do usługi do regionu tworzenia kopii zapasowej przy użyciu zapisów w wielu regionach usługi 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ę tylko do odczytu, ale zasoby we wszystkich innych regionach będą nadal działać bez wpływu. 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 w innym regionie, który obsługuje prywatną 5G Core platformy Azure. Po wystąpieniu awarii regionu można ponownie wdrożyć rdzeń 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 maszyny 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 można jeszcze połączyć konfiguracji rdzeni pakietów ze sprzętem brzegowym. Zamiast tego należy przechowywać wartości z pola packetCoreControlPlanes.platform dla każdego rdzenia pakietów w bezpiecznej lokalizacji, do której można uzyskać dostęp, kto wykona procedurę odzyskiwania (na przykład konto magazynu 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 maszyny SIM są dodawane do usługi podstawowej, te same maszyny SIM są również dodawane do usługi tworzenia kopii zapasowych, powtarzając proces Aprowizuj nowe maszyny 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.

Odzyskiwania

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. Połączenie urządzenia Azure Stack Edge do regionu kopii zapasowej
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 podstawowej pakietu i przerwanie łączności sieciowej z interfejsami użytkownika przez maksymalnie osiem godzin dla każdego rdzenia pakietów. 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.

Połączenie urządzenia Azure Stack Edge do nowego regionu

Postępuj zgodnie z instrukcjami podanymi w temacie Commission the AKS cluster to redeploy the Azure Kubernetes Service cluster on your Azure Stack Edge device (Ponowne wdrażanie klastra 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 lokalizacji niestandardowej dla klastra, który należy zanotować.

Ponowne instalowanie i walidacja

Wykonaj kopię wartości packetCoreControlPlanes.platform przechowywanych w sekcji Przygotowanie i zaktualizuj pole packetCoreControlPlane.platform.customLocation za pomocą identyfikatora lokalizacji niestandardowej zanotowanych powyżej. Upewnij się, że element packetCoreControlPlane.platform.azureStackEdgeDevice jest zgodny z identyfikatorem urządzenia Azure Stack Edge, na którym chcesz zainstalować rdzeń pakietów. Teraz postępuj zgodnie z instrukcjami Modyfikowanie rdzenia pakietów, aby zaktualizować rdzeń pakietu kopii zapasowej przy użyciu wartości platformy. Spowoduje to wyzwolenie wdrożenia rdzeni pakietów na urządzeniu Azure Stack Edge.

Należy postępować zgodnie z normalnym procesem weryfikacji nowej instalacji lokacji, aby potwierdzić, że łączność UE została przywrócona, a wszystkie funkcje sieciowe działają. W szczególności należy potwierdzić, że pulpity nawigacyjne witryny w witrynie Azure Portal pokazują rejestracje ue i że dane przepływają przez płaszczyznę danych.

Przywrócony region nie powiodło się

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órych kopia zapasowa została utworzona w ramach 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ść Region 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 awarię usługi podstawowej usługi pakietów i przerwanie łączności sieciowej z interfejsami użytkownika przez maksymalnie cztery godziny, dlatego zalecamy wykonanie tej czynności tylko w przypadku wdrożeń rdzeni pakietów nieprodukcyjnych lub w czasie, gdy awaria nie wpłynie negatywnie na Twoją firmę.

Następne kroki

• Niezawodność na platformie Azure