2018年10月13日(土) - 14:58 | カテゴリ:
Linux
自鯖の”ns-lab BB”の全サーバ＆全NW機器は、メイン監視としてzabbixを利用している。
先日、Zabbix 4.0がリリースとなった事を知った為、自鯖の監視システムも4.0にアップグレードしてみた。
実際に使っているzabbixの画面。画面を確認する為にわざとエラーを出してみた。
アップグレードしたのは先週なので1週間は継続利用している状況。
特に問題は発生しておらず、普通に使う事が出来ている。
また、4.0にアップグレードするにあたり、VPSに構築しているZabbix Proxyと、
全サーバのZabbix Agentもアップグレードを実施した。
初回アップグレード時のみ、データを蓄積するMySQLの最適化が走るのが通例だが、
毎度の如くコレが一番時間かかった。
環境にもよると思うが、目安として2GBのDBを最適化するのに5分必要だった。
………
細かい所を見ると色々変わっているのだが、3.4系と4.0系で大きく変わったのが次の2点。
- グラフ表示時のタイムバーが選択式に変更
- トリガー条件式の作成画面が整理された
今まではタイムバーだった所が選択式に変更された。
コレに伴い、グラフ表示時の処理が効率化され早く表示出来るようになったらしい。
最初は『タイムバー便利だったのに(´・ω・｀)』と残念に思っていたのだが、
結局使うのは「最新の1日間」ぐらいしか無いので、慣れの問題だと思う。
トリガー条件式については、内容が整理されて設定をつくりやすくなった。
今まではカテゴリーで分別されていた物が、関数として組める様になったのと、
最新トリガー・実行結果を想定しながら組み込めるのはありがたかった。
………
まだ出たばかりのバージョンではあるが、余程細かい事をやっていなければ、
Zabbix 4.0に上げる事をオススメする。
何より、グラフ表示時の動作が軽くなる事だけでもアップグレードをする価値がある。
また、Zabbix 4.0ではPrometheusのエージェントから直接監視データを受け付ける事も出来るらしい。
“ns-lab BB”でPrometheusを運用していないのでテスト出来ないが、
どの程度の事が興味あるので少しずつ調査しようと思う。
« 続きを隠す
2018年09月17日(月) - 19:23 | カテゴリ:
Linux
夏前からルータやら仮想鯖ホスト1・3号機は掃除していたのだが、
仮想鯖ホスト2号機だけ手つかずの状態だった。
『連休最後の日、暇だから掃除するか～』と思いながら仮想ゲストサーバを落としていた所、
偶然にもNICがリアルタイムでご臨終し、ホスト機自体がKernelPanicになって再起動した…
という事で、スペアで確保していた4ポートNICに交換した。
今回壊れたNICがコチラ。ちなみに、換装したスペアNICも同型番を利用。
自鯖ホスト2号機を構築してから今まで、24h/365dでデータを転送し続けてくれた事に感謝。
大容量データをLAN内送受信にも使っていたので、10TB以上はデータ転送している筈。
余談だが今回のスペアNICは、仮想鯖ホスト1号機のNICが故障した際に追加購入していた物。
1号機のNICがご臨終した時、権威DNSサーバが操作できなかったり、
メール配送に支障が出たので『NICのスペアを確保しとくか』と取っておいて良かった (｀・ω・´)
壊れた状況としては、NICのLEDでは正常にLinkUPしているのだが、
OSからは何をやってもデバイスが見れない状態になった。
本職のIT屋ならもう少し切り分けしつつ故障箇所を特定するが、
今回は状況からNIC故障が濃厚だったので、緊急で自鯖のNIC交換に踏み切った。
結果、ホスト鯖を起動させたら交換したNICで普通に起動。
MACアドレスとKVMゲスト用の仮想NIC(ブリッジ)紐付けをやり直し、
3時間程でサーバを復旧させる事が出来た。
………
普通の家庭ならスペアNICは持っていないだろうが、
曲がりなりにも自鯖管理している「逸般の誤家庭」なので持っといて良かった。
ただ、これでスペアNICが無くなってしまったので買っておかなければ。
今まで、ドライバと使い安さでIntel PRO/1000VT(OEM版)を買っていたが、
近頃は新品NICも安くなってきたので、新品購入するのも良いかもしれない。
その辺りは秋葉原を彷徨きつつ良い物が無いか探してから考えようと思う。
« 続きを隠す
2018年09月15日(土) - 23:02 | カテゴリ:
Linux
前回軽く書いていたHDDのクラッシュ修復。
色々と頑張ったが、待避させた時には手遅れだったのか救出不可能だった。
という事で、何をやったがダメだったのか備忘録。
ちなみに、今回お亡くなりになったのはコチラのHDD。
本来はデスクトップ用な物を自鯖で24h/365d稼働させていた事もあり、
約3年でクラッシュした。
- データコピー
定説通り、適当な余りHDDにddやらddrescueでデータコピーを実行。
…しようとしたら、そもそもコピーする段階でエラーが発生して読込み出来なかった。
流石に、ハードウェアコピーする機械は所持していないので、
今回は仕方なくデータ救えなくなる事を覚悟で元HDDでデータ救出を実行。
- fsckでFS修復
定説通りにfsckを実行。
今回のHDDはext4だったので、途中まで普通に走ったが、
ddでエラー出た辺りのブロックでエラー再発したので停止。
- 復旧天使の実行
物は試しと復旧天使を実行してみた所、一部のデータは0バイト状態で見えた。
ただ、0バイトなのでファイルの残骸しか残っておらず断念。
- 再度、fsck実行
ここまで来たら復旧は諦めて、fsckをエラー吐かせつつ全領域実行してみた。
2TBを実行するのに丸3日掛かったが、最終的には完走。
ただ、やはりファイルは復元出来なかった。
………
最終的には復旧出来なかったが、それなりに技術調査しながらやっていたので楽しかった。
まず、復旧させる時は真っ先にread-onlyでマウントするのが定石だが、
ハードウェアレベルで故障している場合は、そもそもマウント自体がアウトだった。
あと、先にfsckを実行したが真っ先に修復アプリに頼るのも一つの手かもしれない。
今回はext4だったが、xfsだとまた変わるのかもしれない。
xfsはfsckの代わりにxfs_repairコマンドになったが、
ダーティログを持つFSを修復出来なかったりするが、
天下のredhat様が色々とドキュメントを公開しているので、ある程度までは対応出来る。
そもそも、バックアップ取得しておくのが最良だが、
稀に復旧チャレンジする場面があるので、憶えておこうと思う。
« 続きを隠す
