安定したアプリケーションになっています。(みなさんのテストのおかげで、それぞれのバージョンでは拡張が行われ、数百の不具合が報告され、修正されてきました。クリティカルや高負荷な環境では、複数のサーバに処理を分散させることが可能です。いずれかのコンポーネントで障害が発生しても、システム自体はダウンしません。細かいモジュールで設計されています。それぞれのモジュールは、独立して動作することができます。それぞれはまた、連携して動作することができ、負荷を分配することができます。基本設計を以下に示します。エージェントは冗長化構成ではありません。エージェントがダウンすると、モジュールの実行ができず、また、複数のエージェントを平行して実行することはできないため、またはシステム自体がダウンしているため、そのエージェントの全てのデータ収集はできなくなります。エージェントのある無しに関わらず、冗長化しモニタリングすることです。おける最も重要なコンポーネントは次の通りです。データベースサーバコンソール各コンポーネントは、あらゆる障害から監視システムを保護するために冗長構成を組むことができます。負荷をバランシングするために必要なノード数を決定するためには、監視対象の数と監視間隔を知る必要があります。監視のニーズによって、異なるアーキテクチャを決定します。アーキテクチャを決めるためのテストは、以下の複数の環境を使用して行っています。データベースのノードは、2台それぞれのサーバで(マスター・スレーブ構成で)設定します。大規模環境では、前述の構成スキームを1つのセットとして定義します。モジュールを監視する必要がある場合、要求を満たすために必要な数のノードを設定する必要があります。つのセットを設定します。全体の環境を管理するには、全体を一元管理できるメタコンソールのインストールが必要です。メタコンソールに必要なリソースは以下の通りです。一つのサーバに集約するには、負荷を考慮してサイズを変更する必要があります。使用することです(プライマリが応答しない場合は代替サーバーに接続できます)。サービスのバランシングまたはクラスタリングを可能にする商用ソリューションを使用することができます。データサーバを利用する必要があります。サーバーを設定する必要があります。アドレス(VIP)を割り当てます。外部バランサを使用していて、いずれかのサーバが故障した場合、アクティブなサーバにのみ接続するようになります。エージェントは変更に気付くことなく、これまでと同様のアドレスへ接続します。この場合は、ロードバランサーは障害が発生したサーバにはデータを送信せず、アクティブな方にのみ送信します。データサーバの設定を変更する必要はありません。それぞれのサーバに別々の名前を設定してさえいえれば、サーバの状態ビューでいずれかがダウンしていることがわかり便利です。データモジュールは、いずれかのサーバで処理することができます。事前のサーバ指定は不要です。構成がとれるように設計されています。メカニズムを使用する場合は、データの送信にわずかな遅延があります。これは、エージェントの実行ごとにプライマリサーバとの接続を試みるためです。セカンダリに対してこれを行います(設定されている場合)。使用して次のディレクトリを共有する必要があります。データサーバのすべてのインスタンスでこれらのディレクトリを読み書きします。共有されるこれらの共有ディレクトリにアクセスできる必要があります。ソフトウエアエージェントでのバランシングソフトウエアエージェントで、データサーバのバランシングを行うことができます。データサーバの一方をマスター、もう一方をバックアップとして設定することができます。おいて、次の部分のコメントを外します。nosecondary_server_opts次に示すオプションがあります。(詳細は、エージェント設定の章を参照してください。セカンダリサーバのモードを設定します。次のいずれかが設定できます。メインサーバにデータを送信できなかった場合のみセカンダリサーバにデータ送信します。メインサーバに接続できるできないに関わらず、常にセカンダリサーバにもデータを送信します。アドレスを指定します。ファイルを置く場所を指定します。ファイルを置くためのポート番号を指定します。