ONTAP 9.5でSVM DR設定


ONTAP 8.x 7-modeではボリューム単位でしかsnapmirrorができませんでしたが、ONTAP 9.5では、SVM DRという機能を使ってSVMの機能ごとsnapmirrorできるようになっています。

ONTAP 8.3時代の分かりやすい絵「SVMのディザスタ リカバリの設定
ONTAP 9.xのドキュメント「SnapMirror SVMレプリケーションの概要

下記の環境であるとした場合のコマンド実行例を書く。

送り元となるクラスタ名 netapp001c
送り元となるSVM名 netapp001
受け側となるクラスタ名 netapp002c
受け側となるSVM名 netapp001-dr

(1) クラスタピア設定

GUIなどでクラスタピアを設定

コマンドだとcluster peerコマンドで実施。

(2) 受け側となるSVMを作成

受け側NetApp上で、受け側となるSVM(ピアSVM)を、dp-destinationというタイプで作成。

まずは、受け側に作られているSVMを確認するため「vserver show」を実行

netapp002c::> vserver show
                               Admin      Operational Root
Vserver     Type    Subtype    State      State       Volume     Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
netapp002    data    default    running    running     netapp002tm netapp002c_
                                                      p_root     01_NL_SAS_1
netapp002c   admin   -          -          -           -          -
netapp002c-01
            node    -          -          -           -          -
netapp002c-02
            node    -          -          -           -          -
4 entries were displayed.

netapp002c::>

ピアSVMを「vserver create -vserver netapp001-dr -subtype dp-destination」で作成し、「vserver show」で作成されたことを確認

netapp002c::> vserver create -vserver netapp001-dr -subtype dp-destination
[Job 937] Job succeeded:
Vserver creation completed.

netapp002c::>
netapp002c::> vserver show
                               Admin      Operational Root
Vserver     Type    Subtype    State      State       Volume     Aggregate
----------- ------- ---------- ---------- ----------- ---------- ----------
netapp001-dr data    dp-destination        stopped     -          -
                               running
netapp002    data    default    running    running     netapp002tm netapp002c_
                                                      p_root     01_NL_SAS_1
netapp002c   admin   -          -          -           -          -
netapp002c-01
            node    -          -          -           -          -
netapp002c-02
            node    -          -          -           -          -
5 entries were displayed.

netapp002c::>

作成したピアSVM netapp001-drは「stopped」状態となっている。

(3) SVM peerを作成1 受け側で関係の設定

受け側NetApp上で、送り元SVMとのSVM peerを作成

「vserver peer create -vserver 受け側SVM -peer-vserver 送り元SVM -applications snapmirror -peer-cluster 送り元NetAppクラスタ」を実行

netapp002c::> vserver peer create -vserver netapp001-dr -peer-vserver netapp001 -applications snapmirror -peer-cluster netapp001c

Info: [Job 938] 'vserver peer create' job queued

netapp002c::> 

実行後、「vserver peer show」を実行し、作成の状況を確認。

netapp002c::> vserver peer show
            Peer        Peer                           Peering        Remote
Vserver     Vserver     State        Peer Cluster      Applications   Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001    initializing netapp001c         snapmirror     netapp001

netapp002c::>

しばらく待つとPeer Stateが「initiated」に変化

netapp002c::> vserver peer show
            Peer        Peer                           Peering        Remote
Vserver     Vserver     State        Peer Cluster      Applications   Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001    initiated    netapp001c         snapmirror     netapp001

netapp002c::> 

(4) SVM peerを作成2 送り元で関係受諾

送り元NetApp上で、受け側からのSVM peer要求を受諾。

まずは「vserver peer show」で状況を確認

netapp001c::> vserver peer show
            Peer        Peer                           Peering        Remote
Vserver     Vserver     State        Peer Cluster      Applications   Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001    netapp001-dr pending      netapp002c         snapmirror     netapp001-dr

netapp001c::> 

Peer Stateが「pending」となっていることを確認。

pending状態を「vserver peer accept -vserver 送り元SVM -peer-vserver 受け側SVM」を実行して受諾。

netapp001c::> vserver peer accept -vserver netapp001 -peer-vserver netapp001-dr

Info: [Job 922] 'vserver peer accept' job queued

netapp001c::> 
netapp001c::> vserver peer show
            Peer        Peer                           Peering        Remote
Vserver     Vserver     State        Peer Cluster      Applications   Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001    netapp001-dr peered       netapp002c         snapmirror     netapp001-dr

netapp001c::>

Peer Stateが「peered」に変わったら受諾処理が完了です。(処理中はpendingのままです)

(5) SVM peerを作成3 受け側でも受諾を確認

受け側NetApp上で、SVM peerが成立したことを確認

netapp002c::> vserver peer show
            Peer        Peer                           Peering        Remote
Vserver     Vserver     State        Peer Cluster      Applications   Vserver
----------- ----------- ------------ ----------------- -------------- ---------
netapp001-dr netapp001    peered       netapp001c         snapmirror     netapp001

netapp002c::>

(6) snapmirrorの作成

まず、現状のsnapmirrorの状態を送り元と受け側で確認しておく。

netapp001c::> snapmirror show
This table is currently empty.

netapp001c::> 

netapp002c::> snapmirror show
This table is currently empty.

netapp002c::> 

snapmirrorの作成は、受け側NetApp上で実行する。

「snapmirror create -source-vserver 送り元SVM -destination-vserver 受け側SVM -type DP -policy DPDefault -schedule hourly -identity-preserve true」と実行する。

-schedule hourly というのは1時間ごとに同期を取る、という設定となる。このスケジュールを別のものにすることもできる。

netapp002c::> snapmirror create -source-vserver netapp001 -destination-vserver netapp001-dr -type DP -policy DPDefault -schedule hourly -identity-preserve true

netapp002c::> 

作成後、「snapmirror show」を実行すると下記の様に、「Mirror State:Uninitialzied」「Relationship Status: Idle」で表示される。

netapp002c::> snapmirror show
                                                                       Progress
Source            Destination Mirror  Relationship   Total             Last
Path        Type  Path        State   Status         Progress  Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001:   XDP  netapp001-dr: Uninitialized
                                      Idle           -         true    -

netapp002c::>

(7) snapmirrorの初期化開始

受け側NetApp上でsnapmirrorの初期化を開始する。

「snapmirror initialize -destination-path 受け側SVM:」を実行する。

netapp002c::> snapmirror initialize -destination-path  netapp001-dr:

netapp002c::> 

実行後、snapmirror showで実行し、「Relationship Status: Transferring」になっていることを確認。

netapp002c::> snapmirror show
                                                                       Progress
Source            Destination Mirror  Relationship   Total             Last
Path        Type  Path        State   Status         Progress  Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001:   XDP  netapp001-dr: Uninitialized
                                      Transferring   -         true    -

netapp002c::>

(8) Snapmirrorの完了を確認

ボリュームを含めてすべてのデータ転送が終わると「Mirror State: Snapmirrored」「Relationship Status: Idle」に変化します。

netapp002c::> snapmirror show
                                                                       Progress
Source            Destination Mirror  Relationship   Total             Last
Path        Type  Path        State   Status         Progress  Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
netapp001:   XDP  netapp001-dr: Snapmirrored
                                      Idle           -         true    -

netapp002c::> 

Backup ExecでNetAppのNDMPバックアップを行おうとしたときに0x20500106(542114054)というエラーになる


Backup ExecでNetAppのNDMPバックアップを行おうとしたときに0x20500106(542114054)というエラーになるという問題が発生した。

技術的詳細をみてみてもよく分からない。

該当の共有を確認すると日本語のディレクトリがある。

そして、NetApp上でボリュームの言語を確認するとja_JP.PCK_v2とUTF-8以外を使用している。

nas01c::> volume show -fields language
vserver   volume language
--------- ------ --------
<略>
svm1      testlang2
                 ja_JP.PCK_v2
nas01c::> 

では、日本語ではなく英数のディレクトリ名に変更

Backup Exec上で問題なく開くことができるようになった。

とりあえず、ボリュームの言語設定の問題であることは判明。

検索すると「How to enable Unicode or UTF-8 Language Support for the NDMP Option」というBackup Exec 11時代の古い記述を発見

ここに書かれている HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\Backup Exec For Windows\Backup Exec\NDMP の UseUTF8の値は「0」であり、UTF-8じゃないボリュームという設定になっているように見える。

この値の変更は、NDMPアクセスをするごとに反映されるようでBackupExecサービスやサーバ再起動は不要だった。

が・・・今回のja_JP.PCK_v2ボリューム上の日本語ディレクトリ問題には対処できなかった。

では、この値変更はBackupExec 21.0で不要かというとそうではなくて、ja_JP.UTF-8ボリュームだと日本語ディレクトリが文字化けで表示される、という問題が発生している。

これが「UseUTF8」の値を「1」に設定することで文字化けが解消されることは確認できた。

さて、本題に戻って、ja_JP.PCK_v2ボリューム上に日本語ディレクトリがある場合にエラーとなる件の対処方法があるかです。

とりあえずボリューム名をクリックするとバックアップ選択はされ、バックアップも完了できました。(レジストリ UseUTF8は0で実施)

リストアを選択すると、きちんと日本語で表示されています。

共有内のファイルを削除してリストアしてみると、正常にリストアされました。

しかし、「実験」だけをリストアしようとするとエラーとなりました。

というわけで、ja_JP.PCK_v2上に日本語ディレクトリがあっても、ボリューム全体をバックアップするのであれば問題無く動作する。

リストア時も全体であればリストアが成功するが、日本語ディレクトリは個別に指定するリストアは失敗する、という動作となりました。

ちなみにja_JP.UTF-8ボリューム上の日本語ディレクトリは文字化けでした。(レジストリUseUTF8は0)

文字化けしている状態であっても、文字化けディレクトリだけを指定してリストアすると正常にリストアできていました。(レジストリUseUTF8は0)


逆にレジストリUseUTF8を1にしてバックアップしたものはリストアできるか検証

ja_JP.UTF-8ボリューム上の日本語は表示できているが、ja_JP.PCK_v2ボリューム上は文字化けています。

リストアジョブを実行してみると成功します。

ja_JP.UTF-8ボリュームではファイル名も問題無くリストアできています。

ja_JP.PCK2_v2の方は文字化けでリストアされています。

ややこしいことにディレクトリ内のファイルについては文字化けせずにリストアされています。

おそらく、指定した階層についてだけ影響があり、それ以下の階層についてはNetApp側で処理されるため元のファイル名のままリストアできたものと想定されます。

NetApp ONTAP9.xでNDMPバックアップする場合の設定項目


NetApp ONTAP 9.xでNDMPバックアップを取得する際に必要な設定項目についての覚え書き

公式のマニュアル:SVMを対象としたNDMPの設定FlexVolのSVMを対象としたNDMPモードの管理

以前は各物理ノードがNDMPを受け付けていたものが、現在はNetAppの管理Storage VM(クラスタ)がNDMPの命令を受け付けるようになっている。

(1) NDMPの有効化

まず、現状有効になっているかを「vserver services ndmp status」を実行して確認する。

ontap-select-cluster::> vserver services ndmp status
This table is currently empty.

ontap-select-cluster::>

有効にするには「vserver services ndmp on -vserver 管理SVM名」を実行する

ontap-select-cluster::> vserver services ndmp on -vserver ontap-select-cluster

ontap-select-cluster::> 

有効になったことを「vserver services ndmp show」を実行して確認する。

ontap-select-cluster::> vserver services ndmp show
VServer       Enabled   Authentication type
------------- --------- -------------------
ontap-select-cluster
              true      challenge
svm0          false     challenge
2 entries were displayed.

ontap-select-cluster::> 

(2) ユーザ作成

NDMPアクセス用のユーザを、NetAppのローカルユーザとして作成する。

下記の例では「backupadmin」というユーザを作成している。「role:backup」という権限で作成することが重要です。

なお、ここで指定するパスワードをそのままNDMPバックアップ時に指定するわけではありません。

ontap-select-cluster::> security login create -user-or-group-name backupadmin -application ssh -authmethod password -role backup

Please enter a password for user 'backupadmin':
Please enter it again:
ontap-select-cluster::> 

NDMPバックアップ時に使用するパスワードは、自動生成のパスワードになります。

「vserver services ndmp generate-password -vserver 管理SVM名 -user ユーザ名」でパスワードを確認します。なお、ユーザ作成時のパスワードを元に生成しているので、generate-passwordを実行するたびにパスワードが変わるということはありません。

ontap-select-cluster::>  vserver services ndmp generate-password -vserver ontap-select-cluster -user backupadmin

 Vserver: ontap-select-cluster
    User: backupadmin
Password: qG5CqQHYxw9fE57g
ontap-select-cluster::> 

(3) LIFの作成

NDMPバックアップは、ネットワークインタフェースのroleがinterclusterであるものを使用します。

現状のinterclusterを確認するには「network interface show -role intercluster」を実行します

ontap-select-cluster::> network interface show -role intercluster
There are no entries matching your query.

ontap-select-cluster::>

存在しない場合は、新規で作成するか、既存のLIFを流用するための設定を行います。

流用する場合は公式マニュアルの「LIFの設定」をみていろいろやります。(面倒くさいはず)

作成する際は、「-home-node」と「-home-port」で主として使用する物理ノードとネットワークポートを指定します。

ontap-select-cluster::> network interface create -vserver ontap-select-cluster -lif cluster_intercluster -role intercluster -service-policy default-intercluster -address 172.17.44.109 -netmask 255.255.0.0 -home-node ontap-select-node -home-port e0a

ontap-select-cluster::>

作成されたことを「network interface show -role intercluster」を実行して確認します。

ontap-select-cluster::> network interface show -role intercluster
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
ontap-select-cluster
            cluster_intercluster
                         up/up    172.17.44.109/16   ontap-select-node
                                                                   e0a     true

ontap-select-cluster::> 

メモ

「vserver show -ins」で表示される「Allowed Protocols」「Disallowed Protocols」の扱い

物理ノードに対するNDMPが有効になっていないか?「system service ndmp show」で「Enabled:false」を確認

対象となるSVMと、必要となるロールの違い:SVMを対象としたNDMPモードでのユーザ認証

Storage Virtual Machine(SVM)を対象としたNDMPモードでは、NDMPユーザ認証がロールベース アクセス制御と統合されます。SVMのコンテキストでは、NDMPユーザのロールはvsadminまたはvsadmin-backupのどちらかである必要があります。クラスタのコンテキストでは、NDMPユーザのロールはadminまたはbackupのどちらかである必要があります。

SVMのfirewall policy設定でinterclusterのポリシーでNDMPが許可されているか「system services firewall policy show -policy intercluster」

NetApp NDMP設定の詳細確認「vserver services ndmp show -ins」の「Preferred Interface Role」に書かれているroleのインタフェースがNDMPに使用できる

2段階のNFSマウントをする方法


直接アクセスできないネットワークにあるNFSサーバをNFSでマウントすることはできないか試行錯誤してみた。

普通にCentOS7やSolaris11からやってみたところ、NFSマウントした領域のNFS exportでの公開はnfsd側から「Cannot export /mnt, possibly unsupported filesystem or fsid= required」とか、「Invalid filesystem」とか言われて設定できない。

これはuser-spaceで動作するnfsdを使えば回避できるんじゃないかと探してみた結果、unfs3というものを発見。ソースコードは https://github.com/unfs3/unfs3

Linux,FreeBSD,Solaris,AIX,Irix,MacOSXで動く以外に、Windows上でも制限ありで動作するとのこと。

Windows上で動かした場合は、unfsdが使用するWindowsユーザを1つ割り当てる形になるので、NFS経由のアクセスは全てそのWindowsユーザがアクセスしている、という扱いになるようだ。

あと、このunfs3はNFS ver3のみ使え、NFS v4やNFS v2でのアクセスには対応していない。また、NFS v3でもREADDIRPLUS(属性付きディレクトリの読み取り)周りは実装していないとのこと。

READDIRPLUSはOracle/Solarisのドキュメントによればlsコマンドなどでディレクトリ内のファイル一覧を表示させる動作を高速化するためのものなので、まぁ、なくてもなんとかなる感じのもの。

属性付きディレクトリの読み取り
NFS バージョン 3 では、READDIRPLUS と呼ばれる操作があります。たとえば、ls や ls -l などの、大部分の READDIR が READDIRPLUS コールとして発行されます。バージョン 3 で ls -l コマンドを実行すると、ディレクトリ内の名前リストと共に、ファイルハンドルと属性が返されます。バージョン 2 では、名前が最初に返され、ファイルハンドルと属性を取得するには、続いてサーバーを呼び出す必要があります。
バージョン 3 の READDIRPLUS 操作の利点は、ファイルごとに GETATTR 要求を送信する必要がないため時間が短縮され、ls と ls -l の速度が同程度になることです。

要件は満たせそうなので、とりあえずテスト用CentOS7環境でunfs3を動作させてみる。

準備

環境をインストール

# yum install git
# yum groupinstall "開発ツール"

コンパイル

まず、ソースコードの入手

$ git clone https://github.com/unfs3/unfs3.git

READMEにあるとおりbootstrap&configureを実行

$ cd unfs3/unfs3
$ ./bootstrap
$ ./configure

そしてmake

$ make
for i in Config ; do (cd $i && make all) || exit; done
make[1]: ディレクトリ `/root/unfs3/Config' に入ります
gcc -g -O2 -Wall -W -I.. -I. -I..   -c -o lex.yy.o lex.yy.c
gcc -g -O2 -Wall -W -I.. -I. -I..   -c -o y.tab.o y.tab.c
ar crs lib.a lex.yy.o y.tab.o
make[1]: ディレクトリ `/root/unfs3/Config' から出ます
gcc -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o afsgettimes.o afsgettimes.c
gcc -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o afssupport.o afssupport.c
gcc -g -O2 -Wall -W  -D_GNU_SOURCE -I.   -c -o attr.o attr.c
attr.c: 関数 ‘get_free_bad_dir_entry’ 内:
attr.c:550:5: エラー: ‘for’ ループ初期化宣言は C99 モード内でのみ許可されてい ます
     for (int i = 0;i < BAD_DIR_CACHE_SIZE;i++) {
     ^
attr.c:550:5: 備考: オプション -std=c99 または -std=gnu99 をコードコンパイル時に使用してください
attr.c: 関数 ‘find_bad_dir_entry’ 内:
attr.c:573:5: エラー: ‘for’ ループ初期化宣言は C99 モード内でのみ許可されてい ます
     for (int i = 0;i < BAD_DIR_CACHE_SIZE;i++) {
     ^
make: *** [attr.o] エラー 1
$

エラーとなってしまいます。

これはコンパイル時のオプションに「-std=c99」を指定するようにして解決

$ export CPPFLAGS="-std=c99";./configure
$ make
<略>
$

インストールと設定

普通にmake installすると/usr/local以下にインストールされます。

# make install
/usr/bin/install -c -d /usr/local/sbin
/usr/bin/install -c -d /usr/local/share/man/man7
/usr/bin/install -c -d /usr/local/share/man/man8
/usr/bin/install -c unfsd /usr/local/sbin/unfsd
/usr/bin/install -c -m 644 ./Extras/tags.7 /usr/local/share/man/man7/tags.7
/usr/bin/install -c -m 644 ./unfsd.8       /usr/local/share/man/man8/unfsd.8
#

NFSで公開するディレクトリの設定は、普通のnfsdと同じく /etc/exports ファイルを使用。「-e」オプションで別のファイルを指定することも可能です。

注意点としては、Linuxだとホスト名指定に「*」とnetgroupが使用できず、ログに「unfsd[20479]: syntax error in ‘/etc/exports’, exporting nothing」といった出力が出てしまうという点です。

「*」については「0.0.0.0/0」で代替できます。

/etc/exports ファイルを編集した場合、変更にはexportfsコマンドは使用できません。

unfsdに対してHUPシグナルを送ることで反映されます。(kill -HUP unfsdのPID)

unfsdの起動は「/usr/local/sbin/unfsd」の実行、停止はunfsdへのTERMシグナル送信(kill -TERM unfsdのPID)です。

東京証券取引所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」におけるコントローラ自動切替の仕様に関する重要なお知らせ

画像
画像
画像