Udostępnij za pośrednictwem

Podejścia architektoniczne dla rozwiązań wielodomenowych opartych na IoT Hub

  • Artykuł

Wielotenanckie rozwiązania oparte na usłudze IoT Hub są dostępne w wielu różnych wersjach i rozmiarach. Może istnieć wiele wymagań i ograniczeń, od własności infrastruktury, po izolację danych klientów po zgodność. Może to być trudne do zdefiniowania wzorca spełniającego wszystkie te ograniczenia projektowe i często wymaga rozważenia wielu wymiarów. W tym artykule opisano kilka często używanych metod rozwiązywania problemów dotyczących wielodostępności dla rozwiązań opartych na usłudze IoT Hub.

Kluczowe zagadnienia i wymagania

Te zagadnienia i wymagania są prezentowane w kolejności, w jakiej są one zwykle priorytetowe dla projektu rozwiązania.

Zarządzanie i zgodność

Zagadnienia dotyczące ładu i zgodności mogą wymagać użycia określonego wzorca lub zestawu zasobów IoT. Nie wszystkie usługi IoT mają te same certyfikaty lub możliwości. Jeśli musisz spełnić określone standardy zgodności, może być konieczne wybranie określonych usług. Aby dowiedzieć się więcej, zobacz Podejścia architektoniczne do zarządzania i zgodności w wielodostępnych rozwiązaniach.

Zarządzanie w usłudze IoT może również mieć inne formy, takie jak własność urządzeń i zarządzanie nimi. Czy klient jest właścicielem urządzenia, czy dostawcą rozwiązań? Kto jest właścicielem zarządzania tymi urządzeniami? Te zagadnienia i implikacje są unikatowe dla każdego dostawcy rozwiązań i mogą prowadzić do różnych wyborów w zakresie technologii, wzorca wdrażania i wzorca wielodostępności, którego używasz.

Skaluj

Ważne jest zaplanowanie skali rozwiązania. Skalowanie jest często brane pod uwagę w tych trzech wymiarach:

  • Ilość urządzeń: wszystkie usługi zarządzania urządzeniami platformy Azure — Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) i Azure IoT Hub — mają ograniczenia dotyczące liczby urządzeń obsługiwanych w jednym wystąpieniu.

    Napiwek

    Jeśli planujesz wdrożyć bardzo dużą liczbę urządzeń, zapoznaj się z dokumentacją o dużej skali.

  • Przepływność urządzenia: różne urządzenia, nawet w tym samym rozwiązaniu, mogą mieć różne wymagania dotyczące przepływności. "Przepływność" w tym kontekście odnosi się zarówno do liczby komunikatów w danym okresie, jak i do rozmiaru komunikatów. Na przykład w:

    • Rozwiązanie dla inteligentnych budynków, termostaty zwykle zgłaszają dane o niższej częstotliwości niż windy.
    • W rozwiązaniu połączonym pojazdem komunikaty dotyczące rejestrowania danych z kamery pojazdów są zwykle większe niż komunikaty telemetryczne nawigacji.

    Jeśli komunikaty są ograniczane pod względem częstotliwości, rozważ zwiększenie liczby instancji usługi. Jeśli komunikaty są ograniczane w odniesieniu do rozmiaru, rozważ skalowanie w górę do większych wystąpień usługi.

  • Najemcy: Skala pojedynczego najemcy może być mała, ale pomnożona przez liczbę najemców, może szybko rosnąć.

Wydajność i niezawodność

Izolacja dzierżawy

W pełni udostępnione rozwiązania mogą mieć hałaśliwych sąsiadów. W przypadku usług IoT Hub i IoT Central sąsiedzi hałaśliwi mogą spowodować kod odpowiedzi HTTP 429 ("Zbyt wiele żądań"), które są twardymi błędami, które mogą powodować efekt kaskadowy. Aby uzyskać więcej informacji, zobacz Limity przydziału i ograniczanie przepustowości.

W w pełni wielodostępnych rozwiązaniach te efekty mogą być kaskadowe. Gdy klienci udostępniają aplikacje usługi IoT Hub lub IoT Central, wszyscy klienci w udostępnionej infrastrukturze otrzymują błędy. Ponieważ usługi IoT Hub i IoT Central są często punktami wejścia dla danych w chmurze, inne systemy podrzędne, które zależą od tych danych, również mogą zakończyć się niepowodzeniem. Często najczęstszą przyczyną tych błędów jest przekroczenie limitu przydziału komunikatów. W takiej sytuacji najszybszą i najprostszą poprawką dla rozwiązań usługi IoT Hub jest uaktualnienie jednostki SKU usługi IoT Hub, zwiększenie liczby jednostek usługi IoT Hub lub obu tych rozwiązań. W przypadku rozwiązań usługi IoT Central rozwiązanie jest automatycznie skalowane w razie potrzeby do udokumentowanej liczby obsługiwanych komunikatów.

Możesz izolować i dystrybuować dzierżawców na płaszczyznach kontroli, zarządzania i komunikacji IoT, korzystając z niestandardowych zasad alokacjiusług DPS . Ponadto, korzystając ze wskazówek dotyczących rozwiązań IoT o dużej skali, można zarządzać innymi dystrybucjami alokacji na poziomie modułu równoważenia obciążenia usługi DPS.

Magazyn danych, zapytania, użycie i przechowywanie danych

Rozwiązania IoT zwykle intensywnie korzystają z danych, zarówno podczas przesyłania strumieniowego, jak i w stanie spoczynku. Aby uzyskać więcej informacji na temat zarządzania danymi w rozwiązaniach wielodostępnych, zobacz Metody architektury magazynowania i danych w rozwiązaniach wielodostępnych.

Zabezpieczenia

Rozwiązania IoT często mają zagadnienia dotyczące zabezpieczeń w wielu warstwach, zwłaszcza w rozwiązaniach wdrożonych w architekturze referencyjnej przedsiębiorstwa purdue zmodyfikowanej w chmurze lub rozwiązaniach branżowych 4.0. Wybrane podejście projektowe ma wpływ na istniejące warstwy i granice sieci; po wybraniu projektu fizycznego możesz wybrać implementację zabezpieczeń. W dowolnej metodzie można użyć następujących narzędzi:

Większość z tych tematów dotyczących zabezpieczeń ma zastosowanie w rozwiązaniu wielodostępnym podobnym do sposobu, w jaki byłyby one w jednym rozwiązaniu dzierżawy, z odmianami powiązanymi z wybranym podejściem. Jednym składnikiem, który prawdopodobnie będzie znacznie inny w ogólnym rozwiązaniu IoT, jest tożsamość użytkownika i aplikacji. Podejścia architektury do obsługi tożsamości w rozwiązaniach wielodostępnych omawia ten aspekt ogólnego rozwiązania wielodostępnego.

Podejścia do rozważenia

Zagadnienia i wybory dotyczące podstawowych składników, takich jak zarządzanie, pozyskiwanie, przetwarzanie, przechowywanie i zabezpieczenia, są takie same w przypadku rozwiązań IoT jednokrotnych i wielonajemnych. Podstawową różnicą jest sposób rozmieszczania i wykorzystywania składników do obsługi wielodostępności. Na przykład typowe punkty decyzyjne dla:

  • Przechowywanie danych może obejmować wybór korzystania z aplikacji SQL Server lub Azure Data Explorer.
  • Warstwa pozyskiwania i zarządzania polega na wybraniu między usługą IoT Hub i usługą IoT Central.

Większość rozwiązań IoT mieści się w głównym wzorcu architektury, który jest kombinacją docelowego wdrożenia, modelu dzierżawy i wzorca wdrażania. Kluczowe wymagania i zagadnienia opisane wcześniej określają te czynniki.

Jednym z największych punktów decyzyjnych, które należy podjąć, w przestrzeni IoT, jest wybranie między podejściami typu "platforma jako usługa" (aPaaS) i "platforma jako usługa" (PaaS). Aby dowiedzieć się więcej, zobacz Porównanie podejść do rozwiązań Internetu Rzeczy (IoT) (PaaS vs aPaaS).

Ten wybór jest typowym dylematem „budować czy kupować”, z którym boryka się wiele organizacji w różnych projektach. Ważne jest, aby ocenić zalety i wady obu opcji.

Pojęcia i zagadnienia dotyczące rozwiązań aPaaS

Typowe rozwiązanie aPaaS korzystające z usługi Azure IoT Central jako podstawowe rozwiązanie może używać następujących usług PaaS i aPaaS:

Architektura T we/wy przedstawiająca dzierżawy udostępniające środowisko centrum operacji we/wy, usługę Azure Data Explorer, usługę Power BI i usługę Azure Logic Apps.

Na poprzednim diagramie dzierżawy współdzielą środowisko usługi IoT Central, usługę Azure Data Explorer, usługę Power BI i usługę Azure Logic Apps.

Takie podejście jest zazwyczaj najszybszym sposobem uzyskania rozwiązania na rynek. Jest to usługa o dużej skali, która obsługuje wielodostępność przy użyciu organizacji.

Ważne jest, aby zrozumieć, że ponieważ usługa IoT Central jest ofertą aPaaS, istnieją pewne decyzje, które są poza kontrolą implementatora. Te decyzje obejmują:

  • Usługa IoT Central używa identyfikatora Entra firmy Microsoft jako dostawcy tożsamości.
  • Wdrożenia usługi IoT Central są realizowane przy użyciu operacji sterowania i płaszczyzny danych, które łączą dokumenty deklaratywne z kodem imperatywnym.
  • Maksymalna liczba węzłów i maksymalna głębokość drzewa w wielodostępnym wzorcu opartym na usłudze IoT Central mogą zmusić dostawcę usług do posiadania wielu wystąpień usługi IoT Central. W takim przypadku należy rozważyć zastosowanie wzorca sygnatury wdrożenia.
  • Usługa IoT Central nakłada limity wywołań interfejsu API , co może mieć wpływ na duże implementacje.

Pojęcia i zagadnienia dotyczące rozwiązań PaaS

Podejście oparte na modelu PaaS może korzystać z następujących usług platformy Azure:

Diagram przedstawiający rozwiązanie I O T. Każda dzierżawa łączy się z udostępnioną aplikacją internetową, która odbiera dane z usługi I O T Hubs i aplikację funkcji. Urządzenia łączą się z usługą Device Provisioning Service i koncentratorami we/wy.

Na poprzednim diagramie każda dzierżawa łączy się z udostępnioną aplikacją internetową, która odbiera dane z usługi IoT Hubs i aplikacji funkcji. Urządzenia łączą się z usługą Device Provisioning Service i z usługą IoT Hubs.

Takie podejście wymaga większego nakładu pracy dewelopera w celu utworzenia, wdrożenia i utrzymania rozwiązania (w porównaniu z podejściem aPaaS). Mniejsza liczba możliwości jest wstępnie skompilowana dla wygody implementatora. W związku z tym takie podejście zapewnia również większą kontrolę, ponieważ mniej założeń jest osadzonych na platformie bazowej.

Wzorce architektury głównej

W poniższej tabeli wymieniono typowe wzorce dla wielodostępnych rozwiązań IoT. Każdy wzorzec zawiera następujące informacje:

  • Nazwa wzorca, który jest oparty na kombinacji typu docelowego, modelu i wdrożenia.
  • Cel wdrożenia reprezentujący subskrypcję platformy Azure w celu wdrożenia zasobów.
  • Model dzierżawy, do których odwołuje się wzorzec, zgodnie z opisem w temacie Modele wielodostępności
  • Wzorzec wdrażania, odwołujący się do prostego wdrożenia z minimalnymi zagadnieniami dotyczącymi wdrażania, wzorcem geode lub wzorcem sygnatury wdrożenia.
Wzorzec Cel wdrożenia Model dzierżawy Wzorzec wdrażania
Proste saas Subskrypcja dostawcy usług W pełni wielodostępny Uproszczony
Poziomy saas Subskrypcja dostawcy usług Partycjonowane w poziomie Sygnatura wdrożenia
Automatyczna obsługa pojedynczej dzierżawy Subskrypcja dostawcy usług lub klienta Pojedyncza dzierżawa na klienta Uproszczony

Proste saas

Diagram przedstawiający architekturę T we/wy. Dzierżawy współużytkuje środowisko usługi I O T Central, Azure Data Explorer, Power BI i Azure Logic Apps.

Cel wdrożenia Model dzierżawy Wzorzec wdrożenia
Subskrypcja dostawcy usług W pełni wielodostępny Uproszczony

Proste podejście SaaS to najprostsza implementacja rozwiązania SaaS IoT. Jak pokazano na poprzednim diagramie, wszystkie infrastruktury są współużytkowane, a infrastruktura nie ma zastosowanych sygnatur geograficznych ani skalowania. Często infrastruktura znajduje się w ramach jednej subskrypcji platformy Azure.

Usługa Azure IoT Central obsługuje koncepcję organizacji. Organizacje umożliwiają dostawcy rozwiązań łatwe segregowanie dzierżaw w bezpieczny, hierarchiczny sposób, a jednocześnie udostępnianie podstawowego projektu aplikacji we wszystkich dzierżawach.

Komunikacja z systemami spoza usługi IoT Central, na przykład na potrzeby długoterminowej analizy danych, wzdłuż zimnej ścieżki lub łączności z operacjami biznesowymi, odbywa się za pośrednictwem innych ofert PaaS i aPaaS firmy Microsoft. Te inne oferty mogą obejmować następujące usługi:

Jeśli porównasz podejście Simple SaaS z automatycznym modelem aPaaS z pojedynczą dzierżawą, wiele cech jest podobnych. Podstawową różnicą między dwoma modelami jest to, że:

  • W zautomatyzowanym modelu pojedynczej dzierżawy wdrażasz odrębne wystąpienie usługi IoT Central dla każdej dzierżawy.
  • W modelu Simple SaaS z usługą aPaaS wdrażasz współdzielone wystąpienie dla wielu klientów i tworzysz organizację w IoT Central dla każdego najemcy.

Ponieważ udostępniasz wielodostępną warstwę danych w tym modelu, musisz zaimplementować zabezpieczenia na poziomie wiersza, aby odizolować dane klientów. Aby dowiedzieć się więcej, zobacz Podejścia architektoniczne dla przechowywania i przetwarzania danych w wielodostępnych rozwiązaniach.

Korzyści:

  • Łatwiejsze zarządzanie i obsługa względem innych przedstawionych tutaj metod.

Czynniki ryzyka:

  • Takie podejście może nie być łatwe skalowanie do dużej liczby urządzeń, komunikatów lub dzierżaw.

  • Usługi i składniki są współużytkowane, dlatego awaria w dowolnym składniku może mieć wpływ na wszystkich użytkowników. To ryzyko wiąże się z niezawodnością i wysoką dostępnością rozwiązania.

  • Ważne jest, aby wziąć pod uwagę sposób zarządzania zgodnością, operacjami, cyklem życia najemców i zabezpieczeniami podzestawów urządzeń. Te zagadnienia stają się ważne ze względu na wspólny charakter tego typu rozwiązania na płaszczyznach kontroli, zarządzania i komunikacji.

Poziomy saas

Cel wdrożenia Model dzierżawy Wzorzec wdrażania
Subskrypcja dostawcy usług Partycjonowane w poziomie Sygnatura wdrożenia

Typowym podejściem do skalowalności jest partycjonowanie rozwiązania w poziomie. Oznacza to, że masz niektóre składniki udostępnione i niektóre składniki dla poszczególnych klientów.

W ramach rozwiązania IoT istnieje wiele składników, które mogą być partycjonowane w poziomie. Podsystemy partycjonowane w poziomie są zwykle rozmieszczone przy użyciu wzorca sygnatury wdrożenia, który integruje się z większym rozwiązaniem.

Przykład poziomy SaaS

Poniższy przykład architektury partycjonuje usługę IoT Central dla każdego klienta końcowego, który służy jako portal zarządzania urządzeniami, komunikacji urządzeń i administracji. Takie partycjonowanie jest często wykonywane w taki sposób, aby klient końcowy korzystający z rozwiązania miał pełną kontrolę nad dodawaniem, usuwaniem i aktualizowaniem swoich urządzeń bez interwencji dostawcy oprogramowania. Reszta rozwiązania jest zgodna ze standardowym wzorcem infrastruktury udostępnionej, który rozwiązuje potrzeby analizy ścieżki gorącej, integracji biznesowych, zarządzania SaaS i analizy urządzeń.

Diagram rozwiązania I O T. Każda dzierżawa ma własną organizację usługi I O T Central, która wysyła dane telemetryczne do udostępnionej aplikacji funkcji i udostępnia ją użytkownikom biznesowym dzierżawy za pośrednictwem aplikacji internetowej.

Każda dzierżawa ma własną organizację usługi IoT Central, która wysyła dane telemetryczne do udostępnionej aplikacji funkcji i udostępnia ją użytkownikom biznesowym dzierżawy za pośrednictwem aplikacji internetowej.

Korzyści:

  • Łatwe zarządzanie i obsługa, chociaż dodatkowe zarządzanie może być wymagane w przypadku składników z jedną dzierżawą.
  • Elastyczne opcje skalowania, ponieważ warstwy są skalowane w razie potrzeby.
  • Efekt awarii składników jest zmniejszony. Podczas gdy awaria wspólnego składnika wpływa na wszystkich klientów, komponenty skalowane horyzontalnie oddziałują tylko na klientów związanych z określonymi instancjami skalowania.
  • Ulepszone szczegółowe informacje o użyciu poszczególnych dzierżaw dla składników partycjonowanych.
  • Składniki partycjonowane zapewniają łatwiejsze dostosowania poszczególnych dzierżaw.

Czynniki ryzyka:

  • Skalowanie rozwiązania, szczególnie w przypadku jakichkolwiek składników udostępnionych.
  • Może to mieć wpływ na niezawodność i wysoką dostępność. Pojedynczy błąd w składnikach udostępnionych może mieć wpływ na wszystkie dzierżawy jednocześnie.
  • Dostosowanie składnika partycjonowanego dla dzierżawy wymaga długoterminowych zagadnień dotyczących metodyki DevOps i zarządzania.

Poniżej przedstawiono najbardziej typowe składniki, które są zazwyczaj odpowiednie do partycjonowania poziomego.

Bazy danych

Możesz wybrać partycjonowanie baz danych. Często są to dane telemetryczne i magazyny danych urządzeń, które są partycjonowane. Często wiele magazynów danych jest używanych do różnych celów, takich jak ciepły i archiwalny magazyn lub informacje o stanie subskrypcji dzierżawy.

Rozdziel bazy danych dla każdej dzierżawy, aby uzyskać następujące korzyści:

  • Obsługa standardów zgodności. Dane każdej dzierżawy są izolowane między wystąpieniami magazynu danych.
  • Korygowanie hałaśliwych problemów z sąsiadem.

Zarządzanie urządzeniami, komunikacja i administracja

Aplikacje usługi Azure IoT Hub Device Provisioning Service, IoT Hub i IoT Central mogą być często wdrażane jako składniki partycjonowane w poziomie. W tym rozwiązaniu potrzebna jest inna usługa do przekierowywania urządzeń do odpowiedniego wystąpienia usługi DPS dla płaszczyzny zarządzania, kontroli i telemetrii tego konkretnego dzierżawcy. Aby dowiedzieć się więcej, zobacz dokumentację Skalowanie rozwiązania Azure IoT w celu obsługi milionów urządzeń.

Takie podejście jest często podejmowane w celu umożliwienia klientom końcowym zarządzania własnymi flotami urządzeń, które są bardziej bezpośrednio i w pełni odizolowane.

Jeśli płaszczyzna komunikacji urządzeń jest partycjonowana horyzontalnie, dane telemetryczne muszą zostać wzbogacone o dane identyfikujące najemcę źródłowego. Funkcja ta pozwala procesorowi strumienia zidentyfikować reguły dzierżawy, które należy zastosować do strumienia danych. Na przykład, jeśli komunikat telemetrii generuje powiadomienie w procesorze strumienia, procesor strumienia musi ustalić właściwą ścieżkę powiadomienia dla powiązanego najemcy.

Przetwarzanie strumieniowe

Partycjonując przetwarzanie strumienia, można włączyć dostosowania analizy dla poszczególnych dzierżaw w procesorach strumienia.

Automatyczna obsługa pojedynczej dzierżawy

Zautomatyzowane podejście z jedną dzierżawą opiera się na podobnym procesie podejmowania decyzji i projektowaniu rozwiązania dla przedsiębiorstw.

Diagram przedstawiający architekturę T we/wy dla trzech dzierżaw. Każda dzierżawa ma własne identyczne, izolowane środowisko z organizacją centralną operacji we/wy i innymi składnikami przeznaczonymi dla nich.

Każda dzierżawa ma własne, izolowane środowisko z organizacją usługi IoT Central i innymi składnikami przeznaczonymi dla nich.

Cel wdrożenia Model dzierżawy Wzorzec wdrożenia
Subskrypcja dostawcy usług lub klienta Pojedyncza dzierżawa na klienta Uproszczony

Krytycznym punktem decyzyjnym w tym podejściu jest wybór subskrypcji platformy Azure, do której mają być wdrażane składniki. Jeśli składniki są wdrażane w ramach subskrypcji, masz większą kontrolę i lepszy wgląd w koszt rozwiązania, ale wymaga posiadania większej liczby kwestii związanych z zabezpieczeniami i ładem rozwiązania. Z drugiej strony, jeśli rozwiązanie jest wdrażane w ramach subskrypcji klienta, klient jest ostatecznie odpowiedzialny za bezpieczeństwo i nadzór nad wdrożeniem.

Ten wzorzec wspiera wysoki stopień skalowalności, ponieważ wymagania dotyczące dzierżawy i subskrypcji są zwykle czynnikami ograniczającymi w większości rozwiązań. W związku z tym izoluj każdą dzierżawę, aby zapewnić duży zakres skalowania obciążenia każdej dzierżawy, bez znacznego nakładu pracy ze strony dewelopera rozwiązań.

Ten wzorzec ma również małe opóźnienie w porównaniu z innymi wzorcami, ponieważ można wdrożyć składniki rozwiązania na podstawie lokalizacji geograficznej klientów. Koligacja geograficzna umożliwia krótsze ścieżki sieciowe między urządzeniem IoT a wdrożeniem platformy Azure.

W razie potrzeby można rozszerzyć wdrożenie automatyczne, aby obsługiwać lepsze opóźnienia lub skalę, włączając szybkie wdrażanie dodatkowych wystąpień rozwiązania w istniejących lub nowych lokalizacjach geograficznych.

Zautomatyzowane podejście z jedną dzierżawą jest podobne do prostego modelu SaaS aPaaS. Podstawową różnicą między dwoma modelami jest to, że w ramach zautomatyzowanego podejścia z jedną dzierżawą wdrażasz odrębne wystąpienie usługi IoT Central dla każdej dzierżawy, natomiast w prostym modelu SaaS z modelem aPaaS wdrażasz współużytkowane wystąpienie usługi IoT Central z wieloma organizacjami usługi IoT Central.

Korzyści:

  • Łatwe zarządzanie i obsługa.
  • Izolacja najemcy jest gwarantowana.

Czynniki ryzyka:

  • Początkowa automatyzacja może być skomplikowana dla nowych pracowników programistycznych.
  • Należy wymusić zabezpieczenia poświadczeń między klientami na potrzeby zarządzania wdrożeniami wyższego poziomu lub zabezpieczenia mogą być rozszerzane między klientami.
  • Oczekuje się, że koszty będą wyższe, ponieważ korzyści ze skalowania udostępnionej infrastruktury między klientami nie są dostępne.
  • Wiele wystąpień do utrzymania, jeśli dostawca rozwiązania jest odpowiedzialny za konserwację każdego wystąpienia.

Zwiększanie skali modelu SaaS

W przypadku rozszerzania skali rozwiązania do dużych wdrożeń istnieją konkretne wyzwania, które pojawiają się w oparciu o limity usług, problemy geograficzne i inne czynniki. Aby uzyskać więcej informacji na temat architektur wdrażania IoT na dużą skalę, zobacz Scaling out an Azure IoT solution to support milionów urządzeń.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Następne kroki