Data center virtuale: una prospettiva di rete

Le applicazioni migrate dall'ambiente locale possono trarre vantaggio dall'infrastruttura conveniente e sicura di Azure, anche con modifiche minime alle applicazioni. Le aziende di grandi dimensioni potrebbero voler adattare le proprie architetture per migliorare l'agilità e sfruttare le funzionalità di Azure.

Microsoft Azure offre servizi e infrastruttura con iperscalabilità con funzionalità e affidabilità di livello aziendale. Questi servizi e l'infrastruttura offrono molte opzioni di connettività ibrida, che consente ai clienti di accedere a tale infrastruttura e a tali servizi tramite Internet o una connessione di rete privata. I partner Microsoft mettono inoltre a disposizione funzionalità avanzate offrendo servizi di sicurezza e appliance virtuali ottimizzati per l'esecuzione in Azure.

I clienti possono usare Azure per estendere con facilità la propria infrastruttura nel cloud e sviluppare architetture multilivello.

Che cos'è un data center virtuale?

All'inizio il cloud era una piattaforma il cui scopo era ospitare applicazioni pubbliche. Col tempo le aziende ne hanno riconosciuto il valore e hanno iniziato a migrarvi le applicazioni line-of-business interne. Queste applicazioni hanno portato più sicurezza, affidabilità, prestazioni e costi considerazioni che richiedevano maggiore flessibilità durante la distribuzione di servizi cloud. Per aumentare la flessibilità sono stati progettati una nuova infrastruttura e nuovi servizi di rete. Le nuove funzionalità offrono scalabilità elastica, ripristino di emergenza e altre considerazioni.

Le soluzioni cloud sono state inizialmente progettate per ospitare singole applicazioni relativamente isolate nell'ambito pubblico. Per alcuni anni queste soluzioni sono state una scelta valida. Man mano che i vantaggi delle soluzioni cloud sono diventati evidenti, sono aumentati i carichi di lavoro di grandi dimensioni ospitati nel cloud. Per la distribuzione e il ciclo di vita del servizio cloud è fondamentale risolvere i problemi relativi a sicurezza, affidabilità, prestazioni e costi.

Nel diagramma di distribuzione cloud di esempio riportato di seguito la casella rossa evidenzia una lacuna nella sicurezza. La casella gialla mostra l'opportunità di ottimizzare le appliance virtuali di rete tra i carichi di lavoro.

I data center virtuali aiutano a ottenere la scalabilità necessaria per i carichi di lavoro aziendali. La scalabilità deve risolvere i problemi introdotti con l'esecuzione di applicazioni su larga scala nel cloud pubblico.

L'implementazione di un data center virtuale non include solo i carichi di lavoro delle applicazioni nel cloud. Offre anche servizi di rete, di sicurezza, di gestione, DNS e Active Directory. Man mano che le aziende migrano più carichi di lavoro ad Azure, occorre considerare l'infrastruttura e gli oggetti che li supportano. Una buona gestione delle risorse aiuta a evitare l'aumento delle "isole di carichi di lavoro" gestite separatamente, con flussi di dati e modelli di sicurezza indipendenti e con problemi di conformità.

Il concetto di data center virtuale fornisce raccomandazioni e progettazioni generali per l'implementazione di una raccolta di entità separate ma correlate. Queste entità presentano spesso funzioni, caratteristiche e infrastruttura di supporto comuni. La visualizzazione dei carichi di lavoro come data center virtuale consente di ridurre i costi derivanti dalle economie di scala. Consente inoltre di ottimizzare la sicurezza tramite la centralizzazione del flusso di dati e dei componenti, nonché operazioni, gestione e controlli di conformità semplificati.

Un data center virtuale consente alle aziende di distribuire carichi di lavoro e applicazioni in Azure per gli scenari seguenti:

• Hosting di più carichi di lavoro correlati
• Migrazione dei carichi di lavoro da un ambiente locale ad Azure
• Implementazione di requisiti di sicurezza e accesso condivisi o centralizzati nei carichi di lavoro
• Combinazione di DevOps e IT centralizzato appropriata a un'azienda di grandi dimensioni.

Chi deve implementare un data center virtuale?

Qualsiasi cliente che decide di adottare Azure può trarre vantaggio dall'efficienza della configurazione di un set di risorse per l'uso comune da parte di tutte le applicazioni. A seconda delle dimensioni, anche le singole applicazioni possono trarre vantaggio dai modelli e dai componenti usati per creare l'implementazione di un data center virtuale.

Alcune organizzazioni hanno team o reparti centralizzati per l'IT, la rete, la sicurezza o la conformità. L'implementazione di un data center virtuale consente di applicare punti di criteri, responsabilità separate e garantire la coerenza dei componenti comuni sottostanti. I team delle applicazioni mantengono la libertà e il controllo adatti alle proprie esigenze.

Le organizzazioni con un approccio DevOps possono inoltre usare i concetti di data center virtuale per fornire raggruppamenti autorizzati di risorse di Azure. Questo metodo garantisce che i gruppi DevOps abbiano il controllo totale all'interno di tale raggruppamento, a livello di sottoscrizione o all'interno di gruppi di risorse in una sottoscrizione comune. Allo stesso tempo, i limiti di rete e sicurezza rimangono conformi. La conformità è definita da un criterio centralizzato nella rete hub e dal gruppo di risorse gestito centralmente.

Considerazioni sull'implementazione di un data center virtuale

Quando si progetta un data center virtuale, è opportuno considerare i seguenti problemi centrali:

Servizio di identità e servizio directory

I servizi directory e di identità sono funzionalità chiave dei data center sia locali sia nel cloud. L'identità copre tutti gli aspetti dell'accesso e dell'autorizzazione ai servizi nell'implementazione di un data center virtuale. Per garantire che solo gli utenti e i processi autorizzati accedano alle risorse di Azure, Azure usa diversi tipi di credenziali per l'autenticazione, tra cui le password dell'account, le chiavi crittografiche, le firme digitali e i certificati. L'autenticazione a più fattori Microsoft Entra offre un ulteriore livello di sicurezza per l'accesso ai servizi di Azure. Un'autenticazione avanzata con una gamma di opzioni di verifica semplici (telefonata, SMS o notifica dell'app per dispositivi mobili) consente ai clienti di scegliere il metodo preferito.

Le aziende di grandi dimensioni devono definire processi di gestione delle identità che descrivono la gestione delle singole identità, l'autenticazione, l'autorizzazione, i ruoli e i privilegi all'interno o nel data center virtuale. Gli obiettivi di questo processo possono aumentare la sicurezza e la produttività, riducendo al contempo i costi, i tempi di inattività e le attività manuali ripetitive.

Le organizzazioni aziendali potrebbero richiedere una combinazione impegnativa di servizi per diverse linee di business. I dipendenti hanno spesso ruoli diversi quando sono coinvolti in progetti diversi. Il data center virtuale richiede una buona collaborazione tra team diversi, ognuno con definizioni di ruolo specifiche per ottenere sistemi in esecuzione con una buona governance. L'insieme di responsabilità, accesso e diritti può essere complesso. La gestione delle identità nel data center virtuale viene implementata tramite Microsoft Entra ID e il controllo degli accessi in base al ruolo di Azure.

Un servizio directory è un'infrastruttura di informazioni condivisa per individuare, gestire, amministrare e organizzare quotidianamente elementi e risorse di rete. Queste risorse possono includere volumi, cartelle, file, stampanti, utenti, gruppi, dispositivi e altri oggetti. Ogni risorsa presente nella rete è considerata un oggetto dal server di directory. Le informazioni su una risorsa vengono archiviate come raccolta di attributi associati a tale risorsa o oggetto.

Tutti i servizi aziendali online Microsoft si basano su Microsoft Entra ID per l'accesso e altre esigenze di identità. Microsoft Entra ID è una soluzione cloud completa e a disponibilità elevata per la gestione delle identità e degli accessi che combina i servizi directory principali, la governance avanzata delle identità e la gestione degli accessi alle applicazioni. Microsoft Entra ID può essere integrato con Active Directory locale per abilitare l'accesso Single Sign-On per tutte le applicazioni locali basate sul cloud e ospitate localmente. Gli attributi utente di Active Directory locale possono essere sincronizzati automaticamente con Microsoft Entra ID.

Ogni reparto specifico, gruppo di utenti o servizi nel servizio directory deve disporre delle autorizzazioni minime necessarie per gestire le proprie risorse all'interno di un'implementazione del data center virtuale. La struttura delle autorizzazioni deve essere ben bilanciata. Troppe autorizzazioni possono ostacolare le prestazioni, mentre autorizzazioni non sufficienti o approssimative possono aumentare i rischi per la sicurezza. Il controllo degli accessi in base al ruolo di Azure consente di risolvere questo problema offrendo una gestione degli accessi con granularità fine per le risorse in un'implementazione del data center virtuale.

Infrastruttura di sicurezza

Il termine infrastruttura di sicurezza si riferisce alla separazione del traffico nel segmento di rete virtuale specifico dell'implementazione di un data center virtuale. Questa infrastruttura specifica come viene controllato il traffico in ingresso e in uscita nell'implementazione di un data center virtuale. Azure si basa su un'architettura multi-tenant che impedisce il traffico non autorizzato e non intenzionale tra le distribuzioni. Questa operazione viene eseguita usando l'isolamento della rete virtuale, gli elenchi di controllo di accesso, i servizi di bilanciamento del carico, i filtri IP e i criteri del flusso di traffico. Network Address Translation (NAT) separa il traffico di rete interno dal traffico esterno.

L'infrastruttura di Azure alloca le risorse dell'infrastruttura ai carichi di lavoro tenant e gestisce le comunicazioni da e verso Macchine virtuali (VM). L'hypervisor di Azure impone la separazione di memoria e processi tra le VM e instrada in modo sicuro il traffico di rete ai tenant del sistema operativo guest.

Connettività al cloud

Un data center virtuale necessita della connettività con reti esterne per offrire i servizi a clienti, partner e/o utenti interni, quindi è in genere necessaria la connettività non solo a Internet, ma anche alle reti e ai data center locali.

I clienti controllano i servizi accessibili e accessibili dalla rete Internet pubblica. Questo accesso viene controllato tramite Firewall di Azure o altri tipi di appliance di rete virtuale, criteri di routing personalizzati tramite route definite dall'utente e filtri di rete tramite gruppi di sicurezza di rete. È consigliabile proteggere tutte le risorse con connessione Internet dalla protezione DDoS di Azure.

Le aziende potrebbero dover connettere il data center virtuale a data center locali o ad altre risorse. La connettività tra Azure e le reti locali è quindi un aspetto fondamentale della progettazione di un'architettura efficace. Le aziende possono creare questa interconnessione in due modi diversi: con transito sulla rete Internet o tramite connessioni dirette private.

Una VPN da sito a sito di Azure connette le reti locali al data center virtuale in Azure. Il collegamento viene stabilito attraverso connessioni crittografate protette (tunnel IPsec). Le connessioni VPN da sito a sito di Azure sono flessibili, veloci da creare e in genere non richiedono più approvvigionamento hardware. In base ai protocolli standard del settore, la maggior parte dei dispositivi di rete attuali può creare connessioni VPN ad Azure tramite Internet o percorsi di connettività esistenti.

ExpressRoute consente di creare connessioni private tra il data center virtuale e qualsiasi rete locale. Le connessioni ExpressRoute non usano la rete Internet pubblica e offrono un livello di sicurezza superiore, maggiore affidabilità e velocità più elevate (fino a 100 Gbps), oltre a una latenza uniforme. ExpressRoute offre i vantaggi delle regole di conformità associate alle connessioni private. Con ExpressRoute Direct è possibile connettersi direttamente ai router Microsoft a 10 Gbps o 100 Gbps.

Per distribuire le connessioni ExpressRoute è in genere necessario usare un provider di servizi ExpressRoute (ExpressRoute Direct fa eccezione). I clienti che devono iniziare rapidamente di solito usano prima una VPN da sito a sito per stabilire la connettività tra il data center virtuale e le risorse locali. Al termine dell'interconnessione fisica con il provider di servizi, eseguire la migrazione della connettività tramite la connessione ExpressRoute.

Per gestire numeri elevati di connessioni VPN o ExpressRoute, esiste la rete WAN virtuale di Azure, che è un servizio di rete che offre connettività da ramo a ramo ottimizzata e automatizzata attraverso Azure. La rete WAN virtuale consente di connettere e configurare i dispositivi delle succursali per comunicare con Azure. La connessione e la configurazione possono essere eseguite manualmente oppure usando i dispositivi di provider preferiti tramite un partner di rete WAN virtuale. L'uso di dispositivi di provider preferiti consente la facilità d'uso, semplifica le operazioni di connettività e agevola la gestione della configurazione. Il dashboard predefinito della rete WAN di Azure offre informazioni dettagliate immediate per la risoluzione dei problemi, che consentono di risparmiare tempo, e permette di visualizzare con facilità la connettività da sito a sito su larga scala. La rete WAN virtuale offre anche servizi di sicurezza grazie a Firewall di Azure e Gestione firewall facoltativi nell'hub della rete WAN virtuale.

Connettività all'interno del cloud

Le reti virtuali di Azure e il peering di reti virtuali sono i componenti di rete di base in un data center virtuale. Una rete virtuale garantisce un limite di isolamento per le risorse del data center virtuale. Il peering consente l'intercomunicazione tra reti virtuali diverse all'interno della stessa area di Azure, tra aree e anche tra reti in sottoscrizioni diverse. I flussi di traffico possono essere controllati all'interno e tra reti virtuali tramite set di regole di sicurezza specificate per i gruppi di sicurezza di rete, i criteri firewall (Firewall di Azure o le appliance virtuali di rete) e le route personalizzate definite dall'utente.

Le reti virtuali sono punti di ancoraggio per l'integrazione di prodotti Azure PaaS (Platform as a Service), ad esempio Archiviazione di Azure, Azure SQL e altri servizi pubblici integrati con endpoint pubblici. Con gli endpoint di servizio e il collegamento privato di Azure è possibile integrare i propri servizi pubblici con la propria rete privata. È anche possibile rendere i propri servizi pubblici privati e sfruttare comunque i vantaggi dei servizi PaaS gestiti da Azure.

Panoramica del data center virtuale

Topologie

È possibile creare un data center virtuale usando una di queste topologie generali. La scelta dipenderà dalle proprie esigenze e dai propri requisiti di scalabilità:

In una topologia flat tutte le risorse vengono distribuite in una singola rete virtuale. Le subnet consentono il controllo del flusso e la separazione.

In una topologia di tipo rete di peer il peering di reti virtuali connette tutte le reti virtuali direttamente tra loro.

Una topologia di tipo peering hub-spoke è particolarmente adatta per le applicazioni distribuite e i team con responsabilità delegate.

Una topologia di tipo rete WAN virtuale di Azure può supportare scenari di succursali su larga scala e servizi WAN globali.

Le topologie di tipo peering hub-spoke e rete WAN virtuale di Azure usano entrambe una progettazione hub-spoke, che risulta ottimale per la comunicazione, le risorse condivise e i criteri di sicurezza centralizzati. Gli hub vengono creati usando un hub di peering di reti virtuali (indicato come Hub Virtual Network nel diagramma) o un hub di rete WAN virtuale (indicato come Azure Virtual WAN nel diagramma). La rete WAN virtuale di Azure è progettata per le comunicazioni da ramo a ramo e da ramo ad Azure su larga scala o per evitare le complessità che nascono quando si creano tutti i componenti singolarmente in un hub di peering di reti virtuali. In alcuni casi, per esigenze dell'azienda, potrebbe essere necessario progettare un hub di peering di reti virtuali, ad esempio se servono appliance virtuali di rete nell'hub.

Nelle topologie hub-spoke l'hub è la zona di rete centrale che controlla e controlla tutto il traffico tra zone diverse, ad esempio Internet, locale e spoke. La topologia hub-spoke consente al reparto IT di applicare i criteri di sicurezza centralmente. riducendo al contempo il rischio di configurazione non corretta ed esposizione.

L'hub spesso contiene componenti di servizio comuni utilizzati dagli spoke. Di seguito sono riportati alcuni esempi di servizi centrali comuni:

• L'infrastruttura di Windows Active Directory è necessaria per l'autenticazione utente di terze parti che accedono da reti non attendibili prima di ottenere l'accesso ai carichi di lavoro nello spoke. Include i servizi Active Directory Federation Services correlati (AD FS)
• Un servizio DNS (Distributed Name System) viene usato per risolvere la denominazione per il carico di lavoro negli spoke e per accedere alle risorse in locale e su Internet se dns di Azure non viene usato
• Viene usata un'infrastruttura a chiave pubblica (PKI) per implementare i carichi di lavoro Single Sign-On
• Controllo del flusso del traffico TCP e UDP tra le zone di rete spoke e Internet
• Controllo del flusso tra gli spoke e l'ambiente locale
• Se necessario, il controllo del flusso tra uno spoke e un altro

Il data center virtuale riduce il costo complessivo usando l'infrastruttura dell'hub condiviso tra più spoke.

Il ruolo di ogni spoke può essere quello di ospitare tipi diversi di carichi di lavoro. Gli spoke consentono anche un approccio modulare per le distribuzioni ripetibili degli stessi carichi di lavoro. Alcuni esempi includono sviluppo/test, test di accettazione utente, pre-produzione e produzione. Gli spoke possono anche essere usati per isolare e consentire gruppi diversi all'interno dell'organizzazione, I gruppi DevOps sono un buon esempio delle operazioni che gli spoke possono eseguire. In uno spoke è possibile distribuire un carico di lavoro di base o carichi di lavoro complessi multilivello con il controllo del traffico tra i livelli.

Limiti della sottoscrizione e hub multipli

In Azure ogni componente, indipendentemente dal tipo, viene distribuito in una sottoscrizione di Azure. L'isolamento dei componenti di Azure in diverse sottoscrizioni di Azure può soddisfare i requisiti di diverse line-of-business, come la configurazione di livelli differenziati di accesso e autorizzazione.

Un'implementazione di un singolo data center virtuale può aumentare un numero elevato di spoke. Anche se, come per ogni sistema IT, esistono limiti di piattaforma. La distribuzione dell'hub è associata a una sottoscrizione di Azure specifica, con restrizioni e limiti, ad esempio un numero massimo di peering di rete virtuale. Per informazioni dettagliate, vedere Sottoscrizione di Azure e limiti, quote e vincoli del servizio. Nei casi in cui i limiti potrebbero essere un problema, l'architettura può aumentare ulteriormente estendendo il modello da un singolo hub spoke a un cluster di hub e spoke. È possibile connettere più hub in una o più aree di Azure usando il peering di reti virtuali, ExpressRoute, la rete WAN virtuale o una VPN da sito a sito.

L'introduzione di più hub aumenta il costo e l'impegno di gestione del sistema È giustificato solo a causa della scalabilità, dei limiti di sistema, della ridondanza, della replica a livello di area per le prestazioni dell'utente finale o del ripristino di emergenza. Negli scenari in cui sono necessari più hub, tutti gli hub devono cercare di offrire lo stesso set di servizi per facilitare le operazioni.

Interconnessione tra spoke

All'interno di un singolo spoke o di una progettazione di rete flat, è possibile implementare carichi di lavoro multilivello complessi. Le configurazioni multilivello possono essere implementate usando subnet, che sono una per ogni livello o applicazione nella stessa rete virtuale. Il controllo del traffico e l'applicazione di filtri vengono evasi usando i gruppi di sicurezza di rete e le route definite dall'utente.

Un architetto potrebbe voler distribuire un carico di lavoro multilivello in più reti virtuali. Usando il peering di rete virtuale, gli spoke possono connettersi ad altri spoke nello stesso hub o in hub diversi. Un esempio tipico di questo scenario è quello in cui i server di elaborazione delle applicazioni sono in uno spoke o rete virtuale, mentre il database viene distribuito in un altro spoke o rete virtuale. In questo caso, è facile interconnettere gli spoke con il peering di rete virtuale, evitando così il transito attraverso l'hub. Completare un'attenta revisione dell'architettura e della sicurezza per assicurarsi che il bypass dell'hub non ignori importanti punti di sicurezza o di controllo che potrebbero esistere solo nell'hub.

Gli spoke possono anche interconnettersi a uno spoke che funge da hub. Questo approccio crea una gerarchia a due livelli. Lo spoke nel livello superiore (livello 0) diventa l'hub degli spoke inferiori (livello 1) della gerarchia. Gli spoke per un'implementazione del data center virtuale sono necessari per inoltrare il traffico all'hub centrale. Il traffico può quindi passare alla destinazione nella rete locale o nella rete Internet pubblica. Un'architettura con due livelli di hub crea un routing complesso che elimina i vantaggi di una relazione hub-spoke semplice.

Anche se Azure consente topologie complesse, uno dei principi fondamentali del data center virtuale è il concetto di ripetibilità e semplicità. Per ridurre al minimo l'impegno di gestione, la progettazione hub-spoke semplice è l'architettura di riferimento consigliata per il data center virtuale.

Componenti

Il data center virtuale è costituito da quattro tipi di componenti di base: infrastruttura, reti perimetrali, carichi di lavoro e monitoraggio.

Ogni tipo di componente è costituito da diverse funzionalità e risorse di Azure. L'implementazione del data center virtuale è costituita da istanze di più tipi di componenti e più varianti dello stesso tipo di componente. È possibile, ad esempio, avere più istanze di carico di lavoro diverse separate in modo logico che rappresentano applicazioni diverse. Questi diversi tipi di componenti e istanze vengono usati per compilare il data center virtuale.

L'architettura concettuale generale precedente del data center virtuale illustra tipi di componenti diversi usati in zone diverse della topologia hub-spoke. Il diagramma illustra i componenti dell'infrastruttura in svariate parti dell'architettura.

Come procedura consigliata in generale, i diritti di accesso e i privilegi possono essere basati sul gruppo. Gestire i gruppi anziché i singoli utenti semplifica la manutenzione dei criteri di accesso, fornendo un modo coerente per gestirlo tra i team, che consente di ridurre al minimo gli errori di configurazione. L'assegnazione e la rimozione di utenti da e verso i gruppi appropriati consente di mantenere aggiornati i privilegi di un utente specifico.

Ogni gruppo di ruoli può avere un prefisso univoco sui nomi. Questo prefisso semplifica l'identificazione del carico di lavoro a cui è associato un gruppo. Un carico di lavoro che ospita un servizio di autenticazione, ad esempio, potrebbe avere gruppi denominati AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps e AuthServiceInfraOps. I ruoli centralizzati o i ruoli non correlati a un servizio specifico potrebbero essere preceduti dal termine Corp. Un esempio è CorpNetOps.

Molte organizzazioni usano una variante dei gruppi seguenti per una suddivisione primaria dei ruoli:

• Il team IT centrale denominato Corp dispone dei diritti di proprietà sul controllo dei componenti dell'infrastruttura (ad esempio, rete e sicurezza) e quindi deve avere il ruolo Collaboratore nella sottoscrizione (e avere il controllo dell'hub) e i diritti di Collaboratore Rete negli spoke. Le grandi organizzazioni spesso suddividono queste responsabilità di gestione tra più team, ad esempio un gruppo per le operazioni di rete CorpNetOps, dedicato esclusivamente alle rete, e un gruppo per le operazioni di sicurezza CorpSecOps, responsabile del firewall e dei criteri di sicurezza. In questo caso specifico è necessario creare due gruppi diversi per l'assegnazione di questi ruoli personalizzati.
• Il gruppo di sviluppo/test denominato AppDevOps ha la responsabilità di distribuire i carichi di lavoro di app o servizi. Questo gruppo ha il ruolo Collaboratore Macchina virtuale per le distribuzioni IaaS oppure uno o più ruoli del collaboratore PaaS. Per altre informazioni, vedere Ruoli predefiniti di Azure. Per il team sviluppo/test potrebbe essere necessario avere visibilità sui criteri di sicurezza (gruppi di sicurezza di rete) e sui criteri di routing (route definite dall'utente) nell'hub o in uno spoke specifico. Oltre ai ruoli di collaboratore per i carichi di lavoro, questo gruppo avrà anche bisogno del ruolo di lettore di rete.
• Il gruppo dedicato alle operazioni e alla manutenzione denominato CorpInfraOps o AppInfraOps ha la responsabilità di gestire i carichi di lavoro in produzione. Questo gruppo deve essere un collaboratore della sottoscrizione per i carichi di lavoro in qualsiasi sottoscrizione di produzione. Alcune organizzazioni potrebbero anche valutare se hanno bisogno di un gruppo del team di supporto per l'escalation con il ruolo di collaboratore alla sottoscrizione nell'ambiente di produzione e nella sottoscrizione dell'hub centrale. L'altro gruppo risolve potenziali problemi di configurazione nell'ambiente di produzione.

Il data center virtuale è progettato in modo che i gruppi del team IT centrale che gestiscono l'hub abbiano gruppi corrispondenti a livello di carico di lavoro. Oltre a gestire le risorse dell'hub, il team IT centrale può controllare l'accesso esterno e le autorizzazioni di primo livello per la sottoscrizione. I gruppi per i carichi di lavoro possono inoltre controllare le risorse e le autorizzazioni della rete virtuale indipendentemente dal team IT centrale.

Il data center virtuale viene partizionato per ospitare in modo sicuro più progetti tra line-of-business diverse. Tutti i progetti richiedono ambienti isolati diversi (sviluppo, test di accettazione utente, produzione). L'uso di sottoscrizioni di Azure separate per ognuno di questi ambienti offre un naturale isolamento.

Il diagramma precedente illustra la relazione tra i progetti, gli utenti, i gruppi e gli ambienti di un'organizzazione in cui vengono distribuiti i componenti di Azure.

Nell'ambito IT un ambiente (o livello) è in genere un sistema in cui vengono distribuite ed eseguite più applicazioni. Le aziende di grandi dimensioni usano un ambiente di sviluppo (dove vengono apportate e testate le modifiche) e un ambiente di produzione (usato dall'utente finale). Questi ambienti sono separati, spesso con diversi ambienti di staging tra di essi, per consentire la distribuzione in più fasi (implementazione), il test e il rollback in caso di problemi. Le architetture di distribuzione variano in modo significativo, ma in genere il processo di base, che prevede l'avvio con lo sviluppo (DEV) e la fine con la produzione (PROD), è ancora seguito.

Un'architettura comune per questi tipi di ambienti multilime include DevOps per sviluppo e test, UAT per la gestione temporanea e gli ambienti di produzione. Le organizzazioni possono usare uno o più tenant di Microsoft Entra per definire l'accesso e i diritti per questi ambienti. Il diagramma precedente mostra un caso in cui vengono usati due tenant Microsoft Entra diversi: uno per DevOps e UAT e l'altro esclusivamente per la produzione.

La presenza di diversi tenant di Microsoft Entra impone la separazione tra gli ambienti. Lo stesso gruppo di utenti, ad esempio il team IT centrale, deve eseguire l'autenticazione usando un URI diverso per accedere a un diverso tenant di Microsoft Entra. In questo modo il team può modificare i ruoli o le autorizzazioni degli ambienti DevOps o di produzione di un progetto. La presenza di autenticazioni utente diverse per accedere ad ambienti diversi riduce le possibili interruzioni e gli altri problemi causati dagli errori umani.

Tipo di componente: infrastruttura

Questo tipo di componente è quello in cui si trova la maggior parte dell'infrastruttura di supporto e a cui i team di IT centralizzato, sicurezza e conformità dedicano la maggior parte del tempo.

I componenti dell'infrastruttura forniscono un'interconnessione per i diversi componenti dell'implementazione di un data center virtuale e sono presenti sia nell'hub che negli spoke. La responsabilità della gestione e della manutenzione dei componenti dell'infrastruttura è in genere affidata al team IT centrale o al team della sicurezza.

Una delle attività principali del team dell'infrastruttura IT è di garantire la coerenza degli schemi degli indirizzi IP in tutta l'organizzazione. Lo spazio indirizzi IP privato assegnato all'implementazione di un data center virtuale deve essere coerente e non sovrapporsi agli indirizzi IP privati assegnati alle reti locali.

Anche se NAT nei router perimetrali locali o negli ambienti di Azure può evitare i conflitti di indirizzi IP, crea complicazioni nei componenti dell'infrastruttura. La semplicità di gestione è uno degli obiettivi chiave del data center virtuale, L'uso di NAT per gestire i problemi IP, mentre una soluzione valida non è una soluzione consigliata.

I componenti dell'infrastruttura contengono le funzionalità seguenti:

• Servizi di identità e directory: l'accesso a ogni tipo di risorsa in Azure è controllato da un'identità archiviata in un servizio directory. Il servizio directory archivia non solo l'elenco di utenti, ma anche i diritti di accesso alle risorse in una sottoscrizione di Azure specifica. Questi servizi possono esistere nel cloud oppure possono essere sincronizzati con l'identità locale archiviata in Active Directory.
• Reti virtuali: le reti virtuali sono uno dei componenti principali del data center virtuale e consentono di creare un limite di isolamento del traffico nella piattaforma Azure. Una rete virtuale è costituita da uno o più segmenti di rete virtuale, ognuno con un prefisso di rete IP specifico (una subnet, IPv4 o IPv4/IPv6 dual stack). La rete virtuale definisce un'area perimetrale interna in cui le macchine virtuali IaaS e i servizi PaaS possono stabilire comunicazioni private. Le macchine virtuali (e i servizi PaaS) in una rete virtuale non possono comunicare direttamente alle macchine virtuali (e ai servizi PaaS) in una rete virtuale diversa. Questo vale anche se entrambe le reti virtuali vengono create dallo stesso cliente, nella stessa sottoscrizione. L'isolamento è una proprietà essenziale che assicura che le macchine virtuali e le comunicazioni dei clienti rimangano private entro una rete virtuale. Dove si desidera la connettività tra reti, le funzionalità seguenti descrivono come può essere eseguita.
• Peering di rete virtuale: la funzionalità fondamentale usata per creare l'infrastruttura di un data center virtuale è il peering di rete virtuale, che connette due reti virtuali nella stessa area. Questa connessione avviene tramite la rete del data center di Azure o usando il backbone di Azure in tutto il mondo tra aree.
• Rete virtuale endpoint di servizio: gli endpoint di servizio estendono lo spazio indirizzi privato della rete virtuale per includere lo spazio PaaS. Gli endpoint estendono anche l'identità della rete virtuale ai servizi di Azure tramite una connessione diretta. Gli endpoint consentono di associare le risorse critiche dei servizi di Azure alle reti virtuali.
• collegamento privato: collegamento privato di Azure consente di accedere ai servizi PaaS di Azure, ad esempio Archiviazione di Azure, Azure Cosmos DB e database SQL di Azure ) e i servizi clienti/partner ospitati in Azure tramite un endpoint privato nella rete virtuale. Il traffico tra la rete virtuale e il servizio attraversa la rete backbone Microsoft, impedendone l'esposizione alla rete Internet pubblica. È anche possibile creare un servizio di collegamento privato personale nella rete virtuale e distribuirlo privatamente ai clienti. Collegamento privato di Azure offre un'esperienza di configurazione e utilizzo coerente per i servizi PaaS di Azure, i servizi di proprietà dei clienti e quelli condivisi dei partner.
• Route definite dall'utente: il traffico in una rete virtuale viene instradato per impostazione predefinita in base alla tabella di routing di sistema. Una route definita dall'utente è una tabella di routing personalizzata che gli amministratori di rete possono associare a una o più subnet per ignorare il comportamento della tabella di routing di sistema e definisce un percorso di comunicazione all'interno di una rete virtuale. La presenza di route definite dall'utente garantisce il traffico proveniente dal transito spoke attraverso macchine virtuali personalizzate specifiche o appliance virtuali di rete e servizi di bilanciamento del carico presenti sia nell'hub che negli spoke.
• Gruppi di sicurezza di rete: un gruppo di sicurezza di rete è un elenco di regole di sicurezza che fungono da filtro del traffico in base a origini IP, destinazioni IP, protocolli, porte di origine IP e porte di destinazione IP (dette anche tuple di livello 4). Il gruppo di sicurezza di rete può essere applicato a una subnet, a una scheda di interfaccia di rete virtuale associata una macchina virtuale di Azure o a entrambe. I gruppi di sicurezza di rete sono essenziali per implementare un controllo del flusso corretto nell'hub e negli spoke. Il livello di sicurezza offerto dal gruppo di sicurezza di rete dipende da quali porte si aprono e per quale scopo. I clienti possono applicare più filtri per macchina virtuale con firewall basati su host, ad esempio iptable o Windows Firewall.
• DNS: DNS fornisce la risoluzione dei nomi per le risorse in un data center virtuale. Azure offre servizi DNS per la risoluzione dei nomi sia pubblica che privata. Le zone private forniscono la risoluzione dei nomi all'interno di una rete virtuale e tra reti virtuali. Le zone private possono estendersi tra reti virtuali nella stessa area e tra aree e sottoscrizioni. Per la risoluzione pubblica, DNS di Azure offre un servizio di hosting per i domini DNS, che fornisce la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Ospitando i domini in Azure, è possibile gestire i record DNS usando le stesse credenziali, API, strumenti e fatturazione come per gli altri servizi Azure.
• Gruppo di gestione, sottoscrizione e gestione gruppo di risorse. Una sottoscrizione definisce un limite naturale per creare più gruppi di risorse in Azure. Questa separazione può essere per funzione, per separazione dei ruoli o per fatturazione. Le risorse in una sottoscrizione vengono assemblate in contenitori logici noti come gruppi di risorse. Il gruppo di risorse rappresenta un gruppo logico in cui sono organizzate le risorse di un data center virtuale. Se l'organizzazione ha molte sottoscrizioni, potrebbe essere necessario trovare una modalità di gestione efficiente dell'accesso, dei criteri e della conformità per tali sottoscrizioni. I gruppi di gestione di Azure offrono un livello di ambito superiore alle sottoscrizioni. Le sottoscrizioni sono organizzate in contenitori denominati gruppi di gestione a cui vengono applicate le condizioni di governance. Tutte le sottoscrizioni all'interno di un gruppo di gestione ereditano automaticamente le condizioni applicate al gruppo di gestione. Per visualizzare queste tre funzionalità in una vista gerarchia, vedere Organizzazione delle risorse in Cloud Adoption Framework.
• Controllo degli accessi in base al ruolo di Azure: il controllo degli accessi in base al ruolo di Azure può eseguire il mapping dei ruoli e dei diritti dell'organizzazione per accedere a risorse di Azure specifiche. In questo modo è possibile limitare gli utenti solo a un determinato subset di azioni. Se si sincronizza Microsoft Entra ID con un Active Directory locale, è possibile usare gli stessi gruppi di Active Directory in Azure usati in locale. Con il controllo degli accessi in base al ruolo di Azure è possibile concedere l'accesso assegnando i ruoli appropriati a utenti, gruppi e applicazioni nell'ambito di pertinenza. L'ambito di un'assegnazione di ruolo può essere una sottoscrizione di Azure, un gruppo di risorse o una singola risorsa. Il controllo degli accessi in base al ruolo di Azure consente l'ereditarietà delle autorizzazioni. Un ruolo assegnato a un ambito padre concede anche l'accesso agli elementi figlio contenuti al suo interno. Con il controllo degli accessi in base al ruolo di Azure è possibile separare i compiti e concedere solo la quantità di accesso agli utenti necessari per svolgere il proprio lavoro. Un dipendente ad esempio può gestire le macchine virtuali in una sottoscrizione, mentre un altro utente può gestire i database SQL Server della stessa sottoscrizione.

Tipo di componente: reti perimetrali

I componenti di una rete perimetrale connettono le reti locali o dei data center fisici, insieme a qualsiasi connettività Internet. Il perimetro richiede in genere un investimento di tempo significativo da parte dei team che si occupano della rete e della sicurezza.

I pacchetti in ingresso possono scorrere le appliance di sicurezza nell'hub prima di raggiungere i server e i servizi back-end negli spoke. Alcuni esempi sono il firewall, IDS e IPS. Prima di lasciare la rete, i pacchetti associati a Internet dai carichi di lavoro possono anche fluire attraverso le appliance di sicurezza nella rete perimetrale. Questo flusso consente l'applicazione di criteri, l'ispezione e il controllo.

I componenti della rete perimetrale includono:

• Reti virtuali, route definite dall'utente e gruppi di sicurezza di rete
• Appliance virtuali di rete
• Azure Load Balancer
• Gateway applicazione di Azure con Web application firewall (WAF)
• IP pubblici
• Frontdoor di Azure con Web application firewall (WAF)
• Firewall di Azure e Gestione firewall di Azure
• Protezione DDoS di Azure

In genere i team dedicati all'IT centrale e alla sicurezza sono responsabili della definizione dei requisiti e del funzionamento delle reti perimetrali.

Il diagramma precedente illustra l'imposizione di due perimetri con accesso a Internet e a una rete locale, entrambe residenti nell'hub della rete perimetrale. Nell'hub della rete perimetrale, la rete perimetrale verso Internet può aumentare le prestazioni per supportare molte line-of-business, usando più farm di Web application firewall (WAF) e/o di Firewall di Azure. L'hub consente anche di impostare la connettività locale tramite VPN o ExpressRoute in base alle esigenze.

Reti virtuali. L'hub è in genere basato su una rete virtuale con più subnet che ospitano diversi tipi di servizi. Questi servizi filtrano e controllano il traffico da o verso Internet tramite istanze del gateway di Firewall di Azure, appliance virtuali di rete, WAF e app Azure lication.

Route definite dall'utente. Usando route definite dall'utente, i clienti possono distribuire firewall, sistemi di rilevamento intrusioni o sistemi di prevenzione intrusioni e altre appliance virtuali. nonché instradare il traffico di rete attraverso queste appliance di sicurezza per l'applicazione dei criteri relativi ai limiti di sicurezza, il controllo e l'ispezione. Le route definite dall'utente possono essere create sia nell'hub sia negli spoke per garantire che il traffico transiti attraverso macchine virtuali personalizzate, appliance virtuali di rete e servizi di bilanciamento del carico specifici usati dall'implementazione di un data center virtuale. Per garantire che il traffico generato dalle macchine virtuali negli spoke transiti verso le appliance virtuali corrette, è necessario impostare una route definita dall'utente nelle subnet dello spoke. Questa operazione viene eseguita impostando l'indirizzo IP front-end del servizio di bilanciamento del carico interno come hop successivo. Il servizio di bilanciamento del carico interno distribuisce il traffico interno alle appliance virtuali (pool back-end di bilanciamento del carico).

Firewall di Azure è un servizio di sicurezza della rete gestito che protegge le risorse di Rete virtuale di Microsoft Azure. Si tratta di un firewall gestito, con stato, con disponibilità elevata e scalabilità cloud. È possibile creare, applicare e registrare criteri di connettività di applicazione e di rete in modo centralizzato tra le sottoscrizioni e le reti virtuali. Firewall di Azure usa un indirizzo IP pubblico statico per le risorse della rete virtuale consentendo ai firewall esterni di identificare il traffico proveniente dalla rete virtuale. Il servizio è completamente integrato con Monitoraggio di Azure per la registrazione e l'analisi.

Se si usa la topologia di tipo rete WAN virtuale di Azure, Gestione firewall di Azure è un servizio di gestione della sicurezza che fornisce funzionalità di gestione dei criteri di sicurezza centrale e delle route per i perimetri di sicurezza basati sul cloud. Funziona con l'hub rete WAN virtuale di Azure, una risorsa gestita da Microsoft che consente di creare facilmente architetture hub-spoke. Quando i criteri di sicurezza e routing sono associati a un hub, viene definito hub virtuale protetto.

Appliance virtuali di rete. Nell'hub la rete perimetrale con accesso a Internet in genere viene gestita tramite un'istanza di Firewall di Azure oppure una farm di firewall o web application firewall (WAF).

Line-of-business diverse usano in genere molte applicazioni Web, che tendono a essere soggette a svariate vulnerabilità e potenziali exploit. I web application firewall sono un tipo speciale di prodotto usato per rilevare attacchi contro le applicazioni Web e HTTP/HTTPS in modo più efficace rispetto a un firewall generico. Rispetto alla tradizionale tecnologia firewall, i Web application firewall hanno un set di funzionalità specifiche per proteggere i server Web interni dalle minacce.

Un firewall di Firewall di Azure o appliance virtuale di rete usa un piano di amministrazione comune, con un set di regole di sicurezza per proteggere i carichi di lavoro ospitati negli spoke e controllare l'accesso alle reti locali. Firewall di Azure ha incorporata la scalabilità, mentre i firewall delle appliance virtuali di rete possono essere ridimensionati manualmente dietro un servizio di bilanciamento del carico. In genere, una farm di firewall ha un software meno specializzato rispetto a un WAF, ma ha un ambito dell'applicazione più ampio per filtrare ed esaminare ogni tipo di traffico in uscita o in ingresso. Se si usa un approccio basato sulle appliance virtuali di rete, è possibile distribuire queste appliance da Azure Marketplace.

È consigliabile usare un set di istanze di Firewall di Azure (o di appliance virtuali di rete) per il traffico che ha origine in Internet e un altro per il traffico che ha origine in locale. L'uso di un solo set di firewall per entrambi i tipi di traffico è un rischio per la sicurezza, perché non viene creato un perimetro di sicurezza tra i due set di traffico. L'uso di livelli firewall separati riduce la complessità del controllo delle regole di sicurezza, che rende chiare le regole corrispondenti alla richiesta di rete in ingresso.

Azure Load Balancer offre un servizio a disponibilità elevata di livello 4 (TCP/UDP) in grado di distribuire il traffico in ingresso tra le istanze del servizio definite in un set con carico bilanciato. Il traffico inviato al servizio di bilanciamento del carico dagli endpoint front-end (endpoint IP pubblici o endpoint IP privati) può essere ridistribuito con o senza conversione degli indirizzi in un set di pool di indirizzi IP back-end (ad esempio appliance virtuali di rete o macchine virtuali).

Azure Load Balancer può eseguire il probe dell'integrità di varie istanze del server. Quando un'istanza non riesce a rispondere a un probe, il servizio di bilanciamento del carico smette di inviare il traffico all'istanza non integra. In un data center virtuale viene distribuito un servizio di bilanciamento del carico esterno per l'hub e gli spoke. Nell'hub il servizio di bilanciamento del carico viene usato per instradare in modo efficiente il traffico tra le istanze del firewall. Negli spoke, i servizi di bilanciamento del carico vengono usati per gestire il traffico dell'applicazione.

Frontdoor di Azure è la piattaforma di accelerazione delle applicazioni Web a disponibilità elevata e scalabile di Microsoft, il servizio di bilanciamento del carico HTTP globale, la protezione delle applicazioni e la rete per la distribuzione di contenuti. Il servizio Frontdoor di Azure viene eseguito in oltre 100 posizioni sul perimetro della rete globale Microsoft e consente di compilare e gestire l'applicazione Web dinamica e il contenuto statico, nonché di aumentarne il numero di istanze. Il servizio Frontdoor di Azure assicura all'applicazione prestazioni per l'utente finale di livello superiore, automazione della manutenzione regionale unificata, automazione della continuità aziendale e ripristino di emergenza, informazioni client/utente unificate, memorizzazione nella cache e informazioni dettagliate sul servizio.

La piattaforma offre:

• Prestazioni, affidabilità e contratti di servizio di supporto
• Certificazioni per la conformità
• Procedure di sicurezza controllabili sviluppate, gestite e supportate in modo nativo da Azure.

Frontdoor di Azure fornisce anche un Web application firewall (WAF), che protegge le applicazioni Web dalle vulnerabilità e dai rischi più frequenti.

Il gateway applicazione di Azure è un'appliance virtuale dedicata che offre un controller gestito per la distribuzione delle applicazioni e varie funzionalità di bilanciamento del carico di livello 7 per l'applicazione. Consente di ottimizzare le prestazioni delle Web farm eseguendo l'offload della terminazione SSL con utilizzo elevato di CPU al gateway applicazione. Offre anche altre funzionalità di routing di livello 7, tra cui la distribuzione round robin del traffico in ingresso, l'affinità di sessione basata su cookie, il routing basato su percorso URL e la possibilità di ospitare più siti Web dietro un unico gateway applicazione. Nello SKU WAF del gateway applicazione è incluso anche un Web application firewall (WAF). Questo SKU offre alle applicazioni Web la protezione da exploit e vulnerabilità Web comuni. Il gateway applicazione può essere configurato come gateway con connessione Internet, gateway solo interno o una combinazione di entrambi.

IP pubblici. Alcune funzionalità di Azure consentono di associare gli endpoint di servizio a un indirizzo IP pubblico in modo che la risorsa sia accessibile da Internet. Questo endpoint usa il processo NAT (Network Address Translation) per instradare il traffico fino all'indirizzo e alla porta interni nella rete virtuale in Azure. È questa la modalità primaria che consente al traffico esterno di passare attraverso la rete virtuale. Gli indirizzi IP pubblici possono essere configurati per determinare il traffico autorizzato a passare e come/dove viene convertito nella rete virtuale.

Protezione DDoS di Azure offre più funzionalità di mitigazione rispetto al livello di servizio di base ottimizzato in modo specifico per le risorse di rete virtuale di Azure. Protezione DDoS è semplice da abilitare e non richiede modifiche all'applicazione. I criteri di protezione sono ottimizzati tramite il monitoraggio del traffico dedicato e algoritmi di apprendimento automatico. I criteri vengono applicati agli indirizzi IP pubblici associati alle risorse distribuite nelle reti virtuali, Ad esempio, il servizio di bilanciamento del carico di Azure, il gateway applicazione di Azure e le istanze di Azure Service Fabric. I log generati dal sistema quasi in tempo reale sono disponibili tramite le visualizzazioni di Monitoraggio di Azure durante un attacco e per la cronologia. La protezione del livello applicazione può essere aggiunta tramite web application firewall del gateway applicazione di Azure. La protezione viene fornita per gli indirizzi IP pubblici di Azure IPv4 e IPv6.

La topologia hub-spoke usa il peering di reti virtuali e le route definite dall'utente per instradare il traffico correttamente.

Nel diagramma, la route definita dall'utente assicura che il traffico transiti dallo spoke al firewall prima di passare all'ambiente locale tramite il gateway ExpressRoute (se i criteri del firewall lo consentono).

Tipo di componente: monitoraggio

I componenti di monitoraggio forniscono visibilità e avvisi da tutti gli altri tipi di componenti. Tutti i team possono avere accesso al monitoraggio dei componenti e dei servizi a cui hanno accesso. Se è presente un help desk centralizzato o team operativi, questi dovranno avere accesso integrato ai dati forniti da tali componenti.

Azure offre tipi diversi di servizi di registrazione e monitoraggio per tenere traccia del comportamento delle risorse ospitate di Azure. La governance e il controllo dei carichi di lavoro in Azure si basano non solo sulla raccolta dei dati di log, ma anche sulla possibilità di attivare azioni in base a eventi segnalati specifici.

Monitoraggio di Azure. Azure include più servizi che singolarmente eseguono un'attività o un ruolo specifico nell'area di monitoraggio. Insieme, questi servizi offrono una soluzione completa per la raccolta, l'analisi e l'utilizzo dei log generati dal sistema delle applicazioni e delle risorse di Azure che li supportano. Possono anche lavorare per monitorare le risorse locali critiche per fornire un ambiente di monitoraggio ibrido. Conoscere gli strumenti e i dati disponibili è il primo passo per sviluppare una strategia di monitoraggio completa per le proprie applicazioni.

Esistono due tipi fondamentali di log in Monitoraggio di Azure:

• Le metriche sono valori numerici che descrivono alcuni aspetti di un sistema in un particolare momento. Sono leggeri e in grado di supportare scenari quasi in tempo reale. Per molte risorse di Azure, i dati raccolti da Monitoraggio di Azure vengono visualizzati direttamente nella relativa pagina di panoramica nel portale di Azure. Osservando ad esempio una qualsiasi macchina virtuale si vedono diversi grafici che mostrano le metriche delle prestazioni. Selezionare uno dei grafici per aprire i dati in Esplora metriche nel portale di Azure, che consente di rappresentare in un grafico i valori di più metriche nel tempo. È possibile visualizzare i grafici in modo interattivo o aggiungerli a un dashboard per visualizzarli con altre visualizzazioni.

• I log contengono diversi tipi di dati organizzati in record con diversi set di proprietà per ogni tipo. Gli eventi e le tracce vengono archiviati come log insieme ai dati sulle prestazioni. Tutti questi elementi possono essere combinati per l'analisi. I dati di log raccolti da Monitoraggio di Azure possono essere analizzati con query per recuperare, consolidare e analizzare rapidamente i dati raccolti. I log vengono archiviati ed sottoposti a query da Log Analytics. È possibile creare e testare query usando Log Analytics nella portale di Azure e analizzare direttamente i dati usando questi strumenti o salvare query da usare con visualizzazioni o regole di avviso.

Monitoraggio di Azure può raccogliere dati da varie origini. Il monitoraggio dei dati per le applicazioni avviene mediante livelli che vanno dall'applicazione, al sistema operativo e ai servizi su cui si basa, fino alla piattaforma di Azure stessa. Monitoraggio di Azure raccoglie i dati da ciascuno dei livelli seguenti:

• Dati di monitoraggio dell'applicazione: dati relativi alle prestazioni e alle funzionalità del codice scritto indipendentemente dalla piattaforma.
• Dati di monitoraggio del sistema operativo guest: dati relativi al sistema operativo in cui viene eseguita l'applicazione. Il sistema operativo potrebbe essere eseguito in Azure, un altro cloud o in locale.
• Dati di monitoraggio delle risorse di Azure: dati relativi al funzionamento di una risorsa di Azure.
• Dati di monitoraggio delle sottoscrizioni di Azure: dati relativi al funzionamento e alla gestione di una sottoscrizione di Azure e all'integrità e al funzionamento di Azure stesso.
• Dati di monitoraggio del tenant di Azure: Dati sul funzionamento dei servizi di Azure a livello di tenant, come Microsoft Entra ID.
• Origini personalizzate: possono essere inclusi anche i log inviati da origini locali. Alcuni esempi sono gli eventi del server locale o l'output syslog del dispositivo di rete.

I dati di monitoraggio sono utili solo se possono aumentare la visibilità del funzionamento dell'ambiente di elaborazione. Monitoraggio di Azure include diverse funzionalità e strumenti che forniscono informazioni dettagliate preziose sulle applicazioni e altre risorse da cui dipendono. Le soluzioni e le funzionalità di monitoraggio, ad esempio Application Insights e Monitoraggio di Azure per i contenitori, forniscono informazioni approfondite su diversi aspetti dell'applicazione e su servizi di Azure specifici.

Le soluzioni di monitoraggio in Monitoraggio di Azure sono set di logica compressi che forniscono informazioni su una determinata applicazione o servizio. Includono logica per la raccolta di dati di monitoraggio per l'applicazione o il servizio, query per analizzare i dati, e visualizzazioni per esaminarli. Sono disponibili soluzioni di monitoraggio di Microsoft e di alcuni partner, che permettono il monitoraggio di vari servizi di Azure e altre applicazioni.

Con una raccolta di dati avanzati, è importante intervenire in modo proattivo sugli eventi che si verificano nell'ambiente, soprattutto quando le query manuali da sole non sono sufficienti. Gli avvisi di Monitoraggio di Azure inviano notifiche proattive sulle condizioni critiche e tentano di eseguire azioni correttive. Le regole di avviso basate sulle metriche forniscono avvisi quasi in tempo reale in base ai valori numerici. Le regole di avviso basate sui log consentono una logica complessa tra i dati di più origini. Le regole di avviso in Monitoraggio di Azure utilizzano i gruppi di azioni che contengono set univoci di destinatari e azioni che possono essere condivise tra più regole. In base ai requisiti, i gruppi di azioni possono usare webhook che causano l'avvio di azioni esterne o l'integrazione con gli strumenti di Gestione dei servizi IT.

Monitoraggio di Azure consente anche di creare dashboard personalizzati. I dashboard di Azure consentono di combinare tipi diversi di dati, tra cui metriche e log, in un unico riquadro del portale di Azure. È possibile condividere il dashboard con altri utenti di Azure. È possibile aggiungere gli elementi di Monitoraggio di Azure a un dashboard di Azure oltre all'output di un grafico di metrica o query di log. Ad esempio, è possibile creare un dashboard che combina riquadri che mostrano un grafico di metriche, una tabella di log attività, un grafico di utilizzo di Application Insights e l'output di una query di log.

Infine, i dati di Monitoraggio di Azure sono un'origine nativa per Power BI. Power BI è un servizio di analisi aziendale che fornisce visualizzazioni interattive per un'ampia varietà di origini dati. È anche un mezzo efficace per rendere i dati disponibili ad altri utenti all'interno e all'esterno dell'organizzazione. È possibile configurare Power BI per importare automaticamente i dati di log da Monitoraggio di Azure per sfruttare queste altre visualizzazioni.

Azure Network Watcher fornisce gli strumenti per il monitoraggio, la diagnostica, la visualizzazione delle metriche e l'abilitazione o la disabilitazione dei log per le risorse in una rete virtuale in Azure. È un servizio con più sfaccettature che consente le funzionalità seguenti e altro ancora:

• Monitorare la comunicazione tra una macchina virtuale e un endpoint
• Visualizzare le risorse in una rete virtuale e le relative relazioni
• Diagnosticare i problemi di filtro del traffico di rete da o verso una macchina virtuale
• Diagnosticare i problemi di routing di rete da una macchina virtuale
• Diagnosticare i problemi delle connessioni in uscita da una macchina virtuale
• Acquisire i pacchetti da e verso una macchina virtuale
• Diagnosticare i problemi relativi a un gateway di rete virtuale e alle connessioni.
• Determinare le latenze relative tra aree di Azure e provider di servizi Internet
• Visualizzare le regole di sicurezza per un'interfaccia di rete
• Visualizzare le metriche di rete
• Analizzare il traffico da o verso un gruppo di sicurezza di rete
• Visualizzare i log di diagnostica per le risorse di rete

Tipo di componente: carichi di lavoro

Nei componenti di tipo carico di lavoro si trovano le applicazioni e i servizi effettivi. Sono i componenti a cui i team di sviluppo delle applicazioni dedicano più tempo.

Le possibilità dei carichi di lavoro sono infinite. I seguenti sono solo alcuni dei possibili tipi di carichi di lavoro:

Applicazioni interne: le applicazioni line-of-business sono fondamentali per le operazioni aziendali. Queste applicazioni hanno in comune alcune caratteristiche. Sono:

• Interattive: vengono immessi dati e vengono restituiti risultati o report.
• Basate sui dati: sono a elevato utilizzo dei dati con accesso frequente ai database o ad altre risorse di archiviazione.
• Integrate: possono essere integrate ad altri sistemi interni o esterni all'organizzazione.

Siti Web per i clienti (con connessione Internet o con connessione interna): la maggior parte delle applicazioni Internet sono siti Web. Azure può eseguire un sito Web tramite una macchina virtuale IaaS o un sito di App Web di Azure (PaaS). Le app Web di Azure si integrano con le reti virtuali per distribuire app Web in un'area di rete spoke. I siti Web per utenti interni non hanno bisogno di esporre un endpoint Internet pubblico, perché le risorse sono accessibili tramite indirizzi instradabili non Internet privati dalla rete virtuale privata.

Analisi dei Big Data: quando i dati devono aumentare fino a volumi più grandi, i database relazionali potrebbero non funzionare correttamente con il carico estremo o la natura non strutturata dei dati. Azure HDInsight è un servizio di analisi open source, ad ampio spettro e gestito nel cloud, rivolto alle aziende. È possibile usare framework open source come Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm e R. HDInsight. Ciò supporta la distribuzione in una rete virtuale basata sulla posizione, che può essere distribuita in un cluster in uno spoke del data center virtuale.

Eventi e messaggistica: Hub eventi di Azure è una piattaforma di streaming di Big Data e un servizio di inserimento di eventi. È in grado di ricevere ed elaborare milioni di eventi al secondo. Offre bassa latenza e conservazione del tempo configurabile, per cui consente di inserire grandi quantità di dati in Azure e di leggere i dati da più applicazioni. Un singolo flusso può supportare sia pipeline in tempo reale sia pipeline basate su batch.

Un servizio di messaggistica cloud altamente affidabile tra applicazioni e servizi può essere implementato tramite il bus di servizio di Azure Questo servizio offre messaggistica negoziata asincrona tra client e server, funzionalità di messaggistica FIFO (First-In-First-Out) strutturate e funzionalità di pubblicazione e sottoscrizione.

Questi esempi illustrano a malapena la superficie dei tipi di carichi di lavoro che è possibile creare in Azure. È possibile creare tutti gli elementi da un'app Web e SQL di base alla versione più recente di IoT, Big Data, Machine Learning, intelligenza artificiale e molto altro ancora.

Disponibilità elevata: più data center virtuali

In questo articolo si è finora parlato della progettazione di un singolo data center virtuale e sono stati descritti i componenti e le architetture di base che contribuiscono alla resilienza. Funzionalità di Azure come Azure Load Balancer, appliance virtuali di rete, zone di disponibilità, set di disponibilità, set di scalabilità e altre funzionalità che consentono di includere livelli di contratto di servizio solidi nei servizi di produzione.

Tuttavia, poiché un data center virtuale viene in genere implementato all'interno di una singola area, potrebbe essere vulnerabile a guasti che interessano l'intera area. I clienti che hanno bisogno di disponibilità elevata devono proteggere i servizi distribuendo lo stesso progetto in due o più implementazioni di data center virtuale, distribuite in aree diverse.

Oltre alle questioni del contratto di servizio, esistono diversi scenari comuni che traggono vantaggio dall'esecuzione di più data center virtuali:

• Presenza a livello di area o globale degli utenti finali o dei partner.
• Requisiti per il ripristino di emergenza.
• Meccanismo per deviare il traffico tra i data center per il carico o le prestazioni.

Presenza a livello di area/globale

I data center di Azure sono presenti in molte aree in tutto il mondo. Quando si selezionano più data center di Azure, occorre considerare due fattori correlati: le distanze geografiche e la latenza. Per ottimizzare l'esperienza utente, valutare la distanza tra ogni data center virtuale e la distanza tra ogni data center virtuale e gli utenti finali.

Un'area di Azure che ospita il data center virtuale della propria organizzazione deve essere conforme ai requisiti normativi di qualsiasi giurisdizione legale in cui si opera.

Ripristino di emergenza

La progettazione di un piano di ripristino di emergenza dipende dai tipi di carichi di lavoro e dalla capacità di sincronizzare lo stato di tali carichi di lavoro tra implementazioni di data center virtuale diverse. Idealmente, la maggior parte dei clienti desidera un meccanismo di failover rapido e questo requisito potrebbe richiedere la sincronizzazione dei dati dell'applicazione tra distribuzioni in esecuzione in più implementazioni di data center virtuale. Tuttavia, quando si progettano piani di ripristino di emergenza, è importante tenere presente che la maggior parte delle applicazioni è sensibile alla latenza che può essere causata da questa sincronizzazione dei dati.

Per il monitoraggio della sincronizzazione e dell'heartbeat in implementazioni di data center virtuale diverse, è necessario che i data center comunichino tramite la rete. Più implementazioni di data center virtuale in aree diverse possono essere connesse tramite:

• Comunicazione da hub a hub integrata in hub di rete WAN virtuale di Azure tra aree nella stessa rete WAN virtuale
• Peering di reti virtuali per connettere hub in aree diverse
• Peering privato ExpressRoute quando gli hub in ogni implementazione di data center virtuale sono connessi allo stesso circuito di ExpressRoute
• Più circuiti di ExpressRoute connessi tramite il backbone aziendale e più implementazioni di data center virtuali connesse ai circuiti di ExpressRoute
• Connessioni VPN da sito a sito tra la zona hub delle implementazioni di data center virtuali in ogni area di Azure.

In genere, le connessioni con gli hub di rete WAN virtuale, il peering di reti virtuali o ExpressRoute sono preferite per la connettività di rete a causa della maggiore larghezza di banda e di una latenza più uniforme durante il transito attraverso il backbone Microsoft.

È consigliabile eseguire test di idoneità della rete per verificare la latenza e la larghezza di banda di queste connessioni e, in base ai risultati, decidere se sia appropriata la replica dei dati sincrona o asincrona. È anche importante valutare attentamente questi risultati in relazione all'obiettivo del tempo di ripristino (RTO, Recovery Time Objective) ottimale.

Ripristino di emergenza: deviare il traffico da un'area a un'altra

Sia Gestione traffico di Azure che frontdoor di Azure controllano periodicamente l'integrità del servizio degli endpoint di ascolto in implementazioni di data center virtuale diverse. Se questi endpoint hanno esito negativo, Gestione traffico di Azure e la route frontdoor di Azure vengono indirizzati automaticamente al data center virtuale più vicino più vicino. Gestione traffico usa le misurazioni utente in tempo reale e DNS per instradare gli utenti al data center virtuale più vicino (o a quello successivo più vicino in caso di errore). Frontdoor di Azure è un proxy inverso presente in oltre 100 siti perimetrali del backbone Microsoft, che usa qualsiasi trasmissione per instradare gli utenti all'endpoint di ascolto più vicino.

Riepilogo

L'approccio del data center virtuale alla migrazione consiste nel creare un'architettura scalabile che ottimizza l'uso delle risorse di Azure, riduce i costi e semplifica la governance del sistema. Il data center virtuale si basa generalmente sulle topologie di rete hub e spoke (usando gli hub di peering di reti virtuali o gli hub di rete WAN virtuale). I servizi condivisi comuni forniti nell'hub e le applicazioni e i carichi di lavoro specifici vengono distribuiti negli spoke. Il data center virtuale corrisponde anche alla struttura dei ruoli aziendali, in cui reparti diversi, ad esempio IT centrale, DevOps e operazioni e manutenzione, interagiscono insieme durante l'esecuzione di ruoli specifici. Il data center virtuale supporta la migrazione in Azure dei carichi di lavoro locali esistenti, ma offre anche molti vantaggi per le distribuzioni native del cloud.

Riferimenti

Altre informazioni sulle funzionalità di Azure illustrate in questo documento.

Funzionalità di rete
Reti virtuali di Azure
Gruppi di sicurezza di rete
Endpoint di servizio
Collegamento privato
Route definite dall'utente
Appliance virtuali di rete
Indirizzi IP pubblici
DNS Azure

Bilanciamento del carico
Frontdoor di Azure
Azure Load Balancer (livello 4)
Gateway applicazione (livello 7)
Gestione traffico di Azure

Connettività
Peering di rete virtuale
Rete privata virtuale
Rete WAN virtuale
ExpressRoute
ExpressRoute Direct

Identità
Microsoft Entra ID
Autenticazione a più fattori Microsoft Entra
Controllo degli accessi in base al ruolo di Azure
Ruoli predefiniti di Azure

Monitoraggio
Network Watcher
Monitoraggio di Azure
Log Analytics

Procedure consigliate
Gruppo di gestione
Gestione sottoscrizioni
Gestione di gruppi di risorse
Limiti delle sottoscrizioni di Azure

Sicurezza
Firewall di Azure
Gestione firewall
WAF del gateway applicazione
WAF di Frontdoor
Azure DDoS

Altri servizi di Azure
Archiviazione di Azure
Azure SQL
App Web di Azure
Azure Cosmos DB
HDInsight
Hub eventi
Bus di servizio
Azure IoT
Azure Machine Learning

Passaggi successivi

• Altre informazioni sul peering di reti virtuali, la tecnologia di base delle topologie hub e spoke.
• Implementare l'ID Microsoft Entra per usare il controllo degli accessi in base al ruolo di Azure.
• Sviluppare un modello di gestione delle risorse e delle sottoscrizioni usando il controllo degli accessi in base al ruolo di Azure che sia adatto alla struttura, ai requisiti e ai criteri dell'organizzazione. L'attività più importante è la pianificazione. Analizzare in che modo le riorganizzazioni, le fusioni, le nuove linee di prodotti e altre considerazioni influiranno sui modelli iniziali per garantire la scalabilità necessaria a soddisfare le esigenze e la crescita future.