• Guide, Sistemi Operativi
• 27 Gennaio 2026

Sapete bene che in ambienti enterprise e in tutte le infrastrutture in cui continuità del servizio, prestazioni e resilienza sono requisiti fondamentali, lo storage di rete rappresenta un elemento critico. Quando si utilizza iSCSI come protocollo di accesso allo storage, è essenziale evitare che un singolo guasto di rete, di switch o di interfaccia comprometta l’accesso ai volumi esposti ai server.

È proprio in questo contesto che entra in gioco il Multipath I/O (MPIO), una tecnologia che consente a un host Windows di stabilire più percorsi simultanei verso lo stesso iSCSI Target. Grazie a MPIO è possibile ottenere failover automatico, bilanciamento del carico e una maggiore affidabilità complessiva dell’infrastruttura storage.

In questa guida vedremo come abilitare e configurare correttamente il Multipath I/O su Windows Server in uno scenario iSCSI, utilizzando uno storage con doppie interfacce di rete e una topologia ridondata. La configurazione che vi propongo prevede due host Windows, due switch di accesso e uno storage con doppio percorso di rete, una soluzione tipica in ambienti professionali e perfettamente scalabile.

Questa configurazione è valida sia per ambienti di test che per contesti di produzione e rappresenta un passo fondamentale per chiunque voglia costruire un’infrastruttura iSCSI affidabile su Windows Server, inclusi scenari di virtualizzazione con Hyper-V, dove affidabilità, continuità del servizio e prestazioni dello storage sono requisiti imprescindibili.

Nella figura sotto è mostrato lo schema dell’infrastruttura utilizzata nella guida: due host Windows Server (HV1 e HV2) collegati tramite doppie interfacce di rete a due switch distinti, che a loro volta forniscono accesso ridondato allo storage iSCSI. La configurazione garantisce multipli percorsi attivi verso lo stesso iSCSI Target, abilitando failover e alta disponibilità tramite MPIO.

Figura 1: Topologia di rete iSCSI ridondata per configurazione Multipath I/O (MPIO)

Perché è una configurazione best practice

Questa topologia rappresenta una best practice per l’utilizzo di iSCSI con Multipath I/O su Windows Server perché rispetta i principali principi di alta disponibilità, isolamento dei guasti e prevedibilità delle prestazioni. Di seguito i motivi principali:

1. Eliminazione dei Single Point of Failure

Ogni componente critico è ridondato:

• Doppie NIC sugli host (HV1 e HV2)
• Doppie NIC sullo storage
• Due switch separati

In caso di guasto di una scheda di rete, un cavo, uno switch o una porta dello storage, l’accesso al LUN iSCSI rimane operativo grazie ai percorsi alternativi gestiti da MPIO.

2. Percorsi fisicamente separati (true multipath)

Ogni percorso iSCSI segue una catena indipendente:

Host NIC → Switch → Storage NIC

Questo è un punto fondamentale: MPIO è realmente efficace solo quando i path non condividono componenti comuni. La separazione fisica dei percorsi evita che un singolo evento di rete impatti tutti i collegamenti contemporaneamente.

3. Allineamento con il modello MPIO di Windows

Windows Server MPIO funziona in modo ottimale quando:

• Ogni NIC iSCSI utilizza un indirizzo IP dedicato
• Le sessioni iSCSI sono stabilite una per percorso
• I target espongono lo stesso LUN su più interfacce

La topologia mostrata segue esattamente questo modello, consentendo a Windows di riconoscere correttamente i percorsi multipli, presentarli come un unico disco logico e di applicare policy di failover o load balancing supportate.

4. Migliore affidabilità rispetto al NIC Teaming

Nel contesto iSCSI:

• MPIO è preferibile al NIC Teaming
• ogni percorso rimane logicamente separato
• il controllo del failover è demandato allo stack storage, non alla rete

Questo approccio riduce complessità, problemi di compatibilità e comportamenti non deterministici, specialmente in ambienti virtualizzati.

5. Scalabilità e manutenzione semplificata

Una configurazione di questo tipo permette:

• manutenzione di switch o interfacce senza downtime
• aggiunta di nuovi host o storage senza riconfigurazioni invasive
• crescita dell’infrastruttura mantenendo le stesse logiche di design

È una topologia che scala in modo naturale da piccoli ambienti fino a contesti enterprise.

6. Coerenza con le linee guida dei vendor

La configurazione è coerente con le best practice indicate da:

• Microsoft per iSCSI + MPIO su Windows Server
• Vendor storage (come Synology, NetApp, Dell, HPE)
• Ambienti Hyper-V e cluster failover
  

Questa coerenza riduce il rischio di configurazioni non supportate e semplifica il troubleshooting.

Configurazione di rete per gli host

Come ho già scritto prima, su ciascun host Hyper-V sono state configurate due schede di rete dedicate al traffico iSCSI, ognuna collegata a uno switch fisicamente distinto. In questo modo ogni host dispone di due percorsi di rete completamente separati verso lo storage.

Le interfacce iSCSI1 e iSCSI2 sono visibili come Microsoft Hyper-V Network Adapter perché sto utilizzando delle VM e risultano correttamente attive su reti non identificate, condizione normale in assenza di gateway e servizi di rete aggiuntivi. Queste schede sono esclusivamente dedicate allo storage e non vengono utilizzate per traffico di management, produzione o virtual machine.

Questa separazione è fondamentale perché:

• garantisce l’isolamento del traffico iSCSI
• consente a Windows di creare una sessione iSCSI per ogni NIC
• permette a MPIO di gestire correttamente i percorsi multipli
• evita interferenze con il vSwitch di management (vEthernet (Management))

A livello di best practice, ogni NIC iSCSI deve:

• avere un indirizzo IP statico
• non avere gateway predefinito
• non registrarsi nel DNS
• avere la risoluzione netbios disabilitata
• non essere inclusa in configurazioni di NIC Teaming

Figura 2: Configurazione delle interfacce di rete iSCSI sugli host Hyper-V

Nelle proprietà avanzate IPv4 delle schede di rete dedicate a iSCSI è stata disabilitata l’opzione “Register this connection’s addresses in DNS”. Questa impostazione è una best practice fondamentale per le NIC iSCSI, in quanto evita la registrazione di indirizzi IP non destinati al traffico di dominio, riduce il rumore nel DNS e previene potenziali problemi di risoluzione dei nomi in ambienti Windows Server.

Figura 3: Disabilitazione della registrazione DNS sulle interfacce iSCSI

Nelle impostazioni avanzate IPv4 delle schede di rete dedicate a iSCSI selezionate l’opzione “Disable NetBIOS over TCP/IP”. Questa configurazione rientra nelle best practice per ambienti iSCSI, in quanto elimina traffico legacy non necessario, riduce il broadcast sulla rete storage e contribuisce a mantenere le interfacce iSCSI pulite e dedicate esclusivamente al traffico di accesso alle LUN.

Figura 4: Disabilitazione di NetBIOS over TCP/IP sulle interfacce iSCSI

Installazione della funzionalità Multipath I/O su Windows Server

Il Multipath I/O (MPIO) è una funzionalità di Windows Server che consente a un sistema operativo di utilizzare più percorsi di rete o di trasporto per accedere allo stesso dispositivo di storage, come una LUN iSCSI.

Dal punto di vista operativo, MPIO:

• presenta al sistema un unico disco logico, anche se fisicamente raggiungibile tramite più connessioni
• monitora costantemente lo stato dei percorsi disponibili
• esegue failover automatico in caso di guasto di una NIC, di un cavo, di uno switch o di una porta dello storage
• può distribuire il carico I/O su più path, a seconda della policy configurata

In uno scenario iSCSI, ogni scheda di rete dedicata crea una sessione indipendente verso il target. MPIO coordina queste sessioni, garantendo continuità del servizio e maggiore resilienza, senza richiedere interventi manuali in caso di problemi di rete.

Nel wizard Add Roles and Features del Windows Server che volete collegare alla vostra SAN iSCSI selezionate la funzionalità Multipath I/O e procedete all’installazione.

Figura 5: Installazione della funzionalità Multipath I/O su Windows Server

Al termine dell’installazione effettuate un riavvio. Il riavvio al termine dell’installazione di Multipath I/O è necessario perché la funzionalità MPIO introduce componenti a basso livello dello stack di storage di Windows, che non possono essere inizializzati completamente a caldo.

In particolare, durante l’installazione MPIO:

• vengono installati driver kernel-mode
• viene abilitato il Microsoft Device Specific Module (DSM)
• vengono modificate dipendenze dello storage stack e del servizio Plug and Play
• vengono preparati i meccanismi di gestione dei percorsi multipli per i dispositivi di storage

Senza un riavvio i driver MPIO non vengono caricati correttamente, i dispositivi iSCSI già presenti potrebbero non essere associati a MPIO ed il sistema potrebbe continuare a vedere i LUN come dischi separati invece che come un unico dispositivo multipath.

Dopo il riavvio, aprite la console MPIO a Server Manager > Tools > MPIO e dalle MPIO Properties, scheda Discover Multi-Paths, attivate l’opzione “Add support for iSCSI devices” e confermate con Add. Questo passaggio istruisce Windows Server a gestire i dispositivi iSCSI tramite MPIO, consentendo il corretto rilevamento e l’aggregazione dei percorsi multipli verso lo stesso LUN iSCSI.

Figura 6: Abilitazione del supporto iSCSI in Multipath I/O

Effettuate un secondo riavvio. Il secondo riavvio è necessario perché, dopo aver abilitato il supporto MPIO per i dispositivi iSCSI, Windows deve rieseguire il rilevamento completo dei dispositivi di storage applicando le nuove regole di multipathing; in più garantisce che tutti i dispositivi iSCSI vengano enumerati fin dall’avvio come MPIO-enabled

In questa fase, infatti:

• Windows associa i dischi iSCSI esistenti al driver MPIO
• viene aggiornato il binding tra sessioni iSCSI e DSM (Device Specific Module)
• Le LUN precedentemente viste come dischi separati vengono riconsolidate in un unico dispositivo multipath
• lo stack di storage viene inizializzato con le nuove policy MPIO

Nella scheda MPIO Devices della console MPIO Properties è ora visibile l’identificativo MSFT2005iSCSIBusType_0x9, che indica che Windows Server ha correttamente associato i dispositivi iSCSI al driver MPIO.

Figura 7: Verifica dei dispositivi iSCSI gestiti da MPIO

Configurazione dell’iSCSI Initiator

L’iSCSI Initiator è il componente software che consente a un sistema operativo di connettersi a uno storage remoto tramite protocollo iSCSI, utilizzando una normale rete IP.

In termini semplici:

• l’initiator è il client
• il target iSCSI è il server di storage

A cosa serve l’iSCSI Initiator

L’iSCSI Initiator permette a un host Windows Server di:

• individuare uno o più iSCSI Target sulla rete
• stabilire sessioni di connessione verso le LUN esposte
• autenticarsi (ad esempio tramite CHAP)
• presentare le LUN al sistema come dischi locali, pur essendo fisicamente remoti

Una volta connesso, lo storage iSCSI viene gestito dal sistema operativo come un normale disco, rendendolo utilizzabile per volumi NTFS/ReFS, storage per Hyper-V, cluster failover o per workload applicativi.

Sugli host che volete collegare, da Server Manager > Tools > lanciate iSCSI Initiator. All’apertura dello strumento iSCSI Initiator, Windows Server segnala che il servizio Microsoft iSCSI non è in esecuzione. Confermando con Yes, il servizio viene avviato e configurato per l’avvio automatico al boot del sistema.

Figura 8: Avvio e configurazione del servizio Microsoft iSCSI Initiator

Nella scheda Discovery delle proprietà di iSCSI Initiator aggiungete manualmente un Target Portal, specificando l’indirizzo IP dello storage iSCSI e la porta TCP 3260 (predefinita per iSCSI). Questo passaggio consente all’host Windows Server di individuare i target iSCSI disponibili sulla rete ed è il primo step operativo per stabilire le connessioni verso i LUN, che verranno poi gestite tramite MPIO.

Figura 9: Configurazione del Target Portal nell’iSCSI Initiator

Nella scheda Targets di iSCSI Initiator selezionate il target iSCSI individuato (1) e fate clic su Connect (2). Nella finestra di connessione abilitate l’opzione Enable multi-path (3) e accedete alle Advanced Settings (4) per specificare i parametri del percorso.
Nelle impostazioni avanzate selezionate Microsoft iSCSI Initiator come adattatore locale (5), indicate l’Initiator IP associato alla scheda di rete iSCSI dedicata (6) e specificate il Target portal IP corrispondente (7). Confermate infine la configurazione facendo clic su OK (8).
Questo passaggio va ripetuto per ogni combinazione di NIC iSCSI e porta dello storage, al fine di creare tutti i percorsi necessari affinché MPIO possa gestire correttamente la ridondanza e il failover.

Figura 10: Connessione al target iSCSI con abilitazione del multipath

Ripetete la procedura di connessione al target iSCSI selezionando nuovamente il target già individuato (1) e facendo clic su Connect (2). Abilitate Enable multi-path (3) e accedete alle Advanced Settings (4).
In questa seconda connessione selezionate una Initiator IP differente, associata alla seconda scheda di rete iSCSI dell’host (5–6), e scegliete il Target portal IP corrispondente alla seconda interfaccia di rete dello storage (7). Confermate infine con OK (8).
Completando questa operazione, create un ulteriore percorso indipendente verso lo stesso LUN, permettendo a MPIO di gestire correttamente la ridondanza e il failover tra i path disponibili.

Figura 11: Configurazione del secondo percorso iSCSI per il multipath

Nella scheda Targets di iSCSI Initiator verificate che il target risulti in stato Connected (1), quindi fate clic su Properties (2). Nella sezione Sessions vengono visualizzate due sessioni iSCSI distinte, una per ciascun percorso di rete configurato.
La presenza di più sessioni attive conferma che le connessioni iSCSI sono state correttamente stabilite su interfacce separate e che MPIO dispone di tutti i path necessari per gestire ridondanza e failover verso lo storage iSCSI.

Figura 12: Verifica delle sessioni iSCSI attive verso lo storage

Nella scheda Volumes and Devices delle proprietà di iSCSI Initiator fate clic su Auto Configure per associare automaticamente tutti i volumi disponibili al servizio iSCSI.
Questo passaggio garantisce che i dischi iSCSI siano correttamente riconosciuti e resi disponibili al sistema anche dopo un riavvio, completando la configurazione del multipath lato host.

In particolare, Auto Configure:

• rileva tutti i LUN iSCSI già connessi
• li associa correttamente alle sessioni iSCSI attive
• assicura che i dischi siano disponibili automaticamente all’avvio del sistema
• garantisce che i dispositivi vengano gestiti correttamente da MPIO fin dalle prime fasi del boot

Senza questo passaggio:

• i volumi potrebbero non essere immediatamente disponibili dopo un riavvi
• servizi o ruoli che dipendono dallo storage (Hyper-V, cluster, applicazioni) potrebbero non avviarsi correttamente
• la gestione dei percorsi multipli potrebbe risultare non deterministica

Figura 13: Associazione dei volumi iSCSI al servizio iSCSI Initiator

Da Disk Management selezionate il disco iSCSI e aprite le Properties, quindi accedete alla scheda MPIO. In questa sezione verificate che il disco sia gestito dal Microsoft DSM e che siano presenti più path attivi in stato Active/Optimized.
La visualizzazione di più percorsi conferma che la configurazione MPIO è correttamente operativa e che lo storage iSCSI viene raggiunto tramite connessioni ridondate, garantendo alta disponibilità e continuità del servizio.

Figura 14: Verifica del Multipath I/O da Disk Management

La configurazione del Multipath I/O per iSCSI può essere eseguita anche tramite PowerShell, offrendo un approccio più rapido, ripetibile e facilmente automatizzabile, particolarmente utile in ambienti enterprise o con più host da configurare. Qui di seguito un semplice script per rifare le stesse operazioni che avete fatto prima graficamente.

Ottimizzazione delle prestazioni iSCSI: configurazione dei Jumbo Frame

Dopo aver completato la configurazione di MPIO e verificato il corretto funzionamento dei percorsi multipli, è possibile ottimizzare ulteriormente le prestazioni dello storage iSCSI configurando i Jumbo Frame.

L’utilizzo dei Jumbo Frame non è strettamente necessario per il funzionamento di iSCSI o MPIO, ma rappresenta una best practice in ambienti di produzione, in quanto consente di:

• ridurre l’overhead della CPU
• diminuire il numero di pacchetti trasmessi
• migliorare throughput e latenza, soprattutto su carichi I/O elevati

È importante sottolineare che questa configurazione deve essere applicata esclusivamente alle NIC iSCSI e solo se tutti i componenti del percorso (host, switch e storage) supportano e utilizzano la stessa MTU. Un’implementazione non coerente può causare problemi di connettività o degrado delle prestazioni.

Impostazione dei Jumbo Frame sulle NIC iSCSI

Accedete alle proprietà avanzate delle schede di rete iSCSI e impostate il parametro relativo ai Jumbo Frame.
A seconda del driver della scheda di rete, l’opzione può essere indicata come:

• Jumbo Packet → valore tipico 9014
• MTU → valore 9000

Il valore effettivo dipende dal vendor e dal driver utilizzato, ma l’obiettivo è consentire una MTU di 9000 byte.

Questa impostazione va applicata a tutte le NIC iSCSI presenti sull’host, mantenendo lo stesso valore su ciascuna interfaccia.

Figura 15: Impostazione dei Jumbo Frame sulle NIC iSCSI

Verifica della configurazione dei Jumbo Frame

Una volta applicata la configurazione, è fondamentale verificarne il corretto funzionamento.

Verifica tramite PowerShell

Utilizzate PowerShell per controllare che le schede di rete iSCSI abbiano il parametro correttamente impostato:

Verificate che il valore configurato corrisponda a 9000 / 9014, in base al driver della scheda.

In alternativa, potete verificare l’MTU effettiva con:

Figura 16: Verifica dell’impostazione del Jumbo Frame

Verifica della connettività end-to-end

Per confermare che i Jumbo Frame funzionino correttamente lungo l’intero percorso, eseguite un test di ping verso l’indirizzo IP iSCSI dello storage utilizzando pacchetti di grandi dimensioni:

Se il test ha esito positivo senza frammentazione, significa che la configurazione dei Jumbo Frame è coerente tra host, switch e storage.

Figura 17: Verifica della connettività utilizzando i Jumbo Frames

Nota importante: utilizzo di schede di rete virtuali Hyper-V

Nel contesto di questa guida, gli host Windows Server utilizzano schede di rete virtuali Hyper-V (Microsoft Hyper-V Network Adapter) per il traffico iSCSI, collegate a un vSwitch esterno.

Quando si utilizzano NIC virtuali, la configurazione dei Jumbo Frame non avviene direttamente sulla scheda virtuale, ma deve essere applicata a monte, ovvero:

• sulla scheda di rete fisica associata al vSwitch
• sul vSwitch Hyper-V
• sulle interfacce di rete dello storage
• sugli switch fisici

Le schede virtuali erediteranno automaticamente la MTU impostata sul percorso sottostante.

Configurazione dei Jumbo Frame in ambienti Hyper-V con NIC virtuali

Se il traffico iSCSI passa attraverso un vSwitch Hyper-V, dovete:

1. Configurare i Jumbo Frame sulla NIC fisica utilizzata dal vSwitch
2. Verificare che il vSwitch esterno supporti e utilizzi la stessa MTU
3. Assicurare coerenza della MTU sugli switch e sullo storage

Sulle schede di rete virtuali (vEthernet) non è necessario né consigliato impostare manualmente il valore MTU.

Verifica corretta in ambiente Hyper-V

Verifica sulla NIC fisica

Verificate che la NIC fisica associata al vSwitch iSCSI sia impostata su 9000 / 9014.

Verifica MTU lato host

Le interfacce virtuali iSCSI erediteranno il valore MTU dal vSwitch.

Verifica end-to-end

Il test di connettività rimane invariato:

Se il ping ha successo, la configurazione dei Jumbo Frame è corretta lungo tutto il percorso, incluso Hyper-V, rete fisica e storage.

Nota sul laboratorio: Hyper-V con Nested Virtualization

La configurazione descritta in questa guida è stata realizzata all’interno di un laboratorio Hyper-V che utilizza la nested virtualization. In questo scenario, gli host Hyper-V sono a loro volta macchine virtuali e le interfacce di rete utilizzate per il traffico iSCSI sono schede di rete virtuali.

In un ambiente di nested virtualization:

• la rete è interamente virtualizzata
• il percorso dei pacchetti attraversa più livelli di astrazione
• alcune ottimizzazioni di basso livello, come i Jumbo Frame, possono non essere pienamente rappresentative delle prestazioni ottenibili su hardware fisico

Jumbo Frame e nested virtualization

In questo contesto, l’abilitazione dei Jumbo Frame non è sempre verificabile o significativa come in un ambiente fisico, perché:

• la MTU effettiva dipende dall’host Hyper-V sottostante
• il vSwitch dell’host fisico può limitare la dimensione dei frame
• le NIC virtuali non espongono tutte le opzioni avanzate dei driver hardware

Per questo motivo, in un laboratorio con nested virtualization, i Jumbo Frame vanno considerati un concetto architetturale e di best practice, più che un’ottimizzazione prestazionale misurabile.

Validità della configurazione

È importante sottolineare che:

• la configurazione iSCSI + MPIO rimane pienamente valida
• il comportamento funzionale (multipath, failover, resilienza) è correttamente testabile
• le considerazioni sui Jumbo Frame restano applicabili in ambienti fisici di produzione

Il laboratorio consente quindi di validare la correttezza della configurazione, mentre i benefici prestazionali dei Jumbo Frame devono essere valutati su hardware reale.

Conclusioni

In questa guida avete visto come configurare correttamente il Multipath I/O (MPIO) su Windows Server in un ambiente iSCSI, partendo dalla progettazione della topologia di rete fino alla verifica finale dei percorsi attivi dallo storage.

Seguendo una configurazione basata su best practice, con schede di rete dedicate, switch separati e percorsi fisicamente indipendenti, avete ottenuto un’infrastruttura ridondata, resiliente e pronta per l’uso in produzione. L’integrazione tra iSCSI Initiator e MPIO consente a Windows di gestire in modo trasparente il failover dei percorsi e, se configurato, anche il bilanciamento del carico I/O.

MPIO non è un’opzione avanzata, ma un requisito fondamentale quando si utilizza iSCSI in ambienti professionali. Implementarlo correttamente significa ridurre i rischi operativi, aumentare l’affidabilità dello storage e garantire continuità ai servizi che dipendono da esso, come Hyper-V, cluster failover e workload critici.