Sdílet prostřednictvím

Model konfigurace úloh Edge

  • Článek

Velký počet systémů a zařízení v obchodě může komplikovat konfiguraci úloh. Tento článek obsahuje přístupy k jeho řešení.

Kontext a problém

Výrobní společnosti se v rámci své cesty digitální transformace zaměřují stále častěji na vytváření softwarových řešení, která je možné znovu použít jako sdílené funkce. Vzhledem k různým zařízením a systémům v provozním podlaží jsou modulární úlohy nakonfigurované tak, aby podporovaly různé protokoly, ovladače a datové formáty. Někdy se dokonce i několik instancí úlohy spouští s různými konfiguracemi ve stejné okrajové lokalitě. U některých úloh se konfigurace aktualizují více než jednou denně. Správa konfigurace je proto pro škálování edge řešení stále důležitější.

Řešení

Pro edgeové úlohy jsou zde běžné charakteristiky správy konfigurace:

  • Existuje několik bodů konfigurace, které je možné seskupit do různých vrstev, jako je zdroj softwaru, kanál CI/CD, cloudový tenant a hraniční umístění: Diagram vrstev, které charakterizují konfigurace úloh: zdroj softwaru, kanály C I / C D, cloudového tenanta a hraniční umístění.
  • Různé vrstvy můžou aktualizovat různí lidé.
  • Bez ohledu na to, jak se konfigurace aktualizují, je potřeba je pečlivě sledovat a auditovat.
  • Pro kontinuitu podnikání je potřeba, aby se ke konfiguracím mohlo přistupovat offline na okraji.
  • Vyžaduje se také, aby byl globální pohled na konfigurace, které jsou dostupné v cloudu.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

  • Povolení úprav, když hraniční zařízení není připojené ke cloudu, výrazně zvyšuje složitost správy konfigurace. Změny v cloudu je možné replikovat, ale existují problémy s:
    • Ověřování uživatelů, protože závisí na cloudové službě, jako je ID Microsoft Entra.
    • Řešení konfliktů po opětovném připojení, pokud úlohy obdrží neočekávané konfigurace, které vyžadují ruční zásah.
  • Hraniční prostředí může mít omezení související se sítí, pokud topologie splňuje požadavky ISA-95. Takové omezení můžete překonat výběrem technologie, která nabízí připojení napříč vrstvami, jako jsou hierarchie zařízení v Azure IoT Edge.
  • Pokud je konfigurace za běhu oddělená od vydaných verzí softwaru, je potřeba změny konfigurace zpracovat samostatně. Pokud chcete nabízet funkce historie a vrácení zpět, musíte ukládat předchozí konfigurace v úložišti dat v cloudu.
  • Chyba v konfiguraci, jako je komponenta připojení nakonfigurovaná pro neexistující koncový bod, může přerušit úlohu. Proto je důležité zacházet se změnami konfigurace při zpracování jiných událostí životního cyklu nasazení v řešení pozorovatelnosti, aby řídicí panely pozorovatelnosti mohly pomoci korelovat chyby systému se změnami konfigurace. Další informace o pozorovatelnosti najdete v průvodci monitorováním cloudu: Pozorovatelnost.
  • Seznamte se s rolemi, které cloudové a hraniční úložiště dat hrají v provozní kontinuitě. Pokud je cloudové úložiště dat jediným zdrojem pravdy, měly by být hraniční úlohy schopné obnovit zamýšlené stavy pomocí automatizovaných procesů.
  • Kvůli odolnosti by úložiště dat edge mělo fungovat jako offline mezipaměť. To má přednost před aspekty latence.

Kdy použít tento vzor

Tento model použijte v těchto případech:

  • Je potřeba nakonfigurovat úlohy mimo cyklu vydávání softwaru.
  • Různé osoby musí mít možnost číst a aktualizovat konfigurace.
  • Konfigurace musí být dostupné, i když není připojení ke cloudu.

Ukázkové úlohy:

  • Řešení, která se připojují k prostředkům na výrobní ploše pro příjem dat, například OPC Publisher, a ovládání a dohled.
  • Úlohy strojového učení pro prediktivní údržbu
  • Úlohy strojového učení, které kontrolují kvalitu výrobní linky v reálném čase

Příklady

Řešení pro konfiguraci hraničních úloh během běhu může být založeno na externím řadiči konfigurace nebo interním poskytovateli konfigurace.

Varianta externího kontroleru konfigurace

Diagram architektury pro variantu externího kontroleru konfigurace

Tato varianta má kontroler konfigurace, který je pro úlohu externí. Role komponenty kontroleru konfigurace cloudu spočívá v nabízení úprav z cloudového úložiště dat do úlohy prostřednictvím hraničního kontroleru konfigurace. Okrajová infrastruktura také obsahuje úložiště dat, aby systém fungoval i při odpojení od cloudu.

S IoT Edge je možné implementovat okrajový kontroler konfigurace jako modul a konfigurace se dají použít s dvojicemi modulů. Dvojče modulu má limit velikosti; pokud konfigurace překročí limit, může být řešení rozšířeno o Azure Blob Storage nebo prostřednictvím bloků větších datových částí přes přímé metody.

Výhody této varianty jsou:

  • Samotná úloha nemusí znát konfigurační systém. Tato funkce je požadavkem, pokud zdrojový kód úlohy není možné upravovat – například při použití modulu z Azure IoT Edge Marketplace.
  • Konfiguraci více úloh je možné změnit současně koordinováním změn prostřednictvím konfiguračního kontroleru v cloudu.
  • Další ověření lze implementovat jako součást pipeline – například k ověření existence koncových bodů v edge síti před odesláním konfigurace do úlohy.

Varianta interního zprostředkovatele konfigurace

Diagram architektury pro interní variantu zprostředkovatele konfigurace

Ve vnitřní variantě zprostředkovatele konfigurace úloha načítá konfigurace od tohoto zprostředkovatele. Příklad implementace naleznete v tématu Implementace vlastního zprostředkovatele konfigurace v .NET. Tento příklad používá jazyk C#, ale lze použít i jiné jazyky.

V této variantě mají úlohy jedinečné identifikátory, aby stejný zdrojový kód spuštěný v různých prostředích mohl mít různé konfigurace. Jedním ze způsobů, jak vytvořit identifikátor, je zřetězení hierarchického vztahu pracovní zátěže k seskupení na nejvyšší úrovni, jako je tenant. Pro IoT Edge může být kombinací skupiny prostředků Azure, názvu centra IoT, názvu zařízení IoT Edge a identifikátoru modulu. Tyto hodnoty společně tvoří jedinečný identifikátor, který v úložištích dat funguje jako klíč.

I když je možné do jedinečného identifikátoru přidat verzi modulu, je běžným požadavkem na zachování konfigurací napříč aktualizacemi softwaru. Pokud je verze součástí identifikátoru, měla by se stará verze konfigurace migrovat s další implementací.

Výhody této varianty jsou:

  • Kromě úložišť dat řešení nevyžaduje komponenty, což snižuje složitost.
  • Logiku migrace z nekompatibilních starých verzí je možné zpracovat v rámci implementace úlohy.

Řešení založená na IoT Edge

Diagram architektury pro variantu založenou na I o T Edge

Cloudová komponenta referenční implementace IoT Edge se skládá z centra IoT, který funguje jako kontroler konfigurace cloudu. Funkce dvojčete modulu Azure IoT Hub šíří změny konfigurace a informace o aktuálně použité konfiguraci pomocí požadovaných a ohlášených vlastností dvojčete modulu. Služba správy konfigurace funguje jako zdroj konfigurací. Může to být také uživatelské rozhraní pro správu konfigurací, systému sestavení a dalších nástrojů používaných k vytváření konfigurací úloh.

Databáze Azure Cosmos DB ukládá všechny konfigurace. Může pracovat s několika ioT Huby a poskytuje historii konfigurace.

Jakmile hraniční zařízení prostřednictvím ohlášených vlastností naznačuje, že byla použita konfigurace, konfigurační stavová služba poznamená událost v instanci databáze.

Když se ve službě pro správu konfigurace vytvoří nová konfigurace, uloží se ve službě Azure Cosmos DB a v centru IoT, ve kterém se nachází zařízení, se změní požadované vlastnosti hraničního modulu. Konfigurace se pak přenáší službou IoT Hub do hraničního zařízení. Očekává se, že modul Edge aplikuje konfiguraci a prostřednictvím dvojčete modulu hlásí stav konfigurace. Služba stavu konfigurace pak naslouchá událostem změny dvojčete a po zjištění, že modul hlásí změnu stavu konfigurace, zaznamenává odpovídající změnu v databázi Azure Cosmos DB.

Hraniční komponenta může používat externí kontroler konfigurace nebo interního zprostředkovatele konfigurace. V obou implementacích se konfigurace přenáší buď v požadovaných vlastnostech dvojčete modulu, nebo v případě, že je potřeba přenést velké konfigurace, požadované vlastnosti dvojčete modulu obsahují adresu URL služby Azure Blob Storage nebo do jiné služby, která se dá použít k načtení konfigurace. Modul pak signalizuje v ohlášených vlastnostech dvojčete modulu, jestli se nová konfigurace úspěšně použila a jaká konfigurace se aktuálně používá.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky