 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| リポジトリ設計 | ||||||||||
|
管理されるノードは、何種類ものハードウェア、OS、ミドルウェアなどで構成されているのが一般的です。Hinemosのリポジトリ機能では、ノード情報を単に登録するだけでなく、スコープと呼ばれる単位にノードをグループ化し、さらにスコープを階層的に管理することができます。 Hinemosではその階層構造を決定する過程をリポジトリ設計と呼び、各ノードの構成情報や使用機能に基づいて表3に示すような登録ノード情報一覧、スコープ構造定義を作成することが目的です。この設計は、システム内に存在するHinemosマネージャーの数だけ行う必要があります。  表3：リポジトリ設計アウトプット例 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||
| リポジトリ設計の重要性 | ||||||||||
|
前回も簡単に解説した通り、リポジトリ設計のアウトプットは様々な監視項目から利用されます。そのため、リポジトリの工夫次第で管理機能を効率的に設計することができます。 例えば、図3のように10台のWebサーバが存在し、Apacheのログやプロセスを監視する場合、各ノードに対して同様のログ転送設定、syslog-ng監視設定、プロセス監視設定を行えば、機能的な目標は達成されます。  図3：監視項目を意識したスコープ例 しかし、Webサーバのスコープを作成すると、1/10の設定項目で同じ目標が実現できます。また、設定項目数を少なくすると、ログ監視などは正規表現によるログのフィルタリング回数が削減できることから、一般的に性能向上が見込まれます。 このようにリポジトリ設計は、Hinemosに備わるほとんどの機能から利用されるだけでなく、システム運用者が利用するHinemosクライアントの画面表示に影響するため、非常に重要な設計項目となります。「スコープをいかに活用し、スマートな監視設計につなげることができるか」という点を常に意識していただきたいと思います。 |
||||||||||
| 設計の観点 | ||||||||||
|
実際に設計する際に、重要と考えられる項目は以下のとおりです。 |
||||||||||
| 登録するノードとIPアドレスの対応 | ||||||||||
|
Hinemosに登録するノードには、必ず1つのIPアドレスを設定します。しかし、システム構成によっては、複数のNICが搭載されたサーバが存在します。 こういった場合、すべてのNICの状態を監視する必要性に応じ、同じ筺体であってもすべてのIPアドレスを別のノードとして登録するかどうかを検討するべきでしょう。 |
||||||||||
| Hinemosの運用監視設計の効率化と性能 | ||||||||||
|
リポジトリ設計の重要性で簡単に説明しましたが、スコープ構造の最適化により設定項目数の削減や性能向上が見込めます。特に、syslog-ng監視、プロセス監視、ジョブ管理は設定項目が多くなりがちな機能です。しかしOSやミドルウェア、アプリケーションごとにスコープを作成すれば、syslog-ng監視やプロセス監視の設定項目数を減らすことができます。 ジョブ管理に関しては、大規模な負荷分散により同じ機能を持つサーバが数多く存在するような場合を除き、スコープに対してジョブの実行を行うことは少ないかもしれませんが、FTPによるログの集約ジョブなどで同様のスコープが活用できます。 |
||||||||||
| システム運用者にとって最適なスコープ構造 | ||||||||||
|
前ページの図2で示したように、登録したスコープ構造はHinemosクライアントの監視画面にそのまま表示されます。システム内の各コンポーネントに詳しいシステムエンジニアの方であれば、スコープの階層構造をたどることで、OSやミドルウェアの種類から障害の切り分けが行えるかもしれません。 しかし、このような判断をしていないシステム運用者にとって、その作業は困難です。つまり、Hinemosの設定上は最適なスコープ構造であったとしても、実際の運用に支障があっては本末転倒なため、既存のシステムの運用管理方法やシステム運用者のスキルも考慮する必要があるでしょう。 |
||||||||||
| スコープ構造設計例 | ||||||||||
|
Hinemosの機能および様々なシステム要件に対する柔軟性を考慮したスコープ構造の設計例（図4）を以下に示します。  図4：スコープ構成の設計例 （画像をクリックすると別ウィンドウに拡大図を表示します） スコープは大きく分けて、「監視」スコープと「設定」スコープの2つに分かれています。 「設定」スコープは監視設定にて利用されるため、監視設定が定まった後は変更されることはあまり無いと考えられます。その一方で「監視」スコープは、システム管理者の監視しやすいよう、実運用までに何度か変更される可能性があります。 もし、これらを同一スコープにして、監視のしやすいようにスコープ構造を変更した場合、監視設定の見直しが必要となってしまいます。このため、スコープを分割しているのです。 監視設定用スコープの必要性および利用法に関しては、次回の管理機能設計で説明します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
