Migrazione a ambiente del servizio app v3 usando la funzionalità di migrazione side-by-side

  • Articolo

Nota

La funzionalità di migrazione descritta in questo articolo viene usata per la migrazione automatica side-by-side (subnet diversa) di ambiente del servizio app v2 a ambiente del servizio app v3.

Per informazioni sulla funzionalità di migrazione sul posto, vedere Eseguire la migrazione a ambiente del servizio app v3 usando la funzionalità di migrazione sul posto. Per informazioni sulle opzioni di migrazione manuale, vedere Opzioni di migrazione manuale. Per informazioni sulla scelta dell'opzione di migrazione più adatta, vedere Albero delle decisioni del percorso di migrazione. Per altre informazioni su ambiente del servizio app v3, vedere panoramica di ambiente del servizio app v3.

servizio app può automatizzare la migrazione dei ambiente del servizio app v1 e v2 a un ambiente del servizio app v3. Sono disponibili diverse opzioni di migrazione. Esaminare l'albero delle decisioni del percorso di migrazione per decidere quale opzione è migliore per il caso d'uso. ambiente del servizio app v3 offre vantaggi e differenze di funzionalità rispetto alle versioni precedenti. Assicurarsi di esaminare le funzionalità supportate di ambiente del servizio app v3 prima della migrazione per ridurre il rischio di un problema imprevisto dell'applicazione.

La funzionalità di migrazione side-by-side automatizza la migrazione a ambiente del servizio app v3. La funzionalità di migrazione side-by-side crea una nuova ambiente del servizio app v3 con tutte le app in una subnet diversa. L'ambiente del servizio app esistente non viene eliminata fino a quando non si avvia l'eliminazione alla fine del processo di migrazione. A causa di questo processo, è disponibile un'opzione di rollback se è necessario annullare la migrazione. Questa opzione di migrazione è ideale per i clienti che vogliono eseguire la migrazione a ambiente del servizio app v3 senza tempi di inattività e possono supportare l'uso di una subnet diversa per il nuovo ambiente. Se è necessario usare la stessa subnet e supportare circa un'ora di inattività dell'applicazione, vedere la funzionalità di migrazione sul posto. Per le opzioni di migrazione manuale che consentono di eseguire la migrazione in base al proprio ritmo, vedere Opzioni di migrazione manuale.

Importante

È consigliabile usare questa funzionalità per gli ambienti di sviluppo prima di eseguire la migrazione di tutti gli ambienti di produzione per assicurarsi che non siano presenti problemi imprevisti. Fornire commenti e suggerimenti relativi a questo articolo o alla funzionalità usando i pulsanti nella parte inferiore della pagina.

Scenari supportati

Al momento, la funzionalità di migrazione side-by-side non supporta le migrazioni a ambiente del servizio app v3 nelle aree seguenti:

Pubblico di Azure

  • Emirati Arabi Uniti centrali

Azure Government

  • US DoD Central
  • US DoD East
  • US Gov Arizona
  • US Gov Texas
  • US Gov Virginia

Microsoft Azure gestito da 21Vianet

  • Cina orientale 2
  • Cina settentrionale 2

È possibile eseguire la migrazione delle configurazioni di ambiente del servizio app seguenti usando la funzionalità di migrazione side-by-side. La tabella fornisce la configurazione ambiente del servizio app v3 quando si usa la funzionalità di migrazione side-by-side in base all'ambiente del servizio app esistente.

Impostazione Configurazione di ambiente del servizio app v3
Bilanciamento del carico interno (ILB) ambiente del servizio app v2 ILB ambiente del servizio app v3
Esterno (ELB/Internet con indirizzo IP pubblico) ambiente del servizio app v2 ELB ambiente del servizio app v3
ILB ambiente del servizio app v2 con un suffisso di dominio personalizzato ILB ambiente del servizio app v3 con un suffisso di dominio personalizzato

ambiente del servizio app v3 può essere distribuito come ridondanza della zona. La ridondanza della zona può essere abilitata purché il ambiente del servizio app v3 si trova in un'area che supporta la ridondanza della zona.

Se si vuole che il nuovo ambiente del servizio app v3 usi un suffisso di dominio personalizzato e non si usi attualmente un suffisso di dominio personalizzato, è possibile configurare il suffisso di dominio personalizzato in qualsiasi momento al termine della migrazione. Per altre informazioni, vedere Configurare il suffisso di dominio personalizzato per ambiente del servizio app. Se l'ambiente esistente ha un suffisso di dominio personalizzato e non si vuole più usarlo, è necessario configurare un suffisso di dominio personalizzato per la migrazione. È possibile rimuovere il suffisso di dominio personalizzato al termine della migrazione.

Limitazioni delle funzionalità di migrazione side-by-side

Di seguito sono riportate alcune limitazioni quando si usa la funzionalità di migrazione side-by-side:

  • Il nuovo ambiente del servizio app v3 si trova in una subnet diversa, ma la stessa rete virtuale dell'ambiente esistente.
  • Non è possibile modificare l'area in cui si trova l'ambiente del servizio app.
  • Non è possibile eseguire la migrazione di un ambiente del servizio app ELB in un ambiente del servizio app v3 ILB e viceversa.
  • Se l'ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurare il suffisso di dominio personalizzato per l'ambiente del servizio app v3 durante il processo di migrazione.
    • Se non si vuole più usare un suffisso di dominio personalizzato, è possibile rimuoverlo al termine della migrazione.
  • La funzionalità di migrazione side-by-side è disponibile solo tramite l'interfaccia della riga di comando o tramite l'API REST. La funzionalità non è disponibile nella portale di Azure.

ambiente del servizio app v3 non supporta le funzionalità seguenti che è possibile usare con l'ambiente del servizio app v2 corrente.

  • Configurazione di un'associazione TLS/SSL basata su IP con le app.
  • L'ambiente del servizio app v3 non esegue il fallback in DNS di Azure se i server DNS personalizzati configurati nella rete virtuale non riescono a risolvere un dato nome. Se questo comportamento è necessario, assicurarsi di disporre di un server d'inoltro a un DNS pubblico o di includere DNS di Azure nell'elenco dei server DNS personalizzati.

La funzionalità di migrazione side-by-side non supporta gli scenari seguenti. Vedere le opzioni di migrazione manuale se il ambiente del servizio app rientra in una di queste categorie.

  • ambiente del servizio app v1
    • È possibile trovare la versione del ambiente del servizio app passando al ambiente del servizio app nella portale di Azure e selezionando Configurazione in Impostazioni sul lato sinistro. È anche possibile usare Esplora risorse di Azure ed esaminare il valore della proprietà per il kind ambiente del servizio app.
    • Se si dispone di un ambiente del servizio app v1, è possibile eseguire la migrazione usando la funzionalità di migrazione sul posto o una delle opzioni di migrazione manuale.
  • Ambiente del servizio app v2 ELB con indirizzi IP SSL
  • Zona aggiunta ambiente del servizio app v2

La piattaforma servizio app esamina i ambiente del servizio app per confermare il supporto della migrazione side-by-side. Se lo scenario non supera tutti i controlli di convalida, non è possibile eseguire la migrazione in questo momento usando la funzionalità di migrazione side-by-side. Se l'ambiente è in uno stato non integro o sospeso, non è possibile eseguire la migrazione fino a quando non si apportano gli aggiornamenti necessari.

Nota

ambiente del servizio app v3 non supporta SSL IP. Se si usa SSL IP, è necessario rimuovere tutte le associazioni SSL IP prima di eseguire la migrazione a ambiente del servizio app v3. La funzionalità di migrazione supporterà l'ambiente dopo la rimozione di tutte le associazioni IP SSL.

Risoluzione dei problemi

Se il ambiente del servizio app non supera i controlli di convalida o si tenta di eseguire un passaggio di migrazione nell'ordine non corretto, viene visualizzato uno dei messaggi di errore seguenti:

Error message Descrizione Elemento consigliato
La migrazione può essere chiamata solo in una rete virtuale A edizione Standard nella rete virtuale arm e questa edizione Standard si trova nella rete virtuale classica. ambiente del servizio app nelle reti virtuali classiche non possono eseguire la migrazione tramite la funzionalità di migrazione side-by-side. Eseguire la migrazione usando una delle opzioni di migrazione manuale.
La migrazione a edizione Standard v3 non è ancora pronta. L'infrastruttura sottostante non è pronta per supportare ambiente del servizio app v3. Eseguire la migrazione usando una delle opzioni di migrazione manuale se si vuole eseguire immediatamente la migrazione. In caso contrario, attendere che la funzionalità di migrazione side-by-side sia disponibile nell'area.
Impossibile abilitare la ridondanza della zona per questo oggetto A edizione Standard. L'area in cui si trova il ambiente del servizio app non supporta la ridondanza della zona. Se è necessario abilitare la ridondanza della zona, usare una delle opzioni di migrazione manuale per eseguire la migrazione a un'area che supporta la ridondanza della zona.
Impossibile chiamare la migrazione su questo suffisso DNS personalizzato A edizione Standard al momento. La migrazione del suffisso di dominio personalizzato è bloccata. Aprire un caso di supporto per contattare il supporto per risolvere il problema.
Al momento non è possibile chiamare la migrazione con ridondanza della zona A edizione Standard. La migrazione con ridondanza della zona ambiente del servizio app è bloccata. Aprire un caso di supporto per contattare il supporto per risolvere il problema.
Non è possibile chiamare la migrazione in A edizione Standard v2 bloccata dall'area. ambiente del servizio app versione 2 non è possibile eseguire la migrazione tramite la funzionalità di migrazione side-by-side in questo momento. Eseguire la migrazione usando una delle opzioni di migrazione manuale se si vuole eseguire immediatamente la migrazione.
Operazione di ripristino esistente in corso. Riprovare più tardi. Viene ripristinato un tentativo di migrazione precedente. Attendere il completamento del ripristino in corso prima di tentare di riavviare la migrazione.
Properties.VirtualNetwork.Id deve contenere l'ID risorsa della subnet. L'errore viene visualizzato se si tenta di eseguire la migrazione senza fornire una nuova subnet per il posizionamento del ambiente del servizio app v3. Assicurarsi di seguire le indicazioni e completare il passaggio per identificare la subnet da usare per il ambiente del servizio app v3.
Non è possibile passare <requested phase> dalla fase <previous phase> corrente della migrazione senza tempi di inattività. Questo errore viene visualizzato se si tenta di eseguire un passaggio di migrazione nell'ordine non corretto. Assicurarsi di seguire i passaggi di migrazione in ordine.
Impossibile avviare l'operazione di ripristino in A edizione Standard in stato ibrido. Riprovare più tardi. Questo errore viene visualizzato se si tenta di ripristinare la migrazione, ma si verifica un errore. Questo errore non influisce sul vecchio o sul nuovo ambiente. Aprire un caso di supporto per contattare il supporto per risolvere il problema.
Non è possibile eseguire la migrazione di questo oggetto A edizione Standard senza tempi di inattività. Questo errore viene visualizzato se si tenta di usare la funzionalità di migrazione side-by-side in un ambiente del servizio app v1. La funzionalità di migrazione side-by-side non supporta ambiente del servizio app v1. Eseguire la migrazione tramite la funzionalità di migrazione sul posto o una delle opzioni di migrazione manuale.
La migrazione non è disponibile per questa sottoscrizione. Il supporto deve essere impegnato per la migrazione di questa ambiente del servizio app. Aprire un caso di supporto per contattare il supporto per risolvere il problema.
Non è possibile chiamare la migrazione con ridondanza della zona perché gli indirizzi IP creati durante la pre-migrazione non sono ridondanti della zona. Questo errore viene visualizzato se si tenta una migrazione con ridondanza della zona ma non sono stati creati indirizzi IP con ridondanza della zona durante il passaggio di generazione IP. Aprire un caso di supporto per contattare il supporto se è necessario abilitare la ridondanza della zona. In caso contrario, è possibile eseguire la migrazione senza abilitare la ridondanza della zona.
Non è possibile chiamare la migrazione se IP SSL è abilitato in uno dei siti. ambiente del servizio app che dispongono di siti con SSL IP abilitato non possono essere migrati usando la funzionalità di migrazione side-by-side. Rimuovere l'SSL IP da tutte le app nel ambiente del servizio app per abilitare la funzionalità di migrazione.
Impossibile eseguire la migrazione all'interno della stessa subnet. L'errore viene visualizzato se si specifica la stessa subnet in cui si trova l'ambiente corrente per il posizionamento del ambiente del servizio app v3. È necessario specificare una subnet diversa per il ambiente del servizio app v3. Se è necessario usare la stessa subnet, eseguire la migrazione usando la funzionalità di migrazione sul posto.
La sottoscrizione ha troppi ambiente del servizio app. Rimuovere alcuni prima di provare a crearne altri. Viene soddisfatta la quota ambiente del servizio app per la sottoscrizione. Rimuovere gli ambienti non necessario o contattare il supporto tecnico per esaminare le opzioni.
Non è possibile chiamare la migrazione in questo oggetto A edizione Standard fino al termine dell'aggiornamento attivo. non è possibile eseguire la migrazione di ambiente del servizio app durante gli aggiornamenti della piattaforma. È possibile impostare le preferenze di aggiornamento nel portale di Azure. In alcuni casi, viene avviato un aggiornamento quando si visita la pagina di migrazione se l'ambiente del servizio app non è aggiornato alla build corrente. Attendere il completamento dell'aggiornamento e quindi eseguire la migrazione.
ambiente del servizio app'operazione di gestione in corso. Il ambiente del servizio app è in corso un'operazione di gestione. Queste operazioni possono includere attività quali distribuzioni o aggiornamenti. La migrazione è bloccata fino al completamento di queste operazioni. È possibile eseguire la migrazione al termine di queste operazioni.
InteralLoadBalancingMode non è attualmente supportato. ambiente del servizio app che hanno InternalLoadBalancingMode impostato su determinati valori non possono essere migrati usando la funzionalità di migrazione in questo momento. InternalLoadBalancingMode deve essere modificato manualmente dal team Microsoft. Aprire un caso di supporto per contattare il supporto per risolvere il problema. Richiedere un aggiornamento a InternalLoadBalancingMode per consentire la migrazione.
La migrazione non è valida. L edizione Standard A deve essere aggiornato alla build più recente per garantire la corretta migrazione. L'A edizione Standard verrà aggiornato ora. Riprovare a eseguire la migrazione in poche ore al termine dell'aggiornamento della piattaforma. Il ambiente del servizio app non è sulla build minima necessaria per la migrazione. Viene avviato un aggiornamento. Il ambiente del servizio app non sarà interessato, ma non sarà possibile ridimensionare o apportare modifiche al ambiente del servizio app mentre è in corso l'aggiornamento. Non sarà possibile eseguire la migrazione fino al termine dell'aggiornamento. Attendere il completamento dell'aggiornamento e quindi eseguire la migrazione.
Non è possibile chiamare la migrazione completa prima che vengano generati indirizzi IP. Questo errore viene visualizzato se si tenta di eseguire la migrazione prima di completare i passaggi di premigration. Assicurarsi di completare tutti i passaggi di premigration prima di tentare di eseguire la migrazione. Vedere la guida dettagliata per la migrazione.
Non è possibile chiamare la migrazione completa nell'ambiente del servizio app con il suffisso dns personalizzato impostato, ma senza una configurazione del suffisso DNS personalizzato aseV3 configurata. Il ambiente del servizio app esistente usa un suffisso di dominio personalizzato. È necessario configurare il suffisso di dominio personalizzato per il ambiente del servizio app v3 durante il processo di migrazione. Configurare un suffisso di dominio personalizzato. Se non si vuole più usare un suffisso di dominio personalizzato, è possibile rimuoverlo al termine della migrazione.

Panoramica del processo di migrazione tramite la funzionalità di migrazione side-by-side

La migrazione side-by-side è costituita da una serie di passaggi che devono essere seguiti in ordine. Per determinati passaggi vengono fornite informazioni essenziali. È importante comprendere cosa accade durante questi passaggi e quale impatto hanno sull'ambiente e sulle app. Dopo aver consultato le informazioni seguenti, quando si è pronti a eseguire la migrazione, attenersi alla guida dettagliata.

Verificare che la migrazione sia supportata usando la funzionalità di migrazione side-by-side per il ambiente del servizio app

La piattaforma verifica che sia possibile eseguire la migrazione dei ambiente del servizio app usando la funzionalità di migrazione side-by-side. Se il ambiente del servizio app non supera tutti i controlli di convalida, non è possibile eseguire la migrazione in questo momento usando la funzionalità di migrazione side-by-side. Per informazioni dettagliate sulle possibili cause dell'errore di convalida, vedere la sezione relativa alla risoluzione dei problemi . Se l'ambiente è in uno stato non integro o sospeso, non è possibile eseguire la migrazione fino a quando non si apportano gli aggiornamenti necessari. Se non è possibile eseguire la migrazione tramite la funzionalità di migrazione side-by-side, vedere le opzioni di migrazione manuale.

La convalida controlla anche se il ambiente del servizio app è sulla build minima necessaria per la migrazione. La build minima viene aggiornata periodicamente per assicurarsi che siano disponibili le correzioni di bug e i miglioramenti più recenti. Se il ambiente del servizio app non è nella build minima, è necessario avviare l'aggiornamento manualmente. Questo aggiornamento è un processo standard in cui il ambiente del servizio app non è interessato, ma non è possibile ridimensionare o apportare modifiche al ambiente del servizio app mentre è in corso l'aggiornamento. Non è possibile eseguire la migrazione fino al termine dell'aggiornamento. Il completamento o la durata degli aggiornamenti può richiedere 8-12 ore a seconda delle dimensioni dell'ambiente. Se si pianifica un intervallo di tempo specifico per la migrazione, è necessario eseguire il controllo di convalida 24-48 ore prima del tempo di migrazione pianificato per assicurarsi di avere tempo per un aggiornamento, se necessario.

Selezionare e preparare la subnet per il nuovo ambiente del servizio app v3

La piattaforma crea il nuovo ambiente del servizio app v3 in una subnet diversa rispetto all'ambiente del servizio app esistente. È necessario selezionare una subnet che soddisfi i requisiti seguenti:

  • La subnet deve trovarsi nella stessa rete virtuale e quindi nell'area del ambiente del servizio app esistente.
    • Se la rete virtuale non ha una subnet disponibile, è necessario crearne una. Potrebbe essere necessario aumentare lo spazio degli indirizzi della rete virtuale per creare una nuova subnet. Per altre informazioni, vedere Creare una rete virtuale.
  • La subnet deve essere in grado di comunicare con la subnet in cui si trova il ambiente del servizio app esistente. Assicurarsi che non siano presenti gruppi di sicurezza di rete o altre configurazioni di rete che impediscono la comunicazione tra le subnet.
  • La subnet deve avere una singola delega di Microsoft.Web/hostingEnvironments.
  • La subnet deve avere un numero sufficiente di indirizzi IP disponibili per supportare il nuovo ambiente del servizio app v3. Il numero di indirizzi IP necessari dipende dal numero di istanze da usare per il nuovo ambiente del servizio app v3. Per ulteriori informazioni, vedere Rete per l'ambiente del servizio app v3.
  • Alla subnet non devono essere applicati blocchi. Se sono presenti blocchi, è necessario rimuoverli prima della migrazione. I blocchi possono essere letti se necessario al termine della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà dei blocchi, vedere Bloccare le risorse per proteggere l'infrastruttura.
  • Non devono essere presenti criteri di Azure che bloccano la migrazione o le azioni correlate. Se sono presenti criteri che bloccano la creazione di ambiente del servizio app o la modifica delle subnet, devono essere rimossi prima della migrazione. I criteri possono essere letti se necessario al termine della migrazione. Per altre informazioni sulle Criteri di Azure, vedere panoramica di Criteri di Azure.

Generare indirizzi IP in uscita per il nuovo ambiente del servizio app v3

La piattaforma crea i nuovi indirizzi IP in uscita. L'attività dell'ambiente del servizio app esistente non verrà interrotta durante la creazione di questi IP, tuttavia non sarà possibile ridimensionare o modificare l'ambiente esistente. Il completamento di questo processo richiede circa 15 minuti.

Al termine, vengono creati i nuovi indirizzi IP in uscita che verranno creati in futuro ambiente del servizio app v3. Questi nuovi IP non hanno alcun effetto sull'ambiente esistente.

Al termine della migrazione si riceve il nuovo indirizzo IP in ingresso, ma prima di apportare la modifica DNS per reindirizzare il traffico dei clienti al nuovo ambiente del servizio app v3. Non si ottiene l'indirizzo IP in ingresso a questo punto del processo perché esistono dipendenze da ambiente del servizio app risorse v3 create durante il passaggio di migrazione. È possibile aggiornare tutte le risorse dipendenti dal nuovo indirizzo IP in ingresso prima di reindirizzare il traffico al nuovo ambiente del servizio app v3.

Questo passaggio è anche il punto in cui si decide se si vuole abilitare la ridondanza della zona per il nuovo ambiente del servizio app v3. La ridondanza della zona può essere abilitata purché il ambiente del servizio app v3 si trova in un'area che supporta la ridondanza della zona.

Aggiornare le risorse dipendenti con nuovi indirizzi IP in uscita

I nuovi indirizzi IP in uscita vengono creati e assegnati prima di avviare la migrazione effettiva. Vengono fornite le nuove connessioni in uscita predefinite per gli indirizzi pubblici Internet, in modo da poter modificare qualsiasi firewall esterno, routing DNS, gruppi di sicurezza di rete e qualsiasi altra risorsa che si basa su questi indirizzi IP prima di completare la migrazione. È responsabilità dell'utente aggiornare tutte le risorse interessate dalla modifica dell'indirizzo IP associata al nuovo ambiente del servizio app v3. Non passare al passaggio successivo fino a quando non sono stati eseguiti tutti gli aggiornamenti necessari. È possibile che si verifichino tempi di inattività dopo il passaggio di migrazione se si hanno dipendenze dagli indirizzi IP in uscita e non è possibile eseguire tutti gli aggiornamenti necessari. Ciò è dovuto al completamento della migrazione, anche se il traffico passa ancora al front-end ambiente del servizio app v2, il calcolo sottostante è il nuovo ambiente del servizio app v3.

Questo passaggio è anche un buon momento per esaminare le modifiche alle dipendenze di rete in ingresso e in uscita quando si passa a ambiente del servizio app v3, inclusa la modifica della porta per il probe di integrità di Azure Load Balancer, che ora usa la porta 80.

Delegare la subnet ambiente del servizio app

ambiente del servizio app v3 richiede che la subnet in cui si trova abbia una singola delega di Microsoft.Web/hostingEnvironments. La migrazione non riesce se la subnet del ambiente del servizio app non è delegata o la si delega a una risorsa diversa. Assicurarsi che la subnet selezionata per il nuovo ambiente del servizio app v3 disponga di una singola delega di Microsoft.Web/hostingEnvironments.

Confermare le modifiche delle dimensioni istanza

I piani di servizio app vengono creati con lo SKU Isolated v2 corrispondente come parte della migrazione. Ad esempio, i piani I2 corrispondono a I2v2. Le app potrebbero essere sottoposte a provisioning eccessivo dopo la migrazione perché il livello Isolated v2 ha più memoria e CPU per ogni dimensione di istanza corrispondente. Al termine della migrazione, è possibile ridimensionare l'ambiente in base alle esigenze. Per altre informazioni, vedere i dettagli dello SKU.

Assicurarsi che non siano presenti blocchi sulle risorse

I blocchi della rete virtuale bloccano le operazioni della piattaforma durante la migrazione. Se la rete virtuale ha blocchi, è necessario rimuoverli prima della migrazione. I blocchi possono essere letti se necessario al termine della migrazione. I blocchi possono esistere in tre ambiti diversi: sottoscrizione, gruppo di risorse e risorsa. Quando si applica un blocco in un ambito padre, tutte le risorse in tale ambito ereditano lo stesso blocco. Se sono stati applicati blocchi nella sottoscrizione, nel gruppo di risorse o nell'ambito delle risorse, è necessario rimuoverli prima della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà dei blocchi, vedere Bloccare le risorse per proteggere l'infrastruttura.

Assicurarsi che non siano presenti criteri di Azure che bloccano la migrazione

Criteri di Azure può essere usato per negare la creazione e la modifica delle risorse a determinate entità. Se si dispone di un criterio che blocca la creazione di ambiente del servizio app o la modifica delle subnet, è necessario rimuoverlo prima della migrazione. I criteri possono essere letti se necessario al termine della migrazione. Per altre informazioni sulle Criteri di Azure, vedere panoramica di Criteri di Azure.

Aggiungere un suffisso di dominio personalizzato (facoltativo)

Se il ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurare un suffisso di dominio personalizzato per il nuovo ambiente del servizio app v3. Il suffisso di dominio personalizzato in ambiente del servizio app v3 viene implementato in modo diverso rispetto a ambiente del servizio app v2. È necessario specificare il nome di dominio personalizzato, l'identità gestita e il certificato, che devono essere archiviati in Azure Key Vault. Per altre informazioni su ambiente del servizio app suffisso di dominio personalizzato v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Configurare il suffisso di dominio personalizzato per ambiente del servizio app. Se il ambiente del servizio app v2 ha un suffisso di dominio personalizzato, è necessario configurare un suffisso di dominio personalizzato per il nuovo ambiente anche se non si vuole più usarlo. Al termine della migrazione, è possibile rimuovere la configurazione del suffisso di dominio personalizzato, se necessario.

Se la migrazione include un suffisso di dominio personalizzato, per ambiente del servizio app v3, il dominio personalizzato non viene visualizzato nella sezione Informazioni di base della pagina Panoramica del portale perché è per ambiente del servizio app v1/v2. Per ambiente del servizio app v3 passare invece alla pagina Suffisso di dominio personalizzato in cui è possibile verificare che il suffisso di dominio personalizzato sia configurato correttamente. Inoltre, in ambiente del servizio app v2, se si dispone di un suffisso di dominio personalizzato, il nome host predefinito include il suffisso di dominio personalizzato ed è nel formato APP-NAME.internal.contoso.com. In ambiente del servizio app v3, il nome host predefinito usa sempre il suffisso di dominio predefinito ed è nel formato APP-NAME. A edizione Standard-NAME.appserviceenvironment.net. Questa differenza è dovuta al fatto che ambiente del servizio app v3 mantiene il suffisso di dominio predefinito quando si aggiunge un suffisso di dominio personalizzato. Con ambiente del servizio app v2, è presente un solo suffisso di dominio.

Eseguire la migrazione all'ambiente del servizio app di Azure v3

Dopo aver completato i passaggi precedenti, è consigliabile continuare con la migrazione il prima possibile.

Non si verificano tempi di inattività dell'applicazione durante la migrazione, ma come nel passaggio di generazione IP, non è possibile ridimensionare, modificare l'ambiente del servizio app esistente o distribuirvi le app durante questo processo.

Importante

Poiché il ridimensionamento è bloccato durante la migrazione, è necessario ridimensionare l'ambiente in base alle dimensioni desiderate prima di avviare la migrazione.

La migrazione side-by-side richiede una finestra del servizio da tre a sei ore per le migrazioni da ambiente del servizio app v2 a v3. Durante la migrazione, la scalabilità e le configurazioni dell'ambiente sono bloccate e si verificano gli eventi seguenti:

  • La nuova ambiente del servizio app v3 viene creata nella subnet selezionata.
  • I nuovi piani di servizio app vengono creati nel nuovo ambiente del servizio app v3 con il livello Isolated v2 corrispondente.
  • Le app vengono create nella nuova ambiente del servizio app v3.
  • Il calcolo sottostante per le app viene spostato nel nuovo ambiente del servizio app v3. I front-end ambiente del servizio app v2 continuano a gestire il traffico. L'indirizzo IP in ingresso precedente rimane in uso.
    • Per le ambiente del servizio app il bilanciamento del carico interno, i front-end ambiente del servizio app v3 non vengono usati fino a quando non si aggiornano le zone DNS private con il nuovo indirizzo IP in ingresso.
    • Per i ambiente del servizio app ELB, il processo di migrazione non reindirizza il traffico ai front-end ambiente del servizio app v3 fino a quando non si completa il passaggio finale della migrazione.

Al termine di questo passaggio, il traffico dell'applicazione continuerà a raggiungere i front-end precedenti ambiente del servizio app v2 e l'INDIRIZZO IP in ingresso assegnato. Tuttavia, ora hai anche un ambiente del servizio app v3 con tutte le tue app.

Ottenere l'indirizzo IP in ingresso per la nuova ambiente del servizio app v3 e aggiornare le risorse dipendenti

Il nuovo indirizzo IP in ingresso viene fornito in modo da poter configurare nuovi endpoint con servizi come Gestione traffico o Frontdoor di Azure e aggiornare una delle zone DNS private. Non passare al passaggio successivo fino a quando non si apportano queste modifiche. Si verifica un tempo di inattività se non si aggiornano le risorse dipendenti con il nuovo indirizzo IP in ingresso. È responsabilità dell'utente aggiornare tutte le risorse interessate dalla modifica dell'indirizzo IP associata al nuovo ambiente del servizio app v3. Non passare al passaggio successivo fino a quando non sono stati eseguiti tutti gli aggiornamenti necessari.

Reindirizzare il traffico dei clienti, convalidare il ambiente del servizio app v3 e completare la migrazione

Il passaggio finale consiste nel reindirizzare il traffico al nuovo ambiente del servizio app v3 e completare la migrazione. La piattaforma esegue questa modifica per l'utente, ma solo quando viene avviata. Prima di eseguire questo passaggio, è necessario esaminare il nuovo ambiente del servizio app v3 ed eseguire i test necessari per verificare che funzioni come previsto. Per impostazione predefinita, il traffico passa al front-end ambiente del servizio app v2. Se si usa un servizio di bilanciamento del carico interno ambiente del servizio app v3, è possibile testare il front-end ambiente del servizio app v3 aggiornando la zona DNS privata con il nuovo indirizzo IP in ingresso. Se si usa un ambiente del servizio app ELB v3, il processo per il test dipende dalla configurazione di rete specifica. Un metodo semplice per testare gli ambienti ELB consiste nell'aggiornare il file host per usare il nuovo indirizzo IP in ingresso ambiente del servizio app v3. Se sono stati assegnati domini personalizzati alle singole app, in alternativa è possibile aggiornare il DNS in modo che punti al nuovo INDIRIZZO IP in ingresso. Il test di questa modifica consente di convalidare completamente il ambiente del servizio app v3 prima di avviare il passaggio finale della migrazione in cui viene eliminato il ambiente del servizio app precedente.

Quando si è pronti per reindirizzare il traffico, è possibile completare il passaggio finale della migrazione. Questo passaggio aggiorna i record DNS interni in modo che puntino all'indirizzo IP del servizio di bilanciamento del carico del nuovo ambiente del servizio app v3 e ai front-end creati durante la migrazione. Le modifiche sono effettive entro un paio di minuti. In caso di problemi, controllare le impostazioni della cache e della durata (TTL). Questo passaggio arresta anche l'ambiente del servizio app precedente ed elimina l'ambiente del servizio app. Il nuovo ambiente del servizio app v3 è ora l'ambiente di produzione.

Nota

Per completare questo passaggio sono disponibili 14 giorni. Se questo passaggio non viene completato in 14 giorni, la migrazione viene ripristinata automaticamente a un ambiente del servizio app v2. Se sono necessari più di 14 giorni per completare questo passaggio, contattare il supporto tecnico.

Se si rilevano problemi con il nuovo ambiente del servizio app v3, non eseguire il comando per reindirizzare il traffico dei clienti. Questo comando avvia anche l'eliminazione del ambiente del servizio app v2. Se si verifica un problema, è possibile ripristinare tutte le modifiche e tornare al ambiente del servizio app versione 2 precedente. Il completamento del processo di ripristino richiede da 3 a 6 ore. Non sono previsti tempi di inattività associati a questo processo. Al termine del processo di ripristino, il vecchio ambiente del servizio app torna online e il nuovo ambiente del servizio app v3 viene eliminato. È quindi possibile tentare di nuovo la migrazione dopo aver risolto eventuali problemi.

Prezzi

Non è previsto alcun costo per la migrazione dell'ambiente del servizio app. Tuttavia, vengono fatturati sia il ambiente del servizio app v2 che il nuovo ambiente del servizio app v3 dopo aver avviato il processo di migrazione. Quando si completa il passaggio finale della migrazione in cui viene aggiornato il DNS e l'ambiente precedente viene eliminato, si interrompe l'addebito per il vecchio ambiente del servizio app v2. È consigliabile completare la convalida il più rapidamente possibile per evitare che gli addebiti in eccesso vengano accumulati. Per ulteriori informazioni sui prezzi dell'ambiente del servizio app, vedere i dettagli sui prezzi.

Quando si esegue la migrazione a ambiente del servizio app v3 dalle versioni precedenti, esistono scenari da considerare che possono potenzialmente ridurre il costo mensile. Prendere in considerazione le prenotazioni e i piani di risparmio per ridurre ulteriormente i costi. Per informazioni sulle opportunità di risparmio sui costi, vedere Opportunità di risparmio dei costi dopo l'aggiornamento a ambiente del servizio app v3.

Nota

A causa delle differenze tra i piani tariffari Isolated to Isolated v2, le app potrebbero essere sottoposte a provisioning eccessivo dopo la migrazione poiché il livello Isolated v2 ha più memoria e CPU per ogni dimensione di istanza corrispondente. Al termine della migrazione, sarà possibile ridimensionare l'ambiente in base alle esigenze. Per altre informazioni, vedere i dettagli dello SKU.

Ridurre i piani di servizio app

Gli SKU del piano servizio app disponibili per ambiente del servizio app v3 vengono eseguiti nel livello Isolated v2 (Iv2). Il numero di core e la quantità di RAM vengono effettivamente raddoppiati per ogni livello corrispondente rispetto al livello isolato. Quando si esegue la migrazione, i piani di servizio app vengono convertiti nel livello corrispondente. Ad esempio, le istanze I2 vengono convertite in I2v2. Mentre I2 ha due core e 7 GB di RAM, I2v2 ha quattro core e 16 GB di RAM. Se si prevede che i requisiti di capacità rimangano invariati, si esegue il provisioning eccessivo e si paga per il calcolo e la memoria che non si sta usando. Per questo scenario, è possibile ridurre l'istanza di I2v2 in I1v2 e terminare con un numero simile di core e RAM precedentemente disponibili.

Domande frequenti

  • Cosa accade se la migrazione del ambiente del servizio app non è attualmente supportata?
    Al momento non è possibile eseguire la migrazione tramite la funzionalità di migrazione side-by-side. Se si dispone di un ambiente non supportato e si vuole eseguire immediatamente la migrazione, vedere le opzioni di migrazione manuale.
  • Ricerca per categorie scegliere quale opzione di migrazione è adatta?
    Esaminare l'albero delle decisioni del percorso di migrazione per decidere quale opzione è migliore per il caso d'uso.
  • Ricerca per categorie sapere se è consigliabile usare la funzionalità di migrazione side-by-side?
    La funzionalità di migrazione side-by-side è ideale per i clienti che vogliono eseguire la migrazione a ambiente del servizio app v3, ma non possono supportare i tempi di inattività dell'applicazione. Poiché viene usata una nuova subnet per il nuovo ambiente, è necessario tenere presenti considerazioni sulla rete, inclusi i nuovi indirizzi IP. Se è possibile supportare il tempo di inattività, vedere la funzionalità di migrazione sul posto, che comporta modifiche minime alla configurazione o le opzioni di migrazione manuale. La funzionalità di migrazione sul posto crea il ambiente del servizio app v3 nella stessa subnet dell'ambiente esistente e usa la stessa infrastruttura di rete.
  • Durante la migrazione vi sarà un periodo di inattività?
    No, non si verificano tempi di inattività durante il processo di migrazione side-by-side. Le app continuano a essere eseguite nell'ambiente del servizio app esistente fino a quando non si completa immediatamente il passaggio finale della migrazione in cui le modifiche DNS sono effettive. Dopo aver completato il passaggio finale, la vecchia ambiente del servizio app viene arrestata ed eliminata. Il nuovo ambiente del servizio app v3 è ora l'ambiente di produzione.
  • Sarà necessario eseguire qualsiasi operazione alle app dopo la migrazione per eseguirle nella nuova ambiente del servizio app?
    No, tutte le app in esecuzione nell'ambiente precedente vengono automaticamente migrate nel nuovo ambiente ed eseguite come in precedenza. Non è necessario alcun input dell'utente.
  • Cosa accade se l'ambiente del servizio app presenta un suffisso di dominio personalizzato?
    La funzionalità di migrazione side-by-side supporta questo scenario di migrazione.
  • Cosa succede se la ambiente del servizio app è bloccata?
    La funzionalità di migrazione side-by-side non supporta attualmente questo scenario di migrazione. Se è stata aggiunta una zona ambiente del servizio app e si vuole eseguire immediatamente la migrazione, vedere le opzioni di migrazione manuale.
  • Cosa succede se il ambiente del servizio app ha indirizzi IP SSL?
    IP SSL non è supportato in ambiente del servizio app v3. È necessario rimuovere tutte le associazioni SSL IP prima di eseguire la migrazione usando la funzionalità di migrazione o una delle opzioni manuali. Se si intende usare la funzionalità di migrazione side-by-side, dopo aver rimosso tutte le associazioni SSL IP, si passa tale controllo di convalida e si può procedere con la migrazione automatica.
  • Quali proprietà del ambiente del servizio app cambieranno?
    Si è in ambiente del servizio app v3, quindi assicurarsi di esaminare le funzionalità e le differenze di funzionalità rispetto alle versioni precedenti. Sia gli INDIRIZZI IP in ingresso che in uscita cambiano quando si usa la funzionalità di migrazione side-by-side. Notare che per l'ambiente del servizio app ELB, in precedenza vi era un singolo IP in ingresso e in uscita. Per l'ambiente del servizio app v3, sono separati. Per ulteriori informazioni, vedere Rete per l'ambiente del servizio app v3. Per un confronto completo delle versioni dell'ambiente del servizio app, vedere Confronto delle versioni dell'ambiente del servizio app.
  • Cosa accade se la migrazione ha esito negativo o si verifica un problema imprevisto durante la migrazione?
    Se si verifica un problema imprevisto, i team di supporto sono disponibili. È consigliabile eseguire la migrazione degli ambienti di sviluppo prima di toccare gli ambienti di produzione per ottenere informazioni sul processo di migrazione e vedere come influisce sui carichi di lavoro. Con la funzionalità di migrazione side-by-side, è possibile ripristinare tutte le modifiche in caso di problemi.
  • Cosa succede al mio vecchio ambiente del servizio app?
    Se si decide di eseguire la migrazione di un ambiente del servizio app usando la funzionalità di migrazione side-by-side, l'ambiente precedente viene usato fino al passaggio finale del processo di migrazione. Dopo aver completato il passaggio finale, l'ambiente precedente e tutte le app ospitate in esso vengono arrestate ed eliminate. L'ambiente precedente non è più accessibile. A questo punto non è possibile eseguire il rollback all'ambiente precedente.
  • Cosa accadrà alle risorse dell'ambiente del servizio app v1/v2 dopo il 31 agosto 2024?
    Dopo il 31 agosto 2024, se non si esegue la migrazione a ambiente del servizio app v3, i ambiente del servizio app v1/v2 e le app distribuite in essi non saranno più disponibili. L'ambiente del servizio app v1/v2 è ospitato nelle unità di scala del servizio app eseguite sull'architettura di Servizi Cloud (versione classica) che verrà ritirata il 31 agosto 2024. Per questo motivo, l'ambiente del servizio app v1/v2 non sarà più disponibile dopo tale data. Eseguire la migrazione all'ambiente del servizio app v3 per mantenere le app in esecuzione oppure salvare le risorse e i dati che si desidera mantenere o eseguirne il backup.

Passaggi successivi

Eseguire la migrazione del ambiente del servizio app a ambiente del servizio app v3 usando la funzionalità di migrazione side-by-side

rete ambiente del servizio app v3

Uso di un ambiente del servizio app v3

Suffisso di dominio personalizzato