Udostępnij przez

Niezawodność w usłudze Azure IoT Hub

Azure IoT Hub to zarządzana usługa hostowana w chmurze, która działa jako centralne centrum komunikatów do komunikacji między aplikacją IoT a dołączonymi urządzeniami.

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

W tym artykule opisano, jak zapewnić odporność usługi IoT Hub na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. W tym artykule opisano również, jak można używać kopii zapasowych do odzyskiwania po innych typach problemów, oraz wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi IoT Hub.

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 IoT Hub zapewnia dość wysoką gwarancję czasu pracy, ale błędy przejściowe mogą wystąpić na dowolnej platformie przetwarzania rozproszonego. Aby obsłużyć błędy przejściowe, utwórz odpowiednie wzorce ponawiania prób w składnikach, które wchodzą w interakcje z aplikacjami w chmurze.

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.

Usługa IoT Hub obsługuje dwa różne typy obsługi stref dostępności:

  • Nadmiarowość strefowa dla danych, która automatycznie replikuje dane między wieloma strefami dostępności dla komponentów magazynujących, przechowujących rejestr tożsamości urządzeń oraz komunikaty z urządzenia do chmury.

  • Nadmiarowość stref dla obliczeń, która zapewnia niezawodność w składnikach odpowiedzialnych za zarządzanie urządzeniami i routing wiadomości.

Obsługa regionów

Typ obsługi strefy dostępności centrum IoT zależy od regionu, w którym jest wdrożony.

Rejon Redundancja stref danych Nadmiarowość strefowa dla obliczeń
Australia Wschodnia Tak Tak
Brazylia Południowa Tak Tak
Kanada Środkowa Tak Tak
Indie Środkowe Nie. Tak
Środkowe stany USA Tak Tak
Wschodnie stany USA Nie. Tak
Francja Środkowa Tak Tak
Niemcy Środkowo-Zachodnie Tak Tak
Japonia Wschodnia Tak Tak
Korea Środkowa Nie. Tak
Europa Północna Tak Tak
Norwegia Wschodnia Nie. Tak
Katar Środkowy Nie. Tak
Południowo-środkowe stany USA Nie. Tak
Azja Południowo-Wschodnia Tak Tak
Południowe Zjednoczone Królestwo Tak Tak
Europa Zachodnia Nie. Tak
Zachodnie stany USA 2 Tak Tak
Zachodnie stany USA 3 Nie. Tak

Centra IoT tworzone w regionach, które nie znajdują się na tej liście, nie są odporne na awarie stref.

Koszt

Redundancja strefowa w usłudze IoT Hub nie wiąże się z dodatkowymi kosztami.

Konfiguruj obsługę stref dostępności

Zasoby usługi IoT Hub automatycznie obsługują nadmiarowość stref po wdrożeniu w obsługiwanych regionach. Nie trzeba konfigurować niczego więcej.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi IoT Hub są skonfigurowane z myślą o nadmiarowości strefowej, a wszystkie strefy dostępności działają.

  • Replikacja danych między strefami: Gdy centrum IoT jest wdrażane w regionie obsługującym nadmiarowość stref dla danych, zmiany w danych są replikowane automatycznie między strefami dostępności. Replikacja odbywa się synchronicznie.

  • Routing ruchu między strefami: Po wdrożeniu centrum IoT w regionie obsługującym nadmiarowość stref dla składników obliczeniowych, żądania są kierowane do wystąpienia podstawowego usługi w jednej ze stref dostępności. Platforma Azure automatycznie wybiera aktywne wystąpienie i strefę.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać po skonfigurowaniu zasobów usługi IoT Hub z uwzględnieniem nadmiarowości stref i w przypadku awarii strefy dostępności.

  • Wykrywanie i reagowanie: Usługa IoT Hub jest odpowiedzialna za wykrywanie awarii w strefie dostępności. Nie musisz nic robić, aby zainicjować tryb failover strefy.

  • Aktywne żądania: Podczas awarii strefy aktywne żądania mogą zostać porzucone. Klienci i urządzenia powinny mieć wystarczającą logikę ponawiania prób zaimplementowaną w celu obsługi błędów przejściowych.

  • Oczekiwana utrata danych: Po wdrożeniu centrum IoT w regionie obsługującym nadmiarowość stref dla danych awaria strefy nie powinna powodować utraty danych.

  • Oczekiwany przestój: Po wdrożeniu centrum IoT w regionie obsługującym nadmiarowość stref dla składników obliczeniowych i danych awaria strefy nie powinna powodować przestoju zasobów usługi IoT Hub.

  • Przekierowywanie ruchu: Po wdrożeniu centrum IoT w regionie obsługującym nadmiarowość stref dla składników obliczeniowych usługa IoT Hub wykrywa utratę strefy. Następnie wszystkie nowe żądania są automatycznie przekierowywane do nowego wystąpienia podstawowego usługi w jednej z dostępnych stref o dobrej kondycji.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana, usługa IoT Hub automatycznie przywraca instancje w strefie dostępności i przekierowuje ruch między instancjami jak poprzednio.

Testowanie pod kątem niepowodzeń strefy

Ponieważ usługa IoT Hub w pełni zarządza routingiem ruchu, trybem failover i powrotem po awarii strefy, nie musisz weryfikować procesów awarii strefy dostępności ani udostępniać żadnych dalszych danych wejściowych.

Odporność na awarie całego regionu

Usługa IoT Hub jest usługą jednoregionową. Jeśli region stanie się niedostępny, zasoby usługi IoT Hub są również niedostępne.

Jeśli jednak zasoby znajdują się w sparowanym regionie, dane centrum IoT są replikowane do sparowanego regionu.

Centrum IoT może przełączyć się do sparowanego regionu w następujących scenariuszach:

  • Awaria zainicjowana przez klienta: Możesz samodzielnie aktywować ręczne przełączenie do sparowanego regionu, niezależnie od tego, czy region ma przestój, czy nie. Za pomocą tego podejścia można przeprowadzać planowane failovery i symulacje awaryjne.

  • Tryb awaryjny zainicjowany przez firmę Microsoft: Jeśli region zostanie utracony, firma Microsoft może zainicjować przełączenie na tryb awaryjny centrów IoT do sparowanego regionu. Jednak jest mało prawdopodobne, że firma Microsoft zainicjuje tryb failover, chyba że po znacznym opóźnieniu i na zasadzie najlepszych starań. Przejście w tryb failover zasobów usługi IoT Hub może wystąpić w innym czasie niż przejście w tryb failover innych usług platformy Azure. Ten proces jest opcją domyślną i nie wymaga interwencji użytkownika.

Jeśli zasoby znajdują się w nie sparowanym regionie, firma Microsoft nie replikuje konfiguracji i danych między regionami i nie ma wbudowanego mechanizmu przełączania awaryjnego między regionami. Można jednak wdrożyć oddzielne zasoby w wielu regionach. W tym scenariuszu twoim zadaniem jest zarządzanie replikacją, dystrybucją ruchu i trybem failover.

Jeśli centrum IoT znajduje się w regionie niepowiązanym albo jeśli domyślne zachowanie replikacji i failoveru nie spełnia Twoich potrzeb, możesz użyć niestandardowych rozwiązań wieloregionalnych w celu zapewnienia odporności, aby zaplanować i zainicjować failover.

Obsługa regionów

Wsparcie dla domyślnej replikacji i trybu failover jest dostępne tylko w sparowanych regionach.

Wymagania

Opcje replikacji sparowanego regionu i trybu failover są dostępne dla wszystkich warstw usługi IoT Hub.

Rozważania

Nie używaj trybu failover zainicjowanego przez klienta, aby trwale migrować centrum pomiędzy sparowanymi regionami platformy Azure. Ogólnie rzecz biorąc, urządzenia znajdują się w pobliżu regionu podstawowego centrum. W przypadku przeniesienia centrum do regionu pomocniczego opóźnienie zwiększa się w przypadku operacji między urządzeniami a centrum IoT w lokalizacji pomocniczej.

Koszt

W przypadku centrów w sparowanych regionach nie ma dodatkowych kosztów replikacji danych między regionami ani przełączenia awaryjnego.

Jeśli centrum IoT znajduje się w niezwiązanym regionie, zobacz Niestandardowe rozwiązania obejmujące wiele regionów w celu uzyskania odporności, aby uzyskać informacje o możliwych kosztach.

Konfigurowanie replikacji i przygotowywanie do przełączenia awaryjnego

Domyślnie replikacja danych między regionami jest automatycznie konfigurowana podczas tworzenia centrum IoT w sparowanym regionie. Ten proces jest opcją domyślną i nie wymaga interwencji użytkownika. W regionach z wyjątkiem Brazylii Południowej i Azji Południowo-Wschodniej (Singapur) dane klientów nie są przechowywane ani przetwarzane poza lokalizacją geograficzną, w której wdrażasz wystąpienie usługi.

Jeśli centrum IoT znajduje się w regionach Brazylii Południowej lub Azji Południowo-Wschodniej (Singapur), możesz wyłączyć replikację danych i zrezygnować z trybu failover. Aby uzyskać więcej informacji, zobacz Wyłączanie odzyskiwania po awarii (DR).

Jeśli centrum IoT znajduje się w regionie niepowiązanym, musisz zaplanować własną replikację międzyregionową i podejście do przełączenia awaryjnego. Aby uzyskać więcej informacji, zobacz Niestandardowe wieloregionowe rozwiązania dla odporności.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy centrum IoT jest skonfigurowane na potrzeby replikacji między regionami i trybu failover, a region podstawowy działa.

  • Replikacja danych między regionami: Dane są replikowane automatycznie do sparowanego regionu. Replikacja odbywa się asynchronicznie, co oznacza, że niektóre straty danych są oczekiwane w przypadku przejścia w tryb failover. Nie ma replikacji danych między regionami dla IoT hubów w regionach, które nie są sparowane.

  • Routing ruchu między regionami: W normalnych operacjach ruch przepływa tylko do regionu podstawowego.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać po skonfigurowaniu centrum IoT na potrzeby replikacji między regionami i przełączenia awaryjnego w przypadku awarii w regionie głównym.

  • Wykrywanie i reagowanie: Odpowiedzialność za wykrywanie awarii i reagowanie na nie w regionie podstawowym może się różnić.

    • Zainicjowane przez klienta przełączenie awaryjne: Jesteś odpowiedzialny za wykrywanie utraty dostępności regionu i podejmowanie decyzji o tym, kiedy należy przejść na przełączenie awaryjne. Aby uzyskać więcej informacji na temat sposobu przeprowadzania trybu failover zainicjowanego przez klienta między sparowanymi regionami, zobacz Wykonywanie ręcznego przejścia w tryb failover dla centrum IoT.

      Istnieją ograniczenia dotyczące częstotliwości, z jaką można przeprowadzić failover zainicjowany przez klienta lub failback.

      • Użytkownicy mogą wykonywać dwie pomyślne operacje failover i dwie pomyślne operacje failback dziennie.

      • Nie są dozwolone operacje przełączania awaryjnego lub failback pod rząd. Musisz poczekać godzinę między tymi operacjami.

    • Failover zainicjowany przez firmę Microsoft: Firma Microsoft może zdecydować się na przeprowadzenie failoveru w przypadku utraty regionu podstawowego. Ten proces może potrwać kilka godzin po utracie regionu podstawowego, a nawet dłużej w niektórych scenariuszach. Przejście w tryb failover zasobów usługi IoT Hub może nie nastąpić w tym samym czasie co inne usługi platformy Azure.

  • Aktywne żądania: Wszelkie żądania, które są przetwarzane przez region podstawowy w czasie przejścia w tryb failover, prawdopodobnie zostaną utracone. Klienci powinni ponowić próby wniosków po zakończeniu przełączenia awaryjnego.

  • Oczekiwana utrata danych: W przypadku sparowanych regionów dane są replikowane asynchronicznie do sparowanego regionu. W związku z tym niektóre straty danych są oczekiwane po przejściu w tryb failover. Proces dotyczy zarówno przełączania awaryjnego zarządzanego przez firmę Microsoft, jak i zarządzanego przez klienta. W poniższej tabeli przedstawiono cel punktu odzyskiwania (RPO) lub oczekiwaną utratę danych każdego typu danych przechowywanych przez centra IoT.

    Typ danych Regionalny Program Operacyjny (RPO)
    Rejestr tożsamości 0–5 minut utraty danych
    Dane bliźniaczej reprezentacji urządzenia 0–5 minut utraty danych
    Komunikaty z chmury do urządzenia 1 0–5 minut utraty danych
    Zadania nadrzędne 1 i urządzenia 0–5 minut utraty danych
    Komunikaty z urządzenia do chmury Wszystkie nieprzeczytane wiadomości zostaną utracone
    Komunikaty zwrotne z chmury do urządzenia Wszystkie nieprzeczytane wiadomości zostaną utracone

    1 Komunikaty z chmury do urządzenia i zadania nadrzędne nie są odzyskiwane w ramach przełączenia awaryjnego zainicjowanego przez klienta.

  • Oczekiwany przestój: Oczekiwany przestój podczas pracy w trybie failover w regionie zależy od typu trybu failover.

    • Tryb failover zainicjowany przez klienta: Oczekuj przestoju trwającego od około 10 minut do 2 godzin, od momentu utraty regionu do momentu, gdy zasób będzie działać w sparowanym regionie. Liczba urządzeń zarejestrowanych w wystąpieniu usługi IoT Hub w trybie failover wpływa na czas odzyskiwania. Można oczekiwać, że czas odzyskiwania dla węzła, który hostuje około 100 000 urządzeń, wynosi około 15 minut.

    • Failover zainicjowany przez firmę Microsoft: Spodziewaj się od 2 do 26 godzin przestoju, licząc od momentu utraty regionu do momentu, gdy zasób będzie dostępny w sparowanym regionie.

      Długi czas odzyskiwania jest spowodowany tym, że firma Microsoft musi wykonać procedurę przełączenia awaryjnego w imieniu wszystkich dotkniętych klientów w tym regionie. W przypadku systemów krytycznych należy użyć trybu failover zainicjowanego przez klienta w celu osiągnięcia mniejszego przestoju. Jeśli jednak uruchamiasz mniej krytyczne rozwiązanie IoT, które może wytrzymać przestój około jednego dnia, może być możliwe podjęcie zależności od opcji zainicjowanej przez firmę Microsoft w celu spełnienia ogólnych celów odzyskiwania po awarii dla rozwiązania IoT.

    • W przypadku obu typów trybu failover w pełni kwalifikowana nazwa domeny wystąpienia centrum IoT pozostaje taka sama po przejściu w tryb failover, co oznacza, że parametry połączenia również pozostają takie same. Jednak ze względu na zmianę bazowego adresu IP klienci muszą czekać na aktualizację rekordów systemu nazw domen (DNS) przed uzyskaniem dostępu do centrum IoT po przejściu w tryb failover.

      Ważne

      Zestawy SDK usługi IoT Hub nie buforują adresu IP centrum IoT Hub. Kod użytkownika współpracujący z SDK również nie powinien buforować adresu IP huba IoT.

      Ze względu na te czynniki czas wykonywania operacji na wystąpieniu centrum IoT Hub staje się w pełni operacyjny po zakończeniu procesu failover i można go wyrazić za pomocą następującej funkcji:

      Czas odzyskiwania = Cel Czasu Odzyskiwania (RTO) [10 minut do 2 godzin dla trybu failover zainicjowanego przez klienta lub od 2 do 26 godzin dla trybu failover zainicjowanego przez firmę Microsoft] + opóźnienie propagacji DNS + czas, który aplikacja kliencka potrzebuje na odświeżenie każdego buforowanego adresu IP centrum IoT Hub

  • Przekierowywanie ruchu: Podczas procesu przełączenia awaryjnego usługa IoT Hub aktualizuje rekordy DNS, aby wskazywały sparowany region. Wszystkie kolejne żądania są wysyłane do sparowanego regionu.

    Po zakończeniu operacji przejścia w tryb failover dla centrum IoT wszystkie operacje z urządzenia i aplikacji zaplecza powinny kontynuować pracę bez konieczności ręcznej interwencji. Ta ciągłość gwarantuje, że komunikaty z urządzenia do chmury będą nadal działać, a cały rejestr urządzeń jest nienaruszony. Jeśli emitujesz zdarzenia za pośrednictwem usługi Azure Event Grid, mogą być używane za pośrednictwem tych samych subskrypcji, które zostały skonfigurowane wcześniej, o ile te subskrypcje usługi Event Grid będą nadal dostępne. W przypadku niestandardowych punktów końcowych nie jest wymagana żadna dalsza obsługa.

Wymagana konfiguracja po przejściu w tryb awaryjny

W zależności od tego, gdzie są kierowane komunikaty centrum IoT, może być konieczne wykonanie dodatkowych kroków po zakończeniu pracy w trybie failover.

  • Azure Event Hubs: Nazwa zgodna z usługą Event Hubs i punkt końcowy wbudowanego punktu odbioru zdarzeń centrum IoT zmieni się po awarii głównego serwera. Ta zmiana występuje, ponieważ klient usługi Event Hubs nie ma wglądu w zdarzenia usługi IoT Hub.

    Gdy odbierasz komunikaty telemetryczne z wbudowanego punktu końcowego przy użyciu klienta usługi Event Hubs lub hosta procesora zdarzeń, użyj parametrów połączenia centrum IoT, aby nawiązać połączenie. Takie podejście gwarantuje, że aplikacje zaplecza będą nadal działać bez konieczności ręcznej interwencji po przejściu w tryb failover.

    Jeśli bezpośrednio używasz nazwy i punktu końcowego zgodnego z usługą Event Hubs w aplikacji, musisz pobrać nowy punkt końcowy zgodny z usługą Event Hubs po przejściu w tryb failover, aby kontynuować operacje. Aby pobrać punkt końcowy i nazwę, możesz użyć witryny Azure Portal lub zestawu .NET SDK:

    • Portal Azure Aby uzyskać więcej informacji na temat korzystania z portalu do pobierania punktu końcowego zgodnego z Event Hubs i nazwy zgodnej z Event Hubs, zobacz Łączenie z wbudowanym punktem końcowym.

    • Zestaw .NET SDK: Aby użyć parametrów połączenia centrum IoT w celu odzyskania punktu końcowego zgodnego z usługą Event Hubs, użyj przykładowego kodu. W tym przykładzie kodu użyto parametrów połączenia, aby uzyskać nowy punkt końcowy usługi Event Hubs i ponownie ustanowić połączenie. Musisz mieć zainstalowany program Visual Studio.

  • Usługi Azure Functions i Azure Stream Analytics: Jeśli używasz Azure Functions lub Stream Analytics do nawiązywania połączenia z wbudowanym punktem końcowym Event Hubs, musisz zaktualizować punkt końcowy Event Hubs, z którym łączy się funkcja lub zadanie, zgodnie z procesem opisanym w poprzednim punkcie. Następnie wykonaj akcję Uruchom ponownie , ponieważ wszelkie przesunięcia strumienia zdarzeń stają się nieprawidłowe po przejściu w tryb failover.

  • Azure Storage: Podczas routingu do usługi Azure Storage najpierw wyświetl listę obiektów blob lub plików. Następnie przejdź przez nie, aby upewnić się, że wszystkie obiekty blob lub pliki są odczytywane bez zakładania partycjonowania. Zakres partycji może potencjalnie ulec zmianie podczas trybu failover zainicjowanego przez firmę Microsoft lub trybu failover zainicjowanego przez klienta. Możesz użyć interfejsu List Blobs API do wyliczenia listy obiektów blob lub List Azure Data Lake Storage API, aby uzyskać listę plików. Aby uzyskać więcej informacji, zobacz Azure Storage jako punkt końcowy routingu.

Odzyskiwanie regionów

Aby powrócić do regionu podstawowego, możesz ręcznie wyzwolić akcję przełączania awaryjnego po raz drugi. Ważne jest, aby pamiętać o ograniczeniach dotyczących tego, jak często można przejść w tryb failover.

Jeśli oryginalna operacja failover została wykonana w przypadku długotrwałej awarii w pierwotnym regionie głównym, przeprowadź przełączenie z powrotem do regionu głównego po odzyskaniu przez region główny awarii.

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

Aby zasymulować awarię w przypadku niedostępności regionu, możesz wymusić ręczne przełączenie awaryjne centrum IoT. Jednak ponieważ regionalne przejście w tryb failover powoduje zarówno przestój, jak i utratę danych, należy wykonać testowe przejścia w tryb failover tylko w środowiskach nieprodukcyjnych. Aby uzyskać więcej informacji, zobacz Zachowanie podczas awarii regionu. Rozważ skonfigurowanie testowego wystąpienia usługi IoT Hub do regularnego uruchamiania planowanej opcji przełączenia awaryjnego. Okresowe testowanie może pomóc w budowaniu zaufania do możliwości przywracania i obsługi kompleksowego rozwiązania w przypadku wystąpienia rzeczywistej awarii.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Możliwości trybu failover między regionami usługi IoT Hub nie są odpowiednie w następujących scenariuszach:

  • Twoje centrum IoT znajduje się w niesparowanym regionie.

  • Cele dotyczące dostępności systemu nie są spełnione przez czas odzyskiwania lub utratę danych oferowaną przez wbudowaną opcję przełączania awaryjnego.

  • Musisz przejść w tryb failover do regionu, który nie jest parą regionu podstawowego.

Możesz zaprojektować rozwiązanie awaryjnego przełączania między regionami dostosowane do każdego urządzenia. Pełne traktowanie topologii wdrażania w rozwiązaniach IoT wykracza poza zakres tego artykułu, ale można rozważyć model wdrażania w wielu regionach. W tym modelu podstawowe centrum IoT i zaplecze rozwiązania są uruchamiane głównie w jednym regionie świadczenia usługi Azure. Pomocnicze centrum IoT i zaplecze są wdrażane w innym regionie świadczenia usługi Azure. Jeśli centrum IoT w regionie podstawowym wystąpi awaria lub połączenie sieciowe z urządzenia do regionu podstawowego zostanie przerwane, urządzenia używają pomocniczego punktu końcowego usługi.

  • Oczekiwany przestój: Takie podejście ma mniej niż jedną minutę przestoju, ale może być złożone do zaimplementowania.

  • Oczekiwana utrata danych: Ilość utraty danych zależy od używanych magazynów danych oraz sposobu konfigurowania replikacji geograficznej między nimi.

  • Koszt: Takie podejście wymaga aprowizacji co najmniej jednego dodatkowego centrum IoT, co zwiększa całkowity koszt.

Aby zaimplementować regionalny model awaryjnego przełączania za pomocą usługi IoT Hub, należy podjąć następujące działania:

  • Wtórny IoT Hub i logika trasowania urządzeń: Jeśli wystąpi zakłócenie usługi w regionie podstawowym, urządzenia muszą zacząć łączyć się z regionem pomocniczym. Ze względu na stanowo-zależny charakter większości zaangażowanych usług, administratorzy rozwiązań często ręcznie rozpoczynają proces przełączania awaryjnego między regionami. Najlepszym sposobem komunikowania nowego punktu końcowego urządzeniom przy zachowaniu kontroli nad procesem jest regularne sprawdzanie usługi concierge w celu ustalenia bieżącego aktywnego punktu końcowego. Usługa concierge może być aplikacją internetową, która jest replikowana i osiągalna przy użyciu technik przekierowania DNS, takich jak usługa Azure Traffic Manager.

    Uwaga / Notatka

    Usługa Traffic Manager nie ma wbudowanej obsługi usługi IoT Hub. Można skonfigurować niestandardowe punkty końcowe usługi Traffic Manager dla każdego centrum IoT. Skonfiguruj sondę sprawdzania kondycji punktu końcowego Menadżera Ruchu, aby używać punktu końcowego centrum IoT.

  • Replikacja rejestru tożsamości: Aby można było go używać, pomocnicze centrum IoT musi zawierać wszystkie tożsamości urządzeń, które mogą łączyć się z rozwiązaniem. Rozwiązanie powinno przechowywać geograficznie replikowane kopie zapasowe tożsamości urządzeń i przekazywać je do pomocniczego centrum IoT przed przełączeniem aktywnego punktu końcowego dla urządzeń. Funkcja eksportowania tożsamości urządzenia usługi IoT Hub jest przydatna w tym kontekście. Aby uzyskać więcej informacji, zobacz Omówienie rejestru tożsamości w centrum IoT.

  • Logika scalania: Gdy region podstawowy stanie się ponownie dostępny, wszystkie stany i dane utworzone w regionie pomocniczym muszą zostać zmigrowane z powrotem do regionu podstawowego. Ten stan i dane dotyczą głównie tożsamości urządzeń i metadanych aplikacji, które muszą zostać scalone z podstawowym centrum IoT i innymi magazynami specyficznymi dla aplikacji w regionie podstawowym.

    Aby uprościć ten krok, użyj operacji idempotentnych . Operacje idempotentne minimalizują skutki uboczne wynikające z docelowej spójności dystrybucji zdarzeń oraz z duplikatów lub przesyłania zdarzeń poza kolejnością. Ponadto logika aplikacji powinna być zaprojektowana tak, aby tolerowała potencjalne niespójności lub nieco nieaktualny stan. Ten scenariusz może wystąpić z powodu dodatkowego czasu, który zajmuje systemowi regeneracja w oparciu o cele punktów odzyskiwania (RPO).

Tworzenie kopii zapasowej i przywracanie

Usługa IoT Hub umożliwia operacje eksportu zbiorczego, które umożliwiają eksportowanie całego rejestru tożsamości centrum IoT. Te dane są przesyłane do kontenera obiektów blob usługi Azure Storage przy użyciu sygnatury dostępu współdzielonego. Ta metoda umożliwia tworzenie niezawodnych kopii zapasowych informacji o urządzeniu w kontrolowanym kontenerze blob. Aby uzyskać więcej informacji, zobacz Importowanie i eksportowanie tożsamości urządzeń usługi IoT Hub zbiorczo.

Możesz również wyeksportować szablon usługi Azure Resource Manager (szablon usługi ARM) istniejącego centrum IoT Hub, aby utworzyć kopię zapasową konfiguracji centrum IoT. Aby uzyskać więcej informacji, zobacz Ręczne migrowanie centrum IoT przy użyciu szablonu ARM.

W przypadku większości rozwiązań nie należy polegać wyłącznie na kopiach zapasowych. Zamiast tego skorzystaj z innych możliwości opisanych w tym przewodniku, aby spełnić wymagania dotyczące odporności. Jednak kopie zapasowe chronią przed pewnymi zagrożeniami, których nie zapewniają inne podejścia. Aby uzyskać więcej informacji, zobacz Co to jest nadmiarowość, replikacja i kopia zapasowa?.

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.

Treści powiązane

  • Last updated on