On-Prem VM Setup
#16 1 pagesDatabases on VMs (On-Prem)
Running stateful databases on bare VMs — firewall rules, config tuning, replica set bootstrap, user management, and Prometheus monitoring for each database.
Why VMs Instead of Kubernetes?
Running databases directly on VMs skips the Kubernetes storage and operator layer — simpler to reason about, easier to tune at the OS level, and often the only option when Kubernetes isn't available or the team doesn't have K8s expertise.
When VMs make more sense than K8s:
- On-prem infrastructure without a Kubernetes platform
- Teams that are strong on Linux/systemd but not on K8s storage and operators
- Databases that need direct NUMA/CPU pinning or non-standard kernel tuning
- Compliance environments where workload isolation must be at the hypervisor level
Why would a team choose to run databases on bare VMs instead of Kubernetes, even if Kubernetes is available?
Files
| File | Database | Topics |
|---|---|---|
| mongodb.md | MongoDB | Replica set on VMs, firewall rules, mongod.conf, cacheSizeGB, users, write concern, mongodb-exporter |
Common Patterns
graph TD
classDef primary fill:#e74c3c,stroke:#c0392b,color:#fff
classDef replica fill:#3498db,stroke:#2980b9,color:#fff
classDef arbiter fill:#f39c12,stroke:#d68910,color:#fff
P["Primary VM<br/>accepts all writes<br/>holds full data"]:::primary
S["Secondary VM<br/>tails oplog / WAL<br/>read-only traffic"]:::replica
A["Arbiter VM<br/>vote-only<br/>no data copy"]:::arbiter
P -->|"replication stream"| S
P -->|"heartbeat"| A
S -->|"heartbeat"| A
In the diagram above, why does the replication stream flow only from Primary → Secondary, while heartbeats are bidirectional between all three nodes?
Firewall rules come first. Every VM-based cluster depends on nodes reaching each other on the database port. Set rules and verify with nc -zv before touching any config file — a firewall problem looks identical to a config bug and wastes hours.
What is the recurring four-step pattern across every VM-hosted database setup, regardless of which database you are deploying?
nc -zv before touching any config file. 2. Config tuning — adjust the database config file (mongod.conf, postgresql.conf, etc.) for memory limits, bind addresses, replication settings, and OS-level parameters like huge pages and open-file limits. 3. Replica setup — bootstrap the replica set or standby so data is durably replicated before taking any production traffic. 4. Monitoring — wire up a Prometheus exporter (mongodb-exporter, postgres-exporter, etc.) from day one so the cluster is observable before the first outage, not after it.