Megbízhatóság az Azure VM Image Builderben

Azure VM Image Builder egy felügyelt szolgáltatás, amely virtuálisgép-rendszerképeket hoz létre és szab testre, majd az így kapott lemezképeket elosztja olyan célokra, mint az Azure Compute Gallery vagy az Azure Blob Storage-ban található virtuális merevlemezek (VHD-k). A szolgáltatás nem igényli a hosszú élettartamú buildinfrastruktúra fenntartását.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan tehető ellenállóbbá az Azure VM Image Builder a különböző lehetséges kimaradásokkal és problémákkal szemben, például átmeneti hibák, rendelkezésre állási zónák hibái, régiószintű hibák és szolgáltatáskarbantartás esetén. Emellett ismerteti a biztonsági mentési és visszaállítási lehetőségeket, az egyéni többrégiós megoldásokat, valamint az Azure VM Image Builder szolgáltatási szintű szerződésével (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Az éles rendszerkép-készítési folyamat tervezésekor vegye figyelembe az alábbi javaslatokat:

  • Definiálja a képsablonokat az infrastruktúra kódként való használatával, például Bicep vagy Terraform használatával, és tárolja a definíciókat a forrásvezérlőben.

  • Ossza el a kész rendszerképeket azokra a régiókra, ahol a számítási feladatok futnak, például Azure Compute Gallery-replikáció révén, hogy elkerülje a felesleges régiók közötti függőségeket a virtuális gépek létrehozása, a horizontális skálázás és az újraimázási műveletek során.

  • Tárolja a testreszabási szkripteket, csomagokat és egyéb buildfüggőségeket olyan tárban, amely a munkaterhelés által igényelt redundancia-jellemzőkkel rendelkezik.

A megbízhatósági architektúra áttekintése

Ez a szakasz a szolgáltatás megbízhatóság szempontjából leginkább releváns működésének néhány fontos aspektusát ismerteti. A szakasz bemutatja a logikai architektúrát, amely tartalmazza a telepített és használt erőforrásokat és funkciókat. Emellett a fizikai architektúrát is ismerteti, amely részletesen bemutatja, hogyan működik a szolgáltatás a borítók alatt.

Logikai architektúra

A VM Image Builder használatakor egy rendszerképsablont helyez üzembe egyetlen Azure régióban, amely a sablon kezdőrégiójává válik.

A sablon létrehozása után buildet futtat, amely több lépést hajt végre a virtuálisgép-rendszerkép létrehozásához. Ezek a lépések szkripteket hajthatnak végre, vagy tartalmazhatnak olyan csomagokat, amelyeket be szeretne ágyazni a rendszerképbe.

A szolgáltatás átmeneti erőforráscsoportot hoz létre vagy használ, és buildinfrastruktúrát helyez üzembe az előfizetésében. A buildelés után a szolgáltatás eltávolítja az ideiglenes erőforrásokat, beleértve a buildelési virtuális gépet és a kapcsolódó hálózati erőforrásokat. Az átmeneti üzembe helyezési erőforráscsoport és a tárolási erőforrások mindaddig megmaradnak, amíg a rendszerkép-sablon erőforrás létezik.

A VM Image Builder a kész lemezképet egy vagy több megadott célra osztja el. A gyakori célok a következők:

  • Azure Compute Gallery (korábbi nevén Shared Image Gallery): A Compute Gallery többrégiós replikációt biztosít a virtuálisgép-rendszerképek számára. Létrehozhat például egy rendszerképet egy régióban, és eloszthatja az eredményként kapott Azure Compute Gallery-rendszerképverziót több célrégióba.

  • Azure Blob Storage: A szolgáltatás a VHD-t abban a tárfiókban tárolhatja, amelybe a VM Image Builder üzembe helyez, vagy egy ön által megadott tárfiókban és blobtárolóban.

    Ha a szolgáltatás által felügyelt tárfiókot VHD-terjesztési célként használja, a szolgáltatás a VHD-t az átmeneti erőforráscsoportban tárolja. A képsablon törlésekor a szolgáltatás a VHD-t is törli. Ha a VHD-t a képsablontól függetlenül szeretné megőrizni, másolja egy egyéni tárfiókba, vagy másolja egy másik helyre a sablon törlése előtt.

Az Azure Compute Gallery és a Blob Storage a VM Image Buildertől különálló szolgáltatások. A rendszerképeket több célhoz is eloszthatja, beleértve a különböző Azure régiókban lévő célokat is. Ez a terjesztési modell segít elkülöníteni azt a régiót, ahol rendszerképet készít, azoktól a régióktól, ahol felhasználja ezt a rendszerképet.

Note

A VM Image Builder a felügyelt rendszerképeket is támogatja, amelyek örökölt disztribúciós célpontnak számítanak. Ez a cikk nem tartalmazza a felügyelt rendszerképeket. Éles környezetben használja az Azure Compute Galleryt.

Fizikai architektúra

A VM Image Builder a rendszerképek alapvető testreszabási és érvényesítési folyamatának futtatásához az Isolated Image Builds szolgáltatást használja. A szolgáltatás egy dedikált Azure Container Instances erőforrást és egy buildelési virtuális gépet helyez üzembe az előfizetés előkészítési erőforráscsoportjában. A Container Instances erőforrás a HashiCorp Packert futtatja a rendszerkép testreszabásához és ellenőrzéséhez, a VM Image Builder pedig koordinálja a buildet.

Rendszerkép-buildek futtatásához regisztrálja a Microsoft.ContainerInstance erőforrás-szolgáltatót, és győződjön meg arról, hogy az előfizetése rendelkezik elegendő Container Instances kvótával. A szolgáltatásarchitektúráról, a támogatott régiókról és a buildelési folyamatról további információt Azure VM Image Builder áttekintésében talál.

Külön Azure-szolgáltatások, például az Azure Compute Gallery és a Blob Storage, tárolják a kész lemezképeket. Konfigurálja az egyes terjesztési célokat a reziliencia-követelményeknek való megfelelés érdekében.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Javaslatok átmeneti hibák kezelésére.

Az Azure VM Image Builderrel általában az Azure portál, az Azure CLI, az Azure PowerShell vagy az infrastruktúra mint kód, például a Bicep használatával lép kapcsolatba. A buildelési folyamat felelős az átmeneti hibák kezeléséért. Ha az Azure Resource Manager átmeneti hibaválaszt ad vissza, próbálkozzon újra a kéréssel a megfelelő késleltetéssel.

Ha egy build sikertelen, ellenőrizze annak lastRunStatus naplóit, testreszabási és érvényesítési naplóit, valamint a terjesztési futtatások kimeneteit, mielőtt újrafuttatná. Ezek a részletek segítenek megállapítani, hogy átmeneti hibaállapot, testreszabási lépés vagy képterjesztési művelet okozta-e a hibát. További információ: VM Image Builder buildelési hibáinak elhárítása.

Az összeállítási műveletek külső rendszerektől is függhetnek, például tárfiókoktól, csomagtárolóktól, forráslemezképek helyeitől és terjesztési céloktól. A testreszabási lépéseket és folyamatokat úgy tervezheti meg, hogy támogassa az ideiglenes hálózati, platform- vagy függőségi problémák utáni újrapróbálkozásokat.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A buildműveletek és a befejezett lemezképek eltérően viselkednek a zónahibák során.

  • Builds: A VM Image Builder nem támogatja a rendelkezésre állási zónákat, és nem nyújt zónareziliencia-garanciát a képsablonokhoz vagy a buildműveletekhez. Ha egy zónahiba hatással van a build által használt erőforrásokra, előfordulhat, hogy a build nem indul el vagy megszakad. A VM Image Builder nem helyezi át automatikusan a buildet egy másik zónába.

    Ha a zónakimaradások során kép buildeket kell futtatnia, helyezze üzembe a rendszerképsablonokat és az erőforrásokat több Azure régióban. További információ: Egyéni többrégiós megoldások a rugalmassághoz.

  • Képek: A kész képek akkor is elérhetők maradnak, ha tárolójuk zónareziliens.

    • Azure Compute Gallery: Azure Compute Gallery rendszerképverziói zónaredundáns tárolást (ZRS) használhatnak a rendelkezésre állási zónákat támogató célrégiókban. Minden célrégió esetében válassza a ZRS-t a tárfiók replikációs típusaként. Az alapértelmezett érték a helyileg redundáns tárolás (LRS), amely nem ellenálló a zónahibákkal szemben. További információért lásd: Azure Compute Gallery magas rendelkezésre állása.

    • Virtuális merevlemezek a Azure Blob Storage: Ha nem használ egyéni tárfiókot, a VM Image Builder alapértelmezés szerint létrehoz egy ZRS-tárfiókot a rendelkezésre állási zónákat támogató régiókban. Ha egyéni tárfiókot használ, Ön felelős a redundancia konfigurálásáért úgy, hogy az megfeleljen a követelményeinek. A ZRS használatával több rendelkezésre állási zónában tárolhatja a VHD másolatait. A ZRS működésével kapcsolatos további információkért lásd: Megbízhatóság az Azure Blob Storage-ban.

Rugalmasság régiószintű hibákhoz

A buildműveletek és a kész képek eltérően viselkednek a teljes régiót érintő kiesések során.

  • Buildverziók: Az Azure VM Image Builder egyrégiós szolgáltatás, és nem biztosít beépített többrégiós feladatátvételt. Ha a rendszerképsablont üzemeltető régió elérhetetlenné válik, a rendszerképsablon és az abban a régióban végzett buildelési műveletek szintén nem érhetők el. A szolgáltatás nem vált át automatikusan egy másik régióba.

    Ha a régiókimaradások során rendszerkép-buildjeit kell futtatnia, helyezze üzembe a rendszerképsablonokat és a támogató erőforrásokat több Azure-régióban. További információ: Egyéni többrégiós megoldások a rugalmassághoz.

  • Képek: A kész képek akkor is elérhetők maradnak, ha tárolójuk ellenáll a régiószintű kieséseknek.

    • Azure Compute Gallery: Konfigurálhatja az Azure Compute Galleryt, hogy a rendszerképverziókat több régióba replikálja. A replikáció aszinkron, és a célrégióban csak a régióba történő replikáció befejezése után használhat képverziót.

      Az egy régióban történő kimaradás során a befejezett replikák továbbra is elérhetők maradnak a virtuális gépek működő célrégiókban történő üzembe helyezéséhez. Ha azonban a katalóguserőforrást tartalmazó régió nem érhető el, nem hozhat létre és nem frissíthet katalóguserőforrásokat. Ha továbbra is közzé kell tennie a rendszerképverziókat egy régiókimaradás során, külön gyűjteményeket kell fenntartania külön buildelési régiókban. További információ: Azure Compute Gallery replikációja és ajánlott eljárásai.

    • VHD-k az Azure Blob Storage-ban: Az alapértelmezett szolgáltatás által felügyelt VHD-célhely nem biztosít georedundanciát. A rendelkezésre állási zónákat támogató régiókban ZRS-t használ, amely nem véd a régiószintű hibák ellen.

      Egy párosított régióval rendelkező régióban a VHD-t terjesztheti egy georedundáns tárolást (GRS) vagy geozónára redundáns tárolást (GZRS) használó egyéni tárfiókba. Az olvasási hozzáférésű GRS (RA-GRS) és az olvasási hozzáférésű GZRS (RA-GZRS) csak olvasási hozzáférést biztosít egy másodlagos végponton keresztül, de nem hajtanak végre feladatátvételt. A párosított régióban a normál írási-olvasási hozzáférés visszaállításához kezdeményezze az ügyfél által felügyelt feladatátadást, vagy másolja a VHD-t a másodlagos végpontról egy külön tárfiókba. A georeplikálás aszinkron, így a nem tervezett átállás elveszítheti a nem replikált adatokat. Ha lehetséges, ellenőrizze a tárfiók Utolsó szinkronizálási idő tulajdonságát a feladatátvétel előtt.

      A Blob Storage feladatátvételi viselkedésről és az adatok nem párosított régiók közötti replikálásának alternatív módjairól a Megbízhatóság az Azure Blob Storage-ban című témakörben talál további információt.

Egyéni többrégiós megoldások a rugalmasság érdekében

Ha egy régió kimaradása során továbbra is rendszerképeket kell készítenie, ön felel a független buildkörnyezetek üzembe helyezéséért és üzemeltetéséért több régióban.

Válassza ki a VM Image Buildert támogató régiókat. Minden buildrégióban előre üzembe kell helyeznie egy képsablont és annak régióspecifikus függőségeit, beleértve a felügyelt identitásokat és szerepkör-hozzárendeléseket, a hálózati konfigurációt, a testreszabási összetevőket, a forrásképet vagy a képreplikát, valamint a terjesztési célokat.

Ha képeket kell közzétennie, amíg a Compute Gallery régiója nem érhető el, minden buildrégióban használjon független Compute Gallery-erőforrást. A képverziók egyetlen galériából való replikálása nem teszi teljes mértékben többrégiós erőforrássá a galériát.

Definiálja ezeket az erőforrásokat infrastruktúra mint kód használatával, és ezeket a definíciókat az igazság forrásaként kezeli. Tartsa szinkronizálva a regionális környezeteket a konfiguráció módosításakor, és rendszeresen tesztelje, hogy az egyes környezetek létrehozhatnak-e és terjeszthetnek-e rendszerképeket.

Biztonsági mentés és visszaállítás

Azure virtuálisgép-rendszerkép-készítő nem helyettesíti a biztonsági mentési és helyreállítási folyamatot. A legtöbb esetben a helyreállítás szempontjából fontos termékfájl az a kész rendszerkép, amelyet az Azure Compute Galleryben vagy a VHD-tárolóban tesz közzé.

Az adatkárósodásból vagy a nem tervezett, elhúzódó kimaradásból való helyreállítás javítása érdekében kövesse az alábbi ajánlásokat:

  • Megtarthatja a közzétett lemezképeket az Azure Compute Galleryben vagy más terjesztési célokban a megőrzési követelményeknek megfelelően.

  • Ha létrehoz egy VHD-t, és az alapértelmezett VHD-célhelyet használja, másolja a VHD-t a saját tartós tárolóba a képsablon törlése előtt.

  • A verziókövetés használatával tárolhatja és verziószámozza a lemezképsablon definícióit.

  • Használjon forrásvezérlőt vagy más típusú tartós tárolót a testreszabási szkriptek és csomagok tárolásához és verziószámozásához.

  • Rendszeresen ellenőrizze, hogy minden előre üzembe helyezett helyreállítási környezet képes-e rendszerképet létrehozni és terjeszteni.

A szolgáltatás karbantartásával szembeni rugalmasság

A Microsoft felügyeli az Azure VM Image Builder karbantartását. A VM Image Builder futásidőben nem szolgálja ki az alkalmazás forgalmát, így a karbantartás nem érinti a közzétett képekből már létrehozott virtuális gépeket. Ha egy build késik vagy megszakad a karbantartás vagy egy másik szolgáltatásesemény során, vizsgálja meg az állapotát és naplóit, és futtassa újra.

Az Azure Service Health használatával figyelheti a tervezett karbantartási és szolgáltatási incidenseket, amelyek hatással lehetnek a buildrégiót.

Szolgáltatásiszint-szerződés

Az Azure VM Image Builder nem biztosít rendelkezésre állási szolgáltatói szerződést (SLA).

Minden olyan SLA, amely egy terjesztési célra vagy tárolási szolgáltatásra vonatkozik, külön vonatkozik, és nem biztosít rendelkezésre állási kötelezettséget a VM Image Builder-sablonhoz vagy a buildelési műveletekhez.

Kapcsolódó tartalom

  • Utolsó frissítés időpontja: