Riallocare un'applicazione locale eseguendo la migrazione alle macchine virtuali di Azure e a Istanza gestita di SQL di Azure

  • Articolo

Questo articolo illustra come contoso società fittizia esegue la migrazione di un'applicazione front-end a due livelli basata su Windows .NET da macchine virtuali VMware a una macchina virtuale di Azure usando Azure Migrate. L'articolo illustra anche come Contoso esegue la migrazione del database dell'applicazione a Istanza gestita di SQL di Azure. Questa migrazione segue le operazioni di preparazione descritte in Distribuire un'infrastruttura di migrazione.

SmartHotel360, l'applicazione in questo esempio è software open source. Se si intende usarla per scopi di test personalizzati, è possibile scaricarla da GitHub.

Nota

L'applicazione di esempio in questo articolo, SmartHotel360, viene archiviata, ma rimane disponibile in GitHub per informazioni di riferimento.

Driver di business

Il team di leadership IT di Contoso lavora strettamente con i partner aziendali dell'azienda per capire cosa vogliono ottenere questa migrazione. Vogliono raggiungere gli obiettivi seguenti:

  • Stare al passo con la crescita aziendale. Contoso è in crescita. Di conseguenza, la pressione è aumentata sui sistemi locali e l'infrastruttura dell'azienda.

  • Aumentare l'efficienza. Occorre rimuovere le procedure inutili e semplificare i processi per sviluppatori e utenti. Per consentire all'azienda di offrire rapidamente i requisiti dei clienti, il team IT deve essere veloce e non perdere tempo o denaro.

  • Aumentare l'agilità. L'IT deve essere più reattivo alle esigenze dell'azienda. Per avere successo nell'economia globale, Contoso deve reagire più velocemente rispetto ai cambiamenti che si verificano nel marketplace. Il reparto IT di Contoso non deve rappresentare un ostacolo per le attività aziendali.

  • Scalabilità. Man mano che l'azienda cresce correttamente, il team IT deve fornire sistemi che possono crescere allo stesso ritmo.

Obiettivi della migrazione

Contoso usa gli obiettivi di migrazione per determinare i metodi migliori della migrazione. Il team cloud di Contoso ha identificato gli obiettivi per questa migrazione:

  • Prestazioni dell'applicazione uguali. Dopo la migrazione, l'applicazione in Azure dovrà avere le stesse caratteristiche di prestazioni di cui dispone attualmente nell'ambiente VMware locale di Contoso. La migrazione dell'applicazione al cloud non significa che le prestazioni sono meno critiche.

  • Nessuna applicazione di sviluppo. Contoso non vuole investire nell'applicazione. L'applicazione è fondamentale e importante per l'azienda, ma vogliono semplicemente spostarla nel cloud nel formato corrente.

  • Amministrazione minima. Le attività di amministrazione del database vengono ridotte al minimo dopo la migrazione dell'applicazione.

  • Evitare Azure SQL Database. Contoso non vuole usare un database SQL di Azure per questa applicazione e sta cercando possibili alternative.

Progettazione della soluzione

Dopo aver chiaro gli obiettivi e i requisiti dell'azienda, Contoso progetta e esamina una soluzione di distribuzione. Contoso identifica anche il processo di migrazione e i servizi di Azure da usare.

Architettura corrente

  • Contoso dispone di un data center principale, contoso-datacenterche si trova a New York City. Ha una connessione fibra ottica a Internet da Metro Ethernet Networks che fornisce 500 megabit al secondo. Il data center principale è completamente virtualizzato dai prodotti VMware. Contoso dispone di due host VMware che eseguono ESXi 6.5 gestiti da vCenter Server 6.5.

  • Contoso ha tre rami tra le Stati Uniti. Ogni ramo è connesso localmente a Internet usando connessioni di classe business e ogni ramo è connesso al data center principale tramite VPN con IPsec. Questa configurazione consente all'intera rete di Contoso di essere sempre connessa e ottimizza la connettività Internet.

  • Contoso usa i server DNS nella rete interna.

  • Contoso usa Active Directory per la gestione delle identità

  • Contoso dispone di un controller di dominio locale, contosodc1. Il controller di dominio nelle filiali locali vengono eseguiti in server fisici. I controller di dominio vengono eseguiti in macchine virtuali VMware. L'ambiente VMware è gestito da vCenter Server 6.5, vcenter.contoso.comin esecuzione in una macchina virtuale.

  • SmartHotel360 è a livelli in due macchine virtuali WEBVM e SQLVM, che si trovano in un host VMware che esegue ESXi versione 6.5, contosohost1.contoso.com.

Diagramma dell'architettura contoso corrente.

Architettura proposta

In questo scenario Contoso esegue la migrazione dell'applicazione di viaggio locale a due livelli, come indicato di seguito:

  • Eseguire la migrazione del database dell'applicazione, SmartHotelDB, a un Istanza gestita di SQL.
  • Eseguire la migrazione della macchina virtuale WEBVM front-end a una macchina virtuale di Azure.
  • Rimuovere le macchine virtuali locali nel data center Contoso dopo il completamento della migrazione.

Diagramma dell'architettura dello scenario.

Considerazioni sul database

Nell'ambito della progettazione della soluzione, Contoso confronta le funzionalità tra database Azure SQL e Istanza gestita di SQL. L'azienda sceglie istanze gestite da SQL a causa delle considerazioni seguenti:

  • Compatibilità con il software esistente.

    • Istanza gestita di SQL mira a offrire una compatibilità quasi del 100% con la versione locale più recente di SQL Server. È consigliabile Istanza gestita di SQL per i clienti che eseguono SQL Server locali o sull'infrastruttura come servizio (IaaS) e che vogliono eseguire la migrazione delle applicazioni a un servizio completamente gestito con modifiche di progettazione minime. Per altre informazioni, vedere Informazioni Istanza gestita di SQL di Azure?

    • Contoso prevede di eseguire la migrazione di un numero elevato di applicazioni da locale a IaaS. Molte di queste applicazioni vengono fornite da un ISV. Contoso si rende conto che l'uso di Istanza gestita di SQL consente di garantire la compatibilità del database per queste applicazioni. Al contrario, database SQL potrebbe non essere supportato.

    • Istanza gestita di SQL supporta SQL Server Agent, che è un componente importante di SmartHotel360. Senza questa compatibilità, Contoso dovrà riprogettare i piani di manutenzione necessari per l'applicazione.

  • Scambio di licenze. Con Software Assurance, Contoso può scambiare le licenze esistenti per i tassi scontati in un'istanza gestita di SQL usando il Vantaggio Azure Hybrid per SQL Server. Ciò consente a Contoso di risparmiare fino al 30% su Istanza gestita di SQL.

  • Tecnologia di sicurezza e isolamento della rete.

    • Istanza gestita di SQL supporta molte funzionalità di sicurezza, tra cui Always Encrypted, maschera dati dinamica, sicurezza a livello di riga e rilevamento delle minacce.

    • Istanza gestita di SQL è completamente contenuto nella rete virtuale, che offre un maggiore isolamento e sicurezza per i dati di Contoso. Contoso può quindi usufruire dei vantaggi del cloud pubblico, mantenendo al contempo l'ambiente isolato dalla rete Internet pubblica.

  • Migrazione automatica. Contoso può eseguire la migrazione a Istanza gestita di SQL usando il Servizio Migrazione del database di Azure completamente automatizzato. Contoso potrà anche riusare questo servizio per le migrazioni di database future.

Revisione della soluzione

Contoso valuta l'architettura proposta elaborando un elenco di vantaggi e svantaggi.

Considerazioni Dettagli
Vantaggi Contoso può passare WEBVM ad Azure senza modifiche, che semplifica la migrazione.

L'istanza gestita di SQL supporta i requisiti tecnici e gli obiettivi di Contoso.

Istanza gestita di SQL offre la compatibilità del 100% con la distribuzione corrente di Contoso mentre si sposta l'azienda dall'uso di SQL Server 2008 R2.

Contoso può sfruttare i propri investimenti in Software Assurance e usare l'offerta Vantaggio Azure Hybrid per SQL Server e Windows Server.

L'azienda può usare nuovamente il Servizio Migrazione del database di Azure per altre migrazioni future.

Istanza gestita di SQL integra la funzionalità per la tolleranza di errore, pertanto Contoso non dovrà configurarla. Ciò garantisce che il livello dati non sia più un singolo punto di failover.
Svantaggi WEBVM esegue Windows Server 2008 R2. Anche se Azure supporta questo sistema operativo, non è più una piattaforma supportata. Per altre informazioni, vedere Criteri di supporto per i prodotti Microsoft SQL Server.

Il livello Web rimane un singolo punto di failover con servizi offerti solo dalla macchina virtuale WEBVM.

Contoso deve continuare a supportare il livello Web dell'applicazione come macchina virtuale anziché passare a un servizio gestito, ad esempio Servizio app di Azure.

Per il livello dati, Istanza gestita di SQL potrebbe non essere la soluzione ideale se Contoso intende personalizzare il sistema operativo o il server di database oppure se vuole eseguire applicazioni di terze parti con SQL Server. L'esecuzione di SQL Server in una VM IaaS potrebbe garantire questa flessibilità.

Processo di migrazione

Contoso esegue la migrazione dei livelli web e dati dell'applicazione SmartHotel360 ad Azure completando questi passaggi:

  1. Aggiungere un paio di componenti specifici all'infrastruttura di Azure configurata in precedenza da Contoso (come descritto in Distribuire un'infrastruttura di migrazione). Gran parte dell'infrastruttura necessaria per questa migrazione è già disponibile.

  2. Eseguire la migrazione del livello dati usando Servizio Migrazione del database di Azure. Questo servizio si connette alla macchina virtuale locale che esegue SQL Server tramite una connessione VPN da sito a sito tra il data center Contoso e Azure. Il servizio esegue quindi la migrazione del database.

  3. Eseguire la migrazione del livello Web usando Azure Migrate. Il processo richiede la preparazione dell'ambiente VMware locale, la configurazione e l'abilitazione della replica e la migrazione delle macchine virtuali tramite il failover in Azure.

    Diagramma dell'architettura di migrazione.

Servizi di Azure

Servizio Descrizione Costi
Servizio Migrazione del database di Azure Consente di eseguire facilmente la migrazione di più origini di database a piattaforme dati di Azure, con tempi di inattività minimi. Vedere altre informazioni sulle aree supportate e sui prezzi del Servizio Migrazione del database di Azure.
Istanza gestita di database SQL di Azure Istanza gestita di SQL è un servizio di database gestito che rappresenta un'istanza completamente gestita di SQL Server nel cloud di Azure. Usa lo stesso codice della versione più aggiornata del motore di database di SQL Server e dispone delle funzionalità, dei miglioramenti delle prestazioni e delle patch di sicurezza più recenti. L'uso di Istanza gestita di SQL di Azure è soggetto a costi in base alla capacità. Altre informazioni sui prezzi di Istanza gestita di SQL.
Azure Migrate Contoso usa Azure Migrate per valutare le macchine virtuali VMware. Azure Migrate valuta l'idoneità alla migrazione delle macchine. Fornisce stime di dimensioni e costi per l'esecuzione in Azure. Azure Migrate è disponibile senza costi aggiuntivi. Potrebbero essere addebitati costi in base agli strumenti (proprietari o di fornitori software indipendenti) che l'azienda decide di usare per la valutazione e la migrazione. Altre informazioni sui prezzi di Azure Migrate.

Prerequisiti

Contoso e gli altri utenti devono soddisfare i prerequisiti seguenti per questo scenario.

Requisiti Dettagli
Sottoscrizione di Azure Contoso ha creato una sottoscrizione nel primo articolo di questa serie. Se non si ha una sottoscrizione di Azure, creare un account gratuito.

Se si crea un account gratuito, si è l'amministratore della sottoscrizione e si possono eseguire tutte le azioni.

Se si usa una sottoscrizione esistente e non si è l'amministratore della sottoscrizione, rivolgersi all'amministratore per assegnare le autorizzazioni proprietario o collaboratore ai gruppi di risorse e alle risorse necessari.
Infrastruttura di Azure Contoso configura l'infrastruttura di Azure come descritto in Distribuzione di un'infrastruttura di migrazione.
Server locali Il server vCenter locale deve eseguire la versione 5.5, 6.0 o 6.5.

L'host ESXi deve eseguire la versione 5.5, 6.0 o 6.5.

L'host ESXi deve eseguire una o più macchine virtuali VMware.
VM locali Esaminare i computer Linux approvati per l'esecuzione in Azure.
Servizio Migrazione del database di Azure Per il Servizio Migrazione del database di Azure è necessario un dispositivo VPN locale compatibile.

È necessario saper configurare il dispositivo VPN locale. Deve avere un indirizzo IPv4 pubblico esterno. che non può trovarsi dietro un dispositivo NAT.

Assicurarsi di poter accedere al database SQL Server locale.

Windows Firewall deve essere in grado di accedere al motore di database di origine. Per altre informazioni, vedere Configurazione di Windows Firewall per l'accesso al Motore di database.

Se il computer in cui si trova il database è protetto da un firewall, aggiungere regole per consentire l'accesso al database e ai file tramite la porta SMB 445.

Le credenziali per la connessione all'istanza di origine di SQL Server e per il Istanza gestita di SQL di destinazione devono essere membri del ruolo del server sysadmin.

Nel database locale deve essere presente una condivisione di rete che può essere usata dal Servizio Migrazione del database di Azure per eseguire il backup del database di origine.

Assicurarsi che l'account del servizio che esegue l'istanza di origine di SQL Server disponga delle autorizzazioni di scrittura per la condivisione di rete.

Prendere nota di un utente e di una password di Windows con autorizzazioni di controllo completo per la condivisione di rete. Servizio Migrazione del database di Azure rappresenta queste credenziali utente per caricare i file di backup nel contenitore di Archiviazione di Azure.

Il processo di installazione per SQL Server Express imposta il protocollo TCP/IP su Disabilitato per impostazione predefinita. Assicurarsi che sia impostato su Abilitato.

Passaggi dello scenario

Ecco come Contoso intende configurare la distribuzione:

  • Passaggio 1: Preparazione di un'istanza gestita di SQL. Contoso richiede un'istanza gestita esistente in cui viene eseguita la migrazione del database SQL Server locale.

  • Passaggio 2: Preparazione del Servizio Migrazione del database di Azure. Contoso deve registrare il provider di migrazione del database, creare un'istanza e quindi creare un progetto di servizio di gestione del database. Contoso deve anche configurare un URI (Uniform Resource Identifier) della firma di accesso condiviso per l'istanza di Servizio Migrazione del database. Un URI di firma di accesso condiviso assicura l'accesso delegato alle risorse dell'account di archiviazione di Contoso, in modo che quest'ultima possa concedere autorizzazioni limitate per gli oggetti di archiviazione. Contoso configura un URI di SAS per consentire al Servizio Migrazione del database di Azure di accedere al contenitore dell'account di archiviazione in cui il servizio carica i file di backup di SQL Server.

  • Passaggio 3: Preparare Azure per lo strumento di migrazione e modernizzazione. Contoso aggiunge questo strumento che fa parte di Azure Migrate al progetto Azure Migrate. La migrazione e la modernizzazione erano denominate in precedenza Azure Migrate: Migrazione server.

  • Passaggio 4: Preparare VMware locale per lo strumento di migrazione e modernizzazione. Contoso prepara gli account per l'individuazione delle macchine virtuali e si prepara per la connessione alle macchine virtuali di Azure dopo la migrazione.

  • Passaggio 5: Replica delle macchine virtuali locali. Contoso configura e avvia la replica delle macchine virtuali in Archiviazione di Azure.

  • Passaggio 6: Migrazione del database tramite il Servizio Migrazione del database di Azure. Contoso esegue la migrazione del database.

  • Passaggio 7: Eseguire la migrazione delle macchine virtuali con lo strumento di migrazione e modernizzazione. Contoso esegue una migrazione di test per verificare che tutto funzioni correttamente e una migrazione completa per spostare le macchine virtuali in Azure.

Passaggio 1: Preparazione di un'istanza gestita di SQL

Per configurare un'istanza gestita di SQL, Contoso richiede una subnet che soddisfi i requisiti seguenti:

  • Connette solo l'istanza gestita. La subnet deve essere dedicata. Deve essere vuota. Non può contenere altri servizi cloud. Non può essere una subnet del gateway. Dopo aver creato l'istanza gestita, Contoso non deve aggiungere risorse alla subnet.

  • Non in un gruppo di sicurezza di rete. Alla subnet non deve essere associato alcun gruppo di sicurezza di rete.

  • Instrada solo a Internet. La subnet deve avere una tabella di route definita dall'utente. L'unica route assegnata deve essere 0.0.0.0/0 per Internet hop successivo.

  • Non ha alcun endpoint di servizio. Alla subnet non deve essere associato un endpoint di servizio, sia per l'archiviazione che per SQL. Gli endpoint di servizio devono essere disabilitati nella rete virtuale.

  • Ha almeno 16 indirizzi IP. La subnet deve avere un minimo di 16 indirizzi IP. Per altre informazioni sul dimensionamento della subnet per l'istanza gestita, vedere Configurare una rete virtuale esistente per Istanza gestita di SQL di Azure.

  • Con DNS personalizzato, include un sistema di risoluzione specifico. Contoso configura la risoluzione dei nomi DNS per l'uso di uno o più server DNS di Azure della società. A causa dell'ambiente ibrido di Contoso, devono anche usare impostazioni DNS personalizzate. Per usare DNS personalizzato, Contoso deve aggiungere 168.63.129.16, un indirizzo IP virtuale, all'elenco dei resolver ricorsivi in Azure. Per altre informazioni sul DNS personalizzato per un'istanza gestita, vedere Risolvere i nomi di dominio privati in Istanza gestita di SQL di Azure.

Configurare una rete virtuale per l'istanza gestita

Per configurare la rete virtuale, gli amministratori contoso completano i passaggi seguenti:

  1. Creare una nuova rete virtuale, VNET-SQLMI-EUS2, nell'area primaria . East US 2 Contoso aggiunge la rete virtuale a ContosoNetworkingRG, un gruppo di risorse.

  2. Assegnano uno spazio di indirizzi 10.235.0.0/24 Contoso verifica che l'intervallo non si sovrapponga ad altre reti dell'azienda.

  3. Aggiungono due subnet alla rete:

    • SQLMI-DB-EUS2 con un intervallo di indirizzi di 10.235.0.0/25.
    • SQLMI-SAW-EUS2 con un intervallo di indirizzi di 10.235.0.128/29. Questa subnet collega una directory all'istanza gestita.

    Screenshot che mostra il riquadro Crea rete virtuale.

  4. Dopo aver distribuito la rete virtuale e le subnet, Contoso aggiunge il peering di rete come segue:

    • Eseguire il peering VNET-SQLMI-EUS2 con VNET-HUB-EUS2, ovvero la rete virtuale hub in East US 2.
    • Eseguire il peering VNET-SQLMI-EUS2 con VNET-PROD-EUS2, ovvero la rete di produzione.

    Screenshot che mostra il peering di rete.

  5. Configurano le impostazioni DNS personalizzate. DNS punta prima ai controller di dominio di Contoso in Azure. Il DNS di Azure è secondario. I controller di dominio di Contoso sono configurati come segue:

    • Si trova nella PROD-DC-EUS2 subnet in VNET-PROD-EUS2, ovvero la rete di produzione in East US 2.
    • CONTOSODC3 con l'indirizzo 10.245.42.4IP .
    • CONTOSODC4 indirizzo con l'indirizzo 10.245.42.5IP .
    • Resolver DNS di Azure con l'indirizzo 168.63.129.16IP .

    Screenshot che mostra i server DNS di rete.

Ulteriore assistenza?

Configurare il routing

Una rete virtuale privata connette l'istanza gestita. Contoso ha bisogno di una tabella di route per consentire alla rete virtuale di comunicare con il servizio di gestione di Azure. Se la rete virtuale non può comunicare con il servizio che la gestisce, diventa inaccessibile.

Contoso considera questi fattori:

  • La tabella di route contiene un set di regole (route) che specifica in che modo i pacchetti inviati dall'istanza gestita devono essere indirizzati nella rete virtuale.
  • Ogni pacchetto che lascia una subnet segue la route specificata dalla tabella di route associata.
  • Una subnet ha una singola tabella di route associata, ma una tabella di route può specificare il routing per più subnet.
  • Non sono previsti costi aggiuntivi per la creazione di tabelle di route in Microsoft Azure.

Per configurare il routing, gli amministratori di Contoso completano i passaggi seguenti:

  1. Creare una tabella di route definita dall'utente, denominata MIRouteTable, assegnata a ContosoNetworkingRG, un gruppo di risorse.

    Screenshot che mostra la tabella di route.

  2. Aggiungere una route con prefisso di indirizzo .0.0.0.0/0 L'opzione Tipo hop successivo è impostata su Internet. Questa configurazione soddisfa i requisiti relativi alle Istanza gestita di SQL.

    Screenshot che mostra il prefisso della tabella di route.

  3. Associare la tabella di route alla SQLMI-DB-EUS2 subnet nella VNET-SQLMI-EUS2 rete.

    Screenshot che mostra la subnet della tabella di route.

Ulteriore assistenza?

Creare un'istanza gestita

Con la rete virtuale e la tabella di route sul posto, gli amministratori contoso possono effettuare il provisioning di un'istanza gestita di SQL completando i passaggi seguenti:

  1. Poiché l'istanza gestita gestisce un'applicazione aziendale, distribuisce l'istanza gestita nell'area primaria dell'azienda, East US 2. e la aggiungono al gruppo di risorse ContosoRG.

  2. Selezionano un piano tariffario, le dimensioni di calcolo e l'archiviazione per l'istanza. Per altre informazioni sui costi, vedere prezzi di Istanza gestita di SQL.

    Screenshot che mostra il riquadro Istanza gestita di SQL.

  3. Con la distribuzione dell'istanza gestita, ContosoRG include due nuove risorse:

    • L'istanza gestita di SQL.
    • Un cluster virtuale in grado di supportare più istanze gestite.

    Screenshot che mostra due nuove risorse.

Ulteriore assistenza?

Guida introduttiva: Creare un Istanza gestita di SQL di Azure.

Passaggio 2: Preparazione del Servizio Migrazione del database di Azure

Per preparare Servizio Migrazione del database di Azure, gli amministratori di Contoso devono completare le attività seguenti:

  • Registrare il provider del Servizio Migrazione del database in Azure.

  • Concedere l'autorizzazione per Servizio Migrazione del database per accedere ad Archiviazione di Azure per caricare i file di backup usati dal servizio per eseguire la migrazione di un database. Per fornire l'accesso ad Archiviazione di Azure:

    • Creano un contenitore Archiviazione BLOB di Azure.
    • e generano un URI di SAS per quest'ultimo.

  • Creano un progetto di Servizio Migrazione del database di Azure.

Gli amministratori di Contoso completano i passaggi seguenti:

  1. Registrare il provider di migrazione del database nella sottoscrizione di Contoso.

    Screenshot che mostra Servizio Migrazione del database registrazione.

  2. Creano un contenitore Archiviazione BLOB di Azure. Contoso genera un URI di SAS in modo che il Servizio Migrazione del database di Azure possa accedervi.

    Screenshot che mostra la generazione di un URI di firma di accesso condiviso.

  3. Creare un'istanza del servizio Migrazione del database di Azure.

    Screenshot che mostra la creazione di un'istanza.

  4. Inseriscono l'istanza del Servizio Migrazione del database nella subnet PROD-DC-EUS2 della rete virtuale VNET-PROD-DC-EUS2.

    • L'istanza deve trovarsi in PROD-DC-EUS2 perché il servizio deve trovarsi in una rete virtuale in grado di accedere alla macchina virtuale locale che esegue SQL Server tramite un gateway VPN.
    • VNET-PROD-EUS2 è sottoposto a peering a VNET-HUB-EUS2 e dispone dell'autorizzazione per l'uso di gateway remoti. Questa autorizzazione garantisce che l'istanza possa comunicare in base alle esigenze. Contoso seleziona Usa gateway remoti per abilitare questa configurazione.

    Screenshot che mostra la configurazione di una rete.

Ulteriore assistenza?

Passaggio 3: Preparare Azure per lo strumento di migrazione e modernizzazione

Per poter eseguire la migrazione delle macchine virtuali, Contoso deve completare le attività seguenti:

  • Creare una rete virtuale per le macchine virtuali di Azure create durante la migrazione.
  • Effettuare il provisioning dello strumento di migrazione e modernizzazione, incluso in Azure Migrate.

Quando Contoso ha preparato la migrazione ad Azure in Distribuire un'infrastruttura di migrazione, configura una rete che lo strumento di migrazione e modernizzazione può usare.

  • SmartHotel360 è un'applicazione di produzione e la migrazione inserisce le macchine virtuali nella rete di produzione di Azure, , VNET-PROD-EUS2nell'area primaria, East US 2.
  • ContosoRG, un gruppo di risorse per le risorse di produzione, include entrambe le macchine virtuali.
  • La macchina virtuale front-end dell'applicazione, WEBVM, esegue la migrazione alla subnet front-end, PROD-FE-EUS2, della rete di produzione.
  • La macchina virtuale del database dell'applicazione, SQLVM, esegue la migrazione alla subnet del database, PROD-DB-EUS2, della rete di produzione.

Passaggio 4: Preparare VMware locale per lo strumento di migrazione e modernizzazione

Per eseguire la migrazione delle macchine virtuali ad Azure, Contoso deve avere i componenti di Azure seguenti:

  • Una rete virtuale per le macchine virtuali di Azure quando vengono create durante la migrazione.
  • L'appliance di Azure Migrate, di cui è stato effettuato il provisioning e la configurazione.

Gli amministratori di Contoso configurano questi componenti completando i passaggi seguenti:

  1. Quando Contoso ha preparato la migrazione ad Azure in Distribuire un'infrastruttura di migrazione, configura una rete che lo strumento di migrazione e modernizzazione può usare.

    • L'applicazione SmartHotel360 è un'applicazione di produzione e, nella migrazione, le macchine virtuali passano alla rete di produzione di Azure, , VNET-PROD-EUS2nell'area primaria, East US 2.
    • ContosoRG, un gruppo di risorse per le risorse di produzione, include entrambe le macchine virtuali.
    • La macchina virtuale front-end dell'applicazione, WEBVM, esegue la migrazione alla subnet front-end, PROD-FE-EUS2, della rete di produzione.
    • La macchina virtuale del database dell'applicazione, SQLVM, esegue la migrazione alla subnet del database, PROD-DB-EUS2, della rete di produzione.

  2. Effettuare il provisioning dell'appliance Azure Migrate.

    1. Scaricare il file di immagine .OVA da Azure Migrate e importarlo in VMware.

      Screenshot che mostra il download del file OVA.

    2. Avviare l'immagine importata e configurare lo strumento seguendo questa procedura:

      1. Configurare i prerequisiti.

        Screenshot che mostra la configurazione dei prerequisiti.

      2. Far puntare lo strumento alla sottoscrizione di Azure.

        Screenshot che mostra la selezione della sottoscrizione

      3. Impostare le credenziali di VMware vCenter.

        Screenshot che mostra l'impostazione delle credenziali VMware vCenter.

      4. Aggiungere le credenziali basate su Linux o Windows per l'individuazione.

        Screenshot che mostra l'impostazione delle credenziali di Linux e Windows.

  3. Dopo la configurazione, lo strumento impiega del tempo per enumerare tutte le macchine virtuali. Al termine dell'enumerazione, gli amministratori contoso possono visualizzare le macchine virtuali popolate nello strumento Azure Migrate in Azure.

Ulteriore assistenza?

Strumento di migrazione e modernizzazione

Preparare le macchine virtuali locali

Dopo la migrazione, Contoso vuole connettersi alle macchine virtuali di Azure e consentire ad Azure di gestirle. Prima della migrazione, gli amministratori di Contoso devono completare le operazioni seguenti:

  1. Per l'accesso tramite Internet:

    • Abilitare RDP o SSH nella macchina virtuale locale prima della migrazione.
    • Aggiungere regole TCP e UDP per il profilo Pubblico , se necessario.
    • Verificare che il firewall del sistema operativo consenta le connessioni RDP o SSH.

  2. Per l'accesso tramite VPN da sito a sito:

    • Abilitare RDP o SSH nella macchina virtuale locale prima della migrazione.
    • Verificare che il firewall del sistema operativo consenta le connessioni RDP o SSH.
    • Per Windows, impostare i criteri SAN del sistema operativo nella macchina virtuale locale su OnlineAll.

  3. Installare l'agente di Azure:

  4. Altre considerazioni:

    • Per Windows non devono essere presenti aggiornamenti in sospeso per Windows nella macchina virtuale all'avvio di una migrazione. Se sono presenti aggiornamenti in sospeso, nessuno è in grado di accedere alla macchina virtuale fino a quando Windows non completa gli aggiornamenti.
    • Dopo la migrazione, un amministratore può controllare la diagnostica di avvio per visualizzare uno screenshot della macchina virtuale. Se questo metodo non funziona, un amministratore deve verificare che la macchina virtuale sia in esecuzione ed esaminare questi suggerimenti per la risoluzione dei problemi.

Ulteriore assistenza?

Passaggio 5: Replica delle macchine virtuali locali

Prima che gli amministratori di Contoso possano eseguire la migrazione dei server in Azure, è necessario configurare e abilitare la replica.

Al termine dell'individuazione, gli amministratori possono avviare la replica di macchine virtuali VMware in Azure. Completano quindi i passaggi seguenti:

  1. Nel progetto Azure Migrate passare a Server>Azure Migrate: Migrazione server. Selezionare quindi Replica.

    Screenshot che mostra l'opzione Replica.

  2. In Replica>Impostazioni origine>I computer sono virtualizzati? selezionare Sì, con VMware vSphere.

  3. Nell'appliance locale selezionare il nome dell'appliance di Azure Migrate configurata e quindi selezionare OK.

    Screenshot che mostra la scheda Impostazioni origine.

  4. In Macchine virtuali selezionare le macchine da replicare e scegliere se importare le impostazioni di migrazione da una valutazione.

    • Se gli amministratori hanno eseguito una valutazione per le macchine virtuali, possono applicare raccomandazioni relative al ridimensionamento e al tipo di disco delle macchine virtuali (Premium/Standard) dai risultati della valutazione. In Importare le impostazioni di migrazione da una valutazione di Azure Migrate selezionare Sì.
    • Se gli amministratori non hanno eseguito una valutazione o non vogliono usare le impostazioni di valutazione, selezionare No.
    • Se gli amministratori scelgono di usare la valutazione, selezionare il gruppo di macchine virtuali e il nome della valutazione.

    Screenshot che mostra la selezione delle valutazioni.

  5. In Macchine virtuali cercare le macchine virtuali in base alle esigenze e controllare ogni macchina virtuale di cui eseguire la migrazione. Selezionare quindi Avanti: Impostazioni di destinazione.

  6. In Impostazioni di destinazione selezionare la sottoscrizione e l'area di destinazione a cui vengono migrate le macchine virtuali. Specificare il gruppo di risorse in cui si troveranno le macchine virtuali di Azure dopo la migrazione. In Rete virtuale selezionare la rete virtuale/subnet di Azure aggiunta alle macchine virtuali di Azure dopo la migrazione.

  7. In Vantaggio Azure Hybrid:

    • Selezionare No per applicare Vantaggio Azure Hybrid.
    • Selezionare Sì per applicare facoltativamente sottoscrizioni di Software Assurance o Windows Server a computer idonei che eseguono Windows Server.

    Fare quindi clic su Avanti.

  8. In Calcolo esaminare i nomi, le dimensioni, i tipi di disco del sistema operativo e i set di disponibilità delle macchine virtuali. Devono essere conformi ai requisiti di Azure. Per altre informazioni, vedere Requisiti di VMware in Matrice di supporto per l'individuazione VMware.

    • Dimensioni della macchina virtuale: Quando si usano le raccomandazioni dei risultati della valutazione, l'elenco delle dimensioni delle macchine virtuali contiene le dimensioni consigliate. In caso contrario, Azure Migrate seleziona le dimensioni più simili nella sottoscrizione di Azure. In alternativa, selezionare manualmente le dimensioni in Dimensioni macchina virtuale di Azure.
    • Disco sistema operativo: specificare il disco del sistema operativo (di avvio) per la VM. È il disco che contiene il bootloader e il programma di installazione del sistema operativo.
    • Set di disponibilità: se la VM deve essere inclusa in un set di disponibilità di Azure dopo la migrazione, specificare il set. Il set deve trovarsi nel gruppo di risorse di destinazione specificato per la migrazione.

  9. In Dischi specificare se i dischi delle macchine virtuali devono essere replicati in Azure. Selezionare quindi il tipo di disco (SSD/HDD Standard o SSD Premium) in Azure e selezionare Avanti.

    • Facoltativamente, escludere i dischi dalla replica.
    • Un disco escluso non si trova nella macchina virtuale di Azure dopo la migrazione.

  10. In Rivedi e avvia replica esaminare le impostazioni. Selezionare quindi Replica per avviare la replica iniziale per i server.

Nota

Aggiornare le impostazioni di replica in qualsiasi momento prima dell'avvio della replica in Gestisci>computer di replica. Le impostazioni non possono essere modificate dopo l'avvio della replica.

Alternativi

In alternativa, è consigliabile valutare il servizio Di riproduzione log (LRS) per la migrazione di database da SQL Server usando il servizio Di riproduzione log.

Passaggio 6: Migrazione del database tramite il Servizio Migrazione del database di Azure

Gli amministratori di Contoso devono creare un progetto di Servizio Migrazione del database e quindi eseguire la migrazione del database.

Creare un progetto di Servizio Migrazione del database di Azure

Gli amministratori contoso completano i passaggi seguenti:

  1. Creare il progetto del Servizio Migrazione del database.

  2. Selezionare il tipo di server di origine SQL Server e Istanza gestita di SQL di Azure come destinazione.

    Screenshot che mostra il riquadro Nuovo progetto di migrazione.

    Viene aperta la Migrazione guidata.

Eseguire la migrazione del database

Gli amministratori contoso completano i passaggi seguenti:

  1. Nella Procedura guidata migrazione specificare la macchina virtuale di origine in cui si trova il database locale. Immettere le credenziali per accedere al database.

    Screenshot che mostra il riquadro Dettagli origine.

  2. Selezionare il database per eseguire la migrazione: SmartHotel.Registration.

    Screenshot che mostra il riquadro Seleziona database di origine.

  3. Per la destinazione immettere il nome dell'istanza gestita in Azure e le credenziali di accesso.

    Screenshot che mostra il riquadro Dettagli destinazione.

  4. In Nuovamigrazione esecuzioneattività> specificare le impostazioni per eseguire la migrazione:

    • Credenziali di origine e di destinazione.
    • Il database di cui eseguire la migrazione.
    • La condivisione di rete creata nella macchina virtuale locale. Servizio Migrazione del database di Azure salva i backup di origine in questa condivisione.
      • L'account del servizio che esegue l'istanza di origine di SQL Server deve disporre delle autorizzazioni di scrittura per questa condivisione.
      • Il percorso della condivisione deve essere il nome di dominio completo.
    • L'URI di firma di accesso condiviso che consente a Servizio Migrazione del database di Azure di accedere al contenitore dell'account di archiviazione in cui il servizio caricherà i file di backup per la migrazione.

    Screenshot che mostra la schermata Configura impostazioni di migrazione.

  5. Salvare le impostazioni di migrazione e quindi eseguire la migrazione.

  6. In Panoramica monitorare lo stato della migrazione.

    Screenshot che mostra lo stato.

  7. Al termine della migrazione, verificare che i database di destinazione esistano nell'istanza gestita.

    Screenshot che mostra la verifica della migrazione del database.

Passaggio 7: Eseguire la migrazione delle macchine virtuali con lo strumento di migrazione e modernizzazione

Gli amministratori contoso eseguono una migrazione di test rapida e verificare che la macchina virtuale funzioni correttamente. Eseguono quindi la migrazione della macchina virtuale.

Eseguire una migrazione di test

Gli amministratori contoso completano i passaggi seguenti:

  1. In Obiettivi della migrazione>Server>Azure Migrate: Migrazione del server selezionare Testare i server con migrazione completata.

    Screenshot che mostra l'elemento Server migrato dal test.

  2. Selezionare e tenere premuto il pulsante del mouse (o fare clic con il pulsante destro del mouse) sulla macchina virtuale da testare, quindi scegliere Migrazione di test.

    Screenshot che mostra l'elemento Di migrazione test.

  3. In Migrazione test selezionare la rete virtuale di Azure in cui si trova la macchina virtuale di Azure dopo la migrazione. È consigliabile usare una rete virtuale non di produzione.

    Verrà avviato il processo Migrazione di test.

  4. Monitorare il processo nelle notifiche del portale.

  5. Al termine della migrazione, visualizzare la VM di Azure di cui è stata eseguita la migrazione in Macchine virtuali nel portale di Azure. Il nome della macchina virtuale ha il suffisso -Test.

  6. Al termine del test, selezionare e tenere premuto (o fare clic con il pulsante destro del mouse) nella macchina virtuale di Azure nei computer di replica e quindi selezionare Pulisci la migrazione dei test.

    Screenshot che mostra l'elemento di migrazione di test pulizia.

Eseguire la migrazione della macchina virtuale

Ora gli amministratori Contoso eseguono una migrazione completa per completare lo spostamento:

  1. Nel progetto Azure Migrate passare a Server>Azure Migrate: Migrazione server e selezionare Replica server.

    Screenshot che mostra l'elemento Replica server.

  2. In Replica delle macchine virtuali selezionare e tenere premuto il pulsante del mouse (o fare clic con il pulsante destro del mouse) sulla macchina virtuale e quindi scegliere Esegui la migrazione.

  3. In Esegui la migrazione>Spegnere le macchine virtuali ed eseguire una migrazione pianificata senza perdita di dati selezionare Sì>OK.

    • Per impostazione predefinita, Azure Migrate arresta la macchina virtuale locale ed esegue una replica su richiesta per sincronizzare le eventuali modifiche apportate alla macchina virtuale dopo l'ultima replica. Questa operazione assicura che non si verifichi alcuna perdita di dati.
    • Per ignorare l'arresto della macchina virtuale, selezionare No.

    Verrà avviato un processo di migrazione per la VM.

  4. Tenere traccia del processo nelle notifiche di Azure.

  5. Al termine del processo, visualizzare e gestire la macchina virtuale dalla pagina Macchine virtuali.

  6. Aggiornare i record DNS per WEBVM in uno dei controller di dominio Contoso.

Aggiornare la stringa di connessione

Come passaggio finale nel processo di migrazione, gli amministratori Contoso aggiornano la stringa di connessione dell'applicazione per puntare al database migrato in esecuzione nell'istanza gestita di SQL:

  1. Nella portale di Azure trovare la stringa di connessione selezionando Impostazioni>stringhe di connessione.

    Screenshot che mostra l'opzione Stringhe di connessione.

  2. Aggiornare la stringa con il nome utente e la password dell'istanza gestita di SQL.

  3. Dopo aver configurato la stringa, sostituire la stringa di connessione corrente nel web.config file dell'applicazione.

  4. Dopo aver aggiornato il file e salvarlo, riavviare IIS WEBVM in esecuzione iisreset /restart in una finestra del prompt dei comandi.

    Dopo il riavvio di IIS, l'applicazione usa il database in esecuzione nell'istanza gestita di SQL.

  5. Arrestare il computer locale SQLVM .

    La migrazione è stata completata.

Ulteriore assistenza?

Eseguire la pulizia dopo la migrazione

Al termine della migrazione, una macchina virtuale di Azure esegue l'applicazione SmartHotel360 e Istanza gestita di SQL ospita il database SmartHotel360.

Contoso esegue ora queste attività di pulizia:

  • Rimuovere la macchina virtuale WEBVM dall'inventario del server vCenter.
  • Rimuovere la macchina virtuale SQLVM dall'inventario del server vCenter.
  • Rimuovere le macchine virtuali WEBVM e SQLVM dai processi di backup locali.
  • Aggiornare la documentazione interna con la nuova posizione e l'indirizzo IP di WEBVM.
  • Rimuovere SQLVM dalla documentazione interna. In alternativa, Contoso può rivedere la documentazione in modo che SQLVM risulti eliminata e non più presente nell'inventario delle macchine virtuali.
  • Esaminare tutte le risorse che interagiscono con le macchine virtuali rimosse. Aggiornare eventuali impostazioni o documenti pertinenti in modo che riflettano la nuova configurazione.

Esaminare la distribuzione

Al termine della migrazione delle risorse in Azure, Contoso deve rendere pienamente operativa la nuova infrastruttura e proteggerla.

Sicurezza

Il team di sicurezza di Contoso controlla le macchine virtuali di Azure e l'istanza gestita di SQL per verificare che l'implementazione non presenti problemi:

  • Il team esamina i gruppi di sicurezza di rete che controllano l'accesso per la macchina virtuale. I gruppi di sicurezza di rete assicurano il passaggio del solo traffico consentito all'applicazione.

  • Il team di sicurezza di Contoso considera anche la protezione dei dati sul disco usando Crittografia dischi di Azure e Azure Key Vault.

  • Il team abilita il rilevamento delle minacce nell'istanza gestita. In caso di minaccia, il rilevamento delle minacce invia un avviso al team di sicurezza/al sistema service desk di Contoso per aprire un ticket. Per altre informazioni sul rilevamento delle minacce, vedere Configurare Advanced Threat Protection in Istanza gestita di SQL di Azure.

    Screenshot che mostra la schermata Rilevamento minacce per Istanza gestita di SQL.

Per altre informazioni sulle procedure di sicurezza per le macchine virtuali, vedere Procedure consigliate per la sicurezza dei carichi di lavoro IaaS in Azure.

Continuità aziendale e ripristino di emergenza

Per la continuità aziendale e il ripristino di emergenza, Contoso esegue le azioni seguenti:

Licenze e ottimizzazione dei costi

Conclusioni

In questo articolo, Contoso rialloca l'applicazione SmartHotel360 in Azure tramite la migrazione della macchina virtuale front-end dell'applicazione ad Azure usando Azure Migrate. Esegue quindi la migrazione del database locale in un'Istanza gestita di SQL tramite il Servizio Migrazione del database di Azure.

Passaggi successivi