A two-node Dell OptiPlex Proxmox cluster and a Raspberry Pi running infrastructure services. The diagrams distinguish services already deployed from the next experiments.
server1 and server2 form one Proxmox cluster, so I can manage their virtual machines from the same interface.
The Raspberry Pi runs corosync-qnetd for the external quorum vote. If one node is unavailable, the remaining node can retain quorum when it can still reach the Pi.
The website and game server have separate Debian VMs. On the Dell nodes, planned container services will run inside a guest rather than directly on the Proxmox host.
A dedicated practice VM gives Linux and Bash experiments their own space. Security training takes place on online lab platforms, separately from the services I host.
Follow the network from the fibre connection to each device. Services marked “Planned” are part of the next build.
I have assigned the hosted workloads to this node so their CPU and memory needs are easier to review together.
VM boundaries let me maintain each service separately, even when they share physical hardware.
View project →The planned metrics stack has its own node, making it easier to observe hosted workloads without sharing their host.
This separation has a limit: dashboards on this node will also be unavailable if it goes down.
View project →Keeping this device outside the Dell hosts lets availability checks continue during a node outage, provided the Pi and network remain available.
Its quorum service supports cluster voting; it is not a third Proxmox host and does not run the cluster’s VMs.
View project →Next, I want to observe what happens when the layout changes.
Where does the lab run out of headroom first? Which workloads benefit from moving? I want measurements to guide the next hardware or configuration change.
My next changes will be guided by the results, rather than adding hardware without a clear purpose.
Explore the configurations, service fixes, earlier builds and security-learning examples behind the portfolio.