Prerequisites
Installation Prerequisites
BindPlane Instance Sizing
BindPlane OP's resource requirements will differ based on the number of managed agents. CPU, Memory, Disk throughput / IOPS, and network consumption will increase as the number of managed agents increases.
Follow this table for CPU, memory, and storage capacity sizing.
| Agent 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 OP. Bbolt should only be used for proof of concept deployments.
note
When exceeding 25,000 agents, 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 agents 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 agents 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 agents each node will be responsible for during maximum fault tolerance. A good rule of thumb is to not exceed 30,000 agents. This is because each agent will open two connections to BindPlane. One for OpAMP remote management, and one for publishing throughput metrics.
If you have 100,000 agents, a cluster size of three would be insufficient as each node would be responsible for roughly 33,000 agents. 33,000 agents * 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 agents, 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.
| Agent 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 OP maintains network connections for the following:
- Agent Management
- Agent Throughput Measurements
- Command line and Web user interfaces
Maximum network throughput scales linearly with the number of connected agents. As a rule of thumb, expect to consume 265B/s for every connected agent, or 2.12Mbps per 1,000 agents.
Firewall
BindPlane OP can run on a local area network and behind a firewall.
BindPlane OP does not need to be reachable from the internet, however, if agents. or users outside of your WAN require access, a VPN or inbound firewall rules must be configured to allow access.
Ports
BindPlane OP listens on port 3001 by default. This port is configurable. See the configuration documentation.
The BindPlane port is used for:
- Agent command and control using the Open Agent Management Protocol (OpAMP) (Websocket)
- Agent 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 OP on the configured port.
Agents
Agents must be able to initiate connections to BindPlane OP for OpAMP (websocket) and throughput measurements (HTTP). BindPlane OP will never initiate connections to the agent. The firewall can be configured to prevent BindPlane OP from reaching the agent networks, however, agent networks must be able to reach BindPlane OP on the configured port.
Agent Updates
BindPlane OP will reach out to github.com/observIQ/bindplane-agent/releases to detect new agent releases. This feature is optional.
You can disable Github polling by setting agentVersions.syncInterval to 0 in your BindPlane configuration.