前回開発会議の議事録に記載しました通り、明日 12月1日(火) 、開発会議を開催いたします。
開催要領は以下の通りです。
--------------------------------------------------------------------------------
■日時:2009年12月 1日(火) 14:00(午後2時) -
■場所: 名古屋大学情報基盤センター 4F 会議室 (演習室とは異なる部屋です)
交通: 名古屋市営地下鉄 名城線 名古屋大学駅 下車 2番出口
http://www.nagoya-u.ac.jp/global-info/access-map/higashiyama/ の 56番の建物
--------------------------------------------------------------------------------
■議題(予定)
1. NGMS Phase1 リリースチェック
(phase1 Releae (http://ticket.ngms.info/versions/show/1) に従ったチェック)
下記各開発項目について、達成状況、現状の課題・懸案事項確認。提案事項
- ネットワーク自動取得
- config自動生成
- Device Tree 操作基本API
- NGMS Shell
2. NGMS Phase2(仮) リリース項目検討
下記各開発項目について、達成目標、克服課題・解消懸案事項の確認
- ネットワーク自動取得
- config自動生成
- Device Tree 操作基本API
- NGMS Shell
3. 仕様検討状況
- Incident管理
4. その他
--------------------------------------------------------------------------------
以上、よろしくお願いいたします。
石川雅彦 masahiko[at]sra.co.jp Software Research Associates, Inc.
石川@とりまとめ担当です。
12月1日の開発会議は予定通り開催されました。(お疲れ様でした。 > 出席者のみなさま)
議事録を作成しました。以下に inline で添付します。
参照下さり、何かあればご連絡ください。
情報サイト (http://ngms.info/) には、これから掲載します。
こちらの方も合わせて参照いただければ幸いです。
次回開発会議は 12月17日(木) 15:00~(午後3時~) です。
よろしくお願いします。
石川雅彦 masahiko[at]sra.co.jp Software Research Associates, Inc.
---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム 開発会議(第7回) 議事録
---------------------------------------------------------------------------
■日時: 2009年12月01日(水) 14:00 - 17:00
■場所: 名古屋大学 情報基盤センター 4F 会議室
■出席:(敬称略)
- 名古屋大学 : 河口、山口、情報基盤センター職員
- とりまとめ担当: 石川、山本
- ITプランニング(以下"ITP")
- 鈴木裕信事務所(以下"SH")
- SRA [TV会議]
■資料
1. 議事次第 (資料1_NGMS開発会議-第7回-091201-議事次第.ppt)
2. インシデント管理:仕様案 (NGMS仕様案-6.インシデント管理-20091201-02.ppt)
3. インシデント管理:チケットタグ仕様案(インシデント管理-タグ仕様案.odt)
4. ネットワーク自動取得: 内部仕様案 (NGMS仕様案-4.ネットワーク自動取得-20091201.ppt)
(以上、情報サイト http://ngms.info/ に掲載)
■議題
1. NGMS Phase1 リリースチェック
2. NGMS Phase2(仮) リリース項目検討
3. 仕様検討状況
4. その他
5. 次回予定
■議事内容
注:(*xxx)は担当者、実行者を示す。(*ALL)は全体
●1. NGMS Phase1 リリースチェック
(phase1 Releae (http://ticket.ngms.info/versions/show/1) に従ったチェック)
下記各開発項目について、達成状況、現状の課題・懸案事項確認。提案事項
【ネットワーク自動取得】
- どういうAPIが必要であるか、洗い出しは進んでいるか?
->必要な機能がどのようなものかはITPさんに伝えている。
前回打合せにてAPIの仕様がある程度把握できたので、そちらを使ってオーソライズする
- 保存機能はない?
+ NMPathを利用して保存する機能を用意するという選択肢もあるが、それは使い方の問題ではないか
+ 便利なAPIをきるか、ラッピングするようなAPIを作るかを選択する必要がある。
- 取得したときに、IPアドレスの範囲をスキャンするか?
->使う側で取得したIPアドレスを絞り込むことはできるが、
オプション等で設定して取得するという作りには現状ではしていない
->それもNMWalkerで取得できるようにしたい
+ コマンドのインタフェースをどうするかにより作り方が変わる
+ 現状ではスタンドアローンで動いてもよいのでは?
- 現時点ではライブラリ的な作り方を進めているという認識でよいか?
->はい。プリミティブが用意されていれば、組み合わせていろいろ用途を広げることが出来るという趣旨
【ネットワーク監視用config 自動生成】
- 今回はあくまでnagios・Cactiから、監視対象を追加するための機能を実装している
ユーザが新しくNagiosに設定したい場合、それをデーモン化するかどうかは使う側の問題との認識(SRA)
- DeviceTree にユーザが情報追加する必要がある
+ Config 機能にはどこに何があってというのは自動的にはわからない
+ Device Tree に監視対象の情報があるという前提。例えば、TAGのような形で。
- 自動生成した Config と、手で作ったのを分けるという方法がある
+ 自動生成された Config と手作成の Config でファイルや置き場所のディレクトリを分ける案はどうか?
+ config ファイルは include が可能。
+ include で、設定が被る場合は先読み優先?後読み優先(オーバーライド)?
- サービスとして死活監視をする。
+ 例えば何を監視対象にするか、サーバだったらサービスを動いてなければいけないとか、
対象の機種とか役割とかで監視対象が違うと思われる。
今後はその辺りの Best Practice を集めていくのが課題
- 仕組みがシンプルな時点で、試行錯誤を進め抽象化された仕組みに変えてほしい
->今回(Phase1)は"function prototype"として実装した。
->今後、この実装を基にリファクタリングしていく。
- ソースコードを基に、クラス設計、リファクタリングについて議論。
+ cactiとNagiosで書き方が違う。
例えば、configへのwrite方法として、nagiosは、writeConfigであり、cactiはaddDeviceとなっている。
->今後、リファクタリングを行うことが課題と考えている。
+ 他のツールに対応する場合に、追加コードを最小単位で出来るようにしたい
- 部品化するのが scala の理由
- cacti は PHP が無いと動かないのか
-> PHP を使用しないと厳しい。nagios config がtext だが、 cacti は DBに書き込むので。
- 今後、様々な config自動生成に対応するが、新たな対応のための実装を楽にするために、知恵を出す必要がある。
+ 抽象化できること、できないことを整理してほしい
->了解
【Device Tree 操作基本API】および【NGMS Shell】
- ツリー構造そのものをファイルシステムに交換していく
+ それらの基本的な API について検討してサンプル実装を行っている
だいぶ出来たが足りないものがあるので拡充していく
- 特にファイルシステムの機能を優先してやっていく
+ Subversion ファイルシステムの開発も必要
- シェルの方の機能からの要請で複数のファイルを並べて実行する必要がある
- 状況報告(API)
+ mountのみ実行可能
+ create file 、 description は作成済
+ operation : 下位オペレーションを呼ぶだけなので可能
- 異なる実装形式を跨るコピー機能はまだできていない
+ まず読み出しと書き出しだけできれば、まずはSRA側で使えると思う
+ 不足機能・要望機能についてはSRA側でスタブを作っておく
●2. NGMS Phase2(仮) リリース項目検討
下記各開発項目について、達成目標、克服課題・解消懸案事項の確認
【ネットワーク自動取得】
- 機能要求としてはサブネット指定で出来ればそれ以上はあまり考えるところはない?
+ ブロードキャストしかサポートしてないような仕掛けがある場合は検討要
+ 現状、コンシューマデバイスとかプリンタは考えなくて良い
【ネットワーク監視用config 自動生成】
- 資料4. ネットワーク自動取得: 内部仕様案 (NGMS仕様案-4.ネットワーク自動取得-20091201.ppt)
を基に説明(とりまとめ担当)
(資料4中、NGMSソフトウェア構成図について)
- 意義、目的は?
+ 1. 現状の設計把握
+ 2. 今後の設計方向がわかる。
+ 3. 開発担当毎の作業境界を明確にしたい。
- 結論
+ 1. 現状の設計把握 ... 現時点ではソースコードは多くないので、コードレベルで把握でよい。
設計的にどうなっているのかFixされていない状態なので
現状、改修点の議論にはソースレベルで行うほうがいい
+ 2. 今後の設計方向 ... 今やらなければならないことを先ずクリアし、方向性議論はその後で行う
(内部設計案について)
- 追加した機器そのものについて管理者は知っているから、自動発見機能は要望の本質そのものではない。
欲しいデバイス情報を正確に取得することが大事
- 論理ネットワークより物理ネットワークを知りたい。
+ LLDPで考えられているはずなのでそれを利用したい
- VLANがちゃんとつながっているのも把握したいが、今回実装するのは厳しいため
今回は先ず、物理LANがどうつながってるか把握したい
●3. 仕様検討状況
【Incident管理】
- 必要なStatusの種類とStatusの遷移について
+ 今のチケット管理(ngms.info)にあるレベルの機能は可能にしたい
+ 先ずは一つ進む、戻るというレベルが可能であればOKではないか?
+ カテゴリによって状態遷移が変えられるような仕組みが必要
+ 状態遷移を行うまでの制約条件が必要
+ 状態遷移時に情報通知をするシステムが必要か
+ ポーリングに行くべきなのか、デザインチョイスが必要
- チケットツリーの構成について
+ チケットがたまっていくと、整理したくなる
+ チケットがフラットに存在したとしても、スマートフォルダ的なものがあればよい
* スマートフォルダもキャッシュがあるのでそこまで遅くない
- Status の遷移のユースケースについて議論
+ インシデントの種類分けについて
* ネットワークが遅いというチケットがあって、そこで新しい機材を購入するという提案になった場合、
そのチケットはインシデントというより運用ではないか?
* インシデントのチケットのフォルダと運用上のチケットのフォルダを分ければいいのでは?
* 緊急対応したので後で上げなければいけないというチケットもある
* 分類は変更可能
+ closeしたのに直ってない場合は?
* 起票者が問題を提起したんだから起票者がクローズすると思われる。
* 運用方法までここで検討するものではない
* 差し戻したときの履歴が残り、通知が滞りなく行えばよいのでは?
- インシデント管理の実装担当はどのチームか?
+ インシデント管理の実装担当を決める必要がある。
- どういうイベントケース・シナリオがあるのかを出す(* とりまとめ担当、SH)
- エスカレーションのデータ構造について
+ 人がこういうエスカレーションしてくださいという設定するために在るもの
* 階層構造がいらないというのではなく、集合構造としてのどういうエスカレーションをするかという定義は必要
* 具体的なイベントケース・シナリオをたたき台として、議論をしたほうが良い
+ シナリオを書くためのエスカレーション条件(例)
* 誰に通知するか、時間帯、スケジューリング、別テーブルに入ってないと駄目、など。
* どのくらいの時間チケットが更新されないとエスカレーションするか?という条件:15分なのか、10分なのか
* 優先度が高いものはすぐにエスカレーションされる、など
* 発生時刻によって、エスカレーション先が異なる。(9:00-5:00PMの間のエスカレーションとそれ以外の場合、など)
●4. その他
- 課題管理(ngms.info)について
+ メンバーはコーディングの状態なので使われないのは仕方が無い
+ とりまとめ担当で、課題管理のページをコントロールする(* とりまとめ担当)
- ファイルのIDについて
+ どこかに何か置けと指示されてない場合には必要
+ NMWalkerのインスタンスを使う際、ためるべきパスが定義されているか、
返す機能が用意されているのであればIDは不要ではないか
->検索時:ディレクトリ上を検索し、descriptionの実体をnetwalkerに渡す。
->保存時:実体だけ渡し、ディレクトリ上のファイルを探し保存させる
- DeviceTreeを利用する側とAPIを提供する側の作業境界について
+ DeviceTreeAPI利用側も、DeviceTreeの構造や操作の実装を知ったうえで、実装して欲しい
+ DeviceTreeへの要望機能については、トラバースした実装をサンプルとして示す(* SRA)
- 今後の打ち合わせについて
+ 開発担当チーム(SRA, ITP,etc)でショートディスカッションを頻繁に進めてほしい。
* 開発会議よりも細かい頻度で。Skype などを使用して。
* 議事録を残す前提でショートディスカッションを頻繁に行っていく
●5. 次回予定
* 次回開催日時: 2009年12月17日(木) 15:00~(午後3時~)
場所: 名古屋大学情報基盤センター4F会議室
---
環境: CentOS release 5.3 (Final)
必要な package - package名
Apache httpd - httpd
PHP - php
GCC - gcc glibc glibc-common
GD liblary - gd gd-devel
MySQL - mysql mysql-server
Net-SNMP - net-snmp
他にも必要かもしれません。(ここには開発環境などもインストールしました)
インストールされていなければ yum でインストールします。
# yum install httpd php
# yum install gcc glibc glibc-common
# yum install gd gd-devel
# yum install mysql mysql-server
# yum install net-snmp
CGI を使う関係上 SELinix の設定を enforce から permissive にする必要が
あるようですので、/etc/selinux/config を変更します。
SELINUX=permissive
reboot をするか、/usr/sbin/setenforce 0 を実行します。
Nagios: Nagios Version 3.2.0
パッケージ内の html/docs/quickstart-fedora.html が参考になります。
以下インストール時のメモです。/usr/local/nagios にインストールされます。
1. ファイルの展開
# tar xzvf nagios-3.2.0.tar.gz
# cd nagios-3.2.0
2. configure
# ./configure
3. make
# make all
4. install
# make install
# make install-init
# make install-config
# make install-commandmode
# vi /usr/local/nagios/etc/objects/contact.cfg
contact 用の mail address 変更
変なところに mail を飛ばさないように変更しておきます。
# make install-webconf
5. plugin
# cd ..
# tar xzvf nagios-plugins-1.4.14.tar.gz
# cd nagios-plugins-1.4.14
# ./configure
# make
# make install
6.
# chkconfig --add nagios
# chkconfig nagios on
7.config
localhost はインストール時に設定されている
localhost の Web server はこの時点では Nagios 専用で、http://localhost/
ではエラーになります。このため、http check が問題になったため、
$NAGIOS/etc/objects/localhost.cfg の check_http に
-u /error/noindex.html を option として設定
...
check_command check_http!-u /error/noindex.html
...
$NAGIOS/etc/NGMS に config file を設定。$NAGIOS/etc/nagios.cfg に
cfg_dir=/usr/local/nagios/etc/NGMS
を追加。ここに自動設定用のテンプレートファイルを置いておく。
ユーザ nagios と グループ nagios が設定されていることを確認する。
グループ nagios のメンバに apache が含まれていること。
8. ユーザの作成
htpasswd を使用して管理用のユーザを登録します。
# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Basic 認証なので、/etc/shadow などに DES や MD5 で encrypt された
パスワードがあればそれを使用することもできます。
9. アクセス制限
Allow from all になっているので、必要であれば
/etc/httpd/config.d/nagios.conf を変更します。変更した場合は reload
します。
10. nagios の起動
# /sbin/service nagios start
11. nagios の使用
http://localhost/nagios/
にアクセスします。
------
Cacti: cacti-0.8.7e
RRDTool のインストール
default の prefix が /opt/rrdtool-1.4.1 のようなので、/usr/local/rrdtool
に変更しました。
1. ソースの展開
# tar xzvf rrdtool-1.4.1.tar.gz
# cd rrdtool-1.4.1
2. configure
# ./configure --prefix=/usr/local/rrdtool
3. make
# make
4. install
# make install
Cacti のインストール
/usr/local/cacti-0.8.7e に展開しました。
1. distribution の展開
# cd /usr/local
# tar xzvf cacti-0.8.7e.tar.gz
# ln -s cacti-0.8.7e cacti
# cd cacti
2. patch
patch は追加、変更されることがあります。最新の状態にしてください。
# patch -p1 < cli_add_graph.patch
# patch -p1 < snmp_invalid_response.patch
# patch -p1 < template_duplication.patch
# patch -p1 < fix_icmp_on_windows_iis_servers.patch
3. database の作成
mysql を新規に install した場合は、root の パスワードを付けます。
# mysqladmin -u root password <password>
# mysqladmin -u root --password reload
# mysqladmin -u root -p create cacti
# mysql -p cacti < cacti.sql
4. database 操作用のユーザの作成
useradd などで、cacti 用のユーザを作成しておく。
# mysql -p cacti
mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY 'password';
mysql> flush privileges;
mysql> exit
ここの password は cactiuser の DB パスワードです。
5. config の変更
include/config.php を変更
$database_type = "mysql";
$database_default = "cacti";
$database_hostname = "localhost";
$database_username = "cactiuser";
$database_password = "password";
4 で設定したパスワードと同じものを config.php に設定します。
# chown -R cactiuser log rra
crontab に設定
# crontab -u cactiuser -e
*/5 * * * * php $CACTI_DIR/poller.php > /dev/null 2>&1
6. httpd の設定
/etc/httpd/conf.d/cacti.conf
<Directory "/usr/local/cacti">
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Directory>
Alias /cacti "/usr/local/cacti"
アクセス制限は適切に設定してください。
httpd の config を reload します。
# /sbin/service httpd reload
7. configure
Web ブラウザで http://localhost/cacti/ にアクセスします。
rrdtool のパスを変更する必要がありますので、/usr/local/bin/rrdtool を
/usr/local/rrdtool/bin/rrdtool に変更します。
Finish するとユーザとパスワードを聞かれますので、ユーザ名 admin
パスワード admin を使用します。認証が終わるとパスワードの変更を
求められますので、変更します。
On: Thu, 03 Dec 2009 17:59:31 +0900
Tatsuro Nakamura <tat...@sra.co.jp> said:
> Nagios: Nagios Version 3.2.0
> パッケージ内の html/docs/quickstart-fedora.html が参考になります。
>
> 以下インストール時のメモです。/usr/local/nagios にインストールされます。
Nagios でも RRDtool を使ってのグラフ表示が可能です。その際には pnp 関
連のものがが必要となるはずで、こちらでは以下のようにしています。
1) pnp-0.4.14.tar.gz とって来る
2) centOS で以下の (3) のオペレーションを実行($NAGIOS は ngios を作成
した directory です。もとの mail の
> 1. ファイルの展開
> # tar xzvf nagios-3.2.0.tar.gz
> # cd nagios-3.2.0
の所ですね、きっと。
3) operations
# yum install php-gd
# cd $NAGIOS
# tar zxvf pnp-0.4.14.tar.gz
# cd $NAGIOS/pnp-0.4.14
# ./configure
# make all
# make install
> 7.config
> localhost はインストール時に設定されている
> localhost の Web server はこの時点では Nagios 専用で、http://localhost/
> ではエラーになります。このため、http check が問題になったため、
> $NAGIOS/etc/objects/localhost.cfg の check_http に
> -u /error/noindex.html を option として設定
> ...
> check_command check_http!-u /error/noindex.html
> ...
check_http は、その他にも 401 を正常と見るとか、https で判断するとか、
もできます。こんなものをこちらでは用意しています。
define command {
command_name check_http_basic
command_line $USER1$/check_http -I $HOSTADDRESS$ -e 401
}
define command {
command_name check_https
command_line $USER1$/check_http -S -I $HOSTADDRESS$ $ARG1$
}
> 10. nagios の起動
> # /sbin/service nagios start
その前に、
alias verify-nagios='/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg'
などを用意して、config の修正を verify するのが吉かと。
-- hisasima