Before you create a federation map, determine the number of servers you plan to devote to each server role. In the following example, one server is devoted to management and reporting and the remaining servers are devoted to collection. We recommend this configuration for a mid-sized environment. You can think of the architecture of the management/reporting server and collection servers as hub and spoke, where the management/reporting server is the hub. The federation map diagram does not mirror this configuration; instead, it shows the tiers so you can easily differentiate pairs that are federated hierarchically from the meshed ones.
When creating a federation map, consider the reports and alerts for which you want different sets of consolidated data. For example, consider the scenario where you want consolidated data using two types of server groupings:
For most reports, where you want to examine recently archived (warm) events while sparing your collection servers from processing queries on new (hot) events
Note: Events are typically archived from collection servers (spokes) to the reporting server (hub) every hour.
For system reports on self-monitoring events, where you want to evaluate the health of all your CA Enterprise Log Manager servers at once
For alerts, where it is important to query for new events from all collection servers
An example federation map that lets you meet these reporting objectives follows:
To implement the design of this federation map, you would take the following actions:
To meet a given objective, it is important to run the report or alert from a server represented by a particular location on your federation map and correctly specify whether federation is needed. Examples follow:
Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |