1つのLUNを2つのWindowsServer2016マシンにエクスポートするFedora22マシンにLIOiSCSIターゲットを構成しましたが、どちらも問題なくディスクにアクセスできます。
これらのサーバーはHAクラスターの一部であり、ディスクをクラスターに追加しようとすると、「デバイスの準備ができていません」というエラーが表示されます。検証ツールによると、SCSI-3 Persistent Reservationsが原因でストレージがパスしないとのことですが、私の調査によると、これは私が受け取っているエラーとは異なるエラーになるはずです。
Creating the physical disk resource for 'Cluster Disk 1'.
Bringing the resource for 'Cluster Disk 1' online.
There was an error creating, configuring, or bringing online the Physical Disk resource (disk) 'Cluster Disk 1'.
The following errors occurred while adding storage to the cluster:
The resource 'Cluster Disk 1' did not come online.
The desired state change for 'Cluster Disk 1' did not occur before the timeout expired.
これは私のiSCSIターゲットです:
o- / ........................................................................................................... [...]
o- backstores ................................................................................................ [...]
| o- block .................................................................................... [Storage Objects: 1]
| | o- ha1 ................................................ [/dev/delta/volpool/ha1 (200.0GiB) write-thru activated]
| o- fileio ................................................................................... [Storage Objects: 0]
| o- pscsi .................................................................................... [Storage Objects: 0]
| o- ramdisk .................................................................................. [Storage Objects: 0]
| o- user ..................................................................................... [Storage Objects: 0]
o- iscsi .............................................................................................. [Targets: 1]
| o- iqn.2017-12.net.hirstgroup.adx.delta:storage.target00 ............................................... [TPGs: 1]
| o- tpg1 ................................................................................. [no-gen-acls, no-auth]
| o- acls ............................................................................................ [ACLs: 4]
| | o- iqn.1991-05.com.Microsoft:dc1.adx.hirstgroup.net ....................................... [Mapped LUNs: 1]
| | | o- mapped_lun0 ..................................................................... [lun0 block/ha1 (rw)]
| | o- iqn.1991-05.com.Microsoft:dc2.adx.hirstgroup.net ....................................... [Mapped LUNs: 1]
| | | o- mapped_lun0 ..................................................................... [lun0 block/ha1 (rw)]
| | o- iqn.2017-12.net.hirstgroup.adx.dc1:dc1 ................................................. [Mapped LUNs: 1]
| | | o- mapped_lun0 ..................................................................... [lun0 block/ha1 (rw)]
| | o- iqn.2017-12.net.hirstgroup.adx.delta:iqn.1991-05.com.Microsoft:dc2.adx.hirstgroup.net .. [Mapped LUNs: 1]
| | o- mapped_lun0 ..................................................................... [lun0 block/ha1 (rw)]
| o- luns ............................................................................................ [LUNs: 1]
| | o- lun0 ............................................................... [block/ha1 (/dev/delta/volpool/ha1)]
| o- portals ...................................................................................... [Portals: 1]
| o- 0.0.0.0:3260 ....................................................................................... [OK]
o- loopback ........................................................................................... [Targets: 0]
o- vhost .............................................................................................. [Targets: 0]
だから、私はここで何が間違っているのかわかりません、ディスクがクラスターに追加されないことを除いてすべてが機能しているようです。私の調査で私が見た1つのことは、これが機能するにはSCSI-3 Persistent Reservationsが必要であるということですが、私の理解では、LIOはこれをサポートしています。私のブロックデバイスは、このマシンでZFSを実行しているため、実際にはシンプロビジョニングされたzvolです。
うまくいけば、誰かがここで何が悪いのかを明らかにするのを助けることができます。
LUNの所有権が変更された後、LIOが更新を「忘れる」可能性があるため、SCSI-3永続予約をクリアしてみることをお勧めします。
私はこの問題を解決しました。 Fedora 22に含まれているバージョンのLIOは、SCSI-3永続予約を正しくサポートしていないようです。私はscsi-target-utilsを使用するように切り替えましたが、この構成ですぐに問題なく動作しました:
backing-store/blah/blah/blah/zvol initiator-address 172.16.20.0/24 incominguser hgx blahblahblah