PandoraFMS を使ってみた

System Consulting & Sales Division の荒川です

先日、社内勉強会にて「PandoraFMS」を発表させていただきました。 発表内容のダイジェストをこちらのHDEブログに書いて欲しいという依頼を頂きましたので ありがたく書かせていただきます。

pandoraFMS とは？

PandoraFMS とは、スペインで開発されているオープンソースの監視ツールになります。 オープンソースの監視ツールとしては、Naigos や Cacti 、 Zabbix などが有名ですが、 PandoraFMS はどちらかというとマイナーな部類になると思います。

（結構知られていると思ったのですが、社内勉強会では、「どこで見つけてきたの？」 的な質問が多く寄せられたので、マイナーな部類だと感じました）

また、PandoraFMS はエンタープライズ版（有償）もあり、こちらは使える機能が増えており、 サポート対応もしてくれます。

詳しい違いは、PandoraFMS のホームページにまとめられています。

http://pandorafms.com/Soporte/pricing/jp

なぜ PandoraFMS か

では何故 PandoraFMS を使ってみようと思ったのでしょうか？ 監視ツールとしては、Naigos と Cacti を利用してきたのですが、監視の運用負荷を 減らしたい！と思ったことが理由です。

監視の運用負荷

1) システム監視とリソース監視が別システム。

Naigos には、リソース状況を分かりやすくグラフ表示してくれる機能が無い為、 システム監視は Nagios 、リソース監視は、Cacti と2つのシステムを使っています。

Cacti のグラフは見やすく使い易いのですが、新環境の監視を設定する時など、 2つのシステムに設定を行うので面倒だと感じていました。

PandoraFMS では、システム監視とリソース監視が1つのシステムで実現できます。 リソース状況の表示も Cacti と同じようにグラフで見やすく使い易いです。

2) そもそも手動で設定したくない。

社内のシステムなど、様々なソフトウェアが動作している環境では、サーバ単位に手動で 監視を設定するしかありません。

しかし、弊社の様にサービスを提供する場合、動作するソフトウェアや導入する監視項目は、 固定できます。監視の導入を自動化することで、工数の削減だけではなく人為的なミスも 防ぐことが出来ます。

PandoraFMS のシステム監視（ネットワーク監視を除く）は、サーバから Push する方式なので、 サーバ構築時に サーバ側に PandoraFMS agent のインストールと設定ファイルを設置すれば 自動で監視が開始されます。

サーバの構築に chef 等の自動化ツールを使用することで、構築から監視までの自動化が 可能になります。

3) GUI による管理が便利

Nagios の設定はテンプレートに汎用的な定義を作成し、それを継承する方法で 行いますが、設定ファイルではどのサーバがどのテンプレートを継承しているかが 分かりにくいと感じていました。

PandoraFMS では、管理GUIで通知先などの設定が可能なため、継承関係が分かりやすく、 簡単に設定変更が行えます。

まとめ

以上、PandoraFMS について少しは理解を深めていただけましたでしょうか？

PandoraFMS は API が豊富なため、オープンソースでも使い方次第では、 必要な監視を網羅できると考えています。

はじめての障害演習

どうもこんにちは。 Account Management Section の服部／安孫子がお送りします。

みなさんは自社が提供しているサービスに障害が起きた場合の備えは万全ですか？ 特に大規模な障害が起きてしまった場合、構築している体制で迅速な対応ができますか？

今回は、弊社内で実施した HDE Oneサービスの障害対応演習について企画者の一人として書いてみたいと思います。

演習実施に至った背景

過去に発生したHDE One サービスにおける障害発生を機に、再発防止のシステム改善と強化だけではなく、社内オペレーションの見直しと障害のケーススタディを行い、対応の練度をあげる必要性が社内で議論されていました。

また、障害発生後にご契約いただいているお客様を対象としたアンケート結果からも、「情報公開」「連絡頻度」「対応スピード」について多くのご意見をいただきました。 そこで社内にプロジェクトチームを立ち上げ、取り組みの第一弾として障害対応演習を実施することになりました。

目的の再確認

第一回である今回は、演習用のクラウド環境などは準備せず、障害発生時の人のオペレーションと課題抽出、コミュニケーション強化をテーマとしました。 訓練も机上演習ながら長い時間を使って演習を行う都合上、週末に実施することに決定しました。

初期の議論のホワイトボード

企画：真面目さと遊びココロのバランス

目的はきっとメンバーにも理解してもらえるでしょう。

でもお題目として理解してもらっても意味はない。

参加メンバー全員が当事者意識と危機感をもって参加してくれなければ、わざわざ週末にまで出社して演習をやることはないと考えていました。 そこで、まじめにやる部分と楽しんでもらう部分のバランスに心を砕きました。

大まかな構成は以下の３部構成。 ①レクリエーション ②ディスカッション ③障害演習

実は、一番早くディテイルが決まったのが①の部分です。内容は「人狼村からの脱出」というリアル脱出ゲームを開催しました。

障害対応のポイントは何度も議論を尽くしたのですが、対応のリーダーシップと役割分担、社内での円滑なコミュニケーションなどのポイントが上がりました。 このゲームは挙がってきたポイントをほぼ全て押さえられるものと判断し、企画のメンバーでテストプレイをしてみて実施を決定しました。

以下、演習当日のハイライトをお送りします。

実際の演習の様子

演習開始：

午前の部：チームビルディング(人狼村からの脱出)

実際のプレイでは、写真のように準備された資料を解いていく事で人狼を突き止め、人狼村から脱出することがゴールです。

午前の部：ディスカッション 過去の経験から改めて障害対応で何が大切になるのか、各メンバーから意見を出してもらい、発表してもらいました。

午後の部：障害演習

プロジェクトチームが用意したケーススタディを元に、4チームに分かれて割り振られた障害に対しに最適な行動を決定し、質疑応答のなかでさらに議論を深めていきました。

刻一刻と変化していく状況にどう対応すべきか議論していく中で、チームが取り組んでいくべき課題がいくつも見つかったことが大きな成果でした。

想定した障害の中には HDE One サービス全体がそもそもダウンしたらどうするか、障害発生時の状況の中には対応すべきメンバーが全員対応不能な状況になっているなど想像するのも恐ろしいものも含まれていました。

午後の部：ディスカッション

第一回の演習で得た気付きは以下の通りです。
- 障害とは何か、障害対応とは何か、当事者間での意識統一の重要性

- 迅速かつ確実な対応を両立させる体制構築の重要性

- 演習の定期実施の必要性

- 社内全体を巻き込んだ情報共有や訓練実施の検討

メンバー全員が高い当事者意識を持ち、お客様に満足いただけるサービスとは何か、という点を真剣に議論する姿が印象的でした。 今後の演習ではクラウド上構築した演習環境を使っての演習実施を計画しています。

最後は打ち上げ、みなさんお疲れ様でした！

偶然にもこの日は、我らがセクションのボスでもある副社長宮本がもうすぐ誕生日でしたのでお祝いをしました！

ボスとケーキ：

HDE では弊社サービスを安心してご利用いただけるよう、チーム一丸となってお客様をサポートして参ります。今後も弊社の取り組みを本ブログにて皆様に公開して参りますので何卒宜しくお願いします。

以上です。