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

Nota

La funzionalità di migrazione descritta in questo articolo viene usata per la migrazione automatica sul posto (stessa subnet) dall'ambiente del servizio app v1 e 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 affiancata. 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.

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 sul posto automatizza la migrazione all'ambiente del servizio app v3 aggiornando l'ambiente del servizio app esistente nella stessa subnet. Questa opzione di migrazione è ideale per i clienti che vogliono eseguire la migrazione all'ambiente del servizio app v3 con modifiche minime alle configurazioni di rete. È anche necessario essere in grado di supportare circa un'ora di inattività delle applicazioni. Se non è possibile supportare tempi di inattività, vedere la funzionalità di migrazione affiancata o le opzioni di migrazione manuale.

Importante

È consigliabile usare questa funzionalità per gli ambienti di sviluppo prima di eseguire la migrazione di un ambiente di produzione per 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 sul posto non supporta le migrazioni all'ambiente del servizio app v3 nelle aree seguenti:

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 sul posto. La tabella fornisce la configurazione dell'ambiente del servizio app v3 quando si usa la funzionalità di migrazione sul posto in base all'ambiente del servizio app esistente. È possibile eseguire la migrazione di tutti gli ambienti del servizio app supportati a un ambiente del servizio app v3 con ridondanza della zona v3 usando la funzionalità di migrazione sul posto, purché l'ambiente si trovi in un'area che supporta la ridondanza della zona. È possibile configurare la ridondanza della zona durante il processo di migrazione.

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 ILB con un suffisso di dominio personalizzato
Ambiente del servizio app v1 ILB	Ambiente del servizio app v3 ILB
Ambiente del servizio app v1 ELB	Ambiente del servizio app v3 ELB
Ambiente del servizio app v1 ILB con un suffisso di dominio personalizzato	Ambiente del servizio app v3 ILB con un suffisso di dominio personalizzato
Ambiente del servizio app v2 aggiunto alla zona	Ambiente del servizio app v3 con configurazione facoltativa della 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.

È 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.

Limitazioni della funzionalità di migrazione sul posto

Di seguito sono riportate alcune limitazioni nell'uso della funzionalità di migrazione sul posto:

• Il nuovo ambiente del servizio app v3 si trova nella subnet esistente usata per l'ambiente precedente.
• Non è possibile modificare l'area in cui si trova l'ambiente del servizio app.
• Non è possibile eseguire la migrazione dell'ambiente del servizio app ELB all'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.

L'ambiente del servizio app v3 non supporta le funzionalità seguenti che potrebbero essere in uso nell'ambiente del servizio app v1 o 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 sul posto 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 v1 in una rete virtuale classica
• Ambiente del servizio app v2 ELB con indirizzi IP SSL
• Ambiente del servizio app v1 ELB con indirizzi IP SSL
• 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 sul posto. Se lo scenario non supera tutti i controlli di convalida, in questo momento non è possibile eseguire la migrazione usando la funzionalità di migrazione sul posto. 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, può essere 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 usando la funzionalità di migrazione sul posto.	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 sul posto sia disponibile nell'area.
Non è possibile chiamare la migrazione in questo ambiente del servizio app. Per assistenza alla migrazione, contattare il supporto tecnico.	È necessario contattare il supporto per la migrazione di questo ambiente del servizio app. Questo problema è potenzialmente dovuto alle impostazioni personalizzate usate da questo ambiente.	Aprire un caso di supporto per contattare il supporto e risolvere il problema.
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 sul posto.	Rimuovere l'IP SSL da tutte le app nell'ambiente del servizio app per abilitare la funzionalità di 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 premigrazione.	Assicurarsi di completare tutti i passaggi di premigrazione prima di tentare la migrazione. Consultare la guida dettagliata per la migrazione.
La migrazione all'ambiente del servizio app v3 non è consentita per questo ambiente del servizio app.	Non è possibile eseguire la migrazione usando la funzionalità di migrazione.	Eseguire la migrazione usando una delle opzioni di migrazione manuale.
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.
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> non è disponibile in questa posizione.	Questo errore viene visualizzato se si sta tentando di eseguire la migrazione di un ambiente del servizio app in un'area che non supporta una delle funzionalità richieste.	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 supporti questa configurazione dell'ambiente del servizio app.
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.
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.
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. InternalLoadBalancingMode deve essere modificato manualmente dal team Microsoft.	Aprire un caso di supporto per contattare il supporto e risolvere il problema. Richiedere un aggiornamento a InternalLoadBalancingMode per consentire la migrazione.

Panoramica del processo di migrazione eseguito con la funzionalità di migrazione sul posto

La migrazione sul posto è 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 sul posto 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 sul posto. 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 sul posto. 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 sul posto, 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.

Generare gli indirizzi IP per il nuovo ambiente del servizio app v3

La piattaforma crea il nuovo indirizzo IP in ingresso (se si esegue la migrazione di un ambiente del servizio app ELB) e 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 verranno forniti i nuovi IP che verranno usati dall'ambiente del servizio app v3. Questi nuovi IP non hanno alcun effetto sull'ambiente esistente. Gli IP usati dall'ambiente esistente continueranno a essere usati fino all'arresto dell'ambiente esistente al momento della migrazione.

Aggiornare le risorse dipendenti con nuovi IP

Dopo la creazione dei nuovi indirizzi IP, si dispone dei nuovi indirizzi Internet pubblici in uscita predefiniti. Durante la preparazione per la migrazione, è possibile modificare firewall esterni, routing DNS, gruppi di sicurezza di rete e qualsiasi altra risorsa che si basa su questi indirizzi IP. Per l'ambiente del servizio app ELB è disponibile anche il nuovo indirizzo IP in ingresso, che è possibile usare per configurare nuovi endpoint con servizi come Gestione traffico o Frontdoor di Azure. È 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. 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.

Confermare le modifiche delle dimensioni istanza

I piani di servizio app vengono convertiti da Isolato al livello Isolato v2 corrispondente come parte della migrazione. Ad esempio, I2 viene convertito in 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.

Scegliere le configurazioni dell'ambiente del servizio app v3

L'ambiente del servizio app v3 può essere distribuito tra zone di disponibilità nelle aree che lo supportano. Questa architettura è nota come ridondanza della zona. La ridondanza della zona può essere configurata solo durante la creazione dell'ambiente del servizio app. Se si vuole che il nuovo ambiente del servizio app v3 sia con ridondanza della zona, abilitare la configurazione durante il processo di migrazione. Qualsiasi ambiente del servizio app che usa la funzionalità di migrazione sul posto per eseguire la migrazione può essere configurato con ridondanza della zona, purché si usi un'area che supporta la ridondanza della zona per l'ambiente del servizio app v3. Se l'ambiente esistente si trova in un'area che non supporta la ridondanza della zona, l'opzione di configurazione è disabilitata e non è possibile configurarla. La funzionalità di migrazione sul posto non supporta la modifica delle aree. Se si vuole usare un'area diversa, usare una delle opzioni di migrazione manuale.

Nota

L'abilitazione della ridondanza della zona può comportare costi aggiuntivi. Per altre informazioni, vedere il modello di prezzi della ridondanza della zona.

Se l'ambiente del servizio app esistente usa un suffisso di dominio personalizzato, viene richiesto di configurare un suffisso di dominio personalizzato per il nuovo ambiente del servizio app v3. È necessario specificare il nome di dominio personalizzato, l'identità gestita e il certificato. 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. È 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.

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.

La migrazione richiede un intervallo di servizio da tre a sei ore per le migrazioni dell'ambiente del servizio app da v2 a v3. Le migrazioni da v1 a v3 possono richiedere fino a sei ore di intervallo di servizio, in base alle dimensioni dell'ambiente. L'intervallo di servizio potrebbe essere esteso in rari casi in cui è necessario l'intervento manuale del team di assistenza. Durante la migrazione, la scalabilità e le configurazioni dell'ambiente sono bloccate e si verificano gli eventi seguenti:

• L'ambiente del servizio app esistente viene arrestato e sostituito con il nuovo ambiente del servizio app v3.
• Tutti i piani di servizio app nell'ambiente del servizio app vengono convertiti dal livello Isolato a Isolato v2.
• Tutte le app presenti nell'ambiente del servizio app sono temporaneamente inattive. È consigliabile prevedere circa un'ora di tempo di inattività durante questo periodo.
  • Se non è possibile supportare i tempi di inattività, vedere la funzionalità di migrazione affiancata o le alternative di migrazione.
• Gli indirizzi pubblici usati dall'ambiente del servizio app cambiano negli IP generati durante il passaggio di generazione IP.

Durante il processo di migrazione sono disponibili gli stati seguenti:

Stato	Descrizione
Convalida e preparazione della migrazione.	La piattaforma sta convalidando il supporto della migrazione ed eseguendo i controlli necessari.
Distribuzione dell'infrastruttura dell'ambiente del servizio app v3.	È in corso il provisioning della nuova infrastruttura dell'ambiente del servizio app v3.
In attesa del completamento dell'infrastruttura.	La piattaforma sta convalidando la nuova infrastruttura ed eseguendo i controlli necessari.
Configurazione della rete. È iniziato il periodo di inattività della migrazione. Le applicazioni non sono accessibili.	La piattaforma sta eliminando l'infrastruttura precedente e spostando tutte le app nel nuovo ambiente del servizio app v3. Le app sono inattive e non accettano traffico.
Esecuzione di convalide post-migrazione.	La piattaforma sta eseguendo i controlli necessari per verificare che la migrazione abbia avuto esito positivo.
Finalizzazione della migrazione.	La piattaforma sta finalizzando la migrazione.

Come durante il passaggio di generazione IP, durante questo processo non è possibile ridimensionare o modificare l'ambiente del servizio app né distribuire app. Al termine della migrazione, le app presenti nell'ambiente del servizio app precedente verranno eseguite nel nuovo ambiente del servizio app v3.

Usare la funzionalità di migrazione sul posto

Prerequisiti

Assicurarsi di comprendere in che modo la migrazione all'ambiente del servizio app v3 influisce sulle applicazioni. Esaminare il processo di migrazione per comprenderne la sequenza temporale 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é 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.

È consigliabile usare il portale di Azure per l'esperienza di migrazione sul posto. Se si decide di usare l'interfaccia della riga di comando di Azure per la migrazione, seguire i passaggi descritti qui nello stesso ordine e secondo le modalità indicate, 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.

1. 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)

2. Verificare che la migrazione sia supportata

Il comando seguente controlla se l'ambiente del servizio app è supportato per la migrazione e verifica che l'ambiente del servizio app sia nella versione della build supportata per la migrazione.

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

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, 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}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

3. Generare indirizzi IP per la nuova risorsa ambiente del servizio app v3

Eseguire il comando seguente per creare nuovi indirizzi IP. Questa operazione 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}/migrate?api-version=2021-02-01&phase=premigration"

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

az rest --method get --uri "${ASE_ID}?api-version=2021-02-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. 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=2021-02-01"

4. Aggiornare le risorse dipendenti con i nuovi indirizzi IP

Usando i nuovi indirizzi IP, aggiornare le risorse o i componenti di rete per assicurarsi che il nuovo ambiente funzioni come previsto una volta completata la migrazione. È responsabilità dell'utente eseguire gli eventuali aggiornamenti necessari.

5. 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

6. 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.

7. Preparare le configurazioni

È possibile applicare la ridondanza della zona alla nuova risorsa ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona. È possibile configurare la ridondanza della zona impostando la proprietà zoneRedundant su true.

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. Inoltre, la migrazione non riesce se durante la migrazione si tenta di aggiungere un suffisso di dominio personalizzato a un ambiente che non ne ha uno configurato. 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 dai nuovi indirizzi IP in uscita dell'ambiente del servizio app generati al passaggio 3. Se si accede all'insieme di credenziali delle chiavi usando un endpoint privato, assicurarsi di aver configurato correttamente l'accesso privato.

Se la migrazione non include un suffisso di dominio personalizzato e non si abilita la ridondanza della zona, è possibile procedere alla migrazione.

Per impostare queste configurazioni, creare un file denominato parameters.json con i dettagli seguenti in base allo scenario. 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, perché questa configurazione è irreversibile dopo la migrazione. Impostare il valore della proprietà kind in base alla versione dell'ambiente del servizio app esistente. I valori accettati per la proprietà kind sono ASEV1 e ASEV2.

Se si esegue la migrazione senza un suffisso di dominio personalizzato e si sta abilitando la ridondanza della zona, usare questo codice:

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

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

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true,
        "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 e non si abilita la ridondanza della zona, usare questo codice:

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

8. 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.

Questo passaggio richiede da tre a sei ore per le migrazioni da v2 a v3 e fino a sei ore per le migrazioni da v1 a v3, a seconda delle dimensioni dell'ambiente. Durante questo intervallo c'è un tempo di inattività delle applicazioni di circa un'ora. Il ridimensionamento, le distribuzioni e le modifiche dell'ambiente del servizio app esistente vengono bloccate durante questo passaggio.

Includere il parametro body nel comando seguente se si abilita la ridondanza della zona e/o si configura un suffisso di dominio personalizzato. Se nessuna di queste configurazioni si applica alla migrazione, è possibile rimuovere il parametro dal comando.

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

Eseguire i comandi seguenti per controllare lo stato dettagliato della migrazione. Per informazioni sugli stati, vedere le descrizioni dello stato della migrazione.

Il primo comando ottiene l'ID operazione per la migrazione. Copiare il valore della proprietà ID.

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

Sostituire il segnaposto per l'ID operazione nel comando seguente con il valore copiato. Questo comando restituisce lo stato dettagliato della migrazione. È possibile eseguire questo comando con la frequenza necessaria per ottenere lo stato più recente.

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

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

Per ottenere i dettagli del nuovo ambiente, eseguire il comando seguente o passare al portale di Azure.

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

1. Verificare che la migrazione sia supportata

Nel portale di Azure passare alla pagina Migrazione per l'ambiente del servizio app di cui si sta eseguendo la migrazione. È possibile accedere alla pagina Migrazione selezionando il banner nella parte superiore della pagina Panoramica per l'ambiente del servizio app oppure selezionando la voce Migrazione nel menu a sinistra.

Selezionare l'opzione di migrazione sul posto per avviare il processo di migrazione sul posto. Se si seleziona l'opzione per la migrazione affiancata, viene visualizzata la documentazione per tale processo di migrazione. Non selezionare l'opzione di migrazione affiancata se si vuole usare la funzionalità di migrazione sul posto.

Nella pagina Migrazione la piattaforma verifica se la migrazione è supportata per l'ambiente del servizio app. Selezionare Convalida e quindi confermare che si vuole procedere con la convalida. Il processo di convalida richiede alcuni secondi.

Se l'ambiente non è supportato per la migrazione, nella parte superiore della pagina compare un banner con un messaggio di errore e il motivo. Per le descrizioni dei messaggi di errore che possono essere visualizzati se non si è idonei per la migrazione, vedere Risoluzione dei problemi.

Se è necessario avviare un aggiornamento per aggiornare l'ambiente del servizio app alla versione della build supportata, viene richiesto di avviare l'aggiornamento. Questo potrebbe richiedere 8-12 ore o più, a seconda delle dimensioni dell'ambiente. Selezionare Aggiorna per avviare l'aggiornamento. Al termine dell'aggiornamento, si supera la convalida e si può usare la funzionalità di migrazione per avviare la migrazione.

Se la migrazione è supportata per l'ambiente del servizio app, procedere con il passaggio successivo del processo. La pagina Migrazione guida nella serie di passaggi per completare la migrazione.

2. Generare indirizzi IP per la nuova risorsa ambiente del servizio app v3

In Ottieni nuovi indirizzi IP confermare di aver compreso le implicazioni e selezionare il pulsante Avvia. Questa operazione richiede circa 15 minuti. Non è possibile dimensionare o apportare modifiche all'ambiente del servizio app esistente durante questo periodo.

3. Aggiornare le risorse dipendenti con i nuovi indirizzi IP

Una volta completato il passaggio precedente, vengono visualizzati gli indirizzi IP per la nuova risorsa ambiente del servizio app v3. Usare i nuovi indirizzi IP per aggiornare le risorse e i componenti di rete in modo che il nuovo ambiente funzioni come previsto una volta completata la migrazione. È responsabilità dell'utente eseguire gli eventuali aggiornamenti necessari.

4. 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. Il portale mostra un collegamento alla subnet in modo che consente di confermare e aggiornare in base alle esigenze.

5. Confermare le modifiche alle dimensioni dell'istanza

Selezionare il pulsante Conferma per confermare di aver capito che, come parte della migrazione, i piani di servizio app vengono convertiti dal livello Isolato al livello Isolato v2 corrispondente.

6. Verificare che la rete virtuale non abbia blocchi

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. Per informazioni dettagliate su come verificare se la sottoscrizione o il gruppo di risorse ha blocchi, vedere Configurare i blocchi.

7. Scegliere le configurazioni

È possibile applicare la ridondanza della zona alla nuova risorsa ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona.

Selezionare la casella di controllo Abilitata se si vuole configurare la ridondanza della zona.

Se l'ambiente si trova in un'area che non supporta la ridondanza della zona, la casella di controllo non è disponibile. Se è necessaria una risorsa dell'ambiente del servizio app con ridondanza della zona v3, usare una delle opzioni di migrazione manuale e creare la risorsa in una delle aree che supportano la ridondanza della zona.

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. Le opzioni di configurazione per un suffisso di dominio personalizzato vengono visualizzate se questa situazione si applica all'utente. Non è possibile eseguire la migrazione finché non si specificano le informazioni necessarie.

Se si vuole usare un suffisso di dominio personalizzato, ma non ne è attualmente configurato uno, è possibile configurarne uno al termine della migrazione. 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 dai nuovi indirizzi IP in uscita dell'ambiente del servizio app generati al passaggio 2. Se si accede all'insieme di credenziali delle chiavi usando un endpoint privato, assicurarsi di aver configurato correttamente l'accesso privato.

Dopo aver aggiunto i dettagli per il suffisso di dominio personalizzato, diventa disponibile il pulsante Esegui migrazione.

8. Eseguire la migrazione all'ambiente del servizio app v3

Dopo aver completato tutti i passaggi precedenti, è possibile avviare la migrazione. Assicurarsi di comprendere le implicazioni della migrazione, incluso ciò che accade in questa fase.

Questo passaggio richiede da tre a sei ore per le migrazioni da v2 a v3 e fino a sei ore per le migrazioni da v1 a v3, a seconda delle dimensioni dell'ambiente. Il ridimensionamento e le modifiche dell'ambiente del servizio app esistente vengono bloccate durante questo passaggio.

Nota

In rari casi, potrebbe essere visualizzata una notifica nel portale che indica che la migrazione all'ambiente del servizio app v3 non è riuscita dopo l'avvio della migrazione. Esiste un bug noto che potrebbe attivare questa notifica anche se la migrazione è in corso. Controllare il log attività dell'ambiente del servizio app per determinare la validità di questo messaggio di errore. Nella maggior parte dei casi, l'aggiornamento della pagina risolve il problema e il messaggio di errore scompare. Se il messaggio di errore persiste, contattare il supporto tecnico per assistenza.

In questo momento, gli stati dettagliati della migrazione sono disponibili solo quando si usa l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere la sezione sull'interfaccia della riga di comando di Azure per la migrazione all'ambiente del servizio app v3. È possibile controllare lo stato della migrazione con l'interfaccia della riga di comando anche se si usa il portale per eseguire la migrazione.

Al termine della migrazione, è disponibile una risorsa ambiente del servizio app v3 e tutte le app sono in esecuzione nel nuovo ambiente. È possibile confermare la versione dell'ambiente controllando la pagina Configurazione dell'ambiente del servizio app.

Se la migrazione include un suffisso di dominio personalizzato, per l'ambiente del servizio app v1/v2 il dominio compariva nella sezione Funzionalità essenziali della pagina Panoramica del portale. Per l'ambiente del servizio app v3, la posizione è diversa. Per l'ambiente del servizio app v3 passare invece alla pagina Suffissi domini personalizzati per verificare che il suffisso di dominio personalizzato sia configurato correttamente. È anche possibile rimuovere la configurazione se non è più necessaria oppure configurarla se non ne è stata creata una in precedenza.

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.

Prezzi

Non è previsto alcun costo per la migrazione dell'ambiente del servizio app. Quando si usa la funzionalità di migrazione sul posto, gli addebiti per l'ambiente del servizio app precedente cessano non appena viene arrestato durante il processo di migrazione. Si iniziano a ricevere addebiti per il nuovo ambiente del servizio app v3 non appena viene distribuito. 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 della conversione dei piani di servizio app da Isolato a 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 sul posto. 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 sul posto?
  La funzionalità di migrazione sul posto è ideale per i clienti che vogliono eseguire la migrazione all'ambiente del servizio app v3 con modifiche minime alle configurazioni di rete e possono supportare circa un'ora di tempo di inattività delle applicazioni. Se non è possibile supportare tempi di inattività, vedere la funzionalità di migrazione affiancata 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. Se si hanno dipendenze da questi specifici indirizzi IP, può essere necessario tenere conto delle modifiche apportate all'indirizzo IP in ingresso e in uscita.
• Durante la migrazione vi sarà un periodo di inattività?
  Sì, bisogna prevedere circa un'ora di tempo di inattività durante l'intervallo di servizio di 3-6 ore nel corso del passaggio di migrazione, quindi pianificare di conseguenza. Se si dispone di un ambiente del servizio app diverso a cui è possibile indirizzare il traffico durante la migrazione usando la funzionalità di migrazione sul posto, è possibile eliminare i tempi di inattività dell'applicazione. Se non si dispone di un altro ambiente del servizio app e non è possibile supportare il tempo di inattività, vedere la funzionalità di migrazione affiancata o le opzioni di migrazione manuale.
• 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 sul posto supporta questo scenario di migrazione.
• Cosa accade se l'ambiente del servizio app è aggiunto alla zona?
  L'ambiente del servizio app aggiunto alla zona v2 è ora uno scenario supportato per la migrazione tramite la funzionalità di migrazione. L'ambiente del servizio app v3 non supporta l'aggiunta a una zona. Quando si esegue la migrazione all'ambiente del servizio app v3, è possibile scegliere se configurare o meno la ridondanza della zona.
• Cosa accade se l'ambiente del servizio app ha 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 sul posto, 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. Per l'ambiente del servizio app ILB, si mantiene lo stesso indirizzo IP del servizio ILB. Per l'ambiente del servizio app con connessione Internet, l'indirizzo IP pubblico e l'indirizzo IP in uscita cambieranno. 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 sul posto, l'ambiente precedente viene arrestato ed eliminato e tutte le app vengono migrate in un nuovo ambiente. L'ambiente precedente non è più accessibile. 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