Niezawodność w usłudze Azure Notification Hubs

Azure Notification Hubs ułatwia zarządzanie powiadomieniami wypychanymi w wielu systemach powiadomień platformowych (PNS), takich jak Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM) i Windows Push Notification Service (WNS).

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Microsoft oferuje szereg funkcjonalności wspierających odporność i odzyskiwanie. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano, jak usługa Notification Hubs jest odporna na różne potencjalne awarie i problemy, w tym błędy przejściowe, awarie strefy dostępności, awarie całego regionu i konserwacja usługi. Opisano również opcje tworzenia i przywracania kopii zapasowych oraz kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Notification Hubs.

Zalecenia dotyczące wdrażania produkcyjnego

W przypadku obciążeń produkcyjnych wykonaj następujące zalecenia:

  • Użyj warstwy Podstawowa lub Standardowa, aby twoja przestrzeń nazw kwalifikowała się do umowy SLA.

  • Jeśli to możliwe, użyj instalacji zamiast rejestracji w aplikacjach urządzeń.

  • Użyj zestawów SDK dostępnych Microsoft do interakcji z usługą Notification Hubs.

  • Aktywuj replikację strefy.

  • Aby przygotować się do awarii w całym regionie, włącz odzyskiwanie po awarii metadanych do innego regionu Azure. Planowanie tworzenia kopii zapasowych i przywracania rejestracji i instalacji urządzeń.

Omówienie architektury niezawodności

Azure Notification Hubs jest zorganizowana wokół przestrzeni nazw i centrów powiadomień. Przestrzeń nazw to granica zarządzania zawierająca co najmniej jeden koncentrator. Koncentratory reprezentują punkty końcowe dla aplikacji. Urządzenia rejestrują się w tych punktach końcowych za pomocą rejestracji lub instalacji, które pozwalają usłudze wysyłać powiadomienia push do urządzeń. Aby uzyskać więcej informacji, zobacz Zarządzanie rejestracją.

Usługa Notification Hubs wysyła powiadomienia push do systemów powiadomień na platformach (PNS), takich jak Apple Push Notification Service (APNs) i Firebase Cloud Messaging (FCM). Kompleksowe dostarczanie powiadomień zależy od dostępności usługi Notification Hubs i zachowania podrzędnych dostawców systemu powiadomień.

W przypadku planowania niezawodności ważne jest rozróżnienie między następującymi typami danych zarządzanych przez usługę Notification Hubs:

  • Metadane: Konfiguracja przestrzeni nazw i centrum, w tym informacje o połączeniu i konfiguracja odzyskiwania po awarii.
  • Dane rejestracyjne: Rejestracje i instalacje urządzeń, które przypisują użytkowników i urządzenia do tagów i szablonów.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Usługa Notification Hubs automatycznie obsługuje błędy przejściowe występujące podczas nawiązywania połączenia z usługą PNS. Jednak odpowiadasz za obsługę przejściowych błędów, gdy usługi lub urządzenia użytkowników wchodzą w interakcję z usługą Notification Hubs. Błędy przejściowe mogą wystąpić podczas operacji rejestracji, operacji wysyłania powiadomień i operacji zarządzania. Postępuj zgodnie z poniższymi wskazówkami:

  • Rejestracje i instalacje: Aplikacje na urządzeniach powinny ponowić próbę rejestracji i operacji instalacji, które kończą się niepowodzeniem z powodu przejściowych błędów. Microsoft dostarczane zestawy SDK automatycznie obsługują ponawianie prób. Jeśli nie możesz użyć udostępnionych pakietów SDK, zaimplementuj logikę ponawiania z wykładniczo wydłużanymi odstępami i losowym rozproszeniem opóźnień, a tam, gdzie to możliwe, zapewnij idempotentność operacji rejestracji.

    Tworzenie lub aktualizowanie instalacji jest idempotentne, więc można bezpiecznie ponowić operację. Jeśli to możliwe, użyj instalacji zamiast rejestracji.

  • Powiadomienia wysyłane i operacje zarządzania: Użyj zestawu SDK dostarczonego Microsoft, aby wysyłać powiadomienia wypychane i wykonywać operacje zarządzania. Te pakiety SDK automatycznie ponawiają próbę w przypadku wystąpienia błędów przejściowych.

    Jeśli nie możesz użyć dostarczonych pakietów SDK, zaimplementuj logikę ponawiania z wykładniczo wydłużanymi odstępami i losowym opóźnieniem oraz, w miarę możliwości, spraw, aby operacje wysyłania powiadomień były idempotentne.

Odporność na błędy strefy dostępności

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

W regionach, które obsługują strefy dostępności, przestrzenie nazw usługi Notification Hubs obsługują konfigurację nadmiarową między strefami. Notification Hubs automatycznie włącza funkcję nadmiarowości stref dla wszystkich przestrzeni nazw w niektórych regionach. Po włączeniu nadmiarowości strefowej firma Microsoft replikuje zarówno metadane, jak i dane rejestracji we wszystkich strefach dostępności w regionie.

Diagram przedstawiający strefowo nadmiarową przestrzeń nazw usługi Notification Hubs, która używa trzech stref dostępności w regionie.

Requirements

  • Obsługa regionów:

    Usługa Notification Hubs automatycznie włącza nadmiarowość strefową we wszystkich przestrzeniach nazw w następujących regionach. Nie można wyłączyć nadmiarowości stref w następujących regionach:

    Europa Bliski Wschód Africa Azja i Pacyfik
    Francja Środkowa Katar Środkowy Północna Republika Południowej Afryki Chiny Północne 3
    Włochy Północne Korea Środkowa
    Norwegia Wschodnia
    Polska Środkowa
    Szwecja Środkowa
    Szwajcaria Północna

    W innych regionach, które obsługują usługę Notification Hubs i mają strefy dostępności, nadmiarowość strefowa jest opcjonalna. Można ją włączyć tylko podczas tworzenia przestrzeni nazw.

  • Obsługiwane warstwy: Ze stref dostępności można korzystać ze wszystkimi warstwami usługi Notification Hubs.

Cost

Nadmiarowość strefowa wiąże się z dodatkową opłatą oprócz ceny warstwy. Aby uzyskać więcej informacji, zobacz Cennik usługi Notification Hubs.

Konfiguruj obsługę stref dostępności

  • Utwórz nową strefowo nadmiarową przestrzeń nazw: Proces tworzenia nowej strefowo nadmiarowej przestrzeni nazw zależy od używanego regionu:

    • W regionach, w których usługa Notification Hubs automatycznie włącza nadmiarowość strefy, nie trzeba jej konfigurować.

      Ważna

      W tych regionach usługa Notification Hubs zawsze tworzy przestrzenie nazw z włączoną nadmiarowością strefową, nawet jeśli wdrożenie oparte na kodzie, takie jak plik Bicep lub szablon Azure Resource Manager, wskazuje, że nadmiarowość strefowa jest wyłączona.

      Jeśli nie chcesz strefowo nadmiarowej przestrzeni nazw, utwórz ją w regionie obsługującym opcjonalną nadmiarowość strefy.

    • W regionach, w których nadmiarowość stref jest opcjonalna, można ją włączyć wyłącznie podczas tworzenia przestrzeni nazw. Aby dowiedzieć się, jak skonfigurować nową przestrzeń nazw z nadmiarowością strefową, zobacz Tworzenie centrum powiadomień platformy Azure w witrynie Azure Portal.

  • Utwórz istniejącą strefę przestrzeni nazw jako strefę nadmiarową: Usługa Notification Hubs nie obsługuje migracji w miejscu istniejącej przestrzeni nazw do obsługi stref dostępności. Musisz wdrożyć nową przestrzeń nazw i przenieść rejestracje do tej przestrzeni nazw. Postępuj zgodnie ze wskazówkami w artykule Przenoszenie zasobów między regionami Azure, które mają zastosowanie również w przypadku wdrożenia nowej przestrzeni nazw w tym samym regionie.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania przestrzeni nazw usługi Notification Hubs pod kątem nadmiarowości strefowej, gdy wszystkie strefy są sprawne.

  • Operacja między strefami: Usługa Notification Hubs automatycznie dystrybuuje i obsługuje żądania przy użyciu infrastruktury w dowolnej strefie w regionie.

  • Replikacja danych między strefami: Zarówno dane rejestracji, jak i metadane są synchronicznie replikowane we wszystkich strefach w określonym regionie.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego należy się spodziewać podczas konfigurowania obszaru nazw usługi Notification Hubs pod kątem nadmiarowości strefowej, jeśli w jednej ze stref wystąpi awaria.

  • Wykrywanie i reagowanie: Microsoft wykrywa awarie stref i zarządza przełączaniem awaryjnym w regionie. Nie musisz inicjować trybu failover.
  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Można jednak użyć Azure Service Health aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty Service Health w celu powiadamiania o problemach.

  • Aktywne żądania: Operacje zarządzania w locie, rejestracje urządzeń i nowe żądania wysyłania powiadomień mogą zakończyć się niepowodzeniem podczas pracy w trybie failover. Aplikacje powinny ponowić próbę niepowodzenia operacji, postępując zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych.

  • Oczekiwana utrata danych: Utrata danych nie jest oczekiwana podczas awarii pojedynczej strefy, ponieważ usługa Notification Hubs synchronicznie replikuje przestrzeń nazw i dane konfiguracji centrum i rejestracji w różnych strefach dostępności.

    Ta replikacja nie jest kopią zapasową. W ramach modelu wspólnej odpowiedzialności odpowiadasz za tworzenie kopii zapasowych danych rejestracji i instalacji. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie.

  • Przewidywany przestój: Możliwa jest krótka przerwa w działaniu usługi, gdy firma Microsoft przekierowuje ruch. Postępuj zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych , aby przygotować aplikacje do tych przerw.

  • Redystrybucja: Usługa automatycznie przekierowuje żądania do stref w dobrej kondycji.

Odzyskiwanie strefy

Po odzyskaniu strefy, której dotyczy problem, nie musisz podejmować żadnych działań. Microsoft przywraca i ponownie równoważy infrastrukturę usługi Notification Hubs w celu korzystania z odzyskanej strefy.

Testowanie pod kątem niepowodzeń strefy

Nie można bezpośrednio zainicjować przełączenia awaryjnego strefy usługi Notification Hubs. Aby przetestować sposób działania obciążenia, uruchom testy odporności pod kątem ponownych prób, idempotencji i awarii zależności w środowiskach nieprodukcyjnych. Można również użyć Azure Chaos Studio do testowania otaczających składników aplikacji.

Odporność na awarie całego regionu

Usługa Notification Hubs zapewnia odzyskiwanie metadanych po awarii przez replikowanie metadanych przestrzeni nazw między regionami, ale nie replikuje danych rejestracji urządzeń. Ta funkcja wymaga ręcznej interwencji w przypadku awarii regionu i wiąże się z pewnym przestojem centrum powiadomień.

Jeśli chcesz zmniejszyć przestoje i ręczną interwencję podczas pracy w trybie failover, rozważ użycie niestandardowego rozwiązania wieloregionowego.

Metadane zarządzane przez firmę Microsoft na potrzeby geograficznego odzyskiwania po awarii

Usługa Notification Hubs obsługuje odzyskiwanie po awarii metadanych zarządzanych Microsoft do pomocniczego regionu Azure. Jeśli region podstawowy ma sparowany region, możesz wybrać ten sparowany region. Niezależnie od stanu parowania regionu podstawowego można również wybrać region pomocniczy z listy elastycznych regionów odzyskiwania. Usługa Notification Hubs replikuje następnie metadane przestrzeni nazw, takie jak nazwa przestrzeni nazw, parametry połączenia i inne informacje krytyczne.

Diagram przedstawiający odzyskiwanie po awarii metadanych usługi Notification Hubs z regionu podstawowego do regionu pomocniczego.

Ważna

Odzyskiwanie po awarii geograficznej metadanych nie replikuje danych rejestracji. Jeśli zostanie wyzwolony scenariusz odzyskiwania po awarii, dane rejestracji i instalacji mogą zostać utracone. Odpowiadasz za zaimplementowanie rozwiązania w celu ponownego wypełniania danych rejestracji w centrum po odzyskiwaniu.

Microsoft jest odpowiedzialny za deklarowanie awarii i inicjowanie trybu failover. W takim przypadku Microsoft tworzy nową przestrzeń nazw w regionie pomocniczym. Ponieważ używa metadanych z regionu podstawowego, aplikacje mogą łączyć się z tą przestrzenią nazw za pomocą istniejącej nazwy przestrzeni nazw, parametrów połączenia i nazw centrów.

Diagram przedstawiający przełączenie awaryjne z podstawowego regionu usługi Notification Hubs do regionu pomocniczego.

Requirements

  • Obsługa regionów: W sparowanych regionach platformy Azure przestrzeń nazw może używać sparowanego regionu platformy Azure jako regionu pomocniczego.

    Jeśli przestrzeń nazw znajduje się w regionie nienależącym do pary lub chcesz replikować dane do innego regionu, możesz wybrać jeden z następujących elastycznych regionów odzyskiwania awaryjnego jako region dodatkowy:

    Ameryka Europa Africa Azja i Pacyfik
    Brazylia Południowa Europa Północna Północna Republika Południowej Afryki Australia Wschodnia
    Zachodnie stany USA 2 Azja Południowo-Wschodnia

  • Obsługa warstw: Opcje odzyskiwania po awarii metadanych są dostępne we wszystkich warstwach usługi Notification Hubs.

Cost

Usługa Notification Hubs nie pobiera dodatkowych opłat w celu skonfigurowania ani użycia odzyskiwania po awarii geograficznej metadanych. Jednak płacisz za przepustowość między regionami używaną do replikowania metadanych. Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik przepustowości i Cennik usługi Notification Hubs.

Konfigurowanie obsługi wielu regionów

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można się spodziewać podczas konfigurowania przestrzeni nazw usługi Notification Hubs na potrzeby geograficznego odzyskiwania po awarii metadanych, gdy zarówno region podstawowy, jak i pomocniczy są operacyjne.

  • Operacja między regionami: Region podstawowy obsługuje wszystkie żądania. Region pomocniczy nie obsługuje żądań, chyba że nastąpi przełączenie awaryjne.

  • Replikacja danych między regionami: Metadane, takie jak nazwa przestrzeni nazw, konfiguracja centrum, parametry połączenia i inne krytyczne informacje, są replikowane asynchronicznie w różnych regionach. Dane rejestracji nie są replikowane. Odpowiadasz za regularne eksportowanie go w celu utrzymania kopii zapasowej.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania przestrzeni nazw usługi Notification Hubs na potrzeby geograficznego odzyskiwania po awarii metadanych oraz gdy wystąpi awaria w regionie podstawowym.

  • Wykrywanie i reagowanie: Microsoft jest odpowiedzialny za wykrywanie awarii regionu i podejmowanie decyzji o tym, czy wyzwalać tryb failover do skonfigurowanego regionu pomocniczego.
  • Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Można jednak użyć Azure Service Health, aby zrozumieć ogólną kondycję usługi, w tym awarie regionów, i skonfigurować alerty Service Health w celu powiadomienia o problemach.

  • Aktywne żądania: Żądania w toku kierowane do przestrzeni nazw w regionie podstawowym mogą zakończyć się niepowodzeniem, gdy region stanie się niedostępny. Klienci powinni ponowić operacje po zakończeniu przełączenia awaryjnego.

  • Oczekiwana utrata danych: Metadane są zachowywane. Dane rejestracji nie są automatycznie tworzone, ale możesz utworzyć kopię zapasową samodzielnie. Aby uzyskać więcej informacji, zobacz Zbiorcze eksportowanie i importowanie rejestracji usługi Azure Notification Hubs. Jeśli tego nie zrobisz, dane rejestracji będą niedostępne do czasu odzyskania regionu podstawowego.

  • Oczekiwany przestój: Uruchomienie przez firmę Microsoft mechanizmu przełączenia awaryjnego metadanych, a następnie zakończenie tego procesu, zajmuje pewien czas. Chociaż czas może się różnić, zazwyczaj trwa kilka godzin.

    Po zakończeniu pracy w trybie failover odpowiadasz za przywrócenie kopii zapasowych danych rejestracji.

  • Redystrybucja: Po przełączeniu awaryjnym żądania są kierowane do przestrzeni nazw w regionie pomocniczym, która korzysta z replikowanych danych z regionu podstawowego. Po zakończeniu przełączenia awaryjnego klienci automatycznie łączą się z przestrzenią nazw w regionie pomocniczym.

Odzyskiwanie regionów

Jeśli region podstawowy wróci do działania, możliwy będzie powrót po awarii do podstawowej przestrzeni nazw w regionie podstawowym. Podstawowa przestrzeń nazw zachowa dane rejestracji przed awarią. Byłby to proces ręczny, a firma Microsoft skontaktowałaby się z Tobą, aby wyjaśnić, jak to działa.

Po odzyskaniu regionu podstawowego należy wykonać następujące działania:

  • Zweryfikuj stan przestrzeni nazw i jej danych.
  • Ustal, czy chcesz zsynchronizować ostatnie zmiany danych rejestracji z regionu pomocniczego z powrotem do regionu podstawowego.

Testowanie pod kątem błędów regionów

Nie można zainicjować trybu failover geograficznego. Należy jednak przetestować własne procedury odzyskiwania po awarii. Sprawdź, czy utworzono kopię zapasową rejestracji i czy można je przywrócić do nowej przestrzeni nazw.

Niestandardowe rozwiązania wieloregionowe zapewniające odporność

Geograficzne odzyskiwanie po awarii metadanych zarządzanych przez firmę Microsoft replikuje tylko metadane. Funkcja może odzyskać te metadane do pomocniczej przestrzeni nazw, ale odpowiadasz za importowanie rejestracji urządzeń do tej przestrzeni nazw, aby aplikacja mogła nadal działać. Takie podejście wymaga ręcznej interwencji podczas awarii i obejmuje przestoje.

Jeśli cele dotyczące odzyskiwania zakładają krótszy przestój lub mniejszą potrzebę ręcznej interwencji, możesz wdrożyć niestandardowe rozwiązanie wieloregionowe typu active-active. Wdróż drugą przestrzeń nazw usługi Notification Hubs w innym regionie Azure z wyprzedzeniem.

Uwaga / Notatka

Ta sekcja zawiera podstawowe wskazówki dotyczące projektowania tego typu rozwiązania. Odpowiadasz za projektowanie, implementację, testowanie, wdrażanie, przełączanie awaryjne i zarządzanie rozwiązaniem.

  • Przełączanie awaryjne: Ponieważ druga przestrzeń nazw jest aktywnym zasobem, można wdrożyć logikę wykrywania awarii regionu i przełączania się do tej przestrzeni nazw.

  • Synchronizacja: Aby zachować synchronizację drugiego centrum powiadomień z podstawowym centrum powiadomień, użyj jednej z następujących opcji:

    • W przypadku instalacji: Użyj zaplecza aplikacji, który jednocześnie tworzy i aktualizuje instalacje w obu centrach powiadomień. Instalacje umożliwiają określenie własnego unikatowego identyfikatora urządzenia, który obsługuje ten scenariusz replikacji. Aby uzyskać więcej informacji, zobacz przykład RedundantHub.

    • W przypadku rejestracji: Użyj zaplecza aplikacji, który regularnie eksportuje rejestracje z podstawowego centrum powiadomień jako kopię zapasową i importuje je zbiorczo do pomocniczego centrum powiadomień. Aby uzyskać więcej informacji, zobacz artykuł Zbiorczy eksport i import rejestracji usługi Azure Notification Hubs.

    Alternatywnie, jeśli nie masz zaplecza, skonfiguruj aplikację do tworzenia instalacji w obu centrach po uruchomieniu aplikacji na urządzeniach docelowych. Urządzenia tworzą nowe rejestracje w obu centrach powiadomień. W końcu pomocnicze centrum powiadomień ma zarejestrowane wszystkie aktywne urządzenia.

  • Wygasłe rejestracje i instalacje: Pomocnicze centrum powiadomień mogło mieć wygasłe rejestracje i instalacje. Gdy powiadomienie push zostanie wysłane do wygasłego uchwytu, usługa Notification Hubs automatycznie usuwa skojarzony rekord rejestracji lub instalacji w centrum powiadomień na podstawie odpowiedzi otrzymanej z serwera PNS. Możesz usunąć wygasłe rekordy z wybranego rozwiązania do tworzenia kopii zapasowych, dodając własną logikę, która przetwarza informacje zwrotne z każdej wysyłki i usuwa wygasłe rejestracje oraz instalacje.

  • Nieotwarte aplikacje: Istnieje okres, w którym urządzenia z nieotwartymi aplikacjami nie otrzymują powiadomień.

  • Koszt: Jeśli używasz własnego centrum pomocniczego do ochrony danych rejestracji, to centrum poniesie normalne opłaty za usługę. Podobnie, jeśli wdrożysz jakiekolwiek inne zasoby platformy Azure w regionie pomocniczym na potrzeby odzyskiwania, płacisz za nie według standardowych stawek za usługi.

Tworzenie kopii zapasowej i przywracanie

Usługa Notification Hubs nie udostępnia jednej wbudowanej funkcji tworzenia kopii zapasowej i przywracania dla wszystkich danych przechowywanych w przestrzeni nazw. Odpowiadasz za połączenie następujących metod:

  • Użyj infrastruktury jako kodu (IaC), takiego jak Bicep, aby zdefiniować przestrzeń nazw, centrum i konfigurację zasad. Przechowuj te definicje w kontroli źródła, aby w razie potrzeby można było ponownie wdrożyć zasoby.
  • Utwórz kopię zapasową danych rejestracji urządzenia przez zbiorcze eksportowanie rejestracji z usługi Azure Notification Hubs.

Odporność usługi na prace konserwacyjne

Firma Microsoft regularnie stosuje aktualizacje usług i wykonuje inną konserwację. Platforma Azure automatycznie obsługuje te działania, zapewniając bezproblemową i przejrzystą konserwację. Podczas zdarzeń konserwacji nie przewiduje się przestoju, chyba że poinformowano Cię o zaplanowanej konserwacji Azure Service Health.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

W przypadku usługi Notification Hubs umowa SLA dotycząca dostępności dotyczy przestrzeni nazw korzystających z warstw Podstawowa i Standardowa.

Treści powiązane

  • Last updated on