iSCSIで接続されているストレージは10Gイーサで接続されているので、
正直パケットがちゃんと取れるのか不安なところでしたが、、、1Gイーサにミラーリングして無理やり取ってみました。
http://www.ietf.org/rfc/rfc3720.txt のサイトでiSCSIコマンドのコードを確認すると以下のようになっています。
Some of the status codes defined in [SAM2] are:
0x00 GOOD
0x02 CHECK CONDITION
0x08 BUSY
0x18 RESERVATION CONFLICT
0x28 TASK SET FULL
0x30 ACA ACTIVE
0x40 TASK ABORTED
取ったパケットの量は当然膨大なので、フィルタ機能でソートをかけないと見れたものではありません。。
上記のコードでフィルタをかけてみます。
ストレージが見えなくなるということは、SCSI Reservationが発生しているのだろうということで、コード 0x18 でフィルタをかけてみます。
フィルタの箇所で、iscsi.scsiresponse.status == 0x18 と入力すれば、 SCSI Reservation conflict が発生している箇所だけ抜き出せます。
2200 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Write(10)) (Reservation Conflict)
2201 10.1.4.200 10.1.4.1 iSCSI SCSI: Reserve(6) LUN: 0x03
2202 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Reserve(6)) (Reservation Conflict)
2203 10.1.4.200 10.1.4.1 iSCSI SCSI: Reserve(6) LUN: 0x03
というように、LUN の番号が確認できるので、どのディスクで Conflict が発生しているか確認できます。
iscsi.opcode == 0x21 でフィルタをかけると以下のようにSCSI Reserve して書き込みして、 Release する一連の動きが確認できます。
フィルタをすると、 Reserve なしで Write のみのパケットも多数あります。
Conflictが多発している状態では、このReseve Good 状態をみんな目指して競合状態になっているようですね。。
そもそもなんでなんだ？？という話ですが。
ネットでいろいろ調べると、スペックだったり、ストレージのFirmwareをアップデートしてなおったりと色々なようです。
下の例は、Wiresharkから抜き取ったもの。
一番左から、パケット番号、取得開始,経過時間、ソースアドレス、デスティネーションアドレス、パケット種別、パケットの詳細の内容です。
1142 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Reserve(6)) (Good)
1146 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Write(10)) (Good)
1148 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Release(6)) (Good)
11114 10.1.4.200 10.1.4.1 iSCSI SCSI: Response LUN: 0x03 (Write(10)) (Good)
Reservationをかけにいって、Reserve Good ,
書き込みをして Write Good ,
その後解放 Release Good でGoodづくめです。
