OSCFUKUOKA

Copyright © 2014 TIS Inc. All rights reserved.
OSC福岡2015
OSS推進室
古矢俊輔
2015年10月3日
実録！Hinemos導入経験者が語る、
実運用でのあるある話

Copyright © 2014 TIS Inc. All rights reserved. 2
本講演の内容は、TISの実績・見解によるものです。
Hinemos4.1.3以前のバージョンをベースとしたお話しになりますが、
Hinemos5.0ではいくつか改善されているものもあります。
はじめに

自己紹介
3分
古矢俊輔（ふるやしゅんすけ）
TIS OSS推進室
・ 2013年入社
やってたこと
・ ECサイトのシステム運用保守（インフラ部分）
・ネットワーク構築
・仮想化基盤構築
・ Hinemos構築（もうすぐHinemos歴1年）
・ OSS運用管理ツールの保守サポート

Hinemosとは
NTTデータ製のOSS統合運用管理ツールです。
監視もジョブも物理も仮想もクラウドもNW機器もまとめて管理！
5月に最新版バージョン5.0がリリース！
クラウド
仮想環境
物理
NW機器
監視
ジョブ
他にもいろ
いろ

TISのHinemosの取り組み
20Job
1台
10台
50台
30台
5台
金融・産業・公共など、幅広い業界のお客様への
Hinemos導入・運用・サポート実績！
50Job
100Job
300Job
100+台
3000+
Job
数台～数十台/10～300ジョブから 100台超/3000ジョブ超まで！

本日のテーマ
設計テクニック
①監視静観の方法は最初に決める!!
②オーナーロールは重要!!
運用してみて困ったこと
①監視の画面がごちゃごちゃ
②ジョブ画面の表示が遅い
③リソース監視で「不明」がでる
Utilityで効率化
①Utilityは工夫が必要!!
②Utilityは危険!!
③失敗を踏まえ今では!!

設計テクニック①
監視静観の方法は最初に決める!!

監視静観とは？
監視静観の方法は最初に決める！
メンテナンス作業
サーバ稼動
00:00
サーバ停止サーバ稼動
01:00 02:00 03:00 04:00
監視中静観監視中
メンテナンス時に監視を止めることをTISでは監視静観とよぶ

なぜ監視静観の方法を最初に決めるべきなのか？
静観の要件次第で、全体の構成が大きく変わるため
APスコープ
●●監視
●●監視
●●監視
××監視
▲▲監視
××監視
▲▲監視
通知
通知A
通知B
監視対象の構成通知の構成例

監視静観の方法は？
方法は大きく分けて4つ
①管理対象から除外
②監視の無効化
③通知の無効化
④カレンダ非稼働
方法スケジューリング監視対象の選択静観中のジョブ実行静観終了後の通知
① 管理対象から除外
② 監視の無効化
③ 通知の無効化
④ カレンダ非稼動
③①
ノード
ノード
ノード
ノード
スコープ
監視
監視
監視
監視
カレンダ
通知
通知
④
△は構成に依存するもの
カレンダ
②

静観の注意点

①管理対象から外す場合はその間ジョブが実行できない
ノード単位でピンポイントに監視を無効化できるというメリットがありますが、管理対
象外のノードはジョブも実行できなくなる
つまり、
・監視を止めて、ジョブでサービス再起動する
などができません。
注意点その1

注意点その2
②監視の無効化と ③通知の無効化は静観終了後に通知がとぶ
ステータス監視は（死活、リソース、プロセスなど）復旧も通知するのが普通ですが、
監視や通知の無効化は、静観終了時に有効にすると、設定している数だけ有効
化直後の初回検知がされます。
正常危険正常
無効化有効化
お休みのところスイマセン！

Hinemos最新版5.0の通知は「有効にした直後は通知しない」という設定が追
加されました！！
これ
正常危険正常
無効化有効化
この設定にチェックをいれれば、、
安心してください！
メール来ません！

実際どれだけ構成が変わるのか

監視の要件
・ノード4台それぞれに3種類の監視を実装する
・ジョブはなし
ノード
ノード
監視
監視
監視
通知
通知
スコープ
ノード
ノード
静観のことを抜きに一番シンプルな構成にした場合
しかし、ここで静観の要件がでてきた…

静観の要件
1. 静観する時間を予約できるようにしたい
2. ノード単位で監視を静観したい
もともと設計していた構成から静観の方法を考えると…
ノード
ノード
監視
監視
監視
通知
通知
スコープ
ノード
ノード
この構成では
どの方法を使っても
静観の要件を満たせない

ノード監視
監視
監視
通知
通知
カレンダ監視
監視
監視
ノード
監視
監視
監視
カレンダ
監視
監視
監視
カレンダ
カレンダノード
ノード
監視要件と静観要件を満たすためには
構成を変更しなければならない

・スコープ、監視設定、通知などを一通り決めたあとで考えると
静観の要件を満たせない場合がある
⇒設計からやり直しということもあり得る
・それぞれの静観方法の特徴を把握した上で
監視静観は、はじめから考えるのがオススメ！！

設計テクニック②
オーナーロールは重要！！

オーナーロールとは？
オーナーロールは重要！
・Hinemosの全ての設定に定義する
・オーナーロールでユーザのアクセス制御をする
●●監視(部署A)
●●ジョブ(部署A)
××監視(部署B)
B_ROLE
××ジョブ(部署B)
B_ROLE
A_ROLE
A_ROLE
A_ROLE
B_ROLE
●●監視(部署A)
●●ジョブ(部署A)
××監視(部署B)
ALL_USERS
××ジョブ(部署B)
ALL_USERS
ALL_USERS
ALL_USERS
ALL_USERS
ALL_USERS
部署Aユーザ
部署Bユーザ
部署Aユーザ
部署Bユーザ
ALL_USERS（デフォルト）オーナーロールでのアクセス制御

オーナーロールが重要な理由って？
・各設定は同じオーナーロール同士しか紐付できない
・デフォルトのALL_USERSを使うと制限がかからない
・オーナーロールは後で変更できない
(ユーザへのロール割当は自由に変更可)
●●監視
●●ジョブ
××監視
B_ROLE
××ジョブ
B_ROLE
A_ROLE
A_ROLE
ノードA
A_ROLE
ノードB
B_ROLE
メール通知A
A_ROLE
メール通知B
B_ROLE

Copyright © 2014 TIS Inc. All rights reserved.
実例紹介
23
ノードのオーナーロール変更
対象ノード：10台
影響範囲は想像以上に大きい!!
オーナーロールの変更がどれだけ大変なのか？

ノードA-04
ノードB-01
部署Aユーザ
ノードA-03
ノードA-01
ノードB-02
部署ごとに管理するノードが異なるため、部署単位でオーナーロールを設定
部署Bユーザ
ノードA-02
ノードB-03
ノードB-04
部署A
部署B
A-B_ROLE
A_ROLE
A-B_ROLE
A_ROLE
B_ROLE
A-B_ROLE
B_ROLE
初期構築時
運用開始後のお客様からの要望
部署A、Bの一部サーバについてはどちらの部署のユーザでも管理したい

監視の観点で見た設定変更箇所
監視
メール通知
カレンダカレンダパターン
ジョブの観点で見た設定変更箇所
ジョブネットジョブ
ジョブ
ジョブメール通知メールテンプレート
カレンダカレンダパターンジョブユニット
1監視あたり(設定数:7)
通知 × 3
メールテンプレート x 1
カレンダ × 1
カレンダパターン × 1
1ジョブユニットあたり(設定数:16)
実行契機 x 1
ジョブネット x 1
カレンダ × 1
カレンダパターン × 1
ジョブ × 5
通知 x 3
メールテンプレート x 3
ジョブ
ジョブ
実行契機
メール通知メールテンプレート
メール通知メールテンプレート
イベント通知
ステータス通知
メールテンプレート

ノード1台だけで・・・
ノードごとに必要となる設定
監視×6
ジョブユニット×5

なんと再設定数1000オーバー！！！
（7×6監視 + 16×5ジョブユニット)×10ノード
ノード10台になると・・・

・オーナーロール(アクセス制御)は
後戻りできないので最初に考える！！
・要件がなくても後で絶対でないとは言えない
⇒ALL_USERSは使わない

運用してみて困ったこと①
監視の画面がごちゃごちゃ！
～3つも必要か？～

過去のイベントを確認済にしない限り
重要度「危険」が表示される
・リアルタイムでの監視状態を
確認する上で混乱を招きやすい
・イベントを確認済にするのは
手間になる
・スコープ画面は非表示
・ステータス画面で全サーバの監視状態を
確認できるようにする
・イベント画面に出力されたものは
未確認のまま
スコープ画面(一番上)は使わないケースが多い

Hinemos5.0では監視履歴画面上に
デフォルトでスコープ画面が表示されなくなった

運用してみて困ったこと②
ジョブ画面の表示が遅い！
～何分待たせるんだい？～

ジョブの数が増えれば増えるほど
ジョブ設定の一覧画面を表示するのに時間がかかってしまう
3000ジョブくらいになると数分またなきゃいけないなんてことも！！
さらに!!
ジョブ履歴を表示させる際においても
ジョブのパースペクティブを開く必要があり、ジョブ[一覧]ビューもセットで読み込ま
れるため同様に時間がかかってしまう
障害対応の時にそんなに待ってられない！！

ジョブユニットA-01
オーナーロールID：A-SYSTEM
ジョブユニットB-01
オーナーロールID：B-SYSTEM
Aユーザ
A-SYSTEMロールを割り当て
Bユーザ
B-SYSTEMロールを割り当て
管理者
Administratorsロールを割り当て
ジョブユニットA-02
オーナーロールID：A-SYSTEM
ジョブユニットB-02
オーナーロールID：B-SYSTEM
必要最低限のジョブだけを表示！！
・何でもかんでも管理者ユーザを使わない
⇒オペレーションミス削減にもつながる
(ジョブ一覧画面にはフィルター機能がない)
①ジョブ一覧画面を表示する際のポイント

②ジョブ履歴を表示する際のポイント
ジョブ一覧は無駄に表示させない！！
・ジョブ[履歴]の確認用にパースペクティブをカスタマイズする

Hinemos5.0では
①ジョブの表示速度が向上！！
②ジョブ設定画面とジョブ履歴画面のパースペクティブが
デフォルトで別々になった！！

運用してみて困ったこと③
リソース監視で「不明」がでる！!
～意外とあるあるなんだよね～

監視の仕組み
リソース監視
SNMPを使用したポーリングにより管理対象ノードのリソース値を取得する
監視のタイミングで、マネージャからノードへSNMPのリクエストを送信する
SNMPリクエスト
レスポンス
Hinemosマネージャ管理対象ノード

深夜の時間帯に、ファイルサーバに対する
リソース(ディスク使用率)監視が「不明」になるときがある
サーバ側のログ等を確認するが、
・特に問題となるような事象は発生していない
・ SNMPのプロセスは落ちてない
Hinemosマネージャ
がおかしいんじゃな
いの？
エージェントが落ちて
たからリソース監視が
失敗したんだ！
事象(実例)

他サーバからファイルサーバに対して
データコピー処理が行われていたことが判明！！
⇒ 監視対象サーバ側に一時的な負荷がかかっていたことで
リクエストがタイムアウトし、リソース値を取得できなかった
監視の仕組み上、リソース監視で値を取得できなくなることは
環境によっては起こり得ること
原因
その都度通知は飛ば
してほしくないなー

監視の判定ポリシーを緩くする
対応
時間
監視結果
before
after
時間
1
2
監視結果

時間
監視結果
ただし、重要度「不明」以外の検知ポリシーも緩くなってしまう
というデメリットもある
after
1
2
before
時間
監視結果

特定の時間帯(02:00-03:00)のみ監視で検知するタイミングを緩くする
2つの監視設定を使用する
監視設定A - 通知：重要度に変更があった1回目で通知
- カレンダ：2:00-3:00 非稼働
監視設定B - 通知：同じ重要度の監視結果が3回連続した場合に通知
- カレンダ：2:00-3:00 のみ稼働
1回で検知
00:00
3回で検知 1回で検知
01:00 02:00 03:00 04:00
このような対応もある！！

Utilityで効率化
~Utilityは工夫が必要!!~

以下の機能を提供するHinemosのオプションツール
・エンタープライズMIBの登録
・設定の一括エクスポート/インポート
・差分比較
同梱ExcelシートHinemosマネージャ xmlファイル
時間大幅減+ミスもなくなる
Utilityとは
Utilityは工夫が必要!!

しかし、
工夫しないとなかなか効率化できない

同梱のExcelシート ≠ 設計書
なぜ工夫が必要なのか？
ジョブだけでも・・・
ジョブデータ
変数
待ち条件
通知

設計書に記載した設定を、Hinemosに投入しようとすると・・・
設計書
同梱Excelシート
xmlファイル
Hinemos
なぜ工夫が必要なのか？

対応策
同梱フォーマットの項目に準じた設計書を使用する

さらにTISでは・・・

インポートデータの作成を簡略化し、設定導入の時間を大幅に削減している。
設計書
Utilityジェネレータ
同梱Excelシート
xmlファイル
設計書
xmlファイル
実質
Utilityジェネレータを使用!!
対応策

Utilityで効率化
~Utilityは危険!!~

やってしまったエピソード①
Utilityは危険!!

事象
ジョブユニットの中に、新たにジョブの追加を行う要件があった
対象のジョブユニットが多かったこともありUtilityを使用し、
追加データをインポートした
ジョブユニットA
ジョブ１
ジョブ２
ジョブ３
ジョブ1
ジョブ2
ジョブ3
ジョブ4
ジョブ4
Hinemos Hinemosインポートデータ
＝＋
こうなる予定だった
Utilityは危険!!

ところが… 我々が目にしたものは！！
Utilityは危険!!

もともと入っていた設定データがなくなってしまった！！
ジョブ１
ジョブ２
ジョブ３
ジョブ4
Hinemos インポートデータ
＝＋
実際はこうなった
ジョブ4
Hinemos
Utilityの注意点
・同一IDのインポートは設定の入れ直しと同等
・インポートデータに無いものは消える
Utilityは危険!!

やってしまったエピソード②
Utilityは危険!!

事象
リソース監視の設定を30個追加し、
動作確認のため一時的に監視間隔を5分から全て1分に変更した
試験後、元の監視間隔に戻す必要があった
そこで、設定追加直後にエクスポートしたリソース監視データの状態に戻すことに！！
こうなる予定
監視A（1分）
監視B（1分）
監視C
監視D
監視E
監視A(5分)
監視B(5分)
Hinemos Hinemos
作業前に取得した
監視データ
監視A（5分）
監視B（5分）
監視C
監視D
＝＋
Utilityは危険!!

ところが… 我々が目にしたものは！！
Utilityは危険!!

メールが大量に通知された
事件起こる
Utilityは危険!!

実際はこうなった
監視A(1分)
監視B(1分)
監視C
監視D
監視E
監視A(5分)
監視B(5分)
監視C
監視D
監視E
Hinemos Hinemos
設定追加直後
監視データ
監視A（5分）上書き
監視B（5分）上書き
監視C 上書き
監視D 上書き
監視E 上書き
初回検知！
＝＋
Utilityの注意点
・エクスポートデータは各設定の全量が含まれる
・インポートデータに含まれるものは、設定に変更が無くても上書きされる
・上書きでインポートした際、初回通知が発報される
Utilityは危険!!

・ Utilityは便利な反面、使い方を間違えると痛い目をみる
・作業フローの中にUtilityを取り入れるには、
機能をしっかりと理解することが必要！！
Utilityは危険!!

Utilityで効率化
~失敗を踏まえ今では!!~

設計書
インポートデータ
変更した設計書から
インポートデータを作成
ポイント①：インポートデータの確認を徹底する！
エクスポートデータ
(before)
インポート前に変更箇所が想定通りかをチェックするため差分比較!!
比較データはインポートデータの中身が正しいことを示すエビデンスとして使う！
Hinemos
失敗を踏まえ今では!!
変更前のHinemosの
データをエクスポート
差分比較

インポートデータ
作業後にデータをエクスポートし、変更箇所が想定通りかチェックするための
最後の差分比較!!
(before)
(after)
Hinemos
作業結果のエビデンスとして使える！！
ポイント②：インポート後の確認も徹底する！
差分比較差分比較

・ Utilityを用いた作業フローを確立！！
・構築にとどまらず、
運用中の設定変更まで
正確かつスピーディーに対応している

最後に

TISはこれ以外にも
まだまだHinemosの必要なテクニックや力をもっ
ています。
また、Hinemosに限らず他のOSSでも
SIから保守サポートまで対応します。
TISブースまで！！
是非お立ち寄りください！！
最後に

OSCFUKUOKA

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a OSCFUKUOKA

Similar a OSCFUKUOKA (20)

Último

Último (8)

OSCFUKUOKA

Notas del editor