VENDITE: 1-800-867-1389

Modelli di applicazione e strategie di sviluppo per SQL Server in Macchine virtuali di Azure

Aggiornamento: febbraio 2015

Articolo tecnico su SQL Server e Azure

Riepilogo: Determinare quale modello o quali modelli dell'applicazione usare per le applicazioni basate su SQL Server in ambiente Azure è un'importante decisione di progettazione e richiede una solida conoscenza del funzionamento congiunto di SQL Server con ciascun componente dell'infrastruttura. Con i servizi di infrastruttura di Azure, è possibile eseguire facilmente la migrazione, la manutenzione e il monitoraggio delle applicazioni SQL Server esistenti compilate nella piattaforma Windows Server in Macchine virtuali di Azure.

Lo scopo di questo articolo è di fornire agli architetti e agli sviluppatori di soluzioni una base solida per l'architettura e il design efficace delle applicazioni, che potranno seguire nella migrazione di applicazioni esistenti in Azure oltre che nello sviluppo di nuove applicazioni in Azure.

Per ogni modello di applicazione sono disponibili uno scenario locale, la rispettiva soluzione abilitata per il cloud e i consigli tecnici correlati. Inoltre, nell'articolo vengono discusse strategie di sviluppo specifiche di Azure in modo da poter progettare correttamente le applicazioni. A causa del numero infinito di modelli di applicazione diversi, è consigliabile che gli architetti e gli sviluppatori scelgano i modelli più appropriati per i relativi utenti e applicazioni.

Autore: Selcin Turkarslan

Collaboratori tecnici: Luis Carlos Vargas Herring, Madhan Arumugam Ramakrishnan

Revisori tecnici: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman, Xin Jin

È possibile sviluppare numerosi tipi di applicazioni di più livelli separando i componenti dei diversi livelli di applicazione in macchine diverse e in componenti separati. Ad esempio, è possibile inserire i componenti di applicazione client e regole di business in un'unica macchina, i componenti livello Web front-end e livello di accesso ai dati in un'altra macchina e un livello di database back-end in un'altra macchina. Questo tipo di strutturazione contribuisce a isolare ogni livello dall'altro. Se si cambia la provenienza dei dati, non sarà necessario modificare il client o l'applicazione Web, ma solo i componenti del livello di accesso ai dati.

Una tipica applicazione a più livelli include il livello presentazione, il livello business e il livello dati:

  • Il livello presentazione (livello Web, livello front-end) è il livello in cui gli utenti interagiscono con un'applicazione.

  • Il livello business (livello intermedio) è quello usato dal livello presentazione e dal livello dati per comunicare tra loro e include la funzionalità centrale del sistema.

  • Il livello dati è fondamentalmente il server su cui vengono archiviati i dati di un'applicazione (ad esempio, un server che esegue SQL Server).

I livelli di applicazione rappresentano i raggruppamenti logici della funzionalità e dei componenti in un'applicazione, laddove i livelli rappresentano la distribuzione fisica della funzionalità e dei componenti su server, computer, reti o posizioni remote fisici separati. I livelli di un'applicazione possono risiedere sullo stesso computer fisico (lo stesso livello) o possono essere distribuiti su computer separati (più livelli) e i componenti in ogni livello comunicano con i componenti in altri livelli attraverso interfacce ben definite. Si pensi al termine "livello" come a modelli di distribuzione fisica, ad esempio due livelli, tre livelli e più livelli. Un modello di applicazione a 2 livelli contiene due livelli di applicazione: server applicazioni e server di database. La comunicazione diretta avviene tra il server applicazioni e il server di database. Il server applicazioni contiene componenti sia a livello Web sia a livello business. Un modello di applicazione a 3 livelli contiene tre livelli di applicazione: server Web, server applicazioni, che contiene il livello di logica di business e/o i componenti di accesso ai dati livello business e infine il server di database. La comunicazione tra il server Web e il server di database avviene tramite il server applicazioni. Per informazioni approfondite sui livelli di applicazione e sui livelli, vedere la guida all'architettura delle applicazioni Microsoft.

Prima di iniziare a leggere questo articolo occorre conoscere i concetti fondamentali di SQL Server e di Azure. Per informazioni, vedere la documentazione online di SQL Server SQL Server in Macchine virtuali di Azure e il sito WindowsAzure.com.

In questo articolo sono descritti diversi modelli di applicazione che possono essere idonei alle applicazioni semplici nonché alle applicazioni aziendali altamente complesse. Prima di descrivere nel dettaglio ogni modello, si consiglia di familiarizzare con i servizi di archiviazione dei dati disponibili in Azure, come Archiviazione di Azure, http://msdn.microsoft.com/en-us/library/azure/sql-database e SQL Server in una macchina virtuale Azure. Per prendere le migliori decisioni in termini di progettazione delle applicazioni, è necessario comprendere chiaramente quale servizio di archiviazione dei dati usare e quando usarlo.

Riepilogando, è consigliabile scegliere SQL Server in una macchina virtuale di Azure nelle seguenti condizioni:

  • È richiesta la completa compatibilità con SQL Server in locale e si desidera spostare le applicazioni esistenti su Azure così come sono.

  • Si desidera sfruttare le capacità dell'ambiente Azure, ma il database SQL di Azure (database SQL) non supporta tutte le funzionalità che richiede l'applicazione o il database, ad esempio:

    • Disponibilità elevata e ripristino di emergenza: Si desidera disporre delle funzionalità di disponibilità tradizionali di SQL Server, ad esempio i gruppi di disponibilità AlwaysOn o il mirroring del database. Con SQL Server in una macchina virtuale di Azure si ha il controllo completo della configurazione e dell'esecuzione delle soluzioni di disponibilità elevata e ripristino di emergenza basate su SQL Server per le proprie applicazioni. Questa possibilità previene i tempi di inattività dei database a causa di errori del software o guasti dell'hardware oppure di aggiornamenti del sistema operativo in Azure. D'altro canto, il database SQL di Azure dispone di una resilienza predefinita all'errore a livello di nodo in Azure. In caso di errore del nodo viene eseguito automaticamente il failover del database in una delle repliche secondarie. Poiché non si ha alcun controllo sul modo in cui può avvenire un failover, è necessario gestire le interruzioni della connessione per le applicazioni client eseguite sul database SQL.

    • Dimensioni del database: alla data di aggiornamento del presente articolo, Database SQL supporta un database con dimensioni massime pari a 500 GB di dati. Se l'applicazione in uso richiede oltre 500 GB di dati e non si desidera implementare soluzioni di partizionamento orizzontale personalizzate, si consiglia di usare SQL Server in una macchina virtuale di Azure. Per informazioni aggiornate, vedere Scalabilità orizzontale di database SQL di Azure e Livelli di servizio e livelli di prestazioni del database SQL di Azure.

    • Conformità HIPAA: Si consiglia ai clienti che operano nel settore sanitario e i fornitori di software indipendenti (ISV) di scegliere SQL Server in Macchine virtuali di Azure invece del database SQL di Azure in quanto SQL Server in una macchina virtuale di Azure è protetto dal Contratto di società in affari HIPAA (BAA). Per informazioni sulla conformità vedere il Centro protezione di Azure.

    • Gap di funzionalità: Si consiglia ad alcuni clienti di scegliere SQL in Macchine virtuali di Azure invece del database SQL di Azure a causa dei gap delle funzionalità di quest'ultimo, come la compressione dei dati e la flessibilità delle operazioni di backup e ripristino. Per altre informazioni, vedere Linee guida e limitazioni per il database SQL di Azure.

In questo modello di applicazione si distribuisce l'applicazione SQL Server e il database a una macchina virtuale autonoma in Azure. La stessa macchina virtuale contiene l'applicazione client/Web, i componenti business, il livello di accesso ai dati e il server di database. I codici di presentazione, business e accesso ai dati sono logicamente separati, ma fisicamente situati in un singolo server. Gran parte dei clienti inizia con questo modello di applicazione per poi scalare aggiungendo altri ruoli Web o macchine virtuali al proprio sistema.

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera eseguire una semplice migrazione alla piattaforma Azure per valutare se questa risponde o no ai requisiti dell'applicazione.

  • Si desidera conservare tutti i livelli di applicazione ospitati sulla stessa macchina virtuale nello stesso data center Azure allo scopo di ridurre la latenza tra livelli.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

Il diagramma seguente illustra un semplice scenario locale e come distribuire la soluzione abilitata per il cloud su una singola macchina virtuale in Azure.

Modello dell'applicazione a 1 livello

La distribuzione del livello business (componenti logica di business e accesso ai dati) sullo stesso livello fisico del livello presentazione può massimizzare le prestazioni dell'applicazione, a meno che non sia necessario usare un livello separato a causa di preoccupazioni relative a scalabilità o sicurezza.

Poiché è molto comune iniziare con questo modello, può essere utile consultare i seguenti collegamenti per informazioni sulla migrazione dei dati e dei file applicativi locali in Macchine virtuali di Azure: Preparazione della migrazione a SQL Server in Macchine virtuali di Azure e Migrazione a SQL Server in una macchina virtuale di Azure. Inoltre, è possibile usare il servizio di importazione/esportazione di Azure per trasferire i dati nell'archiviazione BLOB. Mediante il servizio Importazione/Esportazione è possibile creare un lavoro di importazione per spostare i file di dati nell'archiviazione di Azure. Microsoft carica i dati nel disco in Archiviazione di Azure. Al termine del caricamento da parte di Microsoft dei file di dati nell'archiviazione BLOB nello stesso data center della macchina virtuale, è possibile collegarsi al desktop remoto nella macchina virtuale e scaricare i file di dati dall'archiviazione BLOB. È inoltre possibile accedere ai file nell'archiviazione BLOB usando gli SDK di archiviazione BLOB.

In questo modello di applicazione si distribuisce un'applicazione a 3 livelli in Azure inserendo ciascun livello di applicazione in una diversa macchina virtuale. Ciò fornisce un ambiente flessibili per facili scenari di scalabilità verticale e orizzontale. Quando una sola macchina virtuale contiene l'applicazione client/Web, l'altra ospita i componenti business e l'altra ospita il server di database.

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera eseguire la migrazione di applicazioni di database complesse in Macchine virtuali di Azure

  • Si desidera che livelli di applicazioni diversi siano ospitati in aree diverse. Ad esempio, è possibile che siano presenti database condivisi e distribuiti a più aree a scopi di creazione report.

  • Si desidera spostare le applicazioni aziendali dalle piattaforme virtualizzate locali in Macchine virtuali di Azure. Per una discussione dettagliata sulle applicazioni aziendali, vedere Informazioni sull'applicazione aziendale.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

Nel diagramma seguente è illustrato come distribuire una semplice applicazione a 3 livelli in Azure inserendo ciascun livello di applicazione in una diversa macchina virtuale.

Modello dell'applicazione a 3 livello

In questo modello di applicazione esiste una sola macchina virtuale (VM) in ogni livello. Se si hanno più macchine virtuali in Azure, si consiglia di configurare una rete virtuale. La rete virtuale di Azure crea un limite di sicurezza attendibile e consente inoltre alle macchine virtuali di comunicare tra loro tramite un indirizzo IP privato. Inoltre, assicurarsi sempre che tutte le connessioni Internet siano indirizzate solo al livello presentazione; ciò significa che è consigliabile aprire un endpoint pubblico sul livello presentazione, ma non sugli altri livelli. Nel seguire questo modello di applicazione è inoltre necessario configurare l'elenco di controllo di accesso di rete (ACL) su tale porta pubblica per autorizzare l'accesso di determinati indirizzi IP. Per altre informazioni, vedere Informazioni sugli elenchi di controllo di accesso di rete (ACL).

Nel diagramma, i protocolli Internet possono essere TCP, UDP, HTTP o HTTPS.

Importante: La configurazione di una rete virtuale in Azure è gratuita. Verrà tuttavia addebitata una tariffa per il gateway VPN a cui si connette localmente. Questo addebito dipende dal periodo di tempo in cui viene fornita e resa disponibile la connessione.

In questo modello di applicazione si distribuisce un'applicazione a 2 o a 3 livelli in Macchine virtuali di Azure inserendo ciascun livello di applicazione in una diversa macchina virtuale. In aggiunta, è possibile scalare orizzontalmente il livello presentazione a causa del maggior volume di richieste client in entrata.

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera spostare le applicazioni aziendali dalle piattaforme virtualizzate locali in Macchine virtuali di Azure.

  • È opportuno scalare orizzontalmente il livello presentazione a causa del maggior volume di richieste client in entrata.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

  • Si desidera essere proprietari di un ambiente di infrastrutture che sia possibile scalare verticalmente su richiesta.

Nel diagramma seguente si dimostra come sia possibile inserire i livelli di applicazione in più macchine virtuali in Azure scalando orizzontalmente il livello presentazione a causa dell'aumentato volume di richieste di client in entrata. Come osservato nel diagramma, il servizio di bilanciamento del carico di Azure è responsabile della distribuzione del traffico tra più macchine virtuali e di determinare inoltre a quale server Web connettersi. La presenza di più istanze di server Web dietro il servizio di bilanciamento del carico assicura la disponibilità elevata del livello presentazione. Per altre informazioni, vedere le procedure consigliate per Procedure consigliate per i modelli di applicazione a 2, 3 o più livelli con più macchine virtuali in un solo livello.

Modello dell'applicazione: scalabilità orizzontale del livello presentazione

Si consiglia di collocare le macchine virtuali appartenenti allo stesso livello nello stesso servizio cloud e nello stesso set di disponibilità. Ad esempio, inserire un set di server Web in CloudService1 e AvailabilitySet1 e un set di server di database in CloudService2 e AvailabilitySet2. Un set di disponibilità in Azure consente di collocare i nodi a disponibilità elevata in domini di errore e domini di aggiornamento separati. Per altre informazioni, vedere Gestire la disponibilità delle macchine virtuali e Come connettere macchine virtuali in un servizio cloud.

Per sfruttare più istanze di macchine virtuali di un livello è necessario configurare il servizio di bilanciamento del carico di Azure tra livelli di applicazione. Per configurare il servizio di bilanciamento del carico in ogni livello, creare un endpoint con carico bilanciato separatamente sulle macchine virtuali di ogni livello. Per uno specifico livello, creare prima le macchine virtuali nello stesso servizio cloud: in tal modo, ci si assicurerà che abbiano tutte lo stesso indirizzo IP virtuale pubblico. Creare quindi un endpoint su una delle macchine virtuali su tale livello e assegnarlo ad altre macchine virtuali sullo stesso livello per il servizio di bilanciamento del carico. Creando un set con bilanciamento del carico si distribuisce il traffico tra più macchine virtuali e si consente inoltre al servizio di bilanciamento del carico di determinare a quale nodo connettersi in caso di errore del nodo della macchina virtuale back-end. Ad esempio, la presenza di più istanze di server Web dietro il servizio di bilanciamento del carico assicura la disponibilità elevata del livello presentazione.

Come procedura consigliata, assicurarsi sempre che tutte le connessioni Internet siano indirizzate prima al livello presentazione. Il livello presentazione accede al livello business, che a sua volta accede al livello dati. Ad esempio, aprire un endpoint sul livello presentazione. Ogni endpoint dispone di una porta pubblica e di una porta privata. La porta privata viene usata internamente dalla macchina virtuale per l'ascolto del traffico sull'endpoint. La porta pubblica è il punto di ingresso per la comunicazione dall'esterno di Azure e viene usata dal servizio di bilanciamento del carico di Azure. Si consiglia di configurare un elenco di controllo di accesso di rete (ACL) per definire regole che consentano di isolare e controllare il traffico in ingresso sulla porta pubblica su qualsiasi endpoint pubblico in qualsiasi livello di applicazione. Per altre informazioni, vedere Informazioni sugli elenchi di controllo di accesso di rete (ACL).

Si noti che il servizio di bilanciamento del carico in Azure ha un funzionamento simile agli stessi servizi in un ambiente locale. Per altre informazioni, vedere Bilanciamento del carico delle macchine virtuali.

In aggiunta, si consiglia di configurare una rete privata per le macchine virtuali mediante la rete virtuale di Azure, che consenta la comunicazione tra le stesse tramite indirizzo IP privato. Per altre informazioni, vedere Rete virtuale di Azure.

In questo modello di applicazione si distribuisce un'applicazione a 2 o a 3 livelli in Macchine virtuali di Azure inserendo ciascun livello di applicazione in una diversa macchina virtuale. In aggiunta, può essere opportuno distribuire i componenti del server applicazioni a più macchine virtuali data la complessità dell'applicazione.

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera spostare le applicazioni aziendali dalle piattaforme virtualizzate locali in Macchine virtuali di Azure.

  • Si desidera distribuire i componenti del server applicazioni a più macchine virtuali data la complessità dell'applicazione.

  • Si desidera spostare le applicazioni line-of-business (LOB) locali con elevato contenuto di logica di business in Macchine virtuali di Azure. Le applicazioni LOB sono un set di applicazioni per computer di importanza critica per la gestione di un'azienda, ad esempio applicazioni di contabilità, risorse umane, paghe e stipendi, gestione della catena di fornitura e pianificazione delle risorse.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

  • Si desidera essere proprietari di un ambiente di infrastrutture che sia possibile scalare verticalmente su richiesta.

Il diagramma seguente illustra uno scenario locale e la relativa soluzione abilitata per il cloud. In questo scenario, si inseriscono i livelli di applicazione in più macchine virtuali in Azure scalando orizzontalmente il livello business, che contiene i componenti del livello di logica di business e di accesso ai dati. Come osservato nel diagramma, il servizio di bilanciamento del carico di Azure è responsabile della distribuzione del traffico tra più macchine virtuali e di determinare inoltre a quale server Web connettersi. La presenza di più istanze di server applicazioni dietro il servizio di bilanciamento del carico assicura la disponibilità elevata del livello business. Per altre informazioni, vedere Procedure consigliate per i modelli di applicazione a 2, 3 o più livelli con più macchine virtuali in un solo livello.

Modello dell'applicazione con scalabilità orizzontale del livello business

In questo modello di applicazione si distribuisce un'applicazione a 2 o a 3 livelli in Macchine virtuali di Azure distribuendo i componenti del livello presentazione (server Web) e del livello business (server applicazioni) a più macchine virtuali. In aggiunta, si implementano soluzioni a disponibilità elevata e di ripristino di emergenza per i propri database in Macchine virtuali di Azure.

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera spostare applicazioni aziendali dalle piattaforme virtualizzate locali in Azure mediante l'implementazione delle capacità di disponibilità elevata e ripristino di emergenza di SQL Server.

  • Si desidera scalare orizzontalmente il livello presentazione e il livello business a causa del maggior volume di richieste client in entrata e della complessità dell'applicazione.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

  • Si desidera essere proprietari di un ambiente di infrastrutture che sia possibile scalare verticalmente su richiesta.

Il diagramma seguente illustra uno scenario locale e la relativa soluzione abilitata per il cloud. In questo scenario, si scalano orizzontalmente i componenti di livello presentazione e livello business in più macchine virtuali di Azure. In aggiunta, si implementano tecniche a disponibilità elevata e di ripristino di emergenza (HADR) per i database SQL in Azure.

L'esecuzione di più copie di un'applicazione in macchine virtuali diverse assicura che si eseguirà il bilanciamento del carico delle richieste tra le diverse VM. Quando si hanno più macchine virtuali è necessario assicurarsi che siano tutte accessibili e in esecuzione in un determinato momento. Se si configura il bilanciamento del carico, l'apposito servizio terrà traccia dell'integrità delle macchine virtuali, dirigendo correttamente le chiamate in entrata ai nodi VM funzionanti. Per informazioni su come configurare il bilanciamento del carico delle macchine virtuali, vedere Bilanciamento del carico delle macchine virtuali. La presenza di più istanze di server Web e applicazioni dietro il servizio di bilanciamento del carico assicura la disponibilità elevata del livello presentazione e business. Per altre informazioni, vedere Procedure consigliate per i modelli di applicazione che richiedono soluzioni di disponibilità elevata e ripristino di emergenza per SQL Server.

Scalabilità orizzontale e disponibilità elevata

Quando si configurano le soluzioni di disponibilità elevata e ripristino di emergenza per SQL Server in Macchine virtuali di Azure, la configurazione di una rete virtuale con Rete virtuale di Azure è obbligatoria. Le macchine virtuali nell'ambito di una rete virtuale saranno caratterizzate da un indirizzo IP privato stabile anche dopo un'interruzione del servizio; in tal modo, sarà possibile evitare i tempi di aggiornamento richiesti per la risoluzione dei nomi DNS. Per di più, la rete virtuale consente di estendere la propria rete locale ad Azure, creando un limite di sicurezza attendibile. Se ad esempio l'applicazione è caratterizzata da limitazioni di dominio aziendale (come l'autenticazione Windows o Active Directory), la configurazione della Rete virtuale di Azure è necessaria.

La maggior parte dei clienti che esegue codice di produzione su Azure mantiene repliche sia primarie sia secondarie in Azure.

Per informazioni approfondite ed esercitazioni sulle tecniche di disponibilità elevata e di ripristino di emergenza, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

In questo modello di applicazione si distribuisce un'applicazione a 2 o a 3 livelli in Azure usando sia i http://msdn.microsoft.com/en-us/library/azure/cloud-services (ruoli Web e di lavoro - Platform as a Service (PaaS)) sia http://msdn.microsoft.com/en-us/library/azure/virtual-machines (Infrastructure as a Service (IaaS)). L'uso dei http://msdn.microsoft.com/en-us/library/azure/cloud-services per il livello presentazione/business e di SQL Server in Macchine virtuali di Azure per il livello dati è vantaggioso per gran parte delle applicazioni in esecuzione su Azure. Il motivo è che l'esecuzione di un'istanza di calcolo su Servizi cloud consente di eseguire facilmente la gestione, la distribuzione, il monitoraggio e la scalabilità orizzontale.

Con Servizi cloud, Azure gestisce automaticamente l'infrastruttura, esegue la manutenzione di routine, applica patch ai sistemi operativi e tenta di correggere gli errori hardware e del servizio. Quando è necessario scalare orizzontalmente l'applicazione, sono disponibili opzioni di scalabilità orizzontale manuali e automatiche per il progetto di servizio cloud semplicemente aumentando o riducendo il numero di istanze o di macchine virtuali in uso da parte dell'applicazione. In aggiunta, è possibile usare Visual Studio localmente per distribuire l'applicazione a un progetto di servizio cloud in Azure.

Riepilogando, se non si desidera gestire attività amministrative prolungate per il livello presentazione/business e l'applicazione in uso non richiede alcuna configurazione complessa del software o del sistema operativo, usare i Servizi cloud di Azure. Se il database SQL di Azure non supporta tutte le funzionalità che si stanno cercando, usare SQL Server in una macchina virtuale di Azure per il livello dati. L'esecuzione di un'applicazione sui Servizi cloud di Azure e l'archiviazione di dati in Macchine virtuali di Azure combinano i vantaggi di entrambi i servizi. Per un confronto dettagliato, vedere Strategie di sviluppo in Azure: Confronto tra il tradizionale sviluppo Web, Servizi cloud di Azure e Siti Web di Azure.

In questo modello di applicazione, il livello presentazione include un ruolo Web, cioè un componente dei Servizi cloud in esecuzione nell'ambiente di Azure, personalizzato per la programmazione delle applicazioni Web supportata da IIS e ASP.NET. Il livello business o back-end include un ruolo di lavoro, cioè un componente dei Servizi cloud in esecuzione nell'ambiente di Azure, utile per lo sviluppo generalizzato, che potrebbe eseguire l'elaborazione in background di un ruolo Web. Il livello di database risiede in una macchina virtuale SQL Server in Azure. La comunicazione tra il livello presentazione e il livello di database avviene direttamente oppure attraverso il livello business (componenti ruolo di lavoro).

Questo modello di applicazione è utile nei seguenti casi:

  • Si desidera spostare applicazioni aziendali dalle piattaforme virtualizzate locali in Azure mediante l'implementazione delle capacità di disponibilità elevata e ripristino di emergenza di SQL Server.

  • Si desidera essere proprietari di un ambiente di infrastrutture che sia possibile scalare verticalmente su richiesta.

  • Il database SQL di Azure non supporta tutte le funzionalità di cui necessita l'applicazione in uso.

  • Si desidera eseguire il test di stress per variare i livelli del carico di lavoro ma, allo stesso tempo, non si desidera essere proprietari di molte macchine fisiche di cui eseguire la manutenzione per tutto il tempo.

Il diagramma seguente illustra uno scenario locale e la relativa soluzione abilitata per il cloud. In questo scenario, si inserisce il livello presentazione in ruoli Web, il livello business in ruoli di lavoro e il livello dati in macchine virtuali di Azure. L'esecuzione di più copie del livello presentazione in diversi ruoli di lavoro assicura che si eseguirà il bilanciamento del carico delle richieste tra di essi. Quando si combinano i Servizi cloud di Azure con Macchine virtuali di Azure, si consiglia di configurare anche la Rete virtuale di Azure. Con la rete virtuale di Azure è possibile disporre di indirizzi IP privati stabili e persistenti nell'ambito dello stesso servizio cloud nel cloud. Dopo aver definito una rete virtuale per le macchine virtuali e i servizi cloud, potranno cominciare a comunicare tra loro attraverso l'indirizzo IP privato. In aggiunta, se le macchine virtuali e i ruoli Web/di lavoro di Azure si trovano nella stessa rete virtuale di Azure si ottengono una latenza minima e una connettività più sicura. Per altre informazioni, vedere le pagine Informazioni su un servizio cloud, Modelli di esecuzione di Azure e Rete virtuale di Azure.

Come osservato nel diagramma, il servizio di bilanciamento del carico di Azure distribuisce il traffico tra più macchine virtuali e determina inoltre a quale server Web o server applicazioni connettersi. La presenza di più istanze di server Web e applicazioni dietro il servizio di bilanciamento del carico assicura la disponibilità elevata del livello presentazione e business. Per altre informazioni, vedere Procedure consigliate per i modelli di applicazione che richiedono soluzioni di disponibilità elevata e ripristino di emergenza per SQL Server.

Modelli dell'applicazione con Servizi cloud

Un altro approccio all'implementazione di questo modello di applicazione consiste nell'usare un ruolo Web consolidato che contenga componenti del livello presentazione e livello business, come illustrato nel diagramma seguente. Questo modello di applicazione è utile per le applicazioni che richiedono un design con stato. Poiché Azure fornisce nodi di calcolo senza stato su ruoli Web e di lavoro, si consiglia di implementare una logica per memorizzare lo stato della sessione mediante una delle tecnologie seguenti: http://msdn.microsoft.com/en-us/library/azure/cache, Archiviazione tabelle di Azure o Database SQL di Azure.

Modelli dell'applicazione con Servizi cloud

L'obiettivo principale di questo modello di applicazione è mostrare come combinare i componenti IaaS (Infrastructure as a Service) con i componenti PaaS (Platform as a Service) di Azure nella propria soluzione. Il modello è incentrato sul database SQL di Azure per l'archiviazione di dati relazionali e non include SQL Server in una macchina virtuale di Azure, che è parte dell'offerta IaaS di Azure.

In questo modello di applicazione si distribuisce un'applicazione di database in Azure inserendo i livelli presentazione e business nella stessa macchina virtuale e mediante l'accesso a un database nei server di database SQL (database SQL) di Azure. È possibile implementare il livello presentazione usando le tradizionali soluzioni Web basate su IIS oppure è possibile implementare un livello presentazione/business combinato usando Siti Web di Azure.

Questo modello di applicazione è utile nei seguenti casi:

  • È già stato configurato un server di database SQL esistente in Azure e si desidera testare rapidamente l'applicazione.

  • Si desidera testare le capacità dell'ambiente Azure.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • I componenti logica di business e accesso ai dati possono già essere inclusi in un'applicazione Web completa.

Il diagramma seguente illustra uno scenario locale e la relativa soluzione abilitata per il cloud. In questo scenario, si collocano i livelli di applicazione in un'unica macchina virtuale in Azure e si accede ai dati nel database SQL di Azure.

Modello dell'applicazione misto

Se si sceglie di implementare un livello Web/applicazione combinato mediante Siti Web di Azure, si consiglia di mantenere il livello intermedio o di applicazione come librerie DLL nel contesto di un'applicazione Web.

In aggiunta, leggere i consigli offerti nella sezione Strategie di sviluppo in Azure: Confronto tra il tradizionale sviluppo Web, Servizi cloud di Azure e Siti Web di Azure al termine di questo articolo per altre informazioni sulle tecniche di programmazione.

Nel modello dell'applicazione ibrido a più livelli si implementa l'applicazione in più livelli distribuiti localmente e su Azure. Di conseguenza, si crea un sistema ibrido flessibile e riutilizzabile, che sarà possibile modificare o al quale si potrà aggiungere uno specifico livello senza modificare gli altri. Per estendere la propria rete aziendale al cloud si usa il servizio di rete virtuale di Azure.

Questo modello di applicazione ibrido è utile nei seguenti casi:

  • Si desidera creare applicazioni da eseguire in parte sul cloud e in parte localmente.

  • Si desidera eseguire la migrazione sul cloud di tutti o di alcuni elementi di un'applicazione locale esistente.

  • Si desidera spostare le applicazioni aziendali dalle piattaforme virtualizzate locali su Azure.

  • Si desidera essere proprietari di un ambiente di infrastrutture che sia possibile scalare verticalmente su richiesta.

  • Si desidera eseguire rapidamente il provisioning degli ambienti di sviluppo e test per brevi periodi di tempo.

  • Si desidera trovare un modo efficace in termini di costi per eseguire i backup delle applicazioni di database aziendale.

Nel diagramma seguente è illustrato un modello dell'applicazione ibrido a più livelli distribuito localmente e su Azure. Come illustrato nel diagramma, l'infrastruttura locale include il controller di dominio dei Servizi di dominio Active Directory per supportare l'autenticazione e l'autorizzazione degli utenti. Si noti che il diagramma illustra uno scenario in cui alcune parti del livello dati risiedono in un data center locale, mentre altre parti risiedono in Azure. A seconda delle esigenze applicative è possibile implementare diversi altri scenari ibridi. Ad esempio, è possibile memorizzare il livello presentazione e il livello business in un ambiente locale, ma il livello dati in Azure.

Si verificano problemi di visualizzazione dell'argomento nella libreria di Azure? Provare a visualizzarlo in MSDN Library.

Modello dell'applicazione a più livelli

In Azure è possibile usare Active Directory come directory cloud autonoma dell'organizzazione oppure integrare Active Directory locale esistente con Azure Active Directory. Come illustrato nel diagramma, i componenti di livello business possono accedere a più origini di dati, ad esempio SQL Server in Azure, attraverso un indirizzo IP interno privato, a un SQL Server locale tramite rete virtuale oppure al database SQL usando le tecnologie del provider di dati .NET Framework. In questo diagramma, il database SQL di Azure (database SQL) è un servizio di archiviazione dati opzionale.

Nel modello di applicazione ibrido a più livelli è possibile implementare il seguente flusso di lavoro nell'ordine specificato:

  1. Identificare le applicazioni di database aziendali che devono essere spostate nel cloud usando il Microsoft Assessment and Planning (MAP) Toolkit. MAP Toolkit raccoglie i dati di inventario e di prestazioni dai computer che si vorrebbe destinare alla virtualizzazione e fornisce consigli sulla capacità e sulla pianificazione.

  2. Pianificare le risorse e la configurazione necessarie nella piattaforma Azure, ad esempio gli account di archiviazione e le macchine virtuali. Per un piano di migrazione dettagliato, vedere Preparazione della migrazione a SQL Server in Macchine virtuali di Azure.

  3. Configurare la connettività tra la rete aziendale locale e la rete virtuale di Azure. Per configurare la connessione tra la rete aziendale locale e una macchina virtuale in Azure, usare uno dei due metodi seguenti:

    1. Stabilire una connessione tra la rete locale e Azure tramite endpoint pubblici su una macchina virtuale in Azure. Questo metodo consente di configurare facilmente e usare l'autenticazione di SQL Server sulla macchina virtuale. Configurare inoltre l'elenco di controllo di accesso di rete (ACL) sulle porte pubbliche per autorizzare l'accesso di determinati indirizzi IP. Per altre informazioni, vedere Informazioni sugli elenchi di controllo di accesso di rete (ACL)

    2. Stabilire una connessione tra la rete locale e Azure tramite il tunnel VPN (Virtuale Private Network) di Azure. Questo metodo consente di estendere i criteri di dominio a una macchina virtuale in Azure. È inoltre possibile configurare le regole del firewall e usare l'autenticazione Windows nella macchina virtuale. Attualmente, Azure supporta le connessioni sicure VPN da sito a sito e VPN Point-to-Site:

      • Con la connessione da sito a sito sicura è possibile stabilire la connettività di rete tra la rete locale e la rete virtuale in Azure. È consigliata per la connessione dell'ambiente del data center locale ad Azure.

      • Con la connessione da sito a sito sicura è possibile stabilire la connettività di rete tra rete virtuale in Azure e i singoli computer in esecuzione ovunque. È consigliata principalmente a scopi di sviluppo e test.

      Per informazioni su come connettersi a SQL Server in Azure, vedere Considerazioni relative alla connettività per SQL Server in Macchine virtuali di Azure.

  4. Configurare i lavori e gli avvisi pianificati per il backup dei dati locali sul disco di una macchina virtuale in Azure. Per altre informazioni, vedere Backup e ripristino di SQL Server con il servizio di archiviazione BLOB di Azure e Backup e ripristino per SQL Server in Macchine virtuali di Azure.

  5. A seconda delle esigenze applicative è possibile implementare uno tra i tre scenari comuni seguenti:

    1. È possibile mantenere il server Web, il server applicazioni e i dati non sensibili in un server di database in Azure laddove si conservino i dati sensibili localmente.

    2. È possibile mantenere il server Web e il server applicazioni localmente laddove il server di database si trovi su una macchina virtuale in Azure.

    3. È possibile mantenere il server di database, il server Web e il server applicazioni localmente laddove le repliche di database si trovino su macchine virtuali in Azure. Questa impostazione consente ai server Web o alle applicazioni di creazione report locali di accedere alle repliche del database in Azure. Di conseguenza, è possibile ridurre il carico di lavoro in un database locale. Si consiglia di implementare questo scenario per i carichi di lavoro a elevato utilizzo di lettura e per scopi di sviluppo. Per informazioni sulla creazione di repliche di database in Azure, vedere i Gruppi di disponibilità AlwaysOn nella sezione Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

Per implementare e distribuire un'applicazione basata su SQL Server a più livelli è possibile usare uno dei due seguenti metodi di programmazione:

  • Configurare un server Web tradizionale (IIS - Internet Information Services) in Azure e accedere ai database in SQL Server in Macchine virtuali di Azure.

  • Implementare e distribuire un servizio cloud in Azure. Assicurarsi quindi che questo servizio cloud possa accedere ai database in SQL Server in Macchine virtuali di Azure. Un servizio cloud può includere più ruoli Web e di lavoro.

Nella tabella seguente è illustrato un confronto tra il tradizionale sviluppo Web e Servizi cloud di Azure e Siti Web di Azure per quanto riguarda SQL Server in Macchine virtuali di Azure. La tabella include Siti Web di Azure in quanto è possibile usare SQL Server nella VM di Azure come origine dati per Siti Web di Azure tramite l'indirizzo IP virtuale pubblico o il nome DNS.

Si verificano problemi di visualizzazione dell'argomento nella libreria di Azure? Provare a visualizzarlo in MSDN Library.

 

Sviluppo Web tradizionale in Macchine virtuali di Azure

Servizi cloud di Azure

Hosting Web con Siti Web di Azure

Migrazione dell'applicazione dalla rete locale

  • Applicazioni esistenti così come sono

  • Le applicazioni necessitano di ruoli Web e di lavoro.

  • Applicazioni esistenti così come sono, ma idonee ad applicazioni Web e servizi Web completi che richiedono una rapida scalabilità.

Sviluppo e distribuzione

  • Visual Studio, WebMatrix, Visual Web Developer, WebDeploy, FTP, TFS, IIS Manager, PowerShell.

  • Visual Studio, Azure SDK, TFS, PowerShell. Ogni servizio cloud dispone di due ambienti in cui è possibile distribuire il pacchetto e la configurazione del servizio: gestione temporanea e produzione. È possibile distribuire un servizio cloud nell'ambiente di gestione temporanea per testarlo prima di promuoverlo alla produzione.

  • Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy, PowerShell.

Amministrazione e configurazione

  • L'utente è responsabile delle attività amministrative condotte su applicazione, dati, regole del firewall, rete virtuale e sistema operativo.

  • L'utente è responsabile delle attività amministrative condotte su applicazione, dati, regole del firewall e rete virtuale.

  • L'utente è responsabile delle attività amministrative condotte solo su applicazione e dati.

Disponibilità elevata e ripristino di emergenza (HADR)

  • Si consiglia di collocare le macchine virtuali nello stesso set di disponibilità e nello stesso servizio cloud. L'inserimento delle macchine virtuali nello stesso set di disponibilità consente ad Azure di collocare i nodi a disponibilità elevata in domini di errore e domini di aggiornamento separati. In maniera analoga, l'inserimento delle macchine virtuali nello stesso servizio cloud consente al servizio di bilanciamento del carico e alle macchine virtuali di comunicare direttamente tra loro attraverso la rete locale nell'ambito di un data center di Azure.

  • L'utente è responsabile dell'implementazione di una soluzione di disponibilità elevata e ripristino di emergenza per SQL Server in Macchine virtuali di Azure per evitare qualsiasi tempo di inattività. Per le tecnologie HADR supportate, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

  • L'utente è responsabile del backup dei propri dati e dell'applicazione.

  • Azure può spostare le macchine virtuali in caso di esito negativo della macchina host nel data center a causa di problemi hardware. In aggiunta, potrebbero verificarsi tempi di inattività pianificati della macchina virtuale quando si eseguono aggiornamenti di sicurezza o software della macchina host. Di conseguenza, si consiglia di mantenere almeno due macchine virtuali in ogni livello di applicazione per garantirne la continua disponibilità. Azure non fornisce contratti di servizio per una singola macchina virtuale. Per altre informazioni, vedere Informazioni tecniche sulla continuità aziendale di Azure.

  • Azure gestisce i guasti dovuti all'hardware sottostante o agli errori del software del sistema operativo. Si consiglia di implementare più istanze di un ruolo Web o di lavoro per garantire la disponibilità elevata dell'applicazione. Per informazioni, vedere la pagina relativa al contratto di servizio per servizi cloud, macchine virtuali e rete virtuale e Ripristino di emergenza e disponibilità elevata per applicazioni Azure

  • L'utente è responsabile del backup dei propri dati e dell'applicazione.

  • Per i database che risiedono in un database SQL Server in una macchina virtuale di Azure, l'utente è responsabile dell'implementazione di una soluzione di disponibilità elevata e ripristino di emergenza per evitare qualsiasi tempo di inattività. Per le tecnologie HADR supportate, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

  • Mirroring del database in SQL Server: supportato quando usato con Servizi cloud di Azure (ruoli Web/di lavoro). Le macchine virtuali di SQL Server e un progetto di servizio cloud possono risiedere nella stessa rete virtuale di Azure. Se la macchina virtuale di SQL Server non si trova nella stessa rete virtuale è necessario creare un alias di SQL Server per indirizzare la comunicazione all'istanza di SQL Server. In aggiunta, il nome alias deve corrispondere al nome dell'istanza di SQL Server.

  • La disponibilità elevata viene ereditata dai ruoli di lavoro di Azure, dall'archiviazione BLOB di Azure e dal database SQL di Azure. Il servizio di archiviazione di Azure gestisce ad esempio tre repliche di tutti i dati di BLOB, tabelle e code. In qualsiasi momento, il database SQL di Azure mantiene tre repliche di dati in esecuzione: una replica primaria e due repliche secondarie. Per altre informazioni, vedere Archiviazione e Database SQL.

  • Quando si usa SQL Server nella macchina virtuale di Azure come origine dati per Siti Web di Azure, tenere presente che Siti Web di Azure non supporta la rete virtuale di Azure. In altri termini, tutte le connessioni da Siti Web di Azure alle macchine virtuali di SQL Server in Azure devono attraversare gli endpoint pubblici delle macchine virtuali. Ciò potrebbe causare alcune limitazioni per gli scenari di disponibilità elevata e ripristino di emergenza. Ad esempio, l'applicazione client su Siti Web di Azure che si connette alla macchina virtuale di SQL Server con il mirroring del database non potrebbe connettersi al nuovo server primario, in quanto il mirroring richiede la configurazione della rete virtuale di Azure tra le macchine virtuali host di SQL Server in Azure. Pertanto, l'uso del mirroring dei database SQL Server con Siti Web di Azure non è attualmente supportato.

  • Gruppi di disponibilità di SQL Server AlwaysOn È possibile configurare i gruppi di disponibilità di SQL Server AlwaysOn quando si usa Siti Web di Azure con le macchine virtuali di SQL Server in Azure. È tuttavia necessario configurare il listener dei gruppi di disponibilità di SQL Server AlwaysOn in modo da indirizzare la comunicazione alla replica primaria tramite gli endpoint pubblici con bilanciamento del carico.

Connettività tra più sedi locali

  • È possibile usare la rete virtuale di Azure per la connessione alla sede locale.

  • È possibile usare la rete virtuale di Azure per la connessione alla sede locale.

Scalabilità

  • La scalabilità verticale è disponibile aumentando le dimensioni della macchina virtuale oppure aggiungendo più dischi. Per altre informazioni sulle dimensioni delle macchine virtuali, vedere la pagina relativa alle dimensioni delle macchine virtuali e dei servizi cloud per Azure.

  • Per il server di database: La scalabilità orizzontale è disponibile tramite le tecniche di partizionamento del database e i gruppi di disponibilità di SQL Server AlwaysOn.

    Per i carichi di lavoro a elevato utilizzo di lettura è possibile usare i gruppi di disponibilità AlwaysOn su più nodi secondari nonché la replica di SQL Server.

    Per i carichi di lavoro a elevato utilizzo di scrittura è possibile implementare il partizionamento orizzontale di database tra più server fisici per creare applicazioni con scalabilità orizzontale.

    In aggiunta, è possibile implementare una scalabilità orizzontale usando SQL Server con il routing dipendente dai dati. Con il routing dipendente dai dati (DDR, Data Dependent Routing) è necessario implementare il meccanismo di partizionamento nell'applicazione client, in genere nel livello business, per indirizzare le richieste del database a più nodi SQL Server. Il livello business contiene mapping alla modalità di partizionamento dei dati e a quale nodo contiene i dati.


  • È possibile applicare la scalabilità alle applicazioni in cui vengono eseguite le macchine virtuali. Per altre informazioni, vedere Come scalare un'applicazione.

    Nota importante: la funzionalità di scalabilità automatica di Azure consente di aumentare o ridurre automaticamente il numero di macchine virtuali usate dall'applicazione. In questo modo l'esperienza degli utenti finali non è compromessa nei periodi di massima attività e le VM sono spente quando la domanda è bassa. È consigliabile non impostare l'opzione di scalabilità automatica per il servizio cloud se include VM di SQL Server. La funzionalità di scalabilità automatica, infatti, consente a Azure di accendere una macchina virtuale quando l'utilizzo della CPU in tale VM è superiore rispetto a una certa soglia e di spegnerla quando l'utilizzo della CPU scende al di sotto di tale soglia. Si tratta di una funzionalità utile per le applicazioni senza stato, ad esempio i server Web, in cui tutte le VM possono gestire il carico di lavoro senza riferimenti allo stato precedente. Non è invece utile per le applicazioni con stato, come SQL Server, in cui solo un'istanza consente la scrittura nel database.

  • La scalabilità verticale è disponibile usando più ruoli Web e di lavoro. Per altre informazioni sulle dimensioni delle macchine virtuali per ruoli Web e ruoli di lavoro, vedere Configurare le dimensioni dei servizi cloud.

  • Quando si usa Cloud Services è possibile definire più ruoli per distribuire l'elaborazione nonché per conseguire la scalabilità flessibile dell'applicazione. Ciascun servizio cloud include uno o più ruoli Web e/o ruoli di lavoro, ognuno con i rispettivi file e configurazione dell'applicazione. È possibile scalare verticalmente un servizio cloud aumentando il numero di istanze del ruolo (macchine virtuali) distribuite per un ruolo o riducendo il numero di istanze del ruolo. Per informazioni dettagliate, vedere Modelli di esecuzione di Azure.

  • La scalabilità orizzontale è disponile tramite il supporto a disponibilità elevata incorporato in Azure tramite il contratto di servizio per servizi cloud, macchine virtuali e rete virtuale e il servizio di bilanciamento del carico.

  • Per un'applicazione multilivello si consiglia di connettere l'applicazione dei ruoli Web/di lavoro alle macchine virtuali del server di database tramite la rete virtuale di Azure. In più, Azure offre il bilanciamento del carico per macchine virtuali nello stesso servizio cloud, distribuendo le richieste degli utenti tra le VM. Le macchine virtuali connesse in tale modo saranno in grado di comunicare direttamente tra loro sulla rete locale in un data center di Azure.

  • È possibile impostare la scalabilità automatica sul portale di gestione, oltre alle ore di pianificazione. Per altre informazioni, vedere Come scalare un'applicazione.

  • Scalabilità verticale (verso l'alto o il basso): È possibile aumentare/ridurre le dimensioni dell'istanza (VM) riservata per il sito Web.

  • Scalabilità orizzontale: È possibile aggiungere istanze riservate (VM) per il sito Web.

  • È possibile impostare la scalabilità automatica sul portale di gestione, oltre alle ore di pianificazione. Per altre informazioni, vedere Come scalare un sito Web.

Per altre informazioni sulla scelta tra i metodi di programmazione disponibili, vedere la pagina relativa al confronto tra Siti Web di Azure, Servizi cloud e VM .

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2015 Microsoft