Open-iscsiとマルチパスを使用してOpen-E DSS v7ストレージクラスターとアクティブ/パッシブフェイルオーバー)から提示されたLUNに接続するSLES11SP4を実行しているLinuxサーバーがあります。
Linuxサーバーdb03
には、iSCSIネットワーク内のIP bond0
とのインターフェース10.0.100.66/22
があります。 Open-Eクラスターの両側には、iSCSIネットワークに2つのIPがあります。最初のノードに10.0.100.71
と10.0.100.72
、2番目のノードに10.0.100.73
と10.0.100.74
です。
したがって、フェイルオーバーが発生していない場合、検出は次のようになります。
db03:~ # iscsiadm -m discovery -t sendtargets -p 10.0.100.71:3260
10.0.100.71:3260,1 opene.lun602
10.0.100.72:3260,1 opene.lun602
両方のターゲットが接続されている場合、これはマルチパスステータスです。
db03:~ # multipath -ll
opene.lun602 (2697a42a45d5dcbdb) dm-0 SCST_BIO,izcegeu6eeb2jaeJ
size=500G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 7:0:0:0 sda 8:0 active ready running
`- 8:0:0:0 sdb 8:16 active ready running
フェイルオーバーの場合、これらの接続は両方ともfailed faulty
に入り、カーネルがファイルシステムを読み取り専用で再マウントすることを決定するまで、パスは0で、すべてのI/Oエラーが残ります。
その時点で、手動で別の検出を試し、他の2つのターゲットを接続できます...しかし、Linux側ではフェイルオーバーは自動的に発生しません。
だから私は疑問に思う:
Linuxがこれらのような変更を定期的に再発見できる方法はありますか?何も見つかりませんでした。
Open-E DSSソフトウェアに他のパスをアナウンスするが、それらがバックアップであることを通知するように指示する方法はありますか?(ある時点で、クラスターに4つのパスすべてを表示させることができました。しかし、それらはactive ready
として誤って表示されていました。これは、I/Oをアクティブ部分に向けるだけのアクティブ/パッシブクラスターと一緒に使用することは明らかに良い考えではありません。)
VMWareはこれをどのように処理していますか?同じ方法で構成された別のLUNに接続されたVMWareクラスターでは、このような問題は発生しません。
参考までに、これは私のmultipath.confです。
cat /etc/multipath.conf
multipaths {
multipath {
wwid 2697a42a45d5dcbdb
alias opene.lun602
}
}
devices {
device {
vendor "SCST_FIO|SCST_BIO"
product "*"
path_selector "round-robin 0"
path_grouping_policy multibus
rr_min_io 100
}
}
Open-iscsiとマルチパスを使用してOpen-E DSS v7ストレージクラスターとアクティブ/パッシブフェイルオーバー)から提示されたLUNに接続するSLES11SP4を実行しているLinuxサーバーがあります。
残念ながら、Ping Open-Eは、サポートが不足していることに非常に近いです。これらの人は、いくつかの深刻なmodでSCSTターゲットからのフォークアウトを使用するため、「一般的な」SCSTの知識に基づいて推奨されるすべてのものが機能する場合と機能しない場合がありますが、以前にOpen-Eを使用したことがある人は非常に理由があります。すみません!
ESXiのマルチパスは別の話です。更新を確実に機能させるには、おそらくノードの再起動で終了します。ここで完璧なまとめ:
http://www.codyhosterman.com/2015/03/esxi-iscsi-multipathing/
幸運を!