差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン | ||
ja:documentation:07_technical_annexes:03_capacity_planning [2022/02/23 01:46] – [データ削除と移動の評価] 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. | ||
- | |||
- | 次のステップは、監視のタイプまたは情報の出所に基づいて、システム容量を計算する方法です。 | ||
- | |||
- | === データサーバ === | ||
- | |||
- | Based on the achievement of certain targets, as we have seen in the previous point, we suppose that the estimated target, is to see how it works wiht a load of 100,000 modules, distributed between a total of 3000 agents, that is, an average of 33 modules per agent. | ||
- | |||
- | 前のポイントで見たように、特定の目的に基づいて考えます。合計 3000 のエージェントに分散された 100,000 モジュールの負荷、つまり平均でエージェントあたり 33モジュールでどのような負荷で動作するかを確認したいと想定します。 | ||
- | |||
- | A [[: | ||
- | |||
- | '' | ||
- | |||
- | * 1 module type string. | ||
- | * 17 modules type '' | ||
- | * 15 modules type '' | ||
- | |||
- | * 文字列タイプの 1モジュール | ||
- | * '' | ||
- | * '' | ||
- | |||
- | We will configure the thresholds of the 17 modules of '' | ||
- | |||
- | '' | ||
- | |||
- | < | ||
- | |||
- | module_begin | ||
- | module_name Process Status X | ||
- | module_type generic_proc | ||
- | module_description Status of my super-important daemon / service / process | ||
- | module_exec type=RANDOM; | ||
- | module_end | ||
- | |||
- | </ | ||
- | |||
- | In the 15 modules of '' | ||
- | |||
- | '' | ||
- | |||
- | We should configure the thresholds of the 15 modules of '' | ||
- | |||
- | このタイプのデータが生成されるように、'' | ||
- | |||
- | < | ||
- | module_exec type=SCATTER; | ||
- | |||
- | </ | ||
- | |||
- | Then, we configure the thresholds for these 15 modules, so they have this pattern: | ||
- | |||
- | これらの 15個のモジュールのしきい値を設定すると、次のパターンになります。 | ||
- | |||
- | < | ||
- | 0-50 normal | ||
- | 50-74 warning | ||
- | 75- critical | ||
- | |||
- | </ | ||
- | |||
- | We add to the configuration file of our '' | ||
- | |||
- | '' | ||
- | |||
- | < | ||
- | module_min_critical 75 | ||
- | module_min_warning 50 | ||
- | |||
- | </ | ||
- | |||
- | Execute the '' | ||
- | |||
- | '' | ||
- | |||
- | Should let it running at least for 48 hours without any kind of interruption and we should monitor (with a Pandora FMS agent) the following parameters: | ||
- | |||
- | 中断することなく少なくとも 48時間実行し、次のパラメーターを(Pandora FMS エージェントを使用して)監視する必要があります。 | ||
- | |||
- | Number of queued packages: | ||
- | |||
- | キューに入っているデータ数: | ||
- | |||
- | < | ||
- | find / | ||
- | |||
- | </ | ||
- | |||
- | <font inherit/ | ||
- | |||
- | Pandora FMS サーバ CPU 使用率: | ||
- | |||
- | < | ||
- | |||
- | ps aux | grep "/ | ||
- | |||
- | </ | ||
- | |||
- | '' | ||
- | |||
- | '' | ||
- | |||
- | < | ||
- | |||
- | ps aux | grep "/ | ||
- | |||
- | </ | ||
- | |||
- | CPU used by **mysqld** | ||
- | |||
- | **mysqld** による CPU 使用率(実行の構文を確認してください。MySQL ディストリビューションによって異なります。) | ||
- | |||
- | < | ||
- | |||
- | ps aux | grep " | ||
- | |||
- | </ | ||
- | |||
- | Pandora FMS DDBB response average time: | ||
- | |||
- | Pandora FMS データベース平均応答時間: | ||
- | |||
- | < | ||
- | |||
- | / | ||
- | |||
- | </ | ||
- | |||
- | Number of monitors in unknown state: | ||
- | |||
- | 不明状態の監視項目数: | ||
- | |||
- | < | ||
- | echo " | ||
- | |||
- | </ | ||
- | |||
- | (''< | ||
- | |||
- | (''< | ||
- | |||
- | The first executions should be useful to " | ||
- | |||
- | 最初の実行は、サーバと MySQL 設定を " | ||
- | |||
- | Use the script ''/ | ||
- | |||
- | スクリプト ''/ | ||
- | |||
- | < | ||
- | |||
- | 3000 / (4x60) = 12.5 | ||
- | |||
- | </ | ||
- | |||
- | It should get a processing rate of 12.5 packages minimum to be reasonably sure that Pandora FMS could process this information. | ||
- | |||
- | Pandora FMS がこの情報を処理できることを合理的に確認するには、最低 12.5 個のデータ処理速度が必要です。 | ||
- | |||
- | Elements for adjust: | ||
- | |||
- | 調整要素: | ||
- | |||
- | * Number of threads. | ||
- | * Number maximum of items in intermediate queue ('' | ||
- | * Of course, all the parameters of MySQL that are applicable (very important). | ||
- | |||
- | * スレッド数 | ||
- | * 中間キュー内のアイテムの最大数('' | ||
- | * もちろん、適用可能な MySQL のすべてのパラメーター(非常に重要) | ||
- | |||
- | <WRAP center round tip 60%> | ||
- | |||
- | <WRAP center round tip 60%> | ||
- | |||
- | Configure the system in order that the DDBB maintenance script at ''/ | ||
- | |||
- | ''/ | ||
- | |||
- | < | ||
- | mv / | ||
- | |||
- | </ | ||
- | |||
- | We leave the system working, with the package generator a minimum of 48 hours. Once this time has passed, we should evaluate the following points: | ||
- | |||
- | データジェネレーターを最低 48時間動かして、システムを動作させたままにします。 この時間が経過したら、次の点を評価する必要があります。 | ||
- | |||
- | - Is the system stable?, Is it down? If there are problems, check the logs and graphs of the metrics that we have got (mainly memory). | ||
- | - Evaluate the tendency of time of the metric " | ||
- | - Evaluate the metric " | ||
- | - Evaluate the metric " | ||
- | - Evaluate the metric "MYSQL server CPU"; should be constant with many peaks, but with a constant tendency , **not rising**. | ||
- | |||
- | - システムは安定しているか? | ||
- | - メトリック " | ||
- | - メトリック " Pandora データベースの平均応答時間" | ||
- | - メトリック " | ||
- | - メトリック "MYSQL サーバ CPU使用率" | ||
- | |||
- | == アラートの影響の評価 == | ||
- | |||
- | If all was right, now will evaluate the impact of the alert execution performance. | ||
- | |||
- | すべてが問題なければ、アラート実行パフォーマンスの影響を評価します。 | ||
- | |||
- | Apply one alert to five specific modules of each agent ('' | ||
- | |||
- | '' | ||
- | |||
- | Optionally create one event correlation alert to generate one alert for any critical condition of any agent with one of these five modules. | ||
- | |||
- | オプションで、1つのイベント相関アラートを作成して、これら 5つのモジュールのいずれかを使用するエージェントの障害状態に対して 1つのアラートを生成します。 | ||
- | |||
- | Let the system operating 12 hours under those criteria and evaluate the impact, following the previous criteria. | ||
- | |||
- | これらの基準の下でシステムを 12時間稼働させ、前の基準に従って影響を評価します。 | ||
- | |||
- | == データ削除と移動の評価 == | ||
- | |||
- | Supposing the data storage policy was: | ||
- | |||
- | データストレージのポリシーが以下の通りであると仮定します。 | ||
- | |||
- | * Deleting of events from more than 72 hours. | ||
- | * Moving data to history from more than 7 days. | ||
- | |||
- | * 72時間以上経過した古いイベントを削除 | ||
- | * 7日以上経過したデータをヒストリデータベースへ移動 | ||
- | |||
- | Should let the system working " | ||
- | |||
- | 長期的なパフォーマンスを評価するために、システムを少なくとも 10日間動作させる必要があります。 データがヒストリデータベースに移動される 7日後に " | ||