Installazione, configurazione iSCSI, MPIO e best practice per ambienti Hyper-V enterprise ad alta affidabilità.
DataCore SANsymphony permette di trasformare lo storage fisico in una piattaforma altamente disponibile, separando la gestione dello storage dal singolo sistema hardware.
In combinazione con Microsoft Hyper-V, una corretta progettazione delle reti, del multipathing e del cluster consente di ottenere un’infrastruttura resiliente, senza single point of failure e con continuità operativa anche in caso di guasto di un componente.
Architettura
L’architettura di riferimento prevede:
- Cluster DataCore SANsymphony a 2 nodi
- Storage locale o storage sottostante ridondato
- Mirror sincrono tra i nodi DataCore
- Reti Front-End iSCSI ridondate
- Microsoft Hyper-V come piattaforma di virtualizzazione
- Microsoft MPIO / DataCore MPIO per la gestione dei path
- Hyper-V Failover Cluster, quando richiesto
- Cluster Shared Volumes (CSV) per gli ambienti Hyper-V clustered
- Separazione del traffico Mirror dal traffico Front-End
L’obiettivo è garantire la ridondanza lungo tutta la catena:
Storage → DataCore → Network → iSCSI → MPIO → Hyper-V → Cluster → VM
Separazione delle reti
Una delle configurazioni più importanti riguarda la separazione dei diversi tipi di traffico.
Mirror Network
La rete Mirror viene utilizzata per la replica sincrona tra i nodi DataCore.
Esempio:
- MR01 →
11.11.11.0/29 - MR02 →
22.22.22.0/29
Front-End iSCSI
Le reti Front-End vengono utilizzate dagli host Hyper-V per accedere ai Virtual Disk pubblicati da DataCore.
Esempio:
- FE01 →
33.33.33.0/29 - FE02 →
44.44.44.0/29
🟢 BEST PRACTICE
Separare sempre il traffico Mirror dal traffico Front-End iSCSI.
La separazione consente di evitare che il traffico di replica possa competere con il traffico generato dagli host Hyper-V, riducendo il rischio di latenza e degrado delle performance.
🔴 ATTENZIONE
Le reti dedicate al traffico Mirror normalmente non devono avere un gateway configurato.
Le reti storage devono essere progettate in modo coerente con la topologia di rete e con le indicazioni DataCore.
Configurazione DataCore
DATACORE01
Esempio di configurazione:
- MR01 →
11.11.11.1 - MR02 →
22.22.22.1 - FE01 →
33.33.33.1 - FE02 →
44.44.44.1
DATACORE02
Esempio di configurazione:
- MR01 →
11.11.11.2 - MR02 →
22.22.22.2 - FE01 →
33.33.33.2 - FE02 →
44.44.44.2
Gli indirizzi riportati sono esclusivamente un esempio di progettazione.
In un ambiente reale devono essere utilizzate le subnet previste dal progetto infrastrutturale.
Mirror DataCore
Il Mirror DataCore permette di mantenere una copia sincronizzata dei dati tra i due nodi SANsymphony.
In caso di perdita di uno dei nodi, il sistema può continuare a fornire accesso ai dati attraverso il nodo disponibile, secondo la configurazione di protezione adottata.
Verificare:
- Mirror attivo
- Connessione tra i nodi stabile
- Latenza conforme al progetto
- Banda disponibile
- Assenza di packet loss
- Nessun errore o warning critico
- Corretta associazione delle interfacce Mirror
🟢 BEST PRACTICE
Il traffico Mirror deve utilizzare le interfacce dedicate alla replica.
Evitare di utilizzare le interfacce Front-End iSCSI per il traffico di Mirror quando l’obiettivo è realizzare una vera separazione delle reti.
Configurazione Hyper-V
Gli host Hyper-V devono essere dotati di interfacce di rete dedicate o opportunamente configurate per il traffico iSCSI.
Esempio:
HYPERV01
- iSCSI01 → rete FE01
- iSCSI02 → rete FE02
HYPERV02
- iSCSI01 → rete FE01
- iSCSI02 → rete FE02
La configurazione deve garantire che la perdita di una singola interfaccia, switch o percorso non provochi la perdita dell’accesso allo storage.
🔴 ERRORE CRITICO
Evitare, ove possibile, di utilizzare la stessa interfaccia fisica per:
- Management
- iSCSI
- Live Migration
- Cluster
- Backup
La separazione delle reti consente di ridurre la competizione tra traffico storage e traffico applicativo.
Microsoft iSCSI Initiator
Su ogni host Hyper-V:
- Verificare che il servizio Microsoft iSCSI Initiator sia attivo.
- Aprire iSCSI Initiator.
- Configurare le connessioni verso gli endpoint Front-End DataCore.
- Utilizzare le interfacce iSCSI dedicate.
- Configurare le connessioni persistenti.
- Verificare le sessioni attive.
- Verificare la presenza dei path multipli.
Le connessioni devono essere progettate in modo ridondato verso i nodi DataCore disponibili.
Multipathing
La semplice presenza di più sessioni iSCSI non è sufficiente per ottenere una corretta ridondanza.
È necessario configurare Multipath I/O (MPIO) sul sistema operativo Windows Server e verificare che i diversi percorsi vengano riconosciuti come path appartenenti allo stesso dispositivo.
Installazione MPIO
Su Windows Server è possibile installare la funzionalità MPIO tramite PowerShell:
Install-WindowsFeature -Name Multipath-IO
Al termine dell’installazione potrebbe essere necessario riavviare il server.
Successivamente aprire:
Server Manager → Tools → MPIO
e verificare la corretta configurazione dei dispositivi multipath.
DataCore MPIO
Per gli host Windows, DataCore mette a disposizione strumenti e componenti specifici per l’integrazione dello storage SANsymphony con Windows.
Quando previsto dalla configurazione e dalla versione utilizzata, è consigliabile utilizzare il DataCore Windows Integration Kit e seguire la relativa procedura di configurazione.
Questo consente di integrare correttamente:
- Storage DataCore
- Microsoft Windows
- MPIO
- ALUA
- Gestione dei path
- Failover
🟢 BEST PRACTICE
Non installare o configurare MPIO in modo indiscriminato sui DataCore Server.
È importante distinguere tra:
MPIO dell’host Hyper-V
e
gestione dei percorsi utilizzati internamente dai DataCore Server.
Le due configurazioni hanno finalità e modalità di gestione differenti.
ALUA
Negli ambienti SANsymphony che utilizzano multipathing, ALUA (Asymmetric Logical Unit Access) svolge un ruolo importante nella gestione dei percorsi verso i Virtual Disk.
ALUA permette al sistema operativo di distinguere i percorsi preferiti da quelli alternativi e di gestire correttamente il traffico verso lo storage.
La configurazione deve essere effettuata secondo la versione di SANsymphony, Windows Server e DataCore Windows Integration Kit utilizzati.
Configurazione dei path
In una configurazione ridondata, un host Hyper-V deve poter raggiungere i DataCore Server attraverso percorsi indipendenti.
Esempio concettuale:
| Host Hyper-V | DataCore | Rete | Percorso |
|---|---|---|---|
| HYPERV01 | DATACORE01 | FE01 | Path 1 |
| HYPERV01 | DATACORE01 | FE02 | Path 2 |
| HYPERV01 | DATACORE02 | FE01 | Path 3 |
| HYPERV01 | DATACORE02 | FE02 | Path 4 |
In una configurazione di questo tipo è possibile arrivare a 4 path per Virtual Disk, ma il numero effettivo dipende dalla topologia dell’infrastruttura.
🟢 BEST PRACTICE
Non considerare “4 path” come un requisito assoluto.
Il requisito fondamentale è che esistano path multipli, indipendenti e correttamente gestiti da MPIO, in modo che la perdita di un singolo percorso non provochi la perdita dello storage.
Verifica MPIO
Dopo la configurazione è necessario verificare che Windows riconosca correttamente il multipath.
È possibile utilizzare:
mpclaim -s -d
e gli strumenti disponibili nella console MPIO.
Verificare:
- Device DataCore riconosciuto
- Numero di path
- Stato dei path
- Path attivi
- Path standby, se previsti
- Policy MPIO
- Assenza di path degradati
Policy MPIO
La policy MPIO deve essere configurata in funzione della versione di SANsymphony, Windows Server e della modalità di accesso ai Virtual Disk.
Per le configurazioni DataCore che utilizzano ALUA, la gestione dei path deve rispettare la logica di path preferiti e alternativi prevista dalla configurazione DataCore.
A seconda dello scenario possono essere utilizzate policy come:
- Round Robin with Subset
- Fail Over Only
La scelta deve essere effettuata sulla base della configurazione effettiva e della documentazione DataCore applicabile.
🔴 ERRORE CRITICO
Non applicare automaticamente a Hyper-V i parametri utilizzati in ambienti VMware.
Ad esempio:
Round Robin con iops=10
è un’impostazione tipicamente associata al multipathing VMware e non deve essere trasferita automaticamente a Microsoft MPIO.
Presentazione del Virtual Disk
Dopo la configurazione dei path, il Virtual Disk DataCore deve essere presentato agli host Hyper-V.
Su Windows Server verificare:
Get-Disk
e controllare:
- Disco presente
- Stato Online
- Dimensione corretta
- Identificazione corretta
- Accessibilità da tutti i nodi Hyper-V
- Presenza dei path multipli
Hyper-V Failover Cluster
Quando Hyper-V viene implementato in modalità cluster, tutti i nodi devono poter accedere allo storage condiviso.
La configurazione deve prevedere:
- Storage condiviso DataCore
- MPIO su ogni nodo
- Connessioni iSCSI ridondate
- Accesso ai medesimi Virtual Disk
- Configurazione coerente tra i nodi
- Reti Cluster dedicate o opportunamente progettate
- Live Migration configurata
Cluster Shared Volumes – CSV
Negli ambienti Hyper-V Failover Cluster, i Cluster Shared Volumes (CSV) consentono ai diversi nodi del cluster di accedere contemporaneamente allo storage utilizzato dalle macchine virtuali.
Un esempio di percorso può essere:
C:\ClusterStorage\Volume1
C:\ClusterStorage\Volume2
I CSV possono essere utilizzati per ospitare i file delle macchine virtuali e i relativi VHDX.
🟢 BEST PRACTICE
La suddivisione dei Virtual Disk deve essere progettata in funzione del workload.
È possibile separare, quando opportuno:
- VM Operating System
- VM Data
- Database
- Applicazioni ad alto I/O
- Backup e staging
Non è però necessario creare un LUN per ogni macchina virtuale: il dimensionamento deve essere basato sulle esigenze reali di performance, capacità e gestione.
Live Migration
In un ambiente Hyper-V clustered è consigliabile separare il traffico di:
- Management
- Cluster
- Live Migration
- Storage/iSCSI
- Backup
La separazione permette di evitare che un’attività di Live Migration o di backup possa saturare la rete utilizzata per lo storage.
Ottimizzazione delle NIC iSCSI
Le interfacce utilizzate per iSCSI devono essere configurate coerentemente end-to-end.
Verificare:
- Velocità della NIC
- Driver aggiornati
- Firmware aggiornato
- VLAN corretta
- MTU coerente, se viene utilizzato Jumbo Frame
- Assenza di configurazioni di rete incoerenti
- Connettività verso tutti gli endpoint DataCore
- Assenza di packet loss
🔴 ATTENZIONE
Non modificare indiscriminatamente parametri avanzati delle NIC come:
- RSS
- VMQ
- Offload
- Receive/Transmit Buffers
- Jumbo Frames
Ogni modifica deve essere valutata in funzione del modello della NIC, del driver, del firmware, della velocità della rete e delle raccomandazioni Microsoft/DataCore.
Tuning delle macchine virtuali
Le macchine virtuali che utilizzano storage DataCore devono essere configurate secondo le caratteristiche del workload.
Per i dischi dati è normalmente preferibile utilizzare il controller virtuale SCSI.
I VHDX devono essere dimensionati considerando:
- Capacità
- IOPS
- Throughput
- Latenza
- Crescita prevista
- Tipologia del workload
Per workload particolarmente intensivi può essere opportuno valutare anche:
- CPU allocation
- NUMA
- Memory configuration
- Storage QoS
- qualità del sottosistema storage
Monitoraggio DataCore
Dopo la configurazione è fondamentale monitorare SANsymphony.
Controllare periodicamente:
- Mirror Status
- Storage Pool Status
- Virtual Disk Status
- I/O Throughput
- I/O Latency
- Cache Utilization
- Front-End Activity
- Mirror Activity
- Errori
- Warning
Monitoraggio Hyper-V
Sul sistema Windows è opportuno verificare:
- Event Viewer
- MPIO
- iSCSI Initiator
- Failover Cluster Manager
- Hyper-V Manager
- Performance Monitor
Particolare attenzione deve essere posta agli eventi relativi a:
- iSCSI
- MPIO
- Storport
- Disk
- Failover Cluster
- CSVFS
Test di Failover
Una configurazione enterprise non può essere considerata completata senza un test di failover.
I test devono essere eseguiti in modo controllato e possibilmente durante una finestra di manutenzione.
Test 1 – Perdita di un path
Disabilitare una delle interfacce iSCSI.
Verificare:
- LUN ancora disponibile
- VM operative
- Path alternativi attivi
- Nessuna perdita dello storage
- Eventi MPIO coerenti
Test 2 – Perdita di una rete Front-End
Simulare la perdita della rete FE01.
Verificare che gli host continuino ad accedere ai Virtual Disk attraverso FE02.
Test 3 – Perdita di un nodo DataCore
Simulare, secondo la procedura DataCore prevista, la perdita di uno dei nodi.
Verificare:
- Disponibilità dello storage
- Stato del Mirror
- Path MPIO
- Continuità delle VM
- Eventuali eventi registrati dal sistema
Test 4 – Failover Hyper-V
In ambiente cluster:
- spostare una VM tra i nodi
- verificare l’accesso allo storage
- verificare la Live Migration
- verificare lo stato dei CSV
- verificare la corretta gestione dei path
Errori da evitare
🔴 ERRORI CRITICI
- Utilizzare Mirror e Front-End sulla stessa rete senza una motivazione progettuale
- Configurare gateway sulle reti Mirror
- Utilizzare un unico path iSCSI
- Configurare MPIO senza verificarne il funzionamento
- Utilizzare una sola NIC per tutto il traffico
- Non verificare ALUA quando previsto
- Non verificare i path dal sistema operativo
- Applicare tuning VMware a Hyper-V
- Impostare arbitrariamente
iops=10su Microsoft MPIO - Modificare i parametri avanzati delle NIC senza una motivazione tecnica
- Non testare il failover
- Considerare sufficiente la sola visibilità del LUN
- Ignorare gli eventi MPIO, Storport e iSCSI
- Non verificare la configurazione su tutti i nodi Hyper-V
Checklist finale
DataCore
- Mirror attivo
- Mirror Network separata
- Front-End Network separata
- Nessun gateway sulla rete Mirror
- Storage Pool operativo
- Virtual Disk operativo
- Nessun warning critico
Hyper-V
- NIC iSCSI dedicate
- Microsoft iSCSI Initiator configurato
- Connessioni iSCSI persistenti
- MPIO installato
- DataCore Virtual Disk riconosciuto
- ALUA configurato quando previsto
- Path multipli verificati
- Nessun path degradato
Cluster
- Tutti i nodi vedono lo storage
- CSV configurati quando richiesti
- Live Migration configurata
- Reti correttamente separate
- Failover testato
Performance
- Latency stabile
- Throughput conforme al progetto
- Nessun packet loss
- Nessun path degradato
- Nessun errore MPIO
- Nessun errore Storport
- Mirror stabile
Conclusione
🟢 KEY TAKEAWAY
DataCore SANsymphony e Microsoft Hyper-V possono costituire una piattaforma altamente resiliente, ma l’alta disponibilità non nasce dal solo Mirror DataCore.
La resilienza deve essere progettata end-to-end:
DataCore → Network → iSCSI → MPIO → Hyper-V → Cluster → VM
Una corretta combinazione di:
Mirror ridondato + reti Front-End separate + MPIO + ALUA + Hyper-V Cluster + CSV
permette di ridurre i single point of failure e di garantire continuità operativa anche in presenza di guasti a singoli componenti dell’infrastruttura.
La regola fondamentale è semplice:
La ridondanza deve essere verificata, non semplicemente configurata.
Avere due NIC, due switch o due DataCore non significa automaticamente avere un’infrastruttura realmente ridondata.
La configurazione deve essere verificata attraverso test reali di perdita di path, rete, nodo DataCore e, quando presente, nodo Hyper-V.
FAQ
MPIO è necessario con DataCore?
Per gli host Windows che utilizzano percorsi multipli verso lo storage iSCSI, MPIO è il componente fondamentale per gestire correttamente il multipathing e il failover.
Quanti path iSCSI servono?
Non esiste un numero universale valido per ogni architettura.
Il numero dipende dalla topologia DataCore, dalle interfacce Front-End, dagli switch e dalla configurazione degli host.
In una configurazione a due DataCore con due reti Front-End indipendenti è possibile arrivare a quattro path per Virtual Disk.
È obbligatorio utilizzare quattro path?
No.
Il requisito fondamentale è avere percorsi multipli e indipendenti, correttamente gestiti da MPIO.
Serve ALUA?
ALUA è utilizzato nelle configurazioni DataCore che ne prevedono l’utilizzo per la gestione dei path.
La configurazione deve essere verificata rispetto alla versione di SANsymphony e alla configurazione Windows adottata.
Posso utilizzare Microsoft MPIO?
Sì, DataCore supporta l’integrazione con Microsoft MPIO. La configurazione deve essere effettuata secondo la documentazione DataCore applicabile alla specifica versione.
Posso utilizzare il DataCore Windows Integration Kit?
Sì. Quando previsto per la configurazione adottata, il Windows Integration Kit permette di integrare correttamente l’host Windows con SANsymphony e la gestione del multipathing.
Devo utilizzare Round Robin con IOPS = 10?
No.
Il parametro iops=10 è associato a specifiche configurazioni VMware e non deve essere trasferito automaticamente a Microsoft MPIO.
Posso utilizzare la stessa NIC per Management e iSCSI?
È tecnicamente possibile in determinate configurazioni, ma in un ambiente enterprise è preferibile separare il traffico storage dagli altri flussi di rete.
Il Mirror DataCore sostituisce MPIO?
No.
Il Mirror protegge la disponibilità dei dati tra i nodi DataCore.
MPIO protegge invece il percorso di accesso dell’host allo storage.
Sono due livelli differenti della stessa architettura di resilienza.
Come verifico che la configurazione sia realmente ridondata?
Attraverso test controllati di:
- perdita di un path
- perdita di una NIC
- perdita di una rete Front-End
- perdita di uno switch
- perdita di un nodo DataCore
- failover Hyper-V
La configurazione è realmente resiliente quando il guasto di un singolo componente non interrompe l’accesso allo storage e, dove previsto, la disponibilità delle macchine virtuali.