Migrazione all'ambiente del servizio app v3 con la funzionalità di migrazione affiancata

Nota

La funzionalità di migrazione descritta in questo articolo viene usata per la migrazione automatica affiancata (subnet diversa) dall'ambiente del servizio app v2 all'ambiente del servizio app v3. Se non è stato richiesto un periodo di tolleranza di 30 giorni, vedere la panoramica del periodo di tolleranza, quindi richiedere un periodo di tolleranza passando al portale di Azure e visitando il pannello Migrazione per ogni ambiente del servizio app.

Per informazioni sulla funzionalità di migrazione sul posto, vedere Eseguire la migrazione all'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 sull'ambiente del servizio app v3, vedere Panoramica dell'ambiente del servizio app v3.

La migrazione affiancata presenta problematiche aggiuntive rispetto alla migrazione sul posto. Per i clienti che devono decidere tra le due opzioni, è consigliabile usare la migrazione sul posto perché richiede meno passaggi e presenta meno complessità. Se si decide di usare la migrazione affiancata, esaminare la sezione Origini comuni dei problemi durante la migrazione tramite la funzionalità di migrazione affiancata per evitare problemi comuni.

Il servizio app può automatizzare la migrazione dell'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 sia migliore per il caso d'uso. L'ambiente del servizio app v3 offre vantaggi e funzionalità diversi rispetto alle versioni precedenti. Assicurarsi di esaminare le funzionalità supportate dell'ambiente del servizio app v3 prima di eseguire la migrazione per ridurre il rischio di un problema imprevisto dell'applicazione.

La funzionalità di migrazione affiancata automatizza la migrazione all'ambiente del servizio app v3. La funzionalità di migrazione affiancata crea un nuovo ambiente del servizio app v3 con tutte le app in una subnet diversa. L'ambiente del servizio app esistente non viene eliminato finché non si avvia l'eliminazione alla fine del processo di migrazione. Questa opzione di migrazione è ideale per i clienti che vogliono eseguire la migrazione all'ambiente del servizio app v3 senza alcun tempo di inattività e possono supportare l'uso di una subnet diversa per il nuovo ambiente. Se è necessario usare la stessa subnet ed è possibile 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 seguendo i propri tempi, consultare le opzioni di migrazione manuale.

Importante

Se non vengono completati tutti i passaggi descritti in questa esercitazione si riscontrerà un tempo di inattività. Ad esempio, se non si aggiornano tutte le risorse dipendenti con i nuovi indirizzi IP o non si consente l'accesso a/dalla nuova subnet, ad esempio come nel caso dell'insieme di credenziali delle chiavi del suffisso del dominio personalizzato, si verificheranno tempo di inattività fino a quando questo problema non viene risolto.

È consigliabile usare questa funzionalità per gli ambienti di sviluppo prima di eseguire la migrazione di un ambiente di produzione per provare a eseguire il processo e assicurarsi che non ci siano problemi imprevisti. Inserire un feedback relativo a questo articolo o alla funzionalità usando i pulsanti nella parte inferiore della pagina.

Scenari supportati

Al momento, la funzionalità di migrazione affiancata non supporta le migrazioni all'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 dell'ambiente del servizio app seguenti usando la funzionalità di migrazione affiancata. La tabella fornisce la configurazione dell'ambiente del servizio app v3 quando si usa la funzionalità di migrazione affiancata in base all'ambiente del servizio app esistente.

Impostazione	Configurazione dell'ambiente del servizio app v3
Ambiente del servizio app v2 con bilanciamento del carico interno (ILB)	Ambiente del servizio app v3 con bilanciamento del carico interno
Ambiente del servizio app v2 esterno (ELB/Internet con indirizzo IP pubblico)	Ambiente del servizio app v3 ELB
Ambiente del servizio app v2 con bilanciamento del carico interno e con un suffisso di dominio personalizzato	Ambiente del servizio app v3 con bilanciamento del carico interno e con un suffisso di dominio personalizzato

L'ambiente del servizio app v3 può essere distribuito con ridondanza della zona. La ridondanza della zona può essere abilitata purché l'ambiente del servizio app v3 si trovi 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 se ne usa uno attualmente, il suffisso di dominio personalizzato può essere configurato in qualsiasi momento al termine della migrazione. Per altre informazioni, vedere Configurare il suffisso di dominio personalizzato per l'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 della funzionalità di migrazione affiancata

Di seguito sono riportate alcune limitazioni dell'uso della funzionalità di migrazione affiancata:

• Il nuovo ambiente del servizio app v3 si trova in una subnet diversa, ma nella 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 affiancata è disponibile solo tramite l'interfaccia della riga di comando o l'API REST. La funzionalità non è disponibile nel portale di Azure.

L'ambiente del servizio app v3 non supporta le funzionalità seguenti che l'utente potrebbe 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 affiancata non supporta gli scenari seguenti. Vedere le opzioni di migrazione manuale se l'ambiente del servizio app rientra in una di queste categorie.

• Ambiente del servizio app 1
  • È possibile trovare la versione dell'ambiente del servizio app in uso passando all'ambiente del servizio app nel portale di Azure e selezionando Configurazione in Impostazioni sul lato sinistro. È anche possibile usare Azure Resource Explorer ed esaminare il valore della proprietà kind per l'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
• Ambiente del servizio app v2 aggiunto alla zona
• Ambiente del servizio app con un nome che non soddisfa i limiti dei caratteri. L'intero nome, incluso il suffisso di dominio, deve contenere almeno 64 caratteri. Ad esempio: my-ase-name.appserviceenvironment.net per ILB e my-ase-name.p.azurewebsites.net per ELB devono essere composti da 64 caratteri o meno. Se non si soddisfa il limite di caratteri, è necessario eseguire la migrazione manualmente. I limiti dei caratteri specifici per il nome dell'ambiente del servizio app sono i seguenti:
  • Limite di caratteri del nome dell'ambiente del servizio app ILB: 36 caratteri
  • Limite di caratteri del nome dell'ambiente del servizio app ELB: 42 caratteri

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

Nota

L'ambiente del servizio app v3 non supporta IP SSL. Se si usa IP SSL, è necessario rimuovere tutte le associazioni IP SSL prima della migrazione all'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 l'ambiente del servizio app non supera i controlli di convalida o si tenta di eseguire un passaggio di migrazione non seguendo l'ordine corretto, viene visualizzato uno dei messaggi di errore seguenti:

Error message	Descrizione	Elemento consigliato
La migrazione può essere chiamata solo in un ambiente del servizio app nella rete virtuale di ARM e questo ambiente del servizio app si trova nella rete virtuale classica.	Gli ambienti del servizio app nelle reti virtuali classiche non possono eseguire la migrazione tramite la funzionalità di migrazione affiancata.	Eseguire la migrazione usando una delle opzioni di migrazione manuale.
La migrazione dell'ambiente del servizio app v3 non è ancora pronta.	L'infrastruttura sottostante non è pronta per supportare l'ambiente del servizio app v3.	Eseguire la migrazione usando una delle opzioni di migrazione manuale se si vuole eseguire immediatamente la migrazione. Altrimenti, attendere che la funzionalità di migrazione affiancata sia disponibile nell'area.
Non è possibile abilitare la ridondanza della zona per l'ambiente del servizio app in uso.	L'area in cui si trova l'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.
Al momento non è possibile chiamare la migrazione su questo ambiente del servizio app con suffisso DNS personalizzato.	La migrazione del suffisso del dominio personalizzato è bloccata.	Aprire un caso di supporto per contattare il supporto e risolvere il problema.
Al momento non è possibile chiamare la migrazione dell'ambiente del servizio app con ridondanza della zona.	La migrazione dell'ambiente del servizio app con ridondanza della zona è bloccata.	Aprire un caso di supporto per contattare il supporto e risolvere il problema.
Non è possibile chiamare la migrazione nell'ambiente del servizio app v2 aggiunto alla zona.	Al momento non è possibile eseguire la migrazione dell'ambiente del servizio app v2 aggiunto alla zona con la funzionalità di migrazione affiancata.	Eseguire la migrazione usando una delle opzioni di migrazione manuale se si vuole eseguire immediatamente la migrazione.
Operazione di ripristino della migrazione esistente in corso. Riprovare più tardi.	È in corso l'annullamento di 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 della risorsa della subnet.	L'errore viene visualizzato se si tenta di eseguire la migrazione senza fornire una nuova subnet per il posizionamento dell'ambiente del servizio app v3.	Assicurarsi di seguire le indicazioni e completare il passaggio per identificare la subnet che verrà usata per l'ambiente del servizio app v3.
Non è possibile passare a <requested phase> dalla fase attuale <previous phase> della migrazione senza tempi di inattività.	Questo errore viene visualizzato se si tenta di eseguire un passaggio di migrazione senza seguire l'ordine corretto.	Assicurarsi di seguire i passaggi di migrazione in ordine.
Non è stato possibile avviare l'operazione di ripristino nell'ambiente del servizio app 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 e risolvere il problema.
Non è possibile eseguire la migrazione dell'ambiente del servizio app senza tempo di inattività.	Questo errore viene visualizzato se si tenta di usare la funzionalità di migrazione affiancata in un ambiente del servizio app v1.	La funzionalità di migrazione affiancata non supporta l'ambiente del servizio app v1. Eseguire la migrazione usando la funzionalità di migrazione sul posto o una delle opzioni di migrazione manuale.
La migrazione non è disponibile per questa sottoscrizione.	È necessario contattare il supporto per la migrazione di questo ambiente del servizio app.	Aprire un caso di supporto per contattare il supporto e risolvere il problema.
Non è possibile chiamare la migrazione con ridondanza della zona perché gli indirizzi IP creati durante la premigrazione non sono caratterizzati da ridondanza della zona.	Questo errore viene visualizzato se si tenta una migrazione con ridondanza della zona, ma gli indirizzi IP generati durante il passaggio di generazione dell'indirizzo IP non sono stati creati con ridondanza della zona. La piattaforma tenta di applicare la ridondanza della zona a tutti gli indirizzi IP per garantire la resilienza back-end.	Aprire un caso di supporto per contattare il supporto se è necessario abilitare la ridondanza della zona. I tecnici ripristineranno la migrazione e consentiranno di eseguire un altro tentativo di creare gli indirizzi IP. Altrimenti, è possibile eseguire la migrazione senza abilitare la ridondanza della zona.
Non è possibile chiamare la migrazione se IP SSL è abilitato in uno dei siti.	Gli ambienti del servizio app con siti con IP SSL abilitato non possono essere migrati usando la funzionalità di migrazione affiancata.	Rimuovere l'IP SSL da tutte le app nell'ambiente del servizio app per abilitare la funzionalità di migrazione.
Non è possibile 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 dell'ambiente del servizio app v3.	È necessario specificare una subnet diversa per l'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 ambienti del servizio app. Rimuoverne alcuni prima di provare a crearne altri.	È stata raggiunta la quota dell'ambiente del servizio app per la sottoscrizione.	Rimuovere gli ambienti non necessari o contattare il supporto per esaminare le opzioni.
Non è possibile chiamare la migrazione in questo ambiente del servizio app fino al termine dell'aggiornamento attivo.	Non è possibile eseguire la migrazione degli ambienti del servizio app durante gli aggiornamenti della piattaforma. È possibile impostare le preferenze di aggiornamento nel portale di Azure. Gli aggiornamenti richiedono 8-12 ore o più a seconda delle dimensioni (numero di istanze/core) dell'ambiente del servizio app.	Attendere il completamento dell'aggiornamento e quindi eseguire la migrazione.
Operazione di gestione dell'ambiente del servizio app è in corso.	L'ambiente del servizio app è sottoposto a 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 delle operazioni.
InteralLoadBalancingMode non è attualmente supportato.	Al momento non è possibile eseguire la migrazione degli ambienti del servizio app con InternalLoadBalancingMode impostato su determinati valori usando la funzionalità di migrazione. Il team Microsoft deve modificare manualmente InternalLoadBalancingMode.	Aprire un caso di supporto per contattare il supporto e risolvere il problema. Richiedere un aggiornamento di InternalLoadBalancingMode.
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 premigrazione.	Assicurarsi di completare tutti i passaggi di premigrazione prima di tentare la migrazione. Consultare 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 dell'ambiente del servizio app v3.	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.	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 eseguito con la funzionalità di migrazione affiancata

La migrazione affiancata è costituita da una serie di passaggi che devono essere eseguiti 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 affiancata per l'ambiente del servizio app in uso

La piattaforma verifica che l'ambiente del servizio app possa essere migrato usando la funzionalità di migrazione affiancata. Se l'ambiente del servizio app non supera tutti i controlli di convalida, al momento non è possibile eseguire la migrazione usando la funzionalità di migrazione affiancata. Per informazioni dettagliate sulle possibili cause dell'errore di convalida, vedere la sezione di risoluzione dei problemi. Se l'ambiente è in uno stato non integro o sospeso, non è possibile eseguire la migrazione fino a quando non si applicano gli aggiornamenti necessari. Se non è possibile eseguire la migrazione tramite la funzionalità di migrazione affiancata, vedere le opzioni di migrazione manuale.

La convalida controlla anche se l'ambiente del servizio app è nella build minima necessaria per la migrazione. Questa build potrebbe essere più recente della build standard distribuita con il ciclo di aggiornamento/manutenzione della piattaforma di routine. La build minima viene aggiornata periodicamente per garantire che siano disponibili le correzioni di bug e i miglioramenti più recenti. Se l'ambiente del servizio app non è nella build minima, è necessario avviare manualmente l'aggiornamento. Questo aggiornamento è un processo standard che non influisce sull'ambiente del servizio app, ma non è possibile ridimensionare o apportare modifiche all'ambiente del servizio app mentre è in corso l'aggiornamento. Non è possibile eseguire la migrazione fino al termine dell'aggiornamento. Il completamento degli aggiornamenti può richiedere 8-12 ore o più 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 momento pianificato per la migrazione 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 nella stessa area, dell'ambiente del servizio app esistente.
  • Se nella rete virtuale non è disponibile una subnet, è necessario crearne una. Potrebbe essere necessario aumentare lo spazio 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 in entrambe le direzioni con la subnet in cui si trova l'ambiente del servizio app esistente. Assicurarsi che non siano presenti gruppi di sicurezza di rete o altre configurazioni di rete che potrebbero impedire la comunicazione tra le subnet.
• La subnet deve avere una sola 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 aggiunti di nuovo, se necessario, al termine della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà del blocco, 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 degli ambienti del servizio app o la modifica delle subnet, devono essere rimossi prima della migrazione. I criteri possono essere aggiunti di nuovo, se necessario, al termine della migrazione. Per altre informazioni su Criteri di Azure, vedere la 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 usati dall'ambiente del servizio app v3 futuro. Questi nuovi IP non hanno alcun effetto sull'ambiente esistente.

Si riceve il nuovo indirizzo IP in ingresso al termine della migrazione, ma prima di modificare il 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 risorse dell'ambiente del servizio app 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.

Aggiornare le risorse dipendenti con i 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 di Internet, in modo da poter modificare i firewall esterni, il routing DNS, i 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 associate al nuovo ambiente del servizio app v3. Non procedere al passaggio successivo finché non sono stati eseguiti tutti gli aggiornamenti necessari. È possibile che si verifichino tempi di inattività durante e dopo il passaggio di migrazione se si hanno dipendenze dagli indirizzi IP in uscita e non si eseguono tutti gli aggiornamenti necessari. Questo è dovuto al fatto che, una volta avviata la migrazione, anche se il traffico passa ancora ai front-end dell'ambiente del servizio app v2, il calcolo sottostante è il nuovo ambiente del servizio app v3 nella nuova subnet.

Durante questo passaggio è consigliabile anche esaminare le modifiche alle dipendenze della rete in ingresso e in uscita quando si passa all'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 dell'ambiente del servizio app

L'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 dell'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 abbia una singola delega di Microsoft.Web/hostingEnvironments.

Confermare le modifiche delle dimensioni istanza

I piani del servizio app vengono creati con lo SKU Isolato 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 Isolato v2 ha più memoria e CPU per ogni dimensione di istanza corrispondente. Al termine della migrazione, è possibile dimensionare 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 nella rete virtuale ci sono blocchi, è necessario rimuoverli prima della migrazione. I blocchi possono essere aggiunti di nuovo, 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à del blocco, 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 impedire la creazione e la modifica delle risorse per determinate entità. Se è presente un criterio che blocca la creazione degli ambienti del servizio app o la modifica delle subnet, è necessario rimuoverlo prima della migrazione. Il criterio può essere aggiunto di nuovo, se necessario, al termine della migrazione. Per altre informazioni su Criteri di Azure, vedere la panoramica di Criteri di Azure.

Aggiungere un suffisso di dominio personalizzato (facoltativo)

Se l'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 nell'ambiente del servizio app v3 viene implementato in modo diverso rispetto all'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 sul suffisso di dominio personalizzato dell'ambiente del servizio app v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Configurare il suffisso di dominio personalizzato per l'ambiente del servizio app. Se l'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 l'ambiente del servizio app v3, il dominio personalizzato non viene visualizzato nella sezione Funzionalità essenziali della pagina Panoramica del portale così com'è per l'ambiente del servizio app v1/v2. Per l'ambiente del servizio app v3 passare invece alla pagina Suffissi domini personalizzati in cui è possibile verificare che il suffisso di dominio personalizzato sia configurato correttamente. Inoltre, nell'ambiente del servizio app v2, se è presente un suffisso di dominio personalizzato, il nome host predefinito include il suffisso di dominio personalizzato ed è nel formato APP-NAME.internal.contoso.com. Nell'ambiente del servizio app v3 il nome host predefinito usa sempre il suffisso di dominio predefinito ed è nel formato APP-NAME.ASE-NAME.appserviceenvironment.net. Questa differenza è dovuta al fatto che l'ambiente del servizio app v3 mantiene il suffisso di dominio predefinito quando si aggiunge un suffisso di dominio personalizzato. Con l'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 è previsto alcun tempo di inattività dell'applicazione durante la migrazione, ma come nel passaggio di generazione dell'indirizzo IP, non è possibile dimensionare, modificare l'ambiente del servizio app esistente o distribuirvi le app durante questo processo.

Importante

Poiché il ridimensionamento è bloccato durante la migrazione, è necessario dimensionare l'ambiente in base alle dimensioni desiderate prima di avviare la migrazione. Se è abilitato il ridimensionamento automatico, se si verifica un evento di ridimensionamento prima dell'avvio della migrazione, è necessario attendere il completamento dell'evento di ridimensionamento prima di avviare la migrazione. È consigliabile disabilitare il ridimensionamento automatico prima di avviare la migrazione per evitare questo problema. Se è necessario dimensionare l'ambiente dopo la migrazione, è possibile farlo al termine della migrazione.

Questo passaggio è anche il momento 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é l'ambiente del servizio app v3 si trovi in un'area che supporta la ridondanza della zona.

La migrazione affiancata richiede un intervallo di servizio da tre a sei ore per le migrazioni dell'ambiente del servizio app da v2 a v3. Durante la migrazione, la scalabilità e le configurazioni dell'ambiente sono bloccate e si verificano gli eventi seguenti:

• Il nuovo ambiente del servizio app v3 viene creato nella subnet selezionata.
• I nuovi piani del servizio app vengono creati nel nuovo ambiente del servizio app v3 con il livello Isolato v2 corrispondente.
• Le app vengono create nel nuovo ambiente del servizio app v3.
• Il calcolo o i ruoli di lavoro sottostanti per le app vengono spostati nel nuovo ambiente del servizio app v3, il che significa che le app sono ora in esecuzione nell'ambiente del servizio app v3. Tuttavia, i front-end dell'ambiente del servizio app v2 sono ancora in esecuzione e gestiscono il traffico per impostazione predefinita. Il precedente indirizzo IP in ingresso rimane in uso, ma i nuovi indirizzi IP in uscita sono in uso. Inoltre, i nuovi front-end dell'ambiente del servizio app v3 vengono creati e sono pronti per gestire il traffico.
  • Per gli ambienti del servizio app con bilanciamento del carico interno, i front-end dell'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 gli ambienti del servizio app ELB, il processo di migrazione non reindirizza il traffico ai front-end dell'ambiente del servizio app v3 fino al completamento del passaggio finale della migrazione.

Al termine di questo passaggio, il traffico dell'applicazione continuerà a raggiungere i front-end precedenti dell'ambiente del servizio app v2 e l'indirizzo IP in ingresso a esso assegnato. Tuttavia, le app vengono effettivamente eseguite nei ruoli di lavoro del nuovo ambiente del servizio app v3.

Nota

A causa di un bug noto, i processi Web potrebbero non essere avviati durante il passaggio di distribuzione ibrida. Se si usano processi Web, questo bug potrebbe causare problemi o tempi di inattività dell'app. Aprire un caso di supporto in caso di domande o dubbi su questo problema.

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

Il nuovo indirizzo IP in ingresso viene fornito in modo che sia possibile configurare nuovi endpoint con servizi come Gestione traffico o Frontdoor di Azure e aggiornare una delle zone DNS private. Non procedere 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 associate al nuovo ambiente del servizio app v3. Non procedere al passaggio successivo finché non sono stati eseguiti tutti gli aggiornamenti necessari.

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

Il passaggio finale consiste nel reindirizzare il traffico al nuovo front-end dell'ambiente del servizio app v3 e completare la migrazione. 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 ai front-end dell'ambiente del servizio app v2. Se si usa un ambiente del servizio app v3 con bilanciamento del carico interno, è possibile testare i front-end dell'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 v3 ELB, 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 dell'ambiente del servizio app v3. Se alle singole app sono stati assegnati domini personalizzati, 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 l'ambiente del servizio app v3 prima di avviare il passaggio finale della migrazione in cui viene eliminato l'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/della piattaforma 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 diventano effettive entro un paio di minuti. È responsabilità dell'utente aggiornare i record DNS in modo che puntino al nuovo indirizzo IP in ingresso. Se si verificano problemi o tempi di inattività dell'applicazione, controllare le impostazioni della cache e TTL. Questo passaggio arresta inoltre l'ambiente del servizio app precedente e lo elimina. Il nuovo ambiente del servizio app v3 è ora l'ambiente di produzione.

Importante

La piattaforma garantisce un'esperienza di migrazione senza tempi di inattività. Tuttavia, le impostazioni DNS potrebbero causare tempi di inattività durante il passaggio di modifica del DNS. Ciò può essere dovuto a problemi relativi alle impostazioni TTL e della cache perché il traffico potrebbe essere ancora indirizzato all'ambiente del servizio app precedente dopo la modifica del DNS. È necessario esaminare le impostazioni del DNS e assicurarsi di avere un valore di TTL basso e che il provider DNS supporti la propagazione rapida. Se il valore di TTL è elevato, è possibile che si verifichino tempi di inattività durante il passaggio di modifica del DNS.

Nota

È importante completare questo passaggio il prima possibile. Quando l'ambiente del servizio app è nello stato ibrido, non è in grado di ricevere aggiornamenti della piattaforma e patch di sicurezza, il che lo rende più vulnerabile all'instabilità e alle minacce alla sicurezza.

Per completare questo passaggio sono disponibili 14 giorni. Dopo 14 giorni la piattaforma completerà automaticamente la migrazione ed eliminerà l'ambiente precedente. Se è necessario più tempo, è possibile aprire un caso di supporto per discutere le opzioni disponibili.

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 dell'ambiente del servizio app v2. Se si verifica un problema, contattare il supporto tecnico.

Usare la funzionalità di migrazione affiancata

Prerequisiti

Assicurarsi di comprendere in che modo la migrazione all'ambiente del servizio app v3 influisce sulle applicazioni. Esaminare il processo di migrazione nel suo complesso per comprendere la sequenza temporale del processo e i momenti in cui è necessario intervenire. Esaminare anche le domande frequenti, che possono risolvere alcuni dubbi.

Assicurarsi che non siano presenti blocchi nella rete virtuale, nei gruppi di risorse, nelle risorse o nella sottoscrizione. I blocchi impediscono le operazioni della piattaforma durante la migrazione.

Assicurarsi che non siano presenti criteri di Azure che bloccano le azioni necessarie per la migrazione, incluse le modifiche alla subnet e la creazione di risorse del Servizio app di Azure. I criteri che bloccano la modifica e la creazione delle risorse possono causare il blocco o l'esito negativo della migrazione.

Poiché l'ambiente del servizio app v3 si trova in una subnet diversa nella rete virtuale, è necessario assicurarsi di avere una subnet disponibile nella rete virtuale che soddisfi i requisiti della subnet per l'ambiente del servizio app v3. La subnet selezionata deve anche essere in grado di comunicare con la subnet in cui si trova l'ambiente del servizio app esistente. Assicurarsi che non vi sia alcun blocco della comunicazione tra le due subnet. Se non c'è una subnet disponibile, è necessario crearne una prima della migrazione. La creazione di una nuova subnet potrebbe comportare l'aumento dello spazio indirizzi della rete virtuale. Per altre informazioni, vedere Creare una rete virtuale e una subnet.

Poiché il ridimensionamento è bloccato durante la migrazione, è necessario dimensionare l'ambiente in base alle dimensioni desiderate prima di avviare la migrazione. Se è necessario dimensionare l'ambiente dopo la migrazione, è possibile farlo al termine della migrazione. Se è abilitato il ridimensionamento automatico, se si verifica un evento di ridimensionamento prima dell'avvio della migrazione, la migrazione viene bloccata fino al completamento dell'evento di ridimensionamento. È consigliabile disabilitare il ridimensionamento automatico prima di avviare la migrazione per evitare questo problema.

Seguire i passaggi descritti qui nell'ordine e seguendo le modalità descritte, perché si effettueranno chiamate all'API REST di Azure. È consigliabile usare l'interfaccia della riga di comando di Azure per effettuare queste chiamate API. Per informazioni su altri metodi, vedere riferimento all'API REST di Azure.

Per questa guida, installare l'interfaccia della riga di comando di Azure o usare Azure Cloud Shell e usare una shell Bash.

Nota

È consigliabile usare una shell Bash per eseguire i comandi indicati in questa guida. I comandi potrebbero non essere compatibili con le convenzioni di PowerShell e i caratteri di escape.

Importante

Durante la migrazione, il portale di Azure potrebbe mostrare informazioni errate sull'ambiente del servizio app e sulle app. Non passare all'esperienza di migrazione nel portale di Azure perché la funzionalità di migrazione affiancata non è disponibile lì. È consigliabile usare l'interfaccia della riga di comando di Azure per controllare lo stato della migrazione. Per eventuali domande sullo stato della migrazione o delle app, contattare il supporto.

1. Selezionare la subnet per il nuovo ambiente del servizio app v3

Selezionare una subnet nell'ambiente del servizio app v3 che soddisfi i requisiti della subnet per l'ambiente del servizio app v3. Prendere nota del nome della subnet selezionata. Questa subnet deve essere diversa dalla subnet in cui si trova l'ambiente del servizio app esistente.

2. Recuperare l'ID dell'ambiente del servizio app

Eseguire i comandi seguenti per ottenere l'ID dell'ambiente del servizio app e archiviarlo come variabile di ambiente. Sostituire i segnaposto per il nome e i gruppi di risorse con i valori dell'ambiente del servizio app di cui si vuole eseguire la migrazione. ASE_RG e VNET_RG sono uguali se la rete virtuale e l'ambiente del servizio app si trovano nello stesso gruppo di risorse.

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

3. Verificare che la migrazione sia supportata

Il comando seguente controlla se l'ambiente del servizio app è supportato per la migrazione. Questo comando verifica anche che l'ambiente del servizio app sia nella versione della build supportata per la migrazione. Se l'ambiente del servizio app non è nella versione della build supportata, è necessario avviare manualmente l'aggiornamento. Per altre informazioni sull'aggiornamento premigrazione, vedere Verificare che la migrazione sia supportata usando la funzionalità di migrazione affiancata per l'ambiente del servizio app.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

Se non sono presenti errori, la migrazione è supportata ed è possibile continuare con il passaggio successivo.

Se è necessario avviare un aggiornamento per aggiornare l'ambiente del servizio app alla versione della build supportata, che potrebbe richiedere 8-12 ore o più a seconda delle dimensioni dell'ambiente, eseguire il comando seguente. Eseguire questo comando solo se si verifica un errore durante il passaggio di convalida e viene richiesto di aggiornare l'ambiente del servizio app.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

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

Eseguire il comando seguente per creare nuovi indirizzi IP in uscita. Il completamento di questo passaggio richiede circa 15 minuti. Non dimensionare o apportare modifiche all'ambiente del servizio app esistente durante questo periodo.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

Per verificare lo stato di questo passaggio, eseguire il comando seguente:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status

Se il passaggio è in corso, si ottiene lo stato Migrating. Quando si ottiene lo stato Ready, eseguire il comando seguente per visualizzare i nuovi indirizzi IP in uscita. Se i nuovi indirizzi IP non vengono visualizzati immediatamente, attendere alcuni minuti e riprovare.

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5. Aggiornare le risorse dipendenti con i nuovi indirizzi IP in uscita

Usando i nuovi indirizzi IP in uscita, aggiornare le risorse o i componenti di rete per assicurarsi che il nuovo ambiente funzioni come previsto dopo l'avvio della migrazione. È responsabilità dell'utente eseguire gli eventuali aggiornamenti necessari. I nuovi indirizzi IP in uscita vengono usati dopo la creazione dell'ambiente del servizio app v3 durante il passaggio di migrazione. Ad esempio, se si ha un suffisso di dominio personalizzato e un insieme di credenziali delle chiavi di Azure e si gestiscono le restrizioni di accesso con un firewall, è necessario aggiornare il firewall di Azure Key Vault per consentire solo i nuovi indirizzi IP in uscita o l'intera nuova subnet.

6. Delegare la subnet dell'ambiente del servizio app

L'ambiente del servizio app v3 richiede che la subnet in cui si trova abbia una singola delega di Microsoft.Web/hostingEnvironments. Le versioni precedenti non richiedono questa delega. È necessario verificare che la subnet sia delegata correttamente e aggiornare la delega (se necessario) prima della migrazione. È possibile aggiornare la delega eseguendo il comando seguente o passando alla subnet nel portale di Azure.

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

7. Verificare che non siano presenti blocchi nella rete virtuale

I blocchi della rete virtuale bloccano le operazioni della piattaforma durante la migrazione. Se nella rete virtuale ci sono blocchi, è necessario rimuoverli prima della migrazione. Se necessario, è possibile aggiungere nuovamente i blocchi al termine della migrazione.

Usare il comando seguente per verificare se nella rete virtuale ci sono blocchi:

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Eliminare eventuali blocchi esistenti usando il comando seguente:

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Per i comandi correlati per verificare se nella sottoscrizione o nel gruppo di risorse ci sono blocchi, vedere le informazioni di riferimento sull'interfaccia della riga di comando di Azure per i blocchi.

8. Preparare le configurazioni

Se l'ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurarne uno per la nuova risorsa ambiente del servizio app v3 durante il processo di migrazione. La migrazione non riesce se non si configura un suffisso di dominio personalizzato e se ne usa uno al momento. Per altre informazioni sul suffisso di dominio personalizzato dell'ambiente del servizio app v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Suffisso di dominio personalizzato per gli ambienti del servizio app.

Nota

Se si configura un suffisso di dominio personalizzato, quando si aggiungono le autorizzazioni di rete in Azure Key Vault, assicurarsi che l'insieme di credenziali delle chiavi consenta l'accesso dalla nuova subnet dell'ambiente del servizio app v3. Se si accede all'insieme di credenziali delle chiavi usando un endpoint privato, assicurarsi di aver configurato correttamente l'accesso privato con la nuova subnet. Si verificano tempi di inattività se non è possibile impostare correttamente questo accesso prima della migrazione.

È possibile applicare la ridondanza della zona alla nuova zona dell'ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona. La ridondanza della zona può essere configurata impostando la proprietà zoneRedundant su true. La ridondanza della zona è una configurazione facoltativa. Questa configurazione può essere impostata solo durante la creazione del nuovo ambiente del servizio app v3 e non può essere rimossa in un secondo momento.

Per impostare queste configurazioni, inclusa l'identificazione della subnet selezionata in precedenza, creare un file denominato parameters.json con i dettagli seguenti in base allo scenario in uso. Assicurarsi di usare la nuova subnet selezionata per il nuovo ambiente del servizio app v3. Non includere le proprietà per un suffisso del dominio personalizzato se questa funzionalità non si applica alla migrazione. Prestare attenzione al valore della proprietà zoneRedundant e impostarla in base ai requisiti di resilienza.

Se si esegue la migrazione senza un suffisso di dominio personalizzato, usare questo codice:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

Se si usa un'identità gestita assegnata dall'utente per la configurazione del suffisso di dominio personalizzato, usare questo codice:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

Se si usa un'identità gestita assegnata dal sistema per la configurazione del suffisso di dominio personalizzato, usare questo codice:

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9. Eseguire la migrazione all'ambiente del servizio app v3 e controllare lo stato

Dopo aver completato tutti i passaggi precedenti, è possibile avviare la migrazione. Assicurarsi di comprendere le implicazioni della migrazione.

Il completamento di questo passaggio richiede da tre a sei ore. Durante questo periodo di tempo, non è previsto alcun tempo di inattività dell'applicazione se sono stati eseguiti i passaggi precedenti. Il ridimensionamento, le distribuzioni e le modifiche dell'ambiente del servizio app esistente vengono bloccate durante questo passaggio.

Nota

A causa di un bug noto, i processi Web potrebbero non essere avviati durante il passaggio di distribuzione ibrida. Se si usano processi Web, questo bug può causare problemi o tempi di inattività dell'app. Aprire un caso di supporto in caso di domande o dubbi su questo problema.

Eseguire il comando seguente per avviare la migrazione:

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

Eseguire il comando seguente per verificare lo stato della migrazione:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Quando si ottiene lo stato MigrationPendingDnsChange, la migrazione è stata completata e si dispone di una risorsa ambiente del servizio app v3. Le app sono ora in esecuzione nel nuovo ambiente e nell'ambiente precedente.

Per ottenere i dettagli del nuovo ambiente, eseguire il comando seguente:

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Importante

Durante la migrazione e durante il passaggio MigrationPendingDnsChange, il portale di Azure mostra informazioni errate sull'ambiente del servizio app e sulle app. Usare l'interfaccia della riga di comando di Azure per controllare lo stato della migrazione. Per eventuali domande sullo stato della migrazione o delle app, contattare il supporto.

Nota

Se la migrazione include un suffisso di dominio personalizzato, la configurazione del suffisso di dominio personalizzato potrebbe risultare danneggiata al termine della migrazione a causa di un bug noto. L'ambiente del servizio app dovrebbe comunque funzionare come previsto. Lo stato danneggiato dovrebbe risolversi entro 6-8 ore. Se la configurazione risulta ancora danneggiata dopo 8 ore o se il suffisso del dominio personalizzato non funziona, contattare il supporto.

10. Ottenere gli indirizzi IP in ingresso per il nuovo ambiente del servizio app v3 e aggiornare le risorse dipendenti

In questa fase del processo di migrazione sono disponibili due set di front-end dell'ambiente del servizio app ed entrambi i set sono in grado di gestire il traffico dell'applicazione. Il DNS non viene modificato, quindi per impostazione predefinita il traffico viene inviato ai front-end precedenti dell'ambiente del servizio app. È necessario aggiornare tutte le risorse dipendenti per usare il nuovo indirizzo IP in ingresso per il nuovo ambiente del servizio app v3. Per gli ambienti del servizio app interni (con servizio di bilanciamento del carico interno), è necessario aggiornare le zone DNS private in modo che puntino al nuovo indirizzo IP in ingresso.

È possibile ottenere il nuovo indirizzo IP in ingresso per il nuovo ambiente del servizio app v3 eseguendo il comando seguente che corrisponde al tipo di bilanciamento del carico dell'ambiente del servizio app. È responsabilità dell'utente eseguire gli eventuali aggiornamenti necessari.

Per gli ambienti del servizio app con bilanciamento del carico interno, eseguire il comando seguente per recuperare l'indirizzo IP in ingresso privato:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

Per gli ambienti del servizio app ELB, eseguire il comando seguente per recuperare l'indirizzo IP in ingresso pubblico:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

Importante

Se la migrazione include un suffisso di dominio personalizzato, il comportamento predefinito del nome host per l'ambiente del servizio app v3 è diverso da quello dell'ambiente del servizio app v2. Per l'ambiente del servizio app v3 il nome host predefinito usa sempre il suffisso di dominio predefinito ed è nel formato APP-NAME.ASE-NAME.appserviceenvironment.net. Esaminare tutte le risorse dipendenti, ad esempio il gateway applicazione, che usano i nomi host delle app per assicurarsi che siano aggiornate in modo da tenere conto di questo comportamento. Per altre informazioni sulle differenze di funzione tra le diverse versioni dell'ambiente del servizio app, vedere Confronto delle versioni dell'ambiente del servizio app.

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

Questo passaggio consente di testare e convalidare il nuovo ambiente del servizio app v3.

Importante

Per completare questo passaggio sono disponibili 14 giorni. Dopo 14 giorni la piattaforma completerà automaticamente la migrazione ed eliminerà l'ambiente precedente. Se è necessario più tempo, è possibile aprire un caso di supporto per discutere le opzioni disponibili.

Dopo aver verificato che le app funzionino come previsto, è possibile finalizzare la migrazione eseguendo il comando seguente. Questo comando elimina anche l'ambiente precedente.

Se si verificano problemi o si decide a questo punto che non si vuole più procedere con la migrazione, contattare il supporto tecnico per valutare le possibilità. Non eseguire il comando di modifica DNS perché tale comando completa la migrazione.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

Per verificare lo stato di questo passaggio, eseguire il comando seguente:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Durante questo passaggio, si ottiene lo stato CompletingMigration. Quando si ottiene uno stato MigrationCompleted, il passaggio di reindirizzamento del traffico è stato eseguito e la migrazione è stata completata.

Origini comuni dei problemi durante la migrazione tramite la funzionalità di migrazione affiancata

Di seguito sono riportati esempi di origini comuni dei problemi riscontrati dai clienti durante la migrazione tramite la funzionalità di migrazione affiancata. È consigliabile esaminare queste aree per assicurarsi che non si verifichino tempi di inattività o interruzioni del servizio durante o dopo il processo di migrazione.

• Azure Key Vault deve consentire il traffico dai nuovi indirizzi IP/subnet in uscita.
• Le due subnet devono essere in grado di comunicare tra loro in entrambe le direzioni. I clienti in genere consentono il traffico dalla subnet precedente alla nuova subnet, ma dimenticano di consentire il traffico dalla nuova subnet alla subnet precedente.
• Il gateway applicazione deve essere aggiornato con i nuovi indirizzi IP.
• I record DNS devono essere aggiornati con i nuovi indirizzi IP.
• Se nelle applicazioni sono presenti indirizzi IP hardcoded, è necessario aggiornarli con i nuovi indirizzi IP.
• Le tabelle di route devono essere aggiornate con le nuove route.

Prezzi

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

Quando si esegue la migrazione all'ambiente del servizio app v3 dalle versioni precedenti, è consigliabile considerare scenari 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 sui costi dopo l'aggiornamento all'ambiente del servizio app v3.

Nota

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

Passare a un piano di servizio app inferiore

Gli SKU del piano di servizio app disponibili per l'ambiente del servizio app v3 vengono eseguiti nel livello Isolato v2 (Iv2). Il numero di core e la quantità di RAM vengono effettivamente raddoppiati in base al 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, il provisioning è eccessivo e si paga per risorse di calcolo e memoria che non vengono usati. Per questo scenario, è possibile passare dall'istanza I2v2 a I1v2 e avere infine con un numero di core e RAM simile a quelli precedentemente disponibili.

Domande frequenti

• Cosa accade se la migrazione dell'ambiente del servizio app non è attualmente supportata?
  Al momento non è possibile eseguire la migrazione tramite la funzionalità di migrazione affiancata. Se si dispone di un ambiente non supportato e si vuole eseguire immediatamente la migrazione, consultare le opzioni di migrazione manuale.
• Come scegliere quale opzione di migrazione è adatta?
  Esaminare l'albero delle decisioni del percorso di migrazione per decidere quale opzione sia migliore per il caso d'uso.
• Come è possibile sapere se è necessario usare la funzionalità di migrazione affiancata?
  La funzionalità di migrazione affiancata è ideale per i clienti che vogliono eseguire la migrazione all'ambiente del servizio app v3, ma non possono supportare il tempo di inattività dell'applicazione. Poiché viene usata una nuova subnet per il nuovo ambiente, è necessario fare 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 l'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à?
  La piattaforma garantisce che non si verifichino tempi di inattività durante il processo di migrazione affiancata. Tuttavia, le impostazioni DNS potrebbero causare tempi di inattività durante il passaggio di modifica del DNS. Ciò può essere dovuto a problemi relativi alle impostazioni TTL e della cache perché il traffico potrebbe essere ancora indirizzato all'ambiente del servizio app precedente dopo la modifica del DNS. È necessario esaminare le impostazioni del DNS e assicurarsi di avere un valore di TTL basso e che il provider DNS supporti la propagazione rapida.
• Sarà necessario eseguire operazioni sulle app dopo la migrazione per fare in modo che vengano eseguite nel nuovo 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 affiancata supporta questo scenario di migrazione.
• Cosa accade se l'ambiente del servizio app è aggiunto alla zona?
  La funzionalità di migrazione affiancata non supporta questo scenario di migrazione al momento. Se si dispone di un ambiente del servizio app aggiunto alla zona e si vuole eseguire immediatamente la migrazione, consultare le opzioni di migrazione manuale.
• Cosa accade se l'ambiente del servizio app dispone di indirizzi IP SSL?
  IP SSL non è supportato nell'Ambiente del servizio app v3. È necessario rimuovere tutte le associazioni IP SSL prima di eseguire la migrazione usando la funzionalità di migrazione o una delle opzioni manuali. Se si intende usare la funzionalità di migrazione affiancata, dopo aver rimosso tutte le associazioni IP SSL, si supera il controllo di convalida e si può procedere con la migrazione automatica.
• Quali proprietà dell'ambiente del servizio app cambieranno?
  Se si usa l'ambiente del servizio app v3 è consigliabile esaminare le funzionalità e le differenze di funzionalità rispetto alle versioni precedenti. Sia gli indirizzi IP in ingresso che quelli in uscita cambiano quando si usa la funzionalità di migrazione affiancata. 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 non riesce o si verifica un problema imprevisto durante la migrazione?
  Se si verifica un problema imprevisto, i team di supporto sono pronti a intervenire. È 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 questo influisce sui carichi di lavoro.
• Cosa accade all'ambiente del servizio app precedente?
  Se si decide di eseguire la migrazione di un ambiente del servizio app usando la funzionalità di migrazione affiancata, l'ambiente precedente resta in uso fino al passaggio finale del processo di migrazione. Una volta completato il passaggio finale, l'ambiente precedente e tutte le app che ospita vengono arrestati ed eliminati. L'ambiente precedente non è più accessibile. A questo punto non è possibile ripristinare l'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 all'ambiente del servizio app v3, l'ambiente del servizio app v1/v2s e le app distribuite al loro interno 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

Rete per l'ambiente del servizio app V3

Uso di un ambiente del servizio app v3

Suffisso di dominio personalizzato