Architekturansätze für IoT Hub-basierte Multitenant-Lösungen

Multitenant IoT Hub-basierte Lösungen kommen in vielen verschiedenen Varianten und Größen. Möglicherweise haben Sie viele Anforderungen und Einschränkungen, die vom Infrastrukturbesitz über die Isolierung von Kundendaten bis hin zur Compliance reichen. Es kann eine Herausforderung darstellen, ein Muster zu definieren, das all diese Entwurfseinschränkungen erfüllt, und oft müssen dafür mehrere Dimensionen berücksichtigt werden. In diesem Artikel werden mehrere Ansätze beschrieben, die häufig zur Bewältigung von Multitenancy-Aspekten bei IoT-Hub-basierten Lösungen eingesetzt werden.

Wesentliche Aspekte und Anforderungen

Diese Überlegungen und Anforderungen sind in der Reihenfolge aufgeführt, in der sie normalerweise für den Entwurf einer Lösung priorisiert werden.

Governance und Einhaltung

Überlegungen zu Governance und Einhaltung erfordern möglicherweise, dass Sie ein bestimmtes Muster oder eine Reihe von IoT-Ressourcen verwenden. Nicht alle IoT-Dienste verfügen über die gleichen Zertifizierungen oder Funktionen. Wenn Sie bestimmte Konformitätsstandards erfüllen müssen, müssen Sie möglicherweise bestimmte Dienste auswählen. Weitere Informationen finden Sie unter Architekturansätze für Governance und Compliance in mehrinstanzenfähigen Lösungen

Governance in IoT kann auch andere Formen annehmen, z. B. Gerätebesitz und -verwaltung. Ist der Kunde oder der Anbieter der Lösung der Besitzer des Geräts? Wer ist zur Verwaltung dieser Geräte berechtigt? Diese Überlegungen und Auswirkungen sind für jeden Anbieter einzigartig und können zu unterschiedlichen Entscheidungen hinsichtlich der von Ihnen verwendeten Technologie, des Bereitstellungsmusters und des Musters für die Mehrinstanzenfähigkeit führen.

Skalieren

Es ist wichtig, die Skalierung Ihrer Lösung zu planen. Die Skalierung wird oft über diese drei Dimensionen hinweg betrachtet:

• Anzahl der Geräte: Alle Dienste zur Geräteverwaltung in Azure – Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) und Azure IoT Hub – haben Einschränkungen hinsichtlich der Anzahl der in einer einzelnen Instanz unterstützten Geräte.

  Tipp

  Wenn Sie planen, eine sehr große Anzahl von Geräten bereitzustellen, lesen Sie die Dokumentation für die umfassende Skalierung.

• Gerätedurchsatz: Für verschiedene Geräte, auch in derselben Lösung, können unterschiedliche Durchsatzanforderungen bestehen. „Durchsatz“ bezieht sich in diesem Zusammenhang sowohl auf die Anzahl der Nachrichten in einem bestimmten Zeitraum als auch auf die Größe der Nachrichten. Beispielsweise:

  • Intelligente Gebäudelösung, Thermometer melden in der Regel Daten mit geringerer Frequenz als Aufzüge.
  • In einer Lösung für vernetzte Fahrzeuge sind die von der Fahrzeugkamera aufgezeichneten Daten wahrscheinlich umfangreicher als Telemetrienachrichten für die Navigation.

  Wenn Ihre Nachrichten in Bezug auf die Häufigkeit gedrosselt werden, erwägen Sie, auf mehr Instanzen eines Diensts zu skalieren. Wenn Ihre Nachrichten in Bezug auf die Größe gedrosselt werden, sollten Sie gegebenenfalls auf größere Instanzen eines Dienstes hochskalieren.

• Mandanten: Die Skalierung eines einzelnen Mandanten kann gering sein, aber wenn sie mit der Anzahl der Mandanten multipliziert wird, kann sie schnell zunehmen.

Leistung und Zuverlässigkeit

Mandantenisolation

Vollständig freigegebene Lösungen können einen Noisy Neighbors-Effekt (Beeinträchtigung durch andere Mandanten) aufweisen. In den Fällen von IoT Hub und IoT Central können Noisy Neighbors zu HTTP 429-Antwortcodes („Zu viele Anforderungen“) führen, also zu schwerwiegenden Fehlern, die einen kaskadierenden Effekt verursachen können. Weitere Informationen finden Sie unter Kontingente und Drosselung.

In vollständig mehrinstanzenfähigen Lösungen können diese Effekte kaskadieren. Wenn Kunden IoT Hubs oder IoT Central-Anwendungen freigeben, erhalten alle Kunden in der freigegebenen Infrastruktur Fehlermeldungen. Da IoT Hub und IoT Central in der Regel die Einstiegspunkte für Daten in die Cloud sind, ist es wahrscheinlich, dass auch andere Downstreamsysteme, die auf diese Daten angewiesen sind, Fehler aufweisen. Häufig liegt der häufigste Grund für diese Fehler darin, dass ein Nachrichtenkontingentlimit überschritten wird. In dieser Situation besteht die schnellste und einfachste Lösung für IoT Hub-Lösungen darin, ein Upgrade für die IoT Hub-SKU durchzuführen, die Anzahl der IoT Hub-Einheiten zu erhöhen oder beides. Bei IoT Central-Lösungen wird die Lösung automatisch bedarfsgesteuert bis zur dokumentierten Anzahl der unterstützten Nachrichten skaliert.

Sie können Mandanten über die IoT-Steuerungs-, Verwaltungs- und Kommunikationsebenen isolieren und verteilen, indem Sie die benutzerdefinierten Zuordnungsrichtlinien von DPS verwenden. Wenn Sie die Anleitung für IoT-Lösungen im großen Stil befolgen, können Sie außerdem weitere Zuordnungsverteilungen auf der Ebene des DPS-Lastenausgleichs verwalten.

Datenspeicherung, Abfrage, Nutzung und Datenaufbewahrung

IoT-Lösungen sind in der Regel datenintensiv, sowohl beim Streaming als auch beim Ruhezustand. Weitere Informationen zur Verwaltung von Daten in mehrinstanzenfähigen Lösungen finden Sie unter Architekturansätze für Speicherung und Daten in mehrinstanzenfähigen Lösungen.

Sicherheit

Im Zusammenhang mit IoT-Lösungen und insbesondere mit solchen, die in einer in der Cloud modifizierten Purdue-Referenzarchitektur für Unternehmen bereitgestellt werden, oder mit Industry 4.0-Lösungen, müssen häufig sicherheitsbezogene Überlegungen auf mehreren Ebenen angestellt werden. Der von Ihnen ausgewählte Designansatz wirkt sich darauf aus, welche Netzwerkebenen und Grenzen vorhanden sind; Nachdem Sie den physischen Entwurf ausgewählt haben, können Sie die Sicherheitsimplementierung auswählen. Sie können die folgenden Tools in jedem Ansatz verwenden:

• Microsoft Defender for IoT, eine umfassende IoT-Überwachungslösung, die Sie in Erwägung ziehen sollten und die eine EIoT-Lizenz pro Gerät und OT-Website-Lizenzen für jedes Kundengerät und/oder jede Website bietet. Je nachdem, welcher der unten aufgeführten Ansätze ausgewählt wird, ist das Benutzer-Lizenzierungsszenario – Microsoft 365 genannt – gegebenenfalls nicht möglich. In diesem Fall können pro Gerät und je nach Standort Optionen ausgewählt werden. Diese sind von Microsoft 365-Mandantenlizenzen unabhängig.

• Azure Firewall oder eine nicht von Microsoft stammende Firewall-Appliance, die Sie in Betracht ziehen sollten, um die Netzwerkebenen zu isolieren und den Netzwerkdatenverkehr zu überwachen. Die genaue Wahl des Ansatzes legt fest, wo die Workloads eine Netzwerkisolation statt eines freigegebenen Netzwerks aufweisen, wie später in diesem Artikel beschrieben.

• Azure IoT Edge.

Die Mehrheit dieser Sicherheitsüberlegungen betreffen mehrinstanzenfähige Lösungen, ähnlich wie bei den Einzelmandantenlösungen, wobei die Variationen vom ausgewählten Ansatz abhängen. Die Benutzeridentität und die Anwendungsidentität sind Komponenten, die sich bei einer umfassenden IoT-Lösung wahrscheinlich erheblich unterscheiden werden. Unter Architekturansätze für Identität in mehrinstanzenfähigen Lösungen wird dieser Aspekt im Zusammenhang mit einer mehrinstanzenfähigen Gesamtlösung erörtert.

Zu berücksichtigende Ansätze

Die Überlegungen und Auswahlmöglichkeiten für primäre Komponenten, wie Verwaltung, Eingabe, Verarbeitung, Speicherung und Sicherheit, sind für Einzelinstanz- und Mehrinstanzen-IoT-Lösungen die gleichen. Der Hauptunterschied besteht darin, wie Sie die Komponenten zur Unterstützung der Mehrinstanzenfähigkeit anordnen und nutzen. Allgemeine Entscheidungspunkte können beispielsweise sein:

• Bei Speicheroptionen muss vielleicht zwischen SQL Server und Azure Data Explorer gewählt werden.
• Bei der Erfassungs- und Verwaltungsebene muss gegebenenfalls zwischen IoT Hub und IoT Central gewählt werden.

Die meisten IoT-Lösungen lassen sich in ein Stammarchitekturmuster einordnen, das eine Kombination aus Bereitstellungsziel, Mandantenmodell und Bereitstellungsmuster ist. Die wichtigsten Anforderungen und Überlegungen, die zuvor beschrieben wurden, bestimmen diese Faktoren.

Einer der wichtigsten Entscheidungspunkte im IoT-Bereich ist die Wahl zwischen einem aPaaS- (application Platform as a Service) und PaaS-Ansatz (Platform as a Service). Weitere Informationen finden Sie unter Vergleich von IoT-Lösungsansätzen (PaaS gegenüber aPaaS).

Diese Wahl ist das weit verbreitete Dilemma "Eigenentwicklung versus Kauf", dem viele Organisationen in vielen Projekten gegenüberstehen. Es ist wichtig, die Vor- und Nachteile der beiden Optionen abzuwägen.

Konzepte und Überlegungen zu aPaaS-Lösungen

Eine typische aPaaS-Lösung, die Azure IoT Central als Kern der Lösung verwendet, könnte die folgenden Azure PaaS- und aPaaS-Dienste verwenden:

• Azure Event Hubs als plattformübergreifende Messaging- und Datenfluss-Engine auf Unternehmensniveau.
• Azure Logic Apps als iPaaS-Angebot (integration Platform as a Service).
• Azure Data Explorer als Plattform für die Datenanalyse.
• Power BI als Visualisierungs- und Berichterstellungsplattform.

In der vorherigen Abbildung teilen sich die Mandanten eine IoT Central-Umgebung, Azure Data Explorer, Power BI und Azure Logic Apps.

Dieser Ansatz ist im Allgemeinen der schnellste Weg, um eine Lösung auf den Markt zu bringen. Es handelt sich um einen hochgradig skalierbaren Dienst, der mehrinstanzenfähig ist, indem er Organisationen verwendet.

Es ist wichtig zu verstehen, dass es sich bei IoT Central um ein aPaaS-Angebot handelt und es bestimmte Entscheidungen gibt, die außerhalb der Kontrolle des Implementierers liegen. Zu diesen Entscheidungen gehören:

• IoT Central verwendet Microsoft Entra ID als Identitätsanbieter.
• IoT Central-Bereitstellungen erfolgen mithilfe von Vorgängen auf der Steuerungs- und Datenebene, die deklarative Dokumente mit imperativem Code kombinieren.
• Die maximale Anzahl von Knoten und die maximale Strukturtiefe in einem IoT Central-basierten Mehrmandantenmuster können dazu führen, dass ein Dienstanbieter mehrere IoT Central-Instanzen verwenden muss. In diesem Fall sollten Sie das Muster mit Bereitstellungsstempeln in Betracht ziehen.
• IoT Central setzt API-Aufrufgrenzwertefest, die sich auf große Implementierungen auswirken können.

Konzepte und Überlegungen zu PaaS-Lösungen

Bei einem PaaS-basierten Ansatz können die folgenden Azure-Dienste verwendet werden:

• Azure IoT Hub als zentrale Plattform für Gerätekonfiguration und Kommunikation.
• Azure IoT Device Provisioning Service als Plattform für Gerätebereitstellung und Erstkonfiguration.
• Azure Data Explorer zum Speichern und Analysieren von Zeitreihendaten mit warmem und kaltem Pfad von IoT-Geräten.
• Azure Stream Analytics zum Analysieren von Daten mit langsamstem Pfad von IoT-Geräten.
• Azure IoT Edge für die Ausführung von künstlichen Intelligenzen (AI), Nicht-Microsoft-Diensten oder Ihrer eigenen Geschäftslogik auf IoT Edge-Geräten.

Im vorherigen Diagramm stellt jeder Mandant eine Verbindung mit einer freigegebenen Web-App her, die Daten von IoT Hubs und einer Funktions-App empfängt. Geräte stellen eine Verbindung mit dem Device Provisioning Service und mit IoT Hubs her.

Dieser Ansatz erfordert mehr Aufwand für die Entwickler, um die Lösung zu erstellen, bereitzustellen und zu pflegen (im Gegensatz zu einem aPaaS-Ansatz). Es sind weniger Funktionen für den Komfort des Ausführenden vordefiniert. Daher bietet dieser Ansatz auch mehr Kontrolle, da weniger Annahmen in die zugrunde liegende Plattform eingebettet sind.

Stammarchitekturmuster

In der folgenden Tabelle sind gängige Muster für mehrinstanzenfähige IoT-Lösungen aufgeführt. Jedes Muster enthält die folgenden Informationen:

• Der Name des Musters, der sich aus der Kombination von Ziel, Modell und Bereitstellungstyp ergibt.
• Das Bereitstellungsziel, das das Azure-Abonnement darstellt, in dem Ressourcen bereitgestellt werden sollen.
• Das Mandantenmodell, auf das vom Muster verwiesen wird, wie unter Modelle mit Mehrinstanzenfähigkeit beschrieben.
• Das Bereitstellungsmuster, das auf eine einfache Bereitstellung mit minimalen Überlegungen zur Bereitstellung, ein Muster mit geografischen Knoten oder ein Muster mit Bereitstellungsstempeln verweist.

Muster	Bereitstellungsziel	Mandantenmodell	Bereitstellungsmuster
Einfache SaaS-Lösung	Abonnement des Dienstanbieters	Vollständig mehrinstanzenfähig	Einfach
Horizontale SaaS-Lösung	Abonnement des Dienstanbieters	Horizontal partitioniert	Bereitstellungsstempel
Automatisierte Einzelmandanten	Abonnement des Dienstanbieters oder Kunden	Einzelner Mandant pro Kunde	Einfach

Einfache SaaS-Lösung

Bereitstellungsziel	Mandantenmodell	Bereitstellungsmuster
Abonnement des Dienstanbieters	Vollständig mehrinstanzenfähig	Einfach

Der einfache SaaS-Ansatz ist die einfachste Implementierung für eine SaaS-IoT-Lösung. Wie das vorherige Diagramm zeigt, ist die gesamte Infrastruktur freigegeben, und auf die Infrastruktur ist weder ein geografischer noch ein Skalierungsstempel angewendet. Häufig befindet sich die Infrastruktur in einem einzelnen Azure-Abonnement.

Azure IoT Central unterstützt das Konzept von Organisationen. Organisationen ermöglichen es dem Anbieter einer Lösung, die Mandanten auf sichere, hierarchische Weise zu trennen und gleichzeitig den grundlegenden Entwurf der Anwendung für alle Mandanten freizugeben.

Die Kommunikation mit Systemen außerhalb von IoT Central, z. B. zur längerfristigen Datenanalyse entlang eines kalten Pfads oder für die Konnektivität mit Geschäftsvorgängen, erfolgt über andere Microsoft PaaS- und aPaaS-Angebote. Diese anderen Angebote können die folgenden Dienste umfassen:

• Azure Event Hubs als plattformübergreifende Messaging- und Datenfluss-Engine auf Unternehmensniveau.
• Azure Logic Apps als iPaaS-Angebot (integration Platform as a Service).
• Azure Data Explorer als Plattform für die Datenanalyse.
• Power BI als Visualisierungs- und Berichterstellungsplattform.

Wenn Sie den einfachen SaaS-Ansatz mit dem aPaaS-Modell für automatisierte Einzelmandanten vergleichen, sind viele Merkmale ähnlich. Der Hauptunterschied zwischen den beiden Modellen besteht darin, dass:

• Im Modell für automatisierte Einzelmandanten stellen Sie eine eigene IoT Central-Instanz für jeden Mandanten bereit.
• Im Modell für eine einfache SaaS-Lösung mit aPaaS stellen Sie eine freigegebene Instanz für mehrere Kunden bereit und erstellen Sie eine IoT Central-Organisation für jeden Mandanten.

Da Sie eine mehrinstanzenfähige Datenebene in diesem Modell freigeben, müssen Sie die Sicherheit auf Zeilenebene implementieren, um die Kundendaten zu isolieren. Weitere Informationen finden Sie unter Architekturansätze für Speicherung und Daten in mehrinstanzenfähigen Lösungen.

Vorteile:

• Einfachere Verwaltung und Betrieb im Vergleich zu den anderen hier vorgestellten Ansätzen.

Risiken:

• Dieser Ansatz lässt sich möglicherweise nicht ohne Weiteres auf eine hohe Anzahl von Geräten, Nachrichten oder Mandanten skalieren.

• Dienste und Komponenten werden gemeinsam genutzt, daher kann ein Fehler in einer beliebigen Komponente alle Ihre Mandanten betreffen. Dieses Risiko ist ein Risiko für die Zuverlässigkeit und hohe Verfügbarkeit Ihrer Lösung.

• Überlegen Sie unbedingt, wie Sie die Konformität, den Betrieb, den Lebenszyklus von Mandanten und die Sicherheit von Teilbeständen von Geräten verwalten. Diese Überlegungen sind wichtig, da dieser Lösungstyp auf der Steuerungs-, Verwaltungs- und Kommunikationsebene freigegeben ist.

Horizontale SaaS-Lösung

Bereitstellungsziel	Mandantenmodell	Bereitstellungsmuster
Abonnement des Dienstanbieters	Horizontal partitioniert	Bereitstellungsstempel

Ein gängiger Ansatz für die Skalierbarkeit ist die horizontale Partitionierung der Lösung. Das bedeutet, dass Sie über einige freigegebene Komponenten und einige Komponenten pro Kunde verfügen.

Innerhalb einer IoT-Lösung gibt es viele Komponenten, die horizontal partitioniert werden können. Die horizontal partitionierten Subsysteme werden in der Regel mithilfe eines Musters für Bereitstellungsstempel angeordnet, das in die größere Lösung integriert ist.

Horizontale SaaS-Beispiellösung

Das folgende Architekturbeispiel partitioniert IoT Central für jeden Endkunden und dient als Portal für Geräteverwaltung, Gerätekommunikation und Administration. Diese Partitionierung erfolgt häufig so, dass der Endbenutzer, der die Lösung nutzt, voll kontrolle über das Hinzufügen, Entfernen und Aktualisieren ihrer Geräte hat, ohne dass der Softwareanbieter eingreifen muss. Der Rest der Lösung folgt einem standardmäßigen freigegebenen Infrastrukturmuster, das die Anforderungen an Analysen für den langsamsten Pfad, an geschäftliche Integrationen, die SaaS-Verwaltung und an Geräteanalysen erfüllt.

Jeder Mandant verfügt über eine eigene IoT Central-Organisation, die Telemetriedaten an eine freigegebene Funktions-App sendet und sie den Geschäftsbenutzern der Mandanten über eine Web-App zur Verfügung stellt.

Vorteile:

• Einfach zu verwalten und zu bedienen, obwohl für Single-Tenant-Komponenten möglicherweise eine zusätzliche Verwaltung erforderlich ist.
• Flexible Skalierungsoptionen, da Ebenen nach Bedarf skaliert werden.
• Die Auswirkungen von Komponentenfehlern werden reduziert. Während sich ein Fehler einer gemeinsamen Komponente auf alle Kunden auswirkt, betreffen horizontal skalierte Komponenten nur die Kunden, die bestimmten Skalierungsinstanzen zugeordnet sind.
• Verbesserte Erkenntnisse zum Verbrauch pro Mandant für partitionierte Komponenten.
• Partitionierte Komponenten bieten einfachere Anpassungen pro Mandant.

Risiken:

• Berücksichtigen Sie die Skalierung der Lösung, insbesondere für alle freigegebenen Komponenten.
• Zuverlässigkeit und hohe Verfügbarkeit sind potenziell betroffen. Ein einzelner Fehler in den freigegebenen Komponenten kann sich auf alle Mandanten gleichzeitig auswirken.
• Die Anpassung der partitionierten Komponenten pro Mandant erfordert langfristige Überlegungen zu DevOps und Verwaltung.

Nachfolgend sind die am häufigsten verwendeten Komponenten für die horizontale Partitionierung geeignet.

Datenbanken

Sie können die Datenbanken partitionieren. Häufig sind es die Telemetrie- und Gerätedatenspeicher, die partitioniert sind. Häufig werden mehrere Datenspeicher für unterschiedliche Zwecke verwendet, z. B. für Warm Storage, für die Archivierung von Daten oder für Statusinformationen zum Mandantenabonnement.

Trennen Sie die Datenbanken für jeden Mandanten, um die folgenden Vorteile zu erhalten:

• Unterstützung von Konformitätsstandards. Die Daten der einzelnen Mandanten werden über die Instanzen des Datenspeichers hinweg isoliert.
• Beheben von Problemen aufgrund der Beeinträchtigung durch andere Mandaten (Noisy Neighbors-Effekt).

Geräteverwaltung, Kommunikation und Verwaltung

Azure IoT Hub Device Provisioning Service-, IoT Hub- und IoT Central-Anwendungen können oft als horizontal partitionierte Komponenten bereitgestellt werden. Bei diesem Ansatz benötigen Sie einen weiteren Dienst, um Geräte auf die entsprechende DPS-Instanz für die Verwaltungs-, Steuerungs- und Telemetrieebene des jeweiligen Mandanten weiterzuleiten. Weitere Informationen finden Sie im Whitepaper Aufskalieren einer Azure IoT-Lösung, um Millionen von Geräten zu unterstützen.

Dieser Ansatz wird häufig genutzt, um es den Endbenutzern zu ermöglichen, ihre eigenen Geräteflotten zu verwalten und zu kontrollieren, die direkter und vollständig isoliert sind.

Wenn die Gerätekommunikationsebene horizontal partitioniert ist, müssen die Telemetriedaten mit Daten angereichert werden, die den Quellmandanten identifizieren. Anhand dieser Anreicherung weiß der Datenstromprozessor, welche Mandantenregeln er auf den Datenstrom anwenden muss. Wenn beispielsweise eine Telemetrienachricht eine Benachrichtigung im Streamprozessor generiert, muss der Streamprozessor den richtigen Benachrichtigungspfad für den zugeordneten Mandanten ermitteln.

Datenstromverarbeitung

Durch die Partitionierung der Datenstromverarbeitung können Sie die Analyse innerhalb der Datenstromprozessoren pro Mandant individuell anpassen.

Automatisierte Einzelmandanten

Ein Ansatz mit automatisiertem Einzelmandanten basiert auf einem ähnlichen Entscheidungsprozess und Entwurf wie eine Unternehmenslösung.

Jeder Mandant verfügt über seine eigene identische, isolierte Umgebung mit einer IoT Central-Organisation und anderen für ihn bestimmten Komponenten.

Bereitstellungsziel	Mandantenmodell	Bereitstellungsmuster
Abonnement des Dienstanbieters oder Kunden	Einzelner Mandant pro Kunde	Einfach

Ein wichtiger Entscheidungspunkt bei diesem Ansatz ist die Wahl des Azure-Abonnements, in dem die Komponenten bereitgestellt werden sollen. Wenn die Komponenten im Rahmen eines Abonnements bereitgestellt werden, haben Sie mehr Kontrolle und einen besseren Überblick über die Kosten der Lösung, aber Sie müssen sich auch stärker um die Sicherheit und die Governance der Lösung kümmern. Wird die Lösung hingegen im Rahmen eines Abonnements Ihres Kunden bereitgestellt, ist der Kunde letztendlich für die Sicherheit und die Verwaltung der Bereitstellung verantwortlich.

Dieses Muster unterstützt ein hohes Maß an Skalierbarkeit, da Mandanten- und Abonnementanforderungen in der Regel die Begrenzungsfaktoren in den meisten Lösungen sind. Isolieren Sie daher jeden Mandanten, um einen großen Spielraum für die Skalierung der Workload jedes Mandanten zu haben, ohne dass Sie als Lösungsentwickler einen großen Aufwand betreiben müssen.

Dieses Muster hat im Allgemeinen auch eine geringe Latenz im Vergleich zu anderen Mustern, da Sie die Lösungskomponenten basierend auf der Geografie Ihrer Kunden bereitstellen können. Die geografische Affinität ermöglicht kürzere Netzwerkpfade zwischen einem IoT-Gerät und Ihrer Azure-Bereitstellung.

Bei Bedarf können Sie die automatisierte Bereitstellung erweitern, um eine verbesserte Latenz oder Skalierung zu unterstützen, indem Sie eine schnelle Bereitstellung zusätzlicher Instanzen der Lösung in vorhandenen oder neuen Regionen ermöglichen.

Der Ansatz mit automatisiertem Einzelmandanten ist ähnlich dem einfachen SaaS-aPaaS-Modell. Der Hauptunterschied zwischen den beiden Modellen besteht darin, dass Sie beim Ansatz mit automatisiertem Einzelmandanten eine eigene IoT Central-Instanz für jeden Mandanten bereitstellen, während Sie bei der einfachen SaaS-Lösung mit aPaaS-Modell eine freigegebene Instanz von IoT Central mit mehreren IoT Central-Organisationen bereitstellen.

Vorteile:

• Einfach zu verwalten und zu bedienen.
• Die Mandantenisolation ist garantiert.

Risiken:

• Die anfängliche Automatisierung kann für neue Entwicklungsmitarbeiter kompliziert sein.
• Die Sicherheit von kundenübergreifenden Anmeldeinformationen für die Verwaltung der Bereitstellung auf höherer Ebene muss durchgesetzt werden, sonst können die Kompromisse kundenübergreifend sein.
• Die Kosten werden voraussichtlich höher sein, da die Skalierungsvorteile einer gemeinsamen Infrastruktur für alle Kunden nicht verfügbar sind.
• Viele Instanzen müssen gewartet werden, wenn der Lösungsanbieter die Wartung der einzelnen Instanzen übernimmt.

Erhöhen der Skalierung von SaaS

Wenn Sie die Skalierung einer Lösung auf große Bereitstellungen erweitern, gibt es spezifische Herausforderungen, die auf Dienstgrenzen, geografischen Bedenken und anderen Faktoren basieren. Weitere Informationen zu IoT-Bereitstellungsarchitekturen im großen Stil finden Sie unter Aufskalieren einer Azure IoT-Lösung zur Unterstützung von Millionen von Geräten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Michael C. Bazarewsky | Senior Customer Engineer, FastTrack for Azure
• David Crook | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

• John Downs | Principal Software Engineer
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Nächste Schritte

• Lesen Sie den Leitfaden zu Mehrinstanzenfähigkeit und Azure Cosmos DB.
• Erfahren Sie mehr über heiße, warme und kalte Datenpfade mit IoT in Azure.