Sur certains Dell PowerEdge R730/R760 sous Windows Server 2019/2022, un volume iSCSI (R:) disparaît de l’Explorateur et de Disk Management alors que la LUN demeure « présente » côté Nexsan Unity. Ce guide fournit un diagnostic opérationnel, des correctifs et un runbook prêt à l’emploi.
Disparition inexpliquée d’un volume Windows connecté en iSCSI
Vue d’ensemble du problème
Le scénario typique observé sur un Dell PowerEdge R730/R760 (Windows Server 2019/2022) est le suivant : un lecteur iSCSI (par exemple R:) cesse subitement d’être visible dans l’Explorateur de fichiers, Disk Management et même dans diskpart. Côté baie, l’array Nexsan Unity signale pourtant que la LUN est en ligne, mappée et accessible. L’hôte enregistre simultanément une cascade d’événements iSCSI/StorPort/Disque dans l’Observateur d’événements.
Dans la quasi‑totalité des cas, la cause racine n’est pas un « effacement » du volume NTFS, mais une rupture transitoire ou prolongée de communication entre l’initiateur Windows et la cible iSCSI (pertes réseau, offloads problématiques, firmware instable, cache contrôleur figé). Windows finit par considérer la LUN comme surprise‑removed et la met hors ligne pour protéger l’intégrité des données.
Symptômes dans l’Observateur d’événements
Les événements ci‑dessous forment une signature récurrente :
| ID d’événement | Source | Signification pratique |
|---|---|---|
| 129 | iScsiPrt / StorPort | SCSI timeout : le pilote déclare qu’une requête n’a pas répondu dans le délai attendu. |
| 9, 49, 39 | iScsiPrt | Pertes de paquets/chemins, réinitialisations de cible, rétentatives de connexion. |
| 157 | Disk | « Disk X has been surprise removed » : le disque est considéré comme déconnecté. |
| 51 | Disk | Erreur d’E/S pendant une opération de pagination (indication d’instabilité d’E/S). |
Cette suite d’événements indique une instabilité de transport Bloc (TCP/iSCSI) qui n’est pas nécessairement permanente : il suffit d’une série de timeouts rapprochés pour que Windows bascule le disque hors ligne, voire le dé-monte (perte de lettre/mount‑point).
Arbre de diagnostic rapide
- Confirmer l’état côté hôte : le lecteur R: a‑t‑il disparu (
Get-Volume -DriveLetter R) ? La LUN apparaît‑elle comme Offline (Get-Disk) ? Y a‑t‑il des sessions iSCSI actives (Get-IscsiSession) ? - Valider l’état côté baie : la LUN est‑elle Online, mappée au bon IQN, sans alerte de contrôleur/cache/batterie ?
- Inspecter l’Event Log : présence d’IDs 129/157 autour du créneau de disparition ? Les 9/49/39 iScsiPrt confirment souvent des resets ciblés.
- Écarter la couche OS : MPIO actif et stable ? SAN policy adéquate ? Le volume n’est pas passé en ReadOnly ?
- Isoler le réseau iSCSI : congestion, Jumbo Frames incohérentes, offloads perturbateurs (LSO/RSC/GRO), flow‑control mal configuré, VLAN partagé ?
- Tester un rétablissement contrôlé : si la session iSCSI ne revient pas, appliquer la procédure de bascule manuelle ou, en dernier recours, un power‑cycle de la baie/hôtes.
Procédure de rétablissement sans redémarrage
À tenter en heures ouvrées si l’impact métier le permet et que la baie signale la LUN Online :
- Rescan/Online côté OS
# PowerShell (élevé) Update-HostStorageCache Get-Disk | Where-Object IsOffline -eq $true | Set-Disk -IsOffline $false -ErrorAction SilentlyContinue Get-Volume -FileSystemLabel "NomDuVolume" | Set-Volume -NewFileSystemLabel "NomDuVolume" # no-op, force refresh diskpart /s %TEMP%\rescan.txt :: contenu rescan.txt rescan list disk list volume - Vérifier la session iSCSI
Get-IscsiSession Get-IscsiConnection # Si aucune session : iscsicpl # onglet Cibles : Reconnecter la cible / marquer "Se reconnecter au démarrage" - Réactiver MPIO si nécessaire
# S'assurer que MPIO revendique les périphériques iSCSI Get-MPIOSetting Get-MSDSMSupportedHW # Si non activé : Enable-WindowsOptionalFeature -Online -FeatureName MultiPathIO mpclaim.exe -r -i -d "MSFT2005iSCSIBusType_0x9" - Rendre le volume à nouveau monté
# Si la partition existe mais pas de lettre Get-Partition -DiskNumber <n> | Get-Volume Set-Partition -DriveLetter R -NewDriveLetter R -ErrorAction SilentlyContinue # Sinon, remonter par GUID (mount point) mountvol R: /L - Tester E/S : copier un fichier de 1–2 Go, lancer
chkdsk R: /scan. En cas d’erreur, conserver des preuves et envisager un redémarrage planifié.
Note : si le cache contrôleur de la Unity est figé, ces étapes peuvent échouer jusqu’à la purge complète via redémarrage contrôlé de la baie.
Procédure de redémarrage contrôlé (retour d’expérience)
Dans le cas rapporté, un power‑cycle complet a fait réapparaître immédiatement le volume R:. Voici la séquence conseillée pour minimiser le risque :
- Arrêt ordonné des serveurs consommateurs du LUN (arrêt des services/applications, flush des fichiers ouverts).
- Arrêt des hôtes Windows.
- Arrêt de la baie Nexsan Unity (contrôleurs, shelf U2G460 si présent) en suivant l’ordre constructeur.
- Attente 2–5 minutes pour dissiper le cache et réinitialiser les chemins.
- Redémarrage de la baie (contrôleurs A/B, puis shelves), attendre le retour complet des services.
- Redémarrage des serveurs, vérification des sessions iSCSI/MPIO, rescan des disques, contrôle NTFS.
La réussite de cette séquence confirme souvent un état anormal du cache/contrôleur plutôt qu’une corruption applicative. Conservez les journaux collectés avant/après pour l’analyse constructeur.
Vérifications Windows essentielles
Initiateur iSCSI et timeouts
- Dans
iscsicpl> Configuration > Avancé : vérifiez LoginTimeout et MaxRetry. En environnement sensible à la latence, des valeurs trop faibles favorisent les 129/157. - Évitez de cocher des options digest inutiles. Gardez l’authentification (CHAP/Mutual CHAP) cohérente avec la baie.
<h3>MPIO</h3>
<ul>
<li>Assurez‑vous que <strong>MPIO</strong> revendique les périphériques iSCSI (<code>mpclaim -s -d</code>). Politique d’équilibrage : <em>Round Robin</em> ou <em>Least Queue Depth</em> selon recommandations et nombre de chemins.</li>
<li>Planifiez et testez régulièrement le basculement (désactiver un lien, observer la continuité d’E/S et l’absence de 129 persistants).</li>
</ul>
<h3>Politique SAN et mise en ligne automatique</h3>
<pre><code>diskpartsan # Valeur recommandée selon votre contexte (serveur unique vs cluster). # En serveur autonome, « OnlineAll » évite qu’une LUN revenue reste Offline. # En cluster, conserver « OfflineShared » pour prévenir les corruptions en accès concurrent.
<h3>Pilotes/firmwares</h3>
<ul>
<li>Testez <strong>mise à jour</strong> ou <strong>retour arrière</strong> des pilotes NIC (Intel/Broadcom), du microcode BIOS/iDRAC et des pilotes StorPort lorsque des instabilités sont connues.</li>
<li>Maintenez la cohérence firmware entre contrôleurs A/B de la Unity 3300 et le shelf U2G460.</li>
</ul>Bonnes pratiques réseau iSCSI
Le réseau iSCSI doit être dédié, prévisible et libre de congestions. Les écarts de configuration entre l’hôte, les switchs et la baie sont la source la plus fréquente de timeouts.
| Élément | Recommandations | Commandes utiles (Windows) |
|---|---|---|
| Isolation | Cartes dédiées, VLAN dédié, pas de routage inutile, QoS ou DCB si nécessaire. | Get-NetAdapter -Name "iSCSI*" |
| Jumbo Frames | Activer bout‑en‑bout (hôte ↔ switch ↔ baie) avec la même MTU (p. ex. 9000/9014). | netsh int ipv4 show subinterfacesnetsh int ipv4 set subinterface "iSCSI1" mtu=9014 store=persistent |
| Offloads NIC | Désactiver temporairement LSO/TSO, RSC/RSS/GRO si drivers instables ; réactiver une fois validé. | Disable-NetAdapterLso -Name "iSCSI*"Disable-NetAdapterRsc -Name "iSCSI*"Enable-NetAdapterRss -Name "iSCSI*" # si supporté |
| Flow‑control | Éviter le pause global de bout‑en‑bout ; privilégier la suppression côté hôte si la baie ne l’exige pas. | Réglages via propriétés de la carte ou Set-NetAdapterAdvancedProperty |
| Chemins multiples | Au moins deux NIC iSCSI, idéalement vers deux commutateurs distincts (fabric A/B). | Get-IscsiSession / Get-IscsiConnection |
| DNS & IP | Privilégier des connexions par IP directes pour iSCSI, éviter la dépendance DNS sur ce plan. | — |
Maintenance Nexsan Unity
- Mettre à jour le firmware des contrôleurs Unity 3300 et du shelf U2G460, ainsi que les pilotes d’interface (10/25 GbE).
- Examiner les journaux SPA/SPB : recherches d’erreurs CRC, resets, reconstructions, alertes batterie/cache.
- Vérifier les politiques d’écriture (write‑back / write‑through) et l’état de la batterie de cache.
- Confirmer la symétrie de présentation (LUN mappée aux deux contrôleurs, mêmes ACL/masques).
- Ouvrir un ticket de support en fournissant : horodatage précis, liste d’IDs d’événements, captures
Get-IscsiSession, état MPIO, et export des logs de la Unity.
Prévention : supervision et tests réguliers
Surveiller proactivement les IDs 129/157
# Exemple de collecte PowerShell (administrateur)
$start = (Get-Date).AddDays(-7)
$filter = @{ LogName='System'; Id=@(9,39,49,51,129,157); StartTime=$start }
Get-WinEvent -FilterHashtable $filter | Select-Object TimeCreated, Id, ProviderName, Message | Format-Table -Auto
Intégrez ces événements dans un pipeline d’alerting (Event Forwarding, SCOM, agent de logs) avec seuils et corrélations (p. ex. ≥ 3 × 129 en 60 s).
<h3>Tests de basculement MPIO</h3>
<ol>
<li>Tracer la charge par chemin (compteur PerfMon « <i>iSCSI Initiator</i> » et « <i>PhysicalDisk</i> »).</li>
<li>Désactiver un port/chemin iSCSI de l’hôte pour simuler la perte et confirmer l’absence de 129/157.</li>
<li>Réactiver et vérifier la redistribution automatique de charge.</li>
</ol>
<h3>Backups et intégrité</h3>
<ul>
<li>Maintenir des sauvegardes cohérentes applicativement (VSS). </li>
<li>Programmer un <strong>chkdsk /scan</strong> planifié hebdomadaire sur R: afin de détecter tôt toute anomalie.</li>
</ul>Tableau récapitulatif : actions et résultats
| Action | Détails & résultats |
|---|---|
| Redémarrage complet | Arrêt ordonné des serveurs puis de la baie ; redémarrage inverse pour purger le cache. Résultat : dans le cas rapporté, le volume R: est réapparu normalement. |
| Vérification Windows | Mises à jour ou retours arrière de pilotes NIC/StorPort/BIOS/firmware. Contrôle des timeouts iSCSI (iscsicpl) et activation MPIO si multi‑chemins. Rescan via Disk Management ou diskpart rescan après rétablissement. |
| Bonnes pratiques réseau | NIC dédiées, VLAN isolé, pas de congestion. Jumbo Frames bout‑en‑bout. Désactivation ciblée de flow‑control et de certains offloads (LRO/GRO/RSC/LSO) si bugs pilotes. |
| Maintenance Nexsan | Firmware Unity 3300 et shelf U2G460 à jour. Analyse des logs SPA/SPB et de l’état batterie/cache. Ticket Nexsan si CRC, reconstructions ou alertes. |
| Prévention | Surveillance continue des IDs 129/157, tests de basculement MPIO, sauvegardes régulières, redémarrage contrôlé de la baie documenté pour purger le cache en cas d’incident. |
Commandes PowerShell et outils d’analyse
Inventaire iSCSI et MPIO
# Sessions iSCSI actives
Get-IscsiSession | Format-Table -Auto
# Détail des connexions par session (chemins)
Get-IscsiConnection | Sort-Object -Property SessionIdentifier | Format-Table -Auto
# Statut MPIO
mpclaim -s -d
Get-MPIOSetting
# Périphériques revendiqués par MSDSM
Get-MSDSMSupportedHW État des disques/volumes
Get-Disk | Format-Table Number,FriendlyName,OperationalStatus,IsOffline,IsReadOnly -Auto
Get-Partition | Get-Volume | Format-Table DriveLetter,FileSystemLabel,FileSystem,HealthStatus,SizeRemaining -Auto Paramétrage NIC ciblé iSCSI
# Inspection des propriétés avancées
Get-NetAdapterAdvancedProperty -Name "iSCSI*"
# Désactiver LSO & RSC temporairement pour tester
Disable-NetAdapterLso -Name "iSCSI*"
Disable-NetAdapterRsc -Name "iSCSI*"
# Vérifier/forcer la MTU
netsh int ipv4 show subinterfaces
netsh int ipv4 set subinterface "iSCSI1" mtu=9014 store=persistent Collecte d’événements ciblés
$ids = 9,39,49,51,129,157
$since = (Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=$ids; StartTime=$since} |
Select-Object TimeCreated, Id, ProviderName, Message |
Sort-Object TimeCreated |
Out-GridView Pièges courants et décisions pragmatiques
- MTU incohérente : MTU 9000 sur l’hôte mais 1500 sur un switch intermédiaire ⇒ fragmentations/pertes invisibles. Vérifier chaque tronçon.
- Flow‑control mal aligné : pause frames généralisés peuvent masquer une congestion chronique et déclencher des timeouts.
- Offloads défaillants : certains drivers LSO/RSC provoquent des paquets géants/agrégés non conformes sous charge.
- MPIO absent : une panne d’un seul uplink iSCSI suffit alors à éjecter la LUN.
- Politique SAN inadaptée : une LUN revenue reste Offline si « OfflineShared » dans un contexte non‑cluster.
- Cache contrôleur figé : la baie répond « présente » mais ne traite plus les I/O ; seul un power‑cycle libère la situation.
Checklist de stabilisation post‑incident
| Contrôle | Attendu | État |
|---|---|---|
| Drivers NIC (Intel/Broadcom) | Version recommandée pour iSCSI, WHQL, pas de bug connu | ✓/✗ |
| Firmware BIOS/iDRAC | À jour et cohérent entre nœuds | ✓/✗ |
| MPIO | Activé, au moins deux chemins actifs, politique équilibrage valide | ✓/✗ |
| Jumbo Frames | MTU identique sur hôtes, switchs, baie | ✓/✗ |
| Flow‑control | Politique claire (désactivé côté hôte si non requis) | ✓/✗ |
| Logs Unity | Aucune alerte batterie/cache, pas de CRC | ✓/✗ |
| Surveillance EventIDs | Alertes 129/157 avec seuils et corrélation | ✓/✗ |
Runbook prêt à l’emploi
- Détection : alerte 129/157 ou volume R: introuvable.
- Gel applicatif : stopper les services utilisant R:, prévenir les utilisateurs.
- Diagnostic immédiat :
Get-IscsiSession,Get-Disk, lecture des derniers événements. - Rétablissement doux : rescan, remise Online du disque, reconnexion iSCSI, vérification MPIO.
- Validation : test E/S,
chkdsk /scan, reprise applicative. - Escalade : si échec, bascule vers redémarrage contrôlé de la baie ; collecte logs avant/après.
- Post‑mortem : mise à jour des pilotes/firmwares, alignement MTU/offloads, paramétrage MPIO, supervision 129/157.
Conclusion
La disparition d’un volume iSCSI sur Windows est l’expression d’un délai d’attente transport ayant entraîné la mise hors ligne de la LUN. Dans l’incident étudié, un power‑cycle complet a rétabli la situation, attestant d’un état anormal de cache/contrôleur côté Nexsan Unity. Pour fiabiliser durablement :
- Stabiliser le réseau iSCSI : pilotes et microcodes adéquats, isolation réseau, MTU alignée, offloads maîtrisés.
- Mettre à jour baies et serveurs (ou revenir à une version connue stable en cas de régression).
- Surveiller activement les événements 129/157 pour détecter précocement toute dérive.
- Documenter une procédure de redémarrage contrôlé de la baie pour purger son cache si le phénomène réapparaît.
Appliquées ensemble, ces mesures réduisent fortement le risque de perte de connectivité et sécurisent la disponibilité du volume iSCSI sur Dell PowerEdge et Nexsan Unity.
FAQ
Pourquoi la LUN est‑elle « présente » côté baie mais absente côté Windows ?
Parce que la baie peut annoncer la LUN comme en ligne tout en restant incapable de traiter les E/S (cache bloqué, contrôleur perturbé). Windows, après des timeouts répétés, bascule le disque hors ligne pour protéger les données.
Un chkdsk est‑il risqué après un incident de ce type ?
chkdsk /scan est non intrusif et recommandé. Évitez /f en heures ouvrées ; si des erreurs sont détectées, planifiez une fenêtre dédiée.
Faut‑il activer Jumbo Frames ?
Oui si l’infrastructure est homogène (hôtes, switchs, baie). Une MTU incohérente cause plus de problèmes qu’elle n’en résout.
Quelle politique MPIO choisir ?
Round Robin convient dans la majorité des cas. Least Queue Depth peut améliorer la répartition sous forte charge. Évitez les politiques collant à un seul chemin.
La politique SAN « OnlineAll » est‑elle sûre ?
Sur un serveur autonome, oui. En environnement cluster, conservez « OfflineShared » pour éviter les montages multiples non coordonnés.
Annexes : scripts rapides
Script de collecte express
# Collecte Express iSCSI/MPIO/Disques (PowerShell admin)
$log = "$env:TEMP\iscsi_collect_$(Get-Date -Format yyyyMMdd_HHmmss).txt"
"=== Sessions iSCSI ===" | Out-File $log
Get-IscsiSession | Format-List * | Out-File $log -Append
"`n=== Connexions iSCSI ===" | Out-File $log -Append
Get-IscsiConnection | Format-List * | Out-File $log -Append
"`n=== MPIO ===" | Out-File $log -Append
mpclaim -s -d | Out-File $log -Append
Get-MPIOSetting | Out-File $log -Append
"`n=== Disks/Partitions/Volumes ===" | Out-File $log -Append
Get-Disk | Format-List * | Out-File $log -Append
Get-Partition | Format-List * | Out-File $log -Append
Get-Volume | Format-List * | Out-File $log -Append
"`n=== Events (3j) ===" | Out-File $log -Append
$ids = 9,39,49,51,129,157
Get-WinEvent -FilterHashtable @{LogName='System'; Id=$ids; StartTime=(Get-Date).AddDays(-3)} |
Select-Object TimeCreated, Id, ProviderName, Message | Out-File $log -Append
Write-Host "Journal enregistré dans $log" Mémo décisionnel
Si les IDs 129/157 s’empilent et que Get‑IscsiSession ne montre aucun chemin : corrélez immédiatement avec la télémétrie réseau et la baie. Si un seul redémarrage de service ne suffit pas et que l’application est arrêtée : envisagez le redémarrage contrôlé de la Unity pour purger le cache. Ensuite : validez MTU/offloads, MPIO et mettez à jour ou revenez à un couple driver/firmware connu stable.