Azure-app Services verplaatsen naar een andere regio

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:

• App Service-apps
• App Service-abonnementen
• Implementatiesites
• Aangepaste domeinen die zijn aangeschaft in Azure
• TLS/SSL-certificaten
• Azure Virtual Network-integratie
• Hybride verbindingen.
• Beheerde identiteiten
• Back-upinstellingen

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

App Service-certificaatresources kunnen worden verplaatst naar een nieuwe resourcegroep of een nieuw abonnement, maar niet tussen regio's. Certificaten die kunnen worden geëxporteerd, kunnen ook worden geïmporteerd in de app of in Key Vault in de nieuwe regio. Dit export- en importproces is gelijk aan een verplaatsing tussen regio's.

Er zijn verschillende soorten certificaten waarmee rekening moet worden gehouden bij het plannen van uw serviceverplaatsing:

Type certificaat	Exporteerbaar	Opmerkingen
App Service beheerd	Nee	Maak deze certificaten opnieuw in de nieuwe regio.
Azure Key Vault beheerd	Ja	Deze certificaten kunnen worden geëxporteerd uit Key Vault en vervolgens worden geïmporteerd in Key Vault in de nieuwe regio.
Persoonlijke sleutel (zelfbeheerd)	Ja	Certificaten die u buiten Azure hebt verkregen, kunnen worden geëxporteerd uit App Service en vervolgens worden geïmporteerd in de nieuwe app of in Key Vault in de nieuwe regio.
Openbare sleutel	Nee	Uw app heeft mogelijk certificaten met alleen een openbare sleutel en geen geheim, die worden gebruikt voor toegang tot andere beveiligde eindpunten. Haal de vereiste openbare-sleutelcertificaatbestanden op en importeer deze in de app in de nieuwe regio.

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

• U kunt een momentopname van de bestaande app-instellingen en verbindingsreeks s vanuit Azure Portal vastleggen. Vouw Omgevingsvariabelen instellingen>uit, selecteer Geavanceerd bewerken onder App-instellingen of Verbindingsreeksen en sla de JSON-uitvoer op die de bestaande instellingen of verbindingen bevat. U moet deze instellingen opnieuw maken in de nieuwe regio, maar de waarden zelf worden waarschijnlijk gewijzigd als gevolg van latere regiowijzigingen in de verbonden services.

• Bestaande Key Vault-verwijzingen kunnen niet worden geëxporteerd over een geografische grens van Azure. U moet alle vereiste verwijzingen in de nieuwe regio opnieuw maken.

• Uw app-configuratie kan worden beheerd door Azure-app Configuratie of vanuit een andere centrale (downstream) databaseafhankelijkheid. Bekijk een App Configuration-archief of vergelijkbare winkels voor omgevings- en regiospecifieke instellingen waarvoor mogelijk wijzigingen zijn vereist.

• Zorg ervoor dat u de configuratie van een schijfbestand controleert, die al dan niet wordt overschreven door toepassingsinstellingen.

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}.azurewebsites.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

• U moet alle door het systeem toegewezen beheerde identiteiten opnieuw maken, samen met uw app in de nieuwe doelregio. Normaal gesproken wordt een automatisch gemaakte Microsoft Entra ID-app, die door EasyAuth wordt gebruikt, standaard ingesteld op de naam van de app-resource.

• Door de gebruiker toegewezen beheerde identiteiten kunnen ook niet worden verplaatst tussen regio's. Als u door de gebruiker toegewezen beheerde identiteiten in dezelfde resourcegroep met uw app wilt behouden, moet u deze opnieuw maken in de nieuwe regio. Zie Beheerde identiteiten voor Azure-resources verplaatsen naar een andere regio voor meer informatie.

• Verdeel de beheerde identiteiten dezelfde machtigingen in uw verplaatste services als de oorspronkelijke identiteiten die ze vervangen, inclusief groepslidmaatschappen.

• 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:

1. Maak een back-up van de bron-app.
2. Maak een app in een nieuw App Service-plan in de doelregio.
3. De back-up herstellen in de doel-app
4. 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.
5. Configureer alle andere items in uw doel-app zodat deze hetzelfde zijn als de bron-app en controleer uw configuratie.
6. 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