Architectuurbenaderingen voor multitenant-oplossingen op basis van IoT Hub

Multitenant IoT Hub-oplossingen zijn beschikbaar in veel verschillende smaken en maten. Mogelijk hebt u veel vereisten en beperkingen, variërend van eigendom van de infrastructuur, tot isolatie van klantgegevens tot naleving. Het kan lastig zijn om een patroon te definiëren dat voldoet aan al deze ontwerpbeperkingen. Hiervoor moet vaak rekening worden gehouden met meerdere dimensies. In dit artikel worden verschillende benaderingen beschreven die vaak worden gebruikt voor het oplossen van multitenancy-overwegingen voor ioT Hub-oplossingen.

Belangrijke overwegingen en vereisten

Deze overwegingen en vereisten worden weergegeven in de volgorde waarin ze doorgaans worden geprioriteerd voor het ontwerp van een oplossing.

Governance en naleving

Governance- en nalevingsoverwegingen vereisen mogelijk dat u een bepaald patroon of een bepaalde set IoT-resources gebruikt. Niet alle IoT-services hebben dezelfde certificeringen of mogelijkheden. Als u moet voldoen aan specifieke nalevingsstandaarden, moet u mogelijk specifieke services selecteren. Zie Architectuurbenaderingen voor governance en naleving in multitenant-oplossingenvoor meer informatie.

Governance in IoT kan ook andere vormen aannemen, zoals apparaateigendom en -beheer. Is de klant eigenaar van het apparaat of is de oplossingsprovider? Wie is eigenaar van het beheer van deze apparaten? Deze overwegingen en implicaties zijn uniek voor elke oplossingsprovider en kunnen leiden tot verschillende keuzes in de technologie, het implementatiepatroon en het multitenancypatroon dat u gebruikt.

Schaal wijzigen

Het is belangrijk om de schaal van uw oplossing te plannen. Schaal wordt vaak overwogen in deze drie dimensies:

• Aantal apparaten: Alle Azure-apparaatbeheerservices - Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) en Azure IoT Hub : hebben beperkingen voor het aantal apparaten dat in één instantie wordt ondersteund.

  Tip

  Raadpleeg de documentatie op grote schaal als u van plan bent een zeer groot aantal apparaten te implementeren.

• Apparaatdoorvoer: verschillende apparaten, zelfs in dezelfde oplossing, kunnen verschillende doorvoervereisten hebben. 'Doorvoer' in deze context verwijst naar zowel het aantal berichten gedurende een bepaalde periode als de grootte van de berichten. Bijvoorbeeld in een:

  • Slimme bouwoplossing, thermostaten rapporteren doorgaans gegevens met een lagere frequentie dan liften.
  • In een oplossing voor verbonden voertuigen zijn voertuigcamera's die gegevensberichten opnemen doorgaans groter dan telemetrieberichten voor navigatie.

  Als uw berichten worden beperkt met betrekking tot frequentie, kunt u overwegen om uit te schalen naar meer exemplaren van een service. Als uw berichten worden beperkt met betrekking tot de grootte, kunt u overwegen om omhoog te schalen naar grotere exemplaren van een service.

• tenants: de schaal van één tenant kan klein zijn, maar wanneer vermenigvuldigd met het aantal tenants, kan deze snel toenemen.

Prestaties en betrouwbaarheid

Isolatie van tenants

Volledig gedeelde oplossingen kunnen luidruchtige buren hebben. In het geval van IoT Hub en IoT Central kunnen lawaaierige buren leiden tot HTTP 429-antwoordcodes ('Te veel aanvragen') die harde fouten kunnen veroorzaken die een trapsgewijs effect kunnen veroorzaken. Zie Quota en beperking voor meer informatie.

In volledig multitenant-oplossingen kunnen deze effecten trapsgewijs worden gebruikt. Wanneer klanten IoT Hub- of IoT Central-toepassingen delen, ontvangen alle klanten in de gedeelde infrastructuur fouten. Omdat IoT Hub en IoT Central vaak de toegangspunten zijn voor gegevens naar de cloud, zullen andere downstreamsystemen die afhankelijk zijn van deze gegevens waarschijnlijk ook mislukken. Vaak is de meest voorkomende reden voor deze fouten wanneer een quotumlimiet voor berichten wordt overschreden. In dit geval is de snelste en eenvoudigste oplossing voor IoT Hub-oplossingen het upgraden van de IoT Hub-SKU, het aantal IoT Hub-eenheden of beide verhogen. Voor IoT Central-oplossingen wordt de schaal van de oplossing automatisch aangepast tot het gedocumenteerde aantal ondersteunde berichten.

U kunt tenants isoleren en distribueren over de IoT-beheer-, beheer- en communicatievlakken met behulp van DPS aangepast toewijzingsbeleid. Als u verder de richtlijnen voor grootschalige IoT-oplossingenvolgt, kunt u andere toewijzingsdistributies beheren op het niveau van de DPS-load balancer.

Gegevensopslag, query, gebruik en retentie

IoT-oplossingen zijn meestal gegevensintensief, zowel tijdens streaming als wanneer de gegevens stilstaand zijn. Zie Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingen voor meer informatie over het beheren van gegevens in oplossingen met meerdere tenants.

Beveiliging

IoT-oplossingen hebben vaak beveiligingsoverwegingen op meerdere lagen, met name in oplossingen die zijn geïmplementeerd in een in de cloud gewijzigde Purdue Enterprise Reference Architecture of Industry 4.0-oplossingen . De ontwerpbenadering die u selecteert, is van invloed op de netwerklagen en grenzen; nadat u het fysieke ontwerp hebt geselecteerd, kunt u de beveiligingsmplementatie selecteren. U kunt de volgende hulpprogramma's gebruiken in elke benadering:

• Microsoft Defender voor IoT, een uitgebreide IoT-bewakingsoplossing die u moet overwegen, biedt een EIoT-licentie per apparaat en OT-sitelicenties voor elk klantapparaat en/of elke site. Afhankelijk van de methode die verderop in dit artikel is geselecteerd, kan het scenario voor Microsoft 365-gebruikerslicenties mogelijk niet haalbaar zijn. In dat geval zijn de licentieopties per apparaat en site beschikbaar. Dit zijn licentieopties onafhankelijk van Microsoft 365-tenantlicenties.

• Azure Firewall of een niet-Microsoft-firewallapparaat, waarmee u rekening moet houden bij het isoleren van de netwerklagen en het bewaken van netwerkverkeer. De exacte keuze van de aanpak bepaalt waar workloads netwerkisolatie versus een gedeeld netwerk hebben, zoals verderop in dit artikel wordt behandeld.

• Azure IoT Edge-.

De meeste van deze beveiligingsonderwerpen zijn van toepassing in een multitenant-oplossing die vergelijkbaar is met de manier waarop ze zich in één tenantoplossing zouden bevinden, met de variaties die zijn gekoppeld aan de geselecteerde benadering. Een onderdeel dat waarschijnlijk aanzienlijk verschilt in een algemene IoT-oplossing is de gebruikers- en toepassingsidentiteit. Architectuurbenaderingen voor identiteit in multitenant-oplossingen bespreken dit aspect van een algemene multitenant-oplossing.

Methoden om rekening mee te houden

De overwegingen en keuzes voor primaire onderdelen, zoals beheer, opname, verwerking, opslag en beveiliging, zijn hetzelfde voor enkele en multitenant IoT-oplossingen. Het belangrijkste verschil is hoe u de onderdelen rangschikt en gebruikt om multitenancy te ondersteunen. Bijvoorbeeld algemene beslissingspunten voor:

• Opslag kan ervoor kiezen om SQL Server of Azure Data Explorer te gebruiken.
• De opname- en beheerlaag is om te kiezen tussen IoT Hub en IoT Central.

De meeste IoT-oplossingen passen binnen een hoofdarchitectuurpatroon. Dit is een combinatie van het implementatiedoel, het tenancymodel en het implementatiepatroon. De belangrijkste vereisten en overwegingen die eerder zijn beschreven, bepalen deze factoren.

Een van de grootste beslissingspunten die moeten worden genomen, binnen de IoT-ruimte, is om te kiezen tussen een PaaS-benadering (platform-as-a-service) en paaS-benaderingen (platform-as-a-service). Zie IoT-oplossingsmethoden (Internet of Things) vergelijken (PaaS versus aPaaS)voor meer informatie.

Deze keuze is het veelvoorkomende 'build versus buy'-dilemma waarmee veel organisaties te maken hebben in veel projecten. Het is belangrijk om de voor- en nadelen van beide opties te evalueren.

Concepten en overwegingen voor aPaaS-oplossingen

Een typische aPaaS-oplossing die Gebruikmaakt van Azure IoT Central, als kern van de oplossing, kan gebruikmaken van de volgende Azure PaaS- en aPaaS-services:

• Azure Event Hubs als een platformoverschrijdende, hoogwaardige berichten- en gegevensstroomengine.
• Azure Logic Apps als een integratieplatform-as-a-service of iPaaS-aanbieding.
• Azure Data Explorer als een data analytics-platform.
• Power BI als visualisatie- en rapportageplatform.

In het vorige diagram delen de tenants een IoT Central-omgeving, Azure Data Explorer, Power BI en Azure Logic Apps.

Deze aanpak is over het algemeen de snelste manier om een oplossing op de markt te krijgen. Het is een grootschalige service die ondersteuning biedt voor multitenancy door organisaties te gebruiken.

Het is belangrijk te begrijpen dat er, omdat IoT Central een aPaaS-aanbieding is, bepaalde beslissingen buiten de controle van de implementeerfunctie vallen. Deze beslissingen omvatten:

• IoT Central gebruikt Microsoft Entra ID als id-provider.
• IoT Central-implementaties worden bereikt met behulp van besturings- en gegevensvlakbewerkingen, die declaratieve documenten combineren met imperatieve code.
• Maximale knooppuntlimiet en maximale structuurdiepte in een op IoT Central gebaseerd multitenant-patroon, kan een serviceprovider ertoe dwingen meerdere IoT Central-exemplaren te hebben. In dat geval moet u overwegen het patroon Implementatiestempel te volgen.
• IoT Central legt API-aanroeplimieten op, wat van invloed kan zijn op grote implementaties.

Concepten en overwegingen voor PaaS-oplossingen

Een op PaaS gebaseerde benadering kan gebruikmaken van de volgende Azure-services:

• Azure IoT Hub als het belangrijkste apparaatconfiguratie- en communicatieplatform.
• Azure IoT Device Provisioning Service als de implementatie van het apparaat en het eerste configuratieplatform.
• Azure Data Explorer voor het opslaan en analyseren van tijdreeksgegevens van warme en koude paden van IoT-apparaten.
• Azure Stream Analytics voor het analyseren van hot path-gegevens van IoT-apparaten.
• Azure IoT Edge- voor het uitvoeren van kunstmatige intelligentie (AI), niet-Microsoft-services of uw eigen bedrijfslogica op IoT Edge-apparaten.

In het vorige diagram maakt elke tenant verbinding met een gedeelde web-app, die gegevens ontvangt van IoT Hubs en een functie-app. Apparaten maken verbinding met Device Provisioning Service en ioT Hubs.

Deze aanpak vereist meer inspanningen van ontwikkelaars om de oplossing te maken, te implementeren en te onderhouden (versus een aPaaS-benadering). Er zijn minder mogelijkheden vooraf gebouwd voor het gemak van de implementeerfunctie. Daarom biedt deze aanpak ook meer controle, omdat er minder veronderstellingen zijn ingesloten in het onderliggende platform.

Hoofdarchitectuurpatronen

De volgende tabel bevat algemene patronen voor multitenant IoT-oplossingen. Elk patroon bevat de volgende informatie:

• De naam van het patroon, dat is gebaseerd op de combinatie van het doel, model en implementatietype.
• Het implementatiedoel, dat het Azure-abonnement vertegenwoordigt voor het implementeren van resources.
• Het Tenancy-model waarnaar wordt verwezen door het patroon, zoals beschreven in Multitenancy-modellen
• Het implementatiepatroon, die verwijst naar een eenvoudige implementatie met minimale implementatieoverwegingen, een geode-patroon of een patroon implementatiestempel.

Patroon	Implementatiedoel	Tenancymodel	Implementatiepatroon
Eenvoudige SaaS	Abonnement van serviceprovider	Volledig multitenant	Eenvoudig
Horizontale SaaS	Abonnement van serviceprovider	Horizontaal gepartitioneerd	Implementatiestempel
Geautomatiseerde één tenant	Abonnement van serviceprovider of klant	Eén tenant per klant	Eenvoudig

Eenvoudige SaaS

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider	Volledig multitenant	Eenvoudig

De eenvoudige SaaS-benadering is de eenvoudigste implementatie voor een SaaS IoT-oplossing. Zoals in het vorige diagram wordt weergegeven, wordt alle infrastructuur gedeeld en is er geen geografische of schaalstempel toegepast op de infrastructuur. Vaak bevindt de infrastructuur zich binnen één Azure-abonnement.

Azure IoT Central ondersteunt het concept van organisaties. Organisaties stellen een oplossingsprovider in staat om tenants eenvoudig te scheiden op een veilige, hiërarchische manier, terwijl het basistoepassingsontwerp wordt gedeeld in alle tenants.

Communicatie met systemen buiten IoT Central, zoals voor gegevensanalyse op langere termijn, langs een koud pad of connectiviteit met bedrijfsactiviteiten, wordt uitgevoerd via andere Microsoft PaaS- en aPaaS-aanbiedingen. Deze andere aanbiedingen kunnen de volgende services omvatten:

• Azure Event Hubs als een platformoverschrijdende engine voor berichten en gegevensstromen op bedrijfsniveau.
• Azure Logic Apps als een integratieplatform als een service of iPaaS.
• Azure Data Explorer als een data analytics-platform.
• Power BI als visualisatie- en rapportageplatform.

Als u de eenvoudige SaaS-benadering vergelijkt met het geautomatiseerde aPaaS-model met één tenant, zijn veel kenmerken vergelijkbaar. Het belangrijkste verschil tussen de twee modellen is dat:

• In het geautomatiseerde-model voor één tenant implementeert u een afzonderlijk IoT Central-exemplaar voor elke tenant,
• In de Simple SaaS met aPaaS model implementeert u een gedeeld exemplaar voor meerdere klanten en maakt u een IoT Central-organisatie voor elke tenant.

Omdat u een multitenant-gegevenslaag in dit model deelt, moet u beveiliging op rijniveau implementeren om de klantgegevens te isoleren. Zie Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingenvoor meer informatie.

Voordelen:

• Eenvoudiger te beheren en te gebruiken ten opzichte van de andere benaderingen die hier worden gepresenteerd.

Risico's:

• Deze benadering kan niet eenvoudig schalen naar grote aantallen apparaten, berichten of tenants.

• Services en onderdelen worden gedeeld, waardoor een fout in elk onderdeel van invloed kan zijn op al uw tenants. Dit risico is een risico voor de betrouwbaarheid en hoge beschikbaarheid van uw oplossing.

• Het is belangrijk om na te gaan hoe u de naleving, operaties, de levenscyclus van de gebruikers en de beveiliging van deelvloten van apparaten beheert. Deze overwegingen worden belangrijk vanwege de gedeelde aard van dit oplossingstype op de besturings-, beheer- en communicatievlakken.

Horizontale SaaS

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider	Horizontaal gepartitioneerd	Implementatiestempel

Een algemene schaalbaarheidsbenadering is het horizontaal partitioneren van de oplossing. Dit betekent dat u een aantal gedeelde onderdelen en enkele onderdelen per klant hebt.

Binnen een IoT-oplossing zijn er veel onderdelen die horizontaal kunnen worden gepartitioneerd. De horizontaal gepartitioneerde subsystemen worden doorgaans gerangschikt met behulp van een implementatiestempelpatroon dat kan worden geïntegreerd met de grotere oplossing.

Voorbeeld van horizontale SaaS

Het volgende architectuurvoorbeeld partitioneert IoT Central per eindklant, die fungeert als de portal voor apparaatbeheer, apparaatcommunicatie en beheer. Deze partitionering wordt vaak uitgevoerd op een zodanige manier dat de eindklant die de oplossing gebruikt, volledige controle heeft over het toevoegen, verwijderen en bijwerken van hun apparaten, zonder tussenkomst van de softwareleverancier. De rest van de oplossing volgt een standaardpatroon voor gedeelde infrastructuur, dat oplossing biedt voor hot path-analyse, bedrijfsintegraties, SaaS-beheer en apparaatanalysebehoeften.

Elke tenant heeft een eigen IoT Central-organisatie, die telemetrie verzendt naar een gedeelde functie-app en deze beschikbaar maakt voor de zakelijke gebruikers van de tenants via een web-app.

Voordelen:

• Eenvoudig te beheren en te bedienen, hoewel extra beheer mogelijk vereist is voor onderdelen met één tenant.
• Flexibele schaalopties, omdat lagen zo nodig worden geschaald.
• Het effect van onderdeelfouten wordt verminderd. Hoewel een fout in een gedeeld onderdeel van invloed is op alle klanten, hebben horizontaal geschaalde onderdelen alleen invloed op de klanten die zijn gekoppeld aan specifieke schaalexemplaren.
• Verbeterde inzichten per tenantverbruik voor gepartitioneerde onderdelen.
• Gepartitioneerde onderdelen bieden eenvoudiger aanpassingen per tenant.

Risico's:

• Schaal van de oplossing, vooral voor gedeelde componenten.
• Betrouwbaarheid en hoge beschikbaarheid worden mogelijk beïnvloed. Een enkele fout in de gedeelde onderdelen kan van invloed zijn op alle tenants tegelijk.
• Voor het aanpassen van gepartitioneerde onderdelen per tenant zijn devOps en beheeroverwegingen voor de lange termijn vereist.

Hieronder ziet u de meest voorkomende onderdelen die doorgaans geschikt zijn voor horizontale partitionering.

Databases

U kunt ervoor kiezen om de databases te partitioneren. Vaak zijn het de telemetrie- en apparaatgegevensarchieven die zijn gepartitioneerd. Vaak worden meerdere gegevensarchieven gebruikt voor verschillende specifieke doeleinden, zoals warme en archiveringsopslag, of voor informatie over de status van tenancyabonnementen.

Scheid de databases voor elke tenant voor de volgende voordelen:

• Ondersteuning voor nalevingsstandaarden. De gegevens van elke tenant worden geïsoleerd in exemplaren van het gegevensarchief.
• Problemen met lawaaierige buren oplossen.

Apparaatbeheer, communicatie en beheer

Azure IoT Hub Device Provisioning Service-, IoT Hub- en IoT Central-toepassingen kunnen vaak worden geïmplementeerd als horizontaal gepartitioneerde onderdelen. In deze benadering hebt u een andere service nodig om apparaten om te leiden naar het juiste DPS-exemplaar voor het beheer, de controle en het telemetrievlak van die specifieke tenant. Voor meer informatie, zie het whitepaper Een Azure IoT-oplossing uitschalen ter ondersteuning van miljoenen apparaten.

Deze aanpak wordt vaak gebruikt om de eindklanten in staat te stellen hun eigen vloot van apparaten te beheren die meer direct en volledig geïsoleerd zijn.

Als het communicatievlak van het apparaat horizontaal is gepartitioneerd, moeten telemetriegegevens worden verrijkt met gegevens die de brontenant identificeren. Met deze verrijking kan de streamprocessor weten welke tenantregels moeten worden toegepast op de gegevensstroom. Als een telemetriebericht bijvoorbeeld een melding genereert in de streamprocessor, moet de streamprocessor het juiste meldingspad voor de gekoppelde tenant bepalen.

Stroomverwerking

Door streamverwerking te partitioneren, schakelt u aanpassingen per tenant in van de analyse binnen de streamprocessors.

Geautomatiseerde één tenant

Een geautomatiseerde benadering met één tenant is gebaseerd op een soortgelijk beslissingsproces en ontwerp voor een bedrijfsoplossing.

Elke tenant heeft een eigen identieke, geïsoleerde omgeving, met een IoT Central-organisatie en andere onderdelen die eraan zijn toegewezen.

Implementatiedoel	Tenancymodel	Implementatiepatroon
Abonnement van serviceprovider of klant	Eén tenant per klant	Eenvoudig

Een kritiek beslissingspunt in deze benadering is het kiezen van welk Azure-abonnement de onderdelen moeten worden geïmplementeerd. Als de onderdelen zijn geïmplementeerd in uw abonnement, hebt u meer controle en beter inzicht in de kosten van de oplossing, maar moet u meer van de beveiligings- en governanceproblemen van de oplossing hebben. Als de oplossing echter wordt geïmplementeerd in het abonnement van uw klant, is de klant uiteindelijk verantwoordelijk voor de beveiliging en governance van de implementatie.

Dit patroon ondersteunt een hoge mate van schaalbaarheid, omdat tenant- en abonnementsvereisten over het algemeen de beperkende factoren in de meeste oplossingen zijn. Isoleer daarom elke tenant om een groot bereik te bieden voor het schalen van de workload van elke tenant, zonder dat u hiervoor aanzienlijke inspanningen hoeft uit te voeren als oplossingsontwikkelaar.

Dit patroon heeft over het algemeen ook een lage latentie, in vergelijking met andere patronen, omdat u de oplossingsonderdelen kunt implementeren op basis van de geografie van uw klanten. Geografische affiniteit maakt kortere netwerkpaden mogelijk tussen een IoT-apparaat en uw Azure-implementatie.

Indien nodig kunt u de geautomatiseerde implementatie uitbreiden ter ondersteuning van verbeterde latentie of schaal door snelle implementatie van extra exemplaren van de oplossing in bestaande of nieuwe geografische gebieden mogelijk te maken.

De geautomatiseerde benadering met één tenant is vergelijkbaar met het eenvoudige SaaS aPaaS-model. Het belangrijkste verschil tussen de twee modellen is dat u in de geautomatiseerde benadering met één tenant een afzonderlijk IoT Central-exemplaar voor elke tenant implementeert, terwijl u in de eenvoudige SaaS met eenPaaS-model een gedeeld exemplaar van IoT Central implementeert met meerdere IoT Central-organisaties.

Voordelen:

• Eenvoudig te beheren en te bedienen.
• Tenantisolatie is gegarandeerd.

Risico's:

• Initiële automatisering kan ingewikkeld zijn voor nieuwe ontwikkelmedewerkers.
• Beveiliging van referenties voor meerdere klanten voor implementatiebeheer op een hoger niveau moet worden afgedwongen, of de compromissen kunnen worden uitgebreid tussen klanten.
• De kosten zijn naar verwachting hoger, omdat de schaalvoordelen van een gedeelde infrastructuur voor klanten niet beschikbaar zijn.
• Veel exemplaren die moeten worden onderhouden als de oplossingsprovider eigenaar is van het onderhoud van elk exemplaar.

De schaal van SaaS vergroten

Wanneer u de schaal van een oplossing uitbreidt naar grote implementaties, zijn er specifieke uitdagingen die zich voordoen op basis van servicelimieten, geografische problemen en andere factoren. Zie Een Azure IoT-oplossing uitschalen ter ondersteuning van miljoenen apparaten voor meer informatie over grootschalige IoT-implementatiearchitecturen.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

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

Andere Inzenders:

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

Volgende stappen

• Bekijk de richtlijnen voor multitenancy en Azure Cosmos DB.
• Meer informatie over dynamische, warme en koude gegevenspaden met IoT in Azure.