• Guide, Sistemi Operativi
• 4 Novembre 2026

Comprare un server per Azure Local sembra la parte facile: si guardano CPU, RAM e dischi, si confronta il prezzo e si manda l’ordine. Il problema vero arriva dopo, il giorno del primo aggiornamento, e poi quello del secondo, e poi del terzo. Spoiler: gli aggiornamenti non finiscono mai.

Perché Azure Local non è un hypervisor da installare e dimenticare. Si aggiorna molto spesso, e ogni aggiornamento chiama in causa anche driver e firmware del vostro hardware. Scegliere il nodo giusto significa scegliere chi, nei prossimi anni, si prenderà la briga di tenere allineati hardware e software.

In questo articolo vediamo le categorie di hardware disponibili, che cosa è cambiato nel catalogo Microsoft, perché i pacchetti SBE sono la differenza tra un cluster che funziona e un calvario, e poi dischi, collegamenti di rete e sizing: qualche trucchetto da conoscere prima di firmare un ordine.

Contenuto

Le categorie di hardware per Azure Local

Microsoft e i produttori descrivono l’hardware per Azure Local con tre categorie, che trovate riassunte in questa slide:

Le categorie hardware di Azure Local

Premier Solutions. È il livello con la massima integrazione tra hardware, software e servizi cloud: soluzioni testate di continuo da Microsoft e dai partner, con flussi di deployment completi e aggiornamenti full-stack automatizzati.

Integrated Systems. Sistemi progettati e ottimizzati per Azure Local, con un’esperienza simile a quella di un’appliance dedicata. Sono adatti a chi vuole una soluzione chiavi in mano, con servizio di deployment opzionale e un supporto unico offerto da produttore e Microsoft.

Validated Nodes. Il livello più flessibile: configurazioni più diverse per carichi impegnativi e personalizzazione di processore, memoria, storage e schede di rete, riutilizzando anche hardware esistente se rispetta una soluzione del catalogo.

Ed è qui che c’è una novità che la slide, ormai, non racconta più.

Che fine hanno fatto i Validated Nodes

Se cercate i Validated Nodes nel catalogo Azure Local Solutions, non li trovate più come categoria selezionabile. Un annuncio ufficiale non c’è stato, ma l’MVP Karl-WE se n’era già accorto e lo aveva scritto nero su bianco in un articolo del giugno 2026: il modello a tre livelli (Premier, Integrated, Validated) è diventato un modello a due, Premier Solutions e Integrated Systems.

Il motivo è il servicing. Microsoft ha reso quasi a un clic il download, la distribuzione e l’installazione dei pacchetti SBE attraverso Azure Update Manager, e un hardware che non partecipa a questo flusso non ha più un posto da protagonista nel catalogo. Nel frattempo molti sistemi sono stati consolidati verso Integrated e Premier.

Perché gli SBE contano

SBE sta per Solution Builder Extension: è il pacchetto, fornito dal produttore, con firmware, driver e policy di sicurezza testati per una determinata versione di Azure Local. Dalla versione 2311.2 ogni nuovo hardware Integrated o Premier aggiunto al catalogo deve implementarne uno.

Parlo per esperienza: avere pacchetti SBE gestiti, cosa che sui Validated Nodes non c’era, è la differenza tra un cluster che funziona e un calvario (che di solito si presenta il venerdì pomeriggio). Sui Validated toccava a voi trovare la combinazione giusta di driver e firmware per quella versione di Azure Local, e a ogni aggiornamento sperare che il produttore l’avesse testata, perché nessuno era obbligato a farlo. Con l’SBE quella ricetta arriva già provata da produttore e Microsoft, e passa dallo stesso flusso di aggiornamento di tutto il resto.

Premier e Integrated: la differenza che si sente il giorno dell’aggiornamento

Sulla carta Premier e Integrated sembrano vicine. Il giorno dell’aggiornamento no.

Integrated. Qui tocca a voi. Per i sistemi Integrated gli aggiornamenti di firmware e driver restano manuali, e il produttore vi chiede di verificare la matrice di compatibilità del pacchetto SBE rispetto al nodo e alla versione di Azure Local in uso. In pratica, prima di lanciare ogni aggiornamento dovete controllare lo stato degli SBE del vostro nodo (o dei vostri nodi) e assicurarvi che tutto sia in matrice, per non rischiare nessun tipo di problema. È un lavoro che porta via tempo, e tante volte quel tempo non lo abbiamo. Siccome Azure Local si aggiorna molto spesso, è proprio quando si corre che si fanno i danni.

Premier. Con un Premier, firmware e driver vengono invece aggiornati automaticamente da Azure Update Manager, dentro lo stesso flusso che aggiorna Azure Local. E anche il deploy parte in un altro modo: quando ci consegnano i nodi hanno già un’immagine “ready to deploy”, con a bordo i driver alla versione coerente con quell’immagine del produttore. Non è un dettaglio banale: Azure Local vuole i driver, i suoi driver.

Il primo segnale arriva quando i nodi vengono registrati in Azure Arc: il sistema riconosce l’immagine preinstallata dal produttore (l’OEM image) e, se è obsoleta, la aggiorna prima di completare la registrazione. Nella mia esperienza, a quel punto compare anche la dicitura OEM IMAGE DETECTED. Qui sotto trovate la schermata di una registrazione in Arc, con la riga evidenziata in azzurro.

Registrazione di una macchina in Azure Arc dal terminale. Schermata ricostruita a scopo illustrativo: la riga OEM IMAGE detected è stata aggiunta per indicare il punto in cui compare il rilevamento.

Il secondo segnale lo troviamo all’avvio del deploy da portale. Tra le prime schede della procedura (la scheda Model) c’è il campo Solution Builder Extensions: un link diretto alla pagina del produttore con i pacchetti SBE per quel sistema, cioè la best recipe, la combinazione di driver e firmware indicata per quella versione. Nell’esempio il nodo è un Lenovo ThinkAgile MX, e il link porta al sito Lenovo.

La procedura Deploy Azure Local, scheda Model: il campo Solution Builder Extensions riporta il link del produttore (esempio su Lenovo ThinkAgile MX).

Un’immagine con driver testati e software già installato non serve solo a non piangere durante gli aggiornamenti: serve anche a non piangere durante il deploy. Partire da una base solida, validata, certificata e ready to deploy, come nelle soluzioni Premier, vuol dire essersi già scansati tantissimi problemi che possono saltare fuori proprio mentre si crea l’istanza, per esempio driver e firmware non allineati alla versione di Azure Local. È lo zoccolo duro su cui costruire tutto il resto, e se l’immagine è un po’ datata ci pensa la registrazione in Arc ad aggiornarla.

Con gli Integrated la base c’è, ma hanno comunque bisogno di voi per stare in matrice e non rompersi: sta a voi verificare che driver e firmware siano quelli giusti prima del deploy e a ogni aggiornamento.

Per questo la scelta tra Integrated e Premier non è solo una questione di prezzo: è una scelta su chi si prende, ogni volta, il lavoro (e il rischio) di tenere allineati hardware e software.

Premier e hardware: il canale con il BMC

C’è un dettaglio che si dimentica facilmente: per aggiornare firmware e driver, Azure Local deve parlare con la parte hardware del nodo, cioè il BMC (iDRAC, XCC, iLO). Il canale che l’SBE usa non è la porta di rete esterna dedicata, ma un collegamento interno che unisce il sistema operativo al controller, e nelle guide dei produttori viene chiesto espressamente di lasciarlo attivo. Dell richiede la pass-through NIC dell’iDRAC abilitata e con il suo indirizzo, Lenovo chiede Ethernet over USB attivo su XCC con l’indirizzo predefinito, perché CAU e SBE dipendono da quello.

Nell’XClarity Controller 3 di un Lenovo ThinkAgile MX650 V4 il punto è BMC Configuration, Network, sezione Ethernet over USB: deve essere su Enabled, con le impostazioni IPv4 dedicate a questo canale.

XClarity Controller 3 (MX650 V4): Ethernet over USB abilitato. Qui BMC e sistema operativo hanno 172.20.95.118 e 172.20.95.120, con il port forwarding attivo.

Dal lato del sistema operativo il canale si presenta come un normale adattatore di rete, chiamato IBM USB Remote NDIS Network Device. La guida Lenovo chiede di controllare, prima di un aggiornamento, l’indirizzo IP di questo adattatore e di fare ping al BMC; se l’indirizzo non corrisponde, va riassegnato, come nella schermata qui sotto.

PowerShell sul nodo: rimozione dell’indirizzo dall’adattatore USB Remote NDIS e assegnazione di 170.254.95.120 con prefisso /16.

A questo punto anche il lato XCC deve combaciare: BMC e sistema operativo sulla stessa rete, con le coppie di indirizzi coerenti tra loro.

XClarity Controller 3: BMC 170.254.95.118, sistema operativo 170.254.95.120, maschera 255.255.0.0, port forwarding disattivato.

E non finisce qui: durante il deploy, su un nodo Premier, quella configurazione viene anche controllata, e nella mia esperienza succede sempre. Il pacchetto SBE del produttore estende i controlli di salute che Azure Local esegue prima delle operazioni sul ciclo di vita, deploy compreso, e se quei controlli non passano l’installazione non prosegue (per Dell, ad esempio, devono completarsi con successo perché l’installazione dell’SBE vada avanti). Nell’elenco dei passaggi del deploy compare anche il passo che installa, se serve, gli aggiornamenti hardware tramite Solution Builder Extension.

Un passaggio del deploy: installazione degli aggiornamenti hardware tramite Solution Builder Extension, completata con successo in circa 15 minuti.

Morale: se qualcuno, per una questione di sicurezza, disattiva o riconfigura questo canale, rischia di bloccare il flusso SBE. È uno di quei dettagli che non compaiono sulle schede tecniche e sembrano fuori posto, finché non servono. Il classico “l’ho disattivato perché sembrava inutile” che passa alla storia.

Quanti dischi metto?

Quando si configura un nodo la domanda arriva subito: il produttore ne consiglia almeno due, un altro almeno tre. C’è una regola? Per Microsoft il minimo documentato per Azure Local su hardware fisico è di due dischi capacity per nodo (NVMe o SSD), da almeno 500 GB, uguali su tutti i nodi per numero, tipo, capacità, prestazioni e firmware, più un disco di boot separato. Se si usa anche la cache, servono almeno due dischi in più.

Ma il minimo non è la scelta giusta. Nella mia esperienza, quando Azure Local rileva meno di quattro dischi per nodo (per esempio due) esegue il deploy in modalità small deployment: il cluster nasce, ma in una versione che al momento è in preview, e quindi i due dischi sono supportati solo lì e non per la produzione. Con quattro o più dischi per nodo si resta nel deploy standard. Due dischi funzionano, come un gommone può attraversare l’oceano: ma in produzione non ci andrei.

Il numero dei dischi si lega a doppio filo alla loro combinazione. Qui sotto trovate le geometrie di dischi supportate da Azure Local: sono le uniche, e ogni configurazione fuori da questo schema non rientra nel perimetro supportato. In pratica si può avere un solo tipo di disco (tutto NVMe o tutto SSD) oppure un livello di cache in flash davanti a dischi capacitivi (SSD o HDD). Gli HDD da soli non sono supportati: serve sempre almeno un livello flash, e il vecchio scaffale di dischi rotanti che avete in magazzino può restare dov’è.

Le geometrie di dischi supportate da Azure Local per ogni nodo (esempio con due dischi di cache e quattro capacitivi).

Tre precisazioni. Sul nodo singolo le opzioni si riducono: un solo tipo di disco, tutto NVMe o tutto SSD, senza cache. La combinazione a tre livelli (NVMe in cache, SSD e HDD in capacity) la documentazione Microsoft la definisce piuttosto esotica e non compare tra quelle citate nei requisiti di sistema di Azure Local: se la considerate, fatevela confermare dal produttore. Ho lasciato fuori, per semplicità, le combinazioni con la memoria persistente. Nel caso con cache, i dischi di cache sono almeno due, ciascuno di almeno 32 GB, con una capacità di cache pari ad almeno il 15% di quella capacitiva e un numero di dischi capacitivi multiplo di quelli di cache.

Un consiglio, se state acquistando un cluster Azure Local: per evitare le zone grigie della documentazione, usate sempre, almeno per ora, quattro dischi capacitivi per nodo per lo Storage Spaces Direct, più l’eventuale cache se volete introdurla (in quel caso servono almeno due dischi di cache in più). Quattro capacity è anche il minimo che Windows Server richiede per S2D, quindi vi muovete su un terreno che nessuno discute.

Come collegare i nodi: direct attach o switch

Scelto l’hardware, resta da decidere come collegare i server tra loro: in direct attach, con cavi diretti tra i nodi, oppure tramite switch. Le regole sono semplici e ruotano tutte attorno a un punto: dove viene attraversato il flusso di Storage Spaces Direct.

Direct attach e switch a confronto, con le regole da rispettare dove passa il traffico S2D.

Le regole. Le porte e le NIC attraversate dal flusso S2D devono essere certificate per la parte storage, e servono almeno due porte da 10 Gb.

Nota sulle Mellanox. Il mio consiglio sono le NIC Mellanox (oggi NVIDIA), per la loro stabilità e per il supporto che hanno. Quelle che si usano in questi scenari sono a 10/25 Gb: coprono il minimo delle due porte da 10 Gb e permettono di salire a 25 GbE, la velocità che ODIN raccomanda per lo storage, senza cambiare scheda.

Lo switch. Se passate da uno switch, lo switch deve supportare il protocollo RDMA. In pratica significa DCB, quindi PFC (802.1Qbb) ed ETS (802.1Qaz): Microsoft li richiede per il traffico storage in tutte le configurazioni con switch. Con il direct attach questo requisito non esiste, ma in cambio la soluzione scala poco: la documentazione Microsoft dice che non scala bene oltre i tre nodi, e un cluster switchless non supporta l’add-node, quindi per crescere bisogna rifare il cablaggio e passare a una configurazione con switch. Niente switch, niente problemi, finché non dovete aggiungere un nodo: lì iniziano i cavi.

Il sizing: da dove partire

Il primo punto del sizing è la memoria. Oltre a quella per il sistema operativo e per le VM, Storage Spaces Direct richiede 4 GB di RAM per ogni TB di capacità dei dischi di cache su ogni server, per i suoi metadati. È una regola che si cita spesso come “4 GB per ogni TB di dati”, ma il riferimento è alla cache: conviene tenerlo a mente quando si scelgono dimensione e numero dei dischi.

Per i calcoli uso ODIN. È uno strumento sperimentale ospitato da Microsoft su GitHub, fornito così com’è, e raccoglie sia il sizer sia il calcolatore S2D. Restano stime, quindi la configurazione finale va sempre confermata con il partner e il produttore.

Si parte dai carichi di lavoro: VM Azure Local, cluster AKS Arc, Azure Virtual Desktop e altri scenari, alcuni ancora in preview. Si possono aggiungere a mano oppure importare da Azure Migrate o da RVTools. ODIN restituisce core, memoria e storage necessari. Nell’esempio, un carico di prova da 223 workload richiede 742 vCPU, 4096 GB di RAM e 36,52 TB di storage utilizzabile. Attenzione: i totali includono già un margine di crescita del 10% per il primo anno, quindi il fabbisogno reale è più basso.

Il sizer di ODIN: a sinistra i carichi di lavoro, a destra il fabbisogno calcolato (esempio di prova).

Scorrendo il dettaglio si capisce come ragiona. Nell’esempio servono cinque macchine fisiche, ma ODIN ne considera quattro effettive, perché una è riservata alla tolleranza di guasto e agli aggiornamenti (il famoso N+1). I vCPU sono calcolati con un overcommit di 4:1. Per ogni macchina servono 55 core fisici e 1149 GB di memoria; ODIN dimensiona hardware con 72 core (due socket da 36) e 1536 GB, perché i processori e i banchi di memoria si comprano a tagli precisi.

Le note di sizing. La parte più istruttiva, però, è questa: elencano i costi che di solito si dimenticano di mettere in conto.

Le note di sizing di ODIN: i costi nascosti che riducono la capacità realmente utilizzabile.

Il costo dell’host. Per ogni macchina sono riservati 123 GB di memoria e 8 core fisici per il sistema operativo di Azure Local, la partizione root di Hyper-V, il clustering e lo stack S2D: non sono disponibili per i vostri carichi. L’appliance Azure Resource Bridge si prende 8 GB di memoria e 4 vCPU per cluster. Una curiosità: nell’esempio ogni macchina ha 8 dischi capacitivi da 3,84 TB, cioè 30,72 TB, e 30,72 × 4 GB fa 122,88, che arrotondato dà proprio 123.

Il costo dello storage. Dallo storage utilizzabile ODIN sottrae il volume di infrastruttura (256 GB), quello della cronologia delle prestazioni (20 GB) e uno spazio libero lasciato nel pool per le operazioni di riparazione di S2D, pari fino a quattro dischi capacitivi per macchina: nell’esempio sono 15,36 TB. A questo si aggiunge la resilienza: con il three-way mirror l’efficienza è del 33%, cioè un terzo della capacità grezza.

Quando una VM non entra. ODIN segnala anche quando una VM non ci sta. Nell’esempio un carico che richiede 2048 GB di memoria per VM supera i 1413 GB utilizzabili su una macchina, dopo la riserva dell’host, quindi non può essere posizionato (una VM da 2 TB di RAM è ottimista, ma ODIN non giudica). Sulla rete ricorda che servono NIC con RDMA, con 25 GbE raccomandate: il minimo resta 10 Gb, ma è un buon motivo per pensarci prima di scegliere le porte. Per i sistemi con più di 768 GB di memoria consiglia infine dischi di boot da almeno 400 GB.

Il calcolatore S2D. È l’altra scheda di ODIN e serve a ricavare la dimensione massima di un singolo volume e quanti volumi servono, in base a piattaforma, numero di macchine, copie dei dati (due, tre o quattro), provisioning thin o fixed e dimensione delle extent. Nell’esempio, con quattro macchine, due copie e provisioning thin, il volume massimo è inferiore a 31,5 TB: il risultato include 0,5 TB di overhead e resta sotto il limite di 64 TB per volume. Il suggerimento dello strumento è utile: con tre o più macchine conviene usare tre copie dei dati, per maggiore resilienza e prestazioni.

Il calcolatore S2D di ODIN: dimensione massima di un volume in base a macchine, copie dei dati e provisioning.

Conclusioni

Se dopo questo articolo ricordate una cosa sola, che sia questa: con Azure Local l’hardware non si sceglie solo per quello che ha dentro, ma per chi si occupa di tenerlo aggiornato.

Il catalogo si sta semplificando: meno scelta, più certezza di supporto. I Validated Nodes escono di scena, e il vero spartiacque diventa il flusso di aggiornamento degli SBE, automatico sui Premier e da presidiare a mano sugli Integrated.

Ma l’hardware giusto non è solo questione di marchio e di catalogo. Anche i dettagli del progetto contano: quattro dischi capacitivi per nodo per muoversi su un terreno che nessuno discute, una delle geometrie di dischi supportate (e solo quelle), almeno due porte da 10 Gb per lo storage, certificate dove passa il traffico S2D, e uno switch che supporti RDMA se non scegliete il direct attach. E se per le schede di rete volete meno sorprese, il mio consiglio sono le Mellanox, per stabilità e supporto.

Poi c’è il sizing. Strumenti come ODIN aiutano a non partire alla cieca, ma ricordate che i numeri finali sono sempre più bassi di quelli sulla carta: tra N+1, riserva dell’host, spazio lasciato libero per il repair di S2D e resilienza, la capacità realmente utilizzabile è una frazione di quella acquistata: è il motivo per cui il preventivo sembra sempre enorme e il cluster, a lavoro finito, sempre piccolo. Conviene sempre confrontare il risultato con il partner e con il produttore.

Sulle licenze, invece, vi lascio indagare da soli: provate a dare un’occhiata alle Windows Server Datacenter in Software Subscription tramite CSP, a 1 o 3 anni. È una di quelle cose che conviene scoprire prima di firmare l’ordine e non dopo, quando il preventivo è già partito e tutti vi guardano.

Prima di firmare l’ordine fate queste domande al vostro partner: quale SBE ha quel nodo, fino a quando sarà supportato, quanti dischi e di che tipo, e come sono collegati i nodi e con quali porte. E poi, quando arriva il giorno del primo aggiornamento, vi ringrazierete.