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

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.

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.

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.

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:

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.

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.

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:

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.

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)

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

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

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

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

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

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

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

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

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

{
    "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"
        }
    }
}

{
    "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"
        }
    }
}

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

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

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

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

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.

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