Konfigurationsmönster för Edge-arbetsbelastning

  • Artikel

Det stora utbudet av system och enheter på verkstadsgolvet kan göra arbetsbelastningskonfigurationen till ett svårt problem. Den här artikeln innehåller metoder för att lösa det.

Kontext och problem

Tillverkningsföretag, som en del av sin digitala omvandlingsresa, fokuserar allt mer på att skapa programvarulösningar som kan återanvändas som delade funktioner. På grund av de olika enheterna och systemen på verkstadsgolvet konfigureras de modulära arbetsbelastningarna för att stödja olika protokoll, drivrutiner och dataformat. Ibland körs även flera instanser av en arbetsbelastning med olika konfigurationer på samma gränsplats. För vissa arbetsbelastningar uppdateras konfigurationerna mer än en gång om dagen. Därför blir konfigurationshantering allt viktigare för att skala ut från gränsen lösningar.

Lösning

Det finns några vanliga egenskaper för konfigurationshantering för gränsarbetsbelastningar:

  • Det finns flera konfigurationsplatser som kan grupperas i distinkta lager, till exempel programvarukälla, CI/CD-pipeline, molnklient och gränsplats: Diagram över de lager som kännetecknar arbetsbelastningskonfigurationer: programvarukälla, C I/C D-pipelines, molnklient och gränsplats.
  • De olika lagren kan uppdateras av olika personer.
  • Oavsett hur konfigurationerna uppdateras måste de noggrant spåras och granskas.
  • För affärskontinuitet krävs det att konfigurationer kan nås offline vid gränsen.
  • Det krävs också att det finns en global vy över konfigurationer som är tillgängliga i molnet.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera mönstret:

  • Om du tillåter redigeringar när gränsen inte är ansluten till molnet ökar konfigurationshanteringens komplexitet avsevärt. Det går att replikera ändringar till molnet, men det finns utmaningar med:
    • Användarautentisering eftersom den förlitar sig på en molntjänst som Microsoft Entra-ID.
    • Konfliktlösning efter återanslutning, om arbetsbelastningar får oväntade konfigurationer som kräver manuella åtgärder.
  • Gränsmiljön kan ha nätverksrelaterade begränsningar om topologin uppfyller kraven för ISA-95. Du kan övervinna sådana begränsningar genom att välja en teknik som erbjuder anslutning mellan lager, till exempel enhetshierarkier i Azure IoT Edge.
  • Om körningskonfigurationen är frikopplad från programvaruversioner måste konfigurationsändringar hanteras separat. För att kunna erbjuda funktioner för historik och återställning måste du lagra tidigare konfigurationer i ett datalager i molnet.
  • Ett fel i en konfiguration, till exempel en anslutningskomponent som konfigurerats till en obefintlig slutpunkt, kan bryta arbetsbelastningen. Därför är det viktigt att behandla konfigurationsändringar när du behandlar andra händelser i distributionens livscykel i observerbarhetslösningen, så att instrumentpanelerna för observerbarhet kan hjälpa till att korrelera systemfel med konfigurationsändringar. Mer information om observerbarhet finns i Guiden för molnövervakning: Observerbarhet.
  • Förstå de roller som moln- och gränsdatalager spelar i affärskontinuitet. Om molndatalagringen är den enda sanningskällan bör gränsarbetsbelastningarna kunna återställa avsedda tillstånd med hjälp av automatiserade processer.
  • För återhämtning bör edge-datalagret fungera som en offlinecache. Detta har företräde framför svarstidsöverväganden.

När du ska använda det här mönstret

Använd det här mönstret i sådana här scenarier:

  • Det finns ett krav på att konfigurera arbetsbelastningar utanför programvaruversionscykeln.
  • Olika personer måste kunna läsa och uppdatera konfigurationer.
  • Konfigurationer måste vara tillgängliga även om det inte finns någon anslutning till molnet.

Exempel på arbetsbelastningar:

  • Lösningar som ansluter till tillgångar på butiksgolvet för datainmatning – till exempel OPC Publisher – och kommando och kontroll
  • Maskininlärningsarbetsbelastningar för förutsägande underhåll
  • Maskininlärningsarbetsbelastningar som inspekterar i realtid för kvalitet på tillverkningslinjen

Exempel

Lösningen för att konfigurera gränsarbetsbelastningar under körning kan baseras på en extern konfigurationsstyrenhet eller en intern konfigurationsprovider.

Variant av extern konfigurationsstyrenhet

Diagram över arkitekturen för varianten av den externa konfigurationskontrollanten.

Den här varianten har en konfigurationskontrollant som är extern för arbetsbelastningen. Rollen för komponenten för molnkonfigurationskontrollanten är att skicka redigeringar från molndatalagringen till arbetsbelastningen via gränskonfigurationskontrollanten. Gränsen innehåller också ett datalager så att systemet fungerar även när det är frånkopplat från molnet.

Med IoT Edge kan gränskonfigurationskontrollanten implementeras som en modul och konfigurationerna kan användas med modultvillingar. Modultvillingen har en storleksgräns. Om konfigurationen överskrider gränsen kan lösningen utökas med Azure Blob Storage eller genom segmentering av större nyttolaster via direkta metoder.

Fördelarna med den här varianten är:

  • Själva arbetsbelastningen behöver inte vara medveten om konfigurationssystemet. Den här funktionen är ett krav om källkoden för arbetsbelastningen inte kan redigeras, till exempel när du använder en modul från Azure IoT Edge Marketplace.
  • Det går att ändra konfigurationen av flera arbetsbelastningar samtidigt genom att samordna ändringarna via molnkonfigurationskontrollanten.
  • Ytterligare verifiering kan implementeras som en del av push-pipelinen, till exempel för att verifiera förekomsten av slutpunkter vid gränsen innan konfigurationen skickas till arbetsbelastningen.

Variant av intern konfigurationsprovider

Diagram över arkitekturen för den interna konfigurationsprovidervarianten.

I den interna konfigurationsprovidervarianten hämtar arbetsbelastningen konfigurationer från en konfigurationsprovider. Ett implementeringsexempel finns i Implementera en anpassad konfigurationsprovider i .NET. I det exemplet används C#, men andra språk kan användas.

I den här varianten har arbetsbelastningarna unika identifierare så att samma källkod som körs i olika miljöer kan ha olika konfigurationer. Ett sätt att konstruera en identifierare är att sammanfoga den hierarkiska relationen mellan arbetsbelastningen och en gruppering på den översta nivån, till exempel en klientorganisation. För IoT Edge kan det vara en kombination av Azure-resursgrupp, IoT-hubbnamn, IoT Edge-enhetsnamn och modulidentifierare. Dessa värden utgör tillsammans en unik identifierare som fungerar som en nyckel i datalager.

Även om modulversionen kan läggas till i den unika identifieraren är det ett vanligt krav att bevara konfigurationer mellan programuppdateringar. Om versionen är en del av identifieraren ska den gamla versionen av konfigurationen migreras vidare med ytterligare en implementering.

Fördelarna med den här varianten är:

  • Förutom datalager kräver lösningen inte komponenter, vilket minskar komplexiteten.
  • Migreringslogik från inkompatibla gamla versioner kan hanteras i arbetsbelastningsimplementeringen.

Lösningar baserade på IoT Edge

Diagram över arkitekturen för I o T Edge-baserad variant.

Molnkomponenten i IoT Edge-referensimplementeringen består av en IoT-hubb som fungerar som molnkonfigurationskontrollant. Azure IoT Hub-modultvillingfunktionen sprider konfigurationsändringar och information om den konfiguration som används för närvarande med hjälp av önskade och rapporterade egenskaper för modultvillingar. Konfigurationshanteringstjänsten fungerar som källa för konfigurationerna. Det kan också vara ett användargränssnitt för att hantera konfigurationer, ett byggsystem och andra verktyg som används för att skapa arbetsbelastningskonfigurationer.

En Azure Cosmos DB-databas lagrar alla konfigurationer. Den kan interagera med flera IoT-hubbar och ger konfigurationshistorik.

När en gränsenhet anger via rapporterade egenskaper att en konfiguration har tillämpats noterar konfigurationstillståndstjänsten händelsen i databasinstansen.

När en ny konfiguration skapas i konfigurationshanteringstjänsten lagras den i Azure Cosmos DB och de önskade egenskaperna för gränsmodulen ändras i den IoT-hubb där enheten finns. Konfigurationen överförs sedan av IoT Hub till gränsenheten. Edge-modulen förväntas tillämpa konfigurationen och rapporten via modultvillingen konfigurationens tillstånd. Konfigurationstillståndstjänsten lyssnar sedan på tvillingändringshändelser, och när du upptäcker att en modul rapporterar en ändring av konfigurationstillståndet registrerar motsvarande ändring i Azure Cosmos DB-databasen.

Kantkomponenten kan använda antingen den externa konfigurationsstyrenheten eller den interna konfigurationsprovidern. I båda implementeringarna överförs konfigurationen antingen i de önskade egenskaperna för modultvillingen, eller om stora konfigurationer behöver överföras, innehåller de önskade egenskaperna för modultvillingen en URL till Azure Blob Storage eller till en annan tjänst som kan användas för att hämta konfigurationen. Modulen signalerar sedan i modultvillingen rapporterade egenskaper om den nya konfigurationen tillämpades korrekt och vilken konfiguration som för närvarande tillämpas.

Deltagare

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

Huvudförfattare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg