Model konfigurace úloh Edge

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ém hraničním umístění. U některých úloh se konfigurace aktualizují více než jednou denně. Správa konfigurace je proto pro horizontální navýšení kapacity hraničních řešení stále důležitější.

Řešení

Pro hraniční úlohy existuje několik běžných charakteristik 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.
  • V případě provozní kontinuity je potřeba, aby se ke konfiguracím mohlo přistupovat offline na hraničních zařízeních.
  • Vyžaduje se také, aby byl globální pohled na konfigurace, které jsou dostupné v cloudu.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

  • 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 se má tento model použít

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 v obchodě pro příjem dat – OPC Publisher, například – a řízení příkazů a řízení
  • Ú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. Hraniční zařízení také obsahuje úložiště dat, aby systém fungoval i při odpojení od cloudu.

Se službou IoT Edge je možné implementovat kontroler konfigurace edge jako modul a konfigurace se dají použít s dvojčaty 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ě tím, že bude koordinovat změny prostřednictvím cloudového kontroleru konfigurace.
  • Další ověření je možné implementovat jako součást kanálu nabízených oznámení – například k ověření existence koncových bodů na hraničním zařízení před odesláním konfigurace do úlohy.

Varianta interního zprostředkovatele konfigurace

Diagram architektury pro interní variantu zprostředkovatele konfigurace

V interní variantě zprostředkovatele konfigurace úloha načítá konfigurace od zprostředkovatele konfigurace. 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 úlohy k seskupení nejvyšší úrovně, 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í indikuje ohlášené vlastnosti, že byla použita konfigurace, služba stavu konfigurace zaznamená 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 použije konfiguraci a sestavu prostřednictvím dvojčete modulu ve stavu 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