Effettuare il refactoring di un'applicazione Linux usando Servizio app di Azure, Gestione traffico e Database di Azure per MySQL

  • Articolo

Questo articolo illustra come la società fittizia Contoso effettui il refactoring di un'applicazione basata su LAMP a due livelli eseguendone la migrazione dall'ambiente locale ad Azure usando Servizio app di Azure con l'integrazione GitHub e Database di Azure per MySQL.

osTicket, l'applicazione Service Desk usata in questo esempio, viene fornita come software open source. Se si intende usarla a scopo di test, è possibile scaricarla dal repository osTicket su GitHub.

Driver di business

Il team di leadership IT collabora attivamente con i partner commerciali per capire gli obiettivi da raggiungere:

  • Stare al passo con la crescita aziendale. Contoso è in crescita e si sta espandendo in nuovi mercati. Sono pertanto necessari addetti al servizio clienti aggiuntivi.
  • Scalabilità. la soluzione deve essere compilata in modo che Contoso possa aggiungere altri addetti al servizio clienti man mano che l'azienda aumenta di dimensioni.
  • Migliorare la resilienza: In precedenza, i problemi riguardanti il sistema interessavano solo gli utenti interni. Con il nuovo modello di business, saranno interessati anche gli utenti esterni e per Contoso è necessario che l'applicazione sia configurata e operativa in qualsiasi momento.

Obiettivi della migrazione

Per determinare il metodo di migrazione più consono, il team cloud di Contoso ha stabilito i propri obiettivi per questa migrazione:

  • L'applicazione deve scalare superando la capacità e le prestazioni locali correnti. Contoso sta spostando l'applicazione per sfruttare i vantaggi della scalabilità su richiesta di Azure.
  • Contoso vuole spostare la base di codice dell'applicazione in una pipeline di recapito continuo. Poiché viene eseguito il push delle modifiche dell'applicazione a GitHub, Contoso vuole distribuire tali modifiche senza interventi da parte del personale operativo.
  • L'applicazione deve essere resiliente con capacità di crescita e failover. Contoso vuole distribuire l'applicazione in due diverse aree di Azure e configurarla per il ridimensionamento automatico.
  • Si desidera ridurre al minimo le attività di amministrazione del database dopo che l'applicazione è stata spostata nel cloud.

Progettazione della soluzione

Dopo aver definito i propri obiettivi e requisiti, Contoso progetta ed esamina una soluzione di distribuzione, identificando il processo di migrazione, tra cui i servizi di Azure da usare per la migrazione.

Architettura corrente

  • L'applicazione è suddivisa a livelli in due macchine virtuali (VM) (OSTICKETWEB e OSTICKETMYSQL).
  • Le macchine virtuali si trovano nell'host VMware ESXi contosohost1.contoso.com (versione 6.5).
  • L'ambiente VMware viene gestito dal server vCenter 6.5 (vcenter.contoso.com) in esecuzione in una macchina virtuale.
  • Contoso ha un data center locale (contoso-datacenter) con un controller di dominio locale (contosodc1).

Diagramma dell'architettura corrente.

Architettura proposta

Ecco l’architettura proposta:

  • Per l'applicazione di livello Web su OSTICKETWEB viene eseguita la migrazione creando un'app Web di Servizio app di Azure in due aree di Azure. Il team di Contoso implementerà il Servizio app di Azure per Linux usando il contenitore Docker PHP 7.0.
  • Il codice dell'applicazione verrà spostato in GitHub e l'app Web di Servizio app di Azure verrà configurata per il recapito continuo con GitHub.
  • Servizio app di Azure verrà distribuito sia nell'area primaria (East US 2) che nell'area secondaria (Central US).
  • Per le due app Web in entrambe le aree verrà configurato il servizio Gestione traffico di Azure.
  • Gestione traffico verrà configurato in modalità di priorità per forzare il traffico attraverso East US 2.
  • Se il server di app di Azure in East US 2 è offline, gli utenti possono accedere all'applicazione di cui è stato effettuato il failover in Central US.
  • Verrà eseguita la migrazione del database dell'applicazione al servizio Database di Azure per MySQL usando Servizio Migrazione del database di Azure. Verrà eseguito localmente il backup del database locale, che verrà ripristinato direttamente in Database di Azure per MySQL.
  • Il database risiederà nell'area primaria (East US 2) nella subnet del database (PROD-DB-EUS2) della rete di produzione (VNET-PROD-EUS2).
  • Poiché l'azienda intende eseguire la migrazione di un carico di lavoro di produzione, le risorse di Azure per l'applicazione risiederanno nel gruppo di risorse di produzione ContosoRG.
  • La risorsa di Gestione traffico verrà distribuita nel gruppo di risorse di infrastruttura di Contoso ContosoInfraRG.
  • Le macchine virtuali locali nel data center Contoso verranno rimosse al termine della migrazione.

Diagramma dell'architettura dello scenario.

Processo di migrazione

Contoso completa il processo di migrazione in questo modo:

  1. Prima di tutto, gli amministratori di Contoso configurano l'infrastruttura di Azure, effettuando tra l'altro il provisioning di Servizio app di Azure, la configurazione di Gestione traffico e il provisioning di un'istanza di Database di Azure per MySQL.
  2. Dopo aver preparato l'infrastruttura di Azure, viene eseguita la migrazione del database mediante Servizio Migrazione del database di Azure.
  3. Una volta che il database è in esecuzione in Azure, caricano un repository di GitHub privato per Servizio app di Azure con recapito continuo e vi caricano l'applicazione osTicket.
  4. Nel portale di Azure, caricano l'applicazione da GitHub nel contenitore Docker eseguendo il Servizio app di Azure.
  5. Modificano le impostazioni DNS e configurano la scalabilità automatica per l'applicazione.

Diagramma del processo di migrazione di Contoso.

Servizi di Azure

Servizio Descrizione Costi
Servizio app di Azure Il servizio esegue e ridimensiona le applicazioni usando il servizio PaaS (platform as a service) di Azure per i siti Web. I prezzi si basano sulle dimensioni delle istanze e sulle funzionalità necessarie. Altre informazioni
Gestione traffico di Azure Un bilanciamento del carico che usa il DNS (Domain Name System) per indirizzare gli utenti ad Azure o a servizi e siti Web esterni. I prezzi si basano sul numero di query DNS ricevute e sul numero di endpoint monitorati. Altre informazioni
Servizio Migrazione del database di Azure 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. Altre informazioni sulle aree supportate e sui prezzi del Servizio Migrazione del database.
Database di Azure per MySQL Il database è basato sul motore di database MySQL open source. Offre un database MySQL completamente gestito, di livello aziendale e supportato dalla community per lo sviluppo e la distribuzione di applicazioni. I prezzi si basano sui requisiti di calcolo, archiviazione e backup. Altre informazioni

Prerequisiti

Per eseguire questo scenario, Contoso deve soddisfare i prerequisiti seguenti:

Requisiti Dettagli
Sottoscrizione di Azure Contoso ha creato le sottoscrizioni in un articolo precedente 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 ha il ruolo di amministratore, è necessario rivolgersi all'amministratore per l'assegnazione delle autorizzazioni di proprietario o collaboratore.
Infrastruttura di Azure Contoso configura la propria infrastruttura di Azure come descritto in Azure infrastructure for migration (Infrastruttura di Azure per la migrazione).

Passaggi dello scenario

Ecco il piano di Contoso per completare la migrazione:

  • Passaggio 1: Effettuare il provisioning di Servizio app di Azure. Gli amministratori Contoso effettuano il provisioning delle app Web nelle aree primaria e secondaria.
  • Passaggio 2: Configurare Gestione traffico. Configurano Gestione traffico per le app Web per il routing e il bilanciamento del carico del traffico.
  • Passaggio 3: Effettuare il provisioning di Database di Azure per MySQL. In Azure effettuano il provisioning di un'istanza di Database di Azure per MySQL.
  • Passaggio 4: Eseguire la migrazione del database. La migrazione del database viene eseguita con il Servizio Migrazione del database.
  • Passaggio 5: Configurare GitHub. Viene configurato un repository di GitHub locale per il codice e i siti Web dell'app.
  • Passaggio 6: Configurare le app Web. Le app Web vengono configurate con i siti Web osTicket.

Passaggio 1: Effettuare il provisioning di Servizio app di Azure

Gli amministratori di Contoso effettuano il provisioning di due app Web (una in ogni area) con Servizio app di Azure.

  1. Creano una risorsa app Web (osticket-eus2) nell'area primaria (East US 2) tramite Azure Marketplace.

  2. Inseriscono la risorsa nel gruppo di risorse di produzione ContosoRG.

    Screenshot del riquadro App Web per la creazione di un'app Web in Linux.

  3. Creano un piano di servizio app, APP-SVP-EUS2, nell'area primaria e vengono usate le dimensioni standard.

    Screenshot del riquadro Nuovo piano di servizio app per la creazione di un piano di servizio app.

  4. Viene selezionato un sistema operativo Linux con stack di runtime PHP 7.0, un contenitore Docker.

    Screenshot del riquadro App Web, con sistema operativo Linux, percorso Stati Uniti orientali 2 e PHP 7.0 selezionato.

  5. Creano una seconda app Web, osticket-cus, e un piano di Servizio app di Azure per Stati Uniti centrali.

    Screenshot del riquadro App Web, con sistema operativo Linux, posizione Stati Uniti centrali e PHP 7.0 selezionato.

Ulteriore assistenza?

Passaggio 2: Configurare Gestione traffico

Gli amministratori di Contoso configurano Gestione traffico per indirizzare le richieste Web in ingresso alle app Web in esecuzione nel livello Web osTicket.

  1. In Azure Marketplace creano una risorsa di Gestione traffico, osticket.trafficmanager.net. Usano il routing prioritario, in modo che l'area Stati Uniti orientali 2 sia il sito primario. La risorsa viene posizionata nel gruppo di risorse dell'infrastruttura ContosoInfraRG. Si noti che il servizio Gestione traffico è globale e non è associato a una posizione specifica.

    Screenshot del riquadro Crea profilo di Gestione traffico.

  2. Configurano Gestione traffico con gli endpoint. Aggiungono l'app Web nell'area Stati Uniti orientali 2 come sito primario, osticket-eus2, e l'app Web nell'area Stati Uniti centrali come sito secondario, osticket-cus.

    Screenshot del riquadro Aggiungi endpoint in Gestione traffico.

  3. Dopo aver aggiunto gli endpoint, gli amministratori possono monitorarli.

    Screenshot del riquadro Endpoint per il monitoraggio degli endpoint in Gestione traffico.

Ulteriore assistenza?

Passaggio 3: Eseguire il provisioning del database di Azure per MySQL

Gli amministratori di Contoso effettuano il provisioning di un'istanza di database MySQL nell'area primaria Stati Uniti orientali 2.

  1. Nel portale di Azure si crea una risorsa per il database di Azure per MySQL.

    Screenshot del collegamento Database di Azure per MySQL nella portale di Azure.

  2. Aggiugono il nome contosoosticket per il database di Azure. Aggiungono il database al gruppo di risorse di produzione ContosoRG e ne specificano le credenziali.

  3. Il database MySQL locale è la versione 5.7, pertanto si seleziona questa versione per compatibilità. Si usano le dimensioni predefinite, che corrispondono ai relativi requisiti di database.

    Screenshot del riquadro Server MySQL con la versione 5.7 selezionata.

  4. In Opzioni di ridondanza per il backup selezionano l'uso Con ridondanza geografica. Questa opzione consente di ripristinare il database nell'area secondaria (Stati Uniti centrali) in caso di interruzione. Possono configurare questa opzione solo quando effettuano il provisioning del database.

    Screenshot del riquadro Opzioni ridondanza backup con l'opzione Geo-Redundant selezionata.

  5. Viene impostata la sicurezza della connessione. Nel database selezionano Sicurezza della connessione, quindi configurano le regole del firewall per consentire al database di accedere ai servizi di Azure.

  6. Le regole aggiungono l'indirizzo IP del client per workstation locale agli indirizzi IP iniziale e finale. In questo modo le app Web hanno accesso al database MySQL, insieme al client del database che sta eseguendo la migrazione.

    Screenshot del riquadro Sicurezza connessione che mostra l'accesso ai servizi di Azure attivato e l'indirizzo IP client selezionato.

Passaggio 4: Eseguire la migrazione del database

Esistono diversi modi per spostare il database MySQL. Per ogni opzione è necessario che gli amministratori di Contoso creino un'istanza di Database di Azure per MySQL per la destinazione. Dopo aver creato l'istanza, possono eseguire la migrazione del database usando due percorsi:

  • Passaggio 4a: Servizio Migrazione del database di Azure
  • Passaggio 4b: Backup e ripristino di MySQL Workbench

Passaggio 4a: Eseguire la migrazione del database tramite il Servizio Migrazione del database di Azure

Gli amministratori di Contoso eseguono la migrazione del database mediante il Servizio Migrazione del database di Azure e seguendo l'esercitazione dettagliata sulla migrazione. Possono eseguire migrazioni online, offline e ibride (in anteprima) usando MySQL 5.6 o 5.7.

Nota

MySQL 8.0 è supportato in Database di Azure per MySQL, ma lo strumento Servizio Migrazione del database non supporta ancora questa versione.

In breve, Contoso procede in questo modo:

  • Verifica che tutti i prerequisiti di migrazione siano soddisfatti:

    • L'origine del server MySQL deve corrispondere alla versione supportata dal Database di Azure per MySQL. Database di Azure per MySQL supporta l'edizione MySQL Community, il motore di archiviazione InnoDB e la migrazione tra origine e destinazione con le stesse versioni.

    • Abilita la registrazione binaria in my.ini (Windows) o my.cnf (Unix). Se non è abilitata, si verifica l'errore seguente nella Migrazione guidata:

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      Per altre informazioni, vedere Opzioni e variabili di registrazione binaria nella documentazione di MySQL.

    • L'utente deve avere il ruolo ReplicationAdmin.

    • La migrazione degli schemi del database viene eseguita senza chiavi esterne o trigger.

  • Crea una rete privata virtuale (VPN) che si connette alla rete locale tramite ExpressRoute o VPN.

  • Crea un'istanza del Servizio Migrazione del database di Azure con uno SKU Premium connesso alla rete virtuale.

  • Si assicura che il Servizio Migrazione del database di Azure possa accedere al database MySQL tramite la rete virtuale. A questo scopo occorre assicurarsi che siano consentite tutte le porte in ingresso da Azure a MySQL al livello della rete virtuale, della VPN di rete e del computer su cui è installato MySQL.

  • Esegue lo strumento Servizio Migrazione del database e quindi eseguono le operazioni seguenti:

    1. Creare un progetto di migrazione basato sullo SKU Premium.

      Screenshot del riquadro Panoramica di MySQL con un messaggio che indica che il servizio di migrazione è stato creato correttamente.

      Screenshot del riquadro del progetto di migrazione MySQL New.

    2. Aggiungere un'origine (database locale).

      Screenshot del riquadro Aggiungi dettagli origine della procedura guidata migrazione.

    3. Selezionare una destinazione.

      Screenshot del riquadro Dettagli destinazione della procedura guidata migrazione.

    4. Selezionare i database di cui eseguire la migrazione.

      Screenshot del riquadro Mapping della procedura guidata migrazione ai database di destinazione.

    5. Configurare le impostazioni avanzate.

      Screenshot del riquadro Impostazioni migrazione guidata Migrazione.

    6. Avviare la replica e risolvere eventuali errori.

      Screenshot del riquadro dei dettagli del server.

    7. Eseguire il cutover finale.

      Screenshot del riquadro dettagli osTicket.

      Screenshot del riquadro Di taglio completo.

      Screenshot della tabella di stato delle attività di migrazione.

    8. Reintegrare le chiavi esterne e i trigger.

    9. Modificare le applicazioni in modo da usare il nuovo database.

      Screenshot della tabella Attività di migrazione.

Passaggio 4b: Eseguire la migrazione del database (MySQL Workbench)

  1. Gli amministratori di Contoso verificano i prerequisiti e scaricano MySQL Workbench.

  2. Si installa MySQL Workbench per Windows in conformità con le istruzioni di installazione. Il computer in cui viene installato MySQL Workbench deve essere accessibile alla VM osticketmysql e ad Azure tramite Internet.

  3. In MySQL Workbench creano una connessione MySQL a osticketmysql.

    Screenshot del riquadro dettagli connessione MySQL Workbench.

  4. Esportano il database come osticket in un file autonomo locale.

    Screenshot del riquadro Esportazione dati mySQL Workbench.

  5. Dopo avere eseguito il backup del database localmente, gli amministratori creano una connessione all'istanza di Database di Azure per MySQL.

    Riquadro Configurazione nuova connessione di MySQL Workbench.

  6. A questo punto, possono importare (ripristinare) il database nell'istanza di Database di Azure per MySQL dal file autonomo. Viene creato un nuovo schema (osticket) per l'istanza.

    Screenshot del riquadro Importazione dati mySQL Workbench.

  7. Dopo aver ripristinato i dati, gli amministratori possono eseguire query usando MySQL Workbench. I dati vengono visualizzati nel portale di Azure.

    Screenshot del portale di Azure, che mostra i dati ripristinati.

    Screenshot del pannello Database MySQL con una freccia che punta al database osTicket.

  8. Gli amministratori aggiornano le informazioni del database nelle app Web. Nell'istanza di MySQL, si apreStringhe di connessione.

    Screenshot del collegamento Stringhe di connessione nell'istanza di MySQL.

  9. Nell'elenco delle stringhe di connessione selezionano le impostazioni dell'app Web e quindi le copiano selezionando Fare clic per copiare.

    Screenshot delle impostazioni dell'app Web nell'istanza di MySQL.

  10. Aprono un nuovo file nel Blocco note, vi incollano la stringa e aggiornano la stringa in modo che corrisponda al database osTicket, all'istanza di MySQL e alle impostazioni delle credenziali.

    Screenshot della stringa di connessione incollata in un file del Blocco note.

  11. Possono verificare il nome del server e l'accesso tramite il riquadro Panoramica per l'istanza di MySQL nel portale di Azure.

    Screenshot del riquadro del gruppo di risorse, che mostra il nome del server e il nome dell'account amministratore del server.

Passaggio 5: Configurare GitHub

Gli amministratori di Contoso creano un nuovo repository di GitHub privato e configurano una connessione al database osTicket in Database di Azure per MySQL. Caricano quindi l'app Web in Servizio app di Azure.

  1. Passano al repository di GitHub pubblico del software osTicket e ne creano una copia tramite fork nell'account GitHub di Contoso.

    Screenshot della pagina del repository GitHub, evidenziando il pulsante Fork.

  2. Dopo aver creato una copia del repository tramite fork, passano alla cartella include e selezionano il file ost-config.php.

    Screenshot del file PHP in GitHub.

  3. Il file viene aperto nel browser e viene modificato.

    Screenshot dell'icona di modifica del file (matita) in GitHub.

  4. Nell'editor gli amministratori aggiornano i dettagli del database, in particolare DBHOST e DBUSER.

    Screenshot del riquadro di modifica del file in GitHub.

  5. Eseguono il commit delle modifiche.

    Screenshot che evidenzia il pulsante Commit changes (Commit changes) nel riquadro di modifica.

  6. Per ogni app Web (osticket-eus2 e osticket-cus), nel portale di Azure selezionano Impostazioni dell'applicazione nel riquadro di sinistra e quindi modificano le impostazioni.

    Screenshot che evidenzia il collegamento Impostazioni applicazione nel portale di Azure.

  7. Immettono la stringa di connessione con il nome osticket e copiano la stringa dal Blocco note nell'area dei valori. Infine, viene selezionato MySQL dall'elenco a discesa accanto alla stringa, quindi si salvano le impostazioni.

    Screenshot del riquadro Stringhe di connessione con l'evidenziazione della stringa di connessione osTicket.

Passaggio 6: Configurare le app Web

Come passaggio finale del processo di migrazione, gli amministratori di Contoso configurano le app Web con i siti Web osTicket.

  1. Nell'app Web primaria, osticket-eus2, aprono Opzione di distribuzione e impostano l'origine su GitHub.

    Screenshot del riquadro dell'opzione Distribuzione con GitHub selezionato come origine.

  2. Vengono scelte le opzioni di distribuzione.

    Screenshot dei dettagli dell'opzione nel riquadro dell'opzione Distribuzione.

  3. Dopo aver impostato le opzioni, la configurazione viene visualizzata come In sospeso nel portale di Azure.

    Screenshot del riquadro Opzioni di distribuzione che mostra uno stato del sito in sospeso.

  4. In seguito all'aggiornamento della configurazione e al caricamento dell'app Web osTicket da GitHub nel contenitore Docket che esegue il Servizio app di Azure, il sito viene visualizzato come Attivo.

    Screenshot del riquadro Opzioni di distribuzione.

  5. Ripetono i passaggi precedenti per l'app Web secondaria, osticket-cus.

  6. Dopo aver configurato il sito, questo è accessibile tramite il profilo Gestione traffico. Il nome DNS è la nuova posizione dell'app osTicket. Altre informazioni

    Screenshot del riquadro Profilo di Gestione traffico che visualizza il nome DNS.

  7. Contoso vuole usare un nome DNS che sia facile da ricordare. Nel riquadro New Resource Record creano un alias, un CNAME e un nome di dominio completo, osticket.contoso.com, che punta al nome di Gestione Traffico nel DNS nei controller di dominio.

    Screenshot del riquadro Nuovo record di risorse, che mostra il nome dell'alias e un puntatore a Gestione traffico.

  8. Configurano entrambe le app Web, osticket-eus2 e osticket-cus, in modo da consentire i nomi host personalizzati.

    Screenshot del riquadro Nome host annuncio, che evidenzia il pulsante Convalida.

Configurare la scalabilità automatica

Infine, gli amministratori di Contoso configurano il ridimensionamento automatico per l'applicazione. Il ridimensionamento automatico garantisce che, quando gli agenti usano l'applicazione, le istanze dell'applicazione aumentino e diminuiscano in base alle esigenze aziendali.

  1. Nel Servizio app APP-SVP-EUS2 aprono Unità di scala.

  2. Configurano una nuova impostazione di scalabilità automatica con una singola regola che aumenta di uno il numero di istanze quando l'utilizzo della CPU per l'istanza corrente è superiore al 70% per 10 minuti.

    Screenshot della pagina delle impostazioni di scalabilità automatica per la prima area.

  3. Configurano la stessa impostazione su APP-SVP-CUS per assicurarsi che si verifichi lo stesso comportamento se viene eseguito il failover dell'applicazione nell'area secondaria. L'unica differenza è che l'istanza predefinita viene impostata su 1 perché è solo per il failover.

    Screenshot della pagina delle impostazioni di scalabilità automatica per la seconda area.

Eseguire la pulizia dopo la migrazione

Al termine della migrazione, l'applicazione osTicket viene sottoposta a refactoring per l'esecuzione in un'app Web di Servizio app di Azure con recapito continuo usando un repository di GitHub privato. L'applicazione viene eseguita in due aree per una maggiore resilienza. Dopo la migrazione alla piattaforma PaaS, il database osTicket viene eseguito in Database di Azure per MySQL.

Per eseguire la pulizia dopo la migrazione, Contoso esegue le operazioni seguenti:

  • Rimuove le macchine virtuali VMware dall'inventario vCenter.
  • Rimuove le macchine virtuali locali dai processi di backup locali.
  • Aggiorna la documentazione interna con le nuove posizioni e i nuovi indirizzi IP.
  • Esamina le risorse che interagiscono con le macchine virtuali locali e aggiorna eventuali impostazioni o documenti pertinenti in modo che riflettano la nuova configurazione.
  • Riconfigura il monitoraggio in modo che punti all'URL osticket.trafficmanager.net, per verificare che l'applicazione sia operativa.

Esaminare la distribuzione

Con l'applicazione in esecuzione, Contoso deve rendere pienamente operativa e proteggere la nuova infrastruttura.

Sicurezza

Il team di sicurezza di Contoso esamina l'applicazione Azure per rilevare eventuali problemi di sicurezza. Stabilisce che la comunicazione tra l'applicazione osTicket e l'istanza di database MySQL non è configurata per SSL. Tutto questo viene fatto per garantire che il traffico del database non possa essere compromesso. Altre informazioni

Backup

  • Le app Web osTicket non contengono dati relativi allo stato e quindi non richiedono il backup.
  • Il team di Contoso non deve configurare il backup per il database. Database di Azure per MySQL crea automaticamente i backup del server e gli archivi. Il team ha deciso di usare la ridondanza geografica per il database, in modo che sia resiliente e pronto per la produzione. I backup possono essere usati per ripristinare il server a un momento specifico. Altre informazioni

Licenze e ottimizzazione dei costi

  • Non vi sono problemi di gestione delle licenze per la distribuzione di PaaS.
  • Contoso userà Gestione dei costi e fatturazione di Azure per assicurare che siano rispettati i budget definiti dalla leadership IT.