# 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 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](../incidents/2026-08-27-pveelite-down.md) 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 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=`, 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. ```bash # 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)](../incidents/2026-08-27-pveelite-down.md) - [Corosync Tuning](../README.md#corosync-tuning) — tokenul de 10s, motivat de fragilitatea USB - [cluster/README.md — Rețea](../README.md#rețea)