投稿日: 投稿者: osakanataro

東京証券取引所arrowheadを止めた設定 on_panic

10月1日に東京証券取引所arrowheadシステムは共有ディスク装置のメモリ障害が起因になって発生したとのこと。

ようやく情報が出そろって何が原因だったのかがわかってきた。

書かれていた情報をまとめると後述のようになる。
（注:Data ONTAP 7G, Data ONTAP 8, ONTAP 9という正式表記がありますがめんどいので全部ONTAPで統一します)

なお、富士通が直接やった案件ではどうなのかわかりませんが、それ以外からNetAppを購入している場合、この設定項目を変更するなんてことはしないので、影響ありません。心配しなくて大丈夫です。

前提条件について

・NetApp FASシリーズのOEMである富士通 NR1000Fを使用している

・NetAppはONTAP OSというOSで動作している

・arrowheadで使用していたNASのOSバージョンは(制御機構バージョン)、初代(2010/01)は 7、2代目(2015/09)は8、今回障害が発生した3代目(2019/11)は9

・ONTAP OSはversion 8からシステムが作り直されておりシステム体系がだいぶ変わった。ただ、いままでの操作を新システムに変換する為の一覧(7-Modeオプションとclustered Data ONTAPコマンドのマッピング)が用意されている

・ONTAP 8は7-modeとClusteredの2種類がある
　7-modeはONTAP 7と同じコマンド体系だが内部はClusteredベース

・ONTAP 8を7-modeかClusteredのどちらで使っていたのか不明
　2代目(2015/09)だと、8.1.x最終バージョンの8.1.4(July 2014)はサポート切れになるので
　September 2014リリースの8.2.2、April 2015リリースの8.2.3？
　7-modeが廃止されてClusteredに一本化されたONTAP 8.3はApril 2015リリース

・ONTAP 7とONTAP 8 7-modeではサーバの上でNFS/CIFSファイルサービスが動く形式
　管理とファイルサービスは同一サーバ上で動作
　1物理ノード＝1ファイルサービス

・ONTAP 8 Clustered/ONTAP 9は仮想基盤の上でNFS/CIFSサービス用仮想マシン(StorageVM/SVM)が動く形式
　管理とファイルサービスは別扱いで動作
　1つの物理ノードの上で複数のStorageVMを動作可能

設定内容について

・今回問題となった設定は「storage failoverのonpanicオプション」に関するもの

・このオプションに相当するONTAP 7時代の設定はマッピングには「cf.takeover.on_panic」<=>「storage failover modify -onpanic」と記載されている。

・cf.takeover.on_panic設定についてONTAP 7.3.2のドキュメントではデフォルトが「on」となっている(それ以前のバージョンの同一箇所にはデフォルト記載が無い)

・ONTAP 7.xのリリース時期を比較すると、初代稼働が2010/01ということは2009/夏前には試験が始まってそうなので、7.3.2だと時期が早すぎるので、 7.3.1.1 あたりと想定される
　7.3.1: 23 January 2009, 7.3.1.1: April 2009, 7.3.2: Aug 14 2009
　7.3.3: 18 June 2010,7.3.4: 14 March 2011

・ONTAP 7.3時代のマニュアルには「iSCSIライセンスを入れるとcf.takeover.on_panicがonに設定される」という記述もあり、on_panic設定がデフォルト「off」だった時代もあるようだ

・ONTAP 7.3のマニュアルの「Reasons for takeover」にcf.takeover.on_panicはデフォルト「off」と明記。ONTAP7.3.2の同じ箇所にもデフォルトoffと書いてある。ONTAP7.3.2は同一マニュアル内でon_panicのデフォルト値が異なっているという事態に。どっちなんだよ

・ONTAP 8の7-modeの場合はcf.takeover.on_panicオプションがあるがoff時の説明が「a node panic will not cause an automatic takeover.」に変わっており、「You should not turn this option off unless you are instructed by technical support to do so.」と記載されている。

さて、問題となった設定の「ONTAP7のcf.takeover.on_panic」と「ONTAP8以降のstorage failoverのonpanicオプション」の違いを見てみる

まず、ONTAP 7での「cf.takeover.on_panic」

この値は「on」でも「off」でもサービスが切り替わるのは変わらない。

ONTAP 7では相手ノードからの応答が15秒以内になかったら相手が死んだと判断して切り替える、というのが基本となっている。

しかし、PANICが発生し、それがちゃんと検出できた場合は相手が死んでいるのは確定しているので、15秒待たないで切り替えていいんじゃないか？というのが「cf.takeover.on_panic」の扱いになる。

ONTAP 7時代の cf.takeover.on_panic
　on = PANICを検出したら即座に切り替える
　off = 通常の障害検出である15秒待ってから切り替える

ONTAP 8以降ではこのcf.takeover.on_panicオプションは storage failoverのonpanicオプション に置き換えられた、とマッピングに記載されている。

storage failoverのonpanicオプションについて確認するとonrebootオプションとあわせて、「自動テイクオーバーの制御用コマンド」として掲載されている。

役割は「ノードでのパニック」「ノード再起動」が発生した場合に、ストレージサービス(StorageVM)が使用しているストレージを活きているノード上に所有権を移動して継続稼働させるか、というものになっている。

また、この動作の説明はONTAP8 7-mode時のcf.takeover.on_panicに書かれている説明とも合致する。

ONTAP 8以降のstorage failoverのonpanicオプションとONTAP 8 7-modeのcf.takeover.on_panic
　on = 切り替えを行う
　off = 切り替えない

ただ、ここらへんの違いを下記のドキュメント記述だけで判断できるのか？という感じではある。

ONTAP 7.3.2のcf.takeover.on_panic設定についての記述

ONTAP 8.2.1の7-modeでのcf.takeover.on_panicについての記述

ONTAP 9でのstorage failoverについての記述

ONTAP 7.3の「Reasons for takeover」

ONTAP 7.3.2の「Reasons for takeover」

プレスリリースからの引用

JPX 2020/10/05付け「arrowhead の障害に関する原因と対策について」より

JPX 2020/10/19付け「10月1日に株式売買システムで発生した障害について」

富士通 2020/10/19付け「東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について」と「［重要］ストレージシステム「ETERNUS NR1000 series」におけるコントローラ自動切替の仕様に関する重要なお知らせ」

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

モバイルバージョンを終了