Configuratiepatroon voor Edge-werkbelasting

  • Artikel

De grote verscheidenheid aan systemen en apparaten op de winkelvloer kan de workloadconfiguratie een moeilijk probleem maken. Dit artikel bevat benaderingen voor het oplossen ervan.

Context en probleem

Productiebedrijven richten zich als onderdeel van hun digitale transformatietraject steeds meer op het bouwen van softwareoplossingen die als gedeelde mogelijkheden kunnen worden hergebruikt. Vanwege de verschillende apparaten en systemen op de winkelvloer zijn de modulaire workloads geconfigureerd ter ondersteuning van verschillende protocollen, stuurprogramma's en gegevensindelingen. Soms worden zelfs meerdere exemplaren van een workload uitgevoerd met verschillende configuraties op dezelfde randlocatie. Voor sommige workloads worden de configuraties meer dan één keer per dag bijgewerkt. Daarom is configuratiebeheer steeds belangrijker voor het uitschalen van edge-oplossingen.

Oplossing

Er zijn enkele algemene kenmerken van configuratiebeheer voor edge-workloads:

  • Er zijn verschillende configuratiepunten die kunnen worden gegroepeerd in verschillende lagen, zoals softwarebron, CI/CD-pijplijn, cloudtenant en edge-locatie: Diagram van de lagen die workloadconfiguraties karakteriseren: softwarebron, C I/C D-pijplijnen, cloudtenant en edge-locatie.
  • De verschillende lagen kunnen door verschillende personen worden bijgewerkt.
  • Ongeacht hoe de configuraties worden bijgewerkt, moeten ze zorgvuldig worden bijgehouden en gecontroleerd.
  • Voor bedrijfscontinuïteit is vereist dat configuraties offline aan de rand kunnen worden geopend.
  • Het is ook vereist dat er een globale weergave is van configuraties die beschikbaar zijn in de cloud.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

  • Als u bewerkingen toestaat wanneer de rand niet is verbonden met de cloud, neemt de complexiteit van het configuratiebeheer aanzienlijk toe. Het is mogelijk om wijzigingen in de cloud te repliceren, maar er zijn problemen met:
    • Gebruikersverificatie, omdat deze afhankelijk is van een cloudservice zoals Microsoft Entra-id.
    • Conflictoplossing na opnieuw verbinding maken, als workloads onverwachte configuraties ontvangen waarvoor handmatige interventie is vereist.
  • De edge-omgeving kan netwerkgerelateerde beperkingen hebben als de topologie voldoet aan de ISA-95-vereisten. U kunt dergelijke beperkingen overwinnen door een technologie te selecteren die connectiviteit biedt tussen lagen, zoals apparaathiërarchieën in Azure IoT Edge.
  • Als de runtimeconfiguratie losgekoppeld is van softwarereleases, moeten configuratiewijzigingen afzonderlijk worden verwerkt. Als u geschiedenis- en terugdraaifuncties wilt aanbieden, moet u eerdere configuraties opslaan in een gegevensarchief in de cloud.
  • Een fout in een configuratie, zoals een connectiviteitsonderdeel dat is geconfigureerd voor een niet-bestaand eindpunt, kan de werkbelasting verbreken. Daarom is het belangrijk om configuratiewijzigingen te behandelen wanneer u andere levenscyclus-gebeurtenissen van de implementatie behandelt in de waarneembaarheidsoplossing, zodat de waarneembaarheidsdashboards kunnen helpen bij het correleren van systeemfouten aan configuratiewijzigingen. Zie de handleiding voor cloudbewaking: Waarneembaarheid voor meer informatie over waarneembaarheid.
  • Inzicht in de rollen die de cloud- en edge-gegevensarchieven spelen in bedrijfscontinuïteit. Als het gegevensarchief in de cloud de enige waarheidsbron is, moeten de edge-workloads de beoogde statussen kunnen herstellen met behulp van geautomatiseerde processen.
  • Voor tolerantie moet het edge-gegevensarchief fungeren als een offlinecache. Dit heeft voorrang op latentieoverwegingen.

Wanneer dit patroon gebruiken

Gebruik dit patroon wanneer:

  • Er is een vereiste om workloads buiten de softwarereleasecyclus te configureren.
  • Verschillende personen moeten configuraties kunnen lezen en bijwerken.
  • Configuraties moeten beschikbaar zijn, zelfs als er geen verbinding met de cloud is.

Voorbeeldworkloads:

  • Oplossingen die verbinding maken met assets op de winkelvloer voor gegevensopname, bijvoorbeeld OPC Publisher, en opdrachten en beheer
  • Machine learning-workloads voor voorspellend onderhoud
  • Machine learning-workloads die in realtime controleren op kwaliteit op de productielijn

Voorbeelden

De oplossing voor het configureren van edge-workloads tijdens runtime kan zijn gebaseerd op een externe configuratiecontroller of een interne configuratieprovider.

Variatie van externe configuratiecontroller

Diagram van de architectuur voor de variatie van de externe configuratiecontroller.

Deze variatie heeft een configuratiecontroller die buiten de workload valt. De rol van het onderdeel van de cloudconfiguratiecontroller is het pushen van wijzigingen vanuit het cloudgegevensarchief naar de workload via de edge-configuratiecontroller. De rand bevat ook een gegevensarchief, zodat het systeem zelfs functioneert wanneer de verbinding met de cloud is verbroken.

Met IoT Edge kan de edge-configuratiecontroller worden geïmplementeerd als een module en kunnen de configuraties worden toegepast met moduledubbels. De moduledubbel heeft een groottelimiet; als de configuratie de limiet overschrijdt, kan de oplossing worden uitgebreid met Azure Blob Storage of door grotere nettoladingen te segmenteren via directe methoden.

De voordelen van deze variatie zijn:

  • De workload zelf hoeft zich niet bewust te zijn van het configuratiesysteem. Deze mogelijkheid is vereist als de broncode van de werkbelasting niet kan worden bewerkt, bijvoorbeeld wanneer u een module uit Azure IoT Edge Marketplace gebruikt.
  • Het is mogelijk om de configuratie van meerdere workloads tegelijkertijd te wijzigen door de wijzigingen via de cloudconfiguratiecontroller te coördineren.
  • Aanvullende validatie kan worden geïmplementeerd als onderdeel van de push-pijplijn, bijvoorbeeld om het bestaan van eindpunten aan de rand te valideren voordat de configuratie naar de workload wordt gepusht.

Variatie van interne configuratieprovider

Diagram van de architectuur voor de variatie van de interne configuratieprovider.

In de variatie van de interne configuratieprovider haalt de workload configuraties op van een configuratieprovider. Zie Een aangepaste configuratieprovider implementeren in .NET voor een implementatievoorbeeld. In dat voorbeeld wordt C# gebruikt, maar andere talen kunnen worden gebruikt.

In deze variatie hebben de workloads unieke id's, zodat dezelfde broncode die in verschillende omgevingen wordt uitgevoerd, verschillende configuraties kan hebben. Een manier om een id te maken, is door de hiërarchische relatie van de werkbelasting samen te stellen met een groepering op het hoogste niveau, zoals een tenant. Voor IoT Edge kan het een combinatie zijn van Azure-resourcegroep, IoT Hub-naam, IoT Edge-apparaatnaam en module-id. Deze waarden vormen samen een unieke id die als sleutel in de gegevensarchieven werkt.

Hoewel de moduleversie kan worden toegevoegd aan de unieke id, is het een veelvoorkomende vereiste om configuraties tussen software-updates te behouden. Als de versie deel uitmaakt van de id, moet de oude versie van de configuratie worden gemigreerd naar een extra implementatie.

De voordelen van deze variatie zijn:

  • Anders dan de gegevensarchieven vereist de oplossing geen onderdelen, waardoor de complexiteit wordt verminderd.
  • Migratielogica van incompatibele oude versies kan worden verwerkt binnen de implementatie van de workload.

Oplossingen op basis van IoT Edge

Diagram van de architectuur voor de op I o T Edge gebaseerde variatie.

Het cloudonderdeel van de IoT Edge-referentie-implementatie bestaat uit een IoT-hub die fungeert als de cloudconfiguratiecontroller. Met de azure IoT Hub-moduledubbelfunctionaliteit worden configuratiewijzigingen en informatie over de momenteel toegepaste configuratie doorgegeven met behulp van gewenste en gerapporteerde eigenschappen van de moduledubbel. De configuratiebeheerservice fungeert als de bron van de configuraties. Het kan ook een gebruikersinterface zijn voor het beheren van configuraties, een buildsysteem en andere hulpprogramma's die worden gebruikt voor het ontwerpen van workloadconfiguraties.

In een Azure Cosmos DB-database worden alle configuraties opgeslagen. Het kan communiceren met meerdere IoT-hubs en biedt configuratiegeschiedenis.

Nadat een edge-apparaat via gerapporteerde eigenschappen aangeeft dat een configuratie is toegepast, noteert de configuratiestatusservice de gebeurtenis in het database-exemplaar.

Wanneer een nieuwe configuratie wordt gemaakt in de configuratiebeheerservice, wordt deze opgeslagen in Azure Cosmos DB en worden de gewenste eigenschappen van de edge-module gewijzigd in de IoT-hub waar het apparaat zich bevindt. De configuratie wordt vervolgens door IoT Hub verzonden naar het edge-apparaat. De edge-module wordt verwacht de configuratie en het rapport toe te passen via de moduledubbel de status van de configuratie. De configuratiestatusservice luistert vervolgens naar wijzigingen van dubbels en bij het detecteren dat een module een configuratiestatuswijziging rapporteert, wordt de bijbehorende wijziging vastgelegd in de Azure Cosmos DB-database.

Het edge-onderdeel kan de externe configuratiecontroller of interne configuratieprovider gebruiken. In beide implementaties wordt de configuratie verzonden in de gewenste eigenschappen van de moduledubbel of als grote configuraties moeten worden verzonden, bevatten de gewenste eigenschappen van de moduledubbel een URL naar Azure Blob Storage of naar een andere service die kan worden gebruikt om de configuratie op te halen. De module geeft vervolgens aan dat in de moduledubbel gerapporteerde eigenschappen zijn gerapporteerd of de nieuwe configuratie is toegepast en welke configuratie momenteel wordt toegepast.

Medewerkers

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

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen