差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン 前のリビジョン 次のリビジョン | 前のリビジョン | ||
ja:documentation:07_technical_annexes:03_capacity_planning [2022/02/23 02:32] – [ICMP サーバ(Enterprise)] 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日後に " | ||
- | |||
- | === ICMP サーバ(Enterprise) === | ||
- | |||
- | This is specifically for the [[: | ||
- | |||
- | これは、[[: | ||
- | |||
- | Supposing that server is already working and configured, some key parameters for its performance: | ||
- | |||
- | サーバがすでに設定され動作していると仮定すると、そのパフォーマンスに関するいくつかの重要なパラメーターは次のとおりです。 | ||
- | |||
- | < | ||
- | |||
- | block_size X | ||
- | |||
- | </ | ||
- | |||
- | It defines the number of " | ||
- | |||
- | これは、システムが 1回に実行する " | ||
- | |||
- | On the contrary, the module ping park is heterogeneous and they are in very different networks, with different latency times,it is not convenient for you to put a high number, because the test will take the time that takes the slower one, so you can use a number quite low, such as 15 to 20. | ||
- | |||
- | 逆に、ping モジュールが少なく、対象のネットワークが大きく異なり遅延時間もそれぞれ異なるような場合は、テストに遅い方の時間を要するため、大きな数値は設定しない方が良いです。15 から 20 などの非常に低い数を使用します。 | ||
- | |||
- | < | ||
- | icmp_threads X | ||
- | |||
- | </ | ||
- | |||
- | Obviously, the more threads it has, the more checks it could execute. If you make an addition of all the threads that Pandora FMS execute, they will not be more than 30 to 40. You should not use more than 10 threads here, thought it depends a lot of the kind of hardware an GNU/Linux version that you are using. | ||
- | |||
- | 明らかに、スレッドが多いほど、実行できるチェックも多くなります。 Pandora FMS が実行するすべてのスレッドを追加しても、30〜40 を超えることはありません。利用している GNU/Linux バージョンとハードウェアの種類に大きく依存しますが、ここでは 10 を超えるスレッドは使用するべきではありませn。 | ||
- | |||
- | Now " | ||
- | |||
- | 次に、テストする架空の数の ping モジュールを " | ||
- | |||
- | Using the Pandora CSV importer (available in the Enterprise version) and create a file with the following format: | ||
- | |||
- | Pandora CSV インポーター(Enterprise 版で利用可能)を使用して、次の形式でファイルを作成します。 | ||
- | |||
- | < | ||
- | (Agent name, IP, | ||
- | |||
- | </ | ||
- | |||
- | You can use this shellscript to generate this file (changing the destination IP and the group ID) | ||
- | |||
- | 以下のシェルスクリプトを使用して、ファイルを生成できます(宛先 IP とグループ ID を変更します)。 | ||
- | |||
- | < | ||
- | A=3000 | ||
- | while [ $A -gt 0 ] | ||
- | do | ||
- | echo " | ||
- | A=`expr $A - 1` | ||
- | done | ||
- | |||
- | </ | ||
- | |||
- | Before start all this process, the Pandora FMS server must be running and monitoring, measuring the metrics from the previous point: CPU consumption (**pandora** and **mysql**), number of modules in unknown state and other interesting monitors. | ||
- | |||
- | このすべての処理を開始する前に、Pandora FMS サーバが実行および監視され、前述のメトリック(CPU使用率(**pandora** および **mysql**)、不明状態のモジュール数、およびその他の興味深い監視項目)を測定する必要があります。 | ||
- | |||
- | Import the CSV to create 3000 agents, it will take some minutes. After that go to the first agent ('' | ||
- | |||
- | CSV をインポートして 3000エージェントを作成します。数分かかります。 その後、最初のエージェント('' | ||
- | |||
- | Go to the massive operations tool and copy that module to the other 2999 agents. | ||
- | |||
- | 一括操作ツールに移動し、そのモジュールを他の 2999 エージェントにコピーします。 | ||
- | |||
- | Pandora FMS should then start to process those modules. Measure with the same metrics from the previous case and evaluate how it goes. The objective is to let an operable system for the number of modules of type ICMP required without any of them reaches the unknown status. | ||
- | |||
- | その後、Pandora FMS はそれらのモジュールの処理を開始します。 前のケースと同じメトリックを測定し、それがどのように推移するかを評価します。 目的は、必要な ICMP タイプのモジュールの数に対して、不明状態にならずに処理できかです。 | ||
- | |||
- | === SNMP サーバ(Enterprise) === | ||
- | |||
- | This is specifically about the SNMP Enterprise network server. In case of testing for the Open network server, see the section on the (generic) network server. | ||
- | |||
- | これは SNMP Enterprise ネットワークサーバーに関するものです。 オープンソースのネットワークサーバのテストの場合は、(汎用の)ネットワークサーバの章を参照してください。 | ||
- | |||
- | Assuming that you have the server already working and configured, we are going to explain some key parameters for its working: | ||
- | |||
- | サーバがすでに設定され動作していると仮定して、サーバが機能するためのいくつかの重要なパラメーターについて説明します。 | ||
- | |||
- | < | ||
- | block_size X | ||
- | |||
- | </ | ||
- | |||
- | It defines the number of SNMP requests that the system will do for each execution. You should consider that the server groups them by destination dir IP, so this block is only indicative. It is recommendable that it wouldn' | ||
- | |||
- | これは、システムが 1回に実行する SNMP リクエストの数を定義します。サーバが宛先 IP でグループ化することを考慮するため、このブロックは単なる指標です。 大きくしないことをお勧めします(最大 30〜40)。ブロック内の要素に障害が発生すると、内部カウンターは Enterprise サーバでそれを再試行し、試行回数が x 回を超えても応答がない場合は、オープンソースのサーバに処理を渡します。 | ||
- | |||
- | < | ||
- | snmp_threads X | ||
- | |||
- | </ | ||
- | |||
- | It should not be too large (30 to 40 maximum). When an element of the block fails, an internal counter makes the Enterprise server retry it, and if after X attempts it does not work, it will be passed to the Open server. You shouldn' | ||
- | |||
- | 使用するハードウェアの種類と GNU/Linux のバージョンによって異なりますが、10を超えるスレッドを使用しないでください。 | ||
- | |||
- | The faster way to test is through a SNMP device, applying all the interfaces, all the serial " | ||
- | |||
- | テストのよりすばやく実施する方法は、SNMP デバイスを使用して、すべてのインターフェイス、すべての一連の " | ||
- | |||
- | If you generate other agent with other name, but same dir IP, you will have other 650 modules. Another option could be to copy all modules to serial of agents that will have all the same dir IP, so the copied modules works " | ||
- | |||
- | 他の名前で同じ IP を持つ他のエージェントを作る場合は、さらに 650 モジュールを追加できます。すべてのモジュールを、同じ IP を持つすべてのエージェントにコピーすることにより、コピーされたモジュールは同じスイッチにアクセスします。 | ||
- | |||
- | Other option is to use an SNMP emulator, as for example the **Jalasoft SNMP Device Simulator**. | ||
- | |||
- | 他のオプションとしては、たとえば **Jalasoft SNMP Device Simulator** のような SNMP エミュレータを使用することです。 | ||
- | |||
- | The objective of this point is to be able to monitor in a constant way an SNMP module pool during at least 48 hours, monitoring the infrastructure, | ||
- | |||
- | ここでの目的は、SNMP モジュールプールを少なくとも 48時間一定の方法で監視し、インフラストラクチャを監視して、1秒あたりのモジュール数の監視率が一定であり、 サーバが不明状態のモジュールを生成しないことです。不明状態は、次の原因で発生する可能性があります。 | ||
- | |||
- | * Lack of resources (mem, CPU). It would be possible to see a tendency of these metrics in continual rise, what it is a bad signal. | ||
- | * Occasional problems: | ||
- | * Network problems, due to not related processes (i.e: backup of a server in the network) that affect the speed and availability of the network at any given time. | ||
- | |||
- | * リソース(メモリ、CPU)の不足。これらのメトリクスの傾向が継続的に上昇していることが確認できた場合、それは悪いシグナルです。 | ||
- | * 時々発生する問題: | ||
- | * 監視処理とは関係ない(ネットワーク内のサーバのバックアップなどの)ネットワークの問題で、ネットワークの速度に影響を与えている場合。 | ||