Udostępnij przez

Rozszerz rozwiązanie Azure IoT Hub, aby obsłużyć miliony urządzeń

W tym artykule opisano sposób skalowania rozwiązania Internetu rzeczy (IoT) przy użyciu wzorca skalowania w poziomie na platformie Azure IoT Hub. Wzorzec skalowania poziomego rozwiązuje wyzwania związane z skalowaniem przez dodanie wystąpień do wdrożenia zamiast zwiększania rozmiaru wystąpienia. Te wskazówki dotyczące implementacji pokazują, jak skalować rozwiązanie IoT obsługujące miliony urządzeń i uwzględniać limity usług i subskrypcji platformy Azure. W artykule opisano modele wdrażania niskiego zaangażowania i bezobsługowe, dotyczące wzorca skalowania poziomego, które można wdrożyć w zależności od potrzeb.

Diagram, który przedstawia główne kroki skalowania w poziomie rozwiązania Azure IoT.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

Uwaga

Ten dokument nie obejmuje platformy Azure IoT Operations, która jest skalowana zgodnie z konfiguracją platformy Kubernetes używanej do hostingu.

Zbieranie wymagań

Zbierz wymagania przed wdrożeniem nowego rozwiązania IoT. Ten krok pomaga zapewnić, że implementacja spełnia Cele biznesowe. Twoje wymagania powinny być określane przez cele biznesowe i środowisko operacyjne. "Należy zebrać co najmniej następujące wymagania:"

Zidentyfikuj typy urządzeń, które chcesz wdrożyć. IoT obejmuje szeroką gamę rozwiązań— od prostych mikrokontrolerów (MCU) po średniej klasy system-on-chip (SoC) i mikroprocesora (MPU) po pełne projekty na poziomie komputera. Możliwości oprogramowania po stronie urządzenia mają bezpośredni wpływ na projekt rozwiązania.

Określ liczbę urządzeń, które należy wdrożyć. Niektóre podstawowe zasady implementowania rozwiązań IoT mają zastosowanie we wszystkich skalach. Zrozumienie skali w celu uniknięcia przeinżynierowania rozwiązania. Rozwiązanie dla 1000 urządzeń ma podstawowe różnice w porównaniu z rozwiązaniem dla 1 miliona urządzeń. Rozwiązanie weryfikacji koncepcji (PoC) dla 10 000 urządzeń może nie być odpowiednio skalowane do 10 milionów urządzeń, jeśli nie rozważysz skali docelowej na początku projektu rozwiązania.

Zidentyfikuj liczbę urządzeń, które należy wdrożyć, aby wybrać odpowiednią usługę Azure IoT. Skalowanie usług IoT Hub i IoT Hub DPS jest różne. Zgodnie z projektem pojedyncze wystąpienie usługi DPS może kierować do wielu wystąpień usługi IoT Hub. Dlatego należy wziąć pod uwagę skalę każdej usługi indywidualnie w odniesieniu do liczby urządzeń. Ale limity nie istnieją w izolacji. Jeśli jedna usługa przedstawi problem z limitem, inne usługi prawdopodobnie również. Traktuj limity usług jako odrębne, ale powiązane przydziały.

Udokumentowanie przewidywanych lokalizacji urządzeń. Uwzględnij lokalizację fizyczną, dostępność zasilania i łączność z Internetem. Rozwiązanie wdrażane w jednej lokalizacji geograficznej, takie jak tylko w Ameryce Północnej, jest zaprojektowane inaczej w porównaniu z rozwiązaniem globalnym. Podobnie przemysłowe rozwiązanie IoT wdrożone w fabrykach o pełnej mocy różni się od rozwiązania do zarządzania flotą wdrożonego w pojazdach samochodowych o zmiennej mocy i lokalizacji. Protokół komunikacyjny i dostępna przepustowość, niezależnie od tego, czy do bramy, czy bezpośrednio do usługi w chmurze, mają wpływ na skalowalność projektu w każdej warstwie. Należy również rozważyć dostępność łączności. Ustal, czy urządzenia pozostają połączone z platformą Azure, czy działają w trybie rozłączenia przez dłuższy czas.

Zbadaj wymagania dotyczące lokalizacji danych. Wymagania prawne, zgodności lub klienta mogą ograniczać miejsce przechowywania danych (takich jak dane telemetryczne) lub metadanych (takich jak informacje o urządzeniu) dla rozwiązania. Te ograniczenia znacząco wpływają na projekt geograficzny rozwiązania.

Określanie wymagań dotyczących wymiany danych. Rozwiązanie, które wysyła podstawowe dane telemetryczne, takie jak bieżąca temperatura raz na godzinę, różni się od rozwiązania, które przekazuje 1 MB przykładowych plików raz na 10 minut. Jednokierunkowe rozwiązanie typu urządzenie-chmura (D2C) różni się od dwukierunkowego rozwiązania D2C i chmury do urządzenia (C2D). Ponadto ograniczenia skalowalności produktu traktują rozmiar komunikatów i ilość komunikatów jako różne wymiary.

Udokumentowanie oczekiwanych wymagań dotyczących wysokiej dostępności i odzyskiwania po awarii. Podobnie jak w przypadku każdego rozwiązania produkcyjnego, pełne projekty rozwiązań IoT obejmują wymagania dotyczące dostępności, czyli czasu działania. Projekt musi obejmować zarówno scenariusze planowanej konserwacji, jak i nieplanowane przestoje, w tym błędy użytkownika, czynniki środowiskowe i błędy rozwiązań. Projekt musi również mieć udokumentowany docelowy punkt odzyskiwania (RPO) i docelowy czas odzyskiwania (RTO), jeśli dojdzie do awarii, na przykład wskutek trwałej utraty regionu lub działań złośliwych podmiotów. Ten artykuł koncentruje się na skali urządzeń, dlatego zawiera tylko ograniczone informacje o wysokiej dostępności i problemach związanych z odzyskiwaniem po awarii.

W razie potrzeby zdecyduj się na model najmu klienta. W rozwiązaniu wielodostępnym firmy zajmującej się tworzeniem oprogramowania, w którym twórca rozwiązań tworzy rozwiązanie dla zewnętrznych klientów, projekt musi określić, jak segregować i zarządzać danymi klientów. Aby uzyskać więcej informacji, zobacz Modele dzierżawy i powiązane wskazówki dotyczące IoT.

Omówienie pojęć związanych z usługą Azure IoT

Podczas tworzenia rozwiązania wybierz odpowiednie składniki usługi Azure IoT i inne pomocnicze usługi platformy Azure. Architektura rozwiązania wymaga znacznego nakładu pracy. Prawidłowe korzystanie z usług IoT Hub i IoT Hub DPS może pomóc w skalowaniu rozwiązań do milionów urządzeń.

Centrum IoT

Usługa IoT Hub to zarządzana usługa hostowana w chmurze, która działa jako centralne centrum komunikatów na potrzeby komunikacji między aplikacją IoT a dołączonymi urządzeniami. Usługę IoT Hub można używać samodzielnie lub z usługą IoT Hub DPS.

Usługa IoT Hub skaluje się na podstawie żądanej funkcjonalności oraz liczby komunikatów lub ilości danych dziennie. Użyj następujących trzech danych wejściowych, aby określić sposób skalowania wystąpienia:

  • Warstwy Bezpłatna, Podstawowa i Standardowa określają dostępne możliwości. Instancja produkcyjna nie korzysta z darmowego poziomu, ponieważ jest ograniczona skalą i przeznaczona tylko do wprowadzających scenariuszy deweloperskich. Większość rozwiązań korzysta z warstwy standard, aby uzyskać pełne możliwości usługi IoT Hub.

  • Rozmiar określa jednostkę bazową komunikatu i przepływności danych dla komunikatów D2C dla usługi IoT Hub. Maksymalny rozmiar wystąpienia usługi IoT Hub to 3, który obsługuje 300 milionów komunikatów dziennie i 114,4 GB danych dziennie, na jednostkę.

  • Liczba jednostek określa mnożnik skali rozmiaru. Na przykład trzy jednostki obsługują trzy razy skalę jednej jednostki. Limit rozmiaru 1 lub 2 wystąpień centrum wynosi 200 jednostek, a limit rozmiaru 3 wystąpień centrum to 10 jednostek.

Oprócz dziennych limitów zależnych od rozmiaru i liczby jednostek oraz ogólnych limitów funkcjonalności zależnych od warstwy, usługa IoT Hub wymusza limity przepływności na sekundę. Każde wystąpienie usługi IoT Hub obsługuje również maksymalnie 1 milion urządzeń jako sztywny limit. Wymagania dotyczące wymiany danych pomagają zdefiniować odpowiednią konfigurację. Aby uzyskać więcej informacji, zobacz Inne limity.

Wymagania dotyczące rozwiązania determinują niezbędny rozmiar i liczbę wystąpień usługi IoT Hub jako punkt wyjścia. Jeśli używasz usługi IoT Hub DPS, platforma Azure ułatwia dystrybucję obciążeń między wiele wystąpień usługi IoT Hub.

IoT Hub DPS

IoT Hub DPS to pomocnicza usługa dla IoT Hub, która umożliwia bezobsługową aprowizację just-in-time do odpowiedniego centrum IoT, bez konieczności interwencji człowieka. Każda subskrypcja platformy Azure obsługuje maksymalnie 10 wystąpień usługi DPS. Każde wystąpienie usługi obsługuje maksymalnie 1 milion rejestracji. Uwzględnij limity usług w projektowaniu swojego obciążenia, aby uniknąć problemów w przyszłości.

Wystąpienia usługi DPS znajdują się w określonych regionach geograficznych, ale domyślnie mają globalny publiczny punkt końcowy . Dostęp do określonych wystąpień uzyskuje się przez zakres ID. Ponieważ wystąpienia znajdują się w określonych regionach, a każde wystąpienie ma własny zakres identyfikatorów, powinno być możliwe skonfigurowanie zakresu identyfikatorów dla urządzeń.

Zrozumienie pojęć odporności wspólnej

Należy wziąć pod uwagę wspólne koncepcje odporności, takie jak obsługa błędów przejściowych, wpływ na lokalizację urządzeń oraz, w przypadku firm oprogramowania, odporności danych oprogramowania jako usługi (SaaS).

Omówienie obsługi błędów przejściowych. Każde rozwiązanie rozproszone w środowisku produkcyjnym, zarówno lokalnie, jak i w chmurze, musi być w stanie odzyskać dane po przejściowych lub tymczasowych błędach. Błędy przejściowe mogą występować częściej w rozwiązaniu w chmurze z powodu następujących czynników:

  • Poleganie na dostawcy zewnętrznym
  • Poleganie na łączności sieciowej między urządzeniem a usługami w chmurze
  • Limity implementacji usług w chmurze

Obsługa błędów przejściowych wymaga wbudowanej możliwości ponawiania prób w kodzie urządzenia. Istnieje kilka strategii ponawiania prób, w tym wykładnicze wycofywanie z randomizacją, znane również jako wykładnicze wycofywanie z drżeniem. Aby uzyskać więcej informacji, zobacz Obsługa błędów przejściowych.

Różne czynniki mogą mieć wpływ na łączność sieciową urządzenia:

  • Źródło zasilania urządzenia: Urządzenia zasilane z baterii lub urządzenia zasilane przez źródła przejściowe, takie jak energia słoneczna lub wiatr, mogą mieć mniej łączności sieciowej niż urządzenia zasilane w pełnym wymiarze czasu.

  • Lokalizacja wdrożenia urządzenia: Urządzenia w miejskich zakładach produkcyjnych prawdopodobnie mają lepszą łączność sieciową niż urządzenia w izolowanych lokalizacjach terenowych.

  • Stabilność lokalizacji urządzenia: Urządzenia przenośne prawdopodobnie mają mniej łączności sieciowej niż urządzenia o stałej lokalizacji.

Te obawy mają również wpływ na czas dostępności i łączności urządzeń. Na przykład urządzenia oparte na liniach w gęstych środowiskach miejskich, takich jak inteligentne głośniki, mogą rozłączać się i ponownie łączyć w dużych grupach. Rozważ następujące scenariusze:

  • Zaciemnienie może spowodować, że 1 milion urządzeń przestanie działać w tym samym czasie i jednocześnie ponownie się uruchomi ze względu na brak zasilania i ponowne podłączenie do sieci. Ten scenariusz ma zastosowanie zarówno w sytuacjach konsumenckich, takich jak inteligentne głośniki, jak i w scenariuszach biznesowych oraz przemysłowych IoT, takich jak połączone, zasilane z sieci termostaty raportujące do firmy zajmującej się zarządzaniem nieruchomościami.

  • Podczas krótko trwającego wydarzenia na dużą skalę, takiego jak Black Friday lub Boże Narodzenie, wielu konsumentów włącza urządzenia po raz pierwszy w stosunkowo krótkim czasie.

  • Wiele urządzeń otrzymuje zaplanowane aktualizacje w krótkim czasie, a wszystkie z nich są ponownie uruchamiane przy użyciu nowej aktualizacji w przybliżeniu w tym samym czasie.

Te scenariusze, gdy wiele urządzeń uruchamia się jednocześnie, mogą wyzwalać ograniczanie przepustowości usług w chmurze, nawet przy niemal stałej dostępności sieci.

Poza problemami z siecią i limitami przydziału należy również rozważyć awarie usług platformy Azure. Te awarie mogą mieć wpływ na poszczególne usługi lub całe regiony. Niektóre usługi, takie jak IoT Hub, obsługują nadmiarowość geograficzną. Inne usługi, takie jak IoT Hub DPS, przechowują swoje dane w jednym regionie. Można powiązać jedno centrum IoT z wieloma instancjami usługi DPS, co pomaga ograniczyć ryzyko regionalne.

Jeśli dotyczy to nadmiarowości regionalnej, użyj wzorca Geode. Ten wzorzec hostuje niezależne, pogrupowane zasoby w różnych lokalizacjach geograficznych. Podobnie sygnatura wdrożenia, znana również jako sygnatura skalowania, stosuje ten wzorzec do obsługi wielu obciążeń lub klientów. Aby uzyskać więcej informacji, zobacz Wzorzec sygnatur wdrożenia.

Zrozumienie wpływu lokalizacji urządzenia. Większość usług Azure to regionalne, nawet DPS z globalnymi punktami końcowymi. Wyjątki obejmują Azure Traffic Manager i Microsoft Entra ID. Decyzje dotyczące lokalizacji urządzenia, lokalizacji danych i lokalizacji metadanych (takich jak grupy zasobów platformy Azure) odgrywają kluczową rolę w projekcie.

  • Lokalizacja urządzenia: Wymagania dotyczące lokalizacji urządzenia mają wpływ na wybór regionalny, ponieważ wpływają one na opóźnienie transakcyjne.

  • Lokalizacja danych: Lokalizacja danych jest powiązana z lokalizacją urządzenia, która podlega problemom ze zgodnością. Na przykład rozwiązanie, które przechowuje dane dla stanu w Stanach Zjednoczonych, może wymagać przechowywania danych w lokalizacji geograficznej USA. Wymagania dotyczące lokalizacji danych mogą również wymuszać tę potrzebę.

  • Lokalizacja metadanych: Chociaż lokalizacja urządzenia zwykle nie wpływa na lokalizację metadanych, ponieważ urządzenia wchodzą w interakcje z danymi rozwiązania, a nie z metadanymi rozwiązania, kwestie zgodności i koszty mają wpływ na lokalizację metadanych. W wielu przypadkach wygoda określa, że lokalizacja metadanych jest taka sama jak lokalizacja danych dla usług regionalnych.

Przewodnik Azure Cloud Adoption Framework zawiera wskazówki dotyczące wyboru regionalnego.

Zrozumienie problemów związanych z SaaS w programowej firmie. Firmy programowe, które oferują rozwiązania SaaS, powinny spełniać oczekiwania klientów dotyczące dostępności i odporności. Firmy tworzące oprogramowanie muszą zaprojektować usługi platformy Azure jako wysoce dostępne i uwzględnić koszty związane z zapewnieniem odporności i nadmiarowości przy rozliczaniu z klientem.

Segreguj koszt sprzedanych towarów na podstawie segregacji danych klientów dla każdego klienta oprogramowania. To rozróżnienie jest ważne, gdy użytkownik nie jest taki sam jak klient. Na przykład w przypadku platformy smart TV klient dostawcy platformy może być dostawcą telewizji, ale użytkownik jest nabywcą telewizora. Ta segregacja, wynikająca z modelu dzierżawy klienta wynikającego z wymagań, wymaga oddzielnych wystąpień usług DPS i IoT Hub. Usługa aprowizacji musi również mieć unikatową tożsamość klienta, którą można zdefiniować za pomocą unikatowego punktu końcowego lub procesu uwierzytelniania urządzenia. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące wielodostępności IoT (IoT multitenant guidance).

Poziome skalowanie komponentów i ich usług pomocniczych

Podczas skalowania rozwiązań IoT oceń każdą usługę i sposób ich wzajemnego powiązania. Rozwiązanie IoT można skalować w wielu wystąpieniach usługi DPS lub przy użyciu usługi IoT Hub.

Rozszerzyć na wiele instancji DPS

Ze względu na limity usługi DPS często trzeba rozszerzyć się na wiele wystąpień usługi DPS. Aprowizowanie urządzeń w wielu wystąpieniach usługi DPS może być realizowane za pomocą aprowizacji bezobsługowej lub aprowizacji z minimalną interakcją.

Poniższe podejścia stosują wcześniej opisaną koncepcję znacznika w kontekście odporności i skalowania poziomego. Ta koncepcja obejmuje wdrażanie usługi Azure App Service w wielu regionach oraz korzystanie z narzędzi, takich jak Traffic Manager lub globalny moduł równoważenia obciążenia. Dla uproszczenia poniższe diagramy nie pokazują tych składników.

Podejście 1. Bezobsługowa aprowizacja z wieloma wystąpieniami usługi DPS

W przypadku bezobsługowej lub automatycznej aprowizacji sprawdzona strategia obejmuje wysyłanie przez urządzenie żądania o zakres identyfikatora DPS z internetowego interfejsu API. Interfejs API zarządza i równoważy urządzenia w instancjach DPS skalowanych poziomo. Ta akcja sprawia, że aplikacja internetowa jest krytyczną częścią procesu aprowizacji, dlatego musi być skalowalna i wysoce dostępna. Ten projekt ma trzy podstawowe odmiany.

Na poniższym diagramie przedstawiono pierwszą opcję, która używa niestandardowego interfejsu API aprowizacji i zarządza sposobem mapowania urządzenia do odpowiedniej puli DPS. Każde wystąpienie usługi DPS następnie mapuje urządzenie na odpowiedni IoT Hub przy użyciu standardowych mechanizmów równoważenia obciążenia.

Diagram przedstawiający przykład automatycznej aprowizacji bezdotykowej z bezpośrednim dostępem do usługi Devices Provisioning Service.

  1. Urządzenie wysyła żądanie do interfejsu API aprowizacji hostowanego w usłudze App Service w celu uzyskania zakresu identyfikatora DPS. Interfejs API do aprowizacji konsultuje się z trwałą bazą danych, aby określić najlepszą instancję dla urządzenia na podstawie istniejącego inwentarza urządzeń i zwraca zakres identyfikatora DPS.

    W tym przykładzie baza danych jest wystąpieniem usługi Azure Cosmos DB z włączoną obsługą zapisu wielo podstawowego w celu zapewnienia wysokiej dostępności między regionami. Ta baza danych przechowuje przypisane do każdego urządzenia wartości DPS. Obsługuje śledzenie użycia wystąpienia usługi DPS dla wszystkich odpowiednich metryk, takich jak żądania aprowizacji na minutę i łączna liczba zaaproizowanych urządzeń. Ta baza danych umożliwia również ponowne aprowizowanie przy użyciu tego samego zakresu identyfikatora usługi DPS w razie potrzeby. Uwierzytelnij interfejs API aprowizacji, aby zapobiegać nieodpowiednim żądaniom aprowizacji.

  2. Urządzenie wysyła żądanie do usługi DPS przy użyciu przypisanego zakresu identyfikatorów. Usługa DPS odpowiada za pomocą szczegółów przypisania centrum IoT.

  3. Urządzenie przechowuje zakres ID i informacje o połączeniu z IoT Hub w trwałym magazynie, najlepiej w zabezpieczonej lokalizacji, ponieważ zakres ID stanowi część uwierzytelniania względem wystąpienia usługi DPS. Następnie urządzenie używa tych informacji o połączeniu z centrum IoT w celu uzyskania dalszych żądań do systemu.

Ten projekt wymaga, aby oprogramowanie urządzenia uwzględniało pakiet DPS SDK i zarządzało procesem rejestracji DPS, co jest typowym projektem urządzenia Azure IoT. Jednak w środowisku mikrokontrolera, w którym rozmiar oprogramowania urządzenia jest krytycznym składnikiem projektu, może nie być akceptowalny i może wymagać alternatywnego projektu.

Podejście 2. Bezobsługowa aprowizacja za pomocą interfejsu API aprowizacji

Drugi projekt przenosi wywołanie usługi DPS do interfejsu API aprowizacji. W tym modelu uwierzytelnianie urządzenia względem usługi DPS jest zawarte w interfejsie API aprowizacji, podobnie jak większość logiki ponawiania prób. Ten proces umożliwia bardziej zaawansowane scenariusze kolejkowania i potencjalnie prostszy kod aprowizacji w samym urządzeniu. Umożliwia również buforowanie przypisanego centrum IoT w celu ułatwienia szybszego obsługi komunikatów C2D. Komunikaty są wysyłane bez konieczności odpytywania usługi DPS dla przypisanych informacji o centrum głównym.

pl-PL: Diagram przedstawiający przykład bezdotykowego, automatycznego prowizjonowania z izolowanym dostępem do usługi DPS.

  1. Urządzenie wysyła żądanie do interfejsu API aprowizacji hostowanego w wystąpieniu usługi App Service. Interfejs API prowizjonowania sprawdza swoją trwałą bazę danych, aby określić najlepsze wystąpienie dla urządzenia na podstawie istniejącego spisu urządzeń, a następnie określa zakres identyfikatorów DPS.

    W tym przykładzie baza danych jest wystąpieniem usługi Azure Cosmos DB z włączoną obsługą zapisu wielo podstawowego w celu zapewnienia wysokiej dostępności między regionami. Ta baza danych przechowuje przypisane do każdego urządzenia wartości DPS. Obsługuje śledzenie użycia instancji usługi DPS dla wszystkich odpowiednich metryk. Baza danych umożliwia również ponowne aprowizowanie, gdy jest to potrzebne, korzystając z tego samego zakresu identyfikatora usługi DPS.

    Uwierzytelnij interfejs API aprowizacji, aby zapobiegać nieodpowiednim żądaniom aprowizacji. Prawdopodobnie można użyć tego samego uwierzytelniania, którego usługa aprowizacji używa względem usługi DPS, na przykład klucza prywatnego dla wystawionego certyfikatu. Istnieją jednak inne opcje. Na przykład rozwiązanie FastTrack dla platformy Azure może współpracować z klientem, który używa unikatowych identyfikatorów sprzętu w ramach procesu uwierzytelniania usługi. Partner produkujący urządzenia regularnie dostarcza dostawcy urządzeń listę unikatowych identyfikatorów w celu wprowadzenia do bazy danych, która odnosi się do usługi związanej z niestandardowym interfejsem API aprowizacji.

  2. Interfejs API ds. aprowizacji wykonuje proces aprowizacji usługi DPS przy użyciu przypisanego zakresu identyfikatora, skutecznie pełniąc rolę serwera proxy dla usługi DPS.

  3. Interfejs API przekazuje wyniki DPS do urządzenia.

  4. Urządzenie przechowuje informacje o połączeniu z centrum IoT w pamięci trwałej, najlepiej w zabezpieczonym miejscu, ponieważ zakres identyfikatora jest częścią procesu uwierzytelniania w systemie DPS. Urządzenie używa tych informacji o połączeniu centrum IoT dla późniejszych żądań do systemu.

Ten projekt pozwala uniknąć konieczności odwołowania się do zestawu DPS SDK lub usługi DPS. Pozwala również uniknąć konieczności przechowywania lub utrzymywania zakresu usługi DPS na urządzeniu. pl-PL: Ten model obsługuje scenariusze przenoszenia własności, ponieważ usługa aprowizacji może przekierowywać do odpowiedniego wystąpienia usługi DPS dla klienta końcowego. Jednak takie podejście powoduje, że interfejs API aprowizacji duplikuje niektóre funkcje usługi DPS, co może nie odpowiadać wszystkim scenariuszom.

Podejście 3: Bezobsługowa konfiguracja z przeniesieniem własności

Trzeci bezobsługowy projekt aprowizacji używa wystąpienia usługi DPS skonfigurowanego w fabryce jako punktu początkowego i przekierowuje urządzenia do innych wystąpień usługi DPS w razie potrzeby. Ten projekt umożliwia aprowizowanie bez niestandardowego interfejsu API aprowizacji, ale wymaga aplikacji zarządzania do śledzenia wystąpień usługi DPS i dostarczania przekierowania w razie potrzeby.

Wymagania aplikacji zarządzania obejmują śledzenie, który DPS powinien być aktywnym DPS dla każdego konkretnego urządzenia. Tego podejścia można użyć w scenariuszach przenoszenia własności, w których dostawca urządzeń przenosi własność urządzenia od dostawcy do klienta urządzenia końcowego.

Diagram przedstawiający przykład bezobsługowej aprowizacji z przeniesieniem własności.

  1. Urządzenie łączy się z wystąpieniem usługi DPS skonfigurowanym w fabryce i żąda początkowego procesu aprowizacji.

  2. Urządzenie otrzymuje początkową konfigurację, która obejmuje żądaną docelową instancję DPS.

  3. Urządzenie łączy się z żądanym docelowym wystąpieniem usługi DPS i żąda konfiguracji.

  4. Urządzenie przechowuje informacje o połączeniu z centrum IoT w pamięci trwałej, najlepiej w zabezpieczonym miejscu, ponieważ zakres identyfikatora jest częścią procesu uwierzytelniania w systemie DPS. Urządzenie używa tych informacji o połączeniu z centrum IoT w celu uzyskania dalszych żądań do systemu.

Podejście 4. Aprowizowanie przy niskim dotknięciu z wieloma wystąpieniami usługi DPS

W niektórych przypadkach, takich jak w sytuacjach skierowanych do konsumentów lub przy urządzeniach zespołów wdrożeniowych w terenie, często wybiera się konfigurację o minimalnej interakcji użytkownika lub z pomocą użytkownika. Przykłady aprowizacji o niskim dotknięciu obejmują aplikację mobilną na telefonie instalatora lub aplikację internetową na bramie urządzenia. Takie podejście wykonuje te same operacje co proces aprowizacji bezobsługowej, ale aplikacja aprowizacji przesyła szczegóły do urządzenia.

Diagram przedstawiający przykład aprowizacji z niską interakcją (wspomaganej przez użytkownika) z bezpośrednim dostępem do systemu DPS.

  1. Administrator uruchamia aplikację konfiguracji urządzenia, która łączy się z urządzeniem.

  2. Aplikacja konfiguracji łączy się z interfejsem API aprowizacji hostowanym w wystąpieniu usługi App Service, aby zażądać zakresu identyfikatora usługi DPS. API aprowizacji sprawdza swoją trwałą bazę danych, aby określić najlepszą instancję dla urządzenia na podstawie istniejącego spisu urządzeń i zwraca zakres identyfikatora DPS.

    W tym przykładzie baza danych jest wystąpieniem usługi Azure Cosmos DB z włączoną obsługą zapisu wielo podstawowego w celu zapewnienia wysokiej dostępności między regionami. Ta baza danych przechowuje przypisane do każdego urządzenia wartości DPS. Obsługuje śledzenie użycia instancji systemu DPS dla wszystkich odpowiednich metryk. Ta baza danych umożliwia również ponowne aprowizowanie przy użyciu tego samego zakresu identyfikatora ID DPS w razie potrzeby. Aby zapobiec obsłudze niestosownych żądań aprowizacji, uwierzytelnij interfejs API do aprowizacji.

  3. Aplikacja zwraca zakres identyfikatora aprowizacji do urządzenia.

  4. Urządzenie wysyła żądanie do usługi DPS z przypisanym zakresem identyfikacyjnym. Usługa DPS zwraca szczegóły przypisania centrum IoT do urządzenia.

  5. Urządzenie utrwala zakres identyfikatorów i informacje o połączeniu centrum IoT z magazynem trwałym, najlepiej w zabezpieczonej lokalizacji magazynu, ponieważ zakres identyfikatora jest częścią uwierzytelniania względem wystąpienia usługi DPS. Urządzenie używa tych informacji o połączeniu z centrum IoT w celu uzyskania dalszych żądań do systemu.

Ten artykuł nie obejmuje innych odmian. Można na przykład skonfigurować to podejście, przenosząc wywołanie usługi DPS do interfejsu API aprowizacji, jak pokazano wcześniej w aprowizowaniu bezobsługowym przy użyciu interfejsu API aprowizacji. Celem jest upewnienie się, że każda warstwa jest skalowalna, konfigurowalna i łatwo wdrażalna.

Ogólne wskazówki dotyczące aprowizacji usługi DPS

Zastosuj następujące zalecenia do wdrożenia usługi DPS:

Nie konfiguruj systemu przy każdym rozruchu. Dokumentacja usługi DPS zaleca, aby nie konfigurować przy każdym rozruchu. W przypadku małych przypadków użycia konfiguracja przy każdym uruchomieniu może być uznane za rozsądne, ponieważ jest to najkrótsza ścieżka do wdrożenia. Jednak przy skalowaniu do milionów urządzeń usługa DPS może stać się wąskim gardłem ze względu na stały limit 1000 rejestracji na minutę, na wystąpienie usługi. Nawet wyszukiwania stanu rejestracji urządzeń mogą stać się wąskim gardłem, ponieważ mają limit od 5 do 10 operacji sondowania na sekundę. Wyniki aprowizacji zwykle są mapowane statycznie na hub IoT. Dlatego należy inicjować aprowizację tylko w razie potrzeby, chyba że wymagania obejmują automatyczne żądania ponownego aprowizowania. Jeśli przewidujesz większy ruch, przeprowadź skalowanie horyzontalne do wielu wystąpień usługi DPS w celu obsługi scenariusza.

Użyj rozłożonego w czasie harmonogramu provisioningu. Aby skrócić ograniczenia oparte na czasie, użyj rozłożonego harmonogramu aprowizacji. W przypadku początkowej aprowizacji można zastosować losowe opóźnienie w ciągu kilku sekund lub przedłużyć opóźnienie do minut w zależności od wymagań dotyczących wdrożenia.

Zawsze zapytaj o status przed zażądaniem udostępnienia zasobów. Najlepszym rozwiązaniem jest, aby urządzenia zawsze wysyłały zapytania dotyczące stanu przed zażądaniem aprowizacji przy użyciu interfejsu API wyszukiwania stanu rejestracji urządzeń. To wywołanie nie jest liczone jako rozliczany element, a limit jest niezależny od limitu rejestracji. Operacja zapytania jest stosunkowo szybka w porównaniu z żądaniem aprowizacji, więc urządzenie może zweryfikować jego stan i szybciej rozpocząć normalne obciążenie. Aby uzyskać odpowiednią logikę rejestracji urządzeń, zobacz Wdrażanie na dużą skalę.

Postępuj zgodnie z uwagami dotyczącymi interfejsu API aprowizacji. Kilka projektów w tym artykule zawiera interfejs API aprowizacji. Interfejs API aprowizacji wymaga wspierającego magazynu metadanych, takiego jak Azure Cosmos DB. Na tych poziomach skalowania należy zaimplementować globalnie dostępny i odporny wzorzec projektowy. Wbudowane funkcje wieloprimaryjnych, geograficznie redundantnych możliwości oraz gwarancją niskiego opóźnienia w usłudze Azure Cosmos DB sprawiają, że jest to idealny wybór dla tego scenariusza. Ten interfejs API ma następujące kluczowe obowiązki:

  • Serwować zakres identyfikatorów DPS. Ten interfejs może używać żądania GET. Urządzenia fizyczne lub aplikacje do zarządzania łączą się z tym interfejsem.

  • Obsługa cyklu życia urządzenia. Urządzenie może wymagać ponownej aprowizacji lub mogą wystąpić nieoczekiwane zdarzenia. Przynajmniej zachowaj identyfikator urządzenia i przypisany DPS dla urządzenia. Te informacje umożliwiają anulowanie aprowizacji z przypisanej usługi DPS i ponowne aprowizowanie na innym. Lub jeśli cykl życia urządzenia się skończył, możesz całkowicie usunąć go z systemu.

  • Systemy równoważenia obciążenia. System wykorzystuje identyczne metadane dotyczące identyfikatora urządzenia oraz usługi DPS, co pozwala mu zrozumieć aktualne obciążenie poszczególnych podsystemów i użyć tych danych do lepszego równoważenia urządzeń w ramach komponentów skalowanych poziomo.

  • Podtrzymuje bezpieczeństwo systemu. Interfejs API aprowizacji powinien uwierzytelniać każde żądanie. Zalecanym najlepszym rozwiązaniem jest użycie unikatowego certyfikatu X.509 dla każdego urządzenia. Ten certyfikat może uwierzytelniać urządzenie zarówno względem interfejsu API aprowizacji, jak i instancji DPS, jeśli architektura na to pozwala. Dostępne są inne metody, takie jak certyfikaty floty i tokeny, ale zapewniają mniejsze bezpieczeństwo. Konkretna implementacja i jej wpływ na zabezpieczenia zależą od tego, czy wybierasz opcję bezobsługową, czy niskodotykową.

Skalowanie w poziomie usługi IoT Hub

W porównaniu ze skalowaniem w górę usługi DPS skalowanie w górę usługi IoT Hub jest stosunkowo proste. Zaletą usługi DPS jest możliwość łączenia się z wieloma instancjami IoT Hub. W przypadku stosowania zalecanej praktyki używania usługi DPS w rozwiązaniach Azure IoT skalowanie IoT Hub na większą skalę obejmuje następujące kroki:

  1. Utwórz nowe wystąpienie usługi IoT Hub.

  2. Skonfiguruj nowe wystąpienie przy użyciu odpowiednich reguł routingu i innych szczegółów.

  3. Połącz nowe wystąpienie z odpowiednimi wystąpieniami usługi DPS.

  4. W razie potrzeby przekonfiguruj politykę alokacji DPS lub politykę niestandardowej alokacji.

Projektowanie oprogramowania urządzenia

Skalowalny projekt urządzenia wymaga stosowania najlepszych praktyk i uwzględnienia kwestii po stronie urządzenia. Niektóre z tych praktyk pochodzą z antywzorców napotkanych w tej dziedzinie. W tej sekcji opisano kluczowe pojęcia dotyczące pomyślnego wdrożenia skalowanego.

Szacowanie obciążeń w różnych częściach cyklu życia urządzenia i scenariuszy w ramach cyklu życia. Obciążenia rejestracji urządzeń mogą się znacznie różnić między fazami programowania, takimi jak etapy pilotażowe, programistyczne, produkcyjne, likwidacyjne i końcowe. W niektórych przypadkach mogą również różnić się w zależności od czynników zewnętrznych, takich jak wcześniej wymieniony scenariusz zaciemnienia. Projektowanie pod kątem najgorszego obciążenia w celu zapewnienia sukcesu na dużą skalę.

Obsługa ponownej aprowizacji na żądanie. Tę funkcję można udostępnić za pomocą polecenia urządzenia i żądania użytkownika administracyjnego. Aby uzyskać więcej informacji, zobacz Ponowne aprowizowanie urządzeń. Ta opcja ułatwia scenariusze przenoszenia własności i scenariusze przywracania do ustawień fabrycznych.

Unikaj niepotrzebnego ponownego aprowizowania. Aktywne urządzenia robocze rzadko wymagają ponownej aprowizacji, ponieważ informacje o aprowizacji pozostają stosunkowo statyczne. Nie aprowizuj ponownie bez dobrego powodu.

Sprawdź stan aprowizacji, jeśli często musisz ponownie aprowizować, na przykład podczas każdego rozruchu urządzenia. Jeśli nie masz pewności co do stanu aprowizacji urządzenia, najpierw wykonaj zapytanie dotyczące stanu aprowizacji . Operacja zapytania jest obsługiwana względem innego limitu przydziału niż operacja aprowizacji i jest szybsza. To zapytanie umożliwia urządzeniu zweryfikowanie stanu aprowizacji przed kontynuowaniem. Takie podejście jest szczególnie przydatne, gdy urządzenie nie ma dostępnego magazynu trwałego do przechowywania wyników aprowizacji.

Upewnij się, że masz dobrą strategię ponawiania prób. Urządzenie musi mieć odpowiednie algorytmy ponawiania prób wbudowane w kod urządzenia na potrzeby początkowej aprowizacji i późniejszego ponownego aprowizowania. Użyj technik, takich jak wycofywanie wykładnicze z randomizacją. Początkowe wdrażanie, z definicji, może wymagać bardziej intensywnego procesu ponawiania prób niż ponowne wdrażanie, w zależności od kontekstu użycia. W przypadku ograniczeń przepustowości, usługa DPS zwraca kod błędu HTTP 429 Zbyt wiele żądań, podobnie jak większość usług platformy Azure. Aby uzyskać więcej informacji, zobacz Ponawianie prób i Antywzorce, których należy unikać. W dokumentacji usługi DPS wyjaśniono również, jak interpretować zalecenia dotyczące ponawiania prób usługi i obliczać zakłócenia. Stabilność lokalizacji urządzenia i dostęp do łączności mają również wpływ na odpowiednią strategię ponawiania prób. Jeśli na przykład urządzenie wykryje, że jest w trybie offline przez pewien czas, należy unikać ponawiania prób operacji online.

Obsługa aktualizacji over-the-air (OTA). Dwa proste modele aktualizacji obejmują używanie właściwości bliźniaczej reprezentacji urządzenia przy użyciu automatycznego zarządzania urządzeniami oraz używanie prostych poleceń urządzenia. Aby uzyskać bardziej zaawansowane scenariusze aktualizacji i raportowanie, zobacz Azure Device Update. Aktualizacje OTA umożliwiają naprawienie wad w kodzie urządzenia i przekonfigurowanie usług, np. zakresu identyfikatorów DPS, w razie potrzeby.

Architekt zmian certyfikatów we wszystkich warstwach i używanych certyfikatach. To zalecenie jest zgodne z najlepszymi rozwiązaniami dotyczącymi aktualizacji usługi OTA. Należy wziąć pod uwagę rotację certyfikatów. Dokumentacja usługi IoT Hub DPS dotyczy tego scenariusza z punktu widzenia certyfikatu tożsamości urządzenia . W rozwiązaniach dla urządzeń inne certyfikaty są używane do dostępu do usług, takich jak IoT Hub, App Service i Azure Storage. Platforma Azure czasami zmienia konfiguracje urzędu certyfikacji, więc należy przewidzieć zmiany we wszystkich warstwach. Ponadto należy używać przypinania certyfikatu z ostrożnością, zwłaszcza gdy certyfikaty znajdują się poza kontrolą producenta urządzenia.

Rozważ rozsądny stan domyślny. Aby rozwiązać początkowe błędy aprowizacji, w zależności od okoliczności należy zastosować rozsądną konfigurację rozłączoną lub nieaprowizowaną. Jeśli urządzenie ma ciężki składnik interakcji w ramach początkowej aprowizacji, proces aprowizacji może wystąpić w tle, podczas gdy użytkownik wykonuje inne zadania aprowizacji. Zawsze należy powiązać to podejście z odpowiednim wzorcem ponawiania prób i wzorcem przerywacza obwodu.

Uwzględnij możliwości konfiguracji punktu końcowego, jeśli jest to konieczne. Zezwalaj na konfigurację zakresu identyfikatorów usługi DPS, punktu końcowego usługi DPS lub niestandardowego punktu końcowego usługi aprowizacji. Mimo że punkt końcowy usługi DPS rzadko zmienia się, włączenie tej elastyczności obsługuje scenariusze, takie jak automatyczna walidacja procesu aprowizacji urządzeń przez testowanie integracji bez bezpośredniego dostępu do platformy Azure lub przyszłych modeli aprowizacji korzystających z usługi proxy.

Użyj zestawów SDK usługi Azure IoT do aprowizacji. Niezależnie od tego, czy wywołania usługi DPS znajdują się na samym urządzeniu, czy w niestandardowym interfejsie API aprowizacji, skorzystaj z zestawów SDK usługi Azure IoT, aby wykorzystać wbudowane najlepsze rozwiązania i uprościć wsparcie. Zestawy SDK są publikowane jako open source, dzięki czemu możesz przejrzeć, jak działają i sugerują zmiany. Wybór zestawu SDK zależy od sprzętu urządzenia i dostępnych na nim środowisk uruchomieniowych.

Wdrażanie urządzeń

Wdrażanie urządzenia jest kluczową częścią cyklu życia urządzenia, ale wykracza poza zakres tego artykułu, ponieważ jest on zależny od przypadku użycia. Wcześniej przywołane kwestie dyskusyjne dotyczące przenoszenia własności mogą mieć zastosowanie do wdrożenia i wzorców obejmujących aplikację aprowizacji, taką jak aplikacja mobilna. Należy jednak wybrać podejście wdrażania oparte na używanym typie urządzenia IoT.

Monitorowanie urządzeń

Ważną częścią ogólnego wdrożenia jest monitorowanie rozwiązania od początku do końca, aby upewnić się, że system działa odpowiednio. Ten artykuł jawnie koncentruje się na architekturze i projektowaniu, a nie na aspektach operacyjnych rozwiązania, więc monitorowanie nie jest uwzględniane. Jednak na wysokim poziomie narzędzia do monitorowania są wbudowane na platformie Azure za pośrednictwem usługi Azure Monitor , aby zapewnić, że rozwiązanie nie osiągnie limitów. Aby uzyskać więcej informacji, zobacz następujące artykuły:

Tych narzędzi można używać indywidualnie lub w ramach bardziej zaawansowanego rozwiązania do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), takiego jak Microsoft Sentinel.

Użyj następujących wzorców monitorowania , aby monitorować użycie usługi DPS w czasie:

  • Utwórz aplikację, która wysyła zapytania do każdej grupy rejestracji w wystąpieniu usługi DPS, pobiera łączną liczbę urządzeń zarejestrowanych w tej grupie, a następnie agreguje liczby z różnych grup rejestracji. Ta metoda zapewnia dokładną liczbę urządzeń aktualnie zarejestrowanych za pośrednictwem usługi DPS i pomaga monitorować stan usługi.

  • Monitorowanie rejestracji urządzeń w określonym okresie. Można na przykład monitorować wskaźniki rejestracji dla instancji DPS w ciągu ostatnich pięciu dni. Takie podejście zapewnia tylko przybliżoną liczbę i jest ograniczone do określonego okresu czasu.

Podsumowanie

Skalowanie w górę rozwiązania IoT w celu obsługi milionów, a nawet setek milionów urządzeń, wymaga starannego planowania. Należy wziąć pod uwagę wiele czynników i różne sposoby rozwiązywania problemów występujących na tych skalach. W tym artykule podsumowano kluczowe zagadnienia i przedstawiono metody rozwiązywania tych problemów w pomyślnym wdrożeniu.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

Inni współautorzy:

  • David Crook | Główny menedżer inżynierii klienta, Microsoft Azure CXP
  • Alberto Gorni | Były starszy inżynier klienta, Microsoft Azure CXP

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

  • Last updated on