差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン | ||
ja:documentation:07_technical_annexes:03_capacity_planning [2022/02/23 01:00] – [キャパシティの考察] junichi | ja:documentation:07_technical_annexes:03_capacity_planning [Unknown date] (現在) – 削除 - 外部編集 (Unknown date) 127.0.0.1 | ||
---|---|---|---|
行 1: | 行 1: | ||
- | ====== キャパシティ分析 ====== | ||
- | {{indexmenu_n> | ||
- | |||
- | [[ja: | ||
- | |||
- | ===== キャパシティ分析 ===== | ||
- | |||
- | ==== 概要 ==== | ||
- | |||
- | [[: | ||
- | |||
- | [[: | ||
- | |||
- | Load test were made in a first phase, aimed to a cluster based system, with an unique Pandora server centralized in a DDBB cluster. The load test are also useful to observe the maximum capacity per server. In the current architecture model ([[: | ||
- | |||
- | 最初は、クラスタを使ったシステムを対象にしたロードテストです。データベースクラスタの中に一つの Pandora サーバがあります。ロードテストは、サーバ一台ごとの最大のキャパシティを見るのに便利です。現在([[: | ||
- | |||
- | {{ : | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | === データストレージと圧縮 === | ||
- | 実際に Pandora は、リアルタイムでデータを圧縮しています。これは、保存されるデータ量を計算するためにはとても重要です。最初に、データの保存方法に関して従来のシステムと Pandora FMS の " | ||
- | |||
- | |||
- | |||
- | {{ wiki: | ||
- | |||
- | |||
- | |||
- | ** 従来のシステム ** | ||
- | |||
- | チェックを一日平均20実施すると、1年で 5MB の容量が必要です。エージェントあたり 50チェックでは、1年 250MB になります。 | ||
- | |||
- | **従来とは異なる Pandora FMS のような非同期システム** | ||
- | |||
- | チェックにおいて 1日平均 0.1の状態変化では、1年で 12.3KBの容量になります。エージェントあたり 50チェックでは、1年で 615KB です。 | ||
- | |||
- | === 用語の定義 === | ||
- | |||
- | Next is described a [[: | ||
- | |||
- | 次に、より理解を深められるように、ここで使われている[[: | ||
- | |||
- | * **情報の断片化**: | ||
- | * **モジュール**: | ||
- | * **間隔**: 一つのモジュールで情報を収集する時間間隔です。 | ||
- | * **アラート**: | ||
- | |||
- | ==== 容量考察の例 ==== | ||
- | |||
- | {{ : | ||
- | |||
- | === これまでの考察と対象範囲 === | ||
- | 次の 3種類のパターンで設定を行う場合を考えてみます。 | ||
- | |||
- | * ステージ1: | ||
- | * ステージ2: | ||
- | * ステージ3: | ||
- | |||
- | このデータ量において、正しく Pandora FMS の要求スペックを決めるためには、どのような種類のモニタリングをする予定であるかを知る必要があります。次の例では、" | ||
- | |||
- | * 90% のモニタリングをソフトウエアエージェントで実施。 | ||
- | * 技術/ | ||
- | * モニタするモジュールやイベント間で、実行間隔が異なる。 | ||
- | * 大量の非同期情報がある(イベントやログなど)。 | ||
- | * あまり変化がない状態を確認する処理がたくさんある。 | ||
- | * 全体的にパフォーマンスに関する情報は少ない。 | ||
- | |||
- | すべての技術的な内容とその実装に関する調査(システムとそのモニタ方法の確認)の結果、次のような結論に至ります。 | ||
- | |||
- | * 1システムあたり、平均して 40個のモジュールやイベントが存在する。 | ||
- | * 平均モニタリング間隔は、1200秒(20分)である。 | ||
- | * 5分ごとに情報を送ってくるモジュールもあれば、1週間に一度だけのモジュールもある。 | ||
- | * 全グループの全モジュール (240,000) のうち、確認のたびに変更が発生する可能性があるのは 25% である。 | ||
- | * モジュールごとのアラート比率は 1.3 (モジュール/ | ||
- | * アラートの発生率は、1% と仮定する。(これは我々の経験上の予測です) | ||
- | |||
- | この結論は、予測を策定するための基本となります。理解しやすいように Excel シートにまとめてみます。 | ||
- | |||
- | {{ : | ||
- | |||
- | これらの初期データに対して必要な計算をあてはめます。データベースのサイズおよび、モニタリングに必要となる一秒間あたりのモジュール実行数、その他パラメータを予測できます。 | ||
- | |||
- | {{ : | ||
- | |||
- | === キャパシティの考察 === | ||
- | |||
- | Once known the basic requirements for the implementation in each phase ( modules/ | ||
- | |||
- | それぞれのフェーズで実装のための基本的な要求事項 (秒あたりのモジュール実行数)、アラートの数、日ごとのモジュール実行数、月ごとの容量がわかったら、本番に近いシステムで実際にサーバの負荷テストを行います。(ここでのテストは、本番に近いシステムでは実行できていません。) | ||
- | |||
- | これらの負荷テストでは、Pandora FMS の処理能力がわかり、どの程度で性能劣化するかがわかります。これは、次のような目的において便利です。 | ||
- | |||
- | - 対象のハードウエアで最大どれくらいの規模まで対応できるかを推定する場合。 | ||
- | - ストレージの限界および、ヒストリー DB へ情報を移すポイントを知りたい場合。 | ||
- | - サービス停止や計画停止により、処理する情報がたまった場合の最大処理量に対する余裕を知りたい場合。 | ||
- | - モニタ対象の情報の変化率が変わった場合のパフォーマンスに与える影響を知りたい場合。 | ||
- | - 大量のアラート処理の影響を知りたい場合。 | ||
- | |||
- | The tests have been done on a **DELL server PowerEdge T100®** | ||
- | |||
- | テストは、**Intel Core Duo** プロセッサ 2.5GHz および、メモリ 2GB を積んだ **DELL のサーバ PowerEdge T100** にて実施しました。このサーバでは、Ubuntu Server 8.04 が動いており、HA 環境のテストに使っています。テストは、QUASAR TECHNOLOGIES プロジェクトに似たエージェント設定で実施しました。同じハードウエアではありませんが、同じような HA 環境で、WUASAR TECHNOLOGIES と似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。 | ||
- | |||
- | {{ : | ||
- | |||
- | 得られた結果はとても良く、システムは非常に過負荷にもかかわらず、非常に興味深い情報量を処理することができました(180, | ||
- | |||
- | 1. リアルタイムの情報は、最大 15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。 | ||
- | |||
- | 2. 情報量を考慮して、処理の余裕は想定能力よりも高い最大能力の 50% ほどである。 | ||
- | |||
- | 3 システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。 | ||
- | |||
- | ==== 詳細方法論 ==== | ||
- | |||
- | The previous chapter was a " | ||
- | |||
- | 前の章は、" | ||
- | |||
- | As starting point, in all cases is assume the **worst-case scenario** providing for choose. If can not choose it, it will be the " Common case" philosophy. **It will be never considered anything in the "best of cases" | ||
- | |||
- | 出発点として、すべての選択の場面において、**最悪のシナリオ**を想定しています。 それができない場合、それは " | ||
- | |||
- | Next step is how to calculate the system capacity, by monitoring type or based on the information origin. | ||
- | |||
- | 次のステップは、監視のタイプまたは情報の出所に基づいて、システム容量を計算する方法です。 | ||