Nodes

A node represents hardware resources and an operating system. It can be a physical server, virtual machine, container, or pod.

A node needs a Linux OS, systemd, and standard CPU, memory, disk, and network resources.

Install modules on nodes. The installed modules determine the node type:

In a single-node deployment, one node has all roles: regular, administration, infrastructure, ETCD, and database.

Regular Node

Use node.yml to configure managed nodes to the target state. A regular node can run these services:

node_exporter, vector, and haproxy are enabled by default. They export host metrics, collect logs, and balance traffic. Docker, keepalived, and keepalived_exporter are optional.

ADMIN Node

A deployment has exactly one administration node that runs Ansible playbooks and issues deployment or management commands.

This node has ssh/sudo access to every other node. Restrict access carefully. See Security Model: Trust Boundaries for its trusted access and critical assets.

During single-node installation and configuration, the current node becomes the administration node. A laptop with Ansible and SSH access to all managed nodes can also serve this role. This is not recommended for production.

For example, a laptop managing a cloud Pigsty VM is the administration node.

Production installations usually reserve 1–2 DBA machines for administration. With limited resources, INFRA nodes can also perform administration. All infrastructure nodes have Ansible by default.

INFRA Node

A Pigsty deployment may have 1 or more INFRA nodes; large production environments typically have 2-3.

The infra group in the inventory defines which nodes are INFRA nodes. These nodes run the INFRA module with these components:

Nginx provides the module Web UI and software repository. Services on multiple infrastructure nodes are independent. Each Grafana can access all monitoring data sources.

Pigsty is licensed under Apache-2.0, though embedded Grafana component uses AGPLv3.

ETCD Node

The ETCD module provides Distributed Consensus Service (DCS) for PostgreSQL high availability.

The etcd group in the inventory defines ETCD nodes. These nodes run etcd servers on two ports:

MINIO Node

The MINIO module provides optional backup storage for PostgreSQL.

The minio inventory group defines MINIO module nodes. In v4.5.0, these nodes run Silo servers on:

PGSQL Node

A PGSQL node has the PGSQL module. Each node runs one PostgreSQL instance, giving a 1:1 mapping.

node_id_from_pg lets a PGSQL node use its PostgreSQL instance name. The default is true.

PGSQL nodes run these additional components beyond regular node services:

vip-manager runs only when a PG VIP is configured. Define custom services through pg_services. haproxy exposes them on additional ports.

Node Relationships

Regular nodes normally select an INFRA node with admin_ip. For example, global admin_ip = 10.10.10.10 directs nodes to services at that address.

Parameters that reference ${admin_ip}:

The administration node usually also provides infrastructure. With multiple infrastructure nodes, the first usually administers the environment and others provide backups.

Large deployments can separate administration from infrastructure. For example, use 1–2 small DBA-managed administration hosts and 2–3 high-capacity physical monitoring servers.

Typical node counts by deployment scale: