Introduction › Managed Service Providers and CA Performance Center › Domain Monitoring Considerations

Domain Monitoring Considerations

The IP domains feature supports environments where multiple enterprise systems must be monitored separately. For example, a managed services provider wants to monitor the systems and networks of different customers separately. The MSP administrator creates a tenant in CA Performance Center for each customer enterprise. The data and the configuration for each tenant are hidden from all other tenant users.

However, in other situations, you can deploy multiple IP domains in CA Performance Center without multi-tenancy. In other words, some deployment models consist of multiple IP domains within the Default Tenant.

The IP domain lets you control data collection parameters. Use custom IP domains to determine which collection devices monitor the managed items in your infrastructure. Each collection device, such as a Data Collector or a CA Unified Communications Monitor Collector, operates within a single IP domain.

The following list provides some examples of environments where you can deploy multiple IP domains within the Default Tenant:

• A deployment that includes a CA Application Delivery Analysis data source.

  CA Application Delivery Analysis monitors IP domains without a concept of tenants. The IP domains that you create within custom tenants are not detected. When Data Aggregator or CA Network Flow Analysis monitors items within those domains, they appear as duplicates in CA Application Delivery Analysis. The duplicate data is not aggregated.

• A large deployment that requires load balancing.

  For example, your enterprise includes ten routers with many interfaces, IP SLA testing, and QoS policies in place. Such a deployment would have a polling load similar to an environment with hundreds of servers being monitored for CPU and memory statistics only.

  To monitor the busy routers, you can create an IP domain and can deploy a powerful system for the Data Collector within that domain. And you can monitor the servers in another IP domain, using a less powerful system for the Data Collector. By running discoveries in the appropriate IP domains, you can determine the devices that each Data Collector is polling.

• A method to minimize the potential network impact of bulk statistics collection.

  For example, you can deploy a Data Collector close to the devices that it is monitoring. The Data Collector can process a massive amount of bulk statistics and can reduce them to a much smaller set of monitored metrics, which it then sends to the Data Aggregator. As a result, less data passes across the network between the two components.

• Isolation of potentially sensitive SNMP traffic to a specific area, such as a DMZ.

  For example, security policies do not let SNMP traffic travel across the router that limits an area of network. One option is to deploy a Data Collector behind the router. A path to return the processed metrics back to the Data Aggregator must be open.

  The metric data traveling between the components is not encrypted. However, it is packaged and compressed in a way that makes it less "sniffable." As a result, the data is more secure than raw SNMP flows. To accomplish this setup, create an IP domain for the DMZ and deploy a Data Collector within that IP domain.