mirror of https://github.com/hashicorp/boundary
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
234 lines
12 KiB
234 lines
12 KiB
---
|
|
layout: docs
|
|
page_title: System requirements
|
|
description: >-
|
|
Learn about Boundary system requirements including recommendations for hardware sizing, network connectivity, traffic encryption, databases, and load balancers.
|
|
---
|
|
|
|
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
|
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
|
|
|
# System requirements
|
|
|
|
This topic contains specific recommendations for system requirements.
|
|
|
|
<Note>
|
|
|
|
All specifications outlined in this topic are minimum recommendations without
|
|
any reservations towards vertical scaling, redundancy, or other site reliability
|
|
needs.
|
|
|
|
All resource requirements are directly proportional to the operations
|
|
performed by the Boundary cluster, and the end users' level of usage.
|
|
|
|
</Note>
|
|
|
|
To match your requirements and maximize the stability of your Boundary
|
|
controller and worker instances, perform load tests and monitor
|
|
resource usage including reported matrices from Boundary's telemetry.
|
|
|
|
Refer to [Monitor Boundary](/boundary/docs/monitor) for
|
|
more information.
|
|
|
|
## Hardware sizing for Boundary servers
|
|
|
|
Refer to the tables below for sizing recommendations for controller nodes and
|
|
worker nodes, as well as small and large use cases based on expected usage.
|
|
|
|
Controller nodes
|
|
|
|
| Size | CPU | Memory | Disk capacity | Network throughput |
|
|
|-------|------------|----------------|---------------|--------------------|
|
|
| Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 5 Gbps |
|
|
| Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps |
|
|
|
|
Worker nodes
|
|
|
|
| Size | CPU | Memory | Disk capacity | Network throughput |
|
|
|-------|------------|----------------|---------------|--------------------|
|
|
| Small | 2 - 4 core | 8 - 16 GB RAM | 50+ GB | Minimum 10 Gbps |
|
|
| Large | 4 - 8 core | 32 - 64 GB RAM | 100+ GB | Minimum 10 Gbps |
|
|
|
|
To ensure predictable performance, we recommend that you
|
|
avoid "burstable" CPU and storage options whose performance may degrade
|
|
under continuous load.
|
|
|
|
## Hardware considerations
|
|
|
|
The Boundary controller and worker nodes perform two different tasks.
|
|
The Boundary controller nodes handle requests for authentication and
|
|
configuration.
|
|
The Boundary worker nodes proxy client connections to Boundary
|
|
targets which may require additional resources.
|
|
|
|
Depending on the number of clients connecting to Boundary targets at any given
|
|
time, Boundary workers can become memory or file descriptor constrained.
|
|
As your users create new sessions, the Boundary worker node opens more sockets and
|
|
ultimately creates additional file descriptors. Monitor both the
|
|
file descriptor usage and the memory consumption of each Boundary worker node.
|
|
|
|
## Network considerations
|
|
|
|
The amount of network bandwidth used by the Boundary controllers and workers
|
|
depends on your specific usage patterns.
|
|
For the Boundary controller, even a high request volume does not
|
|
translate to a large amount of network bandwidth consumption.
|
|
|
|
Boundary worker nodes proxy client sessions to Boundary targets. The
|
|
bandwidth consumption depends on the amount of potential clients,
|
|
the number of sessions created, and the amount of data transferred
|
|
between the user and the Boundary targets.
|
|
|
|
It is also important to consider bandwidth requirements to other external
|
|
systems such as monitoring and logging collectors.
|
|
It may be necessary to increase the size of the virtual machine to take
|
|
advantage of additional throughput in certain circumstances.
|
|
|
|
Refer to the following pages for provider-specific virtual machine networking
|
|
limitations:
|
|
|
|
- [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)
|
|
- [Azure](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-machine-network-throughput/)
|
|
- [GCP](https://cloud.google.com/compute/docs/network-bandwidth/)
|
|
|
|
## Network connectivity
|
|
|
|
The following table outlines the default ingress network connectivity
|
|
requirements for Boundary cluster nodes.
|
|
|
|
If you restrict network egress, ensure you allow outgoing access from:
|
|
|
|
- The Boundary controllers to any external integration providers (for example,
|
|
OIDC authentication providers) as well as external log handlers, metrics
|
|
collection, and security and configuration management providers.
|
|
|
|
- The Boundary workers to controllers and any upstream workers.
|
|
|
|
<Note>
|
|
|
|
If any of the default port mappings do not meet your organization's
|
|
requirements, you can update the default listening ports using the resource's
|
|
[listener](/boundary/docs/monitor/listeners) stanza.
|
|
|
|
</Note>
|
|
|
|
|
|
|
|
| Source | Destination | Default destination port | protocol | Purpose |
|
|
| --------------- | --------------------------- | ------------------------ | --------- | -------------------------------------- |
|
|
| Client machines | Controller load balancer | 443 | tcp | Request distribution |
|
|
| Load balancer | Controller servers | 9200 | tcp | Boundary API |
|
|
| Load balancer | Controller servers | 9203 | tcp | Health checks |
|
|
| Worker servers | Controller load balancer | 9201 | tcp | Session authorization, credentials, etc |
|
|
| Controllers | PostgreSQL | 5432 | tcp | Storing system state |
|
|
| Client machines | Worker servers \* | 9202 | tcp | Session proxying |
|
|
| Worker servers | Boundary targets\* | various | tcp | Session proxying |
|
|
| Client machines | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
|
|
| Egress workers | Ingress worker servers \*\* | 9202 | tcp | Multi-hop session proxying |
|
|
| Egress workers | Boundary targets \*\* | various | tcp | Multi-hop session proxying |
|
|
|
|
\* In this scenario, the client connects directly to one worker, which then
|
|
proxies the connection to the Boundary target.
|
|
|
|
** Multi-hop sessions start reverse proxy tunnels when the downstream workers
|
|
start and connect to upstream workers.
|
|
|
|
There are four steps when a client requests to connect to a target that requires
|
|
a multi-hop path:
|
|
|
|
1. The client connects to an ingress worker.
|
|
|
|
1. The ingress worker connects with the next-downstream or egress worker through
|
|
that worker's established reverse-proxy tunnel. This step may be repeated
|
|
multiple times if there are multiple worker connections in the middle of the
|
|
tunnel chain.
|
|
|
|
1. The final downstream egress worker connects to the Boundary target.
|
|
|
|
1. The client can now send data through the tunnel chain.
|
|
|
|
A multi-hop worker that acts as a downstream can start a tunnel to one or
|
|
more upstream workers, specified in the `initial_upstreams` list in the
|
|
worker configuration.
|
|
|
|
## Network traffic encryption
|
|
|
|
You should encrypt connections to the Boundary control plane at the controller
|
|
nodes using standard PKI HTTPS TLS.
|
|
|
|
You can use either a layer 4 load balancer to pass through traffic to the
|
|
Boundary controllers, or a layer 7 load balancer with no configured TLS
|
|
termination.
|
|
|
|
## Database recommendations
|
|
|
|
Boundary clusters depend on a PostgreSQL database for managing state and
|
|
configuration.
|
|
Ensure you are using a version of PostgreSQL covered under [Boundary's supported
|
|
version
|
|
policy](https://developer.hashicorp.com/boundary/docs/enterprise/supported-versions#postgresql-support-policy).
|
|
|
|
Each major cloud provider offers a managed PostgreSQL database service:
|
|
|
|
| Cloud provider | Managed database service |
|
|
|----------------|-----------------------------------------------------------------------------------------|
|
|
| AWS | [Amazon RDS for PostgreSQL](https://aws.amazon.com/rds/postgresql/) |
|
|
| Azure | [Azure database for PostgreSQL](https://azure.microsoft.com/en-us/products/postgresql/) |
|
|
| GCP | [Cloud SQL for PostgreSQL](https://cloud.google.com/sql/postgresql) |
|
|
|
|
### Database network requirements
|
|
|
|
Boundary controllers must be able to reach the PostgreSQL database.
|
|
Worker nodes do not need access to the database.
|
|
|
|
### Database users and roles
|
|
|
|
Database initialization requires elevated privileges.
|
|
When you initialize the database with the `boundary database init` command, the
|
|
Boundary database user requires the `superuser` role plus `all privileges` on
|
|
the Boundary database.
|
|
|
|
Once the database initialization is complete, the database user for a Boundary
|
|
controller requires permissions for [data
|
|
manipulation](https://www.postgresql.org/docs/current/dml.html) operations
|
|
(select, insert, update, and delete).
|
|
|
|
### Required PostgreSQL modules
|
|
|
|
Boundary has a dependency on the PostgreSQL
|
|
[pgcrypto](https://www.postgresql.org/docs/11/pgcrypto.html) module and
|
|
[citext](https://www.postgresql.org/docs/11/citext.html), which are part of the
|
|
standard modules supplied with PostgreSQL. Refer to the PostgreSQL documentation
|
|
for more information.
|
|
|
|
## Load balancer recommendations
|
|
|
|
For the highest levels of reliability and stability, we recommend that you use
|
|
some load balancing technology to distribute requests to your Boundary
|
|
controller nodes.
|
|
|
|
Boundary workers do not require any load balancing.
|
|
The Boundary controller manages load balancing for the Boundary workers when
|
|
clients initiate sessions to Boundary targets.
|
|
|
|
To monitor the health of Boundary controller nodes, configure the load balancer
|
|
to poll the `/health` API endpoint to detect the status of the node and direct
|
|
traffic accordingly.
|
|
|
|
Each major cloud provider offers one or more managed load balancing services:
|
|
|
|
| Cloud | Layer | Layer | Managing load balancing service |
|
|
|-------|---------------------|-------|----------------------------------------------------------------------------------------------------------------|
|
|
| AWS | Network | 4 | [Network load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) |
|
|
| AWS | Application | 7 | [Application load balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) |
|
|
| Azure | Network | 4 | [Azure load balancer](https://learn.microsoft.com/en-us/azure/load-balancer/) |
|
|
| Azure | Application | 7 | [Azure application gateway](https://learn.microsoft.com/en-us/azure/application-gateway/) |
|
|
| GCP | Network/Application | 4/7 | [Cloud load balancing](https://cloud.google.com/load-balancing/docs/load-balancing-overview) |
|
|
|
|
There are also a number of self-hosted options, as well as service discovery
|
|
systems like Consul.
|
|
|
|
Refer to the [listener stanza
|
|
documentation](/boundary/docs/monitor/listeners/) for more information. |