Archivi categoria: Cluster

Windows Server 2019: introduzione alle novità per l’ambiente cluster

Ottobre è il mese del rilascio ufficiale della versione definitiva di Windows Server 2019. Il nuovo sistema operativo server di casa Microsoft introduce, in diversi ambiti, delle importanti novità che consentono di ottenere infrastrutture Hyper-converged (HCI) maggiormente affidabili e flessibili. Per raggiungere questo obiettivo in Windows Server 2019 la soluzione cluster introduce una serie di cambiamenti che vengono riportati in questo articolo.

Cluster Sets

Cluster Sets è una nuova tecnologia di scale-out per l’ambiente cluster introdotta in Windows Server 2019. Grazie a questa funzionalità è possibile raggruppare più Failover Clusters in un’unica entità per ottenere una maggiore fluidità delle macchine virtuali tra i diversi cluster. Il tutto risulta particolarmente utile per attività di bilanciamento dei carichi e per operazioni di manutenzione, come ad esempio la sostituzione di interi cluster, senza impattare sull’esecuzione delle macchine virtuali. In termini di gestione è possibile governare il tutto utilizzando un unico namespace. Cluster Sets non stravolge i normali principi di funzionamento dell’ambiente cluster tradizionale (Preffered Owner, Node Isolation, Load Balancing, etc.), ma rimangono del tutto invariati, aggiungendo benefici quali Azure-like Fault Domains e Availability Sets tra cluster differenti.

Figura 1 – Cluster Sets overview

File share witness

In ambiente cluster si ha la possibilità di configurare come witness l’opzione “File Share Witness” (FSW), per la quale sono state introdotte le seguenti novità.

Viene bloccato l’utilizzo di share di tipologia Distributed File System (DFS). L’utilizzo di share DFS come File Share Witness (FSW) non è mai stata una configurazione supportata in quanto introduce potenziali instabilità nell’ambiente cluster. In Windows Server 2019 è stata introdotta una logica in grado di rilevare se una share utilizza DFS e in caso affermativo Failover Cluster Manager blocca la creazione del witness, visualizzando un messaggio di errore che riporta che si tratta di una configurazione non supportata.

Figura 2 – Messaggio di errore tentando di configurare il witness su share DFS

Per poter utilizzare una configurazione con FSW, prima dell’introduzione di Windows Server 2019, uno dei requisiti da rispettare era che il sistema Windows Server che ospitava la share doveva essere in join a un dominio e parte della stessa foresta Active Directory. Questo requisito era dato dal fatto che il Failover Cluster utilizzava l’autenticazione Kerberos con il Cluster Name Object (CNO) per autenticarsi e collegarsi alla share. In Windows Server 2019 è possibile creare un File Share Witness (FSW) senza utilizzare il CNO, viene infatti semplicemente utilizzato un account locale per connettersi al FSW. Per utilizzare File Share Witness non è quindi più necessaria l’autenticazione Kerberos, il Cluster Name Object e l’ambiente Active Directory. Ne consegue che si ampliano i possibili scenari di utilizzo per i FSW, ed è possibile contemplare l’utilizzo ad esempio di appliance NAS, sistemi Windows non in join al dominio, etc.

 

Spostamento del cluster in un dominio differente

Il cambio della membership di dominio di un Failover Cluster è sempre stata una operazione che richiedeva la distruzione e la ricreazione dell’ambiente, con un importante impatto in termini di tempo e nelle operations. In Windows Server 2019 è prevista una procedura specifica che consente di cambiare la membership ad un nuovo dominio Active Directory dei nodi del cluster, grazie all’introduzione di due nuovi comandi PowerShell:

  • New-ClusterNameAccount: crea in Active Directory un Cluster Name Account
  • Remove-ClusterNameAccount: rimuove da Active Directory un Cluster Name Account

La procedura richiede che i nodi vengano prima configurati in Workgroup e successivamente messi in Join al nuovo dominio Active Directory. Durante l’attività di migrazione è richiesto un fermo dei workloads ospitati dall’ambiente cluster.

Figura 3 – Step di migrazione di dominio di un cluster

 

Rimozione della dipendenza con l’autenticazione NTLM

Windows Server Failover Clusters non utilizza più in alcun modo l’autenticazione NTLM, ma utilizza esclusivamente l’autenticazione Kerberos e l’autenticazione basata sui certificati. Tutto ciò in Windows Server 2019 avviene in modo nativo, senza la necessità di dover fare particolari configurazioni, potendo così trarre i vantaggi conseguenti in termini di sicurezza.

 

Conclusioni

In Windows Server 2019 sono stati fatti importanti investimenti per ottenere un sistema operativo agile, adatto a scenari ibridi, maggiormente sicuro e che consente di implementare infrastrutture Hyper-converged con importanti caratteristiche in termini di scalabilità e performance. Novità come queste riportate in ambiente cluster consentono di garantire un miglior sviluppo delle aziende, offrendo elementi fondamenti per supportare il processo di innovazione e di modernizzazione del proprio datacenter.

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.