Короткий ответ
Цепочка: portal 10.0.30.10:3260 → discovery → ACL разрешает initiator iqn.1991-05.com.microsoft:sql01 → login (CHAP если включён) → сессия → диск в Get-Disk. Чините по слоям. Не Initialize-Disk на LUN с чужой подписью GPT/SQL. Не Force import ZFS из-за iSCSI.
TrueNAS: iSCSI target + extent (zvol tank/sql01) + initiator group. Windows: служба MSiSCSI.
Симптомы и как отличить
Типичная картина:
- SQL01: диски Offline, Error Log I/O;
- iSCSI Initiator: Discovery пустой;
- Login failed, portal ping жив;
- Ubuntu open-iscsi
iscsiadmlogin failed.
| Слой | Признак |
|---|---|
| Нет TCP 3260 | сеть/firewall/service |
| Discovery есть, login fail | ACL IQN, CHAP, target name |
| Login ок, диска нет | rescan, фильтр, MPIO |
| Диск Read-only / I/O error | thin, пул, ёмкость |
| SMB жив, iSCSI нет | сервис iscsi, не «NAS мёртв» |
Возможные причины
- iSCSI service на NAS01 выключен, слушает другой NIC.
- Initiator IQN не в ACL / другой после переустановки Windows.
- CHAP secret рассинхрон.
- Portal IP сменился, старый persistent target.
- Firewall 3260, VLAN storage.
- Пул
tank/ zvol недоступен. - Исчерпаны сессии, дубль login с двух хостов без cluster.
- MTU jumbo обрывает крупные PDU.
Диагностика
1. Portal с SQL01
Get-Service MSiSCSI
Start-Service MSiSCSI
Test-NetConnection 10.0.30.10 -Port 3260
Get-IscsiTargetPortal
Get-IscsiTarget
Get-IscsiSession
Get-InitiatorPort | Format-List NodeAddressNodeAddress должен быть iqn.1991-05.com.microsoft:sql01 (или ваш документированный). Если Windows сгенерировал новый IQN после rebuild ОС — ACL на NAS его не знает.
2. Discovery / connect
New-IscsiTargetPortal -TargetPortalAddress 10.0.30.10
Get-IscsiTarget | Format-List NodeAddress, IsConnectedЗапомните NodeAddress target (на TrueNAS часто iqn.2005-10.org.freenas.ctl:...). Не путайте с initiator IQN.
3. На NAS01
Services → iSCSI running. Initiator group содержит точный IQN SQL01. Associated targets: portal 10.0.30.10, порт 3260. Extent: zvol tank/sql01 существует, не locked.
zfs list tank/sql014. Ubuntu initiator (если не Windows)
cat /etc/iscsi/initiatorname.iscsi
iscsiadm -m discovery -t st -p 10.0.30.10:3260
iscsiadm -m node -P 15. Диск после сессии
Update-HostStorageCache
Get-Disk | Format-Table Number, SerialNumber, OperationalStatus, Size, IsOfflineMPIO: две сессии — один диск, не два. Get-MSDSMSupportedHw / iSCSI DSM.
Решение
Сценарий A. 3260 закрыт
Сеть, firewall NAS, iSCSI listen IP = storage NIC. См. NAS по сети.
Сценарий B. ACL / IQN
Либо верните NodeAddress Windows к документированному (если политика позволяет), либо добавьте новый IQN в initiator group TrueNAS. Удалите stale IQN старого SQL01.
Сценарий C. CHAP
Сверьте secret на target и initiator (Connect-IscsiTarget Authentication). Пустой vs заполненный — fail. Не логируйте secret в тикет открытым текстом.
Сценарий D. Login ок, диск Offline
Set-Disk -Number 2 -IsOffline $falseТолько если это тот LUN. Для кластера — Cluster Disk, не Set-Disk вслепую.
Persistent:
Connect-IscsiTarget -NodeAddress 'iqn.2005-10.org.freenas.ctl:sql-lun0' -IsPersistent $trueПодставьте фактический target из Get-IscsiTarget.
Сценарий E. Два сервера, один LUN без кластера
Второй login — порча ФС. Отключите сессию с чужого хоста. Это не «MPIO».
Имя инициатора Windows задаётся в iSCSI Initiator, вкладка Configuration. После клонирования SQL01 из шаблона два сервера получают один IQN: ACL пропускает первого, второй логинится «странно» или портит NTFS. Смените IQN на клоне до первого Connect и обновите initiator group на NAS01.
Portal с двух адресов (mgmt плюс storage) без MPIO даёт флап сессии и I/O error в SQL. Оставьте discovery и login только на 10.0.30.10. Delayed ACK и offload на NIC иногда ломают iSCSI после обновления драйвера — проверяйте это, а не пересоздавайте target.
Persistent login должен переживать ребут. Проверка: reboot SQL01 в окне, Get-IscsiSession Connected до старта службы SQL. Если диск Online только после ручного Connect, прод упадёт после патча Windows.
Как проверить, что проблема устранена
Get-IscsiSession Connected. Get-Disk Online, тот же UniqueId. SQL открывает БД, checkpoint проходит. После ребута SQL01 сессия persistent. На NAS01 нет ошибок extent.
Если не помогло
- Login циклический: MTU, switch storm control, CRC.
- Высокая latency: storage VLAN перегружен, не «надо Jumbo обязательно».
- Thin zvol 100%: сначала место на
tank. - Windows Target Server (не TrueNAS):
Get-IscsiServerTarget, ACL IQN тот же принцип. - CHAP ok, IPsec policy режет — редкий GPO.
Профилактика
- Документ: initiator IQN SQL01, target IQN, portal, LUN serial.
- Dedicated storage VLAN, мониторинг 3260 и сессий.
- MPIO + два порта, если нужна отказоустойчивость.
- Persistent login.
- Не давать один zvol двум standalone Windows.
- Алерт на disconnect.
Для SQL на iSCSI обязательны: отдельный VLAN, Jumbo только если обе стороны и коммутатор настроены одинаково, очередь достаточной глубины, и не backup-окно full dump на тот же LUN без наблюдения latency. MPIO Round Robin уместен на двух независимых путях; на одном портале две сессии — не MPIO, а двойной login.
После любого изменения ACL IQN на TrueNAS не оставляйте «старый и новый на всякий»: лишний initiator — это лишний хост, который однажды сделает Connect к тому же NTFS. Чистите группу инициаторов как firewall, не как блокнот.
FAQ
Сменить IQN на красивый?
Можно до прод-ACL. После — обновите все initiator groups. Не меняйте каждую переустановку молча.
Нужен ли CHAP в изолированном VLAN?
Политика. Сеть не замена аутентификации, если VLAN не железный.
Initialize Disk предлагает Windows после аварии?
Нет, пока не сравнили подпись. Скорее Online + rescan.
Порт не 3260?
Только если явно меняли. Клиенты по умолчанию 3260. Не выдумывайте.
open-iscsi и Windows к одному target?
Да, если ACL содержит оба IQN и это clustered FS или разные LUN. Один NTFS на двоих — нет.