実装ガイド › 環境の計画 › サブスクリプションの更新の計画 › 例： 6 台のサーバによるサブスクリプションの設定

例： 6 台のサーバによるサブスクリプションの設定

サブスクリプションの設定に着手する場合、サブスクリプション ロールを決定する前に、サーバが実行している他のロールを考慮します。 デフォルトでは、最初にインストールしたサーバである管理サーバは、デフォルトのサブスクリプション プロキシになります。 他のすべてのサーバは、デフォルトのサブスクリプション プロキシのサブスクリプション クライアントになります。 この設定を受け入れることもできますが、オンライン サブスクリプション プロキシを設定して、デフォルトのプロキシをフェイルオーバー用または冗長プロキシとして動作させることをお勧めします。 最も使用頻度の低いサーバに、オンライン プロキシとしてのロールを割り当てるのも良い方法です。

例： 最もビジーでないサーバがオンライン サブスクリプション プロキシである場合の 6 台のサーバ

6 台の CA Enterprise Log Manager サーバのシナリオを考えてみます。 管理サーバは、ログイン時のユーザの認証と許可、およびアプリケーション コンテンツの保存専用のサーバです。 連携した 4 台のサーバは、イベント処理およびレポート処理を行います。 6 番目のサーバは、復元されたデータベースからのイベントを調査するための専用復元ポイントです。 専用復元ポイントを使用する利点は、連携にこのサーバを含めないことで、古いデータが最新のレポートに含まれないようにできる点です。

この例では、「収集」と「レポート」とラベル付けされた 2 台のサーバが、他のサーバよりも高負荷の処理要件を持つように設定されています。 これらのサーバは階層構成で連携され、収集サーバはレポート サーバの子になっています。 収集サーバおよびレポート サーバの両方として動作する 2 台のサーバは、通常のイベント ボリュームとスケジュール済みレポートを提供するように設定されています。 これらは互いに連携し、メッシュ統合で専用のレポート サーバとして機能しています。つまり、3 台のサーバがピアになっています。 サーバを連携させる目的は、連携したサーバからもクエリの結果が得られるように機能を拡張することです。 メッシュ構成にしたサーバの任意のサーバから連携クエリを実行すると、そのサーバ自身と連携内の他の 3 つのサーバからのイベントが返されます。

注： 自己監視イベントに関する統合レポートを実行する場合は、連携に管理サーバを含めます。

このシナリオで推奨されるソリューションは、復元ポイントをオンライン サブスクリプション プロキシとして設定することですが、それは、復元ポイントが最も使用頻度の低いサーバであるためです。 次に、各クライアントがこのオンライン プロキシを参照するように設定し、オンライン プロキシがビジー状態や使用不可能な状態の場合でも、デフォルトのプロキシがバックアップとして動作できるようにします。

詳細情報：

CA Enterprise Log Manager の連携の設定