fix: adjust transilvan-new disk to 20+100GB for 130GB constraint, drop Beszel/Telegraf, document Redis stays local

This commit is contained in:
Malin
2026-05-29 08:13:55 +02:00
parent 68f69c30ea
commit 3c4bdae145

View File

@@ -37,7 +37,7 @@ Both nodes are VMs running on separate bare-metal hosts within the same datacent
| Cache on disk | 4.8GB (W3TC page cache — throwaway) |
| WP code | ~700MB (core + plugins + themes) |
| DB connection | `DB_HOST=transilvan` resolved via /etc/hosts → Tailscale IP |
| Monitoring | Telegraf, Beszel agent, Wazuh agent, Five Nines agent |
| Monitoring | Telegraf, Beszel agent, Wazuh agent, Five Nines agent (all dropped in migration) |
| Security | Fail2ban, SSHGuard, sshguard |
| Mail | Postfix + MTA-STS (SMTP plugin used, local MTA not needed) |
| Panel | AApanel (btpanel) |
@@ -55,7 +55,7 @@ Both nodes are VMs running on separate bare-metal hosts within the same datacent
| DB user | `sql_sibiuindepen` |
| Data directory | /www/server/data (~9.6GB raw) |
| Config | /etc/mysql/mariadb.cnf + conf.d/ |
| Monitoring | Telegraf, Beszel agent, Wazuh agent, Five Nines agent |
| Monitoring | Telegraf, Beszel agent, Wazuh agent, Five Nines agent (all dropped in migration) |
| Panel | AApanel (btpanel) |
| Binlog | Active (mysql-bin.*, high sequence numbers) |
@@ -120,10 +120,10 @@ PHP 8.5 (ports build) recordsize=16K (InnoDB optimal)
xml, zip, exif, fileinfo pf: 3306 from dracula Tailscale IP only
nginx fastcgi_cache (filesystem) Tailscale
Redis (pkg, unix socket) SSH on Tailscale only
pf: 80 from NPM Tailscale IP only Telegraf, Beszel
pf: 80 from NPM Tailscale IP only Proxmox native monitoring
Tailscale
SSH on Tailscale only
Telegraf, Beszel
Proxmox native monitoring
```
### What is dropped
@@ -134,8 +134,10 @@ Telegraf, Beszel
| Memcached | Replaced by Redis (unix socket, faster, simpler) |
| Fail2ban / SSHGuard | No public SSH port, Tailscale-only |
| Postfix / sendmail | SMTP plugin in use, no local MTA needed |
| Wazuh agent | Not mandatory per requirements |
| Five Nines agent | Not mandatory per requirements |
| Wazuh agent | Not required |
| Five Nines agent | Not required |
| Beszel agent | Not required — Proxmox native monitoring covers VM metrics |
| Telegraf | Not required — Proxmox native monitoring covers VM metrics |
| memory-cleanup.sh | Linux /proc hack, was on wrong server anyway |
| ngxblocker | Not applicable to new stack |
| AApanel cron scripts | acme renewal, site_total, backup.py — all panel-specific |
@@ -152,10 +154,10 @@ Telegraf, Beszel
## Host Hardware
| Host | CPU | Logical CPUs | RAM | Storage | VM |
|---|---|---|---|---|---|
| dracula host | Xeon E5-1620 v2 @ 3.70GHz | 8 (4 cores + HT) | 64GB | Datacenter HDD | dracula-new (web) |
| transilvan host | Xeon E5-1620 v2 @ 3.70GHz | 8 (4 cores + HT) | 32GB | SSD | transilvan-new (db) |
| Host | CPU | Logical CPUs | RAM | Storage | Available to VMs | VM |
|---|---|---|---|---|---|---|
| dracula host | Xeon E5-1620 v2 @ 3.70GHz | 8 (4 cores + HT) | 64GB | Datacenter HDD | ~full | dracula-new (web) |
| transilvan host | Xeon E5-1620 v2 @ 3.70GHz | 8 (4 cores + HT) | 32GB | SSD (160GB total, ~130GB free after Proxmox) | 130GB | transilvan-new (db) |
Both hosts run Proxmox VE (confirmed via qemu-guest-agent on current VMs). New VMs are the sole tenants on their respective hosts.
@@ -198,13 +200,16 @@ HDD is acceptable for the web node. The fastcgi_cache working set for a news sit
|---|---|
| vCPU | 4 |
| RAM | 26GB |
| Disk 1 — OS | 40GB virtual (SSD-backed) |
| Disk 2 — ZFS data pool | 150GB virtual (SSD-backed) |
| Disk 1 — OS | 20GB virtual (SSD-backed) |
| Disk 2 — ZFS data pool | 100GB virtual (SSD-backed) |
| Total disk | 120GB — fits within 130GB available, 10GB buffer for Proxmox overhead |
| Balloon | **Disabled** — memory ballooning must not reclaim InnoDB buffer pool RAM |
RAM breakdown: innodb_buffer_pool_size 20GB + MySQL overhead 2GB + OS 4GB.
Both virtual disks originate from the same physical SSD pool in Proxmox. Separation is logical: independent sizing, clean `zpool create data /dev/da1`, ZFS snapshots on the data disk without touching the OS disk, and easy future migration if a dedicated physical disk is added to the host.
**Disk sizing rationale:** FreeBSD base installs to ~2GB; 20GB for the OS disk is generous for binaries, ports tree fragments, and logs. The 100GB ZFS data pool provides: 9.6GB current dataset (likely 67GB after lz4 compression), 7 days of compressed mysqldumps (~4GB each = ~28GB), binlog rotation buffer (expire_logs_days = 3), and substantial growth headroom at the current data trajectory.
Both virtual disks originate from the same physical SSD pool in Proxmox. Separation is logical: independent sizing, clean `zpool create data /dev/da1`, ZFS snapshots on the data disk without touching the OS disk, and straightforward future migration if a dedicated physical disk is added to the host.
---
@@ -266,13 +271,13 @@ qm create 201 \
--net0 virtio,bridge=vmbr0 \
--ostype other \
--scsihw virtio-scsi-single \
--scsi0 local:40,format=raw,discard=on,ssd=1 \
--scsi0 local:20,format=raw,discard=on,ssd=1 \
--cdrom local:iso/FreeBSD-14.2-RELEASE-amd64-disc1.iso \
--boot order=ide2;scsi0 \
--agent enabled=1
# Add second disk for ZFS data pool
qm set 201 --scsi1 local:150,format=raw,discard=on,ssd=1
qm set 201 --scsi1 local:100,format=raw,discard=on,ssd=1
```
`--balloon 0` disables memory ballooning on the DB VM. This is required — ballooning can silently reclaim pages from the InnoDB buffer pool under host memory pressure.
@@ -896,4 +901,5 @@ zfs snapshot data/mysql@post-migration-$(date +%Y%m%d)
- [ ] W3TC features in use beyond caching: minify? If yes, switch to standalone nginx-based minification or keep W3TC minify only with nginx page cache
- [ ] ZFS pool disk — confirm second disk available on transilvan-new VM
- [ ] MySQL 8.4 vs MariaDB 11.4 LTS — plan targets MySQL 8.4; revisit if preferred
- [ ] Beszel and Telegraf — confirm if keeping on new stack (both have FreeBSD builds)
- [x] Beszel and Telegraf — dropped. Proxmox native VM monitoring is sufficient.
- [x] Redis placement — local to dracula-new (unix socket). No 3rd host. WordPress object cache uses 50150MB RAM; a dedicated VM would cost more resources than Redis itself consumes. A separate Redis host is only justified when scaling to multiple web nodes sharing a single cache.