Dettagli tecnici sulla migrazione a Servizi cloud di Azure (supporto "Extended")

Questo articolo illustra i dettagli tecnici relativi allo strumento di migrazione in relazione a Servizi cloud (versione classica).

Dettagli sulle funzionalità e sugli scenari supportati per la migrazione

Migrazione di estensioni e plug-in

  • Viene eseguita la migrazione di tutte le estensioni abilitate e supportate.
  • Non verrà eseguita la migrazione delle estensioni disabilitate.
  • I plug-in sono un concetto legacy e dovrebbero essere rimossi prima della migrazione. Sono supportati per la migrazione, ma dopo la migrazione, se l'estensione deve essere abilitata, è necessario rimuovere il plug-in prima di installare l'estensione. Questa limitazione influisce maggiormente sui plug-in desktop remoto e sulle estensioni.

Migrazione dei certificati

  • In Servizi cloud (supporto "Extended") i certificati vengono archiviati in un insieme di credenziali delle chiavi. Durante la migrazione per i clienti viene creato un insieme di credenziali delle chiavi il cui nome è quello del servizio cloud e tutti i certificati vengono trasferiti da Azure Service Manager all'insieme di credenziali delle chiavi.
  • Il riferimento a questo insieme di credenziali delle chiavi viene specificato nel modello o passato tramite PowerShell o l'interfaccia della riga di comando di Azure.

File di configurazione e di definizione del servizio

Servizio cloud e distribuzioni

  • Ogni distribuzione di Servizi cloud (supporto "Extended") è un servizio cloud indipendente. Le distribuzioni non vengono più raggruppata in un servizio cloud usando gli slot.
  • Se sono presenti due slot nel servizio cloud (versione classica), è necessario eliminare uno slot (staging) e usare lo strumento di migrazione per spostare l'altro slot (produzione) in Azure Resource Manager.
  • L'IP pubblico nella distribuzione del servizio cloud rimane invariato dopo la migrazione ad Azure Resource Manager ed è esposto come risorsa IP SKU Basic (dinamica o statica).
  • Il nome DNS e il dominio (cloudapp.net) per il servizio cloud migrato rimangono invariati.

Migrazione della rete virtuale

  • Se una distribuzione di Servizi cloud si trova in una rete virtuale, durante la migrazione le risorse di Servizi cloud e di rete virtuale associate vengono migrate insieme.
  • Dopo la migrazione la rete virtuale viene inserita in un gruppo di risorse diverso rispetto al servizio cloud.
  • Per le reti virtuali con più servizi cloud, ogni servizio cloud viene migrato uno dopo l'altro.

Migrazione di distribuzioni non in una rete virtuale

  • Alla fine del 2018 Azure ha iniziato a creare automaticamente nuove distribuzioni (senza la rete virtuale specificata dal cliente) in una piattaforma creata in una rete virtuale "predefinita". Queste reti virtuali predefinite non sono visibili ai clienti.
  • Durante la migrazione questa rete virtuale predefinita è esposta ai clienti una sola volta in Azure Resource Manager. Per gestire o aggiornare la distribuzione in Azure Resource Manager, i clienti devono aggiungere queste informazioni sulla rete virtuale nella sezione NetworkConfiguration del file con estensione cscfg.
  • La rete virtuale predefinita, quando viene eseguita la migrazione ad Azure Resource Manager, viene inserita nello stesso gruppo di risorse del servizio cloud.
  • I Servizi cloud creati prima di questa volta (prima della fine del 2018) non si trovano in alcuna rete virtuale e non possono essere migrati usando lo strumento. Valutare la possibilità di ridistribuire questi servizi cloud direttamente in Azure Resource Manager. Un altro approccio consiste nel eseguire la migrazione tramite la creazione di una nuova distribuzione di staging e VIPSwap Altri dettagli sono disponibili qui
  • Per verificare se una distribuzione è idonea per la migrazione, eseguire l'API di convalida nella distribuzione. Il risultato dell'API di convalida contiene un messaggio di errore che indica in modo esplicito se questa distribuzione è idonea per la migrazione.

Load Balancer

  • Per un servizio cloud che usa un endpoint pubblico, un servizio di bilanciamento del carico creato dalla piattaforma e associato al servizio cloud viene esposto all'interno della sottoscrizione del cliente in Azure Resource Manager. Il servizio di bilanciamento del carico è una risorsa di sola lettura e gli aggiornamenti sono limitati solo tramite i file di configurazione del servizio (con estensione cscfg) e di definizione del servizio (con estensione csdef).

Key Vault

  • Durante la migrazione Azure crea automaticamente un nuovo insieme di credenziali delle chiavi e vi esegue la migrazione di tutti i certificati. Lo strumento non consente di usare un insieme di credenziali delle chiavi esistente.
  • Servizi cloud (supporto "Extended") richiede un insieme di credenziali delle chiavi che si trova nella stessa area e nella stessa sottoscrizione. Questo insieme di credenziali delle chiavi viene creato automaticamente durante la migrazione.

Risorse e funzionalità non disponibili per la migrazione

Questo elenco contiene gli scenari principali che prevedono combinazioni di risorse, funzionalità e Servizi cloud. Questo elenco non è esaustivo.

Conto risorse Passaggi successivi/soluzione alternativa
Regole di scalabilità automatica La migrazione viene eseguita ma le regole vengono eliminate. Ricreare le regole dopo la migrazione in Servizi cloud (supporto "Extended").
Avvisi La migrazione viene eseguita ma gli avvisi vengono eliminati. Ricreare le regole dopo la migrazione in Servizi cloud (supporto "Extended").
Gateway VPN Rimuovere il gateway VPN prima di iniziare la migrazione e quindi ricrearlo al termine.
Gateway ExpressRoute (solo nella stessa sottoscrizione della rete virtuale) Rimuovere il gateway ExpressRoute prima di iniziare la migrazione e quindi ricrearlo al termine.
Obiettivo di vendita La quota non viene migrata. Richiedere una nuova quota in Azure Resource Manager prima della migrazione per il corretto completamento della convalida.
Gruppi di affinità Non supportato. Rimuovere tutti i gruppi di affinità prima della migrazione.
Reti virtuali che usano il peering di reti virtuali Prima di eseguire la migrazione di una rete virtuale con peering a un'altra rete virtuale, eliminare il peering, eseguire la migrazione della rete virtuale a Resource Manager e ricreare il peering. Questo può causare tempi di inattività a seconda dell'architettura.
Rete virtuale contenente ambienti del servizio app Non supportato
Reti virtuali con distribuzioni di Azure Batch Non supportato
Rete virtuale contenente servizi HDInsight Non supportato.
Reti virtuali che contengono distribuzioni di Gestione API Non supportato.

Per eseguire la migrazione della rete virtuale, modificare la rete virtuale della distribuzione di Gestione API. Non si tratta di un'operazione del tempo di inattività.
Circuiti ExpressRoute classici Non supportato.

È necessario eseguire la migrazione di questi circuiti in Azure Resource Manager prima di iniziare la migrazione della piattaforma distribuita come servizio (PaaS). Per altre informazioni, vedere Spostamento dei circuiti ExpressRoute dal modello di distribuzione classica al modello di distribuzione Resource Manager.
Controllo degli accessi in base al ruolo Dopo la migrazione l'URI della risorsa cambia da Microsoft.ClassicCompute a Microsoft.Compute e i criteri di controllo degli accessi in base al ruolo devono essere aggiornati.
Gateway applicazione Non supportato.

Rimuovere il gateway applicazione prima di iniziare la migrazione e quindi ricrearlo al termine in Azure Resource Manager.

Configurazioni/scenari di migrazione supportati

Configurazione/scenario Passaggi successivi/soluzione alternativa
Migrazione di alcune distribuzioni meno recenti non in una rete virtuale Alcune distribuzioni di Servizi cloud non in una rete virtuale non sono supportate per la migrazione.

1. Usare l'API di convalida per verificare se la distribuzione è idonea per la migrazione.
2. Se è idonea, le distribuzioni sono spostate in Azure Resource Manager in una rete virtuale con prefisso "DefaultRdfeVnet"
Migrazione delle distribuzioni contenenti distribuzione di slot di produzione e di staging tramite indirizzi IP dinamici La migrazione di un servizio cloud a due slot richiede l'eliminazione dello slot di staging. Dopo aver eliminato lo slot di staging, eseguire la migrazione dello slot di produzione come servizio cloud indipendente (supporto "Extended") in Azure Resource Manager. Ridistribuire quindi l'ambiente di gestione temporanea come nuovo servizio cloud (supporto "Extended") e renderlo scambiabile con il primo.
Migrazione delle distribuzioni contenenti distribuzione di slot di produzione e di staging tramite indirizzi IP riservati Non supportato.
Migrazione della distribuzione di produzione e di staging in una rete virtuale diversa La migrazione di un servizio cloud a due slot richiede l'eliminazione dello slot di staging. Dopo aver eliminato lo slot di staging, eseguire la migrazione dello slot di produzione come servizio cloud indipendente (supporto "Extended") in Azure Resource Manager. Una nuova distribuzione di Servizi cloud (supporto "Extended") può quindi essere collegata alla distribuzione migrata con la proprietà scambiabile abilitata. I file di distribuzione della precedente distribuzione dello slot di staging possono essere riusati per creare questa nuova distribuzione scambiabile.
Migrazione di un servizio cloud vuoto (servizio cloud senza distribuzione) Non supportato.
Migrazione della distribuzione contenente il plug-in e le estensioni del desktop remoto Opzione 1: rimuovere il plug-in del desktop remoto prima della migrazione. Questa operazione richiede modifiche ai file di distribuzione. La migrazione passa quindi attraverso.

Opzione 2: rimuovere l'estensione del desktop remoto ed eseguire la migrazione della distribuzione. Dopo la migrazione rimuovere il plug-in e installare l'estensione. Questa operazione richiede modifiche ai file di distribuzione.

Rimuovere il plug-in e l'estensione prima della migrazione. I plug-in non sono consigliati per l'uso in Servizi cloud (supporto "Extended").
Reti virtuali con distribuzione PaaS e IaaS Non supportato

Spostare le distribuzioni PaaS o IaaS in una rete virtuale diversa. Ciò causa tempi di inattività.
Distribuzioni del servizio cloud che usano dimensioni del ruolo legacy, ad esempio Small o ExtraLarge Le dimensioni del ruolo devono essere aggiornate prima della migrazione. Aggiornare tutti gli artefatti di distribuzione per fare riferimento a queste nuove dimensioni del ruolo moderno. Per altre informazioni, vedere Dimensioni delle macchine virtuali disponibili
Migrazione del servizio cloud a una rete virtuale diversa Non supportate

1. Spostare la distribuzione in una rete virtuale classica diversa prima della migrazione. Ciò causa tempi di inattività.
2. Eseguire la migrazione della nuova rete virtuale ad Azure Resource Manager.

Oppure

1. Eseguire la migrazione della rete virtuale ad Azure Resource Manager.
2. Spostare il servizio cloud in una nuova rete virtuale. Ciò causa tempi di inattività.
Servizio cloud in una rete virtuale ma senza una subnet esplicita assegnata Non supportato. La mitigazione comporta lo spostamento del ruolo in una subnet che richiede un riavvio del ruolo (tempo di inattività)

Traduzione di risorse e convenzioni di denominazione dopo la migrazione

Durante la migrazione i nomi delle risorse vengono modificati e alcune funzionalità di Servizi cloud vengono esposte come risorse di Azure Resource Manager. La tabella riepiloga le modifiche specifiche per la migrazione di Servizi cloud.

Servizi cloud (versione classica)

Nome risorsa
Servizi cloud (versione classica)

Sintassi
Servizi cloud (supporto "Extended")

Nome risorsa
Servizi cloud (supporto "Extended")

Sintassi
Servizio cloud cloudservicename Non associato Non associato
Distribuzione (creata nel portale)

Distribuzione (creazione non-portale)
deploymentname Servizi cloud (supporto "Extended") cloudservicename
Rete virtuale vnetname

Group resourcegroupname vnetname

Non associato
Rete virtuale (non creata nel portale)

Rete virtuale (creata nel portale)

Reti virtuali (predefinita)
vnetname

group-resourcegroupname-vnetname

VNet-cloudservicename
Non associato Non associato Key Vault KV-cloudservicename
Non associato Non associato Gruppo di risorse per distribuzioni dei servizi cloud cloudservicename-migrated
Non associato Non associato Gruppo di risorse per la rete virtuale vnetname-migrated

group-resourcegroupname-vnetname-migrated
Non associato Non associato IP pubblico (dinamico) cloudservicenameContractContract
Nome IP riservato reservedipname IP riservato (creato non-portale)

IP riservato (creato nel portale)
reservedipname

group-resourcegroupname-reservedipname
Non associato Non associato Load Balancer LB-cloudservicename

Problemi di migrazione e come gestirli

Migrazione bloccata per molto tempo in un'operazione.

  • Il commit, la preparazione e l'interruzione possono richiedere molto tempo a seconda del numero di distribuzioni. Il timeout delle operazioni si verifica dopo 24 ore.
  • Le operazioni di commit, di preparazione e di interruzione sono idempotenti. È possibile risolvere la maggior parte dei problemi ripetendo l'operazione. Potrebbero verificarsi errori temporanei, che possono risolversi in pochi minuti, quindi è consigliabile ripetere l'operazione dopo qualche tempo. Se si esegue la migrazione usando il portale di Azure e l'operazione rimane bloccata in uno stato "in corso", usare PowerShell per ripetere l'operazione.
  • Contattare il supporto tecnico per eseguire la migrazione o il rollback della distribuzione dal back-end.

Migrazione non riuscita in un'operazione.

  • Se convalida non riesce è perché la distribuzione o la rete virtuale contiene scenari/funzionalità/risorse non supportati. Usare l'elenco di scenari non supportati per trovare la soluzione alternativa nei documenti.
  • L'operazione di preparazione esegue prima la convalida, incluse alcune convalide onerose (non trattate nella convalida). L'errore di preparazione potrebbe essere dovuto a uno scenario non supportato. Trovare lo scenario e la soluzione alternativa nei documenti pubblici. È necessario chiamare l'interruzione per tornare allo stato originale e sbloccare la distribuzione per le operazioni di aggiornamento ed eliminazione.
  • Se l'interruzione non riesce, ripetere l'operazione. Se i tentativi non riescono, contattare il supporto tecnico.
  • Se il commit non riesce, ripetere l'operazione. Se il tentativo non riesce, contattare il supporto tecnico. Anche in caso di errore di commit, non dovrebbe esserci alcun problema nel piano dati per la distribuzione. La distribuzione dovrebbe poter gestire il traffico dei clienti senza problemi.

Portale aggiornato dopo la preparazione. Esperienza riavviata e commit o interruzione non più visibile.

  • Il portale archivia le informazioni di migrazione in locale e quindi, dopo l'aggiornamento, inizierà dalla fase di convalida anche se il servizio cloud è in fase di preparazione.
  • È possibile usare il portale per ripetere la procedura di convalida e di preparazione ed esporre il pulsante per interruzione e commit. Non causerà errori.
  • I clienti possono usare PowerShell o l'API REST per interrompere o eseguire il commit.

Quanto tempo possono richiedere le operazioni?

La convalida è progettata per essere rapida. La preparazione è a esecuzione prolungata e richiede più tempo a seconda del numero totale di istanze del ruolo di cui viene eseguita la migrazione. L'interruzione e il commit possono richiedere tempo, ma in misura minore rispetto alla preparazione. Tutte le operazioni raggiungono in timeout dopo 24 ore.

Passaggi successivi

Per assistenza durante la migrazione della distribuzione di Servizi cloud (versione classica) a Servizi cloud (supporto "Extended") vedere la pagina di destinazione Supporto e risoluzione dei problemi.