Planning Architecture and Nodes

Pigsty uses a modular architecture. Select the modules for your requirements and define the deployment through declarative configuration.

Common Patterns

Use these common deployment patterns as a starting point. Adjust the configuration for your requirements:

Select the architecture for your reliability requirements and available resources. Production deployments with full high availability require at least 3 nodes. With 2 nodes, use the Semi-HA configuration.

Trade-offs

• Monitoring requires at least 1 INFRA node. Production typically uses 2 nodes; large deployments use 3.
• PostgreSQL HA requires at least 1 ETCD node. Production typically uses 3 nodes; large deployments use 5. An even-member ETCD cluster tolerates no more failures than an odd-member cluster with one fewer member. Prefer an odd number of members.
• Silo object storage requires at least 1 MINIO node. Production typically uses 4 or more nodes in an MNMD cluster.
• Production PostgreSQL clusters typically have at least two nodes: a primary and a replica. More demanding deployments use 3 nodes. Deployments with high read loads can have dozens of replicas.
• Advanced PostgreSQL configurations include offline instances, synchronous instances, standby clusters, and delayed clusters.

Single-Node Setup

The single-node configuration puts all components on one node. It installs four core modules by default. Use it for demonstrations, development, or testing.

An external S3/MinIO backup repository can supply the required recovery time and recovery point objectives (RTO/RPO). With this protection, a single-node configuration can serve standard production environments.

These single-node variants are available:

• Rich (rich) is a production template with local Silo storage, a local software repository, and all PostgreSQL extensions.
• Slim (slim) installs PGSQL and ETCD without the monitoring infrastructure. Slim Installation can expand to multiple nodes with HA.
• Infra-only (infra) installs only INFRA to monitor other instances. It does not install database services.
• Alternative kernels replace the standard PostgreSQL kernel with a derivative. Templates include pgsql, mssql, polar, ivory, and mysql. Other templates include pgtde, oriole, agens, and pgedge.

Two-Node Setup

The two-node configuration enables database replication and Semi-HA. It improves data redundancy and supplies limited automatic failover:

Automatic recovery depends on which node fails:

• If node-1 fails, manually promote node-2. Automatic failover is unavailable.
• If node-2 fails, node-1 is automatically promoted.

Three-Node Setup

The three-node template deploys INFRA, ETCD, PGSQL, and MINIO (Silo) on every node. It tolerates one node failure when the remaining two can communicate and replica state permits failover. Silo uses a three-node, single-drive-per-node EC:1 pool. An existing single-node object store cannot be expanded directly into this topology; create a new pool and migrate objects.

Four-Node Setup

The Pigsty Sandbox uses the standard four-node configuration.

In the demonstration configuration, INFRA and ETCD do not have HA. You can extend the configuration as follows:

More Nodes

The ha/simu simulation template and vagrant/spec/simu.rb currently use 20 nodes, separating key services into groups:

This template simulates functionality and production topology. Size real production deployments and choose service placement according to capacity, failure domains, and dependencies.