ROMFASTSQL/proxmox/cluster/docs/switch-2.5g-dedicat-noduri.md

Switch 2.5GbE suplimentar — porturi fizice conectate pe cele 3 noduri

Data verificării: 2026-08-29 (verificat de trei ori — vezi secțiunea de măsurători) Autor: Claude Code (mmarius28@gmail.com) Status: TERMINAT pe 2026-08-29. Rețeaua dedicată de cluster 10.10.10.0/24 e activă pe toate 3 nodurile, vmbr0 a fost mutat pe interfețele onboard, uplink-ul dintre switch-uri a fost scos, iar replicarea și backup-ul NFS trec verificat pe insulă.

Completat în seara aceleiași zile: al doilea inel corosync (ring1) pe insulă, verificat prin oprirea reală a lui ring0; testul de repornire completă a clusterului, cu Wake-on-LAN. Testul a scos la iveală o linie rămasă în /etc/fstab care fixa tăcut backup-ul NFS pe rețeaua de producție. Toate trei sunt descrise mai jos. Singurul lucru rămas e opțional (MTU 9000).

---

Harta switch-urilor — starea finală, 2026-08-29

Switch 1 — insula de cluster 10.10.10.0/24 (2×10G RJ45 pe p5/p6, 4×2.5G pe p1–p4). Fără router, fără gateway. Toate cele 3 legături negociază 2.5 Gbps.

Port	Viteză port	Conectat la	IP
p1	2.5G	liber (fostul uplink către switch 2, scos)	—
p2	2.5G	pvemini — enp87s0 (Intel I226)	10.10.10.201
p3	2.5G	pve1 — enx6c1ff759e2cb (dongle USB 2.5G)	10.10.10.200
p4	2.5G	pveelite — enx6c1ff71abe67 (dongle USB 2.5G)	10.10.10.202
p5	10G	liber — rezervat pentru un PBS/NAS cu 10GBase-T	—
p6	10G	liber — rezervat pentru un PBS/NAS cu 10GBase-T	—

Ambele porturi de 10G sunt libere pe insulă — singurul loc din infrastructură unde 10G ar aduce ceva real: un PBS/NAS cu 10GBase-T pus acolo ar putea primi backup de la toate 3 nodurile simultan, la 2.5G fiecare, fără să se sufoce reciproc.

Switch 2 — producție 10.0.20.0/24 (8×2.5G):

Conectat la	Interfață	IP
pve1	eno1 (Intel I219-LM, 1G)	vmbr0 10.0.20.200
pvemini	enp90s0 (Intel I226, 2.5G)	vmbr0 10.0.20.201
pveelite	eno1 (Intel I219-LM, 1G)	vmbr0 10.0.20.202
router	—	10.0.20.1 (link 1G, internet 500 Mbps)
stația de administrare	—	—
access point	—	—

Cele două switch-uri nu mai sunt legate între ele. Switch 1 e o insulă fără gateway; switch 2 are tot ce are nevoie de internet. Switch 1 are 3 porturi libere (p1 plus ambele porturi de 10G), switch 2 are 2 porturi libere.

Hardware, pentru referință: pvemini e un Minisforum MS-01 — 2× SFP+ 10G (placa Intel X710, cage-uri goale) și 2× RJ45 2.5G (Intel I226). Nu are port RJ45 de 10G. pve1 și pveelite au onboard Intel I219-LM (1G) plus câte un dongle USB Realtek r8152 (2.5G).

---

Ce am verificat

Switch-ul nou a fost conectat la portul de rezervă (neutilizat) de pe fiecare nod. Porturile erau setate iface ... inet manual fără auto, deci niciodată ridicate la boot — de-aia nu arătau link la prima verificare. Ridicate manual (ip link set <if> up), linkul a apărut după ~5-10s de negociere:

Nod	Interfață	Chipset	Viteză max NIC	Link negociat	MAC
pve1 (10.0.20.200)	eno1	Intel I219-LM	1 Gbps (nu suportă 2.5G)	1000 Mbps Full Duplex	fc:3f:db:0a:0d:d8
pvemini (10.0.20.201)	enp90s0	Intel I226-V	2.5 Gbps	2500 Mbps Full Duplex	58:47:ca:7d:51:3c
pveelite (10.0.20.202)	eno1	Intel I219-LM	1 Gbps (nu suportă 2.5G)	1000 Mbps Full Duplex	84:69:93:57:b2:ea

Nicio interfață nu are IP. Sunt doar manual, ridicate acum administrativ pentru test — nepersistat în /etc/network/interfaces (revine la DOWN la următorul reboot dacă nu se adaugă auto + configurare).

Constatare importantă, neaflată până acum

Doar pvemini poate profita cu adevărat de 2.5G pe rețeaua nouă — placa lui de rezervă (I226-V) suportă viteza integral. pve1 și pveelite au NIC-uri de rezervă vechi (I219-LM), limitate la 1 Gbps, indiferent de switch. Rețeaua dedicată va fi deci mixtă: 2.5G doar pe segmentul pvemini, 1G pe segmentele pve1/pveelite — tot un upgrade real față de starea actuală (vezi mai jos), dar nu 2.5G capăt la capăt.

Constatare colaterală: pve1 rulează rețeaua principală tot pe adaptor USB

Investigând porturile de rezervă, a ieșit la iveală ceva nedocumentat: nu doar pveelite rulează vmbr0 (IP-ul principal de cluster) pe un dongle USB Realtek — și pve1:

Nod	Interfața din vmbr0 (producție)	Tip
pve1	enx6c1ff759e2cb	USB 2.5G (Realtek r8152)
pveelite	enx6c1ff71abe67	USB 2.5G (Realtek r8152)
pvemini	enp87s0	Onboard (Intel I226, integrat pe placă)

Incidentul 2026-08-27 a documentat defectul strict pentru pveelite (reset spontan al adaptorului USB → interfața nu se readaugă în punte → nod invizibil 16 ore). Același risc structural există și pe pve1 — chipset identic (r8152), aceeași lipsă de regulă hotplug în /etc/network/interfaces. Nu s-a manifestat încă pe pve1, dar asta nu înseamnă că nu poate.

---

Măsurători și corecții — a doua verificare, 2026-08-29

Prima verificare a lăsat deschisă ipoteza că se poate câștiga viteză prin 10G pe pvemini. Măsurătorile au infirmat-o. Datele de mai jos sunt scumpe de re-obținut; nu le redescoperi.

Replicarea rulează deja la viteza firului

Test pe exact calea folosită de pvesr (flux SSH criptat, dd 3 GB prin ssh ... cat >/dev/null):

Traseu	Debit măsurat
pvemini → pve1	272 MB/s (2.18 Gbps)
pvemini → pveelite	274 MB/s (2.19 Gbps)

Maximul teoretic pe 2.5GbE după overhead TCP e ~285 MB/s. Suntem la ~95% din fir. Criptarea SSH nu e limita (i9-12900H cu AES-NI) — firul e. Durata replicării incrementale în pve-replication-state.json: 3–8 secunde.

Corolar: migration: type=insecure aduce sub 5%. Se ia pentru că e gratis pe o rețea izolată, nu pentru viteză.

Replicarea e strict secvențială — agregarea de linkuri nu ajută

/usr/share/perl5/PVE/API2/Replication.pm:138 (run_jobs) iterează joburile într-un while sub un singur PVE::Tools::lock_file($pvesr_lock_path), fără fork. Nu există joburi paralele pe un nod, oricât de multe ar cădea în aceeași fereastră */15.

Consecință: un singur flux TCP la un moment dat. LACP hashuiește un flux pe un singur link (câștig zero), iar balance-rr produce reordonare de pachete și de obicei scade debitul. Niciun bond, niciun dongle suplimentar nu aduce nimic.

Placa X710 de 10G e o fundătură

i40e 0000:02:00.0 enp2s0f0np0: Cannot read module EEPROM memory. No module connected.
i40e 0000:02:00.1 enp2s0f1np1: Cannot read module EEPROM memory. No module connected.

Ambele cage-uri SFP+ sunt goale. Porturile de 10G ale switch-ului principal sunt RJ45, deci X710-ul (SFP+) ar cere transceiver SFP+ → 10GBase-T: ~2.5W consum într-un cage care livrează mult mai puțin, plus whitelist de module pe controlerele Intel. Combinație cunoscută ca nefuncțională, 250–450 lei ca să afli asta.

Și chiar dacă ar merge, n-ar folosi la nimic: pve1 și pveelite sunt plafonate hardware la 2.5G (dongle USB Realtek; onboard-urile I219 fac 1G) și n-au slot PCIe liber. Receptorul oprește transferul, indiferent ce are emițătorul.

pvemini nu are porturi RJ45 de 10G

enp87s0 / enp90s0:  Supported link modes: ... 2500baseT/Full    (driver igc = Intel I226)

Nu apare 5000baseT sau 10000baseT. Portul din switch poate fi 10GBase-T — NIC-ul negociază 2.5G și acolo se oprește. Singurul hardware de 10G din pvemini rămâne X710-ul, nefolosibil.

Concluzie

Nu mai există viteză de câștigat pe replicare/migrare cu hardware-ul actual. Ce se poate câștiga e fiabilitate (scoaterea IP-ului de cluster de pe dongle-ul USB) și izolare (traficul de replicare/backup separat de producție).

---

De ce insula e pe switch 1 și nu pe switch 2

Prima variantă a planului punea insula de cluster pe switch 2 (cel de 8 porturi). Constrângerea care a răsturnat-o: stația de administrare și access point-ul sunt pe switch 2, deci switch 2 nu poate fi izolat — s-ar tăia internetul la amândouă. Rezultă că insula trebuie să fie switch 1, iar producția pe switch 2.

Consecință fericită: fiecare nod avea deja câte un cablu în fiecare switch, deci nu s-a mutat niciun cablu de nod — s-a schimbat doar ce rol are fiecare interfață. Pe pvemini nici măcar nu s-au inversat cabluri: vmbr0 a trecut de pe enp87s0 pe enp90s0, iar enp87s0 (deja în switch 1) a primit IP-ul de pe insulă.

Ce s-a câștigat:

• management + corosync ring0 trec de pe dongle-ul USB Realtek pe Intel-ul onboard — exact componenta care a lăsat pveelite mort 16 ore pe 27 august nu mai ține IP-ul de cluster;
• replicarea rămâne la aceiași 2.5G, dar izolată de traficul de producție;
• eno1 ajunge în LAN-ul de producție, pe același segment cu stația de admin — WoL merge direct (dongle-urile USB nu suportă WoL, pierd alimentarea la oprire);
• cale out-of-band nouă: pvemini ajunge la pve1/pveelite pe 10.10.10.0/24 fără gateway. Dacă eno1 sau portul din switch cedează la un nod, ai SSH la el din pvemini.

Ce plătești: producția scade la 1G pe pve1/pveelite. Acolo rulează 101 minecraft, 110 moltbot, 109 Windows DR — niciunul nu cere mai mult, iar internetul e oricum 500 Mbps.

Bonus: porturile de 10G RJ45 (5 și 6) ajung pe insula de cluster. Mutând dongle-ul lui pve1 de pe portul 6 pe portul 2 (2.5G, liber) se eliberează ambele porturi de 10G pe rețeaua de replicare — singurul loc din infrastructură unde 10G ar aduce ceva real: un viitor PBS/NAS cu 10GBase-T ar putea primi backup de la toate 3 nodurile simultan, la 2.5G fiecare.

---

Ce s-a aplicat efectiv, 2026-08-29

Cheia execuției fără deplasare la consolă: cât timp uplink-ul din p1 există, cele două switch-uri sunt un singur domeniu L2, deci mutarea lui vmbr0 de pe o interfață pe alta a nodului rămâne accesibilă prin uplink. Fiecare nod a fost modificat cu o plasă de siguranță: un timer systemd-run --on-active=180 care readucea configurația veche dacă nodul devenea inaccesibil, dezarmat manual după verificare.

1. sysctl ARP — toate 3 nodurile

/etc/sysctl.d/99-cluster-arp.conf:

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

Erau 0/0. Obligatoriu cât timp cele două subrețele împart un domeniu L2, altfel replicarea poate lua tăcut calea lentă. După scoaterea uplink-ului devin inutile, dar rămân puse.

2. /etc/network/interfaces — toate 3 nodurile

Backup pe fiecare nod: /etc/network/interfaces.bak-2026-08-29 și /root/interfaces.rollback.

Nod	vmbr0 (producție)	interfața de insulă
pvemini	bridge-ports enp90s0	auto enp87s0 → 10.10.10.201/24
pve1	bridge-ports eno1	auto enx6c1ff759e2cb → 10.10.10.200/24
pveelite	bridge-ports eno1	auto enx6c1ff71abe67 → 10.10.10.202/24

Interfețele de insulă sunt fără punte și fără gateway.

WoL persistent: post-up /sbin/ethtool -s <if> wol g || true pe vmbr0 la fiecare nod (și pe enp87s0 la pvemini). || true e intenționat — un ethtool eșuat nu trebuie să blocheze ridicarea interfeței. Nu s-a pus pe dongle-urile USB: nu păstrează alimentarea la oprire, deci WoL pe ele n-ar face nimic. Bitul din BIOS cere în continuare acces fizic.

3. NFS — /etc/exports pe pvemini

Backup: /etc/exports.bak-2026-08-29. Subrețeaua insulei a fost adăugată înainte de repointare, altfel montarea ar fi fost refuzată:

/mnt/backup 10.0.20.0/24(rw,sync,no_subtree_check,no_root_squash) 10.10.10.0/24(rw,sync,no_subtree_check,no_root_squash)

4. /etc/pve/storage.cfg

Backup: /root/storage.cfg.bak-2026-08-29 pe pvemini. backup-pvemini-nfs → server 10.10.10.201. Storage-ul backup-nfs (dezactivat) a rămas intenționat pe 10.0.20.201. Montările vechi au fost demontate și refăcute — verificat clientaddr=10.10.10.200/202.

5. /etc/pve/datacenter.cfg

Backup: /root/datacenter.cfg.bak-2026-08-29 pe pvemini.

ha: shutdown_policy=freeze
migration: network=10.10.10.0/24,type=insecure

Verificări după aplicare

• pvecm status — cvorat, 3 voturi, pe tot parcursul;
• guest-urile au rămas în punte (Oracle LXC 108 răspunde la ping);
• ping reciproc pe 10.10.10.x între toate 3 nodurile — OK;
• debit pe insulă: pvemini → pve1 267 MB/s, pvemini → pveelite 273 MB/s — identic cu cel de pe producție înainte de mutare, deci nu s-a pierdut nimic;
• NFS activ și scriibil de pe ambele noduri prin insulă;
• pvesr run --id 108-0 cu numărare de octeți pe interfețe: 4959 KB pe insulă (enp87s0) vs 1553 KB pe producție (enp90s0) — fluxul de date merge pe rețeaua dedicată, pe producție rămâne doar canalul de control.

Capcană evitată: cheile SSH pentru IP-urile noi

Un ssh 10.10.10.200 manual eșuează cu Host key verification failed — cheile nu sunt cunoscute pentru IP-urile de pe insulă. Replicarea nu e afectată: PVE/SSHInfo.pm:70 construiește comanda cu -o HostKeyAlias=<nume_nod>, deci cheia e căutată după numele nodului, nu după IP. Nu trebuie adăugat nimic în known_hosts.

---

Ce a rămas de făcut

Nimic obligatoriu. Uplink-ul a fost scos și enp87s0 mutat de pe p5 pe p2 — verificat după fiecare pas: link 2500 Mbps, ping pe toată insula, 262 / 272 MB/s, job real de replicare (171-0) încheiat cu succes, NFS active pe ambele noduri, cvorum pe 3.

Opționale, în ordinea valorii:

1. corosync ring1 pe 10.10.10.0/24 — APLICAT pe 2026-08-29 seara, vezi mai jos.
2. MTU 9000 pe segmentul dedicat — de testat, nu se știe dacă switch-ul suportă.
3. Test la reboot. — FĂCUT pe 2026-08-29 seara, vezi mai jos.

Test la repornire — făcut pe 2026-08-29, ipoteza infirmată

Clusterul a fost oprit complet (toate 3 nodurile) și pornit înapoi. Insula a urcat singură pe toate trei nodurile, fără intervenție: enumerarea târzie a USB-ului nu s-a produs. Pe pve1 s-a declanșat în plus și regula udev usb-lan-hotplug@ la boot (20:27:33, terminată cu succes), care oricum ar fi reparat situația; pe pveelite a fost suficientă strofa auto.

Wake-on-LAN merge pe toate trei nodurile — nodurile oprite au fost trezite cu magic packet de pe stația de admin, timp de răspuns ~15 secunde. E câștigul mutării lui vmbr0 pe interfețele onboard: dongle-urile USB nu suportă WoL. Unealta: ../scripts/wake-cluster.ps1 (MAC-urile de producție sunt în ea). Wake-on: g era deja armat pe toate trei, iar BIOS-urile nu taie alimentarea plăcii în S5.

Ce a găsit testul: o linie rămasă în /etc/fstab

Repornirea a scos la iveală o deriva tăcută pe pve1 și pveelite:

10.0.20.201:/mnt/backup /mnt/pve/backup-pvemini nfs4 defaults,_netdev 0 0

Montarea NFS a storage-ului PVE e treaba lui pvestatd, din /etc/pve/storage.cfg (unde serverul e corect, 10.10.10.201). Linia din fstab o lua însă înainte la boot, ocupa punctul de montare, iar PVE o lăsa așa. Rezultatul: tot traficul de backup trecea pe rețeaua de producție, cu storage.cfg arătând perfect corect.

Remontarea manuală făcută pe 29 august a corectat simptomul, dar nu și cauza — starea bună a supraviețuit exact până la prima repornire. Liniile au fost comentate pe ambele noduri (backup: /root/fstab.bak-2026-08-29), montările refăcute și verificate: clientaddr=10.10.10.200 / 10.10.10.202, scriibile.

cluster-startup verifică acum asta automat la fiecare pornire.

De reținut: vmbr0 și-a schimbat MAC-ul pe toate 3 nodurile (a preluat MAC-ul noii interfețe). Dacă apar reguli pe router legate de MAC, acolo e cauza.

---

Îmbunătățiri posibile, în ordinea impactului

1. Al doilea inel corosync (link1) pe switch-ul nou — APLICAT pe 2026-08-29

Cluster-ul are azi un singur inel corosync (linknumber: 0, peste vmbr0/IP-ul principal — vezi /etc/pve/corosync.conf). Când adaptorul USB al lui pveelite s-a resetat (aprilie și august), corosync a pierdut nodul respectiv fiindcă nu exista rută alternativă. Adăugarea switch-ului nou ca link1 dedicat corosync ar fi ținut clusterul stabil în ambele incidente, inclusiv pe pve1 dacă i s-ar întâmpla la fel.

Precondiția e îndeplinită din 2026-08-29: IP-urile 10.10.10.200/201/202 există și sunt verificate. Ring0 stă acum pe interfețele onboard (mai robuste), iar ring1 pe insulă ar acoperi și cazul în care dongle-ul USB sau portul din switch cedează.

Cum s-a aplicat

Fereastra: guest-urile oprite cu cluster-shutdown.ps1 -NoNodes, care lasă exact starea necesară — toate resursele HA în stopped, watchdog-ul dezarmat, dar clusterul pornit și cvorat, fiindcă corosync.conf stă pe pmxcfs și fără cvorum devine read-only.

# backup pe FIECARE nod, si copia din /etc/pve, si cea locala pe care o citeste corosync
cp /etc/pve/corosync.conf   /root/corosync.conf.bak-2026-08-29
cp /etc/corosync/corosync.conf /root/corosync.local.bak-2026-08-29

# validare INAINTE de instalare - corosync stie sa-si testeze propriul fisier
COROSYNC_MAIN_CONFIG_FILE=/root/corosync.new.conf corosync -t   # exit 0 = sintaxa buna

cp /root/corosync.new.conf /etc/pve/corosync.conf.new
mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf            # pmxcfs propaga singur

Modificările: ring1_addr: 10.10.10.20x la fiecare nod, un al doilea bloc interface { linknumber: 1 } în totem, config_version 16 → 17. link_mode era deja passive, potrivit pentru două linkuri. Propagarea pe toate 3 nodurile a durat sub 12 secunde.

Verificat prin oprirea reală a lui ring0

Nu doar configurat — testat. Cu eno1 scos administrativ pe pveelite (plasă de siguranță: ifreload -a programat la 120s), corosync a arătat de pe pvemini:

LINK ID 0  nodeid 3: disconnected
LINK ID 1  nodeid 3: connected
Quorate: Yes, Total votes: 3

Exact situația din 27 august, când pveelite a fost declarat mort 16 ore. Acum clusterul nici nu clipește. Restaurarea s-a făcut prin calea out-of-band de pe insulă (ssh de pe pvemini către 10.10.10.202), care a funcționat cu nodul invizibil pe producție.

Ce NU rezolvă ring1 — de reținut

În timpul testului, pveelite a apărut gri/indisponibil în GUI-ul Proxmox, deși cvorumul era intact. E corect: GUI-ul nu se uită la corosync, ci vorbește prin API pe 8006, peste IP-ul de management din 10.0.20.x. Ring1 protejează cvorumul, pmxcfs și HA — nu accesul de management. Pentru management out-of-band există SSH pe insulă, de pe un nod pe altul.

2, 3 și 4 — aplicate pe 2026-08-29

Rețeaua dedicată, IP-urile fixe și mutarea IP-ului principal de pe dongle-ul USB pe onboard sunt făcute — vezi „Ce s-a aplicat efectiv". Decizia de arhitectură dintre variantele A („IP-ul principal rămâne pe USB, eno1 preia replicarea") și B („IP-ul principal se mută pe eno1") a fost tranșată de măsurători în favoarea lui B: dongle-ul rămâne 2.5G indiferent pe ce switch stă, deci mutându-l pe rețeaua dedicată nu se pierde nimic la replicare, iar producția pe 1G nu costă nimic pe pve1/pveelite.

---

Ce NU s-a schimbat

• /etc/pve/corosync.conf — neatins la mutarea rețelei; modificat seara aceleiași zile, pentru ring1 (config_version: 17) — vezi mai sus. Ring0 folosește în continuare IP-urile 10.0.20.20x, care acum stau pe interfețele onboard.
• Cablurile nodurilor — niciunul mutat de scripturi. Toate mutările fizice au fost făcute manual de utilizator (routerul pe switch 2, dongle-ul lui pveelite pe p4, al lui pve1 pe p3).
• Cage-urile SFP+ ale plăcii X710 de pe pvemini — rămân goale, placa nefolosită. La verificări, cele două interfețe au fost ridicate și coborâte la loc, doar ca să se citească EEPROM-ul.

Referințe

• Incident 2026-08-27 — pveelite fără rețea 16h (USB LAN reset)
• Corosync Tuning — tokenul de 10s, motivat de fragilitatea USB
• cluster/README.md — Rețea