Az Azure Resource Manager-alapú és a klasszikus üzemelő példányok: Az üzemi modellek és az erőforrások állapotának ismertetése

Megjegyzés

A cikkben ismertetett információ arra vonatkozik, ha a klasszikusból az Azure Resource Manager-alapú üzemi modellbe migrál.

Ebben a cikkben az Azure Resource Manager-alapú és a klasszikus üzemi modellel ismerkedhet meg. A Resource Manager-alapú és a klasszikus üzemi modell két eltérő módost kínál az Azure-megoldások üzembe helyezésére és felügyeletére. Két eltérő API-készleten keresztül használhatja őket, és az üzembe helyezett erőforrásokban is lehetnek lényeges különbségek. A két modell nem kompatibilis egymással. Ez a cikk röviden ismerteti ezeket az eltéréseket.

Az erőforrások egyszerűbb üzembe helyezése és felügyelete érdekében a Microsoft a Resource Manager használatát javasolja az összes új erőforráshoz. Amennyiben lehetséges, a Microsoft javasolja, hogy a meglévő erőforrásokat is helyezze újra üzembe a Resource Manager használatával. Ha már használta a Cloud Services, a megoldást átemelheti a Cloud Services (kiterjesztett támogatás) használhatja.

Ha még csak most Resource Manager, először tekintse át a témakör áttekintésében Azure Resource Manager terminológiát.

Az üzemi modellek története

Az Azure-ban eredetileg csak a klasszikus üzemi modell volt elérhető. Ebben a modellben az erőforrások egymástól függetlenül léteztek, a kapcsolódó erőforrásokat nem lehetett csoportosítani. Manuálisan kellett nyomon követni, hogy az egyes megoldások és alkalmazások melyik erőforrásokból épültek fel, és gondot kellett fordítani azok összehangolt kezelésére. A megoldások üzembe helyezéséhez vagy létre kellett hozni egyenként az egyes erőforrásokat a portálon, vagy írni kellett egy olyan szkriptet, amely a megfelelő sorrendben helyezte üzembe az erőforrásokat. A megoldások törléséhez külön-külön kellett törölni az egyes erőforrásokat. Nem lehetett egyszerűen alkalmazni és frissíteni a hozzáférés-vezérlési szabályzatokat a kapcsolódó erőforrásokhoz. Végül pedig nem tudott címkéket alkalmazni az erőforrásokra, hogy felcímkézze őket olyan kifejezésekkel, amelyek segítenek az erőforrások monitorzásában és a számlázásban.

Az Azure 2014-ben mutatta be a Resource Managert, amely bevezette az erőforráscsoportok fogalmát. Az erőforráscsoport közös életciklussal rendelkező erőforrások tárolója. A Resource Manager-alapú üzemi modell számos előnyt kínál:

  • A megoldás összes szolgáltatását egy csoportként helyezheti üzembe, felügyelheti és figyelheti meg, és nem különálló erőforrásokként kell kezelnie azokat.
  • A megoldás a teljes életciklusa során ismételten üzembe helyezhető, és az erőforrások üzembe helyezése biztosan konzisztens lesz.
  • Hozzáférés-vezérlést alkalmazhat az összes erőforrásra az erőforráscsoportban, és a rendszer automatikusan alkalmazza ezeket a szabályzatokat, amikor új erőforrásokat ad a csoporthoz.
  • Címkékkel láthatja el az erőforrásokat, így logikusan rendszerezhető az előfizetés összes erőforrása.
  • A megoldás infrastruktúráját JavaScript Object Notation (JSON) formátumban definiálhatja. Ez a JSON-fájl az úgynevezett Resource Manager-sablon.
  • Meghatározhatja az erőforrások közötti függőségeket, hogy azok a megfelelő sorrendben legyenek telepítve.

A Resource Manager bevezetésekor az összes erőforrás visszamenőleg hozzá lett rendelve alapértelmezett erőforráscsoportokhoz. Ha most klasszikus üzembe helyezéssel hoz létre erőforrást, az erőforrás automatikusan létrejön a szolgáltatás alapértelmezett erőforráscsoportja alatt, annak ellenére, hogy az üzembe helyezéskor nem adott meg erőforráscsoportot. Az erőforráscsoporton belüli meglévő erőforrás azonban nem jelenti azt, hogy az erőforrás át lett alakítva a Resource Manager modellre.

A modellek támogatásának bemutatása

Három forgatókönyvről érdemes szót ejteni:

  1. Cloud Services (klasszikus) modell nem támogatja a Resource Manager üzembe helyezési modellt. Cloud Services (kiterjesztett támogatás) támogatja a Resource Manager-telepítési modellt.
  2. A virtuális gépek, a tárfiókok és a virtuális hálózatok a Resource Manager-alapú és a klasszikus üzemi modellt egyaránt támogatják.
  3. Az összes többi Azure-szolgáltatás a Resource Manager használatát támogatja.

A virtuális gépek, a tárfiókok és a virtuális hálózatok esetében, ha az erőforrás a klasszikus modellben lett üzembe helyezve, továbbra is klasszikus műveletekkel kell üzemeltetni. Ha a virtuális gép, a tárfiók vagy a virtuális hálózat Resource Manager-alapú modellben lett üzembe helyezve, továbbra is Resource Manager-műveleteket kell alkalmaznia. Ez elég kusza helyzeteket eredményezhet, ha az előfizetés Resource Manager-alapú és klasszikus üzemi modellben létrehozott erőforrásokat vegyesen tartalmaz. Az erőforrások ilyen kombinációja váratlan eredményeket hozhat, mivel az erőforrások nem támogatják ugyanazt a műveletet.

Bizonyos esetekben egyes Resource Manager-alapú parancsokkal lekérhetők a klasszikus üzemi modellben létrehozott erőforrásokra vonatkozó adatok, vagy végrehajthatók adminisztratív feladatok, például egy klasszikus erőforrás áthelyezése egy másik erőforráscsoportba. Ezek az esetek azonban nem azt a megjelenést keltik, hogy a típus támogatja Resource Manager műveleteket. Tegyük fel például, hogy egy erőforráscsoportban egy olyan virtuális géppel rendelkezünk, amely a klasszikus üzemi modellben lett létrehozva. Ha futtatjuk az alábbi Resource Manager PowerShell-parancsot:

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

A következő virtuális gépet adja vissza:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : westus
SubscriptionId    : {guid}

A Get-AzVM Resource Manager parancsmag azonban csak a virtuális gépeken keresztül üzembe helyezett virtuális gépeket Resource Manager. A következő parancs nem a klasszikus üzembe helyezéssel létrehozott virtuális gépet adja vissza.

Get-AzVM -ResourceGroupName ExampleGroup

Csak a Resource Manager-alapú modellben létrehozott erőforrások támogatják a címkéket. Klasszikus erőforrásokra nem alkalmazhat címkéket.

A számítási, hálózati és tárolási erőforrások változásai

Az alábbi diagramon Resource Manager-alapú modellben üzembe helyezett számítási, hálózati és tárolási erőforrások láthatók.

Resource Manager-architektúra

SRP: Storage, CRP: Compute Resource Provider, NRP: Network Resource Provider

Vegye figyelembe az erőforrások közötti következő összefüggéseket:

  • Mindegyik erőforrás egy erőforráscsoportban található.
  • A virtuális gép egy, a Storage erőforrás-szolgáltatóban definiált adott tárfióktól függ, hogy a lemezeit blobtárolóban tárolhassa (kötelező).
  • A virtuális gép egy, a hálózati erőforrás-szolgáltatóban meghatározott konkrét hálózati adapterre (kötelező) hivatkozik, valamint egy rendelkezésre állási csoportra, amely a Számítási erőforrás-szolgáltatóban van meghatározva (nem kötelező).
  • A hálózati adapter a virtuális gép hozzárendelt IP-címére (kötelező), a virtuális gép virtuális hálózatának alhálózatára (kötelező) és egy hálózati biztonsági csoportra hivatkozik (nem kötelező).
  • A virtuális hálózaton belüli alhálózat egy hálózati biztonsági csoportra hivatkozik (nem kötelező).
  • A terheléselosztási példány az IP-címek háttérkészletére hivatkozik, amelyek tartalmazzák egy virtuális gép hálózati adapterét (nem kötelező), és egy terheléselosztási nyilvános vagy privát IP-címre hivatkozik (nem kötelező).

Íme az összetevők és a kapcsolataik a klasszikus üzemi modellben:

klasszikus architektúra

A klasszikus megoldás a virtuális gépek futtatására a következő:

  • Cloud Services (klasszikus) tárolóként működik a virtuális gépek (számítás) számára. A virtuális gépek automatikusan egy hálózati adaptert és egy, az Azure által hozzárendelt IP-címet kapnak. Ezenkívül a felhőalapú szolgáltatás tartalmaz egy külső terheléselosztó példányt, egy nyilvános IP-címet és alapértelmezett végpontokat a távoli asztali és távoli PowerShell-forgalom lehetővé tételére a Windows-alapú virtuális gépek, valamint Secure Shell- (SSH-) forgalom lehetővé tételére a Linux-alapú virtuális gépek esetében.
  • Egy szükséges tárfiók, amely egy virtuális gép virtuális merevlemezét tárolja, beleértve az operációs rendszert, az ideiglenes és a további adatlemezeket (tárolókat).
  • Egy opcionális virtuális hálózat, amely további tárolóként működik, amelyben létrehozhat egy alhálózati struktúrát, és kiválaszthatja azt az alhálózatot, amelyen a virtuális gép található (hálózat).

A következő táblázat a Compute, a Network és a Storage erőforrás-szolgáltatók együttműködésének változásait ismerteti:

Elem Klasszikus Resource Manager
Felhőszolgáltatás a virtuális gépekhez A Cloud Service egy tároló volt a virtuális gépekhez, amely platform és a terheléselosztás Rendelkezésre állását is igényelte. Az új modell használatával a Cloud Service már nem szükséges objektum egy virtuális gép létrehozásához.
Virtuális hálózatok A virtuális géphez nem szükséges virtuális hálózat. Ha tartalmazza, a virtuális hálózat nem helyezhető üzembe Resource Manager. A virtuális géphez egy, a Resource Managerrel üzembe helyezett virtuális hálózat szükséges.
Storage-fiókok A virtuális géphez szükség van egy tárfiókra, amely az operációs rendszer, az ideiglenes és a további adatlemezek virtuális merevlemezét tárolja. A virtuális gép számára szükséges egy tárfiók, hogy a lemezeit blobtárolóban tárolhassa.
Rendelkezésre állási csoportok A platform rendelkezésre állását ugyanaz a "AvailabilitySetName" konfigurálásával jelezték a Virtual Machines. A tartalék tartományok maximális száma 2 volt. A Rendelkezésre állási csoport egy Microsoft.Compute szolgáltató által közzétett erőforrás. A nagy rendelkezésre állást igénylő virtuális gépeket szerepeltetni kell a Rendelkezésre állási csoportban. A tartalék tartományok maximális száma mostantól 3.
Affinitáscsoportok Virtuális hálózatok létrehozásához szükség volt Affinitáscsoportokra. A regionális virtuális hálózatok bevezetésével azonban erre már nem volt szükség. Az egyszerűbbség érdekében az affinitáscsoportok fogalma nem létezik az api-kon keresztül elérhetővé Azure Resource Manager.
Terheléselosztás Egy felhőszolgáltatás létrehozása egy implicit terheléselosztót biztosít a telepített virtuális gépekhez. A Load Balancer egy Microsoft.Network szolgáltató által közzétett erőforrás. A terheléselosztást igénylő virtuális gépek elsődleges hálózati adapterének hivatkoznia kell a terheléselosztóra. Egy terheléselosztó lehet külső vagy belső. Egy terheléselosztó példány az IP-címek háttérkészletére hivatkozik, amelyek között egy virtuális gép hálózati adaptere is található (nem kötelező), továbbá hivatkozik egy terheléselosztó nyilvános vagy privát IP-címére is (nem kötelező).
Virtuális IP-cím A Cloud Services egy alapértelmezett VIP-t (virtuális IP-cím) kap, amikor egy virtuális gépet hozzáadnak egy felhőszolgáltatáshoz. A Virtuális IP-cím az implicit terheléselosztóhoz társított cím. A nyilvános IP-cím egy Microsoft.Network szolgáltató által közzétett erőforrás. Egy nyilvános IP-cím lehet statikus (fenntartott) vagy dinamikus. A dinamikus nyilvános IP-címek hozzárendelhetők egy terheléselosztóhoz. A nyilvános IP-címek védelme biztonsági csoportok segítségével biztosítható.
Fenntartott IP-címek Az Azure-ban fenntarthat egy IP-címet, és társíthatja egy felhőszolgáltatáshoz, hogy biztosítsa az IP-cím állandóságát. A nyilvános IP-címek létrehozhatók statikus módban, amely ugyanazokat a képességeket biztosítja, mint a fenntartott IP-címek.
Virtuális gépenként megadott nyilvános IP-cím (PIP) A nyilvános IP-címek közvetlenül is hozzárendelhetők egy virtuális géphez. A nyilvános IP-cím egy Microsoft.Network szolgáltató által közzétett erőforrás. Egy nyilvános IP-cím lehet statikus (fenntartott) vagy dinamikus.
Végpontok A virtuális gépen konfigurálni kell a bemeneti végpontokat, hogy bizonyos portok csatlakoztathatóvá váljanak. A virtuális gépekhez való csatlakozás egyik legelterjedtebb módja a bemeneti végpontok beállítása. A bejövő NAT-szabályok konfigurálhatók a terheléselosztókon, így azonos képességek érhetők el a végpontok engedélyezésére adott portokon a virtuális gépekhez való csatlakozás céljából.
DNS-név Egy felhőszolgáltatás egy implicit globálisan egyedi DNS-nevet kap. Példa: mycoffeeshop.cloudapp.net. A DNS-nevek opcionális paraméterek, amelyek egy nyilvános IP-cím erőforráson adhatók meg. Az FQDN formátuma a következő lesz: <domainlabel>.<region>.cloudapp.azure.com.
Hálózati illesztők Az elsődleges és másodlagos hálózati adapter és tulajdonságai egy virtuális gép hálózati konfigurációjaként voltak megadva. A hálózati adapter egy Microsoft.Network szolgáltató által közzétett erőforrás. A hálózati adapter életciklusa nincs virtuális géphez kötve. A virtuális gép hozzárendelt IP-címére (kötelező), a virtuális gép virtuális hálózatának alhálózatára (kötelező), valamint egy hálózati biztonsági csoportra (nem kötelező) hivatkozik.

A különböző üzemi modellekből származó virtuális hálózatok összekapcsolásával kapcsolatban lásd a különböző üzemi modellekből származó virtuális hálózatok a portálon történő összekapcsolását ismertető szakaszt.

Migrálás klasszikusról Resource Manager-alapú környezetbe

Ha készen áll az erőforrások klasszikus üzembe helyezésből Resource Manager való áttelepítésére, tekintse meg a következőt:

  1. Részletes műszaki útmutató a klasszikusból az Azure Resource Manager-alapú üzemi modellbe történő, platform által támogatott migrálásról
  2. Az IaaS-erőforrások klasszikusból Azure Resource Manager-alapú környezetbe való, platform által támogatott migrálása
  3. IaaS-erőforrások migrálása a klasszikusból Resource Manager-alapú környezetbe az Azure PowerShell használatával
  4. IaaS-erőforrások migrálása a klasszikusból Resource Manager-alapú környezetbe az Azure CLI használatával

Gyakori kérdések

Létrehozhatok virtuális gépet a Resource Managerrel úgy, hogy azután egy klasszikus üzembe helyezéssel létrehozott virtuális hálózatban legyen elérhető?

Ez a konfiguráció nem támogatott. Nem használhatja a Resource Manager virtuális gép klasszikus üzembe helyezéssel létrehozott virtuális hálózatban való üzembe helyezésére.

Létrehozhatok virtuális gépeket a Resource Managerrel a klasszikus üzemi modellben létrehozott felhasználói rendszerképből?

Ez a konfiguráció nem támogatott. A virtuális merevlemez fájljait azonban átmásolhatja a klasszikus üzembe helyezési modellel létrehozott tárfiókból, és hozzáadhatja őket egy új fiókhoz, amely a Resource Manager.

Milyen változások vonatkoznak az előfizetésemhez tartozó kvótára?

Az Azure Resource Managerrel létrehozott virtuális gépek, virtuális hálózatok és a tárfiókok kvótái nem azonosak a többi kvótával. Minden előfizetés saját kvótákat kap az erőforrások az új API-kkal való létrehozására. A további kvótákról itt talál részletes információkat.

Használhatom továbbra is az automatizált szkriptjeimet virtuális gépek, virtuális hálózatok és tárfiókok a Resource Manager API-kban történő kiépítésére?

Az összes már létrehozott automatizálás és szkript továbbra is működik az Azure szolgáltatásfelügyeleti módban létrehozott, már meglévő virtuális gépeivel és virtuális hálózataival. Ha viszont az új sémával szeretné használni a szkripteket ugyanazon erőforrásoknak a Resource Manager módban való létrehozásához, frissítenie kell őket.

Hol találhatok példákat az Azure Resource Manager-sablonokra?

A kezdősablonok átfogó készlete a gyorsindítási sablonok Azure Resource Manager található.

Következő lépések