こんにちは、キクです。
先日、本番環境で稼働中のNetApp機器にて「ONTAPバージョンアップ作業」を実施しました。
その中で何度か通信障害が発生してしまったので、本記事ではその内容をご紹介するとともに整理していこうと思います。
それでは、よろしくお願いします。
ONTAPバージョンアップの概要
本項では、今回実施した多段階のONTAPバージョンアップの概要について触れていきます。
ONTAPのバージョンアップにおいては、隣接しないターゲットバージョンにアップグレードする場合には、中間バージョンにアップグレードしてから最終的なバージョンへとアップグレードする「マルチステージ」という方式でバージョンアップを実施することがあります。
今回は「ONTAP9.3 → 9.8」のバージョンアップを実施しましたが、以下のように合計3段階の作業となりました。
なお、上記ではパッチバージョンは省略していますが、各バージョンでは最新のパッチを適用しながら最終的なターゲットバージョンにバージョンアップすることが推奨されています。
また、本記事ではバージョンアップ作業の詳細については割愛しますが、各段階ではコントローラ1台ずつ作業を実施しています。
そのため、全体としては合計6回のバージョンアップを実施したことになります。
通信障害の簡易説明
本項では、今回の作業で発生した通信障害の回数とタイミングについて簡単に触れておきます。
合計6回のバージョンアップ作業のうち、通信障害は2回発生しました。
タイミングとしては以下の通りです。
なお、通信障害の内容についてですが、対象ノードはESXiホストに対してデータストアを提供しており、各データストアにおいて「APD（All Path Down）」が発生しました。
時間としては、1回目は約2分程度、2回目は約20秒程度でした。
サーバ側の事象については、以下の記事でまとめてみました。
関連：【VMware】ストレージOSのバージョンアップに伴って発生したAPD障害に関する整理
1回目の通信障害について
1段階目でONTAP9.3から9.5にバージョンアップする際に、コントローラ2のテイクオーバを実行に発生した通信障害。
テイクオーバ処理が開始されて数秒後にサーバ側でポツポツと赤いエラーが表示されました。
内容は前述の通りデータストアのAPDとなりますが、「おやおや！？」となっている間にAPD状態はひとまず自動回復しました。
今回APDとなったのは、テイクオーバ実施対象のコントローラが管理するアグリゲート上のボリューム達でした。
こちらの原因は、ONTAP9.3に起因する既知のバグに該当していました。
参考：Consecutive cluster takeover initiate LIFs down with error: vifmgr.lifdown.noports:alert
バグの内容としては以下の通りで、LIFの移行回数カウンタ関連でLIFがダウンとして認識されたようです。
■原文
Within the takeover procedure, the LIFs have one attribute to count the number of attempts that have been made to host an LIF to ports in its failover group.
The max number of attempts that are made to try and host a LIF is 2*NUM_OF_LIF_FAILOVER_TARGETS, but ONTAP's defect causes this attribute not to reset to zero after each takeover to mark the LIFs down if meets this max number.
■Google翻訳
テイクオーバー手順内で、LIF には、フェイルオーバー グループ内のポートに LIF をホストするために試行された回数をカウントする属性が 1 つあります。
LIF のホスト試行の最大試行回数は 2*NUM_OF_LIF_FAILOVER_TARGETS ですが、ONTAP の欠陥により、この最大数を満たしている場合、各テイクオーバー後にこの属性がゼロにリセットされず、LIF がマークダウンされます。
対策としては、「LIFのカウンタ情報を手動でリセット」または「ONTAP9.5以降にバージョンアップ」という選択肢がありますが、今回は後者が実施済みとなっているため追加での対応は不要となりました。
コントローラ1側の作業では発動しなかったため、コントローラ2で発動してしまったのは運が悪かった・・・。
2回目の通信障害について
2段階目でONTAP9.5から9.7にバージョンアップする際に、コントローラ1のテイクオーバを実行に発生した通信障害。
1回目の通信障害の原因を特定できたのが全体の作業を終えてからでした。
そのため、当時の作業では「対策前進」で進めていました。
作業時に1点気になったことがあり、それは1回目の通信障害発生時にLIFの移行処理だけがやたらと遅い気がするという状態でした。
これを踏まえて、以降の作業では事前にLIFを移行してからテイクオーバを実施する対策を取ることにしました。
この対策にて何回かは異状なく作業ができていたので「これはいける！」と思いながら残りの作業を進めていました。
しかし、2段階目のコントローラ1で2回目の通信障害が発生してしまいました。
1回目の障害とは異なり、今度はコントローラ1 / コントローラ2双方のボリュームでAPDが発動しました。
ただし、1回目の通信障害よりも短い時間で自動復旧されたという挙動でした。
こちらの原因は、複数のONTAPバージョンが対象となっている既知のバグ（BUG：1295077）に該当していました。
参考：Data LIF of the takeover node briefly disconnects during node takeover
参考：1295077 - Data LIF of the takeover node briefly disconnects during node takeover
バグの内容としては以下の通りで、テイクオーバに伴いデータLIFにて短時間切断が発生してしまっていました。
■原文
While performing a node takeover, moving data LIF to a takeover node results in brief disconnection.
- In the event log there are notifications about LIFs being moved
- External cache warming process terminated (extCache.rw.terminated) due to timeout (extCache.rw.timeout) prior the kernel shutdown notice (kern.shutdown)
■Google翻訳
ノードの引き継ぎの実行中に、データ LIF を引き継ぎノードに移動すると、短時間切断が発生します。
イベント ログには、LIF の移動に関する通知が記録されます
カーネルシャットダウン通知 (kern.shutdown) の前に、タイムアウト (extCache.rw.timeout) により外部キャッシュウォーミングプロセスが終了しました (extCache.rw.terminated
対策としては、テイクオーバ実行前に以下のコマンドを実行することが挙げられています。
::> system node external-cache modify -node コントローラ名 -is-rewarm-enabled falseコマンド内に含まれる「external-cache」は、コントローラに搭載されているキャッシュカードのことを指しています。
また「-is-rewarm-enabled」がTrueの場合には、上記キャッシュカードの情報（Flash Cache）がパートナー側のコントローラにコピーされます。
このコピー処理により対象コントローラの再起動が遅延されて、結果的に通信障害に繋がったという流れとなりました。
もう少し深堀りすると、再起動の遅延によりLIF関連サービスである「Vifmgrプロセス」と呼ばれるものが正常に切り替えできず、LIFの一時的な切断に繋がったようです。
そのため、上記コピー処理を無効化することで再起動の遅延を防ぎ、今回発生したLIFの短時間切断も防ぐことができるようになります。
なお、コピー対象のキャッシュ情報は読み取り専用であるため、コピーを無効化したことでデータロストが発生することもありません。
おわりに
いかがだったでしょうか。
今回はONTAPバージョンアップ作業時に発生した通信障害についてご紹介しました。
基本的に本番作業を実施するときは「これで大丈夫」という状態で臨むので、今回の事象が発生したときには焦りました。
しかし、このような経験は普段の業務では知り得ない部分まで深掘って調査をするので、非常に勉強になりました。
また、今回の事象はどちらも「既知のバグ」だったので、もしかしたら事前に対処できるものだったかもしれないと反省する機会にもなりました。
本記事を最後まで読んでいただき、ありがとうございました。
ではでは！