Azure-alkalmazás-szolgáltatások áthelyezése másik régióba

Ez a cikk azt ismerteti, hogyan helyezhet át App Service-erőforrásokat egy másik Azure-régióba.

Számos oka lehet annak, hogy a meglévő Azure-erőforrásokat érdemes egyik régióból a másikba áthelyezni. Érdemes lehet:

• Használjon ki egy új Azure-régiót.
• Csak bizonyos régiókban elérhető szolgáltatások vagy szolgáltatások üzembe helyezése.
• A belső szabályzat és a szabályozási követelményeknek való megfelelés.
• Összhangban a vállalati egyesülésekkel és felvásárlásokkal
• A kapacitástervezési követelményeknek való megfelelés.

Az App Service-erőforrások régióspecifikusak, és nem helyezhetők át régiók között. Létre kell hoznia egy másolatot a meglévő App Service-erőforrásokról a célrégióban, majd át kell helyeznie a tartalmat az új alkalmazásba. Ha a forrásalkalmazás egyéni tartományt használ, az áthelyezés befejezése után migrálhatja azt a célrégióban lévő új alkalmazásba.

Az alkalmazás másolásának megkönnyítése érdekében biztonsági másolatot készíthet és visszaállíthat egy app Service-alkalmazást egy másik régióban lévő App Service-csomagba.

Előfeltételek

• Győződjön meg arról, hogy az App Service-alkalmazás abban az Azure-régióban van, ahonnan át szeretne lépni.
• Győződjön meg arról, hogy a célrégió támogatja az App Service-t és bármely kapcsolódó szolgáltatást, amelynek erőforrásait át szeretné helyezni.
• Ellenőrizze, hogy van-e elegendő engedély az App Service-erőforrások célelőfizetésben és régióban való üzembe helyezéséhez.
• Ellenőrizze, hogy van-e régiókorlátozással rendelkező Azure-szabályzat.
• Vegye figyelembe az üzemeltetési költségeket, mivel a számítási erőforrások árai régiónként eltérőek lehetnek. A lehetséges költségek becsléséhez tekintse meg a díjkalkulátort.

Előkészítés

Azonosítsa az összes jelenleg használt App Service-erőforrást. Példa:

• App Service-alkalmazások
• App Service-csomagok
• Üzembehelyezési pontok
• Az Azure-ban vásárolt egyéni tartományok
• TLS/SSL-tanúsítványok
• Azure Virtual Network-integráció
• Hibrid kapcsolatok.
• Felügyelt identitások
• Biztonsági mentési beállítások

Bizonyos erőforrások, például importált tanúsítványok vagy hibrid kapcsolatok más Azure-szolgáltatásokkal való integrációt tartalmaznak. Az erőforrások régiók közötti áthelyezéséről a megfelelő szolgáltatások dokumentációjában olvashat.

Felkészülés

Ez a szakasz egy tervezési ellenőrzőlista a következő területeken:

• Állapot-, tárolási és alsóbb rétegbeli függőségek
• Diplomák
• Konfiguráció
• VNet-kapcsolat / Egyéni nevek / DNS
• Identitások
• Szolgáltatásvégpontok

Állapot-, tárolási és alsóbb rétegbeli függőségek

• Határozza meg, hogy az App Service-alkalmazás állapotalapú vagy állapot nélküli-e. Bár azt javasoljuk, hogy az App Service Apps állapot nélküli legyen, és a %HOME%\site meghajtón lévő fájlok csak azok legyenek, amelyek az üzembe helyezett alkalmazás ideiglenes fájlokkal való futtatásához szükségesek, a futtatókörnyezeti alkalmazás állapota továbbra is tárolható a %HOME%\site virtuális meghajtón. Ha az alkalmazás az alkalmazás megosztott tárolási útvonalán írja az állapotot, mindenképpen tervezze meg, hogyan fogja kezelni az állapotot egy erőforrás áthelyezése során.

  Tipp.

  A Kudu használatával a portálhozzáféréssel együtt egy fájlelérési API-t (virtuális fájlrendszert (VFS)) is biztosíthat, amely képes fájlok olvasására/írására a %HOME%\site könyvtár alatt. További információ: Kudu Wiki.

• Ellenőrizze, hogy van-e belső gyorsítótárazás és állapot az alkalmazáskódban.

• Tiltsa le a munkamenet-affinitás beállításait. Ahol lehetséges, javasoljuk, hogy tiltsa le a munkamenet-affinitás beállítását. A munkamenet-affinitás letiltása javítja a horizontális horizontális felskálázás terheléselosztását. Bármely belső állapot hatással lehet a számítási feladatok csökkentésének tervezésére – különösen akkor, ha a nulla leállási idő követelmény. Ha lehetséges, hasznos lehet az alkalmazás állapotának újrabontása, hogy az alkalmazás állapot nélküli legyen az áthelyezés előkészítése során.

• Adatbázis-kapcsolati sztring elemzése. Az adatbázis-kapcsolati sztring az alkalmazásbeállítások között találhatók. Előfordulhat azonban, hogy az alkalmazással szállított konfigurációs fájlokban is keményen vannak kódoltak vagy kezelhetők. Elemezze és tervezze meg az adatmigrálást/replikációt a számítási feladat áthelyezésének magasabb szintű tervezésének részeként. A csevegő- vagy késés szempontjából kritikus alkalmazások esetében nem teljesít a célrégióban lévő alkalmazás számára, hogy visszatérjen a forrásrégió adatforrásaihoz.

• Külső gyorsítótárazás elemzése (például Redis). Az alkalmazás gyorsítótárait a lehető legközelebb kell üzembe helyezni az alkalmazáshoz. Elemezze a gyorsítótárak feltöltésének, a lejárati/kiürítési szabályzatoknak, valamint a ritka gyorsítótáraknak az első felhasználókra gyakorolt hatását a leépítés után.

• Az API- (vagy alkalmazás-) függőségek elemzése és megtervezése A régiók közötti kommunikáció jelentősen kevésbé teljesít, ha a célrégióban lévő alkalmazás visszatér a forrásrégióban lévő függőségekhez. Javasoljuk, hogy a számítási feladatok áthelyezésének részeként helyezze át az összes alsóbb rétegbeli függőséget. A *helyszíni* erőforrások azonban kivételt képeznek, különösen azok az erőforrások, amelyek földrajzilag közelebb vannak a célrégióhoz (ahogyan az újratelepítési forgatókönyvek esetében is előfordulhat).

  Az Azure Container Registry lehet egy alsóbb rétegbeli (futtatókörnyezeti) függőség az App Service-hez, amely egyéni tárolólemezképek futtatására van konfigurálva. Célszerűbb, ha a tárolóregisztrációs adatbázis ugyanabban a régióban van, mint maga az alkalmazás. Fontolja meg a szükséges képek feltöltését egy új ACR-be a cél get régióban. Ellenkező esetben fontolja meg a georeplikációs funkció használatát, ha a képeket a forrásrégióban szeretné tárolni.

• Regionális szolgáltatások elemzése és tervezése. Az Application Insights és a Log Analytics adatai regionális szolgáltatások. Fontolja meg új Application Insights- és Log Analytics-tároló létrehozását a célrégióban. Az App Insights esetében egy új erőforrás hatással van az kapcsolati sztring is, amelyet az alkalmazáskonfiguráció módosítása során frissíteni kell.

Diplomák

Az App Service áthelyezésének megtervezése során számos különböző tanúsítványtípust kell figyelembe venni:

• Az App Service ingyenes felügyelt tanúsítványa nem exportálható.
• Az App Service-tanúsítvány az Azure Key Vaulton keresztül PS1/CLI használatával exportálható.
• Az App Service-en kívül kezelt tanúsítvány.
• Az Azure Key Vaulton keresztül nem felügyelt App Service-tanúsítvány exportálható.
• Az App Service-tanúsítvány erőforrásai áthelyezhetők egy új erőforráscsoportba vagy előfizetésbe, de nem régiók közöttire. A régiók közötti áthelyezéseket az App Service-tanúsítványok nem támogatják.
• Az Azure Key Vaultban kezelt és tárolt tanúsítványokat először a forráskulcstartóból kell exportálni, majd újra importálni a célalkalmazáshoz társított Célkulcstartóba.

Néhány további megfontolandó szempont:

• Az alkalmazáshoz rendelt címek, ahol az App Service-alkalmazás SSL-kapcsolata egy adott alkalmazás által meghatározott IP-címhez van kötve, külső hálózatokból az App Service-be irányuló hívások engedélyezésére használható. Előfordulhat például, hogy egy hálózati/informatikai rendszergazda szeretné zárolni a helyszíni hálózatról vagy virtuális hálózatról érkező kimenő hívásokat egy statikus, jól ismert cím használatához. Így ha az alkalmazáshoz rendelt cím funkció használatban van, az alkalmazásba betárcsázókra vonatkozó felsőbb szintű tűzfalszabályokat – például belső, külső vagy harmadik feleket – ellenőrizni kell, és tájékoztatni kell az új címről. A tűzfalszabályok lehetnek belső, külső vagy harmadik felek, például partnerek vagy jól ismert ügyfelek.

• Fontolja meg a hálózati virtuális berendezés (NVA) vagy a fordított proxy használatát. Előfordulhat, hogy az NVA-konfigurációnak megváltoznia kell, ha újraírja a gazdagép fejlécét vagy/vagy SSL-végződését.

Feljegyzés

Az App Service Environment az egyetlen App Service-ajánlat, amely engedélyezi az alsóbb rétegbeli alkalmazásfüggőségek felé irányuló hívásokat SSL-en keresztül, ahol az SSL önaláírt/PKI-n alapul, nem szabványos legfelső szintű hitelesítésszolgáltatói tanúsítványokkal. A több-bérlős szolgáltatás nem biztosít hozzáférést az ügyfeleknek a megbízható tanúsítványtárolóba való feltöltéshez.

Az App Service-környezet ma nem engedélyezi az SSL-tanúsítványok vásárlását, csak a saját tanúsítványokat. Az IP-SSL nem lehetséges (és nincs értelme), de az SNI igen. A belső App Service-környezet nem társítható nyilvános tartományhoz, ezért a használt SSL-tanúsítványokat az ügyfélnek kell megadnia, ezért szállíthatónak kell lennie, például a PKI használatával generált belső használatra szolgáló tanúsítványokat. Az App Service Environment v3 külső módban ugyanazokat a funkciókat használja, mint a hagyományos több-bérlős App Service.

Konfiguráció

• Tekintse át az alkalmazáskonfigurációt olyan környezet- és régióspecifikus beállításokhoz, amelyeket esetleg módosítani kell. Ellenőrizze, hogy tartalmaz-e lemezfájl-konfigurációt, amely felül lehet bírálva az alkalmazásbeállításoknál.

• Vegye figyelembe, hogy a konfiguráció kezelhető egy központi (alsóbb rétegbeli) adatbázis-függőségből vagy egy olyan szolgáltatásból is, mint a Azure-alkalmazás Configuration.

• Hozza létre újra az App Service Key Vault-hivatkozásokat. A Key Vault-hivatkozások az erőforráshoz hozzárendelt egyedi MSI-hez kapcsolódnak (amely KV-adatsík-hozzáféréssel rendelkezik), és a Key Vaultnak valószínűleg ugyanabban a forrásrégióban kell lennie. Az Az Key Vault-tartalom nem exportálható egy Azure-beli földrajzi határon.

VNet-kapcsolat / Egyéni nevek / DNS

• Az App Service Environment egy virtuális hálózatba injektált egybérlős szolgáltatás. Az App Service Environment hálózatkezelése eltér a több-bérlős App Service-től, amelyhez egy vagy mindkét "privát végpont" vagy "regionális virtuális hálózat integrációja" szükséges. További lehetőség lehet a korábbi P2S VPN-alapú virtuális hálózatok integrációja és a hibrid kapcsolatok (egy Azure Relay szolgáltatás).

  Feljegyzés

  Az ASEv3 hálózatkezelés egyszerűbb – az Azure Management-forgalom és az App Service-környezetek saját alárendelt függőségei nem láthatók az ügyfél virtuális hálózata számára, ami jelentősen leegyszerűsíti a szükséges konfigurációt, ha az ügyfél egy kényszerítő alagutat használ az összes forgalomhoz, vagy egy hálózati virtuális berendezésen/tűzfalon keresztül küldi el a kimenő forgalom egy részhalmazát.

  A hibrid kapcsolatok (Azure Relay) regionálisak. Ha hibrid kapcsolatokat használ, és bár egy Azure Relay Namespace áthelyezhető egy másik régióba, egyszerűbb lenne újra üzembe helyezni a hibrid kapcsolatot (győződjön meg arról, hogy a hibrid kapcsolat be van állítva az új régióban a célerőforrások üzembe helyezésekor), és újból csatolja azt a hibridkapcsolat-kezelő. Gondosan meg kell fontolni a hibridkapcsolat-kezelő helyét.

• Kövesse a meleg készenléti régió stratégiáját. Győződjön meg arról, hogy a központi hálózat és kapcsolat, a központi hálózat, a tartományvezérlők, a DNS, a VPN vagy az Express Route stb. jelen vannak és tesztelve vannak az erőforrás-áthelyezés előtt.

• Ellenőrizze az összes felső vagy alsóbb rétegbeli hálózati ACL-t és konfigurációt. Vegyük például egy külső alsóbb rétegbeli szolgáltatást, amely csak az alkalmazás forgalmát engedélyezi. A több-bérlős App Service új alkalmazáscsomagba való áthelyezése a kimenő IP-címek változását is jelentené.

• A legtöbb esetben célszerű biztosítani, hogy a célrégió virtuális hálózatai egyedi címtérrel rendelkezzenek. Az egyedi címtér megkönnyíti a virtuális hálózatok közötti kapcsolatot, ha például az adatok replikálására van szükség. Ezért ezekben a forgatókönyvekben implicit követelményt kell módosítani:

  • Private DNS
  • Minden olyan kemény kódolt vagy külső konfiguráció, amely IP-cím alapján hivatkozik az erőforrásokra (gazdagépnév nélkül)
  • Hálózati ACL-ek, beleértve a hálózati biztonsági csoportokat és a tűzfal konfigurációját (itt is vegye figyelembe a helyszíni NVA-kra gyakorolt hatást)
  • Minden útválasztási szabály, felhasználó által megadott útvonaltáblák

  Emellett ellenőrizze a konfigurációt, beleértve a régióspecifikus IP-tartományokat/szolgáltatáscímkéket is, ha meglévő DevOps-telepítési erőforrásokat továbbít.

• Kevesebb módosításra van szükség az ügyfél által üzembe helyezett privát DNS-hez, amely úgy van konfigurálva, hogy továbbítsa az Azure-ba az Azure-tartományokhoz és az Azure DNS privát zónáihoz. Mivel azonban a privát végpontok egy erőforrás teljes tartományán alapulnak, és ez gyakran az erőforrás neve is (amely várhatóan eltérő lehet a célrégióban), ne felejtse el keresztellenőrzéssel ellenőrizni a konfigurációt, hogy a konfigurációban hivatkozott teljes tartománynevek ennek megfelelően frissüljenek.

• Szükség esetén hozza létre újra a privát végpontokat a célrégióban. Ugyanez vonatkozik a regionális virtuális hálózatok integrációjára is.

• Az App Service Environment DNS-ét általában az ügyfelek privát egyéni DNS-megoldásán keresztül kezelik (a manuális beállítások felülbírálása alkalmazásonként alapszintű megoldásonként érhető el). Az App Service Environment egy terheléselosztót biztosít a bejövő/kimenő forgalomhoz, míg maga az App Service szűri a gazdagépfejléceket. Ezért több egyéni név is mutatható ugyanarra az App Service Environment bejövő végpontra. Az App Service-környezet nem igényel tartományérvényesítést.

  Feljegyzés

  Az App Service Environment v3-hoz készült Kudu-végpont csak a következő címen {resourcename}.scm.{asename}.appserviceenvironment.netérhető el: . Az App Service Environment v3 DNS-sel és hálózatkezeléssel kapcsolatos további információkért lásd: App Service Environment hálózatkezelés.

  Az App Service Environment esetében az ügyfélé az útválasztás, ezért a leépítéshez használt erőforrások. Bárhol engedélyezve van a hozzáférés az App Service-környezethez külsőleg – általában egy 7. rétegbeli NVA vagy fordított proxy használatával – a Traffic Managerrel, vagy az Azure Front Door/Egyéb L7 globális terheléselosztási szolgáltatással.

• A szolgáltatás nyilvános több-bérlős verziójához az adatsík-végpontok alapértelmezett neve {resourcename}.azurwwebsites.net , valamint a Kudu (SCM) végpont alapértelmezett neve lesz kiépítve. Mivel a szolgáltatás alapértelmezés szerint nyilvános végpontot biztosít, a kötést ellenőrizni kell a tartomány tulajdonjogának igazolásához. A kötés üzembe helyezését követően azonban nincs szükség újraellenőrzésre, és nem szükséges ahhoz sem, hogy a nyilvános DNS-rekordok az App Service-végpontra mutassanak.

• Ha egyéni tartományt használ, azt előzetesen kösse a célalkalmazáshoz. Ellenőrizze és engedélyezze a tartományt a célalkalmazásban.

Identitások

• Hozza létre újra az App Service által felügyelt szolgáltatásidentitásokat az új célrégióban.

• Rendelje hozzá az új MSI hitelesítőadat-alapú szolgáltatáshozzáférést (RBAC). Az automatikusan létrehozott Microsoft Entra ID-alkalmazás (amelyet az EasyAuth használ) alapértelmezés szerint az alkalmazás erőforrásának neve lesz. A célrégióban lévő új erőforrás újrakészítéséhez itt megfontolandó szempontokat kell figyelembe venni. A felhasználó által definiált szolgáltatásnév hasznos lehet, mivel a forrásra és a célra is alkalmazható extra hozzáférési engedélyekkel a cél üzembehelyezési erőforrásokhoz.

• Tervezze meg az identitásszolgáltató (IDP) célrégióba való áthelyezését. Bár a Microsoft Entra ID egy globális szolgáltatás, egyes megoldások helyi (vagy helyszíni) identitásszolgáltatóra támaszkodnak.

• Frissítsen minden olyan erőforrást az App Service-be, amely a Kudu FTP-hitelesítő adataira támaszkodhat.

Szolgáltatásvégpontok

A Azure-alkalmazás szolgáltatás virtuális hálózati szolgáltatásvégpontjai korlátozzák a megadott virtuális hálózathoz való hozzáférést. A végpontok korlátozhatják az IPv4 -címtartományok (4-es internetprotokoll-verzió) listájához való hozzáférést is. Minden olyan felhasználó, aki ezeken a forrásokon kívülről csatlakozik az Event Hubshoz, megtagadja a hozzáférést. Ha a szolgáltatásvégpontok az Event Hubs-erőforrás forrásrégiójában lettek konfigurálva, ugyanezt a célhelyen kell elvégezni.

A Azure-alkalmazás szolgáltatás célrégióba való sikeres felüdüléséhez előzetesen létre kell hozni a virtuális hálózatot és az alhálózatot. Ha a két erőforrás áthelyezése az Azure Resource Mover eszközzel történik, a szolgáltatásvégpontok nem lesznek automatikusan konfigurálva. Ezért manuálisan kell konfigurálni őket, ami az Azure Portalon, az Azure CLI-vel vagy az Azure PowerShell-lel végezhető el.

Áthelyez

Az App Service-erőforrások áthelyezéséhez használhatja az Azure Portalt vagy az infrastruktúrát kódként (IaC).

Áthelyezés az Azure Portal használatával

Az Azure Portal áthelyezésének legnagyobb előnye az egyszerűsége. Az alkalmazás, a csomag és a tartalom, valamint számos beállítás klónozva lesz az új App Service-erőforrásba és csomagba.

Ne feledje, hogy az App Service Environment (izolált) szintek esetében először újra kell üzembe helyeznie a teljes App Service-környezetet egy másik régióban, majd újra üzembe helyezheti az egyes csomagokat az új App Service-környezetben az új régióban.

Az App Service-erőforrások áthelyezése egy új régióba az Azure Portal használatával:

1. Készítsen biztonsági másolatot a forrásalkalmazásról.
2. Hozzon létre egy alkalmazást egy új App Service-csomagban a célrégióban.
3. Biztonsági másolat visszaállítása a célalkalmazásban
4. Ha egyéni tartományt használ, azt előzetesen kösse a célalkalmazáshozasuid., és engedélyezze a tartományt a célalkalmazásban.
5. Konfigurálja a célalkalmazás minden más elemét úgy, hogy az megegyezik a forrásalkalmazással, és ellenőrizze a konfigurációt.
6. Ha készen áll arra, hogy az egyéni tartomány a célalkalmazásra mutasson, újraképezze a tartománynevet.

Áthelyezés az IaC használatával

Akkor használja az IaC-t, ha létezik vagy hozható létre egy meglévő folyamatos integrációs és folyamatos kézbesítési/üzembehelyezési (CI/CD) folyamat. Ha egy CI/CD-folyamat van érvényben, az App Service-erőforrás egy üzembe helyezési művelet vagy egy Kudu zip-telepítés segítségével hozható létre a célrégióban.

Az SLA-követelményeknek meg kell határozniuk, hogy mennyi további erőfeszítésre van szükség. Például: Ez egy korlátozott állásidővel rendelkező újra üzembe helyezés, vagy közel valós idejű leépítés szükséges minimális állásidővel?

A külső, globális forgalomirányítási peremhálózati szolgáltatások, például a Traffic Manager vagy az Azure Front Door felvétele segít megkönnyíteni a külső felhasználók és alkalmazások leépítését.

Tipp.

A Traffic Managert (ATM) akkor lehet használni, ha privát végpontok mögötti App Services-feladatokat ad át. Bár a Traffic Manager-mintavételek nem érik el a privát végpontokat – ha az összes végpont csökkent, akkor az ATM engedélyezi az útválasztást. További információ: Azure-alkalmazás szolgáltatásforgalom szabályozása az Azure Traffic Managerrel.

Érvényesítés

Az áthelyezés befejezése után tesztelje és ellenőrizze Azure-alkalmazás szolgáltatást az ajánlott irányelvekkel:

• Miután a Azure-alkalmazás szolgáltatást áthelyezték a célrégióba, futtasson egy füst- és integrációs tesztet. A teszteket manuálisan is tesztelheti vagy futtathatja egy szkripten keresztül. Ellenőrizze, hogy minden konfiguráció és függő erőforrás megfelelően van-e összekapcsolva, és hogy az összes konfigurált adat elérhető-e.

• Ellenőrizze az összes Azure-alkalmazás szolgáltatásösszetevőt és integrációt.

• Integrációs tesztelést végezhet a célrégió üzembe helyezésén, beleértve az összes formális regressziós tesztelést. Az integrációs tesztelésnek összhangban kell lennie a szokásos Üzleti ritmus üzembe helyezési és tesztelési folyamatokkal, amelyek a számítási feladatra vonatkoznak.

• Bizonyos esetekben , különösen ha az áthelyezés frissítéseket, az alkalmazások vagy az Azure-erőforrások módosítását vagy a használati profil módosítását is magában foglalja, terhelésteszteléssel ellenőrizze, hogy az új számítási feladat alkalmas-e a célra. A terheléstesztelés emellett a műveletek és a figyelési lefedettség ellenőrzésének lehetőségét is lehetővé teszi. Terheléstesztelés használatával például ellenőrizze, hogy a szükséges infrastruktúra és alkalmazásnaplók megfelelően lettek-e létrehozva. A terhelésteszteket a számítási feladatok teljesítménykonfigurációi alapján kell mérni.

Tipp.

Az App Service áthelyezésével újra felmérheti a rendelkezésre állási és vészhelyreállítási tervezést. Az App Service és az App Service Environment (App Service Environment v3) támogatja a rendelkezésre állási zónákat , és ajánlott a rendelkezésre állási zóna konfigurációjával konfigurálni. Tartsa szem előtt az üzembe helyezés, a díjszabás és a korlátozások előfeltételeit, és vegye figyelembe ezeket az erőforrások áthelyezésének tervezésében. A rendelkezésre állási zónákról és az App Service-ről további információt Azure-alkalmazás Szolgáltatás megbízhatósága című témakörben talál.

A fölöslegessé vált elemek eltávolítása

Törölje a forrásalkalmazást és az App Service-csomagot. A nem ingyenes szinten lévő App Service-csomagok díjkötelesek, még akkor is, ha nem fut benne alkalmazás.

Következő lépések

Azure-alkalmazás Szolgáltatásalkalmazás klónozása a PowerShell használatával