Manual Chapter : How does data flow in a BIG-IQ solution

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 8.0.0
Manual Chapter

How does data flow in a BIG-IQ solution

To design the network structure that your BIG-IQ solution requires, it's helpful to understand a little bit about how the BIG-IQ operates. There are four functions essential to BIG-IQ operations.
  • Management (out of band)
  • Discovery
  • Listener
  • Cluster
Each of these functions is enabled by a specific flow of data. Not all BIG-IQ solutions require all four functions, so if your solution doesn't use one of those functions, you probably won't need the network infrastructure that supports that function. Additionally, understanding the data flow requirements for each function helps you understand how decisions you make regarding the number of network interfaces and the number of network subnets you use can impact the reliability, performance, and security of your BIG-IQ solution.
Knowing what data must flow between BIG-IQ components for each function helps you determine the ideal number of network interfaces needed for your BIG-IQ solution. The solution you choose and the performance levels you need determine the optimal number of interfaces you need. For example, if you use BIG-IQ just to manage your BIG-IP licenses, your setup will be very different than if you use BIG-IQ to centrally manage a set of applications across multiple data centers.
To get started, consider the generic BIG-IQ setup illustrated in this diagram.
This illustration shows a BIG-IQ system performing centralized management functions for four BIG-IP devices. Four data collection devices (DCDs), managing the data generated by the applications running on the BIG-IP devices. One way to understand the data flow requirements of this system is to think of the flow hierarchy.
  1. The BIG-IQ uses an out of band (OOB) subnet to perform internal management functions and to facilitate autofailover high availability.
  2. The BIG-IQ manages your BIG-IP devices, so direct communication to each of those devices is an obvious necessity. However, to give you the insight you need for that management, the BIG-IQ needs the analytics, events, and alert data that those BIG-IP devices store on your DCDs. BIG-IQ uses the Discovery subnet to communicate with the BIG-IPs and the DCDs.
  3. Data generated by the traffic running on your BIG-IP applications routes to the DCDs that store and manage this data. This data ranges from metrics you use to analyze device and application performance to events and alerts generated by the traffic services running on those BIG-IP devices. This data flows on the Listener subnet.
  4. The DCD cluster manages your data using an Elasticsearch database. The database makes replicas of your data and distributes those replicas throughout the cluster so that no single DCD failure can put your data at risk. This data flows on the Cluster subnet.
Best practices for which interface to route to which subnet is spelled out in this table.
Primary Functions
Management out-of-band
Best practice is to use the eth0, out-of-band (OOB) interface to communicate with the BIG-IQ CM. The 100 Mb interface speed is not a problem for the modest amounts of data required for this function.
BIG-IQ uses the Discovery function to communicate with the BIG-IP devices it manages and the BIG-IQ DCDs that manage the data. Best practice is to use a dedicated, Discovery self IP interface and subnet for this communication. Depending on your interface configuration, the eth1 interface has 10-100x more bandwidth than the OOB, management (mgmt) interface.
BIG-IQ CM and DCDs use the Cluster function to route and manage the Elasticsearch (ES) data replicas that store your data. BIG-IQ CM and all of the DCDs in the ES cluster use this communication channel. Best practice is to use the eth2 interface for this communication.
BIG-IQ DCDs use the Listener function to receive data from application traffic event logging and alerts; as well as performance analytics from the BIG-IP devices. Best practice is to use the eth3 interface for this communication.
The interfaces on a BIG-IQ Virtual Edition (VE) are commonly referred to as eth0-ethn, while the interfaces on hardware platforms are referred to as 1.0-1.n. Because BIG-IQ VE is the more common use case, in this article the term eth0 will be used to describe either eth0 on a VE and interface or 1.0 on a hardware platform.