Geographically distributed deployments

In geographically distributed deployments your IBM® QRadar® deployment might be impacted by intermittent or poor connectivity to remote data centers. You might also be impacted by local regulations, such as complying with specific state or country regulations to keep data in the place of origin. Both of these situations require that you keep collectors on site. If you must keep data in the place of origin, then you must keep the processor on site.

For example, your company is growing and this growth not only increases activity in the network, but it also requires that you expand your QRadar deployment to other countries. Data retention laws vary from country to country, so the QRadar deployment must be planned with these regulations in mind.

You note these following conditions:

  • Your company must collect event data from one of the office locations that has intermittent connectivity.
  • Your company must comply with data retention regulations in the countries where data is collected. For example, if Germany requires that data remains in-country, then that data must not be stored outside that country.
Figure 1. Geographically Distributed Deployment
geographical deployment

In the geographically distributed deployment, the following processes occur:

  • Your company installs collectors and processors in the German data center to comply with local data laws.
  • In the French data center, your company installs collectors, so that data is sent by the collectors to the head office, which is processed and stored at the head office. Search speeds are increased by having the processor appliances on the same high-speed network segment as the QRadar Console.
  • Your company adds a store-and-forward Event Collector that has scheduled and rate-limited forwarding connections in the remote data center. The scheduled and rate-limited connections compensate for intermittent network connectivity and ensures that the requirement for more bandwidth is avoided during regular business hours.

If you’re constantly searching for data on a remote processor, it’s better to have that processor on the same high-speed network segment as the QRadar Console. If the bandwidth between the QRadar Console and remote processor is not good, you might experience latency with your searches, especially when you're doing multiple concurrent searches.