Arkitekturmetoder för IoT Hub-baserade lösningar för flera klientorganisationer

Multitenant IoT Hub-baserade lösningar finns i många olika smaker och storlekar. Du kan ha många krav och begränsningar, allt från infrastrukturägarskap till isolering av kunddata till efterlevnad. Det kan vara svårt att definiera ett mönster som uppfyller alla dessa designbegränsningar, och det kräver ofta att du överväger flera dimensioner. Den här artikeln beskriver flera metoder som ofta används för att lösa överväganden för flera klientorganisationer för IoT Hub-baserade lösningar.

Viktiga överväganden och krav

Dessa överväganden och krav presenteras i den ordning de vanligtvis prioriteras för en lösnings design.

Styrning och efterlevnad

Styrnings- och efterlevnadsöverväganden kan kräva att du använder ett visst mönster eller en uppsättning IoT-resurser. Alla IoT-tjänster har inte samma certifieringar eller funktioner. Om du behöver uppfylla specifika efterlevnadsstandarder kan du behöva välja specifika tjänster. Mer information finns i arkitektoniska metoder för styrning och efterlevnad i lösningar för flera klientorganisationer.

Styrning i IoT kan också ta andra former, till exempel enhetsägarskap och hantering. Äger kunden enheten eller är lösningsleverantören? Vem äger hanteringen av dessa enheter? Dessa överväganden och konsekvenser är unika för varje lösningsleverantör och kan leda till olika val i teknik, distributionsmönster och fleraktiveringsmönster som du använder.

Skala

Det är viktigt att planera lösningens skala. Skala övervägs ofta i dessa tre dimensioner:

• Antal enheter: Alla Azure-enhetshanteringstjänster – Azure IoT Central, Azure IoT Hub Device Provisioning Service (DPS) och Azure IoT Hub – har begränsningar för antalet enheter som stöds i en enda instans.

  Dricks

  Se den storskaliga dokumentationen om du planerar att distribuera ett mycket stort antal enheter.

• Enhetsdataflöde: Olika enheter, även i samma lösning, kan ha olika dataflödeskrav. "Dataflöde" i den här kontexten refererar till både antalet meddelanden under en tidsperiod och storleken på meddelandena. Till exempel i en:

  • Smart lösning, termostater rapporterar vanligtvis data med lägre frekvens än hissar.
  • I en lösning för anslutna fordon är fordonskameran som registrerar datameddelanden vanligtvis större än navigeringstelemetrimeddelanden.

  Om dina meddelanden begränsas med avseende på frekvens kan du överväga att skala ut till fler instanser av en tjänst. Om dina meddelanden begränsas med avseende på storlek kan du överväga att skala upp till större instanser av en tjänst.

• hyresgäster: En enskild hyresgästs skala kan vara liten, men när den multipliceras med antalet hyresgäster kan den snabbt växa.

Prestanda och pålitlighet

Isolering av klientorganisation

Fullständigt delade lösningar kan ha bullriga grannar. När det gäller IoT Hub och IoT Central kan bullriga grannar resultera i HTTP 429-svarskoder ("För många förfrågningar") som är svåra fel som kan orsaka en sammanhängande effekt. Mer information finns i Kvoter och begränsning.

I helt multitenantlösningar kan dessa effekter överlappas. När kunder delar IoT Hub- eller IoT Central-program får alla kunder i den delade infrastrukturen fel. Eftersom IoT Hub och IoT Central ofta är startpunkter för data till molnet kommer även andra underordnade system som är beroende av dessa data att misslyckas. Den vanligaste orsaken till dessa fel är ofta när en meddelandekvotgräns överskrids. I den här situationen är den snabbaste och enklaste korrigeringen för IoT Hub-lösningar att uppgradera IoT Hub SKU, öka antalet IoT Hub-enheter eller båda. För IoT Central-lösningar skalar lösningen automatiskt efter behov, upp till det dokumenterade antalet meddelanden som stöds.

Du kan isolera och distribuera hyresgäster över IoT-kontroll-, hanterings- och kommunikationsplanerna med hjälp av DPS anpassade allokeringsprinciper. När du följer riktlinjerna för storskaliga IoT-lösningarkan du dessutom hantera andra allokeringsdistributioner på DPS-lastbalanserarens nivå.

Datalagring, fråga, användning och kvarhållning

IoT-lösningar tenderar att vara dataintensiva, både vid direktuppspelning och i vila. Mer information om hur du hanterar data i lösningar för flera klientorganisationer finns i Arkitekturmetoder för lagring och data i lösningar med flera klientorganisationer.

Säkerhet

IoT-lösningar har ofta säkerhetsöverväganden i flera lager, särskilt i lösningar som distribueras i en molnmodifierad Purdue Enterprise-referensarkitektur eller bransch 4.0-lösningar . Den designmetod som du väljer påverkar vilka nätverksskikt och gränser som finns. När du har valt den fysiska designen kan du välja säkerhetsimplementeringen. Du kan använda följande verktyg i valfri metod:

• Microsoft Defender för IoT, en omfattande IoT-övervakningslösning som du bör överväga som erbjuder en EIoT-licens per enhet och OT-platslicenser för varje kundenhet och/eller webbplats. Beroende på vilken metod som väljs senare i den här artikeln kan det hända att scenariot för namngiven användarlicensiering av Microsoft 365 inte är möjligt. I så fall är licensalternativen per enhet och plats tillgängliga, vilket är licensalternativ som är oberoende av Microsoft 365-klientlicenser.

• Azure Firewall eller en icke-Microsoft-brandväggsapplikation, som du bör överväga för att isolera nätverkslager och övervaka nätverkstrafiken. Det exakta valet av metod avgör var arbetsbelastningar har nätverksisolering jämfört med ett delat nätverk, vilket beskrivs senare i den här artikeln.

• Azure IoT Edge.

De flesta av dessa säkerhetsämnen gäller i en lösning med flera klienter som liknar hur de skulle göra i en enda klientlösning, med variationerna knutna till den valda metoden. En komponent som sannolikt kommer att vara väsentligt annorlunda i en övergripande IoT-lösning är användar- och programidentitet. Arkitekturmetoder för identitet i lösningar med flera klientorganisationer diskuterar den här aspekten av en övergripande lösning för flera klientorganisationer.

Metoder att tänka på

Överväganden och val för primära komponenter, till exempel hantering, inmatning, bearbetning, lagring och säkerhet, är desamma för IoT-lösningar med en enda och flera klienter. Den främsta skillnaden är hur du ordnar och använder komponenterna för att stödja flera klientorganisationer. Till exempel vanliga beslutspunkter för:

• Lagring kan vara att välja att använda SQL Server eller Azure Data Explorer.
• Inmatnings- och hanteringsnivån är att välja mellan IoT Hub och IoT Central.

De flesta IoT-lösningar passar in i ett rotarkitekturmönster, vilket är en kombination av distributionsmål, innehavarmodell och distributionsmönster. De viktigaste kraven och övervägandena som beskrivs tidigare bestämmer dessa faktorer.

En av de största beslutspunkterna som behöver fattas inom IoT-utrymmet är att välja mellan en aPaaS-metod (application-platform-as-a-service) och paaS-metoder (platform-as-a-service). Mer information finns i Compare Internet of Things (IoT) solution approaches (PaaS vs. aPaaS).

Det här valet är det vanliga dilemmat "build versus buy" som många organisationer står inför i många projekt. Det är viktigt att utvärdera fördelarna och nackdelarna med båda alternativen.

Begrepp och överväganden för aPaaS-lösningar

En typisk aPaaS-lösning som använder Azure IoT Central, som kärnan i lösningen, kan använda följande Azure PaaS- och aPaaS-tjänster:

• Azure Event Hubs som en plattformsoberoende meddelande- och dataflödesmotor i företagsklass.
• Azure Logic Apps som en integreringsplattform som en tjänst, eller iPaaS-erbjudande.
• Azure Data Explorer som en dataanalysplattform.
• Power BI som en visualiserings- och rapporteringsplattform.

I föregående diagram delar klienterna en IoT Central-miljö, Azure Data Explorer, Power BI och Azure Logic Apps.

Den här metoden är i allmänhet det snabbaste sättet att få en lösning på marknaden. Det är en storskalig tjänst som stöder flera klientorganisationer med hjälp av organisationer.

Det är viktigt att förstå att eftersom IoT Central är ett aPaaS-erbjudande finns det vissa beslut som ligger utanför implementeringsverktygets kontroll. Dessa beslut omfattar:

• IoT Central använder Microsoft Entra ID som identitetsprovider.
• IoT Central-distributioner uppnås med hjälp av både kontroll- och dataplansåtgärder, som kombinerar deklarativa dokument med imperativ kod.
• Maximal nodgräns och maximalt träddjup i ett IoT Central-baserat multitenantmönster kan tvinga en tjänstleverantör att ha flera IoT Central-instanser. I så fall bör du överväga att följa mönstret Distributionsstämpel.
• IoT Central inför API-anropsgränser, vilket kan påverka stora implementeringar.

Begrepp och överväganden för PaaS-lösningar

En PaaS-baserad metod kan använda följande Azure-tjänster:

• Azure IoT Hub som kärnplattform för enhetskonfiguration och kommunikation.
• Azure IoT Device Provisioning Service som enhetsdistribution och inledande konfigurationsplattform.
• Azure Data Explorer för att lagra och analysera tidsseriedata för varm och kall sökväg från IoT-enheter.
• Azure Stream Analytics för att analysera snabbsökvägsdata från IoT-enheter.
• Azure IoT Edge- för körning av artificiell intelligens (AI), tjänster som inte kommer från Microsoft eller din egen affärslogik på IoT Edge-enheter.

I föregående diagram ansluter varje klientorganisation till en delad webbapp som tar emot data från IoT Hubs och en funktionsapp. Enheter ansluter till enhetsetableringstjänsten och till IoT Hubs.

Den här metoden kräver mer utvecklararbete för att skapa, distribuera och underhålla lösningen (jämfört med en aPaaS-metod). Färre funktioner är fördefinierade för implementerarens bekvämlighet. Därför ger den här metoden också mer kontroll, eftersom färre antaganden är inbäddade i den underliggande plattformen.

Rotarkitekturmönster

I följande tabell visas vanliga mönster för IoT-lösningar med flera klientorganisationer. Varje mönster innehåller följande information:

• Namnet på mönstret, som baseras på kombinationen av mål-, modell- och distributionstypen.
• Distributionsmålet, som representerar den Azure-prenumeration som du vill distribuera resurser till.
• Innehavarmodellen som refereras av mönstret, enligt beskrivningen i Modeller för flera innehavare
• Distributionsmönstret, som refererar till en enkel distribution med minimala distributionsöverväganden, ett Geode-mönster eller ett mönster för distributionsstämpel.

Enkel SaaS

Metoden Simple SaaS är den enklaste implementeringen för en SaaS IoT-lösning. Som det föregående diagrammet visar delas all infrastruktur och infrastrukturen har ingen geografisk stämpel eller skalningsstämpling tillämpad. Ofta finns infrastrukturen i en enda Azure-prenumeration.

Azure IoT Central stöder begreppet organisationer. Organisationer gör det möjligt för en lösningsleverantör att enkelt separera klienter på ett säkert, hierarkiskt sätt, samtidigt som den grundläggande programdesignen delas mellan alla klienter.

Kommunikation till system utanför IoT Central, till exempel för långsiktig dataanalys, längs en kall väg eller anslutning med affärsåtgärder, sker via andra Microsoft PaaS- och aPaaS-erbjudanden. Dessa andra erbjudanden kan omfatta följande tjänster:

• Azure Event Hubs som en plattformsoberoende meddelande- och dataflödesmotor i företagsklass.
• Azure Logic Apps som en integreringsplattform som en tjänst eller iPaaS.
• Azure Data Explorer som en dataanalysplattform.
• Power BI som en visualiserings- och rapporteringsplattform.

Om du jämför metoden Simple SaaS med den automatiserade aPaaS-modellen för enskild klientorganisation är många egenskaper liknande. Den primära skillnaden mellan de två modellerna är att:

• I den automatiserade modellen för enskilda klientorganisationer distribuerar du en distinkt IoT Central-instans för varje klientorganisation.
• I Simple SaaS med aPaaS modell distribuerar du en delad instans för flera kunder och skapar en IoT Central-organisation för varje klientorganisation.

Eftersom du delar en datanivå för flera klientorganisationer i den här modellen måste du implementera säkerhet på radnivå för att isolera kunddata. Mer information finns i arkitekturmetoder för lagring och data i lösningar för flera klientorganisationer.

Fördelar:

• Enklare att hantera och använda i förhållande till andra metoder som presenteras här.

Risker:

• Den här metoden kanske inte är lätt att skala till ett stort antal enheter, meddelanden eller klienter.

• Tjänster och komponenter delas, och därför kan ett fel i en komponent påverka alla dina klienter. Den här risken är en risk för lösningens tillförlitlighet och höga tillgänglighet.

• Det är viktigt att tänka på hur du hanterar efterlevnad, drift, klientlivscykel och säkerhet över delparker av enheter. Dessa överväganden blir viktiga på grund av den delade karaktären hos den här lösningstypen på kontroll-, hanterings- och kommunikationsplanerna.

Vågrät SaaS

En vanlig skalbarhetsmetod är att horisontellt partitioneras lösningen. Det innebär att du har vissa delade komponenter och vissa komponenter per kund.

I en IoT-lösning finns det många komponenter som kan partitioneras vågrätt. De vågrätt partitionerade undersystemen ordnas vanligtvis med hjälp av ett mönster för distributionsstämpel som integreras med den större lösningen.

Exempel vågrät SaaS

I följande arkitekturexempel partitioneras IoT Central per slutkund, som fungerar som portalen för enhetshantering, enhetskommunikation och administration. Den här partitioneringen görs ofta på ett sådant sätt att slutkund som använder lösningen har fullständig kontroll över att lägga till, ta bort och uppdatera sina enheter, utan åtgärder från programvaruleverantören. Resten av lösningen följer ett standardmönster för delad infrastruktur som löser analys av frekventa sökvägar, affärsintegreringar, SaaS-hantering och enhetsanalysbehov.

Varje klientorganisation har en egen IoT Central-organisation som skickar telemetri till en delad funktionsapp och gör den tillgänglig för klientorganisationens företagsanvändare via en webbapp.

Fördelar:

• Lätt att hantera och använda, även om extra hantering kan krävas för singletenant-komponenter.
• Flexibla skalningsalternativ eftersom lagren skalas efter behov.
• Effekten av komponentfel minskar. Ett fel i en delad komponent påverkar alla kunder, men horisontellt skalbara komponenter påverkar bara de kunder som är associerade med specifika skalningsinstanser.
• Förbättrade insikter om förbrukning per klientorganisation för partitionerade komponenter.
• Partitionerade komponenter ger enklare anpassningar per klientorganisation.

Risker:

• Skalning av lösningen, särskilt för alla gemensamma komponenter.
• Tillförlitlighet och hög tillgänglighet kan påverkas. Ett enskilt fel i de delade komponenterna kan påverka alla klienter samtidigt.
• Anpassningen av partitionerade komponenter per klientorganisation kräver långsiktiga DevOps- och hanteringsöverväganden.

Följande är de vanligaste komponenterna som vanligtvis är lämpliga för horisontell partitionering.

Databaser

Du kan välja att partitionering av databaserna. Ofta är det telemetri- och enhetsdatalager som är partitionerade. Ofta används flera datalager för olika specifika ändamål, till exempel varm eller arkiveringslagring, eller för statusinformation för innehavarprenumeration.

Avgränsa databaserna för varje klientorganisation för följande fördelar:

• Stöd för efterlevnadsstandarder. Varje klientorganisations data är isolerade mellan instanser av datalagret.
• Åtgärda problem med bullriga grannar.

Enhetshantering, kommunikation och administration

Azure IoT Hub Device Provisioning Service, IoT Hub och IoT Central-program kan ofta distribueras som horisontellt partitionerade komponenter. I den här metoden behöver du en annan tjänst för att omdirigera enheter till lämplig DPS-instans för just den klientorganisationens hanterings-, kontroll- och telemetriplan. Mer information finns i Att skala ut en Azure IoT-lösning för att stödja miljontals enheter white paper.

Den här metoden används ofta för att göra det möjligt för slutkunderna att hantera och kontrollera sina egna flottor av enheter som är mer direkt och fullständigt isolerade.

Om enhetens kommunikationsplan är horisontellt partitionerat måste telemetridata utökas med data som identifierar källklientorganisationen. Med denna berikning görs det möjligt för dataströmprocessorn att veta vilka av hyresgästernas regler som ska tillämpas på dataströmmen. Om ett telemetrimeddelande till exempel genererar en notifikation i strömprocessorn måste strömprocessorn fastställa rätt notifikationssökväg för den associerade klientorganisationen.

Dataströmbearbetning

Genom att partitionera dataströmbearbetning aktiverar du anpassningar per klientorganisation av analysen i dataströmprocessorerna.

Automatiserad enskild klientorganisation

En automatiserad metod för en enda klientorganisation baseras på en liknande beslutsprocess och design som en företagslösning.

Varje klientorganisation har en egen identisk, isolerad miljö med en IoT Central-organisation och andra komponenter som är dedikerade till dem.

En viktig beslutspunkt i den här metoden är att välja vilken Azure-prenumeration komponenterna ska distribueras till. Om komponenterna distribueras till din prenumeration har du mer kontroll och bättre insyn i kostnaden för lösningen, men det kräver att du äger mer av lösningens säkerhets- och styrningsproblem. Om lösningen däremot distribueras i kundens prenumeration är kunden ytterst ansvarig för säkerheten och styrningen av distributionen.

Det här mönstret stöder en hög grad av skalbarhet eftersom klient- och prenumerationskrav i allmänhet är de begränsande faktorerna i de flesta lösningar. Isolera därför varje klientorganisation för att ge ett stort omfång för skalning av varje klientorganisations arbetsbelastning, utan någon större ansträngning från din sida, som lösningsutvecklare.

Det här mönstret har också vanligtvis låg svarstid jämfört med andra mönster, eftersom du kan distribuera lösningskomponenterna baserat på kundernas geografiska område. Geografisk tillhörighet möjliggör kortare nätverkssökvägar mellan en IoT-enhet och din Azure-distribution.

Om det behövs kan du utöka den automatiserade distributionen så att den stöder förbättrad svarstid eller skala genom att aktivera snabb distribution av extra instanser av lösningen i befintliga eller nya geografiska områden.

Den automatiserade metoden för en klientorganisation liknar den enkla SaaS aPaaS-modellen. Den främsta skillnaden mellan de två modellerna är att du distribuerar en distinkt IoT Central-instans för varje klientorganisation i den enkla SaaS med aPaaS-modellen, medan du distribuerar en delad instans av IoT Central med flera IoT Central-organisationer i den enkla SaaS med aPaaS-modellen.

Fördelar:

• Lätt att hantera och använda.
• Klientisolering garanteras.

Risker:

• Inledande automatisering kan vara komplicerat för ny utvecklingspersonal.
• Säkerhet för autentiseringsuppgifter mellan kunder för distributionshantering på högre nivå måste framtvingas eller så kan kompromisserna utökas mellan kunder.
• Kostnaderna förväntas bli högre eftersom skalningsfördelarna med en delad infrastruktur mellan kunderna inte är tillgängliga.
• Många instanser att underhålla om lösningsleverantören äger underhållet av varje instans.

Öka skalan för SaaS

När du utökar skalan för en lösning till stora distributioner finns det specifika utmaningar som uppstår baserat på tjänstgränser, geografiska problem och andra faktorer. Mer information om storskaliga IoT-distributionsarkitekturer finns i Skala ut en Azure IoT-lösning för att stödja miljontals enheter.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• Michael C. Bazarewsky | Senior kundtekniker, FastTrack för Azure
• David Crook | Huvudkundtekniker, FastTrack för Azure

Övriga medarbetare:

• John Downs | Huvudprogramtekniker
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Nästa steg

• Läs vägledningen för flera klientorganisationer och Azure Cosmos DB.
• Lär dig mer om heta, varma och kalla datavägar med IoT i Azure.