Azure-app Services verplaatsen naar een andere regio

Artikel
07/27/2024

In dit artikel wordt beschreven hoe u App Service-resources verplaatst naar een andere Azure-regio.

Er zijn verschillende redenen waarom u uw bestaande Azure-resources mogelijk van de ene regio naar de andere wilt verplaatsen. U kunt het volgende doen:

Profiteer van een nieuwe Azure-regio.
Implementeer functies of services die alleen beschikbaar zijn in specifieke regio's.
Voldoen aan interne beleids- en governancevereisten.
In overeenstemming met bedrijfsfusies en overnames
Voldoen aan vereisten voor capaciteitsplanning.

App Service-resources zijn regiospecifiek en kunnen niet worden verplaatst tussen regio's. U moet een kopie maken van uw bestaande App Service-resources in de doelregio en vervolgens uw inhoud verplaatsen naar de nieuwe app. Als uw bron-app gebruikmaakt van een aangepast domein, kunt u deze migreren naar de nieuwe app in de doelregio na voltooiing van de verplaatsing.

Als u het kopiëren van uw app eenvoudiger wilt maken, kunt u een back-up maken van een afzonderlijke App Service-app en deze herstellen in een App Service-plan in een andere regio.

Vereisten

Zorg ervoor dat de App Service-app zich in de Azure-regio bevindt waaruit u wilt verplaatsen.
Zorg ervoor dat de doelregio App Service en alle gerelateerde services ondersteunt, waarvan u de resources wilt verplaatsen.
Controleer of er voldoende machtigingen bestaan om App Service-resources te implementeren in het doelabonnement en de doelregio.
Controleer of een Azure-beleid is toegewezen met een regiobeperking.
Houd rekening met eventuele operationele kosten, omdat de prijzen van rekenresources per regio kunnen verschillen. Als u uw mogelijke kosten wilt schatten, raadpleegt u de prijscalculator.

Voorbereiden

Identificeer alle App Service-resources die u momenteel gebruikt. Voorbeeld:

Bepaalde resources, zoals geïmporteerde certificaten of hybride verbindingen, bevatten integratie met andere Azure-services. Zie de documentatie voor de betreffende services voor informatie over het verplaatsen van deze resources tussen regio's.

Plannen

Deze sectie is een controlelijst voor planning op de volgende gebieden:

Status-, opslag- en downstreamafhankelijkheden
Certificaten
Configuratie
VNet-connectiviteit/aangepaste namen/DNS
Identiteiten
Service-eindpunten

Status-, opslag- en downstreamafhankelijkheden

Bepaal of uw App Service-app stateful of staatloos is. Hoewel we aanraden dat App Service-apps staatloos zijn en de bestanden op het %HOME%\site station alleen moeten zijn die nodig zijn om de geïmplementeerde toepassing met tijdelijke bestanden uit te voeren, is het nog steeds mogelijk om de runtimetoepassingsstatus op te slaan op het %HOME%\site virtuele station. Als uw toepassing de status schrijft op het gedeelde opslagpad van de app, moet u plannen hoe u die status gaat beheren tijdens het verplaatsen van een resource.

Tip

U kunt Kudu gebruiken om, samen met portaltoegang, een API voor bestandstoegang (Virtual File System (VFS) te bieden waarmee bestanden in de %HOME%\site map kunnen worden gelezen/geschreven. Zie Kudu Wiki voor meer informatie.
Controleer op interne caching en status in toepassingscode.
Instelling voor sessieaffiniteit uitschakelen. Waar mogelijk raden we u aan de instelling voor sessieaffiniteit uit te schakelen. Als u sessieaffiniteit uitschakelt, verbetert u de taakverdeling voor een horizontale uitschaalbewerking. Elke interne status kan van invloed zijn op de planning voor het knippen van een workload, met name als er geen downtime nodig is. Indien mogelijk kan het nuttig zijn om elke toepassingsstatus te herstructureren om de toepassing staatloos te maken ter voorbereiding op de verplaatsing.
Analyseer database-verbindingsreeks s. Database-verbindingsreeks s vindt u in de app-instellingen. Ze kunnen echter ook in code worden vastgelegd of beheerd in configuratiebestanden die bij de toepassing worden geleverd. Analyseer en plan gegevensmigratie/replicatie als onderdeel van de planning op een hoger niveau om de workload te verplaatsen. Voor chatty- of latentiekritieke toepassingen is het niet goed voor de toepassing in de doelregio om terug te gaan naar gegevensbronnen in de bronregio.
Externe caching analyseren (bijvoorbeeld Redis). Toepassingscaches moeten zo dicht mogelijk bij de toepassing worden geïmplementeerd. Analyseer hoe caches worden gevuld, verloop-/verwijderingsbeleid en eventuele gevolgen van een koude cache voor de eerste gebruikers om toegang te krijgen tot de workload na cut-over.
Analyse en plan voor API-afhankelijkheden (of toepassingsafhankelijkheden ) communicatie tussen regio's is aanzienlijk minder goed als de app in de doelregio teruggaat naar afhankelijkheden die zich nog in de bronregio bevinden. We raden u aan alle downstreamafhankelijkheden te verplaatsen als onderdeel van de herlocatie van de workload. *on-premises* resources zijn echter de uitzondering, met name de resources die geografisch dichter bij de doelregio liggen (zoals het geval kan zijn bij repatriëringsscenario's).

Azure Container Registry kan een downstream-afhankelijkheid (runtime) zijn voor App Service die is geconfigureerd voor uitvoering op basis van aangepaste containerinstallatiekopieën. Het is logischer dat het Container Registry zich in dezelfde regio bevindt als de app zelf. Overweeg om de vereiste afbeeldingen te uploaden naar een nieuwe ACR in de doelregio. Anders kunt u overwegen om de functie voor geo-replicatie te gebruiken als u van plan bent om de installatiekopieën in de bronregio te bewaren.
Analyseren en plannen voor regionale services. Application Insights- en Log Analytics-gegevens zijn regionale services. Overweeg het maken van nieuwe Application Insights- en Log Analytics-opslag in de doelregio. Voor App Insights heeft een nieuwe resource ook invloed op de verbindingsreeks die moeten worden bijgewerkt als onderdeel van de wijziging in App Configuration.

Certificaten

Er zijn een aantal verschillende soorten certificaten waarmee rekening moet worden gehouden bij het plannen van uw App Service-herlocatie:

Een gratis beheerd certificaat van App Service kan niet worden geëxporteerd.
Een App Service-certificaat via Azure Key Vault kan worden geëxporteerd met behulp van PS1/CLI.
Een certificaat dat u buiten App Service beheert.
Een App Service-certificaat, niet beheerd via Azure Key Vault, kan worden geëxporteerd.
App Service-certificaatresources kunnen worden verplaatst naar een nieuwe resourcegroep of abonnement, maar niet naar een andere regio. Verplaatsingen tussen regio's worden niet ondersteund door App Service-certificaten.
Certificaten die u beheert en opslaat in Azure Key Vault, moeten eerst worden geëxporteerd uit de bronsleutelkluis en opnieuw worden geïmporteerd in de doelsleutelkluis die is gekoppeld aan de doel-app.

Enkele andere punten om rekening mee te houden:

App-toegewezen adressen, waarbij de SSL-verbinding van een App Service-app is gebonden aan een specifiek door de app aangewezen IP-adres, kan worden gebruikt voor acceptatieaanroepen van netwerken van derden in App Service. Een netwerk-/IT-beheerder wil bijvoorbeeld uitgaande oproepen van een on-premises netwerk of VNet vergrendelen om een statisch, bekend adres te gebruiken. Als de functie Toegewezen adres van de app in gebruik is, moeten upstream-firewallregels, zoals intern, extern of derden, worden gecontroleerd en geïnformeerd over het nieuwe adres. Firewallregels kunnen interne, externe of externe partijen zijn, zoals partners of bekende klanten.
Overweeg een upstream Network Virtual Appliance (NVA) of omgekeerde proxy. De NVA-configuratie moet mogelijk worden gewijzigd als u de hostheader of ssl-beëindiging herschrijft.

Notitie

App Service Environment is de enige App Service-aanbieding die downstreamaanroepen naar downstreamtoepassingsafhankelijkheden via SSL toestaat, waarbij de SSL afhankelijk is van zelfondertekende/PKI met ingebouwde basis-CA-certificaten. De multitenant-service biedt geen toegang voor klanten om te uploaden naar het vertrouwde certificaatarchief.

App Service Environment staat momenteel geen aankoop van SSL-certificaten toe, alleen Bring Your Own-certificaten. IP-SSL is niet mogelijk (en is niet logisch), maar SNI is. Interne App Service Environment wordt niet gekoppeld aan een openbaar domein en daarom moeten de gebruikte SSL-certificaten worden verstrekt door de klant en zijn daarom transporteerbaar, bijvoorbeeld certificaten voor intern gebruik die zijn gegenereerd met behulp van PKI. App Service Environment v3 in de externe modus deelt dezelfde functies als de reguliere App Service voor meerdere tenants.

Configuratie

Controleer app-configuratie voor omgevings- en regiospecifieke instellingen die mogelijk moeten worden gewijzigd. Zorg ervoor dat u controleert of de configuratie van het schijfbestand is ingesteld, die al dan niet wordt overschreven met app-instellingen.
Houd er rekening mee dat de configuratie ook kan worden beheerd vanuit een centrale (downstream)databaseafhankelijkheid of een service zoals Azure-toepassing Configuratie.
Referenties voor App Service Key Vault opnieuw maken. Key Vault-verwijzingen zijn gerelateerd aan de unieke MSI die is toegewezen aan de resource (met KV-gegevensvlaktoegang) en de Key Vault zelf moet zich waarschijnlijk in dezelfde bronregio bevinden. Az Key Vault-inhoud kan niet worden geëxporteerd over een geografische grens van Azure.

VNet-connectiviteit/aangepaste namen/DNS

App Service Environment is een VNet-geïnjecteerde service met één tenant. App Service Environment-netwerken verschillen van de multitenant App Service, waarvoor een of beide privé-eindpunten of regionale VNet-integratie vereist zijn. Andere opties die mogelijk worden afgespeeld, zijn de verouderde VNet-integratie op basis van P2S VPN en hybride verbindingen (een Azure Relay-service).

Notitie

ASEv3-netwerken worden vereenvoudigd: het Verkeer van Azure Management en de App Service Environments zijn niet zichtbaar voor het virtuele netwerk van de klant, waardoor de configuratie die nodig is voor het gebruik van een geforceerde tunnel voor al het verkeer, of het verzenden van een subset van uitgaand verkeer, via een virtueel netwerkapparaat/firewall aanzienlijk wordt vereenvoudigd.

Hybride verbindingen (Azure Relay) zijn regionaal. Als hybride verbindingen worden gebruikt en hoewel een Azure Relay-naamruimte naar een andere regio kan worden verplaatst, is het eenvoudiger om de hybride verbinding opnieuw te implementeren (zorg ervoor dat de hybride verbinding is ingesteld in de nieuwe regio bij het implementeren van de doelresources) en koppel deze opnieuw aan de hybride Verbindingsbeheer. De locatie van de hybride Verbindingsbeheer moet zorgvuldig worden overwogen.
Volg de strategie voor een warme stand-byregio. Zorg ervoor dat de kernnetwerken en -connectiviteit, hubnetwerk, domeincontrollers, DNS, VPN of Express Route, enzovoort, aanwezig en getest zijn voordat de resource wordt verplaatst.
Valideer upstream- of downstreamnetwerk-ACL's en configuratie. Denk bijvoorbeeld aan een externe downstreamservice die alleen uw app-verkeer toestaat. Een verplaatsing naar een nieuw toepassingsplan voor een multitenant App Service zou dan ook een wijziging zijn in uitgaande IP-adressen.
In de meeste gevallen is het raadzaam ervoor te zorgen dat de doelregio-VNets unieke adresruimte hebben. Een unieke adresruimte faciliteert VNet-connectiviteit als dit bijvoorbeeld nodig is om gegevens te repliceren. Daarom is er in deze scenario's een impliciete vereiste om te wijzigen:
- Privé-DNS
- Alle in code vastgelegde of externe configuratie die verwijst naar resources op IP-adres (zonder hostnaam)
- Netwerk-ACL's, waaronder netwerkbeveiligingsgroepen en firewallconfiguratie (houd rekening met de gevolgen voor on-premises NVA's hier ook)
- Routeringsregels, door de gebruiker gedefinieerde routetabellen
Zorg er ook voor dat u de configuratie controleert, inclusief regiospecifieke IP-bereiken/servicetags als u bestaande DevOps-implementatiebronnen doorstuurt.
Er zijn minder wijzigingen vereist voor door de klant geïmplementeerde privé-DNS die is geconfigureerd om door te sturen naar Azure voor Azure-domeinen en Azure DNS-privézones. Aangezien privé-eindpunten echter zijn gebaseerd op een resource-FQDN en dit vaak ook de resourcenaam is (die naar verwachting anders moet zijn in de doelregio), moet u de configuratie kruislings controleren om ervoor te zorgen dat FQDN's waarnaar in de configuratie wordt verwezen, dienovereenkomstig worden bijgewerkt.
Maak privé-eindpunten opnieuw, indien gebruikt, in de doelregio. Hetzelfde geldt voor regionale VNet-integratie.
DNS voor App Service Environment wordt doorgaans beheerd via de persoonlijke aangepaste DNS-oplossing van klanten (er is een handmatige instelling die beschikbaar is op basis van een app). App Service Environment biedt een load balancer voor inkomend/uitgaand verkeer, terwijl App Service zelf filtert op hostheaders. Daarom kunnen meerdere aangepaste namen worden gericht op hetzelfde eindpunt voor inkomend verkeer van App Service Environment. Voor App Service Environment is geen domeinvalidatie vereist.

Notitie

Het Kudu-eindpunt voor App Service Environment v3 is alleen beschikbaar op {resourcename}.scm.{asename}.appserviceenvironment.net. Zie App Service Environment-netwerken voor meer informatie over App Service Environment v3 DNS en netwerken, enzovoort.

Voor App Service Environment is de klant eigenaar van de routering en daarom de resources die worden gebruikt voor de cut-over. Waar toegang extern is ingeschakeld voor de App Service-omgeving , meestal via een NVA-laag 7 of omgekeerde proxy - Traffic Manager of Azure Front Door/Other L7 Global Load Balancing Service kan worden gebruikt.
Voor de openbare multitenant-versie van de service wordt een standaardnaam {resourcename}.azurwwebsites.net ingericht voor de eindpunten van het gegevensvlak, samen met een standaardnaam voor het Kudu-eindpunt (SCM). Omdat de service standaard een openbaar eindpunt biedt, moet de binding worden geverifieerd om het eigendom van het domein te bewijzen. Zodra de binding is ingesteld, is herverificatie echter niet vereist, noch is deze vereist voor openbare DNS-records om naar het App Service-eindpunt te verwijzen.
Als u een aangepast domein gebruikt, bindt u dit vooraf aan de doel-app. Controleer en schakel het domein in de doel-app in.

Identiteiten

Maak Beheerde Service-identiteiten van App Service opnieuw in de nieuwe doelregio.
Wijs de nieuwe MSI-referentie downstreamservicetoegang (RBAC) toe. Normaal gesproken wordt een automatisch gemaakte Microsoft Entra ID-app (één die door EasyAuth wordt gebruikt) standaard ingesteld op de naam van de app-resource. Er kan hier rekening worden gehouden met het opnieuw maken van een nieuwe resource in de doelregio. Een door de gebruiker gedefinieerde service-principal zou nuttig zijn, omdat deze kan worden toegepast op zowel de bron als het doel met extra toegangsmachtigingen voor doelimplementatieresources.
Plan voor het verplaatsen van de id-provider (IDP) naar de doelregio. Hoewel Microsoft Entra ID een globale service is, zijn sommige oplossingen afhankelijk van een lokale (of downstream on-premises) IDP.
Werk alle resources bij naar de App Service die mogelijk afhankelijk is van Kudu FTP-referenties.

Service-eindpunten

De service-eindpunten van het virtuele netwerk voor Azure-app Service beperken de toegang tot een opgegeven virtueel netwerk. De eindpunten kunnen ook de toegang tot een lijst met IPv4-adresbereiken (internetprotocol versie 4) beperken. Elke gebruiker die verbinding maakt met de Event Hubs van buiten deze bronnen, wordt de toegang geweigerd. Als service-eindpunten zijn geconfigureerd in de bronregio voor de Event Hubs-resource, moet hetzelfde worden gedaan in de doelregio.

Voor een geslaagde recreatie van de Azure-app Service naar de doelregio moet het VNet en subnet vooraf worden gemaakt. Als de verplaatsing van deze twee resources wordt uitgevoerd met het Azure Resource Mover-hulpprogramma, worden de service-eindpunten niet automatisch geconfigureerd. Daarom moeten ze handmatig worden geconfigureerd, wat kan worden gedaan via Azure Portal, de Azure CLI of Azure PowerShell.

Verhuizen

Als u App Service-resources wilt verplaatsen, kunt u Azure Portal of Infrastructure as Code (IaC) gebruiken.

Verplaatsen met behulp van Azure Portal

Het grootste voordeel van het gebruik van Azure Portal om te verhuizen, is de eenvoud. De app, het plan en de inhoud, evenals veel instellingen worden gekloond naar de nieuwe App Service-resource en -planning.

Houd er rekening mee dat u voor App Service Environment-lagen (geïsoleerde lagen) eerst de hele App Service-omgeving in een andere regio opnieuw moet implementeren. Vervolgens kunt u beginnen met het opnieuw implementeren van de afzonderlijke plannen in de nieuwe App Service-omgeving in de nieuwe regio.

Ga als volgt te werk om uw App Service-resources te verplaatsen naar een nieuwe regio met behulp van Azure Portal:

Maak een back-up van de bron-app.
Maak een app in een nieuw App Service-plan in de doelregio.
De back-up herstellen in de doel-app
Als u een aangepast domein gebruikt, bindt u dit vooraf aan de doel-app en asuid. schakelt u het domein in de doel-app in.
Configureer alle andere items in uw doel-app zodat deze hetzelfde zijn als de bron-app en controleer uw configuratie.
Wanneer u klaar bent voor het aangepaste domein om naar de doel-app te verwijzen, wijst u de domeinnaam opnieuw toe.

Verplaatsen met behulp van IaC

Gebruik IaC wanneer er een bestaande pijplijn voor continue integratie en continue levering/implementatie (CI/CD) bestaat of kan worden gemaakt. Als er een CI/CD-pijplijn is ingesteld, kan uw App Service-resource worden gemaakt in de doelregio door middel van een implementatieactie of een Kudu-zip-implementatie.

Sla-vereisten moeten bepalen hoeveel extra inspanning er nodig is. Bijvoorbeeld: Is dit een herploy met beperkte downtime of is het een bijna realtime cut-over vereist met minimale tot geen downtime?

Het opnemen van externe, globale edge-services voor verkeersroutering, zoals Traffic Manager of Azure Front Door, helpt om cut-over te vergemakkelijken voor externe gebruikers en toepassingen.

Tip

Het is mogelijk om Traffic Manager (ATM) te gebruiken bij een failover van App Services achter privé-eindpunten. Hoewel de privé-eindpunten niet bereikbaar zijn door Traffic Manager-tests: als alle eindpunten zijn gedegradeerd, staat ATM routering toe. Zie Het beheren van Azure-app serviceverkeer met Azure Traffic Manager voor meer informatie.

Valideren

Zodra de herlocatie is voltooid, test en valideert u Azure-app Service met de aanbevolen richtlijnen:

Zodra de Azure-app Service is verplaatst naar de doelregio, voert u een betrouwbaarheids- en integratietest uit. U kunt handmatig testen of een test uitvoeren via een script. Controleer of alle configuraties en afhankelijke resources correct zijn gekoppeld en of alle geconfigureerde gegevens toegankelijk zijn.
Valideer alle Azure-app Service-onderdelen en -integratie.
Voer integratietests uit op de implementatie van de doelregio, inclusief alle formele regressietests. Integratietests moeten overeenkomen met het gebruikelijke ritme van de bedrijfsimplementatie en testprocessen die van toepassing zijn op de workload.
In sommige scenario's, met name wanneer de herlocatie updates, wijzigingen in de toepassingen of Azure-resources of een wijziging in het gebruiksprofiel omvat, gebruikt u belastingstests om te controleren of de nieuwe workload geschikt is voor doeleinden. Belastingstests bieden ook de mogelijkheid om bewerkingen en bewakingsdekking te valideren. Gebruik bijvoorbeeld belastingstests om te controleren of de vereiste infrastructuur- en toepassingslogboeken correct worden gegenereerd. Belastingstests moeten worden gemeten op basis van vastgestelde basislijnen voor workloadprestaties.

Tip

Een App Service-herlocatie is ook een mogelijkheid om de planning voor beschikbaarheid en herstel na noodgevallen opnieuw te evalueren. App Service en App Service Environment (App Service Environment v3) ondersteunen beschikbaarheidszones en het wordt aanbevolen om te configureren met een configuratie van een beschikbaarheidszone. Houd rekening met de vereisten voor implementatie, prijzen en beperkingen en factor deze in de planning voor het verplaatsen van resources. Zie Betrouwbaarheid in Azure-app Service voor meer informatie over beschikbaarheidszones en App Service.

Opschonen

Verwijder de bron-app en het App Service-plan. Een App Service-plan in de niet-gratis laag brengt kosten met zich mee, zelfs als er geen app wordt uitgevoerd.

Volgende stappen

Azure-app Service-app klonen met behulp van PowerShell

Delen via