ja:documentation:01_understanding:02_architecture

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン 前のリビジョン
次のリビジョン
前のリビジョン
最新のリビジョン両方とも次のリビジョン
ja:documentation:01_understanding:02_architecture [2023/06/09 02:17] – [アクセスが制限されたネットワーク] junichija:documentation:01_understanding:02_architecture [2023/06/09 05:19] – [大規模環境] junichi
行 239: 行 239:
 === 特別な組織構造 === === 特別な組織構造 ===
  
-  * 異なる設定の監視システムで、**複数の拠点を監視する** 必要性があっとします。この場合、個々の Pandora からのモニタリング情報を複製するエクスポート機能を利用します。+  * **Reporting duality:**  Additionally, you may configure agents to report to two different Pandora FMS servers, although they can only be managed by one of them. 
 +  * **Fragmented management:**  It is pretty useful if you are required to **delegate the administration of part of the equipment**  to different personnel with different access levels. This is more of a management issue rather than an architectural problem. It can be solved by the [[:en:documentation:04_using:11_managing_and_administration|assigned permissions on policies]].
  
-{{  :wiki:export-server.png?650  }}//エクスポートサーバを使った階層構造モデル// +  * **複数のレポート**: 異なる 2つの Pandora FMS サーバにデータを送るようにエージェントを設定することができます。ただし、管理は一つのサーバからのみ可能です。 
- +  * **分散管理:** の権限の担当者で **監視内容を分散管理する** 必要がある場合に便利です。これは、構成というより管理が重要です。[[:ja:documentation:04_using:11_managing_and_administration|管理ポリシーの権限設定]]によって調整します。
-  * **複数のレポート**: 異なる Pandora サーバにデータを送るエージェントを設定することができます。ただし、管理は一つから可能です。 +
-  * 分散管理: 必要な時に別の担当者で**監視内容を分散管理する** 必要がある場合に便利です。これは、構成というより管理が重要です。管理ポリシーの権限設定によって調整します。+
  
 === 大規模環境 === === 大規模環境 ===
行 250: 行 249:
 {{:wiki:icono-modulo-enterprise.png  }} {{:wiki:icono-modulo-enterprise.png  }}
  
-  * 数千もの監視項目がある**大規模環境** では、異なるリモートモニタリング手法を利用します。(50,000以上の)大量の監視項目では、一台のサーバに集約することができません。そのため、異なるサーバをリモート監視を分散するブローカーモードで利用します。 +  * **Large-Volume Network:**  Consisting of thousands of network testing processes which must be distributed in different 'remote monitoring probes'. Given their large numbers (over 50,000), they cannot be centralized into a single server. To that end, use servers in broker mode that distribute the remote check load
- +  * **Redundant servers**For security reasons, in case primary hardware fails, a [[http://:en:documentation:05_big_environments:06_ha|server in HA mode]] may automatically relocate and delegate the monitoring workload.
-{{  :wiki:broker_scalation_example.png?600  |//ブローカーモードのエージェントを使ったリモート監視の分散モデル//}} +
- +
-  * The need to install [[:en:documentation:05_big_environments:06_ha|a server on HA]]for security reasons, in case primary hardware fails. You will see how to mount two serversone "passive", waiting for the active to stop responding and start up. There are different ways to do this. +
-  * The need to **monitor large volume of systems and manage them in a centralized way**  (more than 2500 agents). In order to do so, different Pandora FMS Servers are configured to be coordinated by the system called **Metaconsole**'. They can be linearly scaled in this way. +
- +
-  * プライマリサーバのハードウエアが故障した場合にそなえて、[[:ja:documentation:05_big_environments:06_ha|冗長化]] の設定が必要です。 2つのサーバを用意し、一方が停止したときにアクティブになるように一台はスタンバイ状態にしておきます。そうするにはいくつかの手法があります。 +
-  * **大規模システムの監視と集中管理** (2500エージェント以上)が必要な場合、そのためには、**メタコンソール** と呼ばれるシステムでまとめた異なる Pandora サーバを設定します。これにより、リニアにシステムを拡張できます。+
  
-{{  :wiki:pandora_metaconsole_overview2.png  }}+  * **大規模ネットワーク:** 何千ものネットワーク監視処理がある場合は、異なるリモート監視プローブに分散する必要があります。その数が多い (50,000 以上) の場合、単一のサーバに集約することはできません。そのため、リモートチェックの負荷を分散するブローカーモードでサーバを利用します。 
 +  * **サーバの冗長化:** プライマリサーバのハードウエアが故障した場合にそなえて、[[:ja:documentation:05_big_environments:06_ha|冗長化]] の設定により監視処理を別のサーバに引き渡すことができます。
  
 ===== OBSOLETE ===== ===== OBSOLETE =====