From 1c6ab0fa68de93e95c6525c755a1711f29149f30 Mon Sep 17 00:00:00 2001 From: Marius Date: Fri, 28 Aug 2026 11:26:35 +0300 Subject: [PATCH] fix(cluster): retentie snapshot pe destinatie + PATH in alerta, si cauza din spatele resetarilor USB Trei lucruri gasite continuand handoff-ul de la incidentul pveelite. 1. Replicarea oracle-backups taia snapshoturile doar pe sursa. Pe destinatie nu curata nimeni, deci din 25.04 se adunasera 11.886 snapshoturi tinand 941G pe pvemini - nodul cu toata productia, ajuns la 93%. Adaugat KEEP_SNAPS_DEST=288 (72h). Dupa curatarea restantei: 93% -> 44%, 1,01T liberi. Verificat ca rularea cron urmatoare pastreaza fix 288. Stergerea pe interval (ds@a%b) prinde si snapshoturile @failback_/@init_ dintre capete, deci scriptul sterge cate unul; intervalul s-a folosit o singura data, manual, dupa ce s-a verificat ca nu exista non-repl_. 2. pvemini-down-alert.sh rula din cron fara PATH, iar ha-manager e in /usr/sbin: sectiunea "HA status" iesea goala tacut la fiecare alerta. 3. Resetarile adaptorului USB LAN nu erau intamplatoare. Un mouse optic defect se re-enumera de ~1000 de ori pe zi pe acelasi controller xHCI (0000:00:14.0) ca adaptorul de retea; tastatura de pe acelasi hub are o singura enumerare. Erorile "xhci_hcd WARN Set TR Deq Ptr" apar lipite de fiecare resetare r8152, la 3 secunde dupa cate o re-enumerare a mouse-ului. Portul mouse-ului dezactivat din sysfs ca experiment reversibil. Punctul cu exportul NFS "inexistent" din planul de preventie era alarma falsa: exportul e viu, doar ca nu e storage Proxmox. Marcat ca atare. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8 --- .../cluster/failover/pvemini-down-alert.sh | 5 + .../incidents/2026-08-27-pveelite-down.md | 120 +++++++++++++++++- .../scripts/zfs-replicate-oracle-backups.sh | 20 +++ 3 files changed, 138 insertions(+), 7 deletions(-) diff --git a/proxmox/cluster/failover/pvemini-down-alert.sh b/proxmox/cluster/failover/pvemini-down-alert.sh index 34f49b3..3c98c96 100755 --- a/proxmox/cluster/failover/pvemini-down-alert.sh +++ b/proxmox/cluster/failover/pvemini-down-alert.sh @@ -4,6 +4,11 @@ # Stateful: alertează o dată după 2 minute consecutive DOWN, reset la UP set -euo pipefail +# Cron rulează cu PATH minimal (/usr/bin:/bin). ha-manager e în /usr/sbin, deci +# fără linia asta secțiunea "HA status" din alertă iese goală, tăcut: +# /opt/scripts/pvemini-down-alert.sh: line 38: ha-manager: command not found +export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" + PRIMARY_IP=10.0.20.201 STATE=/var/run/pvemini-down-alert.state MAIL_TO=mmarius28@gmail.com diff --git a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md b/proxmox/cluster/incidents/2026-08-27-pveelite-down.md index 9db07f3..22099c6 100644 --- a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md +++ b/proxmox/cluster/incidents/2026-08-27-pveelite-down.md @@ -5,8 +5,10 @@ dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și repli pveelite e oprită) **Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email) **Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică) -**Status:** **REZOLVAT** — cauză confirmată din jurnal. Rămâne o acțiune de fond: -mutarea rețelei de pe adaptorul USB pe `eno1` +**Status:** **REZOLVAT** — cauză confirmată din jurnal. Pe 28.08 s-a găsit și cauza din +spatele ei: un **mouse USB defect** care se re-enumera de ~1.000 de ori pe zi pe **același +controller xHCI** ca adaptorul de rețea (vezi secțiunea dedicată). Portul lui e dezactivat +din 11:24, ca experiment reversibil. Rămâne acțiunea de fond: mutarea rețelei pe `eno1` **Author:** Claude Code (mmarius28@gmail.com) --- @@ -110,6 +112,66 @@ pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O. --- +### DE CE se reseta adaptorul: un mouse defect (2026-08-28, ora 11:20) + +Secțiunea de mai sus explică *ce* s-a rupt — interfața recreată, nereatașată în punte. Nu +explica însă **de ce adaptorul se reseta**, iar concluzia implicită („adaptoarele USB de +rețea sunt nesigure prin natura lor") s-a dovedit greșită. + +**Un mouse optic defect, pe același controller xHCI, se re-enumera de o mie de ori pe zi.** + +| Dispozitiv | Port | Re-enumerări în boot-ul curent (43 h) | +|---|---|---| +| USB Optical Mouse (PixArt, `0461:4e84`) | hub `1-1`, port 1 | **1.127** — una la ~60 s | +| USB Multimedia Keyboard (Logitech, `046d:c313`) | hub `1-1`, port 4 | **1** | + +Tastatura, pe **același hub**, e perfect stabilă. Asta elimină hub-ul, cablul spre hub și +controllerul ca vinovați: defectul e în mouse (sau în cablul lui). + +Mouse-ul stă pe root hub-ul USB2, adaptorul LAN pe cel USB3, dar **ambele atârnă de același +controller PCI, `xhci_hcd 0000:00:14.0`**: + +``` +/sys/devices/pci0000:00/0000:00:14.0 <- mouse (usb1 / 1-1.1) +/sys/devices/pci0000:00/0000:00:14.0 <- adaptor LAN (usb2 / 2-3) +``` + +Lanțul se vede curat la resetul din 28.08, ora 10:31 — mouse-ul se re-enumeră, iar +**trei secunde mai târziu** controllerul dă eroare și placa de rețea cade colateral: + +``` +10:31:36 usb 1-1.1: new low-speed USB device number 90 <- mouse, a 90-a oară +10:31:39 r8152-cfgselector 2-3: USB disconnect, device number 6 +10:31:39 xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. +10:31:39 r8152 2-3:1.0 enx6c1ff71abe67: Tx status -108 +``` + +Toate cele 3 erori `xhci_hcd ... WARN` din boot-ul curent apar lipite de câte o resetare +r8152. Aceeași eroare deschide și citatul de la 16:01:45 din secțiunea precedentă — deci +și căderea de 16 ore intră pe același tipar. + +**Mitigare aplicată la 11:24:04** — portul mouse-ului dezactivat din sysfs, fără acces fizic: + +```bash +echo 1 > /sys/bus/usb/devices/1-1:1.0/1-1-port1/disable # anulare: echo 0 +``` + +Mouse-ul dispare din `lsusb`, tastatura rămâne. **NU e persistent la reboot** — e deliberat, +ca să fie un experiment reversibil, nu o reparație. + +**De verificat înainte de a declara cauza confirmată:** dacă până la următoarea repornire nu +mai apare nicio resetare `r8152`, ipoteza e validată și mitigarea merită făcută permanentă +(regulă udev sau, mai bine, mouse-ul scos fizic — pveelite e nod headless). + +```bash +ssh root@10.0.20.202 'journalctl --since "2026-08-28 11:24" | grep -cE "r8152.*reset|xhci_hcd 0000:00:14.0: WARN"' +``` + +> Mutarea pe `eno1` rămâne validă și după asta — scoate rețeaua nodului de pe magistrala USB +> cu totul. Dar ea era tratamentul; abia acum se știe boala. + +--- + ### Ipoteza alternativă, formulată înainte de confirmare **pveelite are placă de rețea pe USB**, iar deconectarea ei e modul de defectare deja @@ -326,9 +388,26 @@ nu era oprită, ci pornită și fără rețea. Un magic packet nu are ce trezi. `eno1`, WoL devine însă realmente utilizabil, pentru că e placă integrată, alimentată în soft-off — spre deosebire de un dongle USB. -**5. Textul alertei — scos exportul NFS inexistent.** -`/opt/scripts/pveelite-down-alert.sh` menționează `10.0.20.202:/mnt/pve/oracle-backups`, care -nu mai e în `storage.cfg`. Cine citește alerta la 3 noaptea o ia pe o pistă falsă. +**5. ~~Textul alertei — scos exportul NFS inexistent.~~ ALARMĂ FALSĂ, verificat 28.08.** +Se afirmase că `/opt/scripts/pveelite-down-alert.sh` menționează un export +`10.0.20.202:/mnt/pve/oracle-backups` care nu mai există, pentru că nu apare în +`storage.cfg`. **Exportul există și e viu** — nu e storage Proxmox, ci export NFS la nivel +de sistem către mașina de DR: + +``` +# /etc/exports pe pveelite — exportfs -v +/mnt/pve/oracle-backups 10.0.20.37(rw,sync,no_subtree_check,no_root_squash) +``` + +`nfs-server` e `active`, iar datasetul a primit backup-uri RMAN pe 28.08 la 10:11 (`L0_ROA_20260828`, +6 GB), imediat după revenirea nodului. **Textul alertei e corect, nu se atinge.** Lecția e de +metodă: absența din `storage.cfg` nu înseamnă absența exportului. + +**5-bis. `ha-manager: command not found` în alerta de pe pveelite — REPARAT 28.08.** +`/opt/scripts/pvemini-down-alert.sh` rula din cron cu PATH minimal (`/usr/bin:/bin`), iar +`ha-manager` e în `/usr/sbin`. Secțiunea „HA status" ieșea goală la fiecare declanșare, tăcut. +Adăugat `export PATH=...` — la fel cum avea deja `pveelite-down-alert.sh`. Verificat cu +`env -i PATH=/usr/bin:/bin`: comanda se rezolvă și întoarce `quorum OK`. ### 🟡 Tier 2 @@ -339,8 +418,35 @@ mecanism care să repare sau măcar să semnaleze o cădere de rețea. Nodul ră sănătos și invizibil. Merită o alertă de repetiție (nu doar una la început de incident) sau un al doilea inel corosync pe `eno1`, care ar fi ținut nodul în cluster peste căderea USB. -**7. `local-zfs` pe pvemini la 92 %.** -Separat de incident, dar pe același nod pe care stă acum toată producția. +**7. ~~`local-zfs` pe pvemini la 92 %.~~ REZOLVAT 28.08 — 93 % → 44 %.** +Nu era creștere organică. Replicarea `rpool/oracle-backups` (pveelite → pvemini, la 15 min) +**tăia snapshoturile doar pe sursă**: + +```bash +KEEP_SNAPS=5 # rolling history on source side +``` + +Pe destinație nu curăța nimeni, niciodată. Din 25.04 se adunaseră **11.886 snapshoturi care +țineau 941 GB** — pe nodul cu toată producția. Problema era invizibilă de pe pveelite, unde +datasetul arăta cuminte, cu 6 snapshoturi. + +Reparat în [`zfs-replicate-oracle-backups.sh`](../../vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh): +`KEEP_SNAPS_DEST=288` (288 × 15 min = 72 h de puncte de recuperare pe destinație, față de +75 de minute pe sursă). Restanța ștearsă pe interval, cu dry-run înainte: + +``` +pvemini rpool: 93 % / 118 G liberi -> 44 % / 1,01 T liberi +rpool/oracle-backups: 955 G -> 45,3 G snapshoturi: 11.886 -> 288 +``` + +Verificat în producție: rularea cron de la 11:15 a adăugat un snapshot și a tăiat cel mai +vechi — destinația a rămas fix la 288. + +> **Capcană, dacă vreodată se rescrie curățarea:** ștergerea pe interval (`zfs destroy +> ds@a%b`) prinde **toate** snapshoturile dintre capete, inclusiv `@failback_` / `@init_`, +> nu doar cele cu prefixul căutat. De aceea scriptul șterge câte unul (`xargs -n1`), unde +> oricum e un singur snapshot pe rulare; intervalul s-a folosit o singură dată, manual, +> după ce s-a verificat că pe destinație nu există niciun snapshot non-`repl_`. --- diff --git a/proxmox/vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh b/proxmox/vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh index 680a149..a337900 100644 --- a/proxmox/vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh +++ b/proxmox/vm109-windows-dr/scripts/zfs-replicate-oracle-backups.sh @@ -27,6 +27,7 @@ DATASET="rpool/oracle-backups" TARGET_HOST="10.0.20.201" # pvemini direct IP (avoids tailscale magicDNS detour) SNAP_PREFIX="repl" KEEP_SNAPS=5 # rolling history on source side +KEEP_SNAPS_DEST=288 # rolling history on destination (288 x 15 min = 72h) LOCK="/var/run/zfs-replicate-oracle-backups.lock" LOG="/var/log/oracle-dr/replication.log" SSH_OPTS="-o UserKnownHostsFile=/etc/pve/priv/known_hosts -o StrictHostKeyChecking=no -o BatchMode=yes" @@ -70,4 +71,23 @@ zfs list -t snapshot -o name -s creation "$DATASET" \ | head -n -${KEEP_SNAPS} \ | xargs -r -n1 zfs destroy 2>>"$LOG" || true +# Prune old snapshots on destination (keep last KEEP_SNAPS_DEST). +# +# Fara pasul asta destinatia nu taia nimic, niciodata. Intre 25.04 si 28.08.2026 +# s-au adunat 11886 snapshoturi care tineau 941G si urcasera rpool-ul pvemini la +# 93% - cu productia pe acelasi pool. Sursa se curata singura de la inceput, deci +# problema a fost invizibila pe pveelite. +# +# Se sterge cate un snapshot pe rulare (xargs -n1), NU pe interval (@a%b): un +# range ar cuprinde si eventualele snapshoturi @failback_/@init_ prinse intre +# capete, care trebuie sa supravietuiasca. In regim normal e un singur destroy +# la fiecare rulare, deci costul e neglijabil. +if ! ssh $SSH_OPTS root@${TARGET_HOST} \ + "zfs list -t snapshot -o name -H -s creation -r '$DATASET' \ + | awk -v p='${DATASET}@${SNAP_PREFIX}_' '\$0 ~ p' \ + | head -n -${KEEP_SNAPS_DEST} \ + | xargs -r -n1 zfs destroy" 2>>"$LOG"; then + log "WARNING: prune pe destinatie a esuat (replicarea a reusit)" +fi + log "Replication completed successfully"