Archivi categoria: Cluster

Azure Stack HCI: introduzione alla soluzione

L’utilizzo di infrastrutture hyper-converged negli ultimi anni ha subito un forte incremento e le stime provenienti da fonti autorevoli riportano che nei prossimi 12-18 mesi l’investimento in soluzioni di questo tipo saranno tra gli quelli più significativi per la modernizzazione dei datacenter, per circa il 54% delle organizzazioni. Con l’arrivo di Windows Server 2019, Microsoft ha introdotto la soluzione Azure Stack HCI, che consente l’esecuzione di macchine virtuali ed una facile connessione ad Azure con una infrastruttura hyper-converged (HCI). In questo articolo vengono riportate le principali caratteristiche della soluzione e le relative potenzialità.

La tendenza che si sta affermando è il passaggio da una tradizionale infrastruttura “three tier”, composta da switch di rete, appliance, sistemi fisici con a bordo hypervisor, storage fabric e SAN, verso infrastrutture hyper-converged (HCI), dove vengono rimossi diversi componenti hardware, sostituti dalla “magia” del software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione.

Figura 1 – “Three Tier” Infrastructure vs Hyper-Converged Infrastructure (HCI)

Tutto ciò è reso possibile dal nuovo sistema operativo Windows Server 2019, che consente di utilizzare Hyper-V, un ormai solido e affidabile hypervisor, insieme alle soluzioni di Software Defined Storage e Software Defined Networking. A questo viene aggiunto Windows Admin Center, che consente di gestire totalmente e da interfaccia grafica l’ambiente hyper-converged. Il tutto viene implementato su hardware appositamente validato dai vari vendor.

Figura 2 – Azure Stack HCI Solution overview

Il posizionamento della soluzione Azure Stack HCI è il seguente, affiancato ad Azure ed Azure Stack, ma con scopi ben precisi e distinti.

Figura 3 – Azure Family

Azure Stack HCI è una evoluzione della soluzione Windows Server Software-Defined (WSSD) disponibile in passato con Windows Server 2016. Azure Stack HCI è stato inserito nella famiglia di Azure in quanto condivide le stesse tecnologie software-defined utilizzate anche da Azure Stack.

Azure Stack HCI consente l’esecuzione di applicazioni virtualizzate nell’ambiente on-premises, su hardware testato e validato in modo specifico. Per poter ottenere la certificazione l’hardware è sottoposto a rigorosi test di validazione, che garantiscono l’affidabilità e la stabilità della soluzione. Per consultare le differenti soluzioni Azure Stack HCI dei vari vendor hardware è possibile accedere a questa pagina.

Figura 4 – Azure Stack HCI solutions hardware partners

Un corretto dimensionamento dell’hardware è fondamentale per ottenere i risultati attesi in termini di performance e stabilità, pertanto è opportuno utilizzare sempre soluzioni hardware validate in modo specifico e non utilizzare componenti hardware assemblati a piacimento. Tale condizione è indispensabile anche per ottenere una soluzione Azure Stack HCI totalmente supportata.

Grazie all’utilizzo e al supporto delle più moderne innovazioni introdotte nei dispositivi hardware, Azure Stack HCI consente di raggiungere performance molto elevate, tanto da raggiungere un importante record di IOPS (ben 13.798.674) tra le piattaforme hyper-converged, raddoppiando le performance massime che erano state raggiunte con Windows Server 2016.

Figura 5 – Innovazioni hardware supportate da Azure Stack HCI

La soluzione hyper-converged con Windows Server 2016 vedeva un grosso limite dato dal fatto che la configurazione e la gestione dell’ambiente doveva essere fatta prevalentemente da riga di comando.

Grazie all’introduzione di Windows Admin Center si ha la possibilità di gestire e controllare totalmente l’ambiente hyper-converged da interfaccia web. Inoltre, molti vendor delle soluzioni hardware mettono a disposizione delle estensioni di Windows Admin Center per arricchire le funzionalità di management.

Nel seguente video viene mostrata la gestione di un ambiente hyper-converged da Windows Admin Center:

In ambito software-defined storage, la tecnologia Storage Space Direct consente di usufruire di molte funzionalità, che la rendono una soluzione completa, affidabile e sicura.

Figura 6 – Funzionalità in ambito software-defined storage

In Windows Server 2019 sono stati fatti importanti miglioramenti in ambito deduplica e compressione del dato che consentono di avere un quantitativo superiore di spazio storage utilizzabile.

Figura 7 – Possibili risparmi di spazio disco utilizzando deduplica e compressione

L’abilitazione avviene in modo molto semplice direttamente da Windows Admin Center.

Figura 8 – Abilitazione deduplica e compressione da Windows Admin Center

Azure Stack HCI può essere utilizzato per ambienti più piccoli con due nodi e può scalare fino ad un massimo di 16 nodi.

Figura 9 – Scalabilità della soluzione

In presenza di cluster composti esattamente da due nodi Windows Server 2019 è possibile utilizzare la Nested resiliency, una nuova funzionalità di Storage Spaces Direct, introdotta in Windows Server 2019, che consente di sostenere più fault hardware allo stesso momento senza perdere l’accesso allo storage.

Figura 10 – Fault hardware sostenuti

Utilizzando questa funzionalità si avrà a disposizione una capacità inferiore rispetto a un classico two-way mirror, ma si ottiene una maggiore affidabilità, fondamentale per infrastrutture hyper-converged, superando il limite presente nelle precedenti versioni di Windows Server in presenza di ambienti cluster composti da soli due nodi. La nested resiliency mette insieme due nuove opzioni in ambito resiliency, implementate in software e senza la necessità di hardware specifico:

  • Nested two-way mirror: in ogni server viene utilizzato localmente un two-way mirror, e una ulteriore resiliency viene garantita da un two-way mirror tra i due server. Di fatto si tratta di un four-way mirror, dove sono presenti due copie per del dato per ogni server.
  • Nested mirror-accelerated parity: viene combinato il two-way mirror, precedentemente descritto, con la nested parity.

Figura 11 – Nested two-way mirror + Nested mirror-accelerated parity

Azure Stack HCI consente di collegare le risorse on-premises al public cloud Azure per estendere il set di funzionalità, approccio totalmente differente da Azure Stack, che permette di adottare i servizi Azure on-premises, ottenendo una experience totalmente consistente al cloud pubblico, ma con risorse che risiedono nel proprio datacenter.

Figura 12 – Approccio ibrido: Azure Stack vs Azure Stack HCI

La possibilità di connettere Azure Stack HCI con i servizi Azure per ottenere una soluzione hyper-converged ibrida è un importante valore aggiunto che la differenzia fortemente da altri competitor. Anche in questo caso l’integrazione può essere fatta direttamente da Windows Admin Center per usufruire dei seguenti servizi Azure:

  • Azure Site Recovery per implementare scenari di disaster recovery.
  • Azure Monitor per tenere sotto controllo, in modo centralizzato, quello che avviene a livello applicativo, sulla rete e nella propria infrastruttura hyper-converged, con l’esecuzione di analisi avanzate tramite l’intelligenza artificiale.
  • Cloud Witness per utilizzare lo storage account di Azure come quorum del cluster.
  • Azure Backup per una protezione offsite della propria infrastruttura.
  • Azure Update Management per fare un assessment degli aggiornamenti mancanti e procedere con la relativa distribuzione, sia per macchine Windows che per sistemi Linux, indipendentemente dalla loro location, Azure oppure on-premises.
  • Azure Network Adapter per collegare facilmente le risorse on-premises con le VMs in Azure tramite una VPN point-to-site.
  • Azure Security Center per il monitoraggio e il rilevamento sulle macchine virtuali delle minacce di security.

Figura 13 – Integrazione Azure hybrid services da Windows Admin Center

Conclusioni

Microsoft ha effettuato importanti investimenti per evolvere, migliorare e rendere maggiormente affidabile e performante la propria proposizione per scenari hyper-converged. Azure Stack HCI risulta ora una soluzione matura, che supera i limiti della precedente soluzione Windows Server Software-Defined (WSSD) ed ingloba tutto il necessario per realizzare una ambiente hyper-converged in un unico prodotto ed in un’unica licenza: Windows Server 2019. La possibilità di collegare remotamente Azure Stack HCI ai vari servizi Azure la rendono inoltre una soluzione ancora più completa e funzionale.

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.