設定も終わり、トラフィック監視もそれとなくできている今日この頃。月初になったので CentOS関連の更新があるかと思い確認したところ
[rot@cacti ~]$ sudo yum check-update
[sudo] A0gaku のパスワード:
読み込んだプラグイン:fastestmirror, langpacks
base | 3.6 kB 00:00
epel/x86_64/metalink | 7.7 kB 00:00
epel | 4.7 kB 00:00
extras | 3.4 kB 00:00
mariadb | 2.9 kB 00:00
updates | 3.4 kB 00:00
(1/4): epel/x86_64/updateinfo | 879 kB 00:00
(2/4): extras/7/x86_64/primary_db | 166 kB 00:00
(3/4): epel/x86_64/primary_db | 6.2 MB 00:00
(4/4): updates/7/x86_64/primary_db | 6.0 MB 00:01
Loading mirror speeds from cached hostfile
* base: ftp.riken.jp
* epel: ftp.riken.jp
* extras: ftp.riken.jp
* updates: ftp.riken.jp
cacti.noarch 1.1.33-1.el7 epel
epel-release.noarch 7-11 epel
tzdata.noarch 2018c-1.el7 updates
yum.noarch 3.4.3-154.el7.centos.1 updates
と Cacti 1.1.33 がリリースされていました。rpm は 1.1.28 の次に 1.1.33 でしたね。Changelog を見ると色々と更新されていました。先々のことを鑑み、アップグレードをしてみます。
アップグレードの方法ですが、次の方針で行うことにしました。
- cronを止める
# vi /etc/cron.d/cacti
先頭に '#' を入れ、cron を無効化 - ESXi に入れてあるのでスナップショットの作成
- yum で cacti のアップデート
# yum update -y cacti - spine のソースを落としコンパイル → インストールまで
- ブラウザで管理画面にログイン
今回は設定の確認だけで、特に変更する箇所(赤字)はありませんでした - cronを動かす
# vi /etc/cron.d/cacti
先頭の '#' を削除し、cron を有効化
特に問題もなくアップグレードができました。本当だったら DBのバックアップとか旧Cacti環境のバックアップが必要なんでしょうけど、ダメだったらスナップショットから戻す方針で作業を実施しました。
5分以内に完了しなかったので、ログが 1回分欠落しているけど許容範囲ということで。
終わってから気が付きましたが、項番4. の spine のインストールですが、make を完了し make install 待ちにしておくと時間短縮ができましたね... 項番5. のチェックで修正が入るとダメですけど。
---
2018/02/19 追記
自分の場合、監視する台数も少ないんで spine → cmd.php に切り替えて、アップデート後のんびりと spine を入れてあげればいいですね。焦らなくていいので、こちらの方法がベストかも。
---
作業時の画面ショットはこんな感じ。
4.アップグレード成功の画面に遷移
ダメだったら潔く(?)スナップショットから 1.1.28 の旧環境に戻す
5.ログを確認してみる
1回分ロスト、想定内
※14:40 の RRDsProcessed:60 になっているのは何だろう?
2018/02/04 追記
グラフの更新がうまくいっているので問題ないと思っていましたが、実は失敗していました...
2018/02/06 追記
問題無かったのかもしれません。ESXi のメモリーリークが原因でした。
2018/02/19 追記
↑ メモリーリークは NIC が接続できないには関連していましたが、cacti のバージョンアップとは無関係の模様。
アップグレード時に自分で
3.アップグレード確認の画面に遷移
注意書きを一通り読む
と書いておきながら、全然読んでいませんねぇ。Chrome使っているならキャッシュをクリアしろって書いてあるじゃないですか... 謎が解けました!
0 件のコメント:
コメントを投稿