Prerequisites
Installation Prerequisites
Bindplane Instance Sizing
Bindplane's resource requirements will differ based on the number of managed collectors. CPU, Memory, Disk throughput / IOPS, and network consumption will increase as the number of managed collectors increases.
Follow this table for CPU, memory, and storage capacity sizing.
| Collector Count | Bindplane Nodes | Fault Tolerance | CPU Cores | Memory | Database |
|---|---|---|---|---|---|
| 1-100 | 1 | N/A | 2 | 4GB | bbolt |
| 100-25,000 | 1 | N/A | 4 | 16GB | postgres |
| 1-60,000 | 3 | 1 | 2 | 8GB | postgres |
| 60,000-125,000 | 5 | 1 | 2 | 8GB | postgres |
| 125,000-250,000 | 10 | 2 | 2 | 8GB | postgres |
note
Postgres is required for production deployments of Bindplane. Bbolt should only be used for proof of concept deployments.
note
When exceeding 25,000 collectors, it is recommended to operate Bindplane in High Availability.
High Availability and Fault Tolerance
When operating Bindplane in High Availability, you need to consider how many collectors you expect a single Bindplane instance to handle.
Take the total number of Bindplane instances, and subtract the maximum number of nodes you expect to become unavailable due to maintenance. It is important to make sure each node is not responsible for more than 30,000 collectors during a node outage. See Load Balancer Connection Constraints for details.
Load Balancer Connection Constraints
Most load balancers will be limited to roughly 65,535 connections per backend instance. When sizing your Bindplane cluster, you must consider how many collectors each node will be responsible for during maximum fault tolerance. A good rule of thumb is to not exceed 30,000 collectors. This is because each collector will open two connections to Bindplane. One for OpAMP remote management, and one for publishing throughput metrics.
If you have 100,000 collectors, a cluster size of three would be insufficient as each node would be responsible for roughly 33,000 collectors. 33,000 collectors * 2 results in 66,000 TCP connections to each Bindplane instance. This situation gets worse if you bring one node down for maintenance, as each Bindplane instance would become responsible for 50,000 collectors, or 100,000 TCP connections.
Postgres Sizing
When using PostgreSQL storage back-end, performance is generally limited by the number of CPU cores and Memory available. It is recommended that the storage backing Postgres be low latency (SSD) and capable of high throughput.
| Collector Count | CPU Cores | Memory |
|---|---|---|
| 1-60,000 | 4 | 16GB |
| 60,000-125,000 | 8 | 32GB |
| 125,000-250,000 | 16 | 64GB |
Network Requirements
Bandwidth
Bindplane maintains network connections for the following:
- Collector Management
- Collector Throughput Measurements
- Command line and Web user interfaces
Maximum network throughput scales linearly with the number of connected collectors. As a rule of thumb, expect to consume 265B/s for every connected collector, or 2.12Mbps per 1,000 collectors.
Firewall
Bindplane can run on a local area network and behind a firewall.
Bindplane does not need to be reachable from the internet, however, if collectors. or users outside of your WAN require access, a VPN or inbound firewall rules must be configured to allow access.
Ports
Bindplane listens on port 3001 by default. This port is configurable. See the configuration documentation.
The Bindplane port is used for:
- Collector command and control using the Open Agent Management Protocol (OpAMP) (Websocket)
- Collector throughput measurement requests (HTTP POST request)
- Browser and CLI users (HTTP and Websocket)
Browsers and API Clients
The firewall must allow HTTP traffic to reach Bindplane on the configured port.
Collectors
Collectors must be able to initiate connections to Bindplane for OpAMP (websocket) and throughput measurements (HTTP). Bindplane will never initiate connections to the collector. The firewall can be configured to prevent Bindplane from reaching the collector networks, however, collector networks must be able to reach Bindplane on the configured port.
Collector Updates
Bindplane will reach out to github.com/observIQ/bindplane-agent/releases to detect new collector releases. This feature is optional.
You can disable Github polling by setting agentVersions.syncInterval to 0 in your Bindplane configuration.