Az alábbi példa számítási feladat egy automatikusan futó szimuláció összeállítását ismerteti, amely egy Azure DevOps-folyamaton keresztül értékeli a szimulált járműfüggvényeket. Ez a folyamat minden alkalommal fut, amikor egy mérnök ellenőrzi a példafüggvény forráskódjának vagy szimulációs környezetének új verzióját.
Architektúra
Töltse le az architektúra Visio-fájlját.
Felhasználói beviteli réteg
A fejlesztő csak ezt a réteget fogja használni. Tartalmazza a fejlesztői munkaállomást (a hatókörünkben egy Azure-beli virtuális gépet) és a szimulációs környezetet leíró specifikációs fájlt.
Vezénylési réteg
A "vezénylésnek" széles körű jelentése van: a szó által leírt problémák némelyike triviálisan megoldódott; mások sokkal összetettebbek. A tárolók és virtuális gépek létrehozásának, monitorozásának és megsemmisítésének "vezénylési" problémáját például számos eszköz oldja meg – ehhez maga az Azure API elegendő "vezénylő".
Munkafolyamat
Fontos azonban, hogy a "vezénylés" fekete dobozát kisebb összetevőkre bontsuk.
Szimulációs API: Ez az API egy specifikációs fájlt kap, amely a szimulációs környezetek és a szimulációs futtatások vezénylési réteggel való vezérlésének belépési pontja.
Értelmező: Ez az összetevő a specifikációs fájlt a Szimulációkezelő logikai struktúrájába értelmezi.
Szimulációkezelő: Ez az az állapotgép, amely a logikai szimulációs környezet objektumát kívánt állapotokká és más összetevők által használandó műveletekké alakítja. Ez az összetevő aktiválja a szimuláció összeállítását, végrehajtását és lebontását. A belső függőségeket és hibamódokat is kezeli.
Ütemező: Ez az összetevő építőelemeket rendel az infrastruktúra-erőforrásokhoz, és ott indítja el őket. Hardver- és hozzáférési követelményeket, rendelkezésre álló erőforrásokat és erőforráskorlátokat is biztosít.
Environment Manager: Ez az összetevő figyeli a mögöttes infrastruktúrát, és válaszol a problémákra, például amikor egy tárológazda leáll.
Network Manager: Ez az összetevő kezeli a szimulációs környezetek hálózatait és útválasztását. Minden környezetnek izolált hálózati környezetben kell élnie, ahol az elkülönített építőelemek bejövő kapcsolatokat kapnak az interaktivitás érdekében. Ez az összetevő egy szimuláció építőelemeinek megoldására is használható (például belső DNS-n keresztül).
Access Manager: Ez az összetevő a Microsoft Entra-azonosítóból a rendszer többi részébe történő engedélyezést/hitelesítést tükrözi.
Configuration Manager: Ez az összetevő állandó tárolási mechanizmusként működik az infrastruktúra és a szimulációs környezetek állapotához.
Infrastruktúra absztrakciója: Ez egy absztrakciós réteg, amely az általános parancsokat a tárolók és virtuális gépek meghatározott Azure API-parancsaira fordítja le.
Storage Manager: Ez az összetevő kezeli a tároló kiépítését és csatolását szimulációs környezetekhez (például virtuálisgép-gyökéreszközökhöz vagy tárolóhoz csatlakoztatott kötetekhez).
Erőforrás-figyelő: Ez az összetevő egy idősoros adatbázisba figyeli az infrastruktúraszintű erőforrás-használatot az ADP alapvető monitorozásába való exportáláshoz.
Log Manager: Ez az összetevő összesíti az építőelemek naplóit a felhasználói ellenőrzéshez. Emellett naplókat exportál az ADP-magnaplózásba.
A példa számítási feladat elsődleges fókusza az Vezénylési réteg.
Szimulációs infrastruktúra rétege
Ez a réteg az összes futó szimulációs környezetet jelöli.
Szimulációs környezet: A definíciófájl és a paraméterek által definiált építőelemek kombinációja itt jön létre, hálózati elkülönítésben bármely más szimulációs környezettől.
Építőelem-szerződés: Az az írott szabvány, amely meghatározza, hogy az összes építőelem hogyan küldjön kimenetet, hibákat és állapotot az Vezénylési rétegnek.
Építőelem-folyamat: Ez a terület kezeli az építőelemek létrehozását és tárolását.
Építőelem-adattár: Ez az építőelem-rendszerképek tárolási és lekérési rendszere, például egy tárolóregisztrációs adatbázis és/vagy egy Azure-rendszerképtár.
Building Block Factory: A folyamatos integrációs és folyamatos üzembe helyezési (CI/CD) folyamat, amely nem módosítható, ellenőrizhető összetevőcsomagok (például dpkg vagy apt) használatával hoz létre építőelem-lemezképeket egy deklaratív konfigurációs nyelven (például Chef vagy Ansible).
Tárolási réteg
Ez a réteg tartósan és elérhető módon tárolja a szimuláció eredményeit. Elsősorban a mobilalkalmazás-fejlesztési platform (MADP) Data Lake workstream feladata, bár a kimenetet ennek a csapatnak kell kezelnie.
Tárolási felület: Az a felület, amely lehetővé teszi a felhasználók számára a szimulációs eredmények tárolását. Ez a fenti Storage Manager vezénylési összetevővel szoros hangversenyben működik, vagy az is lehetséges.
Tárolás: A szimulációs eredmények mentéséhez használt tárolási mechanizmus (például Azure Blob Storage vagy Azure Disk Storage-erőforrások).
Összetevők
Az Azure Virtual Machines igény szerinti, méretezhető számítási erőforrásokat biztosít, amelyek rugalmasságot biztosítanak a virtualizáláshoz anélkül, hogy meg kellene vásárolniuk és karbantartaniuk a fizikai hardvert.
Az Azure Virtual Network az Azure-beli magánhálózat alapvető építőeleme. Az Azure Virtual Network számos típusú Azure-erőforrást, például azure-beli virtuális gépeket tesz lehetővé az egymással, az internettel és a helyszíni hálózatokkal való biztonságos kommunikációhoz.
Az Azure Container Instances a leggyorsabb és legegyszerűbb módot kínálja a tárolók Azure-ban való futtatására anélkül, hogy virtuális gépeket kellene kezelnie, és nem kell magasabb szintű szolgáltatást bevezetnie.
Az Azure Container Registry egy felügyelt, privát Docker-beállításjegyzék-szolgáltatás, amely a nyílt forráskódú Docker Registry 2.0-n alapul. Az Azure tárolóregisztrációs adatbázisait használhatja a meglévő tárolófejlesztési és üzembehelyezési folyamatokkal, vagy az Azure Container Registry Tasks használatával tárolólemezképeket hozhat létre az Azure-ban. Igény szerint építhet, vagy teljes mértékben automatizálhatja a buildeket eseményindítókkal, például forráskód véglegesítésével és alaprendszerkép-frissítésekkel.
Az Azure Pipelines az Azure DevOps Services része, és automatizált buildeket, teszteket és üzembe helyezéseket futtat. Külső CI-/CD-megoldásokat is használhat, például a Jenkinst.
A Microsoft Entra ID egy felhőalapú identitás- és hozzáférés-kezelési szolgáltatás, amely hitelesíti a felhasználókat, a szolgáltatásokat és az alkalmazásokat.
Az Azure Storage tartós, magas rendelkezésre állású és nagymértékben méretezhető felhőalapú tárolási megoldást kínál. Ide tartoznak az objektum-, fájl-, lemez-, üzenetsor- és táblatárolási képességek.
Az Azure Monitor számos helyszíni és Azure-forrásból gyűjt monitorozási telemetriát. Ez a szolgáltatás a költségekre és teljesítményre optimalizált naplóadattárban összesíti és tárolja a telemetriát.
Alternatívák
Ez az architektúra virtuális gépeket és tárolókat használ a különböző eszközök és szolgáltatások üzembe helyezéséhez. Alternatív megoldásként az Azure Kubernetes Servicest (AKS) is használhatja. Az AKS kiszolgáló nélküli Kubernetest, integrált CI/CD-funkciókat, valamint vállalati szintű biztonságot és cégirányítást tartalmaz.
A szimulációs eredmények mentéséhez használt tárolási mechanizmus ebben az architektúrában az Azure Blob Storage-on vagy az Azure Disk Storage-on alapul. A nagyobb számítási feladatok alternatívájaként az Azure nagy léptékű adat- és elemzési megoldásait is megtekintheti az adatok tárolására és elemzésére.
Fontolja meg az Azure Monitor használatát az infrastruktúra teljesítményének elemzéséhez és optimalizálásához, valamint a hálózati problémák monitorozásához és diagnosztizálásához anélkül, hogy bejelentkezett a virtuális gépekre.
Forgatókönyv részletei
Az autonóm vezetés (AD) felméréséhez a függvénymérnököknek az AD-képességekkel rendelkező járművek viselkedését kell szimulálniuk. Fontolja meg a következő példa vezetési forgatókönyvet:
Egy tesztjármű önvezető úton, 80 mph sebességgel halad a jobb oldali sávban egy 3 sávos autópályán. Van egy teherautó 600 láb előre vezet ugyanabban a sávban és ugyanabban az irányban 55 mph. A közelben nincs jármű a középső sávban. Az útjelzők láthatóak, a nap merőleges a járműre, és az út száraz.
Egy ilyen forgatókönyvet használó jármű viselkedésének véges szimulációját szimulációs futtatásnak nevezzük. A fenti forgatókönyvben a szimulált jármű elvárt viselkedése az, hogy kényelmesen áthaladjon a teherautón anélkül, hogy balesetet okoz, és nem szegi meg a forgalmi szabályokat. A függvények minden új verziójához futtatott szimulációval az AD-függvénymérnökök tesztelik, hogy az új verzió továbbra is a várt viselkedést mutatja-e.
Szimuláció futtatásához az AD-függvénymérnökök gyakran használnak szoftveralkalmazásokat. Ezek közé tartozhat a virtuális tesztmeghajtó (VTD), az időpartíciós tesztelés (TPT),az Avionics Development System 2G (ADS2) és az Automotive Data and Time-Trigger Framework (ADTF) is, amelyek mindegyike az adott autonóm vezetési funkció, például az autópálya-pilóták tesztelésére vonatkozó konfigurációjuknak megfelelően kommunikál egymással. A szoftvereszközök és konfigurációik helyszíni és/vagy felhőbeli fizikai és/vagy virtuális gépeken való üzembe helyezését szimulációs környezetnek nevezzük.
Az összes futtatott szimuláció által generált teszteredmények érvényességének biztosításához győződjön meg arról, hogy a szimuláció a kezdeti állapotára beállított friss szimulációs környezetben indul el.
Minden önvezető csapatnak külön alkalmazáskészletre van szüksége a szimulációs környezetben, egyedi konfigurációval. Sok csapatnak több különböző szimulációs környezetre is szüksége lesz. Egy LIDAR-érzékelő kiértékeléséhez például nagyon nagy felbontású objektumszimulációra lesz szükség, de más illesztőprogramokra, útjelzőkre vagy egyéb funkciókra nincs szükség. Bár az egyes környezetek egyediek, jelentős átfedés van a használt alkalmazásokban. Sok csapat például több szimulációs környezetben is használ VTD-t.
Egy szimuláció futtatható újrahasználható, beágyazható és egymástól független kiértékelt egységekből álló szimulációs környezetben. Ezek az egységek "építőelemként" szolgálnak a szimulációs környezetek automatikus és igény szerinti létrehozásához az Azure-felhőben. Ezeket a szimulációs környezeteket automatizált vezetési platformoknak (ADP) is nevezik.
Lehetséges használati esetek
Ez a megoldás ideális az autóipar és a közlekedés területén. A számítási feladat tipikus felhasználási módjai a következők:
Autós tesztek automatizálása.
Az autóipari vezérlőrendszerek prototípus-, fejlesztési, integrációs, tesztelési, ellenőrzési és ellenőrzési rendszere.
Járműadatok rögzítése vizualizációhoz.
Összetett vezetési forgatókönyvek szimulálása az autóiparban.
Megfontolások
Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.
Rendelkezésre állás és rugalmasság
Fontolja meg a virtuális gépek rendelkezésre állási csoportok vagy rendelkezésre állási zónák közötti üzembe helyezését, amely segít megvédeni az alkalmazásokat a tervezett karbantartási események és a nem tervezett leállások ellen.
A rendelkezésre állási csoport a virtuális gépek logikus csoportosítását jelenti, ami lehetővé teszi az Azure számára az alkalmazás felépítésének megértését a redundancia és a rendelkezésre állás biztosításához.
A rendelkezésre állási zónák egyedi fizikai helyek az Azure-régiókban, amelyek segítenek megvédeni a virtuális gépeket, alkalmazásokat és adatokat az adatközpontok meghibásodásaitól. Minden zóna egy vagy több adatközpontból áll. A zónákban lévő virtuális gépek és alkalmazások akkor is elérhetők maradhatnak, ha egyetlen adatközpontban fizikai hiba történik.
Méretezhetőség
Az Azure-beli virtuális gépeket manuálisan vagy automatikus méretezési funkciókkal skálázhatja.
Tárolótelepítések esetén az Azure Containers-példányok és az Azure Kubernetes Services is úgy van kialakítva, hogy manuálisan vagy automatikusan fel- vagy felskálázhatók legyenek.
Biztonság
A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: A biztonsági pillér áttekintése.
Mint minden más típusú alkalmazás esetén, a szimulációs környezet is alkalmas a bizalmas adatok kezelésére. Ezért korlátoznia kell, hogy ki jelentkezhet be és használhatja azokat, és azt is korlátoznia kell, hogy mely adatok érhetők el a felhasználó identitása vagy szerepköre alapján. Identitás- és hozzáférés-vezérléshez használja a Microsoft Entra-azonosítót, és az Azure Key Vault használatával kezelheti a kulcsokat és titkos kulcsokat.
A biztonságos megoldások tervezésével kapcsolatos általános útmutatásért tekintse meg az Azure biztonsági dokumentációját.
DevOps
Friss szimulációs környezetek üzembe helyezéséhez a legjobb, ha CI/CD-folyamatokat használ olyan megoldásokkal, mint az Azure DevOps vagy a GitHub Actions.
Költségoptimalizálás
A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.
A legtöbb esetben az Azure-díjkalkulátorral megbecsülheti költségeit. A költségeket úgy is optimalizálhatja, hogy követi a folyamatot, hogy a virtuális gépek kapacitását a kezdetektől fogva megfelelően méretezhesse, és szükség szerint egyszerűsített átméretezést is végezhet. Egyéb szempontokat a Microsoft Azure Well-Architected Framework Költség szakaszában ismertetünk.
Következő lépések
Termékdokumentáció:
A Microsoft képzési tervei:
Tárterület implementálása és kezelése Azure-rendszergazdák számára
Számítási erőforrások üzembe helyezése és kezelése Azure-rendszergazdák számára
Virtuális hálózatok konfigurálása és kezelése Azure-rendszergazdák számára
Identitások és irányítás kezelése azure-rendszergazdák számára
Erőforrások monitorozása és biztonsági mentése Azure-rendszergazdák számára
Kapcsolódó erőforrások
Az Azure Architecture Center áttekintési cikkei:
Releváns architektúrák: