Share via

Az IaaS-erőforrások klasszikusból Azure Resource Manager-alapú környezetbe való áttelepítésének megtervezése

  • Cikk

A következőkre vonatkozik: ✔️ Linux rendszerű ✔️ windowsos virtuális gépek

Fontos

Ma az IaaS virtuális gépek körülbelül 90%-a használja az Azure Resource Manager. 2020. február 28-tól a klasszikus virtuális gépek elavultak, és 2023. szeptember 6-án teljesen megszűnnek. További információ erről az elavulásról és arról, hogy ez milyen hatással van Önre.

Bár az Azure Resource Manager számos csodálatos funkciót kínál, fontos megtervezni a migrálási folyamatot, hogy a dolgok zökkenőmentesen működjenek. A tervezéssel töltött idő biztosítja, hogy ne tapasztalhasson problémákat a migrálási tevékenységek végrehajtása során.

Megjegyzés

Az azure-beli ügyféltanácsadási csapat és a felhőmegoldás-tervezők nagy mértékben hozzájárultak az alábbi útmutatóhoz, amely az ügyfelekkel együtt dolgozott a nagy méretű környezetek migrálásán. Ezért ez a dokumentum a sikeresség új mintáinak megjelenésével folyamatosan frissülni fog, ezért időről időre ellenőrizze, hogy vannak-e új javaslatok.

A migrálási folyamatnak négy általános fázisa van:

A migrálás fázisai

Felkészülés

Technikai szempontok és kompromisszumok

A műszaki követelmények méretétől, földrajzi helyétől és működési gyakorlatától függően érdemes megfontolni a következő szempontokat:

  1. Miért kívánatos az Azure Resource Manager a szervezet számára? Mik a migrálás üzleti okai?
  2. Mik az Azure Resource Manager technikai okai? Milyen (ha vannak) egyéb Azure-szolgáltatásokat szeretne használni?
  3. Melyik alkalmazás (vagy virtuális gépcsoport) szerepel a migrálásban?
  4. Mely forgatókönyvek támogatottak a migrálási API-val? Tekintse át a nem támogatott funkciókat és konfigurációkat.
  5. Az operatív csapatok mostantól a klasszikus és az Azure Resource Manager is támogatják az alkalmazásokat/virtuális gépeket?
  6. Hogyan módosítja (ha egyáltalán) az Azure Resource Manager a virtuális gépek üzembe helyezését, felügyeletét, figyelését és jelentéskészítési folyamatait? Frissíteni kell az üzembehelyezési szkripteket?
  7. Mi a kommunikációs terv az érdekelt felek (végfelhasználók, alkalmazástulajdonosok és infrastruktúra-tulajdonosok) értesítésére?
  8. A környezet összetettségétől függően legyen-e olyan karbantartási időszak, amikor az alkalmazás nem érhető el a végfelhasználók és az alkalmazástulajdonosok számára? Ha igen, mennyi ideig?
  9. Mi az a képzési terv, amely biztosítja, hogy az érdekelt felek jártasak és jártasak legyenek az Azure Resource Manager?
  10. Mi a migrálás programfelügyeleti vagy projektkezelési terve?
  11. Mik az Azure Resource Manager migrálásának és más kapcsolódó technológiai ütemterveknek az ütemtervei? Optimálisan vannak igazítva?

A siker mintái

A sikeres ügyfelek részletes tervekkel rendelkeznek, amelyekben az előző kérdéseket tárgyalják, dokumentálják és szabályozzák. Győződjön meg arról, hogy a migrálási tervek széles körben kommunikálnak a szponzorokkal és az érdekelt felekkel. Felkészítheti magát a migrálási lehetőségek ismeretére; Az alábbi migrálási dokumentumkészlet beolvasása erősen ajánlott.

Elkerülendő buktatók

  • Nem sikerült megtervezni. A migrálás technológiai lépései bizonyítottak, és az eredmény kiszámítható.
  • Feltételezve, hogy a platform által támogatott migrálási API az összes forgatókönyvet figyelembe veszi. Olvassa el a nem támogatott funkciókat és konfigurációkat , és ismerje meg, hogy mely forgatókönyvek támogatottak.
  • Nem tervezzük az alkalmazáskimaradást a végfelhasználók számára. Tervezze meg a megfelelő puffert, hogy megfelelően figyelmeztesse a végfelhasználót a potenciálisan elérhetetlen alkalmazásidőre.

Tesztkörnyezet

A környezet replikálása és a migrálás tesztelése

Megjegyzés

A meglévő környezet pontos replikálása egy közösség által támogatott eszközzel történik, amelyet a Microsoft ügyfélszolgálata hivatalosan nem támogat. Ezért ez egy opcionális lépés, de ez a legjobb módja annak, hogy az éles környezetek érintése nélkül derítsünk ki problémákat. Ha a közösség által közzétett eszköz használata nem lehetséges, olvassa el az alábbi Valid/Prepare/Abort Dry Run javaslatot.

A zökkenőmentes migrálás legjobb módja a pontos forgatókönyv (számítás, hálózatkezelés és tárolás) labortesztjének elvégzése. Ez segít biztosítani a következőt:

  • Egy teljesen különálló tesztkörnyezet vagy egy meglévő, nem éles környezetben történő tesztelés. Egy teljesen különálló tesztkörnyezetet ajánlunk, amely ismételten migrálható, és destruktív módon módosítható. A metaadatok valós előfizetésekből való gyűjtésére/hidratálására szolgáló szkriptek az alábbiakban láthatók.

  • Érdemes külön előfizetésben létrehozni a tesztkörnyezetet. Ennek az az oka, hogy a tesztkörnyezetet többször lebontják, és ha külön, elkülönített előfizetéssel rendelkezik, azzal csökkenti annak az esélyét, hogy valami valós dolog véletlenül törlődik.

    Ez az AsmMetadataParser eszközzel valósítható meg. Erről az eszközről itt olvashat bővebben

A siker mintái

Az alábbiakban számos nagyobb migrálás során észleltek problémákat. Ez nem teljes lista, és további részletekért tekintse meg a nem támogatott funkciókat és konfigurációkat . Előfordulhat, hogy ezek a technikai problémák nem merülnek fel, de ha a migrálási kísérlet előtt megoldja ezeket, az gördülékenyebb élményt nyújt.

  • Érvényesítés/előkészítés/száraz futtatás megszakítása – Ez talán a legfontosabb lépés a klasszikus és az Azure Resource Manager migrálás sikerességének biztosításához. A migrálási API három fő lépésből áll: Ellenőrzés, előkészítés és véglegesítés. Az ellenőrzés beolvassa a klasszikus környezet állapotát, és visszaadja az összes probléma eredményét. Mivel azonban előfordulhatnak problémák az Azure Resource Manager veremben, az Ellenőrzés nem fog mindent elkapni. A migrálási folyamat következő lépése, a Prepare segít felfedni ezeket a problémákat. A Prepare áthelyezi a metaadatokat a klasszikusról az Azure Resource Manager, de nem véglegesíti az áthelyezést, és nem távolít el és nem módosít semmit a klasszikus oldalon. A száraz futtatás magában foglalja a migrálás előkészítését, majd a migrálások előkészítésének megszakítását (nem véglegesítését). A száraz futtatás ellenőrzésének/előkészítésének/megszakításának célja az, hogy az Azure Resource Manager veremben lévő összes metaadatot megtekintse, megvizsgálja (programozottan vagy a Portálon), és ellenőrizze, hogy minden megfelelően migrál-e, és hogy műszaki problémákat tapasztaljon. Emellett a migrálás időtartamát is érzékelteti, így ennek megfelelően megtervezheti az állásidőt. Az ellenőrzés/előkészítés/megszakítás nem okoz felhasználói állásidőt; ezért nem diszkont az alkalmazáshasználatra.

    • Az alábbi elemeket meg kell oldani a száraz futtatás előtt, de a száraz futtatási teszt is biztonságosan kiüríti ezeket az előkészítési lépéseket, ha kihagyják őket. A vállalati migrálás során úgy találtuk, hogy a száraz futtatás biztonságos és felbecsülhetetlen értékű módszer a migrálás készenlétének biztosítására.
    • Amikor az előkészítés fut, a vezérlősík (Azure felügyeleti műveletek) zárolva lesz a teljes virtuális hálózatra vonatkozóan, így a virtuális gép metaadatai nem módosíthatók az ellenőrzés/előkészítés/megszakítás során. Ellenkező esetben azonban az alkalmazásfüggvények (RD, virtuális gépek használata stb.) nem lesznek hatással. A virtuális gépek felhasználói nem fogják tudni, hogy a száraz futtatás végrehajtása folyamatban van.

  • Express Route-kapcsolatcsoportok és VPN. Jelenleg az engedélyezési hivatkozásokkal rendelkező Express Route Gatewayek nem migrálhatók állásidő nélkül. A kerülő megoldásért lásd: ExpressRoute-kapcsolatcsoportok és társított virtuális hálózatok migrálása a klasszikustól a Resource Manager üzembehelyezési modellig.

  • Virtuálisgép-bővítmények – A virtuálisgép-bővítmények a futó virtuális gépek migrálásának egyik legnagyobb akadályát jelenthetik. A virtuálisgép-bővítmények szervizelése akár 1-2 napot is igénybe vehet, ezért ennek megfelelően tervezze meg. Működő Azure-ügynökre van szükség a futó virtuális gépek virtuálisgép-bővítményének állapotának jelentéséhez. Ha az állapot egy futó virtuális gép esetében olyan rossz állapotba kerül, az leállítja a migrálást. Magának az ügynöknek nem kell működőképesnek lennie a migrálás engedélyezéséhez, de ha bővítmények vannak a virtuális gépen, akkor a migráláshoz mind a munkaügynökre, mind a kimenő internetkapcsolatra (DNS-lel) szükség lesz a migráláshoz.

    • Ha a DNS-kiszolgálóval való kapcsolat megszakad az áttelepítés során, a BGInfo v1.* kivételével minden virtuálisgép-bővítményt el kell távolítani minden virtuális gépről a migrálás előkészítése előtt, majd újra hozzá kell adni a virtuális géphez az Azure Resource Manager migrálás után. Ez csak a futó virtuális gépekre vonatkozik. Ha a virtuális gépek felszabadítása leáll, a virtuálisgép-bővítményeket nem kell eltávolítani. Megjegyzés: Számos bővítmény, például az Azure-diagnosztika és a Felhőhöz készült Defender monitorozása újratelepíti magát a migrálás után, így azok eltávolítása nem jelent problémát.

    • Emellett győződjön meg arról, hogy a hálózati biztonsági csoportok nem korlátozzák a kimenő internet-hozzáférést. Ez a hálózati biztonsági csoportok egyes konfigurációinál fordulhat elő. A virtuálisgép-bővítmények Azure Resource Manager való migrálásához kimenő internet-hozzáférésre (és DNS-re) van szükség.

    • A BGInfo bővítménynek két verziója van: v1 és v2. Ha a virtuális gépet a Azure Portal vagy a PowerShell használatával hozták létre, a virtuális gép valószínűleg rendelkezik a v1 kiterjesztéssel. Ezt a bővítményt nem kell eltávolítani, és a migrálási API kihagyja (nem migrálja). Ha azonban a klasszikus virtuális gépet az új Azure Portal hozta létre, valószínűleg a BGInfo JSON-alapú v2-es verziójával fog rendelkezni, amely migrálható az Azure-ba Resource Manager feltéve, hogy az ügynök működik, és kimenő internet-hozzáféréssel (és DNS-sel) rendelkezik.

    • 1. szervizelési lehetőség. Ha tudja, hogy a virtuális gépek nem rendelkeznek kimenő internet-hozzáféréssel, működő DNS-szolgáltatással és működő Azure-ügynökökkel a virtuális gépeken, távolítsa el az összes virtuálisgép-bővítményt a migrálás részeként az Előkészítés előtt, majd telepítse újra a virtuálisgép-bővítményeket a migrálás után.

    • 2. szervizelési lehetőség. Ha a virtuálisgép-bővítmények túl nagyok, egy másik lehetőség az összes virtuális gép leállítása/felszabadítása a migrálás előtt. Migrálja a felszabadított virtuális gépeket, majd indítsa újra őket az Azure Resource Manager oldalán. Ennek az az előnye, hogy a virtuálisgép-bővítmények migrálva lesznek. A hátránya az, hogy az összes nyilvános virtuális IP-cím elvész (ez nem kezdő szintű lehet), és nyilvánvalóan a virtuális gépek leállnak, ami sokkal nagyobb hatást gyakorol a működő alkalmazásokra.

      Megjegyzés

      Ha a felhőhöz készült Microsoft Defender szabályzat a migrált futó virtuális gépekhez van konfigurálva, a biztonsági szabályzatot le kell állítani a bővítmények eltávolítása előtt, ellenkező esetben a rendszer automatikusan újratelepíti a biztonsági monitorozási bővítményt a virtuális gépen az eltávolítás után.

  • Rendelkezésre állási csoportok – Ahhoz, hogy egy virtuális hálózat (vNet) migrálható legyen az Azure Resource Manager, a klasszikus üzembe helyezés (azaz a felhőszolgáltatás) által tartalmazott virtuális gépeknek egy rendelkezésre állási csoportban kell lenniük, vagy a virtuális gépeknek nem lehetnek rendelkezésre állási csoportokban. Ha egynél több rendelkezésre állási csoport van a felhőszolgáltatásban, az nem kompatibilis az Azure Resource Manager, és leállítja a migrálást. Emellett egyes virtuális gépek nem lehetnek rendelkezésre állási csoportban, és egyes virtuális gépek nem lehetnek rendelkezésre állási csoportban. A probléma megoldásához helyre kell állítania vagy újra kell rendeznie a felhőszolgáltatást. Ennek megfelelően tervezze meg, mivel ez időigényes lehet.

  • Webes/feldolgozói szerepkörök üzembe helyezése – a webes és feldolgozói szerepköröket tartalmazó Cloud Services nem migrálhatók az Azure Resource Manager. A webes/feldolgozói szerepköröket először el kell távolítani a virtuális hálózatból a migrálás megkezdése előtt. Tipikus megoldás a webes/feldolgozói szerepkörpéldányok áthelyezése egy külön klasszikus virtuális hálózatra, amely szintén egy ExpressRoute-kapcsolatcsoporthoz van csatolva, vagy a kód újabb PaaS App Servicesbe való migrálása (ez a vitafórum túlmutat a jelen dokumentum hatókörén). Az előző ismételt üzembehelyezési esetben hozzon létre egy új klasszikus virtuális hálózatot, helyezze át/helyezze át újra a webes/feldolgozói szerepköröket az új virtuális hálózatba, majd törölje az áthelyezett virtuális hálózatból az üzemelő példányokat. Nincs szükség kódmódosításra. Az új Virtual Network társviszony-létesítési képesség használható a web-/feldolgozói szerepköröket és az ugyanabban az Azure-régióban található más virtuális hálózatokat, például az áttelepített virtuális hálózatot tartalmazó klasszikus virtuális hálózat társviszony-létesítésére (miután befejeződött a virtuális hálózat migrálása, mivel a társviszonyban álló virtuális hálózatok nem migrálhatók), így ugyanazokat a képességeket teljesítményvesztés és késés/sávszélesség-büntetés nélkül biztosíthatja. A Virtual Network társviszony-létesítés hozzáadása miatt a webes/feldolgozói szerepkörök üzembe helyezése mostantól egyszerűen kezelhető, és nem blokkolja az Azure-Resource Manager való migrálást.

  • Azure Resource Manager-kvóták – Az Azure-régiók külön kvótával/korlátokkal rendelkeznek a klasszikus és az Azure-Resource Manager. Annak ellenére, hogy a migrálási forgatókönyvben nem használnak fel új hardvereket (meglévő virtuális gépeket cserélünk klasszikusról Azure Resource Manager), az Azure Resource Manager kvótáinak továbbra is elegendő kapacitással kell lenniük a migrálás megkezdése előtt. Az alábbiakban felsoroljuk a problémákat okozó főbb korlátokat. Nyisson meg egy kvótatámogatási jegyet a korlátok megemeléséhez.

    Megjegyzés

    Ezeket a korlátokat ugyanabban a régióban kell emelni, mint az aktuális migrálni kívánt környezetet.

    • Hálózati illesztők

    • Terheléselosztók

    • Nyilvános IP-címek

    • Statikus nyilvános IP-címek

    • Cores

    • Network Security Groups (Hálózati biztonsági csoportok)

    • Útvonaltáblák

      A jelenlegi Azure Resource Manager-kvótákat az alábbi parancsokkal ellenőrizheti az Azure CLI legújabb verziójával.

      Compute(Magok, rendelkezésre állási csoportok)

      az vm list-usage -l <azure-region> -o jsonc

      Hálózat(virtuális hálózatok, statikus nyilvános IP-címek, nyilvános IP-címek, hálózati biztonsági csoportok, hálózati adapterek, terheléselosztók, útvonaltáblák)

      az network list-usages -l <azure-region> -o jsonc

      Storage(Tárfiók)

      az storage account show-usage

  • Az Azure Resource Manager API szabályozási korlátai – Ha elég nagy környezettel rendelkezik (például > 400 virtuális gép egy virtuális hálózaton), előfordulhat, hogy eléri az írások alapértelmezett API-szabályozási korlátait (jelenleg 1200 írás/óra) az Azure Resource Manager. A migrálás megkezdése előtt hozzon létre egy támogatási jegyet az előfizetés korlátjának növeléséhez.

  • Időtúllépés miatt kiépített virtuális gép állapota – Ha valamelyik virtuális gép kiépítési állapota túllépte az időkorlátot, ezt az áttelepítés előtt fel kell oldani. Ezt csak állásidővel teheti meg a virtuális gép megszüntetésével/újraépítésével (törölje, tartsa meg a lemezt, és hozza létre újra a virtuális gépet).

  • RoleStateUnknown Virtuális gép állapota – Ha a migrálás egy ismeretlen szerepkörállapot-hibaüzenet miatt leáll, ellenőrizze a virtuális gépet a portálon, és ellenőrizze, hogy fut-e. Ez a hiba általában néhány perc elteltével magától megszűnik (nincs szükség szervizelésre), és gyakran átmeneti típus, amelyet gyakran tapasztalnak a virtuális gépek indítási, leállítási és újraindítási műveletei során. Ajánlott eljárás: néhány perc múlva próbálkozzon újra a migrálással.

  • A hálófürt nem létezik – Bizonyos esetekben bizonyos virtuális gépek különböző furcsa okokból nem migrálhatók. Az egyik ilyen ismert eset az, ha a virtuális gépet nemrég hozták létre (az elmúlt egy héten belül), és olyan Azure-fürtöt szállt le, amely még nincs felszerelve az Azure Resource Manager számítási feladatokhoz. Hibaüzenet jelenik meg, amely szerint a hálófürt nem létezik , és a virtuális gép nem migrálható. A néhány napos várakozás általában megoldja ezt a problémát, mivel a fürt hamarosan engedélyezve lesz az Azure Resource Manager. Az egyik közvetlen áthidaló megoldás azonban a virtuális gép, stop-deallocate majd a migrálás folytatása, majd a migrálás után a virtuális gép biztonsági mentése az Azure Resource Manager.

Elkerülendő buktatók

  • Ne használja a parancsikonokat, és hagyja ki a száraz futtatás ellenőrzésére/előkészítésére/megszakítására vonatkozó migrálásokat.
  • A legtöbb, ha nem az összes lehetséges probléma az ellenőrzési/előkészítési/megszakítási lépések során jelenik meg.

Áttelepítés

Technikai szempontok és kompromisszumok

Most már készen áll, mert végigdolgozta a környezettel kapcsolatos ismert problémákat.

A valódi migrálások esetében érdemes megfontolni a következőket:

  1. Tervezze meg és ütemezze a virtuális hálózatot (a migrálás legkisebb egységét) növekvő prioritással. Először az egyszerű virtuális hálózatokat végezze el, és halad a bonyolultabb virtuális hálózatokkal.
  2. A legtöbb ügyfél nem éles és éles környezetekkel fog rendelkezni. Az üzem utolsó ütemezése.
  3. (NEM KÖTELEZŐ) Ütemezzen karbantartási állásidőt sok pufferrel, ha váratlan problémák merülnek fel.
  4. Ha problémák merülnek fel, kommunikáljon a támogatási csapatokkal, és összhangban legyen azokkal.

A siker mintái

A fenti Tesztkörnyezeti teszt szakasz technikai útmutatóját figyelembe kell venni és kezelni kell a valódi migrálás előtt. Megfelelő tesztelés esetén a migrálás valójában nem esemény. Éles környezetekben hasznos lehet további támogatás, például megbízható Microsoft-partner vagy Microsoft Premier szolgáltatások használata.

Elkerülendő buktatók

A nem teljes tesztelés problémákat és késést okozhat a migrálásban.

A migráláson túl

Technikai szempontok és kompromisszumok

Most, hogy az Azure Resource Manager van, maximalizálja a platformot. További előnyökért olvassa el az Azure Resource Manager áttekintését.

Megfontolandó szempontok:

  • A migrálás összekapcsolása más tevékenységekkel. A legtöbb ügyfél az alkalmazáskarbantartási időszakot választja. Ha igen, érdemes lehet ezt az állásidőt más Azure Resource Manager képességek, például a titkosítás és a Managed Disks való migrálás engedélyezéséhez használni.
  • Tekintse át az Azure Resource Manager technikai és üzleti okait; engedélyezze a csak az Azure-Resource Manager elérhető további szolgáltatásokat, amelyek az Ön környezetére vonatkoznak.
  • A környezet modernizálása PaaS-szolgáltatásokkal.

A siker mintái

Legyen céltudatos, hogy milyen szolgáltatásokat szeretne engedélyezni az Azure Resource Manager. Sok ügyfél az alábbi lenyűgözőnek találja az Azure-környezetek szempontjából:

Elkerülendő buktatók

Ne feledje, miért indította el ezt a klasszikus azure-Resource Manager migrálási folyamatot. Mik voltak az eredeti üzleti okok? Elérted az üzleti okot?

Következő lépések