Dela via

Arkitekturmetoder för IoT i en lösning med flera klientorganisationer

  • Artikel

Multitenant IoT-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 innehavare för IoT-baserade lösningar. Det här dokumentet innehåller exempel på arkitekturer med flera klientorganisationer som använder vanliga komponenter enligt IoT-referensarkitekturen.

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. Information om styrning och efterlevnad beskrivs i en särskild artikel om det ämnet.

Styrning i IoT kan också ta ytterligare 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 alternativ inom teknik, distributionsmönster och mönster för flera innehavare 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. I en smart bygglösning rapporterar termostater till exempel sannolikt data med lägre frekvens än hissar, medan fordonskameran som registrerar datameddelanden i en lösning med anslutet fordon sannolikt är större än navigeringstelemetrimeddelanden. Om dina meddelanden begränsas med avseende på frekvens kan du behöva skala ut till fler instanser av en viss tjänst, men om de begränsas med avseende på storlek kan du behöva skala upp till större instanser av en viss tjänst.

  • Klienter: En enskild klients skala kan vara liten, men när den multipliceras med antalet klienter 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 detta 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 Hubs- eller IoT Central-program börjar alla kunder i den delade infrastrukturen få 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 förekomsten för detta är ofta när en meddelandekvotgräns har överskridits. 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 klienter över IoT-kontroll-, hanterings- och kommunikationsplanerna med hjälp av DPS anpassade allokeringsprinciper. När du följer riktlinjerna för storskaliga IoT-lösningar kan du dessutom hantera ytterligare allokeringsdistribution på DPS-lastbalanserarens nivå.

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

IoT-lösningar tenderar att vara mycket 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 väljs från de nedan påverkar vilka nätverksskikt och gränser som finns. När den fysiska designen har valts kan säkerhetsimplementeringen väljas. Verktyg som kan användas i alla metoder är:

  • 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 valts från senare i den här artikeln är det inte möjligt att använda microsoft 365 med namnet användarlicensiering. 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 brandväggsinstallation från tredje part, som du bör överväga för att isolera nätverksskikten samt övervaka nätverkstrafik. Det exakta valet av metod påverkar var arbetsbelastningar kommer att ha nätverksisolering jämfört med ett delat nätverk enligt nedan.

  • Azure IoT Edge eller Azure IoT Operations, som du bör överväga som en del av enhetsanslutningen till Azure-värdbaserade tjänster utan att direkt exponera enheter för direkt Internetåtkomst. Eftersom Azure IoT Operations är i förhandsversion just nu beskriver det här dokumentet inte användningen av erbjudandet i allmänhet. En framtida revision av det här dokumentet kommer att åtgärda detta.

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å

Alla överväganden som du normalt skulle göra i en IoT-arkitektur, för alla primära komponenter (till exempel hantering, inmatning, bearbetning, lagring, säkerhet och så vidare), är alla val du fortfarande måste göra när du strävar efter en lösning för flera klientorganisationer. Den främsta skillnaden är hur du ordnar och använder komponenterna för att stödja flera innehavare. Vanliga beslutspunkter för lagring kan till exempel vara att bestämma om du vill använda SQL Server eller Azure Data Explorer, eller kanske på inmatnings- och hanteringsnivån, du väljer 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. Dessa faktorer bestäms av de viktigaste kraven och övervägandena som beskrivs ovan.

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).

Detta är det vanliga dilemmat "build vs. 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:

En I O T-arkitektur som visar klienter som delar en I O T Central-miljö, Azure Data Explorer, Power B I och Azure Logic Apps.

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 en implementerings 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.
  • I ett multitenantmönster kan både den maximala nodgränsen för IoT Central (som gäller för både föräldrar och löv) och det maximala träddjupet 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 tillämpar 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:

Diagram som visar en I O T-lösning. Varje klientorganisation ansluter till en delad webbapp som tar emot data från I O T Hubs och en funktionsapp. Enheter ansluter till enhetsetableringstjänsten och till I O T Hubs.

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. Det innebär att den här metoden också ger 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.
Mönster Distributionsmål Innehavarmodell Distributionsmönster
Enkel SaaS Tjänstleverantörens prenumeration Helt multitenant Enkel
Vågrät SaaS Tjänstleverantörens prenumeration Horisontellt partitionerad Distributionsstämpel
Automatiserad enskild klientorganisation Antingen tjänsteleverantörens eller kundens prenumeration Enskild klientorganisation per kund Enkel

Enkel SaaS

Diagram som visar en I O T-arkitektur. Klienter delar en I O T Central-miljö, Azure Data Explorer, Power BI och Azure Logic Apps.

Distributionsmål Innehavarmodell Distributionsmönster
Tjänstleverantörens prenumeration Helt multitenant Enkel

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 ytterligare erbjudanden kan omfatta följande tjänster:

Om du jämför metoden Simple SaaS med den automatiserade aPaaS-modellen för enskild klientorganisation är många egenskaper liknande. Den främsta skillnaden mellan de två modellerna är att i den automatiserade modellen för enskild klientorganisation distribuerar du en distinkt IoT Central-instans för varje klientorganisation, medan du i Simple SaaS med aPaaS-modellen i stället distribuerar en delad instans för flera kunder och skapar en IoT Central-organisation för varje klientorganisation.

När du delar en datanivå med flera klientorganisationer i den här modellen måste du implementera säkerhet på radnivå, enligt beskrivningen i Arkitekturmetoder för lagring och data i lösningar med flera klientorganisationer, för att kunna isolera kunddata.

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 enkelt skalas till ett mycket stort antal enheter, meddelanden eller klienter.

  • Eftersom alla tjänster och komponenter delas kan ett fel i alla komponenter påverka alla dina klienter. Det här ä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, åtgärder, klientlivscykel och säkerhet för underflottor 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

Distributionsmål Innehavarmodell Distributionsmönster
Tjänstleverantörens prenumeration Horisontellt partitionerad Distributionsstämpel

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 arkitekturexemplet nedan partitioneras IoT Central per slutkund, som fungerar som portalen för enhetshantering, enhetskommunikation och administration. Detta 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 enheter själva, utan inblandning av 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.

Diagram över en I O T-lösning. Varje klientorganisation har en egen I O T Central-organisation, som skickar telemetri till en delad funktionsapp och gör den tillgänglig för klientorganisationens företagsanvändare via en webbapp.

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:

  • I allmänhet är det enkelt att hantera och använda, även om ytterligare hantering kan krävas för komponenter med en klientorganisation.
  • 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:

  • Överväg lösningens skala, särskilt för delade 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.

Nedan visas 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. Om du följer den här metoden måste du ha ytterligare en tjänst för att omdirigera enheter till lämplig enhetsetableringstjänst för just klientorganisationens hanterings-, kontroll- och telemetriplan. Mer information finns i white paper, Scaling out an Azure IoT solution to support millions of devices (Skala ut en Azure IoT-lösning för att stödja miljontals enheter).

Detta görs 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 för källklientorganisationen, så att dataströmprocessorn vet vilka klientregler som ska tillämpas på dataströmmen. Om ett telemetrimeddelande till exempel genererar ett meddelande i dataströmprocessorn måste dataströmprocessorn fastställa rätt meddelandesö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.

Diagram som visar en I O T-arkitektur för tre klienter. Varje klientorganisation har en egen identisk, isolerad miljö med en I O T Central-organisation och andra komponenter som är dedikerade till dem.

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

Distributionsmål Innehavarmodell Distributionsmönster
Antingen tjänsteleverantörens eller kundens prenumeration Enskild klientorganisation per kund Enkel

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. Detta beror på att 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 tillåta snabb distribution av extra instanser av lösningen för en kund 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:

  • Relativt lätt att hantera och använda.
  • Klientisolering garanteras i princip.

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 kunder inte är tillgängliga.
  • Om lösningsleverantören äger underhållet av varje instans kan du ha många instanser att underhålla.

Öka skalan för SaaS

När du utökar skalan för en lösning till mycket 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:

Övriga medarbetare:

Nästa steg