Distribuire un'infrastruttura di rete tenant altamente scalabile per provider di hosting

Pubblicato: giugno 2013

Aggiornamento: agosto 2014

Si applica a: System Center 2012 R2, Windows Azure Pack, Windows Server 2012 R2

Finalità della guida. Questa guida consente ai provider di hosting di medie dimensioni di comprendere le fasi di progettazione e implementazione della soluzione consigliate per distribuire un'infrastruttura di rete scalabile a supporto di un'infrastruttura distribuita come servizio (IaaS). Il provisioning di reti tenant può essere costoso da eseguire e complesso da gestire.

Questa guida fornisce informazioni utili per distribuire una soluzione di infrastruttura di rete virtuale di tipo IaaS rigorosa e testata che sia economica, flessibile, scalabile e facile da gestire. Inoltre, fornisce ai tenant un modo più semplice e conveniente per connettere i loro data center ai propri e distribuire le loro soluzioni di cloud ibrido.

Suggerimento

Se non si ha familiarità con i concetti di virtualizzazione di rete, vedere Panoramica di Virtualizzazione rete Hyper-V e Dettagli tecnici di Virtualizzazione rete Hyper-V.

Se non si ha familiarità con i concetti di virtualizzazione di rete in System Center 2012 R2 Virtual Machine Manager (VMM), è consigliabile configurare ed eseguire un laboratorio di testing servendosi della guida seguente prima di procedere con la pianificazione e progettazione: Guida dell'ambiente di prova: Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

La guida dell'ambiente di prova illustra i concetti di Virtual Machine Manager e agevolerà la pianificazione, progettazione e distribuzione della soluzione.

Esaminare anche i concetti di VMM presentati nella pagina di Microsoft System Center dedicata alla creazione di una soluzione di rete virtualizzata per altre informazioni sulle considerazioni di pianificazione e progettazione in una soluzione basata su VMM.

Contenuto della guida alla soluzione:

  • Scenario, presentazione del problema e obiettivi

  • Qual è il progetto consigliato per la soluzione?

  • Perché viene consigliato questo progetto?

  • Quali sono i passaggi necessari per implementare la soluzione?

  • Configurazioni facoltative

Il diagramma seguente illustra il problema affrontato in questa guida. È necessario eseguire il provisioning di un unico gateway per ogni tenant, che richiede notevoli interventi di configurazione e le VLAN offrono scalabilità solo fino a circa 1.000 tenant.

Connessione dei tenant a un provider di hosting

Progettazione non scalabile e difficile da gestire

Scenario, presentazione del problema e obiettivi

Questa sezione descrive lo scenario, il problema e gli obiettivi per un'organizzazione di esempio.

Scenario

Un provider di hosting di medie dimensioni mette a disposizione dei propri clienti la tecnologia IaaS. Ultimamente ha iniziato a offrire un servizio di rete virtuale su richiesta dei clienti.

L'attività di promozione del reparto marketing interno del provider di hosting è stata talmente proficua che la richiesta del servizio di rete virtuale da parte dei clienti è in rapido aumento.

Presentazione del problema

L'attuale servizio di rete virtuale del provider di hosting non offre scalabilità sufficiente ed è inefficiente e costoso da gestire. Ad esempio:

  • La struttura attuale richiede due gateway per ogni tenant (per la ridondanza) e ogni coppia di gateway richiede un indirizzo IP pubblico. Con l'aumento del numero di tenant, il numero di gateway necessari per supportarli è aumentato progressivamente. Questo è difficile da gestire per il provider di hosting. L'aggiunta di due gateway per tenant non è una soluzione economicamente vantaggiosa.

  • Se un tenant deve connettersi a più siti, anche ogni sito tenant richiederà un gateway separato.

  • Al momento non viene usato un protocollo di routing standard nel settore e gli amministratori devono gestire manualmente le route di rete, un sistema inefficiente e soggetto a errori di configurazione.

  • La struttura corrente usa le VLAN per l'isolamento della rete. I commutatori di rete supportano solo 1.000 VLAN, limitando di fatto la scalabilità. Per spostare una macchina virtuale tenant in un altro host situato fisicamente in una posizione diversa, spesso è necessario cambiare l'indirizzo IP e riconfigurare il commutatore. Questo problema rende molto difficile spostare macchine virtuali tenant e offre scarsa flessibilità nell'infrastruttura del data center.

Obiettivi dell'organizzazione

Il provider di hosting ha bisogno di disponibilità elevata, convenienza economica e gestione semplificata per fornire servizi di qualità superiore e competitivi a livello di costi per soddisfare la maggiore richiesta dei clienti. Vuole implementare una nuova soluzione con gli attributi seguenti:

  • Possibilità di distribuire gateway in grado di connettersi a più reti tenant e più siti per tenant contemporaneamente.

  • Possibilità di usare un protocollo di routing standard nel settore e abilitare un protocollo di isolamento di rete virtuale scalabile che non si limitato dalle tecnologie VLAN attuali.

  • Possibilità di fornire reti tenant isolate usando una tecnologia scalabile in funzione dell'aumento del numero di tenant e dei relativi carichi di lavoro.

  • Una struttura di rete virtuale gestibile dotata di un'interfaccia di gestione facile da usare che consente la gestione centralizzata di reti virtuali, spazi degli indirizzi IP e gateway. Questo consente di gestire più tenant alla volta in modo più semplice ed efficiente.

  • Possibilità di fornire un portale self-service comune per i tenant, che consente di posizionare le risorse di elaborazione nel punto in cui soddisfano meglio le esigenze aziendali.

  • Possibilità di fornire semplici istruzioni per i clienti in modo che possano connettere facilmente la loro rete locale al provider di hosting tramite una rete privata virtuale (VPN) sicura da sito a sito. Queste istruzioni includeranno indicazioni per configurazione del router, con informazioni dettagliate sui protocolli richiesti, sulle impostazioni e sugli indirizzi degli endpoint.

Qual è il progetto consigliato per la soluzione?

Il diagramma seguente mostra il progetto consigliato per questa soluzione, che connette la rete di ogni tenant al gateway multi-tenant del provider di hosting con un singolo tunnel VPN da sito a sito. In questo modo il provider di hosting può supportare circa 100 tenant in un cluster a gateway singolo, con conseguente riduzione della complessità di gestione e del costo. Ogni tenant deve configurare un proprio gateway per la connessione al gateway del provider di hosting. Il gateway instrada quindi i dati di rete di ogni tenant e usa il protocollo NVGRE (Network Virtualization using Generic Routing Encapsulation) per la virtualizzazione di rete.

Progetto di soluzione di rete multi-tenant

Architettura soluzione di rete multi-tenant cloud ibrido

Nella tabella seguente sono elencati gli elementi che fanno parte della soluzione e viene descritto il motivo della scelta.

Elemento del progetto di soluzione Perché è incluso nella soluzione?

Windows Server 2012 R2

Rappresenta il sistema operativo di base della soluzione. È consigliabile selezionare l'opzione di installazione Server Core per limitare l'esposizione agli attacchi per la sicurezza e ridurre la frequenza di aggiornamento software.

Windows Server 2012 R2 Gateway

È integrato con Virtual Machine Manager per supportare connessioni VPN multi-tenant simultanee da sito a sito tramite NVGRE. Per una panoramica di questa tecnologia, vedere Windows Server Gateway.

Microsoft SQL Server 2012

Fornisce servizi di database per Virtual Machine Manager e Windows Azure Pack.

System Center 2012 R2 Virtual Machine Manager

Gestisce le reti virtuali (usando NVGRE per l'isolamento di rete), la gestione dell'infrastruttura e gli indirizzi IP. Per una panoramica del prodotto, vedere Panoramica sulla configurazione di rete in VMM.

Clustering di failover di Windows Server

Tutti gli host fisici sono configurati come cluster di failover per la disponibilità elevata, così come molti guest di macchina virtuale che ospitano i carichi di lavoro di gestione e dell'infrastruttura.

Il gateway VPN da sito a sito può essere distribuito in configurazione 1+1 per la disponibilità elevata. Per altre informazioni su Clustering di failover, vedere Panoramica di Clustering di failover.

File server a scalabilità orizzontale

Fornisce le condivisioni file per i dati delle applicazioni server con affidabilità, disponibilità, gestibilità e prestazioni elevate. Questa soluzione usa due file server a scalabilità orizzontale: uno per il dominio che ospita i server di gestione e uno per il dominio che ospita i server gateway. Questi due domini non hanno una relazione di trust. Il file server a scalabilità orizzontale per il dominio gateway è implementato come cluster guest di macchine virtuali. Il file server a scalabilità orizzontale per il dominio gateway è necessario perché non è possibile accedere a un file server a scalabilità orizzontale da un dominio non attendibile.

Per una panoramica di questa funzionalità, vedere Panoramica di file server a scalabilità orizzontale per dati di applicazioni.

Per informazioni più dettagliate sulle soluzioni di archiviazione possibili, vedere Offrire archiviazione conveniente per carichi di lavoro Hyper-V mediante Windows Server.

VPN da sito a sito

Consente di connettere un sito tenant al sito del provider di hosting. Questo metodo di connessione è conveniente e il software VPN è incluso con Accesso remoto in Windows Server 2012 R2, che riunisce Servizio Routing e Accesso remoto (RRAS) e DirectAccess. Inoltre, sono disponibili software e/o hardware VPN di diversi fornitori.

Windows Azure Pack

Fornisce un portale self-service per consentire ai tenant di gestire le proprie reti virtuali. Windows Azure Pack offre un'esperienza self-service comune, un insieme di API di gestione comuni e un'esperienza di hosting identica per il sito Web e la macchina virtuale. I tenant possono sfruttare le interfacce comuni, ad esempio Service Provider Foundation, in modo da poter spostare i propri carichi di lavoro nel punto più appropriato per l'azienda o per in base ai propri requisiti in evoluzione. In questa soluzione viene usato Windows Azure Pack per il portale self-service, ma è possibile usare un portale self-service diverso se si preferisce.

Per una panoramica del prodotto, vedere Windows Azure Pack per Windows Server

System Center 2012 R2 Orchestrator

Fornisce Service Provider Foundation (SPF), che espone un servizio estendibile Web OData che interagisce con VMM. Ciò consente ai provider di servizi di progettare e implementare portali self-servizi multi-tenant che integrano le funzionalità IaaS disponibili in System Center 2012 R2.

Grazie a Windows Server 2012 R2 con System Center 2012 R2 Virtual Machine Manager (VMM), i provider di hosting dispongono di una soluzione gateway multi-tenant che supporta più connessioni tenant VPN da host a host, l'accesso a Internet per le macchine virtuali tenant mediante una funzionalità NAT gateway e funzionalità gateway di inoltro per le implementazioni di cloud privato. Virtualizzazione rete Hyper-V fornisce l'isolamento delle reti virtuali dei tenant con NVGRE, che consente ai tenant di mantenere i propri spazi degli indirizzi e offre ai provider di hosting una scalabilità migliore di quella ottenuta mediante l'isolamento con VLAN.

I componenti del progetto sono suddivisi in server separati perché ognuno ha requisiti di sicurezza, gestibilità e scalabilità specifici.

Per altre informazioni sui vantaggi di Virtualizzazione rete Hyper-V e Windows Server Gateway, vedere:

VMM offre un'interfaccia utente per gestire gateway, reti virtuali, macchine virtuali e altri elementi dell'infrastruttura.

Quando si pianifica la soluzione, prestare attenzione ai seguenti aspetti:

  • Progettazione della disponibilità elevata per i server che eseguono Hyper-V, le macchine virtuali guest, il server SQL, il gateway, VMM e altri servizi

    È necessario assicurarsi che la progettazione sia a tolleranza di errore e sia in grado di supportare le condizioni di disponibilità dichiarate.

  • Requisiti di accesso a Internet delle macchine virtuali dei tenant

    Valutare se i tenant richiedono l'accesso a Internet per le macchine virtuali. In caso affermativo, sarà necessario configurare la funzionalità NAT quando si distribuisce il gateway.

  • Velocità effettiva e capacità dell'hardware fisico dell'infrastruttura

    Verificare che la rete fisica sia in grado di offrire la scalabilità orizzontale necessaria man mano che si espande l'offerta IaaS.

  • Velocità effettiva di connessione da sito a sito

    Stabilire quale velocità effettiva è possibile fornire ai tenant e se le connessioni VPN da sito a sito saranno sufficienti.

  • Tecnologie di isolamento della rete

    Questa soluzione usa NVGRE per l'isolamento delle reti dei tenant. Stabilire se sono presenti o si possono ottenere componenti hardware ottimali per questo protocollo, ad esempio, schede di interfaccia di rete, commutatori e così via.

  • Meccanismi di autenticazione

    Questa soluzione usa due domini di Active Directory per l'autenticazione, uno per i server di infrastruttura e uno per il cluster gateway e il file server a scalabilità orizzontale per il gateway. Se non è disponibile un dominio di Active Directory per l'infrastruttura, occorre preparare un controller di dominio prima di iniziare la distribuzione.

  • Indirizzi IP

    Pianificare gli spazi degli indirizzi IP usati da questa soluzione.

Importante

Se si usano i frame jumbo nell'ambiente di rete, può essere necessario apportare alcune modifiche alla configurazione prima della distribuzione. Per altre informazioni, vedere l'articolo relativo alla riduzione di MTU in Virtualizzazione rete (NVGRE) di Windows Server 2012 R2.

Determinare i requisiti dei tenant

Per facilitare la pianificazione della capacità, è necessario determinare i requisiti dei tenant. Questi requisiti incideranno sulle risorse che devono essere disponibili per i carichi di lavoro tenant. Ad esempio, possono essere necessari più host Hyper-V con più RAM e spazio di archiviazione oppure può essere necessaria un'infrastruttura LAN e WAN più veloce per supportare il traffico di rete generato dai carichi di lavoro tenant.

Usare le domande seguenti per pianificare i requisiti dei tenant.

Considerazione di progettazione Effetto

Quanti tenant si prevede di ospitare e con quale rapidità si prevede che tale numero possa aumentare?

Consente di determinare il numero di host Hyper-V necessari per supportare i carichi di lavoro tenant.

L'analisi delle risorse di Hyper-V consente di tenere traccia dei dati cronologici sull'uso delle macchine virtuali e di comprendere l'uso delle risorse di server specifici. Per altre informazioni, vedere l'introduzione all'analisi delle risorse nel blog dedicato alla virtualizzazione Microsoft.

Quali tipi di carichi di lavoro si prevede che i tenant sposteranno sulla rete?

Consente di determinare la RAM, lo spazio di archiviazione e la velocità effettiva della rete (LAN e WAN) da mettere a disposizione dei tenant.

Qual è l'accordo di failover con i tenant?

Influenza la configurazione del cluster e le altre tecnologie di failover distribuite.

Per altre informazioni sulle problematiche di pianificazione delle risorse fisiche di calcolo, vedere la sezione 3.1.6 dedicata all'hypervisor nell'ambito delle risorse di calcolo fisiche nella guida alle opzioni di progettazione nella soluzione di infrastruttura cloud per l'IT aziendale.

Determinare la strategia di clustering di failover

Pianificare la strategia di clustering di failover in base alle esigenze dei tenant e alla propria tolleranza al rischio. Ad esempio, è consigliabile distribuire almeno gli host di gestione, calcolo e gateway come cluster a due nodi. Si può decidere di aggiungere altri nodi ai cluster e configurare il clustering guest per le macchine virtuali che eseguono SQL, Virtual Machine Manager, Windows Azure Pack e così via.

Per questa soluzione, i file server a scalabilità orizzontale, gli host Hyper-V di calcolo, gli host Hyper-V di gestione e gli host Hyper-V gateway vengono configurati come cluster di failover. È anche possibile configurare SQL, Virtual Machine Manager e le macchine virtuali guest gateway come cluster di failover. Questa configurazione assicura la protezione da eventuali malfunzionamenti a livello di computer fisico e macchina virtuale.

Considerazione di progettazione Effetto

Qual è la tolleranza al rischio per la mancata disponibilità di applicazioni e servizi?

Aggiungere nodi al cluster di failover per aumentare la disponibilità di applicazioni e servizi.

   
   

Definire la strategia di disponibilità elevata SQL

È necessario selezionare un'opzione SQL per la disponibilità elevata per questa soluzione. SQL Server 2012 presenta varie opzioni:

  • Istanze del cluster di failover AlwaysOn

    Questa opzione fornisce la disponibilità elevata locale tramite ridondanza a livello di istanza del server, un'istanza del cluster di failover.

  • Gruppi di disponibilità AlwaysOn

    Questa opzione consente di ottimizzare la disponibilità di uno o più database utente.

Per altre informazioni, vedere Soluzioni a disponibilità elevata (SQL Server).

Per l'opzione di disponibilità elevata SQL per questa soluzione, si consigliano le istanze del cluster di failover AlwaysOn. In questo modo, tutti i nodi del cluster si trovano nella stessa rete ed è disponibile l'archiviazione condivisa, che consente di distribuire un'istanza del cluster di failover più affidabile e stabile. Se non è disponibile spazio di archiviazione condiviso e i nodi si trovano in più reti, Gruppi di disponibilità AlwaysOn può essere una soluzione migliore.

Determinare i requisiti del gateway

È necessario pianificare il numero di cluster guest gateway necessari. Il numero da distribuire dipende dal numero di tenant da supportare. Anche i requisiti hardware per gli host Hyper-V gateway dipendono dal numero di tenant da supportare e dai requisiti del carico di lavoro dei tenant.

Per consigli sulla configurazione di Windows Server Gateway, vedere Requisiti di configurazione e hardware di Windows Server Gateway.

Per la pianificazione della capacità, si consiglia un cluster guest gateway ogni 100 tenant.

Il progetto per questa soluzione è orientato ai tenant che si connettono al gateway tramite una VPN da sito a sito. Si consiglia quindi di distribuire un gateway di Windows Server tramite una VPN. È possibile configurare un cluster di failover host Hyper-V a due nodi con un cluster di failover guest a due nodi tramite i modelli di servizio predefiniti disponibili nell'Area download Microsoft (per altre informazioni, vedere Come usare un server che esegue Windows Server 2012 R2 come gateway con VMM).

Considerazione di progettazione Effetto

In che modo i tenant si connetteranno alla rete?

  • Se i tenant si connettono tramite una VPN da sito a sito, è possibile usare Windows Server Gateway come terminazione VPN e gateway per le reti virtuali.

    Si tratta della configurazione oggetto di questa guida alla pianificazione e progettazione.

  • Se si usa un dispositivo VPN non Microsoft per terminare la VPN, è possibile usare Windows Server Gateway come gateway di inoltro per le reti virtuali dei tenant.

  • Se un tenant si connette alla rete del provider di servizi tramite una rete a commutazione di pacchetti, è possibile usare Windows Server Gateway come gateway di inoltro per connetterli alle reti virtuali.

Importante

È necessario distribuire un gateway di inoltro separato per ogni tenant che richiede un gateway di inoltro per la connessione alla rete virtuale.

Pianificare l'infrastruttura di rete

Per questa soluzione si usa Virtual Machine Manager per definire le reti logiche, le reti VM, i profili di porta, i commutatori logici e i gateway per organizzare e semplificare le assegnazioni di rete. Prima di creare questi oggetti, è necessario avere predisposto il piano dell'infrastruttura di rete logica e fisica.

In questo passaggio vengono forniti esempi di pianificazione per agevolare la creazione del piano di infrastruttura di rete.

Il diagramma mostra il progetto di rete consigliato per ogni nodo fisico nei cluster di gestione, calcolo e gateway.

Progettazione della rete per i nodi cluster

Interfacce di rete del nodo di gestione ed elaborazione

È necessario pianificare diverse subnet e VLAN per le diverse tipologie di traffico generate, ad esempio gestione/infrastruttura, virtualizzazione della rete, esterno (in uscita), clustering, archiviazione e migrazione in tempo reale. È possibile usare reti VLAN per isolare il traffico di rete al commutatore.

Questo progetto, ad esempio, consiglia le reti elencate nella tabella seguente. La velocità della linea, gli indirizzi, le VLAN e così via possono variare a seconda dell'ambiente specifico.

Piano subnet/VLAN

Velocità della linea (Gb/S) Scopo Indirizzo VLAN Commenti

1

Gestione/Infrastruttura

172.16.1.0/23

2040

Rete per la gestione e l'infrastruttura. Gli indirizzi possono essere statici o dinamici e vengono configurati in Windows.

10

Virtualizzazione di rete

10.0.0.0/24

2044

Rete per il traffico di rete VM. Gli indirizzi devono essere statici e vengono configurati in Virtual Machine Manager.

10

Altre informazioni

131.107.0.0/24

2042

Rete esterna, con connessione Internet. Gli indirizzi devono essere statici e vengono configurati in Virtual Machine Manager.

1

Clustering

10.0.1.0/24

2043

Usato per le comunicazioni nel cluster. Gli indirizzi possono essere statici o dinamici e vengono configurati in Windows.

10

Archiviazione

10.20.31.0/24

2041

Usato per il traffico di archiviazione. Gli indirizzi possono essere statici o dinamici e vengono configurati in Windows.

Piano di rete logica VMM

Questo progetto consiglia le reti logiche elencate nella tabella seguente. Le reti logiche possono variare in base alle esigenze specifiche.

Nome Pool IP e siti di rete Note

Altre informazioni

  • Rack01_External

    • 131.107.0.0/24, VLAN 2042

    • Tutti gli host

Reti host

  • Rack01_LiveMigration

    • 10.0.3.0, VLAN 2045

    • Tutti gli host

  • Rack01_Storage

    • 10.20.31.0, VLAN 2041

    • Tutti gli host

Infrastruttura

  • Rack01_Infrastructure

    • 172.16.0.0/24, VLAN 2040

    • Tutti gli host

Virtualizzazione di rete

  • Rack01_NetworkVirtualization

    • 10.0.0.0/24, VLAN 2044

    • Tutti gli host

Piano di rete VM VMM

Questo progetto usa le reti VM elencate nella tabella seguente. Le reti VM possono variare in base alle esigenze specifiche.

Nome Intervallo di indirizzi del pool IP Note

Altre informazioni

Nessuno

Migrazione in tempo reale

10.0.3.1 – 10.0.3.254

Gestione

Nessuno

Archiviazione

10.20.31.1 – 10.20.31.254

Dopo aver installato Virtual Machine Manager, è possibile creare un commutatore logico e profili di porte uplink. È quindi possibile configurare gli host sulla rete per l'uso di un commutatore logico con schede di rete virtuali collegate al commutatore. Per altre informazioni sui commutatori logici e sui profili di porte uplink, vedere Configurazione di porte e commutatori per le reti VM in VMM.

Questo progetto usa i seguenti i seguenti profili di porte uplink, come definito in VMM:

Piano di profili di porte uplink in VMM

Nome Proprietà generale Configurazione di rete

Rack01_Gateway

  • Algoritmo di bilanciamento del carico: Host predefinito

  • Modalità gruppo: LACP

Siti di rete:

  • Rack01_External, Rete logica: Altre informazioni

  • Rack01_LiveMigration, Rete logica: Reti host

  • Rack01_Storage, Rete logica: Reti host

  • Rack01_Infrastructure, Rete logica: Infrastruttura

  • Network Virtualization_0, Rete logica: Virtualizzazione di rete

Rack01_Compute

  • Algoritmo di bilanciamento del carico: Host predefinito

  • Modalità gruppo: LACP

Siti di rete:

  • Rack01_External, Rete logica: Altre informazioni

  • Rack01_LiveMigration, Rete logica: Reti host

  • Rack01_Storage, Rete logica: Reti host

  • Rack01_Infrastructure, Rete logica: Infrastruttura

  • Network Virtualization_0, Rete logica: Virtualizzazione di rete

Rack01_Infrastructure

  • Algoritmo di bilanciamento del carico: Host predefinito

  • Modalità gruppo: LACP

Siti di rete:

  • Rack01_LiveMigration, Rete logica: Reti host

  • Rack01_Storage, Rete logica: Reti host

  • Rack01_Infrastructure, Rete logica: Infrastruttura

Questo progetto distribuisce il commutatore logico seguente tramite i profili di porta uplink seguenti, come definito in VMM:

Piano di commutatore logico VMM

Nome Estensione Uplink Porta virtuale

VMSwitch

Piattaforma filtro Microsoft Windows

  • Rack01_Compute

  • Rack01_Gateway

  • Rack01_Infrastructure

  • Larghezza di banda elevata

  • Infrastruttura

  • Carico di lavoro migrazione in tempo reale

  • Larghezza di banda ridotta

  • Larghezza di banda media

Questo progetto consente di isolare i carichi di traffico maggiori sui collegamenti di rete più veloci. Ad esempio, il traffico di rete di archiviazione è isolato dal traffico di virtualizzazione di rete su collegamenti veloci separati. Per usare i collegamenti di rete più lenti per alcuni dei carichi elevati di traffico, è possibile usare il gruppo NIC.

Importante

Se si usano i frame jumbo nell'ambiente di rete, può essere necessario apportare alcune modifiche alla configurazione durante la distribuzione. Per altre informazioni, vedere l'articolo relativo alla riduzione di MTU in Virtualizzazione rete (NVGRE) di Windows Server 2012 R2.

Pianificare la distribuzione di Windows Azure Pack

Se si usa Windows Azure Pack per il portale self-service tenant, è possibile configurare molte opzioni da offrire ai tenant. Questa soluzione include alcune funzionalità cloud di macchine virtuali, ma sono disponibili molte altre opzioni, non solo con cloud di macchine virtuali ma anche con cloud di siti Web, cloud del bus di servizio, SQL Server, MySQL Server e così via. Per altre informazioni sulle funzionalità di Windows Azure Pack, vedere Windows Azure Pack per Windows Server.

Dopo aver esaminato la documentazione di Windows Azure Pack, stabilire quali servizi distribuire. Dato che questa soluzione usa solo Windows Azure Pack come componente facoltativo, usa solo alcune delle funzionalità Cloud di siti Web, mediante una distribuzione con installazione rapida, con tutte i componenti di Windows Azure Pack installati in una singola macchina virtuale. Se Windows Azure Pack è usato come portale di produzione, invece, è consigliabile usare una distribuzione distribuita e pianificare le risorse aggiuntive necessarie.

Per determinare i requisiti host per un'implementazione di produzione distribuita, vedere Architettura di Windows Azure Pack.

Se si decide di distribuire Windows Azure Pack nell'ambiente di produzione usare una distribuzione distribuita. Se si preferisce valutare le funzionalità di Windows Azure Pack prima della distribuzione nell'ambiente di produzione, usare la distribuzione con installazione rapida. Per questa soluzione viene usata la distribuzione con installazione per presentare il servizio Cloud di siti Web. Si distribuisce Windows Azure Pack in una singola macchina virtuale situata nel cluster di calcolo in modo che i portali Web siano accessibili dalla rete esterna (Internet). Quindi si distribuisce una macchina virtuale che esegue Service Provider Foundation su una macchina virtuale situata nel cluster di gestione.

Perché viene consigliato questo progetto?

Il progetto include i cluster di failover per garantire disponibilità elevata e scalabilità per la soluzione.

Il diagramma seguente mostra i quattro tipi di cluster di failover distribuiti. Ogni cluster di failover consente di isolare i ruoli richiesti per la soluzione.

Macchine virtuali e cluster fisici

Nella tabella seguente sono indicati gli host fisici consigliati per questa soluzione. È stato scelto un numero di nodi corrispondente al requisiti minimo per garantire la disponibilità elevata. È possibile aggiungere altri host fisici per distribuire ulteriormente i carichi di lavoro per soddisfare i requisiti specifici. Ogni host dispone di 4 schede di rete fisiche per supportare i requisiti di isolamento di rete del progetto. Si consiglia di usare un'infrastruttura di rete da 10 GB/s o più veloce. 1 Gb/s può essere adeguato per il traffico del cluster e dell'infrastruttura.

Consiglio per gli host fisici

Host fisici Ruolo nella soluzione Ruoli di macchina virtuale

2 host configurati come cluster di failover

Cluster di infrastruttura/gestione:

Fornisce gli host Hyper-V per i carichi di lavoro di gestione/infrastruttura (VMM, SQL, Service Provider Foundation, file server a scalabilità orizzontale in cluster guest per il dominio gateway, controller di dominio).

  • SQL in cluster guest

  • VMM in cluster guest

  • File server di file di scalabilità orizzontale in cluster guest per il dominio gateway

  • Endpoint di Service Provider Foundation

2 host configurati come cluster di failover

Cluster di calcolo:

Fornisce gli host Hyper-V per i carichi di lavoro dei tenant e Windows Azure Pack for Windows Server.

  • Tenant

  • Portale Windows Azure Pack accessibile da reti pubbliche

2 host configurati come cluster di failover

Cluster di archiviazione:

Fornisce i file server a scalabilità orizzontale per l'archiviazione cluster di gestione e infrastruttura.

Nessuno (il cluster ospita solo condivisioni file)

2 host configurati come cluster di failover

Cluster gateway di Windows Server:

Fornisce gli host Hyper-V per le macchine virtuali gateway.

Per consigli sulla configurazione di host fisici gateway e macchine virtuali gateway, vedere Requisiti di configurazione e hardware di Windows Server Gateway.

Gateway cluster guest

Quali sono i passaggi necessari per implementare la soluzione?

Importante

Quando si distribuiscono host e macchine virtuali Hyper-V, è estremamente importante applicare tutti gli aggiornamenti disponibili per il software e i sistemi operativi usati nella soluzione. In caso contrario, la soluzione potrebbe non funzionare nel modo previsto.

Per implementare la soluzione è possibile eseguire i passaggi descritti in questa sezione. Verificare la corretta esecuzione di ogni passaggio prima di procedere al successivo.

Nota

Per stampare o esportare un set personalizzato di argomenti della soluzione, vedere la guida alla stampa/esportazione di più argomenti.

  1. Distribuire o identificare un dominio di Active Directory.

    I file server di gestione, calcolo e scalabilità orizzontale verranno aggiunti al dominio. In alternativa, identificare un dominio di Active Directory esistente che possa ospitare i server.

  2. Distribuire o identificare un secondo dominio di Active Directory.

    Questo secondo dominio di Active Directory ospiterà i server gateway host Hyper-V e un file server a scalabilità orizzontale per l'archiviazione gateway. Questo secondo dominio di Active Directory non deve avere alcuna relazione di trust con il dominio dell'infrastruttura per motivi di sicurezza.

    Importante

    Assicurarsi che ognuno dei domini sia in grado di risolvere i nomi nell'altro dominio. Ad esempio, è possibile configurare un server d'inoltro in ogni server DNS in modo che punti al server DNS nell'altro dominio.

  3. Distribuire i nodi di archiviazione e i cluster per il dominio di gestione.

    Un file server a scalabilità orizzontale ospita la memoria per questa soluzione come condivisioni di file. Questo file server a scalabilità orizzontale è configurato su host fisici nel dominio di gestione. Successivamente viene implementato un altro file server a scalabilità orizzontale per il dominio gateway nelle macchine virtuali sul cluster di gestione. Per altre informazioni sulla distribuzione di un file server a scalabilità orizzontale, vedere Distribuire un file server a scalabilità orizzontale.

  4. Distribuire i cluster e i nodi di gestione.

    Nota

    Sarà necessario creare un commutatore virtuale temporaneo mediante la console di gestione di Hyper-V per poter installare e configurare le macchine virtuali. Dopo l'installazione di VMM, è possibile definire un commutatore logico in VMM, eliminare il commutatore virtuale definito in Hyper-V e configurare gli host per l'uso di un commutatore virtuale basato sul commutatore logico definito in VMM.

    Questo cluster host ospiterà le macchine virtuali del server SQL, del server Service Provider Foundation e del file server a scalabilità orizzontale (per il dominio gateway). Il file server a scalabilità orizzontale per il dominio gateway viene implementato nelle macchine virtuali e aggiunto al dominio gateway. Per ulteriori informazioni, vedere i seguenti argomenti:

    Importante

    Per il momento distribuire tutte le macchine virtuali in un nodo cluster host. Dopo avere configurato le funzionalità di rete in VMM, è necessario bilanciare il carico delle macchine virtuali tra i nodi del cluster host.

    1. Distribuire il cluster guest SQL.

      Per informazioni sulla distribuzione di un'istanza del cluster di failover SQL Server, vedere gli argomenti seguenti:

    2. Distribuire VMM.

      Per informazioni a questo proposito, vedere Distribuzione di System Center 2012 - Virtual Machine Manager. Per questa soluzione si usa VMM per distribuire e gestire il gateway e altre funzionalità di rete.

      1. Installare VMM in un cluster guest.

        Per informazioni su come procedere, vedere gli argomenti seguenti:

      2. Aggiungere un server di libreria usando una condivisione sul file server a scalabilità orizzontale. Per altre informazioni, vedere Come aggiungere un server di libreria VMM o una condivisione di libreria VMM. Quando viene richiesto di specificare il nome del computer, digitare il nome usato durante la configurazione del ruolo del file server a scalabilità orizzontale. Non usare il nome del cluster.

        Importante

        Quando si aggiunge un server di libreria, assicurarsi di usare un account utente diverso dall'account del servizio VMM. In caso contrario, l'aggiunta del server di libreria avrà esito negativo senza alcun avviso e nessuna cronologia processo indicherà che si è verificato un errore.

      3. Disabilitare l'impostazione Crea automaticamente reti logiche prima di aggiungere host. Le reti logiche verranno create manualmente in seguito con specifiche impostazioni. Questa impostazione si trova in Impostazioni, Impostazioni di rete.

      4. Aggiungere gli host Hyper-V designati come host VMM.

        Aggiungere il cluster di gestione e il cluster File Server a scalabilità orizzontale. In seguito si aggiungerà il cluster host di calcolo.

        È consigliabile aggiungere il cluster File Server a scalabilità orizzontale nella categoria Infrastruttura, Archiviazione, File server. È consigliabile aggiungere il cluster di gestione (e infine il cluster di calcolo) in Tutti gli host. Per organizzare gli host, creare altri gruppi host, ad esempio Calcolo e Gestione e inserire i cluster appropriati nei gruppi host.

        Importante

        Quando si distribuisce un file server a scalabilità orizzontale per il dominio gateway, è necessario aprire la porta pubblica Gestione remota Windows (HTTP-In) porta in entrambi i nodi del cluster guest. Questa porta deve essere aperta perché il server VMM e cluster gateway si trovano in domini non attendibili separati e tale porta non è aperta per impostazione predefinita per il profilo pubblico.

        Per altre informazioni, vedere Panoramica sull'aggiunta di server Windows come host Hyper-V in VMM.

        Per una procedura di esempio, vedere la sezione relativa all'aggiunta di HNVHOST1, HNVHOST2 e HNVHOST3 come host VMM nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

      5. Aggiungere l'archiviazione alla condivisione file.

        Dopo aver aggiunto il cluster, è possibile configurare i percorsi di archiviazione per le macchine virtuali distribuite nei nodi del cluster. Aprire la pagina Proprietà per il cluster e aggiungere una condivisione dal file server a scalabilità orizzontale nella pagina Archiviazione condivisione file.

      6. Creare le reti logiche pianificate e i pool IP associati.

        Per questa soluzione è possibile creare una rete logica per le reti Esterna (Internet), Infrastruttura, Reti host (con pool IP Cluster e pool IP Migrazione in tempo reale) e Virtualizzazione di rete. Tenere presente che questi sono nomi di esempio, ma è possibile usare nomi personalizzati in base al proprio piano. Creare i pool IP appropriati per ogni rete logica in base al piano, assicurandosi che gli intervalli di indirizzi IP non coincidano con indirizzi IP esistenti in uso.

        Configurare la rete logica Reti host come Rete indipendente basata su VLAN e configurare le altre come Una rete connessa.

        Per altre informazioni, vedere Come creare una rete logica in VMM.

        Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla definizione di reti logiche con pool IP associati nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

      7. Creare reti VM per le reti logiche Infrastruttura, Esterna (Internet), Migrazione in tempo reale e Archiviazione.

        Creare un pool di indirizzi IP per le reti Archiviazione e Migrazione in tempo reale, con l'intervallo di indirizzi appropriato in base al piano.

        Per altre informazioni, vedere l'argomento relativo alla creazione di una rete VM in VMM in System Center 2012 R2.

        Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla definizione di reti VM nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

      8. Creare i profili di porta uplink

        Creare un profilo di porta uplink Gateway, Calcolo e Infrastruttura. Configurare l'algoritmo di bilanciamento del carico Host predefinito e la modalità gruppo LACP (Link Aggregation Control Protocol), supponendo che il commutatore supporti LACP. Selezionare tutti i siti di rete per la configurazione di rete del profilo di porta Calcolo e Gateway e i siti Migrazione in tempo reale, Archiviazione e Infrastruttura per i profili Infrastruttura.

        Per altre informazioni, vedere Configurazione di porte e commutatori per le reti VM in System Center 2012 SP1.

        Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla creazione di profili di porta e commutatori logici VM nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

      9. Creare il commutatore logico.

        Selezionare Piattaforma filtro Microsoft Windows per le estensioni, selezionare Team per la modalità Uplink e aggiungere i tre profili di porta uplink creati in precedenza.

        Aggiungere le seguenti porte virtuali: Larghezza di banda elevata, Infrastruttura, carico di lavoro Migrazione in tempo reale, Larghezza di banda ridotta e Larghezza di banda media.

      10. Creare un commutatore virtuale raggruppato in un nodo di gestione.

        Aggiungere un commutatore virtuale al nodo cluster host di gestione, ovvero il nodo a cui non sono associate macchine virtuali.

        A questo scopo, in VMM individuare il nodo host nel riquadro Infrastruttura, Server, aprire la pagina Proprietà e aggiungere un commutatore virtuale nella pagina Nuovo commutatore virtuale.

        Aggiungere le due schede fisiche più veloci per formare un team e scegliere il profilo di porta uplink Infrastruttura. Aggiungere quindi due schede di rete virtuale per Migrazione in tempo reale e Archiviazione.

        Al termine dell'operazione, verificare che il commutatore virtuale risulti analogo a quanto segue:

        Switch virtuale

        Scheda virtuale dell'adattatore virtuale - Migrazione in tempo reale

        Scheda virtuale dell'adattatore virtuale - Archiviazione

        Importante

        Può essere necessario apportare alcune modifiche di configurazione alle porte di commutazione fisiche a cui sono connesse queste schede di rete. Se si usa LACP per il gruppo, è necessario configurare le porte del commutatore per LACP. Se le porte di commutazione sono configurate in modalità Accesso (per i pacchetti senza tag), è necessario configurarle in modalità Trunk, poiché i pacchetti con tag saranno provenienti dalle schede in gruppo.

        Per altre informazioni, vedere l'argomento relativo alla configurazione delle impostazioni di rete su un host applicando un commutatore logico in VMM.

        Suggerimento

        Per operazioni di risoluzione dei problemi, è possibile usare i seguenti cmdlet di Windows PowerShell:

        Get-NetLbfoTeam, Get-NetLbfoTeamMember e Get-NetLbfoTeamNic

        Per visualizzare altri cmdlet correlati, digitare Get-command *lbfo*.

      11. Configurare le impostazioni di migrazione.

        Terminata la configurazione della scheda di migrazione sul commutatore virtuale, è possibile configurare le impostazioni di migrazione nella pagina Proprietà, Impostazioni di migrazione di ogni nodo. Configurare le impostazioni desiderate e assicurarsi che l'indirizzo subnet per la migrazione in tempo reale sia stato aggiunto e si trovi nella parte superiore dell'elenco. In realtà la subnet viene immessa come indirizzo IP singolo con maschera a 32 bit: x.x.x.x/32. Quindi, se l'indirizzo della scheda di rete virtuale per la migrazione in tempo reale è 10.0.3.6, la pagina Impostazioni di migrazione sarà simile alla seguente:

        Impostazioni della migrazione

      12. Eseguire la migrazione in tempo reale delle macchine virtuali.

        Ora che è presente un host con un commutatore virtuale configurato tramite VMM, è possibile eseguire la migrazione delle macchine virtuali per preparare un altro nodo allo stesso modo.

        Per eseguire la migrazione delle macchine virtuali, in VMM selezionare l'area di lavoro VM e servizi, selezionare il nodo nel cluster di gestione in cui vengono eseguite le macchine virtuali, fare clic con il pulsante destro del mouse sulla macchina virtuale in esecuzione e scegliere Esegui migrazione macchina virtuale. Selezionare l'altro nodo e spostare la macchina virtuale.

      13. Eliminare il commutatore virtuale originariamente creato tramite la console di gestione di Hyper-V.

        Dopo avere spostato le macchine virtuali, è possibile eliminare il commutatore virtuale originale creato con la console di gestione di Hyper-V.

      14. Creare un nuovo commutatore virtuale raggruppato tramite VMM.

        Dopo aver eliminato il commutatore virtuale precedente, è possibile creare un nuovo commutatore virtuale raggruppato usando la stessa procedura seguita per il nodo precedente. Eseguire il passaggio precedente per creare il commutatore virtuale in questo nodo con VMM.

      15. Eseguire nuovamente la migrazione in tempo reale di alcune macchine virtuali.

        Ora che entrambi i nodi sono configurati con un commutatore virtuale raggruppato con VMM, è possibile eseguire nuovamente la migrazione di alcune delle macchine virtuali. Ad esempio, spostare uno dei nodi del cluster guest SQL per fare in modo che i nodi del cluster guest siano suddivisi tra i nodi del cluster host. Ripetere l'operazione per tutti gli altri cluster guest.

      Al termine di questo passaggio, entrambi i nodi del cluster host di gestione saranno installati con le macchine virtuali di gestione e la rete del nodo host configurata tramite VMM.

  5. Distribuire i nodi e i cluster di calcolo.

    Il cluster Hyper-V ospita le macchine virtuali tenant e il server del portale Windows Azure Pack.

    La procedura per installare il cluster Hyper-V di calcolo è analoga a quella eseguita per installare il cluster di gestione:

    1. Distribuire gli host Hyper-V e accedere al dominio di gestione.

    2. Includere gli host in un cluster e aggiungere il cluster al gruppo Host di Calcolo VMM.

    3. Creare il commutatore virtuale raggruppato e le schede virtuali di migrazione in tempo reale e archiviazione per entrambi i nodi host come fatto in precedenza per i nodi di gestione. Quando si raggruppano le schede di rete fisiche, usare il profilo di porta Uplink di Calcolo per le schede.

    4. Aggiungere l'archiviazione alla condivisione file.

      Configurare un percorso di archiviazione per le macchine virtuali distribuite nei nodi del cluster. Aprire la pagina delle proprietà per il cluster e aggiungere una condivisione dal file server a scalabilità orizzontale nella pagina Archiviazione condivisione file.

  6. Distribuire il gateway.

    Per distribuire il gateway di Windows Server in Windows Server 2012 R2, distribuire un cluster host di Hyper-V dedicato e quindi le macchine virtuali gateway mediante VMM. Il gateway di Windows Server offre un punto di connessione per più connessioni VPN tenant da sito a sito. La procedura è simile a quella per la distribuzione degli host fisici, ma usando un modello di servizio VMM per distribuire le macchine virtuali del cluster guest.

    Per distribuire il gateway di Windows Server, procedere nel modo seguente:

    1. Distribuire gli host Hyper-V e accedere al dominio gateway.

    2. Includere gli host in un cluster e aggiungere il cluster al gruppo Host di Gateway VMM.

    3. Creare il commutatore virtuale raggruppato e le schede virtuali di migrazione in tempo reale e archiviazione per entrambi i nodi host come fatto in precedenza per i nodi di gestione e calcolo. Quando si raggruppano le schede di rete fisiche, usare il profilo di porta Uplink di Gateway per le schede.

    4. Aggiungere l'archiviazione alla condivisione file.

      Configurare un percorso di archiviazione per le macchine virtuali distribuite nei nodi del cluster. Aprire la pagina Proprietà per il cluster e aggiungere una condivisione dal file server a scalabilità orizzontale nella pagina Archiviazione condivisione file.

    5. Assicurarsi che sia disponibile una condivisione file da VMM (in cui è presente un file con estensione vhd o vhdx di Windows Server 2012 R2). Questo file verrà usato dal modello di servizio VMM per distribuire le macchine virtuali gateway.

    6. Configurare gli host come host gateway.

      Ogni host Hyper-V gateway deve essere configurato come gateway di virtualizzazione di rete dedicato. In VMM fare clic con il pulsante destro del mouse su un host gateway e scegliere Proprietà. Fare clic su Accesso host e selezionare la casella di controllo Questo host è un gateway della virtualizzazione rete dedicato, pertanto non è disponibile per la selezione host delle macchine virtuali che richiedono la virtualizzazione di rete.

    7. Per distribuire le macchine virtuali gateway, eseguire le procedure indicate nell'argomento relativo a come usare un server che esegue Windows Server 2012 R2 come gateway con VMM ed eseguire la distribuzione mediante il modello di servizio 3-NIC HA Gateway.

      Il modello di servizio che consente di distribuire il gateway è corredato da una Guida introduttiva in cui sono fornite alcune informazioni per la configurazione dell'infrastruttura per la distribuzione del gateway. Si tratta di informazioni simili a quelle fornite in questa guida. In tale Guida introduttiva è possibile saltare i passaggi relativi all'infrastruttura già illustrati nella presente guida.

      Quando si giunge alla procedura di configurazione finale e si esegue la procedura guidata per l'aggiunta del servizio di rete, la pagina Stringa di connessione sarà simile alla seguente:

      Stringa di connessione del servizio di rete

      La proprietà Connettività del servizio di rete del gateway sarà simile alla seguente:

      Connettività del servizio di rete

    Al termine di questo passaggio, verificare che due processi nel registro risultino completati:

    • Aggiorna dispositivo del servizio di rete

    • Aggiungi la connessione al dispositivo del servizio di rete

    Suggerimento

    Se è necessario distribuire regolarmente un cluster guest gateway, ad esempio per far fronte alle richieste di risorse, si può personalizzare il modello di servizio mediante Progettazione modelli di servizio. Ad esempio, è possibile personalizzare le impostazioni Configurazione sistema operativo per l'aggiunta a un dominio specifico, l'uso di un codice Product Key specifico o l'uso di una configurazione del nome di computer specifico.

    Avviso

    Non modificare il modello di servizio gateway per rendere le macchine virtuali a disponibilità elevata. Il modello di servizio gateway lascia intenzionalmente deselezionata la casella di controllo Macchina virtuale a disponibilità elevata nell'area Avanzate\Disponibilità. Le macchine virtuali sono configurate come nodi di un cluster guest, ma è importante non modificare questa impostazione. Altrimenti, durante il failover, gli indirizzi del cliente (CA) non vengono associati al nuovo indirizzo del provider (PA) e il gateway non funzionerà correttamente.

  7. Verificare il funzionamento del gateway.

    Verificare che vi sia connettività tra una macchina virtuale di test e gli host situati su una rete tenant di test.

    Usare la procedura seguente per verificare che il gateway e le reti VM funzionino correttamente.

    1. Stabilire una connessione VPN da sito a sito.

      La modalità di connessione della rete tenant di test varia a seconda delle apparecchiature usate per stabilire la connessione VPN. Accesso remoto, che riunisce DirectAccess e Servizio Routing e Accesso remoto (RRAS), è una delle modalità di connessione al gateway. Per un esempio di uso di RRAS per la connessione al gateway, vedere la sezione relativa all'installazione di RRAS in Contoso EDGE1 e creazione di una connessione VPN da sito a sito per GatewayVM1 in esecuzione su HNVHOST3 nella guida dell'ambiente di testing per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

      Suggerimento

      Per connettere altri dispositivi VPN, i requisiti di connettività sono simili ai requisiti per la connessione di VPN in Windows Azure. Per altre informazioni, vedere Informazioni sui dispositivi VPN per Rete virtuale

    2. Visualizzare la connessione VPN da sito a sito sul gateway.

      Dopo avere stabilito la connessione VPN, è possibile usare alcune comandi di Windows PowerShell e alcune nuove opzioni di ping per verificare la connessione VPN.

      Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla visualizzazione delle connessioni VPN da sito a sito in GatewayVM1 nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

    3. Distribuire le macchine virtuali tenant di test.

      Dopo avere verificato la presenza di una connessione da sito a sito al gateway, è possibile distribuire una macchina virtuale di test e connetterla alla rete VM di test sulla rete del provider di servizi di hosting.

      Per una procedura di esempio in un ambiente di testing, vedere il passaggio 2 relativo alla distribuzione di macchine virtuali tenant nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

    4. Verificare la connettività di rete delle VM di test e il funzionamento di Virtualizzazione rete Hyper-V da sito a sito.

      Dopo avere distribuito la macchina virtuale di test, è necessario verificare che disponga di connettività di rete alle risorse remote nella rete locale tenant su Internet tramite il gateway da sito a sito multi-tenant.

      Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla verifica della connettività di rete per le macchine virtuali APP2 nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

  8. Distribuire Gestione indirizzi IP di Windows Server (consigliato).

    Gestione indirizzi IP di Windows Server è integrato con VMM per la gestione dello spazio degli indirizzi IP per l'infrastruttura dell'ambiente e del cliente. Per altre informazioni, vedere Distribuzione del server di Gestione indirizzi IP.

    Per una procedura di esempio in un ambiente di testing, vedere il passaggio 6 relativo alle operazioni di installazione e configurazione di Gestione indirizzi IP su HNVHOST2 nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

    Dopo la distribuzione di gestione indirizzi IP, configurare il plug-in IPAM VMM. Per altre informazioni, vedere Come aggiungere un server di Gestione indirizzi IP in VMM in System Center 2012 R2.

    Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa alla configurazione del plug-in IPAM VMM in HNVHOST2 nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

    Al termine di questo passaggio, verificare che lo spazio di indirizzi virtualizzato sia visibile in Gestione indirizzi IP.

    Per una procedura di esempio in un ambiente di testing, vedere la sezione relativa all'uso di Gestione indirizzi IP per visualizzare lo spazio degli indirizzi virtualizzato nella guida dell'ambiente di prova per Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM.

  9. Distribuire un portale self-service tenant.

    Un portale self-service tenant consente ai tenant di creare reti virtuali e macchine virtuali con il minimo coinvolgimento del provider di servizi di hosting. I provider di servizi possono progettare e implementare portali self-servizi multi-tenant che integrano le funzionalità IaaS disponibili in System Center 2012 R2. Service Provider Foundation espone un servizio estendibile Web OData che interagisce con VMM.

    Windows Azure Pack è una soluzione di portale self-service Microsoft che si integra con VMM tramite SPF. Offre un portale di sito Web simile a Windows Azure, quindi se i tenant sono anche clienti di Windows Azure avranno già familiarità con l'interfaccia utente in Windows Azure Pack. Per presentare le funzionalità di Windows Azure Pack per questa soluzione viene usata una distribuzione di Windows Azure Pack con installazione rapida. Le funzionalità necessarie vengono installate in un unico server. Per distribuire Windows Azure Pack nell'ambiente di produzione, è consigliabile usare la distribuzione distribuita. Per altre informazioni, vedere Requisiti di installazione di Windows Azure Pack.

    1. Creare la macchina virtuale WAPPortal.

      Esaminare i Prerequisiti hardware e software per le distribuzioni con installazione rapida, quindi creare la macchina virtuale WAPPortal sul cluster di calcolo.

    2. Installare i prerequisiti software.

      Seguire la procedura indicata in Installare i prerequisiti software.

    3. Installare una distribuzione con installazione rapida di Windows Azure Pack.

      Seguire la procedura indicata in Installare una distribuzione con l'opzione di installazione rapida di Windows Azure Pack.

    4. Consultare gli argomenti riportati in Effettuare il provisioning di cloud di macchine virtuali, quindi esaminare le indicazioni fornite in Requisiti per l'utilizzo del servizio Cloud VM.

    5. Creare un cloud con VMM.

      Ad esempio, è possibile usare la Creazione guidata cloud per creare un cloud con le proprietà seguenti:

      Proprietà Impostazioni

      Generale

      Nome: Oro

      Risorse

      Gruppo host: Calcolo

      Reti logiche

      Virtualizzazione di rete

      Classificazioni porte

      Larghezza di banda elevata

      Archiviazione

      Archiviazione remota

      Libreria

      VMM-Lib (una condivisione file situata nel file server a scalabilità orizzontale)

      Capacità

      Capacità cloud: impostare la capacità desiderata

      Per altre informazioni sulla creazione di un cloud in VMM, vedere Come creare un cloud privato da gruppi host.

    6. Installare Service Provider Foundation in una macchina virtuale separata situata nel cluster di gestione e infrastruttura seguendo la procedura per l'installazione di Service Provider Foundation per System Center 2012 SP1.

    7. Configurare SPF per l'uso con Windows Azure Pack, come descritto nella sezione relativa alla configurazione di Windows Azure Pack per Windows Server in Configurazione di portali per Service Provider Foundation.

      Al termine della procedura di registrazione dell'endpoint SPF per cloud di macchine virtuali, il cloud creato in VMM dovrebbe essere visualizzato nel portale dell'amministratore di Windows Azure Pack.

    8. Dal portale dell'amministratore di Windows Azure Pack, creare un piano da usare per i test. Ad esempio, è possibile creare un piano denominato Piano oro con le proprietà seguenti:

      Proprietà Impostazioni

      Nome

      Piano oro

      Servizi

      Cloud di macchine virtuali

      Dopo averlo creato, fare clic sul piano per proseguire la configurazione. Fare clic sul servizio Cloud macchine virtuali e configurare Server di gestione VMM, Cloud macchine virtuali e i limiti di utilizzo. Fare clic su Salva per completare la configurazione dei cloud di macchine virtuali. Fare clic sul pulsante Indietro e infine su Modifica accesso per pubblicare il piano.

    9. Creare una risorsa Raccolta di Windows Azure Pack. I tenant possono usare la raccolta per posizionare le macchine virtuali nelle loro reti virtuali. Per altre informazioni, vedere l'argomento relativo a download e installazione della risorsa Galleria di Windows Azure Pack.

    10. Nella pagina di accesso del portale tenant di Windows Azure Pack fare clic su Iscrizione per registrare un account tenant di test.

      Procedere al portale tenant, aggiungere una sottoscrizione e scegliere un piano.

    11. Una volta creato l'account, creare una nuova rete virtuale per il tenant mediante Creazione personalizzata.

      Dopo avere creato la rete, verificare che sia presente in Reti VM in VMM.

    12. Stabilire una connessione VPN da sito a sito con il tenant di test come fatto in precedenza durante la creazione di una rete virtuale di test manuale.

    13. Creare un nuovo ruolo macchina virtuale usando la raccolta creata in precedenza.

    14. Dopo avere creato la macchina virtuale di test, verificare che disponga di connettività alla rete tenant attraverso il tunnel VPN da sito a sito.

Configurazioni facoltative

Questa sezione descrive le configurazioni facoltative per aggiungere funzionalità alla soluzione.

Distribuire un gateway di inoltro per il supporto delle macchine virtuali connessi a Internet

È possibile che alcuni tenant vogliano distribuire macchine virtuali connesse direttamente a Internet e che abbiano esigenze di connessione che non richiedono NAT nel percorso della connessione.

In alternativa, è possibile che siano presenti tenant che necessitano di connettività diretta con una rete fisica. Ad esempio, una VLAN con hardware con percorso condiviso o rete commutata con pacchetti, quale una rete MPLS (Multiprotocol Label Switching).

Per supportare questi requisiti è possibile usare un gateway di inoltro connesso a una rete VM usata esclusivamente per le macchine virtuali connesse direttamente, quindi creare subnet sulla rete VM per ogni tenant. È possibile usare gli elenchi di controllo di accesso estesi per isolare le singole macchine virtuali tenant e controllare il traffico di rete in entrata e in uscita delle macchine virtuali.

Ecco come:

  1. Distribuire un gateway tramite il modello di servizio come per la soluzione originale.

  2. Si noti l'indirizzo IP front-end del cluster e il nome del nuovo cluster gateway VM. Queste informazioni verranno usate nella stringa di connessione nel passaggio successivo.

  3. Creare un nuovo servizio di rete in VMM per distribuire il servizio gateway di inoltro. Utilizzare una stringa di connessione simile alla seguente:

    VMHost=gateway-cl.adatum-gw.lab;GatewayVM=FGWCL01.adatum-gw.lab;BackendSwitch=VMSwitch;DirectRoutingMode=True;FrontEndServerAddress=131.107.0.55

    Nota

    Notare i nuovi parametri nella stringa di connessione: DirectRoutingMode e FrontEndServerAddress.

  4. Creare una subnet VM configurata per il routing diretto usando il nuovo gateway di inoltro come periferica gateway.

    1. Creare subnet separate per ogni tenant. Ad esempio:

      Subnet della rete di inoltro

  5. Posizionare le macchine virtuali tenant nelle rispettive subnet.

  6. Per isolare le macchine virtuali, usare gli elenchi di controllo di accesso estesi ed eseguire i cmdlet sull'host VMM. Configurare le porte e i protocolli necessari per le macchine virtuali tenant.

    Importante

    Prima di eseguire i cmdlet seguenti, è necessario installare il modulo PowerShell di Hyper-V sull'host VMM. Il cmdlet di PowerShell da usare a questo scopo è Install-WindowsFeature hyper-v-powershell

    Esempio:

    $vm = get-scvirtualMachine -Name "<nomecomputer>"
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn –VMName $vm.Name –Direction in  –Action Allow -Weight 15 -localport 68 -Protocol udp –Stateful $true
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 12 -RemotePort 53 -Protocol udp -Stateful $true
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 11 -LocalPort 443 -Protocol tcp -Stateful $true
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action allow -Weight 10 -LocalPort 80 -Protocol tcp -Stateful $true
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn –VMName $vm.Name –Direction in  –Action Allow -Weight 10 -localport 80 -Protocol tcp –Stateful $true
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction out -Action deny  -Weight 1
    Add-VMNetworkAdapterExtendedAcl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name -Direction in  -Action deny  -Weight 1
    

    Esempio per rimuovere gli ACL di porta da una macchina virtuale:

    $vm = get-scvirtualMachine -Name "<nomecomputer>"
    Get-VMNetworkAdapterExtendedacl -ComputerName $vm.vmhost.fqdn -VMName $vm.Name | Remove-VMNetworkAdapterExtendedAcl
    

Suggerimento per la risoluzione dei problemi

Se il gateway di inoltro appena distribuito non inoltra correttamente i pacchetti alla subnet di VM configurata per il routing diretto, verificare di nuovo di avere eseguito correttamente la procedura precedente. Se si verificano ancora problemi, assicurarsi che le interfacce front-end nel gateway di inoltro siano configurate per l'inoltro. A tale scopo, verificare quanto segue

  1. Accedere a una delle macchine virtuali del cluster guest del gateway di inoltro.

  2. Dal prompt dei comandi dell'amministratore di Windows PowerShell usare Get-NetIPInterface per esaminare le interfacce IP. Annotare il numero di ifIndex per l'interfaccia associata alla rete front-end.

  3. Usare Get-NetIPInterface –InterfaceIndex <ifindex for frontend interface> | fl, quindi esaminare il parametro Forwarding.

  4. Se il parametro Forwarding è Disabled, abilitarlo usando il comando seguente: Get-NetIPInterface –InterfaceIndex <ifindex for frontend interface> | Set-NetIpInterface –Forwarding Enabled

  5. Ripetere l'operazione per ogni nodo del cluster guest del gateway di inoltro.

  6. Ripetere il test per verificare che il gateway di inoltro stia inoltrando correttamente i pacchetti alla rete VM.

Vedere anche

Tipo di contenuto Riferimenti

Valutazione del prodotto/guida introduttiva

Guida dell'ambiente di prova: Virtualizzazione rete Hyper-V di Windows Server 2012 R2 con System Center 2012 R2 VMM

Pianificazione e progettazione

Guida alla pianificazione e progettazione di una rete multi-tenant per cloud ibrido

Microsoft System Center: Creazione di una soluzione di rete virtualizzata

Riferimento

Risorse della community

Soluzioni correlate

Tecnologie correlate