Una delle grandi caratteristiche di Azure Local, rispetto Azure Stack HCI, è la separazione tra i servizi presenti lato sistema operativo e quelli presenti lato cloud. Ad oggi, lato sistema operativo, siamo alla 23H2, in attesa del prossimo arrivo della 24H2 che porterà diverse novità già viste in Windows Server 2025 – come i miglioramenti sul driver NVMe.
Sul fronte cloud, invece, gli aggiornamenti vengono rilasciati più o meno ogni mese, che contengono non solo la parte di aggiornamenti sicurezza OS, ma anche quelli di funzionalità per andare ad utilizzare le capacity presenti all’interno di Microsoft Azure, incluse quelle nuove.
Azure Stack HCI 22H2 non permetteva più una crescita tecnica, questo a causa del suo Resource Bridge che consentiva poche cose ma che, soprattutto, non era aggiornabile in modo automatico.
Per chi non conoscesse ancora Azure Local, si tratta della piattaforma di iperconvergenza, che nasce con l’obiettivo di fornire alcuni servizi nativi di Azure, all’interno dell’infrastruttura on-premises. Il motivo del suo utilizzo è adottare modelli particolari, come AKS o Azure Virtual Desktop, sfruttando la latenza vicino allo zero data dalla rete locale.
Se è vero che oggi come oggi, per chi deve realizzare un’infrastruttura nuova, si parte subito dall’implementare Azure Local, per tutti coloro che arrivano da Azure Stack HCI 22H2 è necessario eseguire una serie di passaggi per trasformare la piattaforma.
La trasformazione da Azure Stack HCI, a Azure Local, consiste in due macro passaggi: upgrade 23H2 ed esecuzione del processo di conversione ed installazione servizi all’interno dei vari host – operazione che si svolge da Microsoft Azure.
Aggiornamento Lato Server
Tutti i passaggi relativi alla configurazione sono disponibili in questo articolo – About Azure Local upgrade to version 23H2 – Azure Local | Microsoft Learn. Noi ci focalizzeremo su alcune operazioni, come la parte di sistema operativo, che può essere eseguita tramite Cluster Aware Updating (CAU) oppure singolarmente, tramite la sezione dei Feature Updates.
NB: il CAU è mandatorio per Azure Local, quindi dovrete averlo sempre funzionante per fare gli update mensili.
Al termine delle operazioni, che richiedono circa 30 minuti per host, sarà necessario eseguire due comandi per aggiornare le funzionalità del cluster e dello storage pool.
Update-ClusterFunctionalLevel
Update-StoragePool -FriendlyName “S2D on hci-cluster1”
Qualora non l’abbiate già fatto con la 22H2, tutto lo stack di rete dovrà essere convertito sotto Network ATC, che possiamo vedere come un teaming più intelligente, in cui vengono aggregate più schede di rete e partizionate per scope (Compute, Management, Storage).
Questa operazione può richiedere anche 60 minuti, soprattutto perchè potrebbero essere necessarie delle operazioni sui vostri switch core.
Conclusa la parte network, ci si sposta sulla parte storage, che anche in questo caso vede una novità importante, ovvero la creazione di un volume dedicato alla gestione dello stack e del suo mantenimento. Per poter procedere al passaggio verso Azure Local, è necessario che siano disponibili 250GB per la creazione di questo nuovo volume; solitamente questo spazio dovrebbe essere disponibile se avete riservato un 10% di buffer, durante la prima creazione dello Storage Pool.
NB: non aver fatto questo, potrebbe obbligarvi a dover rifare tutto il pool da zero, con un disservizio non da poco….dato che la conversione da Fixed a Thin non è sempre possibile.
Tra processo di validazione, tramite script in PowerShell, e remediation, potreste anche impiegare 2 ore.
Aggiornamento Lato Cloud
Al momento in cui la validazione viene passata, ci si può spostare all’interno di Microsoft Azure, nella sezione di Azure Arc dedicata ad Azure Stack HCI, per eseguire il task di upgrade dei servizi core ed estensioni.
Il wizard prevede la creazione di una Key Vault e la definizione dei range di IP da assegnare al resource bridge.
Anche se avete eseguito il validation test via PowerShell, il wizard via cloud rieseguirà nuovamente questo test, per controllare che non ci siano state delle modifiche alla configurazione.
Effettuato il test, se viene passato correttamente, potrete procedere con l’upgrade ad Azure Local. Mettetevi l’anima in pace e preparatevi ad attendere, perchè il tempo di esecuzione è di circa 4 ore, che comprende il download degli aggiornamenti, la configurazione dei nuovi ruoli all’interno del cluster, il deployment del Resource Bridge e la configurazione di tutte le nuove componenti.
In caso di errore, potrete analizzare cos’è successo e rilanciare il wizard.
Una volta concluso tutto il processo, sarete in grado di creare nuovamente risorse cloud based, come Virtual Machine, Container AKS, Azure Virtual Desktop e tutto quello che la soluzione ha da offrire. Lato on-premises non ci saranno grosse novità, a parte 4 nuovi servizi ed il relativo Resource Bridge.
Nei prossimi articoli andremo a vedere la creazione delle varie risorse, anche se il procedimento non è cambiato molto rispetto al passato.
Problemi Noti
Ci sono alcuni problemi noti, soprattutto per quegli utenti che passano dalla 22H2 alla 23H2, come l’impossibilità di eseguire la Live Migration; problema risolvibile con l’applicazione di una chiave di registro.
A tal proposito è stata creata una pagina in GitHub per raccogliere un po’ di suggerimenti per ovviare ai vari problemi che possono nascere durante la fase di aggiornamento – AzureLocal-Supportability/TSG/Upgrade at main · Azure/AzureLocal-Supportability · GitHub.
Cercate di eseguire questo upgrade in un momento di basso impatto, cercando di seguire le varie fasi operative, per essere proattivi in caso di problemi. Cercate anche di tenere uno dei Domain Controller fuori dal cluster, almeno per questa fase, per fare in modo che sia sempre disponibile l’autenticazione del servizio cluster.
Conclusioni
L’upgrade ad Azure Local sblocca tutte le funzionalità di native cloud, presenti all’interno della vostra piattaforma di iperconvergenza, che vanno sfruttate per valorizzare al meglio questa soluzione. All’atto pratico non è obbligatorio aggiornare anche la parte cloud, aggiornando solo la parte di OS, ma sarebbe un po’ uno spreco aver scelto questa tipologia di prodotto per poi relegarlo a semplice sistema di HCI.
Una volta effettuato il passaggio a questa versione, gli aggiornamenti verranno gestiti direttamente da Azure Update Manager, per orchestrare al meglio il patching ma anche per implementare le nuove funzionalità.