Archivi categoria: Cloud

Azure SQL Database: come gestire la connettività con i vNet Service Endpoints

Per avere un maggiore controllo sugli accessi che vengono effettuati sugli Azure SQL Database, lo scorso mese, Microsoft ha rilasciato pubblicamente la possibilità di abilitare i Virtual Network (vNet) Service Endpoints per i SQL Database. In questo articolo verrà spiegato il principio di funzionamento, con i benefici che ne derivano, e verrà mostrata la relativa configurazione.

Caratteristiche e principi di funzionamento

I vNet Service Endpoints per gli Azure SQL Database consentono di isolare maggiormente i SQL Server logici presenti nel cloud Microsoft, garantendo l’accesso solamente da una o più subnet definite nelle proprie Virtual Network di Azure. Questa funzionalità garantisce che tutto il traffico generato dalle proprie vNet verso l’Azure SQL Database rimarrà sempre all’interno della rete di backbone di Azure. Si tratta di una funzionalità disponibile in tutte le region di Azure e non sono previsti costi aggiuntivi per il relativo utilizzo.

Figura 1 – Schema di sintesi dell’architettura

Sul firewall degli Azure SQL Database rimane la possibilità di abilitare la comunicazione da parte dei servizi Azure e di filtrare gli accessi sulla base di un range di IP Pubblici.

Figura 2 – Impostazioni firewall di Azure SQL Server

Abilitando l’impostazione “Allow access to Azure services” viene consentito l’accesso al SQL Server da tutti gli indirizzamenti IP pubblici di Azure e da tutte le subnet di Azure, comprese quelle non di propria appartenenza. Andando ad applicare ulteriori filtri sulla base dell’IP pubblico che si deve connettere può diventare di difficile gestione e richiedere la configurazione di indirizzi IP pubblici statici sulle risorse di Azure.

Grazie all’introduzione dei Virtual Network (vNet) Service Endpoints per SQL Server è possibile avere un maggiore controllo sulle potenziali comunicazioni e un minor effort di gestione delle risorse. Il principio di funzionamento dei vNet Service Endpoints non si estende al mondo on-premises anche in presenza di connettività con Azure (VPN oppure ExpressRoute), ma per consentire l’accesso da sistemi presenti on-premises è necessario continuare ad utilizzare le regole firewall per limitare la connettività solamente agli IP pubblici di propria appartenenza.

I Virtual Network (vNet) Service Endpoints sono disponibili, con lo stesso principio di funzionamento, anche per Azure Storage e per Azure SQL Datawarehouse (al momento in preview).

Come effettuare la configurazione

L’abilitazione dei vNet Service Endpoints richiede l’attivazione sulla subnet della virtual network di Azure, dalla quale ci si intende connettere al SQL Server, dell’Enpoint di SQL Server (Microsoft.SQL).

Figura 3 – Abilitazione del SQL Server Service Endpoint sulla subnet

Figura 4 – Service Endpoint di SQL Server abilitato con successo sulla subnet

Successivamente è necessario aggiungere lato SQL Database la virtual network, con il Service Endpoint abilitato, nella sezione Firewall and virtual networks.

Figura 5 – Aggiunta Virtual Network con Service Endpoint di SQL Server abilitato

Ogni Virtual Network Rule viene applicata a livello di Azure SQL Database server e non a livello di singolo database.

Questo tipo di configurazione comporta che collegandosi ai DB ospitati dall’Azure SQL Server da una macchina attestata su una vNet con i Service Endpoint abilitati, verrà utilizzato come source IP un indirizzo appartenente all’address space della vNet. Questo aspetto è da tenere in considerazione, in configurazioni esistenti, per evitare che quando si attiva il SQL Server Service Endpoint sulla subnet, venga bloccato l’accesso al SQL Server. A questo scopo è possibile evitare il blocco consentendo temporaneamente l’accesso tramite l’impostazione “Allow access to Azure services”, oppure definendo la vNet nelle firewall rule del SQL Server prima di abilitare il Service Endpoint sulla subnet. Per farlo è necessario utilizzando il flag IgnoreMissingServiceEndpoint oppure selezionare il flag seguente presente nel portale Azure:

Figura 6 – Aggiunta Virtual Network senza Service Endpoint di SQL Server abilitato

Conclusioni

I Virtual Network (vNet) Service Endpoints sono in grado di estendere le proprie virtual network di Azure e la relativa identità verso determinati servizi di Azure, come Azure SQL Server, tramite una connessione diretta. Questo consente di aumentare il livello di sicurezza dei propri servizi presenti nel cloud Microsoft, di ottimizzare il routing per accedere alle risorse Azure dalle proprie vNet e di diminuire l’effort di gestione, il tutto con pochi semplici passaggi.

Creazione di un ambiente Docker in Azure tramite VM Extension

Docker è una piattaforma software che consente di creare, gestire ed eseguire applicazioni isolate in containers. Un container non è altro che una metodologia di creazione dei pacchetti software in un formato che permette di essere eseguito in modo indipendente ed isolato su un sistema operativo condiviso. I containers a differenza delle machine virtuali non comprendono un sistema operativo completo, ma solamente le librerie e le impostazioni necessarie per consentire l’esecuzione del software. Ne derivano quindi una serie di vantaggi in termini di dimensione, velocità, portabilità e gestione delle risorse.

 
Figura 1 – Diagramma dei Container

 

Nel mondo Microsoft Azure ci sono svariate possibilità di configurare ed utilizzare container Docker che vi elenco sinteticamente:

  • VM Extension: tramite una Extension specifica è possibile implementare Docker all’interno di una macchina virtuale.
  • Azure Container Service: consente di distribuire rapidamente nell’ambiente Azure un cluster Docker Swarm, DC/OS o Kubernetes pronto per la produzione. Si tratta della soluzione più completa per l’orchestrazione dei container.
  • Docker EE for Azure: è un template disponibile sull’Azure Marketplace, frutto della collaborazione tra Microsoft e Docker, grazie al quale è possibile fare il provisioning di un cluster Docker Enterprise Edition sfruttando l’integrazione con gli Azure VM Scale Sets, gli Azure Load Balancer e l’Azure Storage.
  • RancherOS: è una distribuzione Linux appositamente creata per l’esecuzione di containers Docker disponibile come template all’interno del Marketplace Azure.
  • Web App for Containers: viene offerta la possibilità di utilizzare containers facendone il deployment nella piattaforma gestita degli Azure App Service come Web App in esecuzione in un ambiente Linux.
  • Azure Container Instances (attualmente in preview): è sicuramente il metodo più semplice e rapido per eseguire un container Docker nella piattaforma Azure, senza la necessità di creare macchine virtuali, ideale in scenari che prevedono containers isolati.
  • Azure Service Fabric: supporta i containers sia nell’ambiente Windows che Linux. La piattaforma contiene in modo nativo il supporto per Docker Compose (attualmente in preview), consentendo di orchestrare applicazioni basate su containers nell’Azure Service Fabric.
  • DC/OS su Azure: si tratta di un servizio cloud gestito che mette a disposizione un ambiente per il deployment di workload in cluster utilizzando la piattaforma DC/OS (Datacenter Operating System).

Tutte queste possibilità offerte consentono, in base alle esigenze e allo scenario che si deve implementare, di scegliere la metodologia di deployment più opportuna nell’ambiente Azure per l’esecuzione dei container Docker.

In questo articolo approfondiremo la creazione di un ambiente Docker utilizzando l’apposita Virtual Machine Extension. Partendo da una macchina virtuale presente in Azure è possibile aggiungere la Docker Extension che installa e configura il daemon Docker, il client Docker e il Docker Compose.

Questa extension è supportata per le seguenti distribuzioni Linux:

  • Ubuntu 13 o superiore.
  • CentOS 7.1 o superiore.
  • Red Hat Enterprise Linux (RHEL) 7.1 o superiore.
  • CoreOS 899 o superiore.

L’aggiunta dell’extension dal portale Azure può essere fatta tramite i seguenti step. Nella sezione Extensions della macchina virtuale seleziono il pulsante Add:

Figura 2 – Aggiunta Extension alla VM dal portale Azure

 

Successivamente viene mostrato l’elenco delle Extension disponibili, ci si posiziona sull’Extension Docker e si preme il pulsante Create.

Figura 3 – Selezione dell’Extension Docker

 

Per consentire una comunicazione sicura con il sistema Docker implementato nell’ambiente Azure è necessario utilizzare dei certificati e delle chiavi rilasciati da una CA trusted. Se non si dispone di una CA per generare questi certificati è possibile seguire le indicazioni riportate nella sezione Create a CA, server and client keys with OpenSSL presente nella documentazione ufficiale di Docker.

 

Figura 4 – Schema di comunicazione docker tramite protocollo crittografato TLS

 

Il wizard di aggiunta dell’Extension richiede come prima cosa di inserire la porta di comunicazione utilizzata dell’Engine Docker (2376 è la porta di default). Inoltre è richiesto l’inserimento del certificato della CA, del certificato Server e della Server Key, tutti nel formato base64-encoded:

Figura 5 – Parametri richiesti dal wizard di aggiunta della Docker VM Extension

 

L’aggiunta dell’Extension Docker richiede alcuni minuti al termine dei quali sulla macchina virtuale sarà presente l’installazione dell’ultima versione stabile del Docker Engine e il daemon Docker sarà in ascolto sulla porta specificata utilizzando i certificati inseriti nel wizard.

Figura 6 – Dettagli dell’Extension Docker

 

Nel caso sia necessario consentire la comunicazione Docker dall’esterno della vNet su cui è attestata la macchina virtuale con Docker è necessario configurare in modo opportuno le regole nel Network Security Group utilizzato:

Figura 7 – Esempio di configurazione NSG per consentire comunicazione Docker (porta 2376)

 

Giunti a questo punto l’ambiente è pronto per essere utilizzato e da un client remoto posso iniziare a comunicare verso l’ambiente Docker appena configurato:

Figura 8 – Comando Docker eseguito da un client remoto per recuperare informazioni

 

Conclusioni

L’Azure Docker VM extension è ideale per implementare facilmente e in modo affidabile e sicuro un ambiente Docker di sviluppo oppure di produzione su una singola macchina virtuale. Microsoft Azure offre un’ampia gamma di possibilità nelle scelte di implementazione relative alla piattaforma Docker, consentendo di scegliere con molta flessibilità la soluzione più idonea per le proprie esigenze.

Azure Multi-Factor Authentication: Introduzione alla Soluzione

Per rendere più sicuro l’accesso ai dati e alle applicazioni critiche può essere necessario prevedere l’autenticazione a più fattori che generalmente richiede l’utilizzo di almeno due dei seguenti metodi di verifica:

 

  • Qualcosa che si conosce (tipicamente una password).
  • Qualcosa che si possiede (un dispositivo unico e non facilmente duplicabile, come ad esempio un telefono).
  • Un sistema di riconoscimento biometrico che ha lo scopo di identificare una persona sulla base di una o più caratteristiche biologiche o comportamentali (biometria).

 

Microsoft consente di adottare una soluzione di autenticazione a due fattori utilizzando l’Azure Multi-Factor Authentication (MFA) che prevede l’adozione di un secondo metodo di verifica dell’identità durante il processo di autenticazione. Utilizzando questa soluzione sono configurabili i seguenti fattori di autenticazione aggiuntivi:

 

  • Chiamata telefonica: viene effettuata una chiamata verso il telefono registrato per l’utenza. In questo caso verrà richiesto all’utente di rispondere alla chiamata e di verificare l’accesso premendo il pulsante # oppure inserendo un codice PIN.
  • Messaggio di testo (SMS): viene inviato al cellulare dell’utente un SMS che contiene un codice pin di 6 cifre il quale dovrà essere inserito durante il processo di autenticazione.
  • Notifica tramite Mobile App: sullo smartphone dell’utente viene inviata tramite Mobile App una richiesta di verifica che deve essere approvata dall’utente per completare il processo di autenticazione.
  • Codice di verifica tramite Mobile App: nella Mobile App presente sullo smartphone dell’utente viene generato un codice di 6 cifre ogni 30 secondi. L’utente dovrà quindi inserire il codice più recente nel momento in cui effettua l’autenticazione.
  • Token OATH di terze parti: c’è la possibilità di configurare Azure Multi-Factor Authentication per accettare metodi di verifica messi a disposizione da soluzione di terze parti.

 

L’Azure Multi-Factor Authentication (MFA) prevede due possibili modelli di deployment:

 

  • MFA come soluzione interamente nel Cloud.
  • Sistema MFA installato e configurato su sistemi on-premises.

 

Per individuare il modello di deployment più opportuno è necessario prendere in considerazione diversi aspetti: cosa sto mettendo in sicurezza, dove si trovano gli utenti che devono accedere alla soluzione e di quali funzionalità ho realmente bisogno.

 

Cosa si sta Tentando di Proteggere?

Questa è sicuramente la prima domanda che occorre porsi la cui risposta ci può già indirizzare a un modello di deployment specifico. Nel caso infatti ci sia la necessità di abilitare il doppio fattore di autenticazione per applicazioni IIS non pubblicate tramite Azure AD App Proxy oppure soluzioni di accesso remoto (VPN oppure Remote Desktop Gateway) è necessario utilizzare il server Azure MFA implementato sui sistemi on-premises.

 

Figura 1 – Cosa si intende proteggere tramite MFA

 

Dove si Trovano gli Utenti?

Un altro aspetto importante da tenere in considerazione è dove si trovano gli utenti sulla base del modello di Identity adottato, come mostra la figura 2.

 

Figura 2 – Ubicazione degli utenti

 

Quali funzionalità sono necessarie?

A seconda del modello di deployment scelto (MFA nel cloud oppure MFA locale) sono disponibili funzionalità differenti che ci potrebbero far optare per una scelta piuttosto che per un’altra, come mostra la figura 3.

 

Figura 3 – Funzionalità MFA disponibili nei due modelli

 

Requisiti necessari per l’utilizzo della MFA

Per poter utilizzare l’Azure Multi-Factor Authentication (MFA) è necessario avere accesso a una subscription Azure. Nel caso si volesse testare il servizio è possibile eventualmente utilizzare una subscription di trial di Azure.

 

I requisiti hardware per quanto riguarda l’Azure Multi-Factor Authentication Server sono minimi (200 MB di spazio disco e 1 GB di RAM), mentre sono richieste le seguenti caratteristiche software:

 

  • Sistema Operativo: Windows Server 2008 R2 o superiore
  • Microsoft .NET 4.0 Framework
  • IIS 7.0 o superiore se si vuole installare lo User Portal oppure il Web Service SDK

 

Ogni server MFA deve essere in grado di comunicare sulla porta 443 in uscita verso i seguenti indirizzi web:

 

  • https://pfd.phonefactor.net
  • https://pfd2.phonefactor.net
  • https://css.phonefactor.net

 

Inoltre nel caso ci siano policy firewall di blocco in uscita verso la porta 443 è necessario aprire i range di indirizzi IP documentati nel paragrafo “Azure Multi-Factor Authentication Server firewall requirements” della documentazione ufficiale Microsoft.

 

Azure Multi-Factor Authentication nel cloud

L’abilitazione della MFA nello scenario cloud è molto semplice ed avviene per utente. Per farlo è necessario accedere al servizio Azure Active Directory, figura 4, dal portale Azure:

 

Figura 4 – Step 1: abilitazione MFA nel cloud

 

Dopo aver selezionato la Directory, nella sezione “Users and groups” selezionare “Multi-Factor Authentication”:

 

Figura 5 – Step 2: abilitazione MFA nel cloud

 

Si verrà rediretti su un altro portale dove selezionando l’utente specifico, figura 6, è possibile abilitare la MFA:

 

Figura 6 – Step 3: abilitazione MFA nel cloud

 

Giunti a questo punto l’utente sarà abilitato all’utilizzo della MFA. La stessa operazione può essere fatta anche selezionando più utenti contemporaneamente e dallo stesso portale è possibile configurare le varie impostazioni dell’Azure Multi-Factor Authentication. Per maggiori dettagli a riguardo vi invito a consultare la documentazione ufficiale Microsoft.

 

La stessa operazione può essere portata a termine anche utilizzando i cmdlet Powershell per Azure AD i quali ci consentono facilmente di effettuare l’abilitazione della MFA per più utenti con poche righe di codice, come riportato nell’esempio seguente:

 

$users = “user1@ugisystemcenter.org”,”user2@ugisystemcenter.org”,”user3@ugisystemcenter.org”

foreach ($user in $users)

{

    $st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

    $st.RelyingParty = “*”

    $st.State = “Enabled”

    $sta = @($st)

    Set-MsolUser -UserPrincipalName $user -StrongAuthenticationRequirements $sta

}

 

Azure Multi-Factor Authentication on-premises

Il deployment on-premises dell’Azure Multi-Factor Authentication Server richiede di effettuare il download del setup di installazione direttamente dal portale Azure. Nel caso si voglia licenziare Azure Multi-Factor Authentication come servizio autonomo con opzioni di fatturazione per utente e per autenticazione è necessario creare dal portale Classic di Azure un nuovo Multi-Factor Auth Provider (tale funzionalità presto sarà disponibile anche sul nuovo portale Azure).

 

Figura 7 – Creazione nuovo Multi-Factor Auth Providers

 

Selezionando il pulsante Manage si viene rediretti verso il portale dell’Azure Multi-Factor Authentication, figura 8, dal quale è possibile effettuare il donwload del setup e generare le credenziali di attivazione del servizio.

 

Figura 8 – Download del Multi-Factor Authentication Server e generazione credenziali

 

Nel caso si voglia utilizzare la licenza in bundle a Enterprise Mobility Suite, Azure AD Premium oppure Enterprise Cloud Suite non è necessario creare un Multi-Factor Auth Provider ma è sufficiente accedere al portale dell’Azure Multi-Factor Authentication per effettuare direttamente il download del setup.

 

Dopo essere entrati in possesso del setup è possibile effettuare l’installazione dell’Azure MFA Server. Durante il setup verrà richiesto solamente il percorso di installazione, figura 9.

 

Figura 9 – Setup Azure MFA Server

 

Figura 10 – Setup Azure MFA Server

 

Giunti a questo punto è necessario eseguire il Multi-Factor Authentication Server appena installato che ci guiderà nella procedura di attivazione.

 

Figura 11 – Applicazione Multi-Factor Authentication Server

 

Figura 12 – Step 1: Procedura attivazione Multi-Factor Authentication Server

 

Nella schermata seguente è necessario inserire le credenziali di accesso che vengono generate dal Portale dell’Azure Multi-Factor Authentication (vedi Figura 8).

 

Figura 13 – Step 2: Procedura attivazione Multi-Factor Authentication Server

 

Dopo aver completato l’attivazione del primo server Azure MFA è possibile avviare il Wizard di configurazione, figura 14, per attivare la replica tra più server Azure MFA e configurare il servizio in alta disponibilità.

 

Figura 14 – Wizard di configurazione Multi-Server MFA

 

Nello scenario dove il Multi-Factor Authentication Server è abilitato su più sistemi, i server Azure MFA comunicano tra di loro attraverso chiamate RPC e per fare in modo che il tutto avvenga in modo sicuro devono autenticarsi in modo reciproco. Tale processo di autenticazione può avvenire sia tramite l’appartenenza a un gruppo di security specifico in Active Directory (denominato Phone Factor Admins) sia tramite l’utilizzo di certificati SSL.

 

Ora che il server Azure MFA è stato configurato c’è la possibilità di importare facilmente gli utenti da Active Directory, figura 15, e su questi abilitare il doppio fattore di autenticazione desiderato.

 

Figura 15 – Import degli utenti da Active Directory

 

Nello scenario di utilizzo dell’Azure Multi-Factor Authentication (MFA) Server è bene specificare che i dati relativi agli utenti vengono salvati sui sistemi on-premises e nessun dato viene memorizzato in modo persistente sul cloud. Infatti nel momento in cui un utente effettua il processo di autenticazione a più fattori il server Azure MFA invia i seguenti dati verso il servizio Cloud Azure MFA per effettuare la verifica e a fini di reportistica:

 

  • ID univoco dell’utente (username oppure ID del server MFA interno)
  • Nome e Cognome (opzionali)
  • Indirizzo Email (opzionale)
  • Numero di telefono (in caso di chiamata Telefonica oppure di invio SMS)
  • Device token (quando viene utilizzata l’autenticazione tramite mobile app)
  • Metodo di autenticazione
  • Esito autenticazione
  • Nome e inidirizzo IP del server Azure MFA
  • Client IP (se disponibile)
  • Esito verifica (successo o negata) e motivazione in caso di deny

 

Oltre all’import mirato dei diversi utenti da Active Directory sui quali si vuole abilitare il doppio fattore di autenticazione è possibile integrare il server Azure MFA con il servizio Active Directory e impostare una importazione mirata e schedulata degli utenti secondo determinati criteri. Per maggiori dettagli in merito è possibile consultare la documentazione ufficiale Integrazione di directory tra il server Azure MFA e Active Directory.

 

Modelli di Licensing della soluzione

Azure Multi-Factor Authentication è disponibile come servizio autonomo, con opzioni di fatturazione per utente e per autenticazione, oppure in bundle con Azure Active Directory PremiumEnterprise Mobility Suite e Enterprise Cloud Suite. Azure Multi-Factor Authentication è disponibile attraverso un contratto Enterprise Microsoft, il programma di licenza Open Volume, il programma Cloud Solution Provider e un contratto Direct, come modello annuale per utente. Il servizio è anche disponibile con un modello in base al consumo per utente e per autenticazione, fatturato ogni mese secondo l’Azure monetary commitmen.

 

Per maggiori informazioni sui costi della soluzione è possibile consultare il seguente documento: Prezzi di Multi-Factor Authentication.

 

Conclusioni

Azure Multi-Factor Authentication è una soluzione semplice da usare, scalabile e affidabile che offre la possibilità di introdurre un secondo metodo di validazione in modo che gli utenti siano in grado di accedere in modo più sicuro ai propri dati e alle applicazioni, sia esse presenti on-premises che in ambienti cloud. Per chi è interessato a provare il servizio può facilmente attivare una subscription Azure gratuitamente accedendo alla Free Trial di Azure.

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.