Archivi categoria: Azure Stack HCI

Massimizza le prestazioni di Azure Stack HCI: scopri le migliori configurazioni per il networking

Le infrastrutture iperconvergenti (HCI) sono sempre più diffuse in quanto consentono di semplificare la gestione dell’ambiente IT, ridurre i costi e scalare facilmente in caso di necessità. Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure per modernizzare la propria infrastruttura IT. Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire la sicurezza, l’affidabilità e le prestazioni delle applicazioni. In questo articolo, vengono esplorati i fondamenti della configurazione del networking di Azure Stack HCI, approfondendo le opzioni di rete disponibili e le best practice per la progettazione e la configurazione del networking.

Sono differenti i modelli di rete che è possibile prendere come riferimento per progettare, distribuire e configurare Azure Stack HCI. Nei paragrafi seguenti vengono riportati gli aspetti principali da considerare per indirizzare le possibili scelte di implementazione a livello di rete.

Numero di nodi che compongono il cluster Azure Stack HCI

Un singolo cluster Azure Stack HCI può essere composto da un unico nodo e può scalare fino a 16 nodi.

Se il cluster è composto da un singolo server a livello fisico è consigliato prevedere i seguenti componenti di rete, riportati anche nell’immagine:

  • singolo switch TOR (L2 oppure L3) per il traffico in direzione nord-sud;
  • due\quattro porte di rete in team per gestire il traffico di management e computazionale collegate allo switch;

Inoltre, opzionalmente è possibile prevedere i seguenti componenti:

  • due NIC RDMA, utili se si prevede di aggiunge un secondo server al cluster per scalare la configurazione;
  • una scheda BMC per la gestione remota dell’ambiente.

Figura 1 – Architettura di rete per un cluster Azure Stack HCI composto da un singolo server

Se il cluster Azure Stack HCI è composto da due o più nodi è necessario approfondire i parametri seguenti.

Necessità di switch Top-Of-Rack (TOR) e relativo livello di ridondanza

Per i cluster Azure Stack HCI composti da due o più nodi, in ambiente di produzione, è fortemente consigliata la presenza di due switch TOR, in modo da poter tollerare interruzioni delle comunicazioni riguardanti il traffico nord-sud, in caso di guasto oppure di manutenzione del singolo switch fisico.

Se il cluster Azure Stack HCI è composto da due nodi si può fare in modo di non prevedere una connettività tramite switch per il traffico riguardante lo storage.

Configurazione a due nodi senza switch TOR per la comunicazione storage

In un cluster Azure Stack HCI composto da solo due nodi, per ridurre i costi degli switch, andando magari ad utilizzare switch già in possesso, è possibile collegare in modalità full-mesh le NIC RDMA dello storage.

In determinati scenari, che includono ad esempio branch office, oppure laboratori, si può adottare il seguente modello di rete che prevede un unico switch TOR. Applicando questo modello si ottiene una tolleranza agli errori a livello di cluster, ed è idonea se è possibile tollerare interruzioni della connettività in direzione nord-sud quando il singolo switch fisico si guasta oppure richiede manutenzione.

Figura 2 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e con un unico switch TOR

Sebbene i servizi SDN L3 siano pienamente supportati per questo schema, i servizi di routing come BGP dovranno essere configurati sul dispositivo firewall che si trovano sopra allo switch TOR, se questo non supporta i servizi L3.

Nel caso si voglia ottenere una maggiore tolleranza ai guasti per tutti i componenti di rete è possibile prevedere la seguente architettura, che prevede due switch TOR ridondati:

Figura 3 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e switch TOR ridondati

I servizi SDN L3 sono pienamente supportati da questo schema. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

  • duequattro porte di rete in team, per gestire il traffico di management e computazionale, collegate alloagli switch TOR;
  • due NIC RDMA in una configurazione full-mesh per il traffico est-ovest per lo storage. Ogni nodo del cluster deve avere una connessione ridondata all’altro nodo del cluster;
  • come opzionale, una scheda BMC per la gestione remota dell’ambiente.

In entrambi i casi sono necessarie le seguenti connettività:

Reti Management e computazionale Storage BMC
Velocità di rete Almeno 1 GBps,

10 GBps recommendata

 Almeno 10 GBps Tbd
Tipologia di interfaccia RJ45, SFP+ oppure SFP28 SFP+ oppure SFP28 RJ45
Porte e aggregazione Duequattro porte in teaming Due porte standalone Una porta

Configurazione a due o più nodi utilizzando switch TOR anche per la comunicazione storage

Quando si prevede un cluster Azure Stack HCI composto da più di due nodi oppure se non si vuole precludere la possibilità di poter aggiungere facilmente ulteriori nodi al cluster, è necessario far confluire anche il traffico riguardante lo storage dagli switch TOR. In questi scenari si può prevedere una configurazione dove si mantengono delle schede di rete dedicate per il traffico storage (non-converged), come mostrato nella seguente immagine:

Figura 4 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “non-converged”

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

  • due schede di rete in team per gestire il traffico di management e computazionale. Ogni NIC è collegata a uno switch TOR diverso;
  • due NIC RDMA in configurazione standalone. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
  • come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti Management e computazionale Storage BMC
Velocità di rete Almeno 1 GBps,

10 GBps recommendata

 Almeno 10 GBps Tbd
Tipologia di interfaccia RJ45, SFP+ oppure SFP28 SFP+ oppure SFP28 RJ45
Porte e aggregazione Due porte in teaming Due porte standalone Una porta

Un’altra possibilità da tenere in considerazione prevede una configurazione “fully-converged” delle schede di rete, come riportato nella seguente immagine:

Figura 5 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “fully-converged”

Quest’ultima soluzione è preferibile quando:

  • i requisiti di larghezza di banda per il traffico nord-sud non richiedono schede dedicate;
  • le porte fisiche degli switch sono un numero ridotto;
  • si vogliono mantenere contenuti i costi della soluzione.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

  • due schede di rete RDMA in team per il traffico di management, computazionale e storage. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
  • come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti Management, computazionale e storage BMC
Velocità di rete Almeno 10 GBps Tbd
Tipologia di interfaccia SFP+ oppure SFP28 RJ45
Porte e aggregazione Due porte in teaming Una porta

I servizi SDN L3 sono pienamente supportati da entrambi i modelli sopra riportati. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

Tipologia di traffico che deve passare dagli switch TOR

Per scegliere gli switch TOR più adatti è necessario valutare il traffico di rete che confluirà da tali apparati di rete, il quale può essere suddiviso in:

  • traffico di management;
  • traffico computazionale (generato dai workload ospitati dal cluster), il quale può essere suddiviso in due categorie:
    • traffico standard;
    • traffico SDN;
  • traffico storage.

Microsoft ha recentemente cambiato l’approccio a riguardo. Infatti, non è più richiesto che gli switch TOR rispettino ogni requisito di rete riguardante le varie funzionalità, indipendentemente dal tipo di traffico per il quale lo switch viene utilizzato. Questo consente di avere switch fisici supportati in base al tipo di traffico che trasportano e permette di poter scegliere tra un maggior numero di dispositivi di rete ad un costo più contenuto, ma sempre di qualità.

In questo documento sono elencati gli standard di settore obbligatori per i ruoli specifici degli switch di rete utilizzati nelle implementazioni di Azure Stack HCI. Questi standard contribuiscono a garantire comunicazioni affidabili tra i nodi dei cluster Azure Stack HCI. In questa sezione sono invece riportati i modelli degli switch supportati dai vari vendor, in base alla tipologia di traffico prevista.

Conclusioni

Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire che l’infrastruttura hyper-converged funzioni in modo corretto, garantendo sicurezza, affidabilità e prestazioni ottimali. In questo articolo sono stati riportati i concetti fondamentali riguardanti la configurazione del networking di Azure Stack HCI, analizzando le opzioni di rete disponibili. Il consiglio è di pianificare sempre attentamente gli aspetti legati al networking di Azure Stack HCI, scegliendo l’opzione di rete più appropriata per le esigenze del vostro business e seguendo le best practice di implementazione.

Il modello di costo di Azure Stack HCI (12/2022)

Sul mercato sono disponibili tecnologie di diversi vendor che consentono di realizzare infrastrutture hyper-converged (HCI). Microsoft in questo settore propone una soluzione innovativa chiamata Azure Stack HCI, distribuita come servizio di Azure, che consente di ottenere prestazioni elevate, con funzionalità avanzate in ambito sicurezza e con un’integrazione nativa con diversi servizi Azure. In questo articolo viene descritto quanto è necessario investire per ottenere la soluzione Azure Stack HCI e quali aspetti è possibile considerare per strutturare a proprio piacimento il modello di costo.

Premessa: OPEX vs CAPEX

Il termine CAPEX (contrazione da CAPital EXpenditure, cioè le spese in conto capitale) indica il costo che si impiega per sviluppare o fornire asset durevoli per un prodotto o per un sistema.

La sua controparte, la spesa operativa oppure OPEX (dal termine inglese OPerational EXpenditure) è il costo necessario per gestire un prodotto, una soluzione oppure un sistema. Questi sono detti anche costi di O&M (Operation and Maintenance) ovvero costi operativi e di gestione.

I costi CAPEX richiedono solitamente lo stanziamento di un budget e di un piano di spesa. Anche per questi motivi, le realtà aziendali generalmente preferiscono sostenere costi OPEX, in quanto sono più facili da pianificare e da gestire.

Chiariti questi concetti, vediamo ora il modello di costo di Azure Stack HCI e come poter ottenere un modello totalmente OPEX.

Costi dell’hardware

Per poter attivare la soluzione Azure Stack HCI è necessario dotarsi dell’hardware on-premise per eseguire il sistema operativo dedicato della soluzione e per l’esecuzione dei vari workload. Esistono due possibilità:

  • Azure Stack HCI Integrated Systems: determinati vendor, offrono dei sistemi appositamente strutturati e integrati per questa soluzione, che forniscono un’esperienza simile ad una appliance. Tali soluzioni comprendono anche il supporto integrato, in modo congiunto tra il vendor e Microsoft.
  • Nodi validati Azure Stack HCI: l’implementazione avviene tramite hardware appositamente testato e validato da un vendor. In questo modo è possibile personalizzare la soluzione hardware in base alle proprie esigenze, andando a configurare il processore, la memoria, lo storage e le caratteristiche delle schede di rete, ma rispettando le matrici di compatibilità del fornitore. Sono diversi i fornitori hardware che offrono soluzioni idonee per eseguire Azure Stack HCI e possono essere consultate accedendo a questo indirizzo. La maggior parte delle implementazioni avviene secondo questa modalità.

Figura 1 – Scenari di deployment dell’hardware

Anche per l’hardware è possibile fare alcune valutazioni per adottare un modello di costo basato sul noleggio. Infatti, i principali vendor come HPE, Dell e Lenovo, sono in grado di offrire l’hardware necessario in modalità “infrastructure as-a-service”, mediante un modello di pagamento in base all’uso.

Costi Azure

Nonostante sia in esecuzione on-premise, Azure Stack HCI prevede una fatturazione basata su subscription Azure, esattamente come per qualsiasi altro servizio nel cloud pubblico di Microsoft.

Azure Stack HCI offre un periodo di prova gratuito che consente di valutare nel dettaglio la soluzione. La durata di questo periodo è pari a 60 giorni e inizia da quando si completa la registrazione dell’ambiente cluster in Azure.

Al termine del periodo di prova, il modello è semplice e prevede un costo di “10 € / core fisico / mese”*. Il costo è quindi dato dal totale dei core fisici presenti nei processori del cluster Azure Stack HCI. Questo modello non prevede un minimo oppure un massimo sul numero di core fisici licenziati e tanto meno dei limiti riguardanti la durata di attivazione.

Vantaggi economici per i clienti con un contratto di Software Assurance

I clienti che dispongono di licenze Windows Server Datacenter con Software Assurance attiva, possono attivare l’Azure Hybrid Benefit anche per il proprio cluster Azure Stack HCI. Per attivare questo vantaggio, senza costi aggiuntivi, sarà necessario scambiare una licenza core di Windows Server Datacenter con Software Assurance per un core fisico di Azure Stack HCI. Questo aspetto permette di azzerare i costi Azure per il canone degli host Azure Stack HCI e fornisce il diritto ad eseguire un numero illimitato di macchine virtuali guest Windows Server sul cluster Azure Stack HCI.

Inoltre, è possibile attivare gli Azure Hybrid Benefit anche per Azure Kubernetes Service (AKS). In questo caso sono richieste licenze Windows Server StandardDatacenter con Software Assurance attiva, oppure la presenza di una subscription Cloud Solution Provider (CSP). Ogni licenza di Windows Server core dà diritto all’uso di un core virtuale di AKS.

Nell’immagine seguente viene sintetizzato come, i clienti con Software Assurance, possono utilizzare Azure Hybrid Benefit per ridurre ulteriormente i costi nel cloud, nei datacenter on-premises e nelle sedi periferiche.

Figura 2 – Cosa include l’Azure Hybrid Benefit per i clienti in Software Assurance

In particolare per i clienti con un contratto di Software Assurance, l’adozione di Azure Stack HCI si traduce in una riduzione drastica dei costi di modernizzazione dell’ambiente di virtualizzazione, rendendo questa soluzione ancora più competitiva dal punto di vista dei costi rispetto ai competitor sul mercato. Per consultare nel dettaglio i requisiti di licensing è possibile fare riferimento a questo documento.

Costi per le macchine virtuali guest

Nei costi Azure riportati nel paragrafo precedente non sono inclusi i costi del sistema operativo per le macchine guest in esecuzione nell’ambiente Azure Stack HCI. Questo aspetto è comune anche ad altre piattaforme HCI, come Nutanix e VMware vSAN.

Nell’immagine seguente è schematizzato come può avvenire il licenziamento dei sistemi operativi guest:

Figura 3 – Licenziamento dei sistemi operativi guest

Costi per le macchine virtuali Windows Server

Per licenziare le macchine guest Windows Server in Azure Stack HCI esistono principalmente due opzioni:

  • Acquistare licenze Windows Server (modalità CAPEX), Standard oppure Datacenter, le quali includono il diritto di attivare il SO delle macchine virtuali guest. La Standard Edition può essere adatta se il numero di macchine guest Windows Server è limitato, mentre se sono presenti diversi sistemi guest Windows Server è opportuno valutare la Datacenter Edition che dà diritto all’attivazione di un numero illimitato di sistemi virtualizzati Windows Server.
  • Pagare la licenza di Windows Server per i sistemi guest tramite la propria subscription Azure, proprio come avviene in ambiente Azure. Scegliendo questa opzione si dovrà sostenere un costo (OPEX) pari a “22.4 € / core fisico / mese”* per avere la possibilità di attivare un numero illimitato di sistemi guest Windows Server in ambiente Azure Stack HCI.

*Costi stimati per la region West Europe e soggetti a modifiche. Per maggiori dettagli sui costi di Azure Stack HCI potete consultare la pagina ufficiale Microsoft.

Costi per altri workload in esecuzione su Azure Stack HCI

Il risultato che si intende perseguire con l’infrastruttura Azure Stack HCI è quello di poter eseguire in ambiente on-premises non solo macchine virtuali, ma gli stessi workload del cloud pubblico Microsoft. Per raggiungerlo Microsoft sta portando i workload di Azure più popolari in Azure Stack HCI e per ciascuno di questi valgono le seguenti considerazioni sui costi:

  • Azure Kubernetes Service: la configurazione del cluster K8s Arc enabled è gratuita**.
  • Azure Arc-enabled data services:
    • Per SQL Server i clienti possono acquistare licenze SQL Server in modalità CAPEX oppure, chi dispone già di licenze SQL, può usare Azure Hybrid Benefit per Azure Arc-enabled SQL Managed Instance, senza la necessità di dover pagare nuovamente la licenza SQL.
    • Nel caso si voglia passare a un modello OPEX è possibile ottenere le licenze di Microsoft SQL Server tramite i servizi dati abilitati per Azure Arc di Microsoft**.
  • Azure Virtual Desktop:
    • Diritti di accesso utente per Azure Virtual Desktop. Le stesse licenze che concedono l’accesso ai desktop virtuali di Azure nel cloud si applicano anche ad Azure Virtual Desktop in Azure Stack HCI.
    • Tariffa del servizio ibrido Azure Virtual Desktop. Questa tariffa prevede un costo per ogni CPU virtuale (vCPU) utilizzata dai session host di Azure Virtual Desktop in esecuzione in ambiente Azure Stack HCI.

**Per maggiori dettagli sui costi di Azure Arc è possibile consultare questa pagina.

Costi per il supporto

Azure Stack HCI, essendo a tutti gli effetti una soluzione Azure, è coperta dal supporto Azure con le seguenti caratteristiche:

  • Viene fornita la possibilità di scegliere tra diversi piani di supporto Azure, a seconda delle esigenze. Il supporto Basic è gratuito, ma in determinati scenari è consigliato valutare almeno il supporto Standard, che prevede un costo fisso mensile.
  • Il supporto tecnico è fornito da un team di esperti dedicato a supportare la soluzione Azure Stack HCI e si può richiedere facilmente direttamente dal portale Azure.

Conclusioni

Azure Stack HCI consente di portare l’innovazione del cloud all’interno del proprio datacenter e al tempo stesso di creare un collegamento strategico verso Azure. Nell’era dei datacenter ibridi, una soluzione come Azure Stack HCI, consente di strutturare a piacimento il modello di costo e di avere la massima flessibilità. Sul mercato ci sono diversi vendor che offrono soluzioni per realizzare infrastrutture hyper-converged (HCI) ibride, ed Azure Stack HCI può risultare molto competitivo, non solo dal punto di vista delle funzionalità, ma anche dal punto di vista dei costi.

4 buoni motivi per scegliere Azure Stack HCI

Il cloud computing è sempre più popolare per le aziende che vogliono semplificare la gestione ed ottenere una maggiore scalabilità del loro ambiente IT. Tuttavia, molte organizzazioni continuano ad utilizzare infrastrutture presso i loro datacenter per diversi motivi, che spaziano dall’esigenza di garantire supporto ai workload legacy, alla necessità di rispettare specifici requisiti tecnici e normativi. In questo articolo vengono riportati i principali motivi per i quali è opportuno valutare l’adozione di Azure Stack HCI rispetto ad altre soluzioni di virtualizzazione on-premises.

Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Azure Stack HCI è stato appositamente progettato da Microsoft per aiutare i clienti a modernizzare il proprio datacenter ibrido, offrendo un’esperienza Azure completa e familiare in ambiente on-premises. Se vi un approfondimento sulla soluzione Microsoft Azure Stack HCI vi invito a leggere questo articolo oppure a visualizzare questo video.

Figura 1 – Panoramica di Azure Stack HCI

Confrontandomi quotidianamente con i clienti, spesso mi viene chiesto perché dovrebbero scegliere Azure Stack HCI rispetto ad altre soluzioni note presenti da tempo sul mercato. Nei paragrafi seguenti vi riporto quelle che, a mio modo di vedere, sono i motivi principali che fanno propendere per l’adozione di Azure Stack HCI.

1. Modernizzare la propria infrastruttura on-premises portando innovazione

Azure Stack HCI non è sinonimo di ambiente di virtualizzazione, ma consente di ottenere molto di più. Infatti, risulta ideale se si vuole modernizzare la propria infrastruttura, adottando un’architettura hyper-converged che consente di:

  • Attivare macchine virtuali basandosi su tecnologie consolidate che rendono l’ambiente stabile e in alta disponibilità, particolarmente adatto anche per workload che richiedono elevate performance ed alta scalabilità.
  • Distribuire e gestire applicazioni moderne basate su micro-servizi, parallelamente alle macchine virtuali, sullo stesso ambiente cluster, adottando Azure Kubernetes Service (AKS). Oltre a poter eseguire app Windows e Linux in conteiner, AKS rende disponibile l’infrastruttura per eseguire dei servizi PaaS selezionati della piattaforma Azure in ambiente on-premises, grazie ad Azure Arc.
  • Attivare macchine virtuali con Windows Server 2022 edizione Azure Datacenter, che offre funzionalità specifiche non disponibili nelle classiche edizioni Standard e Datacenter. Per approfondire le caratteristiche disponibili in questa edizione è possibile consultare questo articolo.
  • Creare pool di session host di Azure Virtual Desktop utilizzando macchine virtuali in esecuzione on-premises. Tale scenario ibrido diventa interessante in situazioni dove le applicazioni risultano sensibili alla latenza, come ad esempio l’editing video, oppure scenari dove gli utenti hanno bisogno di usufruire di un sistema legacy presente on-premises che non può essere facilmente raggiunto.
  • Estendere le funzionalità della soluzione on-premises connettendosi a vari servizi Azure come Azure Site Recovery, Azure Backup, Azure Monitor e Defender for Cloud. Questo aspetto garantisce una innovazione costante, data della continua evoluzione dei servizi cloud.

2. Ottimizzare i costi

Il modello di costo di Azure Stack HCI, descritto nel dettaglio in questo articolo, risulta molto semplice.

In particolare, per i clienti con un contratto di Software Assurance, l’adozione di Azure Stack HCI si traduce in una riduzione drastica dei costi di modernizzazione dell’ambiente di virtualizzazione, rendendo questa soluzione ancora più competitiva dal punto di vista dei costi rispetto ai competitor sul mercato. Recentemente, facendo una comparativa dei costi tra Azure Stack HCI e VMware vSphere + vSAN su una proiezione di 3 anni, è emerso come Azure Stack HCI consente di ottenere un risparmio fino al 40%.

3. Aumentare il livello di sicurezza

Azure Stack HCI offre una sicurezza trasversale su hardware e firmware, integrata nelle funzionalità del sistema operativo, in grado di aiutare a proteggere i server da minacce avanzate. Infatti, i sistemi Azure Stack HCI, possono adottare le funzionalità di sicurezza di Secured-core, il tutto tramite una facile esperienza di configurazione da Windows Admin Center.

Inoltre, Azure Stack HCI consente di ottenere gratuitamente, proprio come in Azure, importanti patch di sicurezza per i prodotti legacy di Microsoft che hanno superato il termine del supporto, tramite il programma Extended Security Update (ESU). Al momento vale per Windows Server 2008/R2 e verrà presto applicato anche a Windows Server 2012/R2 quando si raggiungerà la fine del supporto, oltre alle versioni corrispondenti di SQL Server. Questo consente di avere più tempo per intraprendere un percorso di modernizzazione applicativa, senza trascurare gli aspetti della sicurezza.

4. Massimizzare gli investimenti già fatti

Azure Stack HCI è in grado di integrarsi con l’ambiente esistente e con le più diffuse soluzioni di terze parti. Pertanto, l’adozione di questa soluzione non richiede nuovi investimenti per introdurre oppure adeguare le soluzioni di gestione, identità, sicurezza e protezione.

In particolare, la gestione amministrativa di Azure Stack HCI non richiede software specifici, ma è possibile adottare gli strumenti di gestione esistenti come Admin Center, PowerShell, System Center Virtual Machine Manager e persino strumenti di terze parti. Inoltre, adottando Azure Stack HCI ed Azure Arc è possibile applicare i modelli di gestione del cloud anche all’ambiente on-premises, semplificando notevolmente l’esperienza di utilizzo.

Azure Stack HCI consente di sfruttare a pieno non solo gli investimenti già effettuati in merito agli strumenti, ma anche per quanto riguarda le competenze del personale IT.

Conclusioni

Microsoft ha portato in Azure Stack HCI l’innovazione del cloud e l’esperienza maturata nel gestire tra i più grandi data center del mondo. I clienti, a loro volta, adottando Azure Stack HCI possono modernizzare il loro datacenter on-premises, salvaguardando gli investimenti effettuati e quelli futuri, senza trascurare gli aspetti legati alla sicurezza e all’integrazione. Le motivazioni descritte in questo articolo sono particolarmente importanti, al punto di aver portato già diversi clienti a scegliere Azure Stack HCI rispetto ad altre soluzioni in quest’ambito.

Azure Stack HCI: la soluzione hyper-converged in continua evoluzione – edizione di novembre 2022

Azure Stack HCI è la soluzione che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Anche Azure Stack HCI viene considerato come servizio hybrid di Azure e come tale è in continua evoluzione. Recentemente Microsoft ha introdotto una serie di nuove funzionalità che aprono la strada a nuovi scenari di adozione di Azure Stack HCI e che consentono di gestire al meglio la propria infrastruttura ibrida basata su questa soluzione. In questo articolo vengono riportati i principali aspetti che hanno subito un’evoluzione e le nuove funzionalità recentemente introdotte in Azure Stack HCI.

Vantaggi economici per i clienti con un contratto di Software Assurance

I clienti che dispongono di licenze Windows Server Datacenter con Software Assurance attiva, possono attivare l’Azure Hybrid Benefit anche per il proprio cluster Azure Stack HCI. Per attivare questo vantaggio, senza costi aggiuntivi, sarà necessario scambiare una licenza core di Windows Server Datacenter con Software Assurance per un core fisico di Azure Stack HCI. Questo aspetto permette di azzerare i costi Azure per il canone degli host Azure Stack HCI e fornisce il diritto ad eseguire un numero illimitato di macchine virtuali guest Windows Server sul cluster Azure Stack HCI.

Inoltre, è possibile attivare gli Azure Hybrid Benefit anche per Azure Kubernetes Service (AKS). In questo caso sono richieste licenze Windows Server StandardDatacenter con Software Assurance attiva, oppure la presenza di una subscription Cloud Solution Provider (CSP). Ogni licenza di Windows Server core dà diritto all’uso di un core virtuale di AKS.

Nell’immagine seguente viene sintetizzato come, i clienti con Software Assurance, possono utilizzare Azure Hybrid Benefit per ridurre ulteriormente i costi nel cloud, nei datacenter on-premises e nelle sedi periferiche.

Figura 1 – Cosa include l’Azure Hybrid Benefit per i clienti in Software Assurance

In particolare per i clienti con un contratto di Software Assurance, l’adozione di Azure Stack HCI si traduce in una riduzione drastica dei costi di modernizzazione dell’ambiente di virtualizzazione, rendendo questa soluzione ancora più competitiva dal punto di vista dei costi rispetto ai competitor sul mercato. Per consultare nel dettaglio i requisiti di licensing è possibile fare riferimento a questo documento.

Aggiornamento 22H2

Il nuovo aggiornamento, conosciuto come “versione 22H2” oppure “22H2 feature update”, è stato rilasciato ufficialmente ed è pronto per l’utilizzo in ambiente produzione. Questa versione apporta su diversi fronti della soluzione una maggiore qualità.

Nei punti seguenti vengono riportate sinteticamente le varie funzionalità e i diversi miglioramenti introdotti al sistema operativo Azure Stack HCI, versione 22H2:

  • Network ATC v2 è in grado di assegnare automaticamente gli indirizzi IP alle reti storage intra-cluster e di nominare automaticamente le reti del cluster in base all’uso previsto. Può anche gestire le impostazioni della live migration, come la selezione della rete, del trasporto e l’allocazione della larghezza di banda.
  • La gestione dello storage è più flessibile in quanto è possibile modificare i volumi storage esistenti per aumentarne la resilienza (ad esempio, passando da un two-way a un three-way mirror) oppure effettuare una conversione in-place da provisioning di tipologia fixed verso uno di tipologia thin.
  • La replica dello storage in uno stretched cluster è più veloce grazie alla nuova possibilità opzionale di compressione.
  • La live migration di Hyper-V è più affidabile per i cluster a 2 e a 3 nodi senza la presenza di switch specifici.
  • Lato networking è inoltre disponibile una nuova possibilità di segmentazione della rete basata su tag, che consente di proteggere i workload virtualizzati dalle minacce in base a tag personalizzati che vengono assegnati.

Per consultare tutti i dettagli relativi alla versione 22H2 è possibile consultare questo documento.

Tutti i cluster Azure Stack HCI esistenti possono ricevere l’aggiornamento 22H2 come aggiornamento gratuito over-the-air ed è possibile applicare l’aggiornamento senza interruzioni grazie all’aggiornamento cluster-aware. Microsoft raccomanda la versione 22H2 per tutte le nuove implementazioni di Azure Stack HCI.

Anche gli strumenti di gestione sono stati rinnovati per supportare le funzionalità di questo nuovo aggiornamento. Infatti, è possibile utilizzare Windows Admin Center per gestire la versione 22H2. Inoltre, viene mantenuta la compatibilità con System Center Virtual Machine Manager e con Operations Manager, grazie al primo Update Rollup (UR1) per System Center 2022, che aggiungerà il supporto ufficiale per Azure Stack HCI, versione 22H2.

Azure Arc-enabled VM management

Adottando Azure Stack HCI ed Azure Arc è possibile applicare i modelli di gestione del cloud anche all’ambiente on-premises. All’inizio dell’anno Microsoft ha rilasciato l’anteprima pubblica per la gestione delle macchine virtuali abilitate ad Azure Arc, che consente di distribuire le macchine virtuali su Azure Stack HCI tramite ARM, Azure CLI e portale Azure.

In questo ambito sono state introdotte nuove importanti funzionalità:

  • Oltre all’utilizzo di immagini personalizzate, è ora possibile accedere alle immagini direttamente dal Marketplace Azure. In modo rapido è così possibile distribuire le ultime immagini Microsoft completamente aggiornate, tra le quali Windows Server 2022 Azure Edition con hotpatching e Windows 11 Enterprise multi-session per Azure Virtual Desktop. In futuro saranno disponibili anche immagini di terzi parti. Questa funzionalità è integrata in modo nativo in Azure Arc ed è stata progettata per rispettare la larghezza di banda della rete. Infatti, le immagini sono ottimizzate per ridurre al minimo le dimensioni dei file ed è sufficiente scaricarle una sola volta per creare anche diverse macchine virtuali.
  • Quando si distribuisce una nuova VM in Azure Stack HCI attraverso Azure Arc, il sistema operativo guest è ora automaticamente abilitato ad Arc. Ciò significa che è possibile utilizzare estensioni per le VMs, come Domain Join oppure Custom Script per distribuire e configurare le applicazioni. In futuro saranno disponibili anche altre estensioni.

Servizio Kubernetes ibrido di Azure

Molte realtà aziendali hanno un mix di applicazioni obsolete in ambiente di virtualizzazione e nuove applicazioni basate su container. Adottando Azure Kubernetes Service (AKS) in ambiente Azure Stack HCI è possibile distribuire e gestire applicazioni containerizzate parallelamente alle macchine virtuali, sullo stesso server fisico o ambiente cluster.

L’aggiornamento di settembre 2022 per AKS su Azure Stack HCI ha introdotto alcuni miglioramenti significativi, tra i quali:

  • L’immagine di base del container Linux è stata aggiornata a Mariner 2.0, che è più ridotta come dimensioni e più sicura.
  • L’integrazione del software-defined networking (SDN) è disponibile e pronta per essere utilizzata in ambiente di produzione.
  • La procedura per collegare le GPU ai container è stata semplificata.
  • Viene introdotta la possibilità di utilizzare qualsiasi account del gruppo degli Amministratori di sistema per gestire AKS.

Recentemente è stata inoltre introdotta la possibilità di effettuare il provisioning di cluster AKS ibridi direttamente da Azure, utilizzando un’identità AAD. La distribuzione di nuovi cluster Kubernetes nell’ambiente on-premises avviene mediante l’Arc Resource Bridge, in modo molto simile alla gestione delle macchine virtuali abilitate ad Arc. Si tratta di un’evoluzione importante verso un’esperienza di provisioning delle applicazioni end-to-end semplice e uniforme, che abbraccia il cloud e l’edge.

Hardware progettato, spedito e supportato direttamente da Microsoft

Microsoft ha annunciato che nel 2023 offrirà un sistema Azure Stack HCI basato su hardware progettato, spedito e supportato direttamente dalla casa di Redmond.

La soluzione, chiamata “Pro 2”, ha le seguenti caratteristiche:

  • Form factor compatto di sole 2U a metà profondità, ideale anche per le implementazione al di fuori dei data center (es. retail, manufacturing e ambienti sanitari).
  • Resistente alle manomissioni.
  • Abbastanza silenzioso per un ambiente d’ufficio, generando meno di 60 dBA di rumore acustico.
  • Ordinabile direttamente dal portale Azure e fornito con Azure Stack HCI preinstallato.
  • Disponibile in diverse configurazioni, con specifiche adatte a differenti casi d’uso.
  • Gestione dell’hardware totalmente integrata con gli strumenti di gestione dei cluster esistenti, compresa una nuova estensione di Windows Admin Center in fase di sviluppo.

Questo prossimo rilascio consente ai clienti di adottare un modello di business coerente tra il cloud e l’edge: un modello di pagamento OPEX con la possibilità di utilizzare i commitment Azure per ottenere una soluzione Microsoft completa, compreso l’hardware.

Conclusioni

Grazie ad un costante miglioramento, all’introduzione continua di nuove funzionalità ed all’inclusione di nuovi scenari di utilizzo, la proposizione Microsoft per scenari hyper-converged risulta sempre più completa, integrata e performante. Azure Stack HCI si integra perfettamente all’ambiente on-premises esistente ed offre un importante valore aggiunto: la possibilità di connettere Azure Stack HCI con altri servizi Azure per ottenere una soluzione hyper-converged ibrida. Questo aspetto in particolare la differenzia fortemente da altri competitor che offrono soluzioni in questo ambito.

Il modello di costo di Azure Stack HCI

Sul mercato sono disponibili tecnologie di diversi vendor che consentono di realizzare infrastrutture hyper-converged (HCI). Microsoft in questo settore propone una soluzione innovativa chiamata Azure Stack HCI, distribuita come servizio di Azure, che consente di ottenere prestazioni elevate, le più recenti funzionalità in ambito sicurezza e un’integrazione nativa con i servizi Azure. In questo articolo viene descritto quanto è necessario investire per ottenere la soluzione Azure Stack HCI e quali aspetti è possibile considerare per strutturare a proprio piacimento il modello di costo.

Premessa: OPEX vs CAPEX

Il termine CAPEX (contrazione da CAPital EXpenditure, cioè le spese in conto capitale) indica il costo che si impiega per sviluppare o fornire asset durevoli per un prodotto o per un sistema.

La sua controparte, la spesa operativa oppure OPEX (dal termine inglese OPerational EXpenditure) è il costo necessario per gestire un prodotto, una soluzione oppure un sistema. Questi sono detti anche costi di O&M (Operation and Maintenance) ovvero costi operativi e di gestione.

I costi CAPEX richiedono solitamente lo stanziamento di un budget e di un piano di spesa. Anche per questi motivi, le realtà aziendali generalmente preferiscono sostenere costi OPEX, in quanto sono più facili da pianificare e da gestire.

Chiariti questi concetti, vediamo ora il modello di costo di Azure Stack HCI e come poter ottenere un modello totalmente OPEX.

Costi dell’hardware

Per poter attivare la soluzione Azure Stack HCI è necessario dotarsi dell’hardware on-premise per eseguire il sistema operativo dedicato della soluzione e per l’esecuzione dei vari workload. Esistono due possibilità:

  • Azure Stack HCI Integrated Systems: determinati vendor, offrono dei sistemi appositamente strutturati e integrati per questa soluzione, che forniscono un’esperienza simile ad una appliance. Tali soluzioni comprendono anche il supporto integrato, in modo congiunto tra il vendor e Microsoft.
  • Nodi validati Azure Stack HCI: l’implementazione avviene tramite hardware appositamente testato e validato da un vendor. In questo modo è possibile personalizzare la soluzione hardware in base alle proprie esigenze, andando a configurare il processore, la memoria, lo storage e le caratteristiche delle schede di rete, ma rispettando le matrici di compatibilità del fornitore. Sono diversi i fornitori hardware che offrono soluzioni idonee per eseguire Azure Stack HCIe possono essere consultate accedendo a questo indirizzo. La maggior parte delle implementazioni avviene secondo questa modalità.

Figura 1 – Scenari di deployment dell’hardware

Anche per l’hardware è possibile fare alcune valutazioni per adottare un modello di costo basato sul noleggio. Infatti, i principali vendor come HPE, Dell e Lenovo, sono in grado di offrire l’hardware necessario in modalità “infrastructure as-a-service”, mediante un modello di pagamento in base all’uso.

Costi Azure

Nonostante sia in esecuzione on-premise, Azure Stack HCI prevede una fatturazione basata su subscription Azure, esattamente come per qualsiasi altro servizio nel cloud pubblico di Microsoft.

Azure Stack HCI offre un periodo di prova gratuito che consente di valutare nel dettaglio la soluzione. La durata di questo periodo è pari a 60 giorni e inizia da quando si completa la registrazione dell’ambiente cluster in Azure.

Al termine del periodo di prova, il modello è semplice e prevede un costo di “10 € / core fisico / mese”*. Il costo è quindi dato dal totale dei core fisici presenti nei processori del cluster Azure Stack HCI. Questo modello non prevede un minimo oppure un massimo sul numero di core fisici licenziati e tanto meno dei limiti riguardanti la durata di attivazione.

Costi per le macchine Windows Server

Nei costi Azure riportati nel paragrafo precedente non sono inclusi i costi del sistema operativo per le macchine guest in esecuzione nell’ambiente Azure Stack HCI. Questo aspetto è comune anche ad altre piattaforme HCI, come Nutanix e VMware vSAN. Per licenziare le macchine guest Windows Server in Azure Stack HCI esistono due opzioni:

  • Acquistare licenze Windows Server (modalità CAPEX), Standard oppure Datacenter, le quali includono il diritto di attivare il SO delle macchine virtuali guest. La Standard Edition può essere adatta se il numero di macchine guest Windows Server è limitato, mentre se sono presenti diversi sistemi guest Windows Server è opportuno valutare la Datacenter Edition che dà diritto all’attivazione di un numero illimitato di sistemi virtualizzati Windows Server.
  • Pagare la licenza di Windows Server per i sistemi guest tramite la propria subscription Azure, proprio come avviene in ambiente Azure. Scegliendo questa opzione si dovrà sostenere un costo (OPEX) pari a “22.2 € / core fisico / mese”* per avere la possibilità di attivare un numero illimitato di sistemi guest Windows Server in ambiente Azure Stack HCI.

*Costi stimati per la region West Europe e soggetti a modifiche. Per maggiori dettagli sui costi di Azure Stack HCI potete consultare la pagina ufficiale Microsoft.

Costi per altri workload in esecuzione su Azure Stack HCI

Il risultato che si intende perseguire con l’infrastruttura Azure Stack HCI è quello di poter eseguire in ambiente on-premises non solo macchine virtuali, ma gli stessi workload del cloud pubblico Microsoft. Per raggiungerlo Microsoft sta portando i workload di Azure più popolari in Azure Stack HCI e per ciascuno di questi valgono le seguenti considerazioni sui costi:

  • Azure Kubernetes Service: la configurazione del cluster K8s Arc enabled è gratuita**.
  • Azure Arc-enabled data services:
    • Per SQL Server i clienti possono acquistare licenze SQL Server in modalità CAPEX oppure, chi dispone già di licenze SQL, può usare Azure Hybrid Benefit per Azure Arc-enabled SQL Managed Instance, senza la necessità di dover pagare nuovamente la licenza SQL.
    • Nel caso si voglia passare a un modello OPEX è possibile ottenere le licenze di Microsoft SQL Server tramite i servizi dati abilitati per Azure Arc di Microsoft**.
  • Azure Virtual Desktop:
    • Diritti di accesso utente per Azure Virtual Desktop. Le stesse licenze che concedono l’accesso ai desktop virtuali di Azure nel cloud si applicano anche ad Azure Virtual Desktop in Azure Stack HCI.
    • Tariffa del servizio ibrido Azure Virtual Desktop. Questa tariffa prevede un costo per ogni CPU virtuale (vCPU) utilizzata dai session host di Azure Virtual Desktop in esecuzione in ambiente Azure Stack HCI.

**Per maggiori dettagli sui costi di Azure Arc è possibile consultare questa pagina.

Costi per il supporto

Azure Stack HCI, essendo a tutti gli effetti una soluzione Azure, è coperta dal supporto Azure con le seguenti caratteristiche:

  • Viene fornita la possibilità di scegliere tra diversi piani di supporto Azure, a seconda delle esigenze. Il supporto Basic è gratuito, ma in determinati scenari è consigliato valutare almeno il supporto Standard, che prevede un costo fisso mensile.
  • Il supporto è fornito da un team di esperti dedicato a supportare la soluzione Azure Stack HCI.
  • Si può richiedere facilmente supporto tecnico direttamente dal portale Azure.

Conclusioni

Azure Stack HCI consente di portare l’innovazione del cloud all’interno del proprio datacenter e al tempo stesso di creare un ponte di collegamento verso Azure. Nell’era dei datacenter ibridi, una soluzione come Azure Stack HCI, consente di strutturare a proprio piacimento il modello di costo e di avere la massima flessibilità. Sul mercato ci sono diversi vendor che offrono soluzioni per realizzare infrastrutture hyper-converged (HCI) ibride, ed Azure Stack HCI può risultare molto competitivo, non solo dal punto di vista delle funzionalità, ma anche dal punto di vista dei costi.

Come modernizzare l’infrastruttura e ottenere i vantaggi di Azure con un singolo server on-premises

Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione dei workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Recentemente Microsoft ha introdotto la possibilità di creare un cluster Azure Stack HCI composto da un singolo server. Questa possibilità apre nuovi scenari per quanto riguarda l’adozione di questa soluzione. In questo articolo vengono riportati i principali casi d’uso, gli aspetti da considerare e i benefici che si possono ottenere attivando Azure Stack HCI su un singolo sistema server.

In una infrastruttura hyper-converged (HCI), vengono rimossi diversi componenti hardware, sostituti dal software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione. In questo modo si ha un 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).

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

Azure Stack HCI è uno stack composto da hardware e software che i clienti utilizzano anche per le potenzialità date dall’integrazione semplice con il cloud Microsoft Azure.

Casi d’uso di Azure Stack HCI composto da più nodi

L’utilizzo di una configurazione Azure Stack HCI standard composta da più nodi è idoneo se:

  • Si vuole modernizzare la propria infrastruttura, adottando un’architettura hyper-converged semplice e basata su tecnologie consolidate. Ideale sia per i workload esistenti nel datacenter principale sia per scenari di branch office che richiedono una elevata resilienza.
  • Si vuole prevedere un’estensione delle funzionalità della soluzione on-premises, che garantisce resilienza, connettendosi ad Azure. Questo aspetto garantisce una innovazione costante, data dell’evoluzione dei servizi cloud e la possibilità di usufruire di un set strumenti comune, semplificando l’esperienza di utilizzo.
  • Si vuole una soluzione idonea per ospitare workload che richiedono elevate performance ed alta scalabilità.
  • Si ritiene utile innovare il proprio datacenter, in quanto si ha la possibilità di attivare cluster AKS e distribuire app cloud native e servizi abilitati per Azure Arc in alta disponibilità. Tutto questo grazie alla stretta integrazione di AKS in ambiente Azure Stack HCI.

Figura 2 – Casi d’uso di Azure Stack HCI con più nodi

Casi d’uso di Azure Stack HCI con un singolo nodo

Grazie alla possibilità di attivare un cluster Azure Stack HCI anche con un solo server si ha la facoltà di contemplare nuovi scenari di utilizzo, tra i quali:

  • Attivazione di Azure Stack HCI in ambienti dove non ci sono particolari esigenze in termini di resilienza, come ad esempio i branch office.
  • Adozione di una soluzione in ambienti dove è richiesta la possibilità di scalare facilmente, partendo inizialmente da un singolo nodo per arrivare potenzialmente fino a 16 nodi, se necessario.
  • Necessità di attivare una soluzione con un ingombro ridotto, magari in location con vincoli di spazio fisico e che al tempo stesso permetta di mantenere contenuti i costi hardware ed i costi operativi.
  • Possibilità di creare e mantenere più facilmente ambienti di test e sviluppo.

Funzionalità a confronto tra cluster Azure Stack HCI a singolo nodo e multinodo

Dal punto di vista delle funzionalità, i cluster Azure Stack HCI composti da un singolo nodo offrono un set di funzionalità molto simile ai cluster tradizionali costituiti da più nodi, come:

  • L’integrazione nativa con Azure Arc, elemento chiave per l’innovazione e la modernizzazione della propria infrastruttura.
  • Possibilità di aggiungere server orizzontalmente per aumentare la scalabilità dell’ambiente cluster.
  • L’integrazione con i servizi Azure.
  • Il supporto degli stessi workload, come Azure Virtual Desktop (AVD) e Azure Kubernetes Service (AKS).

Per una comparativa completa delle funzionalità è possibile consultare questo documento Microsoft.

I cluster Azure Stack HCI composti da un nodo singolo hanno al momento le seguenti limitazioni:

  • L’installazione deve avvenire utilizzando comandi PowerShell e non è ancora disponibile il supporto per la configurazione mediante Windows Admin Center.
  • Sono resilienti ad alcuni errori, ad esempio la presenza di un disco guasto, ma le capacità limitate in termini di resilienza impongono che devono essere composti solamente da una tipologia di unità disco, NVMe oppure SSD (non combinabili tra loro). Questo implica che non c’è la possibilità di avere livelli di cache.
  • Non tutti i fornitori hardware dispongono al momento di soluzioni supportate. Per verificare la disponibilità è possibile consultare il catalogo Microsoft delle soluzioni Azure Stack HCI.

Conclusioni

La possibilità di attivare con un solo server fisico un cluster Azure Stack HCI introduce una maggiore flessibilità e amplia notevolmente le possibilità di adozione di questa soluzione. Inoltre, questa scelta denota come Azure Stack HCI sia il futuro della virtualizzazione e delle soluzioni software-defined in casa Microsoft. Adottando Azure Stack HCI è possibile portare innovazione anche all’interno del proprio datacenter grazie ad una soluzione che viene aggiornata costantemente ed in grado di integrarsi facilmente con i servizi Azure.

La modernizzazione del datacenter: un caso reale con soluzioni Microsoft

I dati statistici parlano chiaro, oltre il 90% delle realtà aziendali dispongono già oppure prevedono, nel breve periodo, di adottare una strategia ibrida per la propria infrastruttura IT. Questi dati vengono confermati dalla quotidianità dei fatti, dove diversi clienti includono nei loro piani di investimento sia il mantenimento dei workload sulle infrastrutture on-premises, sia l’adozione di soluzioni nel cloud pubblico. Parallelamente viene affiancato un percorso di modernizzazione delle applicazioni con l’obiettivo di sfruttare al meglio le potenzialità e l’innovazione offerte da queste infrastrutture. Viviamo quindi nell’era del cloud ibrido e Microsoft mette a disposizioni diverse soluzioni interessanti per modernizzare il proprio datacenter e gestire agilmente la propria infrastruttura ibrida. In questo articolo viene portato un esempio reale di come un cliente ha intrapreso il percorso di modernizzazione del proprio datacenter grazie ad Azure Stack HCI e come, tramite Azure Arc, è stato in grado di estendere i servizi ed i principi di gestione di Azure anche alla propria infrastruttura on-premises.

Richiesta iniziale del cliente e problematiche da risolvere

Il cliente in questione voleva attivare presso il proprio datacenter una nuova infrastruttura di virtualizzazione moderna ed integrata, per consentire di configurare in modo rapido, dinamico e flessibile i workload applicativi. L’infrastruttura in uso dal cliente non era adeguata e riscontrava diverse problematiche, tra le quali:

  • Soluzione di virtualizzazione non scalabile e poco flessibile
  • Obsolescenza hardware
  • Configurazioni che non garantivano una disponibilità adeguata dei sistemi virtualizzati
  • Problemi di performance e di stabilità
  • Difficoltà nella gestione dei vari componenti dell’infrastruttura

Caratteristiche delle soluzioni proposte, adottate e benefici ottenuti

Il cliente ha deciso di adottare una infrastruttura hyper-converged (HCI), dove sono stati rimossi diversi componenti hardware, sostituti dal software in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione. In questo modo ha effettuato un 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).

Figura 1 – Passaggio da una infrastruttura “Three Tier” verso una Hyper-Converged Infrastructure (HCI)

Azure Stack HCI: lo stack completo dell’infrastruttura Hyper-Converged

Tutto ciò è stato fatto adottando la soluzione Microsoft Azure Stack HCI, che consente l’esecuzione di workload ed una facile connessione ad Azure dell’infrastruttura hyper-converged (HCI).  Nei paragrafi seguenti si riportano le principali caratteristiche della soluzione.

Scelta e personalizzazione dell’hardware

Il cliente ha potuto personalizzare la soluzione hardware in base alle proprie esigenze, andando a configurare il processore, la memoria, lo storage e le caratteristiche delle schede di rete, rispettando le matrici di compatibilità del fornitore.

Figura 2 – Composizione hardware della soluzione Azure Stack HCI

Sono diversi i fornitori hardware che offrono soluzioni idonee per eseguire Azure Stack HCI e possono essere consultate accedendo a questo indirizzo. La scelta è ampia e ricade su oltre 200 soluzioni di oltre 20 partner differenti. Azure Stack HCI richiede hardware appositamente testato e validato dai vari vendor.

Sistema operativo dedicato e specifico

Il sistema operativo della soluzione Azure Stack HCI è un sistema operativo specifico con una composizione semplificata e componenti più aggiornati rispetto a Windows Server. In questo sistema operativo non sono inclusi i ruoli non necessari alla soluzione, ma è presente il più recente hypervisor utilizzato anche in ambiente Azure, con tecnologie storage e di rete software-defined ottimizzate per la virtualizzazione.

L’interfaccia utente locale è minima ed è progettato per essere gestito da remoto.

Figura 3 – Interfaccia del SO di Azure Stack HCI

Disaster recovery e failover delle macchine virtuali

Il cliente ha inoltre sfruttato la possibilità di creare uno stretched cluster per estendere il proprio cluster Azure Stack HCI, nel caso specifico in due edifici differenti. Questa funzionalità si basa su una replica dello storage (sincrona in questo scenario) contemplando la crittografia, la resilienza locale del sito ed il failover automatico delle macchine virtuali in caso di disastro.

Figura 4 – Stretched cluster dell’architettura hyper-converged di Azure Stack HCI

Aggiornamenti di tutto lo stack della soluzione (full-stack updates)

Al fine di ridurre la complessità ed i costi operativi dati dal processo di aggiornamento dell’intera soluzione, il cliente può avviare in Azure Stack HCI il processo che prevede l’aggiornamento full-stack (firmware / driver insieme al sistema operativo) direttamente da Windows Admin Center.

Figura 5 – Solution updates della soluzione Azure Stack HCI marchiata Dell EMC

Servizio ibrido di Azure: familiarità nella gestione e nel funzionamento

Il cliente è in grado di gestire la propria infrastruttura basata su Azure Stack HCI in modo semplice e senza adottare strumenti software specifici, come se fosse un’estensione del cloud pubblico, grazie alle caratteristiche citate nei paragrafi seguenti.

Integrazione nativa in Azure

Azure Stack HCI si integra in modo nativo con i servizi Azure e con Azure Resource Manager (ARM). Per questa integrazione non è richiesto alcun agente, ma Azure Arc è integrato direttamente nel sistema operativo. Questa permette di visualizzare, direttamente dal portale Azure, il cluster Azure Stack HCI presente on-premises esattamente come una risorsa di Azure.

Figura 6 – Integrazione di Azure Stack HCI in Azure

Grazie all’integrazione con Azure Resource Manager il cliente può sfruttare i seguenti vantaggi dati della gestione basata su Azure:

  • Adozione dei costrutti standard basati su Azure Resource Manager (ARM)
  • Classificazione dei cluster con i Tags
  • Organizzazione dei cluster in Resource Groups
  • Visualizzazione di tutti i cluster di Azure Stack HCI in un’unica vista centralizzata
  • Gestione degli accessi tramite Azure Identity Access Management (IAM)

Inoltre, dalla risorsa Azure Stack HCI è possibile individuare, aggiungere, modificare o rimuovere le extension, grazie alle quali è possibile accedere facilmente alle funzionalità di gestione.

Figura 7 – Funzionalità di gestione di Azure Stack HCI

Gestione delle VM Arc-enabled

Oltre che per gestire il cluster, il cliente può utilizzare Azure Arc anche per eseguire il provisioning e la gestione delle macchine virtuali in esecuzione su Azure Stack HCI, direttamente dal portale di Azure. Le macchine virtuali e le loro risorse associate (immagini, dischi, e network) vengono proiettate in ARM come risorse separate mediante una nuova tecnologia multi piattaforma chiamata Arc Resource Bridge.

In questo modo è possibile:

  • ottenere una gestione coerente tra le risorse cloud e le risorse Azure Stack HCI;
  • automatizzare le distribuzioni delle macchine virtuali utilizzando i modelli ARM;
  • garantire un accesso self-service grazie al supporto ad Azure RBAC.

Figura 8 – Funzionalità date dall’integrazione di Azure Arc per le VMs di Azure Stack HCI

Azure Backup ed Azure Site Recovery

Azure Stack HCI supporta Azure Backup ed Azure Site Recovery. Con Microsoft Azure Backup Server (MABS) il cliente effettua il backup degli host e delle macchine virtuali attive in Azure Stack HCI. Inoltre, utilizzando Azure Site Recovery è possibile attivare la replica delle macchine virtuali da Azure Stack HCI ad Azure, per creare scenari di disaster recovery specifici.

Monitor dell’infrastruttura con Azure Monitor Insights per Azure Stack HCI

Grazie alla soluzione Azure Stack HCI Insights il cliente è in grado di consultare informazioni dettagliate sull’integrità, sulle prestazioni e sull’utilizzo dei cluster Azure Stack HCI connessi ad Azure e registrati per il relativo monitoraggio. Azure Stack HCI Insights archivia i propri dati in un workspace di Log Analytics, avendo così la possibilità di utilizzare potenti aggregazioni e filtri per analizzare al meglio i dati raccolti nel tempo. Si ha la possibilità di visualizzare i dati di monitor di un singolo cluster dalla pagina delle risorse Azure Stack HCI oppure è possibile utilizzare Azure Monitor per ottenere una visualizzazione aggregata di più cluster Azure Stack HCI con una panoramica dell’integrità del cluster, lo stato di nodi e delle macchine virtuali (CPU, memoria e consumo di storage), metriche delle prestazioni e altro ancora. Si tratta degli stessi dati forniti anche da Windows Admin Center, ma progettati per scalare fino a 500 cluster contemporaneamente.

Figura 9 – Pannello di controllo di Azure Monitor Insights per Azure Stack HCI

Azure benefit per Windows Server

Microsoft offre vantaggi speciali quando si distribuisce Windows Server in ambiente Azure e gli stessi vantaggi sono disponibili anche su Azure Stack HCI.

Figura 10 – Azure benefit per Windows Server

Azure Stack HCI consente di:

  • Distribuire macchine virtuali con Windows Server 2022 edizione Azure Datacenter, che offre funzionalità specifiche non disponibili nelle classiche edizioni Standard e Datacenter. Per approfondire le caratteristiche disponibili in questa edizione è possibile consultare questo articolo.
  • Ottenere gratuitamente aggiornamenti di sicurezza estesi, proprio come in Azure. Questo vale sia per Windows Server 2008/R2, sia per Windows Server 2012/R2, oltre alle versioni corrispondenti di SQL Server.
  • Ottenere la licenza ed attivare le macchine Windows Server come in Azure. Azure Stack HCI oltre a consentire di utilizzare la propria licenza Datacenter per abilitare l’attivazione automatica delle macchine virtuali (Automatic VM Activation – AVMA), mette a disposizione l’opzione di pagare la licenza di Windows Server per i sistemi guest tramite la propria subscription Azure, proprio come avviene in ambiente Azure.

Team di supporto Azure dedicato

Azure Stack HCI è a tutti gli effetti una soluzione Azure, pertanto il cliente può usufruire del supporto Azure con le seguenti caratteristiche:

  • Potrà richiedere facilmente supporto tecnico direttamente dal portale Azure.
  • Il supporto sarà fornito da un nuovo team di esperti dedicato a supportare la soluzione Azure Stack HCI.
  • Sarà possibile scegliere tra diversi piani di supporto, a seconda delle esigenze.

Innovazione dell’infrastruttura e nuovi scenari evoluti

In ambiente Azure Stack HCI, oltre ad eseguire macchine virtuali, è possibile attivare Azure Kubernetes Service (AKS) ed Azure Virtual Desktop.

Azure Kubernetes Service in Azure Stack HCI

Questo scenario di implementazione di AKS on-premises permette di automatizzare l’esecuzione su larga scala di applicazioni moderne basate su micro-servizi. Grazie ad Azure Stack HCI l’adozione di queste architetture applicative basate su container possono essere ospitate direttamente presso il proprio datacenter, adottando la stessa esperienza di gestione di Kubernetes che si ha con il servizio gestito presente nel cloud pubblico di Azure.

Figura 11 – Panoramica di AKS su Azure Stack HCI

Per maggiori informazioni è possibile consultare l’articolo Azure Kubernetes Service in ambiente Azure Stack HCI.

Azure Virtual Desktop per Azure Stack HCI

In situazioni dove le applicazioni risultano sensibili alla latenza, come ad esempio l’editing video, oppure scenari dove gli utenti hanno bisogno di usufruire di un sistema legacy presente on-premises che non può essere facilmente raggiunto, Azure Virtual Desktop aggiunge una nuova opzione ibrida grazie ad Azure Stack HCI. Azure Virtual Desktop per Azure Stack HCI usa lo stesso piano di gestione cloud del normale Azure Virtual Desktop, ma consente di creare pool di session host utilizzando macchine virtuali in esecuzione su Azure Stack HCI. Queste macchine virtuali possono eseguire Windows 10 e/o Windows 11 Enterprise multi-session. Collocando i desktop più vicini agli utenti, è possibile abilitare l’accesso diretto a bassa latenza e senza round trip.

Conclusioni

Microsoft gestisce tra i più grandi data center del mondo e sta facendo grossi investimenti per portare l’esperienza maturata e l’innovazione del cloud anche in Azure Stack HCI. Questo cliente, affidandosi ad Azure Stack HCI sta usufruendo di un servizio in abbonamento che riceve aggiornamenti regolari delle funzionalità, con l’obiettivo importante di poter sfruttare on-premises la tecnologia collaudata su larga scala nel cloud. Inoltre, è in grado di gestione in modo unificato le risorse del proprio ambiente ed avere una continua innovazione della propria infrastruttura ibrida.

Azure Stack HCI: la soluzione hyper-converged in continua evoluzione – edizione di novembre 2021

Azure Stack HCI è la soluzione che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Anche Azure Stack HCI viene considerato come servizio hybrid di Azure e come tale è in continua evoluzione. Recentemente Microsoft ha introdotto una serie di nuove funzionalità che aprono la strada a nuovi scenari di adozione di Azure Stack HCI e che consentono di gestire al meglio la propria infrastruttura ibrida basata su questa soluzione. In questo articolo vengono riportati i principali aspetti che hanno subito un’evoluzione e le nuove funzionalità recentemente introdotte in Azure Stack HCI.

Nuovi workload e nuovi benefici

Il risultato che si intende perseguire con l’infrastruttura Azure Stack HCI è quello di poter eseguire in ambiente on-premises gli stessi carichi di lavoro del cloud pubblico con gli stessi vantaggi. Per raggiungerlo Microsoft sta portando i workload di Azure più popolari in Azure Stack HCI.

A partire dallo scorso anno è possibile attivare su Azure Stack HCI l’orchestratore Azure Kubernetes Service (AKS), che consente di automatizzare la distribuzione e la gestione delle applicazioni containerizzate in ambiente on-premises esattamente come avviene in Azure. Oltre a poter eseguire app Windows e Linux in conteniter, AKS rende disponibile l’infrastruttura per eseguire dei servizi selezionati della piattaforma Azure (PaaS) su Azure Stack HCI.

Le importanti novità annunciate in questo ambito sono le seguenti.

Figura 1 – Nuovi workload Azure e nuovi benefici in Azure Stack HCI

Azure Virtual Desktop per Azure Stack HCI (preview)

Attivando Azure Virtual Desktop nel cloud pubblico, gli utenti possono accedere ai propri desktop e alle proprie applicazioni da qualsiasi luogo, usufruendo della familiarità e della compatibilità garantita da Windows 10 e da Windows 11. Azure Virtual Desktop è un servizio ospitato e gestito da Microsoft, che non richiede la configurazione di una complessa infrastruttura VDI.

Esistono però situazioni dove le applicazioni risultano sensibili alla latenza, come ad esempio l’editing video, oppure scenari dove gli utenti hanno bisogno di usufruire di un sistema legacy presente on-premises che non può essere facilmente raggiunto. Per consentire di affrontare al meglio situazioni di questo tipo, Azure Virtual Desktop aggiunge una nuova opzione ibrida grazie ad Azure Stack HCI.

Azure Virtual Desktop per Azure Stack HCI usa lo stesso piano di gestione cloud del normale Azure Virtual Desktop, ma consente di creare pool di session host utilizzando macchine virtuali in esecuzione su Azure Stack HCI. Queste macchine virtuali possono eseguire Windows 10 e/o Windows 11 Enterprise multi-session. Collocando i desktop più vicini agli utenti, è possibile abilitare l’accesso diretto a bassa latenza e senza round trip, utilizzando una tecnologia chiamata RDP Shortpath.

Azure benefit per Windows Server

Microsoft offre vantaggi speciali quando si distribuisce Windows Server in ambiente Azure e gli stessi vantaggi, entro la fine di quest’anno, saranno disponibili anche su Azure Stack HCI.

Innanzi tutto, quando si distribuiscono macchine virtuali con Windows Server 2022, anche in ambiente Azure Stack HCI è possibile attivare l’edizione Azure Datacenter che offre funzionalità specifiche non disponibili nelle classiche edizioni Standard e Datacenter. Per approfondire le caratteristiche disponibili in questa edizione è possibile consultare questo articolo.

Inoltre, Azure Stack HCI versione 21H2 consente di:

  • Ottenere gratuitamente aggiornamenti di sicurezza estesi, proprio come in Azure. Questo vale per Windows Server 2008/R2 e verrà presto applicato anche a Windows Server 2012/R2 quando si raggiungerà la fine del supporto, oltre alle versioni corrispondenti di SQL Server.
  • Ottenere la licenza ed attivare le macchine Windows Server come in Azure. Azure Stack HCI oltre a consentire di utilizzare la propria licenza Datacenter per abilitare l’attivazione automatica delle macchine virtuali (Automatic VM Activation – AVMA), mette a disposizione l’opzione di pagare la licenza di Windows Server per i sistemi guest tramite la propria subscription Azure, proprio come avviene in ambiente Azure.

Innovazione dell’infrastruttura

In Microsoft vengono gestiti tra i più grandi data center del mondo e si vuole portare l’esperienza maturata e l’innovazione del cloud anche in Azure Stack HCI. Per queste ragioni Azure Stack HCI è un servizio in abbonamento che riceve aggiornamenti regolari delle funzionalità con l’obiettivo importante di poter sfruttare on-premises la tecnologia collaudata su larga scala nel cloud.

Figura 2 – Innovazione dell’infrastruttura in Azure Stack HCI

Grazie al rilascio dell’ultimo aggiornamento, noto come “versione 21H2” oppure come “feature update 21H2”, vengono introdotte le seguenti nuove funzionalità:

  • Gestione del quick restart con Kernel Soft Reboot: migliora le prestazioni di riavvio, saltando la sequenza di pre-avvio e l’autotest all’accensione dell’hardware. In questo modo si riduce anche il tempo complessivo di aggiornamento del cluster (disponibile solo su Azure Stack HCI Integrated Systems).
  • Utilizzo delle GPUs con VM clusterizzate: fornisce l’accelerazione GPU ai carichi di lavoro in esecuzione sulle VM in ambiente cluster. Ideale per workload in ambito AI/ML.
  • Dynamic CPU compatibility mode: la modalità di compatibilità del processore è stata aggiornata per sfruttare al meglio tutte le funzionalità dei processori in ambiente cluster. Infatti, è possibile combinare differenti generazioni di processori nello stesso cluster con un degrado minimo. Il cluster calcola in modo intelligente il più grande sottoinsieme comune di funzionalità del processore che possono essere esposte alle macchine virtuali.
  • Storage thin provisioning: migliora l’efficienza dello storage e semplificata la gestione mediante il thin provisioning.
  • Network ATC: semplifica la gestione della configurazione di rete degli host.
  • Velocità di riparazione dello storage regolabile: maggiore controllo sul processo di ri-sincronizzazione dei dati.
  • Supporto per la nested virtualization con processori AMD: migliore flessibilità per realizzare ambienti di test e valutazione grazie alla possibilità di attivare la nested virtualization anche in presenza di processori AMD.
  • Secured-Core Server: offre una sicurezza trasversale su hardware e firmware, integrata nelle funzionalità del sistema operativo, in grado di aiutare a proteggere i server da minacce avanzate.

Nuove funzionalità di gestione

Un altro risultato che si vuole ottenere con Azure Stack HCI è quello di poter gestire la propria infrastruttura come se fosse un’estensione del cloud pubblico. Azure Stack HCI si integra infatti in modo nativo con Azure Resource Manager e questo consente di proiettare il cluster come risorsa nel portale di Azure. In questo modo è possibile sfruttare gli stessi processi in tutti gli ambienti e gestire le risorse Azure Stack HCI proprio come le risorse cloud.

Figura 3 – Nuove funzionalità di gestione di Azure Stack HCI

Host server Arc-enabled ed extension

Dalla risorsa Azure Stack HCI è possibile individuare, aggiungere, modificare o rimuovere le extension, grazie alle quali è possibile accedere facilmente alle funzionalità di gestione. Con la disponibilità di Azure Stack HCI versione 21H2 il cluster abiliterà automaticamente ad Arc i server host, al momento della registrazione, per poter utilizzare fin da subito le extension disponibili.

Gestione delle VM Arc-enabled (preview)

Oltre che per gestire il cluster, ora è possibile utilizzare Azure Arc anche per eseguire il provisioning e la gestione delle macchine virtuali in esecuzione su Azure Stack HCI, direttamente dal portale di Azure. Le macchine virtuali e le loro risorse associate (immagini, dischi, e network) vengono proiettate in ARM come risorse separate mediante una nuova tecnologia multipiattaforma chiamata Arc Resource Bridge.

In questo modo è possibile:

  • ottenere una gestione coerente tra le risorse cloud e le risorse Azure Stack HCI;
  • automatizzare le distribuzioni delle macchine virtuali utilizzando i modelli ARM;
  • garantire un accesso self-service grazie al supporto ad Azure RBAC.

Azure Backup ed Azure Site Recovery

Con Azure Stack HCI versione 21H2 è stato introdotto il supporto ufficiale per Azure Backup ed Azure Site Recovery. Con MABS v3 UR2 o versioni successive è possibile eseguire il backup degli host e delle macchine virtuali attive in Azure Stack HCI. Inoltre, con Azure Site Recovery è possibile replicare le macchine virtuali da Azure Stack HCI ad Azure ed attivare scenari di disaster recovery.

Conclusioni

Grazie ad un costante miglioramento, all’introduzione continua di nuove funzionalità ed all’inclusione di nuovi scenari di utilizzo, la proposizione per scenari hyper-converged risulta sempre più completa, integrata e performante. Azure Stack HCI si integra perfettamente all’ambiente on-premises esistente ed offre un importante valore aggiunto: la possibilità di connettere Azure Stack HCI con altri servizi Azure per ottenere una soluzione hyper-converged ibrida. Questo aspetto in particolare la differenzia fortemente da altri competitor che offrono soluzioni in questo ambito.

Azure Kubernetes Service in ambiente Azure Stack HCI

La soluzione hyper-converged Azure Stack HCI permette di attivare in ambiente on-premises l’orchestratore Azure Kubernetes Service (AKS) per l’esecuzione di applicazioni containerizzate su larga scala. In questo articolo viene approfondito come Azure Kubernetes in ambiente Azure Stack HCI offre la possibilità di ospitare nel proprio datacenter container Linux e Windows, andando ad esplorare i principali benefici di questa soluzione.

Prima di entrare nello specifico di AKS in ambiente Azure Stack si riporta un riepilogo delle soluzioni coinvolte.

Che cos’è Kubernetes?

Kubernetes, conosciuto anche come “k8s”, provvede all’orchestrazione automatizzata dei container, migliorandone l’affidabilità e riducendo il tempo e le risorse necessarie in ambito DevOps, mediante:

  • Deployment tendenzialmente più semplici che permettono di eseguire implementazioni e rollback in modo automatico.
  • Migliore gestione delle applicazioni con la possibilità di monitorare lo stato dei servizi per evitare errori in fase di implementazione. Infatti, tra le varie funzionalità sono previsti controlli di integrità dei servizi, con la possibilità di riavviare i container che non sono in esecuzione oppure che risultano bloccati, permettendo di annunciare ai client solo i servizi correttamente avviati.
  • Possibilità di scalare automaticamente in base all’utilizzo e, esattamente come per i container, gestire in maniera dichiarativa l’ambiente cluster, consentendo una configurazione controllata a livello di versione e facilmente replicabile.

Figura 1 – Cluster Kubernetes con i relativi componenti dell’architettura

Che cos’è Azure Kubernetes Service (AKS)?

Azure Kubernetes Service (AKS) è il servizio Azure completamente gestito che permette l’attivazione di un cluster Kubernetes, ideale per semplificare il deployment e la gestione di architetture basate su microservizi. Grazie alle funzionalità offerte da AKS è possibile scalare automaticamente in base all’utilizzo, utilizzare controlli per garantire l’integrità dei servizi, implementare politiche di bilanciamento del carico e gestire i secret. L’utilizzo di questo servizio gestito viene integrato con le pipeline di sviluppo e di deployment dei container.

Figura 2 – Esempio di architettura di Azure Kubernetes Service (AKS)

Che cos’è Azure Stack HCI?

Azure Stack HCI è la soluzione che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workloads in ambiente on-premises e che prevede una connessione strategica ai servizi di Azure. Si tratta di una infrastruttura hyper-converged (HCI), dove vengono rimossi diversi componenti hardware, sostituti dal software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione. In questo modo si ha un 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).

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

Che cos’è AKS in Azure Stack HCI?

AKS in ambiente Azure Stack HCI è un’implementazione Microsoft di AKS, che consente di automatizzare la distribuzione e la gestione delle applicazioni containerizzate.

Microsoft, dopo aver introdotto AKS come servizio in Azure, ha esteso la sua disponibilità anche agli ambienti on-premises. Tuttavia, ci sono alcune importanti differenze:

  • In Azure, Microsoft gestisce il control plane di ogni cluster AKS. Inoltre, i nodi del cluster (management node e worker node) vengono eseguiti su macchine virtuali Azure oppure su virtual machine scale set di Azure.
  • In ambiente on-premises, il cliente gestisce l’intero ambiente, dove i nodi del cluster AKS sono in esecuzione su macchine virtuali ospitate sull’infrastruttura hyper-converged.

Architettura di AKS su Azure Stack HCI

L’implementazione di AKS in Azure Stack HCI è costituita da due tipologie di cluster:

  • Un cluster di management di AKS. Questo cluster funge da control plane dedicato per la gestione dei cluster Kubernetes in esecuzione sulla piattaforma hyper-converged. Tale cluster è costituito da macchine virtuali Linux, che ospitano componenti di sistema Kubernetes come API server e load balancer.
  • Uno o più cluster Kubernetes. Questi cluster sono costituiti dai control node e dai worker node. I control node sono implementati come macchine virtuali Linux, con API server e load balancer che soddisfano le richieste degli utenti di Azure Stack HCI. I workload sono distribuiti sui worker node basati su sistema operativo Linux oppure Windows.

Figura 4 – Architettura di AKS su Azure Stack HCI

Ogni cluster Kubernetes viene eseguito sul proprio set dedicato di macchine virtuali, protette dall’isolamento basato su Hypervisor, consentendo di condividere in modo sicuro la stessa infrastruttura fisica anche in scenari che richiedono l’isolamento dei workload.

AKS in Azure Stack HCI supporta sia i container basati su Linux sia i container basati su Windows. Quando si crea un cluster Kubernetes si deve semplicemente specificare la tipologia di container che si intende eseguire e sulla piattaforma hyper-converged viene avviata automaticamente la procedura di installazione del sistema operativo richiesto sui nodi del cluster Kubernetes.

Vantaggi di AKS su Azure Stack HCI

AKS semplifica la distribuzione dei cluster Kubernetes fornendo un livello di astrazione in grado di mascherare alcuni dei dettagli di implementazione più impegnativi.

Tra i principali benefici di AKS in ambiente Azure Stack HCI troviamo:

  • Deployment semplificati di app containerizzate in ambiente cluster. Mediante l’utilizzo di Windows Admin Center si ha un processo guidato di installazione del cluster di management di AKS. Windows Admin Center facilita inoltre l’installazione di singoli cluster Kubernetes che contengono i worker node, mediante un processo di installazione automatico di tutti i componenti software rilevanti, inclusi gli strumenti di gestione come kubectl.
  • Possibilità di scalare orizzontalmente per gestire le risorse computazionali, aggiungendo o rimuovendo nodi del cluster Kubernetes.
  • Gestione semplificata dello storage e delle configurazioni di rete delle risorse cluster.
  • Aggiornamenti automatici dei nodi del cluster all’ultima versione di Kubernetes disponibile. Microsoft gestisce le immagini Windows Server e Linux per i nodi del cluster e le aggiorna mensilmente.
  • Connessione strategica, mediante Azure Arc, ai servizi Azure come: Microsoft Azure Monitor, Azure Policy, e Azure Role-Based Access Control (RBAC).
  • Gestione centralizzata dei cluster Kubernetes e dei relativi carichi di lavoro tramite il portale Azure, grazie all’adozione di Azure Arc for Kubernetes. La gestione basata sul portale di Azure integra anche gli strumenti e le interfacce di amministrazione Kubernetes tradizionali, come l’utility da riga di comando kubectl e le dashboard Kubernetes.
  • Gestione del failover automatico delle macchine virtuali che fungono da nodi del cluster Kubernetes se si verifica un errore localizzato dei componenti fisici sottostanti. Ciò integra l’elevata disponibilità intrinseca in Kubernetes, in grado di riavviare automaticamente i conteiner in stato failed.

Conclusioni

Grazie ad Azure Stack HCI l’adozione di architetture applicative basate su container possono essere ospitate direttamente presso il proprio datacenter, adottando la stessa esperienza di gestione di Kubernetes che si ha con il servizio gestito presente nel cloud pubblico di Azure. Anche il processo di deployment risulta molta semplificato ed intuitivo. Inoltre, Azure Stack HCI permette di migliorare ulteriormente l’agilità e la resilienza delle distribuzioni Kubernetes in ambiente on-premises.

Azure Stack HCI: funzionalità di disaster recovery intrinseche nella soluzione

Nella più recente versione di Azure Stack HCI viene inclusa la possibilità di creare stretched cluster per estendere un cluster Azure Stack HCI in due location differenti (stanze, edifici oppure anche città differenti). Questa soluzione di disaster recovery fornisce una replica dello storage (sincrona oppure asincrona) e contempla la crittografia, la resilienza locale del sito ed il failover automatico delle macchine virtuali. In questo articolo vengono approfondite le possibili architetture e le caratteristiche della soluzione.

Per migliorare ulteriormente la resilienza built-in nella soluzione Azure Stack HCI è possibile implementare un cluster composto da due gruppi di nodi, definito “stretched cluster”. Ogni gruppo è dislocato in un sito differente e deve contenere un minimo di due nodi. Uno stretched cluster può essere composto da un minimo di quattro fino a sedici nodi fisici (numero massimo di nodi supportati da un cluster Azure Stack HCI), i quali devono soddisfare i requisiti hardware standard per soluzioni HCI.

Figura 1 – Panoramica di uno stretched cluster in una architettura hyper-converged di Azure Stack HCI

Scendendo nel dettaglio dell’architettura i componenti e le funzionalità utilizzate sono:

  • Azure Stack HCI. La versione minima richiesta è la 20H2, distribuita come servizio hybrid di Azure e rilasciata a dicembre 2020. Si tratta di una infrastruttura hyper-converged (HCI), dove vengono rimossi diversi componenti hardware, sostituti dal software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione.
  • Storage Replica. La tecnologia inclusa in Windows Server che consente la replica dei volumi tra server oppure tra cluster ai fini di disaster recovery.
  • Live Migration. La funzionalità di Hyper-V che consente di spostare facilmente le macchine virtuali (VMs) in esecuzione su un host Hyper-V ad un altro, senza avere tempi di inattività. Tale funzionalità risulta utile per gestire downtime attesi oppure programmati.
  • Risorsa Witness. Il Witness è un componente obbligatorio all’interno dei cluster Azure Stack HCI. Per implementarlo è possibile scegliere un Azure Cloud Witness oppure un File Share Witness. Azure Cloud Witness è la scelta consigliata per i stretched cluster Azure Stack HCI purché tutti i nodi dispongano di una connessione Internet affidabile.

Uno stretched cluster di Azure Stack HCI si basa sull’utilizzo di Storage Replica ed è possibile avere una replica sincrona oppure asincrona del dato:

  • Utilizzando la replica sincrona viene effettuato un mirroring dei dati tra i siti in una rete a bassa latenza. I volumi risultano crash-consistent per garantire una perdita di dati pari a zero a livello di file system durante un evento di failure. Il requisito per la replica sincrona applicabile ai stretched cluster impone come latenza di rete 5 ms di round trip tra i due gruppi di nodi dislocati nei siti replicati. A seconda delle caratteristiche di connettività della rete fisica, questo vincolo si traduce in genere in circa 30-45 Km di distanza. Con questa configurazione, se capita un problema che influisce sulla disponibilità di un sito, il cluster è in grado di trasferire automaticamente i workload ai nodi del sito non interessato dalla problematica per ridurre al minimo i potenziali tempi di inattività.
  • La replica asincrona esegue il mirroring dei dati tra i siti su collegamenti di rete con latenze più elevate, ma non si ha la garanzia che entrambi i siti dispongano di copie identiche dei dati quando si verifica un evento di failure. In presenza di replica asincrona, è necessario portare online manualmente i volumi di destinazione nell’altro sito in seguito ad un failover.

Esistono due tipologie di stretched cluster: attivo-attivo e attivo-passivo.

Figura 2 – Tipologie di stretched cluster a confronto

Un sito attivo è un sito che dispone di risorse e ospita ruoli e workload ai quali i client possono connettersi. Un sito passivo è un sito che non eroga ruoli oppure workload per i client, ma è in attesa di un failover dal sito attivo a fini di disaster recovery.

La replica in uno stretched cluster attivo-passivo ha una direzione preferita, mentre la replica in uno stretched cluster attivo-attivo può avvenire in modo bidirezionale da entrambi i siti.

Azure Stack HCI e Storage Replica supportano anche la deduplica dei dati, utile ad aumentare la capacità di archiviazione utilizzabile, identificando porzioni duplicate di file e archiviandole solo una volta. A partire da Windows Server 2019, la deduplica è disponibile sui volumi formattati con Resilient File System (ReFS), che è il file system consigliato per Azure Stack HCI. Negli stretched cluster di Azure Stack HCI è consigliato abilitare la Data Deduplication solo sui nodi del cluster di origine, e non sui nodi di destinazione, i quali ricevono sempre copie deduplicate di ciascun volume.

Conclusioni

La possibilità di estendere i cluster Azure Stack HCI in due location differenti consente di implementare architetture di disaster recovery in un modo totalmente integrato nella soluzione, senza la necessità di dover adottare prodotti di terze parti. Questa caratteristica, unita alla possibilità di connettere Azure Stack HCI con i servizi Azure per ottenere un sistema hyper-converged ibrido, la rende una soluzione completa, stabile ed affidabile, in grado di rispondere alle esigenze più avanzate nell’ospitare workload business critical.