カテゴリー: ストレージ

投稿日:

Proxmox VEクラスタをUPSで停止する手法のメモ(調査段階

Proxmox VE環境でcephによるストレージ領域を作成して、物理的にディスクを共有していない状態で複数サーバ間を1ファイルシステムで運用できる環境についての試験中。

Proxmox VEクラスタをUPS連動で停止する場合の処理について確認しているのだが、公式ドキュメントにそのまま使えるようなものがないので、情報を集めているところ・・・

Proxmox VE公式ドキュメント:Shutdown Proxmox VE + Ceph HCI cluster
これはceph側の処理だけかかれていて、ceph側を止める前には仮想マシンを停止しなければならないのに、そこについて触れていない。

Proxmox VEフォーラムを探す
Clean shutdown of whole cluster (2023／01／16)
Shutdown of the Hyper-Converged Cluster (CEPH) (2020/04/05)

ここらのスクリプトが使えそうだが、仮想マシン/コンテナを停止するのは「各ノードで pvenode stopallを実行」ではなく、「APIを使ってすべてを停止する」が推奨される模様。

ここから試験

「pvesh get /nodes」でノードリストを作って、「ssh ホスト名 pvenode stopall」で仮想マシンを停止できるか試してみたが、管理Web上は「VMとコンテナの一括シャットダウン」と出力されるのだが、仮想マシンの停止が実行されなかった。

3.11.3. Bulk Guest Power Management を見ると止まっても良さそうなんだけど・・・

pvesh コマンドを調べるとこちらでも停止させることができる模様なので下記で実施

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do for vmid in `pvesh ls /nodes/$hostname/qemu/|awk '{ print $2 }'`; do pvesh create /nodes/$hostname/qemu/$vmid/status/shutdown; done; done

実行例

root@pve36:~# for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`
> do for vmid in `pvesh ls /nodes/$hostname/qemu/|awk '{ print $2 }'`
>   do
>     pvesh create /nodes/$hostname/qemu/$vmid/status/shutdown
>   done
> done
VM 102 not running

Requesting HA stop for VM 102
UPID:pve36:00014A47:0018FC0A:6731A591:hastop:102:root@pam:
VM 100 not running
Requesting HA stop for VM 100"UPID:pve37:00013A71:0018FDDC:6731A597:hastop:100:root@pam:"
VM 101 not running
Requesting HA stop for VM 101"UPID:pve38:000144BF:00192F03:6731A59D:hastop:101:root@pam:"
Requesting HA stop for VM 103"UPID:pve38:000144DC:0019305D:6731A5A0:hastop:103:root@pam:"
root@pve36:~#

これで、停止することを確認

次に仮想マシンの停止確認

root@pve36:~# pvesh get /nodes/pve36/qemu
lqqqqqqqqqwqqqqqqwqqqqqqwqqqqqqwqqqqqqqqqqqwqqqqqqqqqqwqqqqqqqqqwqqqqqwqqqqqqqqqqqwqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqqwqqqqqqwqqqqqqqqk
x status  x vmid x cpus x lock x   maxdisk x   maxmem x name    x pid x qmpstatus x running-machine x running-qemu x tags x uptime x
tqqqqqqqqqnqqqqqqnqqqqqqnqqqqqqnqqqqqqqqqqqnqqqqqqqqqqnqqqqqqqqqnqqqqqnqqqqqqqqqqqnqqqqqqqqqqqqqqqqqnqqqqqqqqqqqqqqnqqqqqqnqqqqqqqqu
x stopped x  102 x    2 x      x 32.00 GiB x 2.00 GiB x testvm2 x     x           x                 x              x      x     0s x
mqqqqqqqqqvqqqqqqvqqqqqqvqqqqqqvqqqqqqqqqqqvqqqqqqqqqqvqqqqqqqqqvqqqqqvqqqqqqqqqqqvqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqvqqqqqqvqqqqqqqqj
root@pve36:~#

ヘッダーを付けない形式で出力

root@pve36:~# pvesh get /nodes/pve36/qemu --noborder --noheader
stopped  102    2      32.00 GiB 2.00 GiB testvm2                                                 0s
root@pve36:~#

“stopped” となってない行があればまだ停止していない、ということになるので「pvesh get /nodes/pve36/qemu –noborder –noheader|grep -v “stopped”」の出力結果があるかどうかで判断できそう

また、これらはqemu仮想マシンについてのみなので、lxcコンテナについては含まれないので、そちらについても対応する

停止

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do for vmid in `pvesh ls /nodes/$hostname/lxc/|awk '{ print $2 }'`; do pvesh create /nodes/$hostname/lxc/$vmid/status/shutdown;done;done

仮想マシンが止まったかを判断するには、すべての仮想マシンの状態が”stopped”になっているか、で判定するなら下記

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do  echo "=== $hostname ===";    flag=0;  while [ $flag -eq 0 ];  do    pvesh get /nodes/$hostname/qemu --noborder --noheader|grep -v "stopped" > /dev/null;    flag=$?;    echo $flag;  done; done

すべての仮想マシンの状態で”running”がないことなら

for hostname in pvesh ls /nodes/|awk '{ print $2 }'; do echo “=== $hostname ===”; flag=0; while [ $flag -eq 0 ]; do pvesh get /nodes/$hostname/qemu –noborder –noheader|grep “running” > /dev/null ; flag=$?; echo $flag; done; done

どっちがいいかは悩むところ

Cephの停止についてはRedHatの「2.10. Red Hat Ceph Storage クラスターの電源をオフにして再起動」とProxmoxの「Shutdown Proxmox VE + Ceph HCI cluster 」を確認

Proxmox VE側だと下記だけ

ceph osd set noout
ceph osd set norecover
ceph osd set norebalance
ceph osd set nobackfill
ceph osd set nodown
ceph osd set pause

RedHat側にはこれらを実行する前にcephfsを停止するための手順が追加されている。

ceph fs set FS_NAME max_mds 1
ceph mds deactivate FS_NAME:1 # rank 2 of 2
ceph status # wait for rank 1 to finish stopping
ceph fs set FS_NAME cluster_down true
ceph mds fail FS_NAME:0

ceph fs setで設定しているmax_mdsとcluster_downの値はどうなっているのかを確認

root@pve36:~# ceph fs get cephfs
Filesystem 'cephfs' (1)
fs_name cephfs
epoch   65
flags   12 joinable allow_snaps allow_multimds_snaps
created 2024-11-05T14:29:45.941671+0900
modified        2024-11-11T11:04:06.223151+0900
tableserver     0
root    0
session_timeout 60
session_autoclose       300
max_file_size   1099511627776
max_xattr_size  65536
required_client_features        {}
last_failure    0
last_failure_osd_epoch  3508
compat  compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,7=mds uses inline data,8=no anchor table,9=file layout v2,10=snaprealm v2}
max_mds 1
in      0
up      {0=784113}
failed
damaged
stopped
data_pools      [3]
metadata_pool   4
inline_data     disabled
balancer
bal_rank_mask   -1
standby_count_wanted    1
[mds.pve36{0:784113} state up:active seq 29 addr [v2:172.17.44.36:6800/1472122357,v1:172.17.44.36:6801/1472122357] compat {c=[1],r=[1],i=[7ff]}]
root@pve36:~#

cluster_downはない？

root@pve36:~# ceph mds stat
cephfs:1 {0=pve36=up:active} 1 up:standby
root@pve36:~# ceph mds compat show
compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table,9=file layout v2,10=snaprealm v2}
root@pve36:~#

んー？　ceph fsのcluster_down を実行してみる

root@pve36:~# ceph fs set cephfs cluster_down true
cephfs marked not joinable; MDS cannot join as newly active. WARNING: cluster_down flag is deprecated and will be removed in a future version. Please use "joinable".
root@pve36:~#

joinableを使えとあるので、この記述は古いらしい

おや？と思って再度探したところRedHatのドキュメントが古かった。RedHat「2.5. Red Hat Ceph Storage クラスターの電源をオフにして再起動」、もしくはIBMの「Ceph File System ・クラスターの停止」

ceph fs set FS_NAME max_mds 1
ceph fs fail FS_NAME
ceph status
ceph fs set FS_NAME joinable false

IBM手順の方だとmax_mdsの操作は行わずに実施している

root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK  STATE    MDS      ACTIVITY     DNS    INOS   DIRS   CAPS
 0    active  pve36  Reqs:    0 /s    21     20     16     23
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph fs fail cephfs
cephfs marked not joinable; MDS cannot join the cluster. All MDS ranks marked failed.
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph fs fail cephfs
cephfs marked not joinable; MDS cannot join the cluster. All MDS ranks marked failed.
root@pve36:~# echo $?
0
root@pve36:~#  ceph fs set cephfs joinable false
cephfs marked not joinable; MDS cannot join as newly active.
root@pve36:~# echo $?
0
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~#

…止めてしまったら、dfコマンドが実行できなくなるので注意

root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3599
root@pve36:~# ceph osd set noout
noout is set
root@pve36:~# ceph osd set norecover
norecover is set
root@pve36:~# ceph osd set norebalance
norebalance is set
root@pve36:~# ceph osd set nobackfill
nobackfill is set
root@pve36:~# ceph osd set nodown
nodown is set
root@pve36:~# ceph osd set pause
pauserd,pausewr is set
root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

ドキュメントに「重要 上記の例は、OSD ノード内のサービスと各 OSD を停止する場合のみであり、各 OSD ノードで繰り返す必要があります。」とあるので、各サーバで確認してみたが、別に各サーバで実行する必要はなさそうである。

root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve37 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve38 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve39 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

このあと、各サーバに対してshutdown -h nowを実行して止めた

起動後

root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_ERR
            1 filesystem is degraded
            1 filesystem is offline
            pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover flag(s) set

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 41s)
    mgr: pve38(active, since 30s), standbys: pve37, pve36
    mds: 0/1 daemons up (1 failed), 2 standby
    osd: 16 osds: 16 up (since 48s), 16 in (since 3d)
         flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover

  data:
    volumes: 0/1 healthy, 1 failed
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

root@pve36:~# ceph osd stat
16 osds: 16 up (since 69s), 16 in (since 3d); epoch: e3621
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

root@pve36:~# ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~#

復帰のためのコマンド群1

root@pve36:~# ceph osd unset noout
noout is unset
root@pve36:~# ceph osd unset norecover
norecover is unset
root@pve36:~# ceph osd unset norebalance
norebalance is unset
root@pve36:~#  ceph osd unset nobackfill
nobackfill is unset
root@pve36:~# ceph osd unset nodown
nodown is unset
root@pve36:~# ceph osd unset pause
pauserd,pausewr is unset
root@pve36:~# ceph osd stat
16 osds: 16 up (since 100s), 16 in (since 3d); epoch: e3627
root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_ERR
            1 filesystem is degraded
            1 filesystem is offline

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 102s)
    mgr: pve38(active, since 90s), standbys: pve37, pve36
    mds: 0/1 daemons up (1 failed), 2 standby
    osd: 16 osds: 16 up (since 108s), 16 in (since 3d)

  data:
    volumes: 0/1 healthy, 1 failed
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

  io:
    client:   21 KiB/s rd, 0 B/s wr, 9 op/s rd, 1 op/s wr

root@pve36:~#

ファイルシステム再開

root@pve36:~# ceph fs set cephfs joinable true
cephfs marked joinable; MDS may join as newly active.
root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK    STATE     MDS   ACTIVITY   DNS    INOS   DIRS   CAPS
 0    reconnect  pve36              10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph osd stat
16 osds: 16 up (since 2m), 16 in (since 3d); epoch: e3627
root@pve36:~# cpeh status
-bash: cpeh: command not found
root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_WARN
            1 filesystem is degraded

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 2m)
    mgr: pve38(active, since 2m), standbys: pve37, pve36
    mds: 1/1 daemons up, 1 standby
    osd: 16 osds: 16 up (since 2m), 16 in (since 3d)

  data:
    volumes: 0/1 healthy, 1 recovering
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

root@pve36:~#
root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK  STATE    MDS   ACTIVITY   DNS    INOS   DIRS   CAPS
 0    rejoin  pve36              10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# df
Filesystem           1K-blocks     Used Available Use% Mounted on
udev                   8156156        0   8156156   0% /dev
tmpfs                  1638000     1124   1636876   1% /run
/dev/mapper/pve-root  28074060 14841988  11780656  56% /
tmpfs                  8189984    73728   8116256   1% /dev/shm
tmpfs                     5120        0      5120   0% /run/lock
/dev/fuse               131072       36    131036   1% /etc/pve
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-2
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-0
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-1
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-3
tmpfs                  1637996        0   1637996   0% /run/user/0
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE    MDS      ACTIVITY     DNS    INOS   DIRS   CAPS
 0    active  pve36  Reqs:    0 /s    10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# df
Filesystem                               1K-blocks     Used Available Use% Mounted on
udev                                       8156156        0   8156156   0% /dev
tmpfs                                      1638000     1128   1636872   1% /run
/dev/mapper/pve-root                      28074060 14841992  11780652  56% /
tmpfs                                      8189984    73728   8116256   1% /dev/shm
tmpfs                                         5120        0      5120   0% /run/lock
/dev/fuse                                   131072       36    131036   1% /etc/pve
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-2
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-0
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-1
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-3
tmpfs                                      1637996        0   1637996   0% /run/user/0
172.17.44.36,172.17.44.37,172.17.44.38:/ 142516224 11116544 131399680   8% /mnt/pve/cephfs
root@pve36:~#

ただ、これだと通常のPVE起動プロセスで実行される「VMとコンテナの一括起動」で仮想マシンが実行されなかった。おや？と思ったら、設定が変わってた

root@pve36:~# ha-manager status
quorum OK
master pve39 (active, Mon Nov 11 18:24:13 2024)
lrm pve36 (idle, Mon Nov 11 18:24:15 2024)
lrm pve37 (idle, Mon Nov 11 18:24:18 2024)
lrm pve38 (idle, Mon Nov 11 18:24:18 2024)
lrm pve39 (idle, Mon Nov 11 18:24:15 2024)
service vm:100 (pve37, stopped)
service vm:101 (pve38, stopped)
service vm:102 (pve36, stopped)
service vm:103 (pve38, stopped)
root@pve36:~# ha-manager config
vm:100
        state stopped

vm:101
        state stopped

vm:102
        state stopped

vm:103
        state stopped

root@pve36:~#

投稿日:

NetApp ONTAPファイルサーバ置き換え後にいらないsnapshotを削除する

NetApp ONTAPファイルサーバを置き換える際、snapmirrorでボリューム転送して行う、というのがよくある。

で、置き換えた後、新旧NetAppを結ぶsnapmirrorで使用していたvolume snapshotについては自動削除されないので、それを特定して削除する、という必要があるので、その手法のメモ書き。

1 いまあるsnapshotの確認

「volume snapshot show -volume ボリューム名」で該当するボリューム内にあるsnapshotを確認

snapmirrorで作成されたsnapshotは「snapmirror.<UUID>_ID.日時」で作成されている。

2 snapmirrorで使用しているsnapshotの確認

「snapmirror show -destination-volume ボリューム名 -field exported-snapshot」でsnapmirrorが使用しているsnapshot名が表示される

つまり、1で確認したsnapmirrorと名前がついているsnapshotで、exported-snapshotに表示されないものが不要なものとなる。

3 snapshotの依存を確認

通常ONTAPのCLIでは-fields で表示させたい項目を入力する場合、タブ補完機能があるのだが、そこに表示されない裏オプション的なものがある。

それが、snapshotの依存が存在するかを表示する「dependency」である。(タブ補完がきかないので、すべて手動で入力する必要がある)

「volume snapshot show -volume ボリューム名 -fields dependency」を実行して確認する

表示される値は以下の意味がある。

空欄: 依存関係なし
snapmirror: snapmirrorの送り側
busy: snapmirrorの受け側

2で不要なsnapshotは確定しているが、そのsnapshotに対して「snapmirror」も「busy」もついてない、ということを確認する

4 snapshotの削除

不要なsnapshotを削除する

「volume snapshot delete -volume ボリューム名 -snapshot snapshot名」で削除する。

ちゃんとsnapmirror関係の削除処理が行われていれば削除しますかy/nの確認をしたのちに削除が行える。

なんらかの事情でロックがかかっている状態となっていて、それでも削除したい場合は、「set adv」でadvanced権限に移行し

「volume snapshot delete -volume ボリューム名 -snapshot snapshot名 -force true -ignore-owners true」オプションで強制削除する

投稿日:

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).

2024/06/11追記

ONTAP EMS reference の monitor.volume.nearlyFull に詳細が書いてあった。

Parameters
object_type (STRING): Identifier for the type of object to which this event applies (aggregate or volume).
name (STRING): Name of this object.
app (STRING): Application UUID.
vserver_uuid (STRING): Universal Unique ID (UUID) of the object’s Vserver, if the object is a volume. Otherwise, this string is empty.
percent_full_blocks (STRING): Used capacity of the space of the object, as a percent.
percent_full_inodes (STRING): Used capacity of inodes of the object, as a percent.

ほかのメッセージでテストする場合は、このEMS referenceの内容を確認すればよい、ということも分かった

メモ

エラーイベントを送る場合(イベントフィルタ: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がクラッシュすることもなく期待通りの動作をするようにはなった。

投稿日:

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 以上の物理メモリの使用をお勧めします。

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

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