2020年5月18日月曜日

iSCSI + DM-multipathで冗長構成を組んだ際の、障害時のパス切り替わり動作を確認してみた

先日、DM-multipathを使ってマルチパス構成のiSCSIストレージを認識させる手順を記載した。
マルチパス構成となっているため、片方のパスがダウンしたとしても、問題なくI/Oができる。実際にパスが切り替わる際の動作確認をしてみた。

環境

  • OS：Red Hat Enterprise Linux 7.6
  • iSCSIターゲット：QNAP NAS
  • iSCSIディスク：5GB、2GB、1GBの3つ


監視設定を確認する

iSCSI設定

RHELのiSCSIイニシエータは、pingによるターゲットの状態監視を行う。以下2つのパラメータで時間が設定されている。デフォルトでは5秒間隔でpingを行い、5秒間応答がないとエラーとして検知する。
パラメータ 内容 デフォルト値
timeo.noop_out_interval ping監視間隔 5秒
timeo.noop_out_timeout ping監視タイムアウト 5秒
実際の設定は、/etc/iscsi/iscsid.confに記載されている。
# cat /etc/iscsi/iscsid.conf | grep "noop_out"
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

DM-multipath設定

DM-multipathでは、以下2つのパラメータでストレージデバイスの監視を行う。最初は5秒間隔でポーリングを行い、徐々に間隔を増加させ、最終的には4倍の20秒間隔でポーリングするよう動作するらしい。パスのチェック方式はストレージごとに設定が異なるので注意。
パラメータ 内容 デフォルト値
polling_interval 初期ポーリング間隔 5秒
max_polling_interval 最大ポーリング間隔 5秒 x 4倍 = 20秒
path_checker パスチェック方式 directio (直接I/Oを行い最初のセクタ読み取りを行う)
実際の設定は、multipath -tコマンドで確認できる。下記はポーリング間隔設定を確認したコマンド例となる。
# multipath -t | grep interval
        polling_interval 5
        max_polling_interval 20

サーバ側のNIC切断時

まずは、サーバ側のNIC切断時に、どのようにパスが切り替わるかを確認してみることにする。
通常状態は以下のように「ready」ステータスとなる。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active ready running
  `- 36:0:0:2 sde 8:64 active ready running
サーバ側のNICを切断する。undef→faultyとステータスが遷移する。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active undef running
  `- 36:0:0:2 sde 8:64 active ready running

# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 failed faulty running
  `- 36:0:0:2 sde 8:64 active ready running
tail -f /var/log/messagesを実行し、NW切断時の挙動を確認してみる。以下ような動作をしていることがわかる。iSCSIは約5秒でping監視エラーを検知し、DM-multipathはストレージデバイスによって検知時間が異なるようだが、いずれも最大11秒でパスダウンを検知しているようだ。
  • 15:01:50 OSがLink Down検知
  • 15:01:56 DM-multipathがmpathaのストレージデバイスのパスダウンを検知
  • 15:01:56 iSCSIのping監視エラーを検知
  • 15:02:01 DM-multipathがmpathbとmpathcのストレージデバイスのパスダウンを検知
Mar 21 15:01:50 localhost kernel: vmxnet3 0000:13:00.0 ens224: NIC Link is Down
Mar 21 15:01:56 localhost multipathd: mpatha: sdc - readsector0 checker reports path is down
Mar 21 15:01:56 localhost multipathd: checker failed path 8:32 in map mpatha
Mar 21 15:01:56 localhost multipathd: mpatha: remaining active paths: 1
Mar 21 15:01:56 localhost kernel: connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4379116259, last ping 4379121264, now 4379126272
Mar 21 15:01:56 localhost kernel: connection3:0: detected conn error (1022)
Mar 21 15:01:56 localhost kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4379116259, last ping 4379121264, now 4379126272
Mar 21 15:01:56 localhost kernel: connection1:0: detected conn error (1022)
Mar 21 15:01:56 localhost kernel: device-mapper: multipath: Failing path 8:32.
Mar 21 15:01:56 localhost iscsid: Kernel reported iSCSI connection 3:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 15:01:56 localhost iscsid: Kernel reported iSCSI connection 1:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 15:02:01 localhost multipathd: mpathb: sdf - readsector0 checker reports path is down
Mar 21 15:02:01 localhost multipathd: checker failed path 8:80 in map mpathb
Mar 21 15:02:01 localhost multipathd: mpathb: remaining active paths: 1
Mar 21 15:02:01 localhost kernel: session3: session recovery timed out after 5 secs
Mar 21 15:02:01 localhost kernel: sd 35:0:0:1: rejecting I/O to offline device
Mar 21 15:02:01 localhost kernel: sd 35:0:0:1: [sdf] killing request
Mar 21 15:02:01 localhost kernel: device-mapper: multipath: Failing path 8:80.
Mar 21 15:02:01 localhost kernel: device-mapper: multipath: Failing path 8:48.
Mar 21 15:02:01 localhost multipathd: checker failed path 8:48 in map mpathc
Mar 21 15:02:01 localhost multipathd: mpathc: remaining active paths: 1
NICを接続すると、即座にパスが復旧する。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active ready running
  `- 36:0:0:2 sde 8:64 active ready running
パス復旧時の挙動も再度ログから確認してみる。
  • 15:03:02 OSがLink Up検知
  • 15:03:06 DM-multipathがmpatha、mpathb、mpathcのストレージデバイスのパス復旧を検知
  • 15:03:06 iSCSIの接続復旧を検知
Mar 21 15:03:02 localhost kernel: vmxnet3 0000:13:00.0 ens224: NIC Link is Up 10000 Mbps
Mar 21 15:03:02 localhost NetworkManager[5551]: <info>  [1584770582.1065] device (ens224): carrier: link connected
Mar 21 15:03:03 localhost iscsid: connect to 192.168.33.13:3260 failed (No route to host)
Mar 21 15:03:03 localhost iscsid: connect to 192.168.33.13:3260 failed (No route to host)
Mar 21 15:03:06 localhost multipathd: mpatha: sdc - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:32: reinstated
Mar 21 15:03:06 localhost multipathd: mpatha: remaining active paths: 2
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:32.
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:80.
Mar 21 15:03:06 localhost multipathd: mpathb: sdf - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:80: reinstated
Mar 21 15:03:06 localhost multipathd: mpathb: remaining active paths: 2
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:48.
Mar 21 15:03:06 localhost multipathd: mpathc: sdd - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:48: reinstated
Mar 21 15:03:06 localhost multipathd: mpathc: remaining active paths: 2
Mar 21 15:03:06 localhost iscsid: connection3:0 is operational after recovery (8 attempts)
Mar 21 15:03:06 localhost iscsid: connection1:0 is operational after recovery (9 attempts)

ストレージ側のNIC切断

NW切断時の挙動を確認してみる。以下ような動作をしていることがわかる。
  • 14:57:36 iSCSIのping監視エラーを検知
  • 14:57:36 DM-multipathがmpathaのストレージデバイスのパスダウンを検知
  • 14:57:41 DM-multipathがmpathbとmpathcのストレージデバイスのパスダウンを検知
Mar 21 14:57:36 localhost kernel: connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4378856640, last ping 4378861648, now 4378866656
Mar 21 14:57:36 localhost kernel: connection3:0: detected conn error (1022)
Mar 21 14:57:36 localhost kernel: device-mapper: multipath: Failing path 8:32.
Mar 21 14:57:36 localhost multipathd: mpatha: sdc - readsector0 checker reports path is down
Mar 21 14:57:36 localhost multipathd: checker failed path 8:32 in map mpatha
Mar 21 14:57:36 localhost multipathd: mpatha: remaining active paths: 1
Mar 21 14:57:36 localhost iscsid: Kernel reported iSCSI connection 3:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 14:57:36 localhost kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4378856760, last ping 4378861776, now 4378866784
Mar 21 14:57:36 localhost kernel: connection1:0: detected conn error (1022)
Mar 21 14:57:37 localhost iscsid: Kernel reported iSCSI connection 1:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 14:57:41 localhost multipathd: mpathb: sdf - readsector0 checker reports path is down
Mar 21 14:57:41 localhost kernel: session3: session recovery timed out after 5 secs
Mar 21 14:57:41 localhost kernel: sd 35:0:0:1: rejecting I/O to offline device
Mar 21 14:57:41 localhost kernel: sd 35:0:0:1: [sdf] killing request
Mar 21 14:57:41 localhost kernel: device-mapper: multipath: Failing path 8:80.
Mar 21 14:57:41 localhost kernel: device-mapper: multipath: Failing path 8:48.
Mar 21 14:57:41 localhost multipathd: checker failed path 8:80 in map mpathb
Mar 21 14:57:41 localhost multipathd: mpathb: remaining active paths: 1
Mar 21 14:57:41 localhost multipathd: checker failed path 8:48 in map mpathc
Mar 21 14:57:41 localhost multipathd: mpathc: remaining active paths: 1
パス復旧時の挙動も再度ログから確認してみる。
  • 14:58:09 iSCSIの接続復旧を検知
  • 14:58:11 DM-multipathがmpatha、mpathb、mpathcのストレージデバイスのパス復旧を検知
Mar 21 14:58:09 localhost iscsid: connection3:0 is operational after recovery (3 attempts)
Mar 21 14:58:09 localhost iscsid: connection1:0 is operational after recovery (3 attempts)
Mar 21 14:58:11 localhost multipathd: mpatha: sdc - readsector0 checker reports path is up
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:32.
Mar 21 14:58:11 localhost multipathd: 8:32: reinstated
Mar 21 14:58:11 localhost multipathd: mpatha: remaining active paths: 2
Mar 21 14:58:11 localhost multipathd: mpathb: sdf - readsector0 checker reports path is up
Mar 21 14:58:11 localhost multipathd: 8:80: reinstated
Mar 21 14:58:11 localhost multipathd: mpathb: remaining active paths: 2
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:80.
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:48.
Mar 21 14:58:11 localhost multipathd: mpathc: sdd - readsector0 checker reports path is up
Mar 21 14:58:11 localhost multipathd: 8:48: reinstated
Mar 21 14:58:11 localhost multipathd: mpathc: remaining active paths: 2

参考

By 時刻:
ラベル:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)

人気の投稿

  • Windows標準コマンドでdiffする
    Linuxなら迷うこと無く diff コマンドがあるので問題ないが、Windowsの場合どうすれば良いか悩んでしまうことがある。フリーソフトがインストールできる環境ならまだしも、インターネットに繋がないサーバーとなると、OS標準のコマンドで実施する必要があるので調べてみた。...
  • WSFC / MSFC入門 (Windows Serverのクラスターでファイルサーバーを構築する)
    Windows Serverでクラスター構成を行う場合、OS標準の機能であるWSFC (Windows Server Failover Clustering)、別名MSFC (Microsoft Failover Clustering)を使うことが鉄板だろう。クラスターとい...
  • Ubuntu 20.04でシステム領域のディスク容量の拡張を行う
    Ubuntu 20.04を仮想環境で動かしているのだが、システム領域のディスク容量はデフォルトの16GBで運用していた。しかし、Linuxとはいえ、各種GUIのソフトウェアをインストールすることで、残り容量が心もとなくなってきた。 そこで、ディスク容量を拡張をすることにしたのだ...
  • Windows標準コマンド (PowerShell) を使ってsedっぽいことを実現する
    コマンドラインを使って文字列操作を行う場合、Linuxでは sed コマンドを使って実施するのが鉄板だが、WindowsではPowerShellのコマンドレットを組み合わせることでほぼ同様のことができる。 今回、いくつか sed でよく使う文字列処理のパターンに対して、Powe...
  • yum (dnf) でインストールメディアやローカルに保存されているrpmを適用する方法
    ローカルのディレクトリにある rpm について、 yum (RHEL 8以降は dnf ) の機能を用いて依存関係を考慮して適用したいことがある。ということで、 過去の記事 でローカルのディレクトリをリポジトリ登録する方法を記載したが、そんなことはしなくても、もっと簡単な方法が...