NetApp ONTAPのevent動作確認手法


syslogやsnmpにイベントを飛ばせる設定(EMS設定の概要)ができるのだが、設定した後の動作確認をどうするかを確認した

一般論的には「How to generate EMS Events manually for testing purposes」(日本語訳版)なのだが、サンプルとして書かれているコマンドを入力した場合の動作がいまいちである。

ontap9131::> set diag

Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

ontap9131::*> event generate -node ontap9131-01 -message-name monitor.volume.nearlyFull  -values Volume testshare@vsevrer:2d770626-xxxx-11ef-8a02-d039ea59xxxx is neary full is nearly full

ontap9131::*>

これでsyslogサーバには以下のログが届いた

May 23 15:29:01 rsyslogsevrer.adosakana.local [ontap9131-01: monitor.volume.nearlyFull:error]: Volume testshare@vsevrer:2d770626-xxxx-11ef-8a02-d039ea59xxxxisneary is nearly full (using or reserving full% of space and is% of inodes).

なんか出力内容が微妙

さがすともうちょっとまともなコマンド例が出てきた

Events not sent to syslog server due to network routes」(日本語訳版)

ontap9131::> set diag

Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

ontap9131::*> event generate -message-name monitor.volume.nearlyFull -values TEST,TEST,TEST,TEST,TEST,TEST

ontap9131::*>

これで届いたログは以下

May 23 15:18:32 rsyslogsevrer.adosakana.local [ontap9131-01: monitor.volume.nearlyFull:error]: TEST TESTTESTTEST is nearly full (using or reserving TEST% of space and TEST% of inodes).

ノード指定しなくても出力されてますね

何回かテストしてみたところ、未指定時は -01ノードの方から出力されており、-02ノードからノード指定しないとログが出ませんでした

あとはテストログの内容を現物に似せるため、まずは実際のエラーを出してみます

May 23 16:30:55 rsyslog.adosakana.local  [ontap9131-01: wafl.vol.autoSize.done:notice]: Volume autosize: Automatic grow of volume 'testshare@vserver:2d770626-xxxx-11ef-8a02-d039ea59xxxx' by 421MB is complete.
May 23 16:30:55 rsyslog.adosakana.local [ontap9131-01: monitor.volume.full:ALERT]: Volume "testshare@vserver:2d770626-xxxx-11ef-8a02-d039ea59xxxx" is full (using or reserving 99% of space and 0% of inodes).

それっぽい出力内容を調整すると下記な感じなんだけど「”」の入れ方がわからない・・・

ontap9131::*> event generate -message-name monitor.volume.nearlyFull -values Volume ,volume名,@SVM名,UUID,xx,yy

ontap9131::*>
May 23 16:40:24 rsyslog.adosakana.net [ontap9131-01: monitor.volume.nearlyFull:error]: Volume volume名@SVM名UUID is nearly full (using or reserving xx% of space and yy% of inodes).

メモ

エラーイベントを送る場合(イベントフィルタ:default-trap-events で見れる)

event generate -message-name monitor.volume.nearlyFull -values Volume ,volume名,@SVM名,UUID,xx,yy

アラートイベントを送る場合(イベントフィルタ:important-events で見れる)

event generate -message-name monitor.volume.full -values Volume ,volume名,@SVM名,UUID,xx,yy

直近15分以内のイベントログを見る

event log show -time >=15m

2024年5月23日17:00~17:20までのイベントログを見る

event log show -time "5/23/2024 17:00:00".."5/23/2024 17:20:00"

メモ ONTAP AV Connector 1.0.6と1.0.7はONTAP 9.1で使おうとするとクラッシュする


Windows Updateおこなってない環境にONTAP 9.1のCIFSファイルサーバがあって、そこからONTAP 9.13.1の新機種に移行したい、とかいうので環境作って検証した。

正攻法としてはONTAP 9.1を9.3→9.5→9.7→9.9.1にアップデートしてから(参考:アップデート手順ガイド)、Snapmirror互換性がOKな9.9.1から9.13.1へのsnapmirrorを設定してボリュームを移行するって感じにはなっている。

しかし、保証はされていないものの、9.3→9.11.1のsnapmirrorとかはできるというのはやったことがあった。

ひょっとして9.1→9.13.1のsnapmirrorも可能なんじゃないか?と思って確認してみたところ、めっちゃできた。

で・・・今回の本題。

このONTAP 9.13.1環境の方でONTAP AV Connector経由でのアンチウイルス対策を行う設定をしたついでに、ONTAP 9.1P22環境の方も設定してみたところ、異常な動作が発生

ONTAP 9.1P22ファイルサーバから検査対象ファイルが送られてくると、受け取ったAV Connectorがクラッシュしてサービスが死ぬ、というもの

障害が発生しているアプリケーション名: ontapavc.exe、バージョン: 1.0.7.0、タイム スタンプ: 0x661cd147
障害が発生しているモジュール名: ntdll.dll、バージョン: 10.0.17763.5458、タイム スタンプ: 0x761f6403
例外コード: 0xc0000374
障害オフセット: 0x000e0773
障害が発生しているプロセス ID: 0x1120
障害が発生しているアプリケーションの開始時刻: 0x01daa0f22241d4b8
障害が発生しているアプリケーション パス: C:\Program Files (x86)\ONTAP AV Connector\ontapavc.exe
障害が発生しているモジュール パス: C:\Windows\SYSTEM32\ntdll.dll
レポート ID: 25143b91-e094-4f5e-938b-c2aa5cc35312
障害が発生しているパッケージの完全な名前: 
障害が発生しているパッケージに関連するアプリケーション ID: 
障害バケット 1543444931139731394、種類 1
イベント名: APPCRASH
応答: 使用不可
Cab ID: 0

問題の署名:
P1: ontapavc.exe
P2: 1.0.7.0
P3: 661cd147
P4: StackHash_9e39
P5: 10.0.17763.5458
P6: 761f6403
P7: c0000374
P8: PCH_3C_FROM_ntdll+0x00071C4C
P9: 
P10: 

添付ファイル:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA03E.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA0FA.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA11B.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA119.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA129.tmp.txt

これらのファイルは次の場所にある可能性があります:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_ontapavc.exe_57546d7998f01e724387b6a478ec37f3d1a2348_9be34728_1fa5a5fb

分析記号: 
解決策を再確認中: 0
レポート ID: 25143b91-e094-4f5e-938b-c2aa5cc35312
レポートの状態: 268435456
ハッシュされたバケット: 519f2138c2a0e328e56b6afcc2f5ffc2
Cab GUID: 0

いろいろ試してみたところ、ONTAP 9.1だとAPIの使い方が違うために発生している模様で

ONTAP 9.3P22にアップデートしたところ、とりあえずAV Connectorがクラッシュすることもなく期待通りの動作をするようにはなった。

Oracle CloudのFree Tier(メモリ1GB)でdnfが死ぬ件でswapサイズを調べた


Oracle Cloud(OCI)にある無料枠(Free Tier)、x86_64ベースのやつはメモリが1GBとなっている。

Oracle Linux 7時代は特に問題なかった。

Oracle Linux 8も最初は特に問題なかったのだが、最近、dnfコマンドを実行するとOOM Killerでプロセスが殺されることが増えてきた。

Oracle Linux 9になると、OOM Killer発動するまで長時間かかりdnfコマンドの応答が返ってこないままフリーズしてるようにみえる、という状況が続く、というなかなかめんどくさいことになっていた。

Oracle Linux 9でtopコマンド実行しながら、dnf updateを実行して観察していると、レポジトリのファイル容量が80MBを超えているとdnfコマンド内部処理中にswapが1000MB以上使われているというのが見えた。

インスタンスとしては3GB~4GBぐらいのスワップ領域があるとよさそう、という感じである。

で、運用している環境で起きたりおきてなかったりするのはなぜなんだろう?と各インスタンスの設定状況を調べていくと、swap領域の設定がOCIイメージの作成時期によって違う、というめんどくさい状態であることが判明した。

特にOracle Linux 8の容量のかわりようが結構謎である・・・

ディストリビューションOCIイメージ名swap容量swap path
Oracle Linux 7 x86_64Oracle-Linux-7.7-2019.08.28-08G/dev/sda2
Oracle Linux 7 x86_64Oracle-Autonomous-Linux-7.8-2020.05-08G/dev/sda2
Oracle Linux 8 x86_64Oracle-Linux-8.7-2023.01.31-31.9G/.swapfile
Oracle Linux 8 aarch64Oracle-Linux-8.3-aarch64-2021.05.12-04G/.swapfile
Oracle Linux 8 aarch64Oracle-Linux-8.4-aarch64-2021.10.25-08G/.swapfile
Oracle Linux 8 aarch64Oracle-Linux-8.5-aarch64-2022.03.17-14G/.swapfile
Oracle Linux 8 aarch64Oracle-Linux-8.6-aarch64-2022.05.30-04G/.swapfile
Oracle Linux 9 x86_64Oracle-Linux-9.3-2024.04.22-0948M/.swapfile

BackupExecの重複排除ストレージはディスク1TBあたりメモリ1GBが必須


BackupExecには重複排除ストレージの機能があるが、ストレージ1TBあたりメモリが1GB要求される仕様になっている。

このため、例えばメモリ32GBのサーバで、ディスクが34TB(NTFSフォーマット後の容量)ある場合、下記の警告が定期的に出力されることになる。

Backup Exec 22 管理者ガイドの「Deduplication Feature の必要条件」には以下のように書かれている。

重複排除用ディスクストレージでは、ストレージの容量が 4 TB 以下の場合、4 GB の物理メモリが必要です。ストレージ容量がこれを超えて 32 TB 以下の場合、重複排除用ディスクストレージ 1 TB ごとに 1 GB の物理メモリが必要です。たとえば、5 TB のストレージでは 5 GB の物理メモリが必要です。重複排除用ストレージディスクの容量が 32 TB ~ 64 TB の場合は、32 GB 以上の物理メモリの使用をお勧めします。重複排除用ストレージディスクの容量が 64 TB ~ 100 TB の場合は、100 GB 以上の物理メモリの使用をお勧めします。

「勧めします」という表記になっており、バックアップ自体は動作するので、駄目、というわけではないのですが、1日複数回警告が出力されるため現実的ではないでしょう

この例の場合は、NTFSでフォーマット後の容量が31.5TBとなるようパーテーションを調整したところ警告が出なくなり、3TB程度なので誤差、ということでOKとなった。