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標準のコマンドで実施する必要があるので調べてみた。...
  • Windows Timeサービスの時刻同期を正しく設定する手順【Windows 10・Windows Server 2016以降対応】
    数年前の記事となるが、Windows Server 2008 R2環境における時刻同期方法について記事にした。 Workgroup環境でのWindowsの時刻同期の設定方法 あれからWindows Serverも2012、2012 R2、2016、2019とバージョンアッ...
  • Workgroup環境のWindwos OSからドメインユーザのパスワードを変更する
    Windowsのユーザのパスワードを変更する場合は、通常は直接対象ユーザにてOSにログインを行いパスワードを変更すればよいが、何らかの理由で 直接ログインはできないがパスワードを変更を行いたい場合 がある。 例として挙げると、ドメインに新しいユーザを作成した際に「ユーザーは次回...
  • Squid入門
    プロキシサーバーといえばデファクトスタンダードともいえるSquid。このSquidの基本的な設定について記載する。 プロキシサーバーとして動作する設定ではあるが、本記事の内容だけでは、パフォーマンス面やセキュリティ面において考慮不足となる事項が多数ある点に注意すること。 S...
  • Ubuntu 20.04でシステム領域のディスク容量の拡張を行う
    Ubuntu 20.04を仮想環境で動かしているのだが、システム領域のディスク容量はデフォルトの16GBで運用していた。しかし、Linuxとはいえ、各種GUIのソフトウェアをインストールすることで、残り容量が心もとなくなってきた。 そこで、ディスク容量を拡張をすることにしたのだ...