Archivi categoria: Windows Server 2016

Azure Backup Server v2 in ambiente Windows Server 2016

Azure Backup Server è una soluzione disponibile sul mercato ormai da Ottobre 2015 e nella primavera di quest’anno è stata rilasciata la seconda versione del prodotto, denominata Azure Backup Server v2 (MABS v2), che supporta l’installazione in ambiente Windows Server 2016. In realtà Azure Backup Server ha ereditato le stesse funzionalità di System Center Data Protection Manager, con la differenza sostanziale che non supporta i backup su tape. L’utilizzo di Azure Backup Server v2 implementato in Windows Server 2016 consente l’utilizzo del Modern Backup Storage che garantisce, grazie alle nuove tecnologie introdotte in Windows Server 2016, di migliorare le performance dei backup, di ridurre l’occupazione dello storage e di aumentare la resilienza e la sicurezza per quanto riguarda la protezione delle macchine virtuali. In questo articolo viene descritto come implementare Azure Backup Server v2 e riporta le indicazioni da seguire per usufruire dei benefici apportati grazie all’integrazione nativa con Windows Server 2016.

Requisiti di installazione

Il deployment di Azure Backup Server v2 (MABS v2) può essere effettuato su un server fisico standalone, su una macchina virtuale sia in ambiente Hyper-V che VMWare oppure su una macchina virtuale ospitata su Azure.

Il sistema operativo può essere Windows Server 2012 R2, ma è consigliato Windows Server 2016 per poter beneficiare dei vantaggi di Modern Backup Storage. La macchina dovrà essere in join ad un dominio Active Directory e dovrà aver la possibilità di accedere in Internet verso Microsoft Azure anche nel caso si decida di non inviare i dati protetti verso il cloud.

In merito alle specifiche hardware Microsoft consiglia quanto segue.

Processore
Minimo: 1 GHz, dual-core CPU.
Raccomandato: 2.33 GHz, quad-core CPU.

RAM
Minimo: 4 GB.
Raccomandata: 8 GB.

Spazio disco
Installazione del software: consigliato circa 8-10 GB.
Storage Pool: 1.5 volte lo spazio dei dati che si intendono proteggere.
Scratch Location: almeno il 5% dello spazio totale dei dati protetti nel cloud.

Per quanto riguarda i requisiti software è necessario installare Microsoft .Net 3.5 SP1, Microsoft .Net 4.6 e i moduli Hyper-V di Powershell.

Infine è necessario creare sulla propria subscription Azure un Recovery Service Vault, al quale verrà associato l’Azure Backup Server. Saranno richieste dal setup di installazione di Azure Backup Server le credenziali del Vault che è possibile scaricare accedendo alle proprietà dal Portale Azure:

Figura 1 – Download Backup Credentials

 

Procedura di installazione

Il download del setup di installazione di Azure Backup Server v2 può essere avviato direttamente accedendo a questa pagina Microsoft. Al termine del download dei vari file è necessario avviare l’eseguibile MicrosoftAzureBackupServerInstaller.exe per estrarre in una singola folder i binari di installazione. All’interno della folder prescelta sarà possibile eseguire il file Setup.exe per avviare la procedura di installazione in seguito documentata.

Figura 2 – Selezionare Install Microsoft Azure Backup Server

Figura 3 – Welcome page

Figura 4 – Check dei prerequisiti

Azure Backup Server richiede la presenza di una istanza Microsoft SQL Server per ospitare i relativi database. Nel caso non si abbia a disposizione una istanza esistente da utilizzare (richiesto almeno SQL Server 2014 SP1) il setup consente di installare SQL Server 2016 Service Pack 1 (versione raccomandata da Microsoft). In questo scenario non è richiesta l’acquisizione di una licenza di SQL Server purché l’istanza sia ad uso esclusivo di MABS v2.

Figura 5 – Scelta relativa all’istanza SQL Server che ospita i DB di MABS v2 e check dei requisiti

Nel caso non sia stato installato a priori il modulo Powershell di Hyper-V il setup effettuerà l’installazione, ma sarà necessario interrompere il setup di installazione per riavviare il sistema.

Figura 6 – Requisiti non soddisfatti e richiesta di riavvio per installazione modulo Powershell di Hyper-V

Figura 7 – Requisiti soddisfatti

Figura 8 – Scelta dei path di installazione

Il setup di MABS v2 crea l’account MICROSOFT$DPM$Acct locale alla macchina con cui verranno eseguiti i servizi SQL Server e SQL Server Agent e l’account DPMR$NomeServer utilizzato per la generazione della reportistica.

Figura 9 – Scelta della password per gli account MICROSOFT$DPM$Acct e DPMR$NomeServer

Figura 10 – Scelta relativa alla distribuzione degli aggiornamenti di MABS v2 tramite Windows Update

Figura 11 – Summary relativo alle scelte di installazione

A questo punto viene avviato in automatico il setup del Microsoft Azure Recovery Services (MARS) Agent necessario per la connessione verso il Recovery Service Vault presente in Microsoft Azure.

Figura 12 – Configurazione del server proxy se richiesto per accedere verso i servizi pubblici di Microsoft Azure

Figura 13 – Verifica della presenza dei requisiti necessari e installazione del MARS

Terminata l’installazione del MARS viene avviata la procedura di registrazione dell’Azure Backup Server verso il recovery Service Vault di Azure che richiede le credenziali del Backup Vault (recuperabili seguendo lo step documentato in Figura 1) e la passphrase necessaria per effettuare l’encryption dei dati salvati. Tale chiave è opportuno salvarla in un luogo sicuro in quanto è indispensabile durante le operazioni di recovery e non può essere in alcun modo recuperata dal personale di servizio Microsoft.

Figura 14 – Selezione delle credenziali del Backup Vault

Figura 15 – Passphrase per l’encryption dei backup

Al termine di questi passaggi è necessario attendere la conclusione del processo di installazione.

Figura 16 – Installazione conclusa con successo di MABS v2

Prima di procedere con la configurazione di MABS v2 si consiglia di applicare l’ultimo update disponibile per Microsoft Azure Backup Server v2 che è possibile scaricare dal sito di support Microsoft.

A questo punto è necessario configurare l’istanza SQL Server appena installata secondo le proprie esigenze ed è consigliato applicare l’ultimo Cumulative Update disponibile per SQL Server 2016 Service Pack 1.

 

Funzionalità date dall’integrazione tra MABS v2 e Windows Server 2016

Azure Backup Server v2 si integra in modo nativo con le nuove tecnologie di Windows Server 2016 grazie alle quali è possibile usufruire dei seguenti vantaggi:

  • Efficienza maggiore nell’esecuzione dei backup: utilizzando le tecnologie ReFS Block Cloning, VHDX e la Deduplica è possibile ottenere una riduzione dello storage necessario per la protezione dei dati e migliorare le performance nell’esecuzione dei backup. La configurazione del Modern Backup Storage può avvenire seguendo gli step documentati nella documentazione ufficiale, che pur riferendosi a DPM 2016 è identica anche per Azure Backup Server v2. Molto interessante anche la funzionalità Workload Aware Storage che consente di selezionare quali volumi utilizzare in base alla tipologia dei workloads protetti, avendo così la possibilità di scegliere storage più performante e di dedicarlo alle attività di backup più frequenti per le quali è bene avere elevate prestazioni.
  • Affidabilità elevata nella protezione delle macchine virtuali Hyper-V, grazie all’integrazione con la tecnologia Resilient Change Tracking (RCT) in grado di tenere traccia in modo nativo dei cambiamenti apportati alle VMs rispetto ai backup, senza la necessità di inserire filter driver specifici. Questo consente di ridurre le operazioni time-consuming per effettuare consistency checks.
  • Sicurezza: possibilità di effettuare backup e restore di Shielded VMs.

 

Costi della soluzione

Per quanto riguarda i costi della soluzione è bene specificare che è ovviamente necessario contemplare la licenza del sistema operativo della macchina su cui viene installato MABS v2. Un aspetto interessante è che per poter implementare Azure Backup Server non è richiesta alcuna licenza relativa a System Center, ma è necessario disporre di una subscription Azure. Nei costi della soluzione è necessario considerare una fee per ogni istanza protetta e l’eventuale storage occupato in Microsoft Azure. Per maggiori dettagli sui costi della soluzione è possibile consultare la pagina ufficiale Microsoft relativa al Pricing.

 

Conclusioni

Azure Backup Server v2 con il suo approccio cloud-first e grazie all’integrazione con determinate funzionalità di Windows Server 2016 si dimostra una soluzione completa e funzionale per la protezione di differenti workloads. Per coloro che utilizzano la prima release di Azure Backup Server è possibile effettuare l’upgrade a MABS v2 mantenendo tutto le impostazioni. Il consiglio è comunque di implementare MABS v2 in ambiente Windows Server 2016 in modo da disporre di una soluzione che consente di eseguire i backup con velocità superiori fino a 3 volte e di ridurre fino al 50% l’utilizzo dello storage.

Windows Server 2016: Introduzione agli Hyper-V VHD Set

In Windows Server 2016 una nuova e interessante funzionalità è stata introdotta in ambito Hyper-V ed è chiamata VHD Set. Si tratta di una nuova modalità di creazione dei dischi virtuali che necessitano di essere condivisi tra più macchine virtuali, utile per implementare guest cluster. In questo articolo verranno approfondite le caratteristiche dei VHD Set, verrà spiegato come implementarli al meglio e come affrontare in modo efficace scenari di migrazione.

Caratteristiche

La possibilità di condividere dischi virtuali tra più macchine virtuali è necessaria per realizzare configurazioni guest cluster che richiedono la presenza di storage condiviso e per evitare di dover configurare l’accesso allo storage tramite ad esempio HBA virtuali oppure attraverso l’utilizzo del protocollo di comunicazione iSCSI.

Figura 1 – VHD Set

In ambito Hyper-V questa funzionalità è stata introdotta con Windows Server 2012 R2 con la tecnologia chiamata Shared VHDX, la quale presenta i seguenti importanti limiti che spesso ne impediscono l’utilizzo in ambiente di produzione:

  • Il backup degli Shared VHDX deve avvenire con agenti specifici e non è supportato il backup host based
  • Non sono supportati scenari di replica Hyper-V
  • Il resize online di Shared VHDX non è contemplato

Con Hyper-V in Windows Server 2016 è stata rivoluzionata questa funzionalità con l’introduzione dei VHD Set al posto degli Shared VHDX che rimuove le limitazioni sopra elencate rendendola una tecnologia matura e affidabile anche per gli ambienti di produzione. Infatti le macchine virtuali configurate per accedere ai VHD Set è possibile proteggerle tramite backup host based, senza dover installare agenti sulle macchine guest. In questo caso è comunque consigliata una verifica per stabilire se la soluzione di backup in uso supporta questa configurazione. Inoltre i dischi nel formato VHD Set supportano il ridimensionamento online, senza la necessità di dover fermare il guest cluster configurato per accederci. Anche la replica Hyper-V supporta i dischi nel formato VHD Set consentendo di implementare scenari di disaster recovery anche per configurazioni guest cluster.

Al momento le uniche limitazioni nell’utilizzo dei VHD Set sono date dal mancato supporto per la creazione di checkpoint delle macchine virtuali che ci accedono e dall’impossibilità di effettuare delle storage live migration di macchine virtuali con VHD Set. L’obiettivo di Microsoft per il futuro è comunque di rendere le macchine virtuali configurate con VHD Set paritetiche a tutte le altre in termini di funzionalità.

Requisiti per l’utilizzo di VHD Set

Il formato VHD Set è supportato solamente per sistemi operativi guest Windows Server 2016. Inoltre per poter configurare guest cluster dove le macchine virtuali accedono a dischi virtuali condivisi è necessario rientrare in uno dei seguenti scenari:

  • Hyper-V failover cluster con tutti i file delle VMs, compresi i dischi nel formato VHD Set, che risiedono su un Cluster Shared Volumes (CSV).
  • Hyper-V failover cluster che ha come storage location per i VHD Set una share SMB 3.0 erogata da uno Scale Out File Server (SOFS).

Figura 2 – Scenari supportati per l’utilizzo di dischi virtuali condivisi

Come Creare VHD Set

La creazione di dischi virtuali nel formato VHD Set può essere fatta sia da interfaccia grafica (GUI) che tramite Powershell. Per crearli tramite GUI è sufficiente aprire Hyper-V Manager e dal riquadro Actions selezionare New, Hard Disk. Tra i possibili formati sarà presente anche VHD Set come mostrato nella figura seguente:

Figura 3 – Selezione del formato nel wizard di creazione dei dischi virtuali

Proseguendo con il Wizard è possibile specificare se il disco deve essere di tipologia Fixed piuttosto che Dynamic, il nome, la location e la relativa dimensione nel caso si scelga di creare un nuovo disco blank. La stessa operazione può essere svolta anche utilizzando il cmdlet Powershell New-VHD, specificando come estensione del disco virtuale la nuova estensione .vhds, come mostrato dall’esempio seguente:

Figura 4 – Esempio di creazione di un disco nel formato VHD Set utilizzando Powershell

La creazione del disco nel formato VHD Set comporta la creazione nel percorso specificato dei seguenti file:

Figura 5 – File generati dalla creazione di un disco nel formato VHD Set

Il file con estensione .avhdx contiene i dati e può essere fixed o dynamic in base alla scelta fatta durante la creazione, mentre il file .vhds contiene i metadati necessari per coordinare l’accesso dai differenti nodi del guest cluster.

Configurazione delle Macchine Virtuali con Dischi VHD Set

Per poter aggiungere i dischi nel formato VHD Set alle macchine virtuali è sufficiente modificare le proprietà delle stesse e configurare in modo opportuno il collegamento al controller SCSI:

Figura 6 – Aggiunta dello Shared Drive nelle proprietà della VM

Successivamente è necessario selezionare la location del file:

Figura 7 – Configurazione della location del drive condiviso

La stessa operazione sarà necessario svolgerla per tutte le macchine virtuali che costituiranno il guest cluster. In seguito alla configurazione dello storage condiviso, che comporta l’aggiunta alle macchine virtuali dei dischi nel formato VHS Set, è possibile proseguire con la configurazione dell’ambiente guest cluster secondo la procedura standard di creazione di un cluster descritta nella documentazione ufficiale Microsoft.

Conversione di Shared VHDX in VHD Set

In scenari di aggiornamento dell’infrastruttura Hyper-V da Windows Server 2012 R2 a Windows Server 2016, può capitare di dover affrontare la migrazione di Shared VHDX in VHD Set per poter usufruire di tutti i vantaggi apportati nella nuova tecnologia di condivisione dei dischi virtuali. Il passaggio a Windows Server 2016 non comporta nessun aggiornamento automatico degli Shared VHDX in VHD Set ed è comunque consentito continuare ad utilizzare i dischi condivisi nel formato Shared VHDX anche in Windows Server 2016. Per poter migrare gli Shared VHDX nel formato VHD Set è necessario seguire la seguente procedura manuale:

  • Spegnere tutte le macchine virtuali connesse allo Shared VHDX che si intende migrare.
  • Scollegare lo Shared VHDX da tutte le VMs tramite il cmdlet Powershell Remove-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
  • Avviare la conversione dello Shared VHDX nel formato VHD Set tramite il cmdlet Powershell Convert-VHD
  • Collegare il disco appena convertito nel formato VHD Set a tutte le VMs utilizzando il cmdlet Powershell Add-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
  • Accendere le macchine virtuali connesse al VHD Set.

Quando si utilizzano dischi nel formato VHD Set possono essere utili i seguenti cmdlet Powershell:

  • Get-VHDSet: utile per visualizzare diverse informazioni relative al disco nel formato VHD Set, compresa la lista di eventuali checkpoint.
  • Optimize-VHDSet: necessario per ottimizzare l’allocazione dello spazio utilizzato dal disco nel formato VHD Set.

Conclusioni

In Windows Server 2016 l’introduzione dei VHD Set in ambito Hyper-V consente di implementare in modo semplice architetture guest cluster senza dover utilizzare tecnologie di condivisione dello storage che richiedono configurazioni più laboriose e complesse. Inoltre sono state rimosse buona parte delle limitazioni riguardanti la metodologia di condivisione dei dischi virtuali, presenti nella precedente versione di Hyper-V, rendendo VHD Set una tecnologia matura, affidabile e di conseguenza utilizzabile anche in ambienti di produzione.

OMS Log Analytics: come effettuare il monitor del networking di Azure

All’interno di Log Analytics c’è la possibilità di abilitare delle solution specifiche che consentono di effettuare il monitor di alcuni componenti dell’infrastruttura di rete presente in Microsoft Azure.

Tra queste solution troviamo Network Performance Monitor (NPM) la quale è stata approfondita nell’articolo Monitorare le performance di rete con la nuova solution di OMS e che si presta molto bene anche per monitorare lo stato di salute, la disponibilità e la raggiungibilità del networking di Azure. Sono inoltre attualmente disponibili nella gallery di Operations Management Suite le seguenti solution che arricchiscono le potenzialità di monitoring lato OMS:

  • Azure Application Gateway Analytics
  • Azure Network Security Group Analytics

Abilitazione delle Solution

Accedendo al portale OMS è possibile aggiungere facilmente queste solution presenti nella gallery seguendo gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS).

Figura 1 – Solution Azure Application Gateway Analytics

Figura 2 – Solution Azure Network Security Group Analytics

Azure Application Gateway Analytics

L’Azure Application Gateway è un servizio che è possibile configurare in ambiente Azure in grado di fornire funzionalità di Application Delivery garantendo un bilanciamento applicativo layer 7. Per ottenere maggiori informazioni relative all’Azure Application Gateway è possibile consultare la documentazione ufficiale.

Per poter collezionare i log di diagnostica in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Application Gateway che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 3 – Application Gateway Diagnostics settings

Per l’Application Gateway è possibile selezionare la raccolta dei seguenti log:

  • Log relativi agli accessi effettuati
  • Dati di performance
  • Firewall log (nel caso l’Application Gateway abbia il Web Application Firewall abilitato)

Dopo aver completato questi semplici passaggi la solution OMS installata consente di consultare facilmente i dati inviati dalla platform:

Figura 4 – Azure Application Gateway Analytics Overview nel portale OMS

All’interno della solution è possibile visualizzare un sommario delle informazioni raccolte e selezionando i singoli grafici si accede ai dettagli relativi alle categorie seguenti:

  • Application Gateway Access log
    • Errori client e server riscontrati nei log di accesso dell’Application Gateway
    • Richieste ricevute dall’Application Gateway per ora
    • Richieste fallite per ora
    • Errori rilevati per user agent

Figura 5 – Application Gateway Access log

  • Application Gateway performance
    • Stato di salute degli host che rispondono alle richieste dell’Application Gateway
    • Richieste fallite dell’Application Gateway espresso come numero massimo e con il 95° percentile

Figura 6 – Application Gateway performance

  • Application Gateway Firewall log

 

Azure Network Security Group Analytics

In Azure è possibile controllare le comunicazioni di rete tramite i Network Security Group (NSG) i quali aggregano una serie di regole (ACL) per consentire oppure negare il traffico di rete basandosi sulla direzione (in ingresso o in uscita), il protocollo, l’indirizzo e la porta sorgente oppure l’indirizzo e la porta di destinazione. I NSG vengono utilizzati per controllare e proteggere le virtual network oppure direttamente le interfacce di rete. Per tutti i dettagli relativi ai NSG è possibile consultare la documentazione ufficiale Microsoft.

Per poter collezionare i log di diagnostica dei Network Security Group in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Network Security Group che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 7 – Abilitazione diagnostica NSG

Figura 8 – Configurazione diagnostica NSG

Sui Network Security Group è possibile raccogliere le seguenti tipologie di log:

  • Eventi
  • Contatori relativi alle rule

Giunti a questo punto nell’home page del portale OMS è possibile selezionare il tile di Overview della solution Azure Network Security Group Analytics per accedere ai dati dei NSG raccolti dalla platform:

Figura 9 – Azure Network Security Group Analytics Overview nel portale OMS

La solution mette a disposizione un summary dei log raccolti suddividendoli nelle seguenti categorie:

  • Network security group blocked flows
    • Regole del Network Security Group con traffico bloccato
    • Indirizzamenti di rete con regole di traffico bloccato

Figura 10 – Network security group blocked flows

  • Network security group allowed flows
    • Regole del Network security group con traffico consentito
    • Indirizzamenti di rete con regole di traffico consentito

Figura 11 – Network security group allowed flows

La metodologia di invio dei log di diagnostica degli Application Gateway e dei Network Security Group di Azure verso Log Analytics è cambiata recentemente introducendo i seguenti vantaggi:

  • La scrittura dei log in Log Analytics avviene direttamente senza la necessità di utilizzare degli storage account come repository. Si può comunque scegliere di salvare i log di diagnostica sugli storage account, ma non è necessario per l’invio dei dati verso OMS.
  • La latenza tra il tempo di generazione dei log e la loro consultabilità in Log Analytics è stata ridotta.
  • Sono stati semplificati gli step necessari per la configurazione.
  • Tutti le informazioni di diagnostica di Azure sono state uniformate come formato.

Conclusioni

Grazie a una sempre più completa integrazione tra Azure e Operations Management Suite (OMS) è possibile monitorare e controllare lo stato dei componenti dell’infrastruttura di rete realizzata su Azure in modo completo ed efficace, il tutto con passaggi semplici e intuitivi. Questa integrazione della platform Azure con OMS è sicuramente destinata ad arricchirsi con nuove soluzioni specifiche anche per altri componenti. Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente.

Windows Server 2016: Configurazione del Cloud Witness in ambito Failover Cluster

Nell’articolo Windows Server 2016: What’s New in Failover Clustering sono state approfondite tutte le principali novità introdotte con Windows Server 2016 in ambito failover clustering. In questo articolo entreremo del dettaglio della configurazione del witness del cluster nel cloud Microsoft Azure, analizzando i possibili scenari supportati e i benefici di questa nuova funzionalità.

 

Possibili scenari supportati dal Cloud Witness

Tra gli scenari supportati che si prestano maggiormente per questo tipo di configurazione troviamo:

  • Multi-site stretched cluster.
  • Failover Cluster che non necessitano di storage condiviso (SQL Always On, Exchange DAGs, etc).
  • Failover Cluster composti da nodi ospitati su Microsoft Azure, altri cloud pubblici oppure in private cloud.
  • Cluster di tipologia Scale-out File Server.
  • Cluster realizzati in realtà small branch-office.

 

Configurazione del Cloud Witness

Iniziamo con il specificare che un requisito necessario per poter configurare il cluster per l’utilizzo del Cloud Witness è che tutti i nodi che compongono il cluster abbiano un accesso internet verso Azure. Il Cloud Witness infatti utilizza il protocollo HTTPS (porta 443) per stabilire una connessione con il servizio blob dell’Azure Storage Account.

 

La configurazione del Cloud Witness richiede la presenza di una subscription Azure all’interno della quale configurare uno Storage Account che sarà utilizzato come Cloud Witness e sul quale saranno scritti i blob file utilizzati per l’arbitration del cluster.

 

Dal portale Azure è necessario creare uno storage account di tipologia Genaral Purpose. Per questo scopo è corretto crearlo con un livello di performance standard in quanto non sono necessarie elevate prestazioni che vengono fornite con l’utilizzo di dischi SSD. Dopo aver selezionato la policy di replica e la location più opportuna si può procedere con il processo di creazione.

 

Figura 1 – Creazione dello Storage Account

 

Dopo aver creato lo storage account è necessario recuperare la relativa chiave di accesso necessaria per l’autenticazione, che verrà richiesta negli step successivi di configurazione.

 

Figura 2 – Chiavi di accesso dello Storage Account

 

Giunti a questo punto è possibile modificare le impostazioni del Quorum del cluster da Failover Cluster Manager seguendo i passaggi sotto riportati:

 

Figura 3 – Configurazione delle impostazioni Quorum da Failover Cluster Manager

 

Figura 4 – Selezione del Quorum Witness

 

Figura 5 – Selezione del Cloud Witness

 

Figura 6 – Nome e chiave di accesso dello Storage Account

 

Al termine della configurazione sarà presente tra le varie risorse del cluster anche il Cloud Witness:

 

Figura 7 – Risorsa Cloud Witness

 

Sullo Storage Account di Azure viene creato un container denominato msft-cloud-witness, all’interno del quale sarà presente un unico blob file che ha come nome l’ID univo del cluster. Questo comporta che è possibile utilizzare lo stesso Microsoft Azure Storage Account per configurare il Cloud Witness su cluster differenti, dove sarà presente un blob file per ogni cluster.

 

Figura 8 – Container presente all’interno dello Storage Account e relativo contenuto

 

Vantaggi nell’utilizzo del Cloud Witness

L’utilizzo del Cloud Witness consente di ottenere i seguenti vantaggi:

  • Viene eliminata la necessità di disporre di un ulteriore data center separato per determinate configurazioni cluster utilizzando invece Microsoft Azure.
  • Viene annullato l’effort amministrativo necessario per mantenere una macchina virtuale aggiuntiva con il ruolo di witness del cluster.
  • Considerata la quantità ridotta di dati scritti sullo Storage Account il costo del servizio è irrisorio.
  • Lo stesso Microsoft Azure Storage Account può essere utilizzato come witness per cluster differenti.

 

Conclusioni

Anche in ambito failover cluster Windows Server 2016 si dimostra pronto per l’integrazione con il cloud. Grazie all’introduzione del cloud Witness è possibile realizzare più facilmente sistemi cluster riducendo sensibilmente i costi complessivi per l’implementazione, l’effort di gestione e aumentando la flessibilità dell’architettura cluster.

Windows Server 2016: What’s New in Failover Clustering

Molto frequentemente per poter garantire l’alta disponibilità e la business continuity per applicazioni e servizi critici è necessario implementare un Failover Cluster in ambiente Microsoft. In questo articolo approfondiremo le principali novità introdotte con Windows Server 2016 in ambito failover clustering e analizzeremo i vantaggi nell’adottare la più recente tecnologia.

Cluster Operating System Rolling Upgrade

In Windows Server 2016 è stata introdotta una importante funzionalità che consente di aggiornare i nodi di un cluster Hyper-V oppure di uno Scale-Out File Server da Windows Server 2012 R2 a Windows Server 2016 senza nessun disservizio ed evitando di fermare i workload da esso ospitati.

Il processo di aggiornamento prevede questi step:

  • Mettere il nodo che si vuole aggiornare in pausa e spostare tutte le machine virtuali oppure gli altri workload sugli altri nodi del cluster
  • Rimuovere il singolo nodo dal cluster ed effettuare un’installazione pulita di Windows Server 2016
  • Aggiungere il nodo Windows Server 2016 al cluster esistente. Da questo momento il cluster entrerà in modalità Mixed con nodi sia Windows Server 2012 R2 che nodi Windows Server 2016. A questo proposito è bene specificare che il cluster continuerà ad erogare i servizi in modalità Windows Server 2012 R2 e non saranno ancora disponibili le funzionalità introdotte in Windows Server 2016. In questa fase sarà possibile aggiungere e rimuovere nodi sia Windows Server 2012 R2 che nodi Windows Server 2016
  • Procedere con l’aggiornamento di tutti i nodi del cluster nella stessa modalità precedentemente descritta
  • Solo quando tutti i nodi del cluster saranno stati aggiornati a Windows Server 2016 sarà possibile cambiare il functional level del cluster portandolo a Windows Server 2016. Tale operazione non è reversibile e per portarla a termine è necessario utilizzare il cmdlet PowerShell Update-ClusterFunctionalLevel. Dopo aver eseguito tale comando sarà possibile sfruttare tutti i vantaggi introdotti in Windows Server 2016 di seguito riportati

Cloud Witness

Windows Server 2016 introduce la possibilità di configurare il witness del cluster direttamente nel cloud Microsoft Azure. Il Cloud Witness, esattamente come per le alte tipologie di witness, fornirà un voto arbitrario partecipando al calcolo del quorum.


Figura 1 – Cloud Witness in Failover Cluster Manager

La configurazione del Cloud Witness prevede due semplici passaggi:

  • Creazione su una subscription Azure di un Azure Storage Account che sarà utilizzato dal Cloud Witness
  • Configurazione del Cloud Witness in una delle seguenti modalità

PowerShell

Failover Cluster Manager


Figura 2 – Configurazione Cloud Witness Step 1


Figura 3 – Configurazione Cloud Witness Step 2

 


Figura 4 – Configurazione Cloud Witness Step 3

L’utilizzo del Cloud Witness consente di ottenere i seguenti vantaggi:

  • Sfrutta Microsoft Azure eliminando così la necessità di disporre di un ulteriore data center separato per determinate configurazioni cluster
  • Utilizza direttamente un Microsoft Azure Blob Storage annullando in questo modo l’effort amministrativo necessario per mantenere una macchina virtuale in una cloud pubblica
  • Lo stesso Microsoft Azure Storage Account può essere utilizzato per più cluster
  • Vista la mole ridotta di dati scritti sullo Storage Account il costo del servizio è irrisorio

Site-Aware Failover Clusters

Windows Server 2016 introduce il concetto di failover cluster site-aware ed è in grado di raggruppare gruppi di nodi in una configurazione stretched cluster in base alla location geografica (site).  Durante il ciclo di vita di un cluster site-aware le policy di placement, l’heartbeat tra i nodi e le operazioni di failover e di calcolo del quorum sono pensate e migliorate per questa specifica configurazione dell’ambiente cluster. Per maggiori dettagli a riguardo vi invito a consultare l’articolo Site-aware Failover Clusters in Windows Server 2016.

Workgroup e Multi-domain Cluster

In Windows Server 2012 R2 e nelle precedenti versioni di Windows tutti i nodi di un cluster dovevano necessariamente appartenere allo stesso dominio Active Directory. Con Windows Server 2016 vengono rimosse queste barriere e viene fornita la possibilità di creare un Failover Cluster senza dipendenze da Active Directory.

In Windows Server 2016 sono supportate le seguenti configurazioni:

  • Single-domain Cluster: cluster dove tutti i nodi appartengono allo stesso dominio
  • Multi-domain Cluster: cluster composto da nodi in join a domini Active Directory differenti
  • Workgroup Cluster: cluster con nodi in workgroup (non in join a un dominio)

A tal proposito è bene specificare quali sono i workload supportati e le relative limitazioni per i Multi-domain e Workgroup cluster:

 Cluster Workload

 Supporto

DettagliMotivazione
SQL Server

Supportato

Raccomandato l’utilizzo dell’autenticazione SQL Server.
File Server

Supportato, ma non raccomandato

L’autenticazione Kerberos (non disponibile in questi ambienti) è il protocollo di autenticazione consigliato per il traffico Server Message Block (SMB).
Hyper-V

Supportato, ma non raccomandato

Non è supportata la Live Migration, ma solo la Quick Migration.
Message Queuing (MSMQ)

Non supportato

Message Queuing salva proprietà in AD DS.

Diagnostic in Failover Clustering

In Windows Server 2016 sono state introdotte le seguenti novità per facilitare le operazioni di troubleshooting nel caso dovessero emergere problematiche relative all’ambiente cluster:

SMB Multichannel e Multi-NIC Cluster Network

In Windows Server 2016 diverse sono le novità introdotte anche in ambito network per quanto riguarda l’ambiente cluster che consentono di facilitare la configurazione e di ottenere maggiori performance.

I benefici principali introdotti in Windows Server 2016 possono essere sintetizzati nei seguenti punti:

  • SMB Multichannel viene abilitato di default
  • Il failover cluster è in grado di riconoscere in automatico le NIC attestate sulla stessa subnet stesso switch
  • Una singola risorsa IP Address viene configurata per ogni Cluster Access Point (CAP) Network Name (NN)
  • Le network con solo indirizzi IPv6 Link Local (fe80) sono riconosciute come reti private (cluster only)
  • Il cluster validation non riporta più messaggi di warning nel caso siano presenti più NIC attestate sulla stessa subnet

Per maggiori informazioni a riguardo vi rimando alla documentazione Microsoft: Simplified SMB Multichannel and Multi-NIC Cluster Networks.

Conclusioni

Windows Server 2016 introduce importanti cambiamenti anche in ambito Failover Clustering rendendo la soluzione maggiormente flessibile e aprendo nuovi possibili scenari di configurazione. Inoltre il processo di upgrade ci consente di aggiornare facilmente ambienti cluster già esistenti per beneficiare di tutti i vantaggi introdotti da Windows Server 2016 per i differenti workload.

Windows Server 2016: La nuova modalità di creazione dei Virtual Switch in Hyper-V

In questo articolo approfondiremo le caratteristiche e vedremo come configurare un Virtual Switch di Hyper-V in Windows Server 2016 nella modalità Switch Embedded Teaming (SET). Si tratta di una nuova tecnologia, alternativa al NIC Teaming, che consente di avere più schede di rete dell’host fisico di virtualizzazione in join allo stesso Virtual Switch di Hyper-V.

Con Windows Server 2012 era stata introdotta la possibilità di creare in modo nativo dal sistema operativo un teaming di rete (fino a un massimo di 32 schede di rete) senza dover installare software specifici dei vendor. Sugli host di virtualizzazione era pratica comune definire dei virtual switch di Hyper-V attestandoli su questi NIC teaming. Per avere quindi alta disponibilità e bilanciare il traffico di rete delle macchine virtuali era necessario unificare questi due differenti costrutti, il Team di rete e il Virtual Switch di Hyper-V. Utilizzando questa configurazione è opportuno specificare che il teaming tradizione LBFO (Load Balancer Fail Over) non era compatibile con la tecnologia RDMA.

In Windows Server 2016 è stata introdotta una ulteriore possibilità per quanto riguarda la configurazione dei Virtual Switch di Hyper-V chiamata Switch Embedded Teaming (SET), figura 1, la quale consente di unificare più schede di rete (fino a un massimo di 8) in un unico Virtual Switch senza configurare nessun teaming. SET ingloba infatti le funzionalità di teaming di rete all’interno del Virtual Switch consentendo di ottenere elevate performance e fault tolerance a fronte di guasti hardware delle singole NIC. In questa configurazione c’è la possibilità di abilitare la tecnologia RDMA sulle singole schede di rete e di conseguenza viene a decadere la necessità di avere set di NIC separati (uno per l’utilizzo con i Virtual Switch e uno per utilizzare la tecnologia RDMA).

2016_12_16_virtualswitch-01
Figura 1 – Architettura SET

Quando si valuta l’adozione della modalità Switch Embedded Teaming (SET) è importante considerare le compatibilità con le altre tecnologie relative al networking.

SET risulta compatibile con:

  • Datacenter bridging (DCB)
  • Hyper-V Network Virtualization sia in modalità NVGRE che VxLAN
  • Receive-side Checksum offloads (IPv4, IPv6, TCP) – Se supportato dal modello hardware delle NIC
  • Remote Direct Memory Access (RDMA)
  • SDN Quality of Service (QoS)
  • Transmit-side Checksum offloads (IPv4, IPv6, TCP) – Se supportato dal modello hardware delle NIC
  • Virtual Machine Queues (VMQ)
  • Virtual Receive Side Scalaing (RSS)

SET risulta invece non compatibile con le seguenti tecnologie di rete:

  • 1X authentication
  • IPsec Task Offload (IPsecTO)
  • QoS (implementato lato host)
  • Receive side coalescing (RSC)
  • Receive side scaling (RSS)
  • Single root I/O virtualization (SR-IOV)
  • TCP Chimney Offload
  • Virtual Machine QoS (VM-QoS)

 

Differenze rispetto al NIC Teaming

Switch Embedded Teaming (SET) si differenzia dal tradizionale NIC Teaming in particolare per i seguenti aspetti:

  • Quando si fa un deployment di SET non è supportato utilizzare NIC in modalità standby, ma tutte le schede di rete devono essere attive;
  • Non è possibile assegnare un nome specifico al team, ma solamente al Virtual Switch;
  • SET supporta solamente la modalità Switch Independent, mentre il NIC teaming ha diverse modalità di funzionamento. Questo significa che gli switch di rete, dove le NIC che appartengono a SET vengono attestate, non sono a conoscenza della presenza di questa configurazione e di conseguenza non introducono nessun controllo su come distribuire il traffico di rete tra i differenti membri.

In fase di configurazione di SET è necessario solamente specificare quali schede di rete appartengono al team e il meccanismo di bilanciamento del traffico.

Un Virtual Switch in modalità SET deve essere composto da schede di rete certificate da Microsoft che hanno superato i test di compatibilità “Windows Hardware Qualification and Logo (WHQL)“ per Windows Server 2016. Un aspetto importante è che le NIC devono essere identiche in termini di marca, modello, driver e firmware.

Per quanto riguarda come viene distribuito il traffico di rete tra i differenti membri di SET sono disponibili due modalità: Hyper-V Port e Dynamic.

Hyper-V Port

In questa configurazione il traffico di rete viene suddiviso tra i diversi membri del team in base all’associazione porta del virtual switch e MAC address della macchina virtuale connessa. Questa modalità è particolarmente adatta quando si utilizza in congiunzione alla tecnologia Virtual Machine Queues (VMQs). Bisogna inoltre considerare che nel caso in cui siano presenti poche macchine virtuali sull’host di virtualizzazione si potrebbe non avere un bilanciamento omogeneo del traffico essendo un meccanismo poco granulare. In questa modalità inoltre la banda disponibile per una scheda di rete di una macchina virtuale (con il traffico proveniente quindi sempre da una singola porta dello switch) è sempre limitata alla banda disponibile sulla singola interfaccia di rete.

Dynamic

Questo meccanismo di load balancing ha le seguenti caratteristiche:

  • Il traffico in uscita viene distribuito (sulla base di un hash porte TCP e indirizzi IP) secondo il principio denominato flowlets (basato sulle interruzioni presenti nei flussi delle comunicazioni TCP). Inoltre in modalità Dynamic è presente un meccanismo di ri-bilanciamento del traffico in real time tra i vari membri di SET.
  • Il traffico in ingresso invece viene distribuito esattamente come nella modalità Hyper-V Port.

Per quanto riguarda la configurazione di SET così come per tutti i componenti appartenenti al software-defined networking (SDN) è consigliato adottare System Center Virtual Machine Manager (VMM). Nella configurazione del Logical Switch è sufficiente selezionare “Embedded” nell’Uplink Mode così come viene mostrato nella figura 2.

2016_12_16_virtualswitch-02
Figura 2 – Configurazione SET in VMM

Come alternativa per la configurazione di SET è possibile utilizzare i seguenti comandi PowerShell:

Creazione Virtual Switch in modalità SET

2016_12_16_virtualswitch-03

Il parametro EnableEmbeddedTeaming per la creazione di un team SET è opzionale nel caso siano elencate più schede di rete, ma risulta utile quando si vuole configurare un Virtual Switch in questa modalità con una singola scheda di rete per essere esteso con ulteriori NIC successivamente.

Modifica dell’algoritmo di distribuzione del traffico

2016_12_16_virtualswitch-04

Conclusioni

Grazie a questo nuovo meccanismo di creazione dei Virtual Switch introdotto in Hyper-V 2016 è possibile avere una maggiore flessibilità nella gestione del networking riducendo il numero di schede di rete e la complessità di configurazione, senza rinunciare ad elevate performance e all’alta disponibilità.

Windows Server 2016: What’s New in Hyper-V

Windows Server 2016 è stato ufficialmente rilasciato e molte sono le novità introdotte relative ad Hyper-V che lo rendono sempre più una potente piattaforma di virtualizzazione ricca di nuove e interessanti funzionalità. In questo articolo verranno riportate le nuove funzionalità di Hyper-V in Windows Server 2016 e verranno approfonditi i cambiamenti apportati rispetto alla precedente versione.

Nested Virtualization

Questa funzionalità consente di avere una macchina virtuale con il ruolo di Hyper-V e di conseguenze di poter ospitare su di essa altre machine virtuali. Si tratta di una funzionalità utile per ambienti di test e sviluppo, ma non è idonea per essere utilizzata in ambienti di produzione. Per poter utilizzare la nested virtualization devono essere rispettati i seguenti requisiti:

  • La macchina virtuale con il ruolo di Hyper-V deve avere almeno 4 GB di RAM
  • Le macchine virtuali guest devono anch’esse essere Windows Server 2016
  • Al momento la nested virtualization è disponibile solo se l’host fisico che detiene la VM con il ruolo Hyper-V ha processori Intel (VT-x e tecnologia EPT).

Per approfondimenti in merito potete consultare l’articolo Windows Server 2016: Introduzione ad Hyper-V Nested Virtualization a cura di Silvio Di Benedetto oppure il documento Microsoft riguardante la Nested Virtualization.

Networking Features

Anche in ambito networking sono state introdotte importanti novità che consentono di sfruttare al meglio l’hardware ed avere maggiori performance:

  • Remote direct memory access (RDMA) e switch embedded teaming (SET). Switch Embedded Teaming (SET) è una nuova tecnologia alternativa al NIC Teaming che consente di avere più schede di rete in join allo stesso Virtual Switch di Hyper-V. Prima di Windows Server 2016 era necessario avere set di NIC separati (uno per l’utilizzo con i Virtual Switch e uno per sfruttare RDMA) in quanto il teaming del SO non era compatibile con la tecnologia RDMA. In Windows Server 2016 c’è la possibilità di abilitare RDMA sulle schede di rete che sono associate ad un Virtual Switch configurato con oppure senza la modalità Switch Embedded Teaming (SET)
  • Virtual machine multi queues (VMMQ). Miglioramento sul VMQ throughput grazie alla possibilità di allocare più hardware queues per singola macchina virtuale
  • Quality of service (QoS) per software-defined networks

Hot add and remove for network adapters and memory

Per le machine virtuali di generazione 2 con sistema operativo sia Windows che Linux è possibile aggiungere o rimuovere schede di rete mentre la macchina virtuale è in esecuzione, senza nessun fermo. Inoltre per le macchine virtuali sia di generazione 1 che di generazione 2, ma con sistema operativo Windows Server 2016 o Windows 10 è possibile modificare la quantità di memoria RAM ad essa assegnata mentre è in esecuzione, anche se non è abilitata la memoria dinamica.

Rolling Hyper-V Cluster Upgrade

Importanti sono le novità anche in ambito cluster. Viene fornita la possibilità di aggiungere un nodo Windows Server 2016 a un cluster Hyper-V già esistente costituito da nodi Windows Server 2012 R2. Questo ci consente di aggiornare i sistemi cluster senza avere nessun downtime. Fintanto che tutti i nodi del cluster non vengono aggiornati a Windows Server 2016 il cluster rimane con le funzionalità di Windows Server 2012 R2. Al termine del processo di aggiornamento dei vari nodi del cluster è necessario aggiornare il livello di funzionalità tramite il cmdlet Powershell Update-ClusterFunctionalLevel.

Start Order Priority for Clustered Virtual Machines

Grazie a questa funzionalità si riesce ad ottenere un maggiore controllo sulla priorità di avvio delle machine virtuali in ambiente cluster. Questo può risultare utile per avviare macchine virtuali che forniscono servizi prima di avviarne altre che usufruiscono di questi servizi. Il tutto è facilmente ottenibile configurando dei set, assegnando le macchine virtuali ai vari set e definendo delle dipendenze.

Production Checkpoints

La creazione dei production checkpoint si basa su tecnologie di backup presenti all’interno della macchina virtuale anziché sullo stato di save (save state di Hyper-V). Per le macchine basate su sistema operativo Windows viene utilizzata la tecnologia Volume Snapshot Service (VSS), mentre per le macchine virtuali Linux viene effettuato un flush dei diversi buffer del file system per creare un checkpoint che è consistente a livello di file system. I Production checkpoint sono il default per le nuove macchine virtuali, ma c’è sempre la possibilità di creare i checkpoint basati sullo stato di save della macchina virtuale, denominati ora standard checkpoint.

Host Resource Protection

Questa funzionalità aiuta a prevenire condizioni dove le operazioni svolte da una singola macchina virtuale possono degradare le performance dell’host Hyper-V o di altre machine virtuali. Quando questo meccanismo di monitoring rileva una macchina virtuale con una attività eccessiva a questa vengono ridotte le risorse assegnate. Di default questo meccanismo di controllo è disabilitato ed è possibile attivarlo utilizzando il seguente comando Powershell: Set-VMProcessor -EnableHostResourceProtection $true

Shielded Virtual Machines

Le Shielded virtual machines, aggregando diverse funzionalità, rendono molto più difficili tutte quelle attività che possono essere fatte da malware oppure dagli amministratori stessi di Hyper-V per effettuare l’inspect, la manomissione e l’acquisizione impropria dei dati.  I dati e lo stato delle Shielded virtual machines sono criptati e agli amministratori di Hyper-V non è consentito visualizzare l’output video e i dati contenuti nei dischi virtuali. Queste macchine virtuali possono essere eseguite esclusivamente su specifici host Hyper-V definiti e in stato di salute secondo le policy impartite dall’Host Guardian Server. Le shielded virtual machines sono compatibile con la funzionalità di Hyper-V Replica. Per attivare la replica è necessario che venga autorizzato l’host Hyper-V sul quale si vogliono replicare le shielded virtual machine. Per maggiori dettagli relativi a queste nuove funzionalità è possibile consultare il documento Guarded Fabric and Shielded VMs.

Virtualization-based Security for Generation 2 Virtual Machines

Nuove funzionalità in termini di sicurezza sono state introdotte per le machine virtuali generation 2 (a partire dalla versione 8 del file di configurazione) come Device Guard e Credential Guard, che sono in grado di aumentare la protezione del sistema operativo da attacchi malware.

Encryption Support for the Operating System Disk in Generation 1 Virtual Machines

Ora c’è la possibilità di proteggere i dischi del sistema operativo utilizzando BitLocker anche per le machine virtuali di generazione 1. Grazie alla nuova funzionalità Key Storage (richiede almeno la versione 8 del file di configurazione) viene creato un piccolo drive dedicato ad ospitare le chiavi utilizzate da BitLocker anziché utilizzare un Trusted Platform Module (TPM) virtuale che è disponibile solo per le macchine virtuali di generazione 2.

Linux Secure Boot

Le machine virtuali di generazione 2 basate su sistema operativo Linux possono effettuare il boot utilizzando l’opzione Secure Boot. Sono abilitate al Secure Boot su host Windows Server 2016 le seguenti distribuzioni Linux:

  • Ubuntu 14.04 +
  • SUSE Linux Enterprise Server 12 +
  • Red Hat Enterprise Linux 7.0 +
  • CentOS 7.0 +

Windows PowerShell Direct

Si tratta di un nuovo metodo per eseguire comandi Windows PowerShell in una macchina virtuale impartendoli direttamente dall’host, senza richiedere un accesso via network e indipendentemente dalla configurazione dei tool di gestione remoti. Windows PowerShell Direct è quindi un’ottima alternative ai tool attualmente utilizzati dagli amministratori di Hyper-V come PowerShell, Remote Desktop oppure Hyper-V Virtual Machine Connection (VMConnect) ed offre un’ottima experience in ambito scripting e automation (difficile ad esempio da ottenere con VMConnect).

Compatible with Connected Standby

Quando il ruolo Hyper-V viene abilitato su un sistema che utilizza come power model Always On/Always Connected (AOAC) è ora disponibile come power state Connected Standby.

Discrete Device Assignment

Questa interessante funzionalità consente di fornire a una macchina virtuale un accesso diretto ed esclusivo ad alcune device harware PCIe. Utilizzando un device in questa modalità viene bypassato l’intero stack di virtualizzazione Hyper-V garantendo così un accesso più rapido all’harware. Per avere maggiori dettagli sui requisiti hardware necessari è possibile consultare il paragrafo “Discrete device assignment” nel documento  System requirements for Hyper-V on Windows Server 2016.

Windows Containers

Parlando delle novità in ambito Hyper-V è opportuno citare anche i Windows Containers che consentono l’esecuzione su un sistema di applicazioni isolate. Tra i principali punti di forza dei containers troviamo la velocità di creazione, l’alta scalabilità e la portabilità. Sono disponibili due tipologie di container runtime, ognuno fornisce un differente grado di isolamento dell’applicazione:

  • Windows Server Containers che utilizza namespace e process isolation
  • Hyper-V Containers che utilizza una piccola macchina virtuale per ogni container

Per maggiori dettagli sui containers vi invito a consultare la documentazione ufficiale dei Windows Container e la sezione specifica su WindowServer.it contenente diversi articoli molto interessanti.

 

Aggiornamento Funzionalità in Windows Server 2016

More Memory and Processors for Generation 2 Virtual Machines and Hyper-V Hosts

Le machine virtuali di generazione 2, a partire dalla versione 8 del file di configurazione, possono essere configurate con un numero maggiore di risorse in termini di processori virtuali e memoria RAM. Sono inoltre stati rivisti anche i limiti massimi di utilizzo delle risorse da parte degli host fisici. Per tutti i dettagli relativi alla scalabilità di Hyper-V in Windows Server 2016 è possibile consultare il documento Plan for Hyper-V scalability in Windows Server 2016.

Virtual Machine Configuration File Format

Il file di configurazione delle machine virtuali utilizza un nuovo formato che consente di leggere e scrivere in modo più efficiente le differenti configurazioni. Questo nuovo formato lo rende anche più resiliente a corruzioni nel caso dovessero verificarsi failure del sottosistema dischi. L’estensione del nuovo file di configurazione che detiene la configurazione della macchina virtuale è .vmcx mentre l’estensione .vmrs è utilizzata per detenere lo stato di runtime.

Virtual Machine Configuration Version

La versione del file di configurazione rappresenta il Livello di compatibilità della macchina virtuale con la versione di Hyper-V. Le machine virtuali con file di configurazione versione 5 sono compatibili Windows Server 2012 R2 e possono essere attivate sia su Windows Server 2012 R2 che su Windows Server 2016. Macchine virtuali aventi versioni del file di configurazione introdotte in Windows Server 2016 non possono essere eseguite in Hyper-V su Windows Server 2012 R2. Per poter utilizzare tutte le nuove funzionalità sulle macchine virtuali create con Windows Server 2012 R2 e poi migrate o importate in Hyper-V su Windows Server 2016 è necessario aggiornare la configurazione delle macchine virtuali. L’aggiornamento non avviene in automatico. Il downgrade del file di configurazione non è supportato. Tutti i dettagli su come aggiornare la versione della configurazione delle macchine virtuali li trovate nel seguente articolo: Upgrade virtual machine version in Hyper-V on Windows 10 or Windows Server 2016.

Hyper-V Manager Improvements

Anche Hyper-V manager introduce important miglioramenti:

  • Alternate credentials support – Viene fornita la possibilità di utilizzare un set di credenziali differenti in Hyper-V Manager quando ci si collega ad un host remoto Windows Server 2016 oppure Windows 10. Le credenziali possono anche essere salvate per essere facilmente riutilizzate.
  • Manage earlier versions – Utilizzando Hyper-V Manager in Windows Server 2016 e Windows 10 è possibile gestire anche sistemi Hyper-V basati su Windows Server 2012, Windows 8, Windows Server 2012 R2 e Windows 8.1.
  • Updated management protocol – Hyper-V Manager utilizza il protocollo WS-MAN per comunicare con gli host Hyper-V remoti. Tale protocollo di comunicazione consente l’autenticazione CredSSP, Kerberos oppure NTLM e facilita la configurazione degli host per consentire la gestione remota.

Integration Services Delivered Through Windows Update

Di grande utilità è la possibilità di aggiornare gli integration services delle virtual machine basate su sistema operativo Windows tramite Windows Update. Questo è un aspetto di particolare interesse anche per i service providers perché grazie a questo meccanismo il controllo dell’applicazione di questi aggiornamenti viene lasciato nelle mani del tenant che possiede la macchina virtuale. I tenant possono quindi aggiornare in autonomia la propria macchina virtuale Windows con tutti gli aggiornamenti, compresi gli integration services, utilizzando un unico metodo.

Shared Virtual Hard Disks

Viene fornita la possibilità di effettuare il resize dei virtual hard disks di tipologia shared, utilizzati per realizzare ambienti guest clustering, senza alcun downtime. Le dimensioni dei shared virtual hard disks possono infatti essere estese o ridotte mentre la macchina virtuale è online. I guest cluster che utilizzano shared virtual hard disks possono ora essere protetti con l’Hyper-V Replica a fini di disaster recovery.

Storage Quality of Service (QoS)

In ambito storage è possibile creare delle policy di QoS su Scale-Out File Server ed assegnarle ai vari dischi virtuali associati alle macchine virtuali Hyper-V. In questo modo si ha la possibilità di controllare le performance dello storage evitando che l’utilizzo dello stesso da parte delle singole macchine virtuali possa impattare l’intero sottosistema dei dischi. Potete trovare tutti i dettagli riguardanti questo argomento nel documento Storage Quality of Service.

 

Conclusioni

Molte sono le novità introdotte nella piattaforma di virtualizzazione Microsoft con Windows Server 2016 che la rendono ancora più completa e ricca di nuove funzionalità. Microsoft Hyper-V è ormai disponibile sul mercato da diversi anni, ha raggiunto altissimi livelli di affidabilità ed offre un’ottima soluzione di virtualizzazione a livello enterprise. Nella scelta della piattaforma di virtualizzazione è bene non trascurare anche le varie possibilità che Microsoft offre per scalare verso il public cloud oppure per implementare architetture ibride.

Potete testare tutte le nuove funzionalità di Microsoft Hyper-V Server 2016 scaricando la versione di valutazione dal TechNet Evaluation Center.

Per ulteriori approfondimenti sul tema vi invito a partecipare alle sessioni dedicate ad Hyper-V durante il  SID // Windows Server 2016 Roadshow, l’evento gratuito dedicato al nuovo sistema operativo, rivolto a tutte le aziende, consulenti e partner che vogliono prepararsi al futuro e che vogliono conoscere le novità e le best-practice di implementazione del nuovo sistema operativo server.

Windows Server 2016: Introduzione al Network Controller

In Windows Server 2016 sono molte le novità introdotte in ambito networking che ci consentono di realizzare una infrastruttura funzionale, denominata Software Defined Networking (SDN), che è alla base del Software Defined Datacenter (SDDC).

Le caratteristiche principali dell’architettura Software Defined Networking (SDN) sono l’adattabilità, la dinamicità e la facilità di gestione. Tutti questi aspetti possono essere contemplati al meglio grazie all’introduzione in Windows Server 2016 delle funzionalità che andremo ad approfondire in questo articolo.

Network Controller

Si tratta di un nuovo ruolo introdotto in Windows Server 2016 che può essere facilmente installato tramite Server Manager oppure utilizzando PowerShell e che consente di gestire, configurare e monitorare l’infrastruttura di rete virtuale e fisica del proprio datacenter. Grazie al Network Controller è anche possibile automatizzare la configurazione della propria infrastruttura di rete anziché dover configurare manualmente device e servizi. Questo ruolo può essere installato anche su macchine virtuali, prevede di essere messo in alta disponibilità e può scalare facilmente. Il deploy del Network Controller può essere fatto sia in ambiente di dominio, in questo caso l’autenticazione degli utenti e dei device di rete avviene tramite Kerberos, che in un ambiente non di dominio richiedendo l’autenticazione basata su certificati.

La comunicazione tra il Network Controller e i componenti di rete avviene utilizzando l’interfaccia Southbound API, figura 1, grazie alla quale viene fatto il discovery degli apparati di rete e rilevata la configurazione dei servizi. Inoltre tramite la stessa interfaccia vengono raccolte le informazioni di rete necessarie e trasmesse agli apparati le modifiche effettuate.

Tramite l’interfaccia Northbound API è possibile comunicare con il Network Controller per consultare le informazioni di rete ed utilizzarle per fare monitoring e troubleshooting. La stessa API viene utilizzata per apportare modifiche alla configurazione di rete e per fare il deploy di nuovi device.

2015_12_27_WS16NC_01
Figura 1 – Schema Comunicazione

La gestione e il monitor della rete tramite Network Controller, figura 2, può avvenire direttamente tramite PowerShell (Network Controller Cmdlets) oppure utilizzando applicazioni di management come ad esempio System Center Virtual Machine Manager (SCVMM) e System Center Operations Manager (SCOM).

2015_12_27_WS16NC_02

Figura 2 – Gestione Network Controller

Tramite il Network Controller è possibile gestire i seguenti componenti dell’infrastruttura di rete fisica e virtuale:

  • Hyper-V VMs e virtual switch
  • Switch
  • Router
  • Firewall software
  • VPN Gateway (compreso RRAS Multitenant Gateway)
  • Load Balancer

Funzioni Network Virtualizzate

La diffusione della virtualizzazione ha coinvolto anche il settore network e c’è sempre più interesse nelle appliance virtuali e nei servizi cloud che erogano servizi di rete con un mercato emergente in forte crescita. Nei software defined datacenter vediamo infatti sempre più frequentemente l’utilizzo di appliance virtuali per erogare funzionalità di rete che tipicamente venivano erogate esclusivamente da apparati fisici (come ad esempio bilanciatori, firewall, router, switch, etc.).

In Windows Server 2016 Technical Preview sono disponibili le seguenti virtual appliance:

Software Load Balancer

Si tratta di un bilanciatore software layer-4, con caratteristiche analoghe al load balancer già ampliamente utilizzato sulla piattaforma Azure. Per maggiori informazioni su Microsoft Azure Load Balancing Services vi invito a consultare Microsoft Azure Load Balancing Services.

Firewall Multi-Tenant

Il Datacenter Firewall, figura 3, è un nuovo servizio introdotto in Windows Server 2016. Questo firewall è in grado di proteggere il layer network delle reti virtuali ed è pensato per essere multitenant. Quando viene implementato può essere offerto come servizio dal service provider e l’amministratore del tenant può installare e configurare delle firewall policy per proteggere le proprie reti virtuali da potenziali attacchi che provengono da internet o dalle reti interne.

2015_12_27_WS16NC_03

Figura 3 – Firewall Policy

La gestione del Datacenter Firewall può essere fatta utilizzando il network controller. Il Datacenter Firewall offre i seguenti vantaggi per il cloud service provider:

  • Un servizio firewall software scalabile e gestibile che può essere offerto come servizio ai propri tenant
  • Offre protezione ai tenant indipendentemente dal sistema operativo in esecuzione sulla macchina virtuale
  • Libertà di spostare le macchine virtuali dei tenant su host della fabric differenti senza interrompere le funzionalità firewall erogate in quanto:
  • L’agente firewall viene deployato come porta vSwitch;
  • Le macchine virtuali del tenant prendono le policy assegnate al loro vSwitch;
  • Le regole del firewall vengono configurate in ogni porta del vSwitch, indipendentemente dall’host fisico che detiene la macchina virtuale

Per quanto riguarda i tenant invece il Datacenter Firewall offre i seguenti vantaggi:

  • Possibilità di definire regole sul firewall per aumentare la protezione dei workload esposti nelle virtual network verso Internet
  • Possibilità di creare delle regole sul firewall per la protezione tra macchine virtuali presenti sulla stessa subnet layer 2 oppure su subnet L2 differenti
  • Possibilità di definire delle regole firewall per aumentare la protezione e isolare il traffico di rete tra la rete tenant on premise e la propria virtual network presente presso il service provider

RAS Gateway

RAS Gateway viene utilizzato per fare routing del traffico di rete tra le reti virtuali e le reti fisiche. Diversi sono gli ambiti di utilizzo:

Site-to-Site Gateway

Soluzione gateway multi-tenant, figura 4, che consente ai tenant di accedere alle loro risorse e di gestirle utilizzando una connessione VPN site-to-site. Grazie a questo gateway è possibile mettere in comunicazione risorse virtuali nel cloud con la rete fisica del tenant.

2015_12_27_WS16NC_04

Figura 4 – S2S Gateway

Forwarding Gateway

Utilizzato per fare routing del traffico di rete tra le reti virtuali e la rete fisica del provider di hosting (nella stessa location geografica) – figura 5.

2015_12_27_WS16NC_05

Figura 5 – Forwarding Gateway

GRE Tunnel Gateway

I gateway sono in grado di creare tunnel basati sul protocollo GRE che forniscono connettività tra le virtual network dei tenant e le reti esterne. Il protocollo GRE è supportato in molti apparati di rete, pertanto è una scelta ideale quando non viene richiesta l’encryption del canale. Per maggiori dettagli sul tunnel GRE vi invito a consultare GRE Tunneling in Windows Server Technical Preview.

Hyper-V Network Virtualization

La Network Virtualization di Hyper-V (HNV) è un componente fondamentale della soluzione Software Defined Networking (SDN) di Microsoft e come tale sono molte le novità introdotte in Windows Server 2016 per renderlo sempre più funzionale e integrato nello stack SDN.

Un aspetto importante da tenere in considerazione quando si parla di SDN è che lo stesso stack è consistente con Microsoft Azure e ci consente quindi di portare le stesse potenzialità utilizzate nel public cloud di Azure presso la propria realtà.

Programmable Hyper-V Switch

Tramite il componente Network Controller è possibile fare la push delle policy HNV, figura 6, verso l’agent in esecuzione su ogni host che utilizza l’Open vSwitch Database Management Protocol (OVSDB – RFC 7047). L’Host Agent memorizza queste policy utilizzando una customizzazione dello schema VTEP ed è in grado di programmare regole anche complesse all’interno del performante motore dell’Hyper-V virtual switch.

2015_12_27_WS16NC_06

Figura 6 – Push Policies

Supporto a VXLAN Encapsulation

Il protocollo Virtual eXtensible Local Area Network (VXLAN – RFC 7348) è stato ampliamente adottato sul mercato con il supporto di importanti vendor come Cisco, Brocade, Dell, HP e altri. L’HNV ora supporta questo schema di incapsulamento utilizzando la modalità di distribuzione MAC attraverso il Microsoft Network Controller, il quale consente di programmare l’associazione tra gli indirizzi IP del tenant (Customer Address – CA) e gli indirizzi IP della rete fisica (Provider Address – PA). Il protocollo di incapsulamento Network Virtualization Generic Routing Encapsulation (NVGRE) continua ad essere supportato anche in Windows Server 2016.

Interoperabilità con il Software Load Balancer (SLB)

Il software load balancer (SLB) presentato in precedenza è pienamente supportato in ambito reti virtuali. Il SLB avviene attraverso il performante motore del virtual switch e controllato dal network controller per quanto riguarda il mapping Virtual IP (VIP) – Dynamic IP (DIP).

IEEE Compliant

Per garantire la piena interoperabilità con apparati di rete fisici e virtuali Microsoft garantisce che tutti i pacchetti trasmessi quando si utilizza HNV sono in tutti i suoi campi compliant con gli standard dettati da IEEE. Questo aspetto è stato fortemente curato e ulteriormente migliorato in Windows Server 2016.

Nuovi Elementi Introdotti (Cloud Scale Fundamentals)

In Windows Server 2016 sono state introdotte le seguenti funzionalità per avere la possibilità di configurare il proprio ambiente in modo più efficace, sfruttando al meglio le risorse hardware a disposizione:

Converged Network Interface Card (NIC): Questa funzionalità consente di utilizzare una singola scheda di rete per gestire tipologie differenti di traffico: il management, l’accesso allo storage (RDMA) e il traffico dei tenant. In questo modo è possibile diminuire il numero di schede di rete necessarie per ogni host fisico.

Switch Embedded Teaming (SET): SET è una nuova soluzione di NIC Teaming integrata nei Virtual Switch di Hyper-V. SET consente di avere teaming composti fino ad un massimo di otto schede di rete fisiche in un unico SET team. Questa modalità di teaming, essendo integrata nei virtual switch, può essere utilizzata solo sugli host fisici e non all’interno delle macchine virtuali, dove sarà comunque possibile configurare teaming in modo tradizionale (NIC Teaming in Virtual Machines). Questa modalità di teaming non espone interfacce di team, ma le configurazioni vanno apportate tramite Virtual Switch port.

2015_12_27_WS16NC_07

Packet Direct: Packet Direct consente di raggiungere un elevato throughput e una bassa latenza per il traffico di rete.

Novità Apportate ai Servizi Esistenti

DHCP
La funzionalità Network Access Protection (NAP) è già nello stato “deprecated” in Windows Server 2012 R2. In Windows Server 2016 il ruolo DHCP Server non supporterà più la funzionalità NAP e gli scope DHCP non potranno più essere NAP-enabled.

DNS Server
Approfondiamo ora quelle che sono in Windows Server 2016 le diverse novità introdotte sul servizio DNS Server per migliorare l’efficacia e la sicurezza:

DNS Policy: è possibile configurare delle policy DNS per definire come il server DNS risponde alle query DNS. Le risposte DNS possono essere in base a molti parametri, come ad esempio all’indirizzo IP del client (location) oppure all’ora del giorno. Le policy DNS aprono le porte a diversi scenari di configurazione come DNS location-aware, gestione del traffico, load balancing e split-brain DNS.

Response Rate Limiting (RRL): è possibile configurare sul server DNS dei limiti sul response rate. Questo tipo di configurazione ci consente di evitare l’utilizzo del sistema DNS da parte di sistemi malevoli per effettuare attacchi di tipo DOS (denial of service).

DNS-based Authentication of Named Entities (DANE): è possibile utilizzare i record TLSA (Transport Layer Security Authentication) per fornire informazioni ai DNS Client riguardanti quale CA è attesa per uno specifico domain name. Questo meccanismo risulta utile per poter prevenire attacchi ti tipologia man-in-the-middle.

Supporto degli Unknown Record: questa funzionalità consente di aggiungere record che non risultano supportati in modo esplicito dal Server DNS Windows.

IPv6 root hints: è possibile utilizzare gli IPV6 root server per effettuare la risoluzione dei nomi Internet.

Windows PowerShell Support: è stato migliorato il supporto PowerShell introducendo nuovi cmdlets per il DNS Server.

DNS e IPAM: miglior integrazione tra il servizio DNS e IPAM.

Vi invito ad approfondire e valutare direttamente sul campo le nuove funzionalità introdotte in ambito networking scaricando Windows Server 2016.