Proxmox VE 6->7 frissítés, alkalmi munka

Virtualizáció

Sziasztok!

Kicsit (eléggé) lemaradva szeretnénk frissíteni 5 node-ból álló hiperkonvergens (Ceph) Proxmox clusterünket 6.4-15 verzióról egészen 8-ra.

Különálló szerveren nem okozott problémát a dolog, mivel azon nem is használunk Ceph-t, viszont ebben az 5 node-os clusterben van 1 SSD-s pool és egy 1 HDD-s pool is. PVE 7-re történő frissítés után a jelenlegi 15.2.x Octopus-t 16.x Pacific-re kell frissíteni és ez a része a dolognak, amit nem szívesen csinálnék. 7-ben a 15.x 2022Q2-ig volt támogatva a Proxmox wiki szerint, 16-ra pedig nem tudom előre frissíteni.
Opció lenne áthúzni a ceph tartalmát NFS-re, de az ilyen jellegű tárolónk iszonyú lassú ehhez, ezt csak legleglegvégső esetben lépném meg.

Ezek lényegében egyforma (RAM méret nem) Dell R630 szerverek, konzol van.

Aki tapasztalt ebben és meg tudná oldani nekünk ezt a problémát, kérem, hogy jelentkezzen nálam. Nem ingyen várjuk a megoldást. :D

( _ventura_ v | 2024. 06. 11., k – 13:18 )

Naprakész backup legyen ...

Fedora 40, Thinkpad x280

( hunti v | 2024. 06. 11., k – 14:50 )

Szerkesztve: 2024. 06. 11., k – 14:51

Gond nélkül több lépésben meg lehet csinálni a frissítést, úgy ahogy proxmox wiki-n le van írva. Emlékeim szerint először mindig ceph-et kell frissíteni a leírás alapján (Prerequisite rész), utána dist upgrade, de ahogy írtam, pontosan leírják mit hogyan kell csinálni. Attól még hogy nem supported, a pve csomag tárolókon elérhetőek adott mayor verziók legutolsó verziójú csomagjai, így lehet frissíteni mindent, esetedben 6->7->8, tehát 2 lépésben.

vps4you.hu kupon VPS szolgáltatásra: HUP2023

A prereq. résznél ez van:

Hyper-converged Ceph: upgrade the Ceph Nautilus cluster to Ceph 15.2 Octopus before you start the Proxmox VE upgrade to 7.0.

Ez már teljesült, mert most is 15.2.x van fent. Viszont repo átírásnál nem 7.0-ra fogja frissíteni, hanem 7.4-re (erről nincs infóm, hogy támogatja-e még a 15.2.x verziót, de 2022Q2 már régen volt).
Az after upgrade résznél ez van:

Now you can upgrade the Ceph cluster to the Pacific release, following the article Ceph Octopus to Pacific. Note that while an upgrade is recommended, it's not strictly necessary. Ceph Octopus will be supported until its end-of-life (circa end of 2022/Q2) in Proxmox VE 7.x,

A 7.4 what's new oldalán pedig ez:

Ceph Quincy 17.2.5 and Ceph Pacific 16.2.11

7.2-nél még ez volt:

Ceph Pacific 16.2.7 and continued support for Ceph Octopus 15.2.16 (until mid 2022);

 

Ezért nem tudom, hogyan is kéne ennek nekilátni, mert a wiki-t így lehetetlen követni ha ezeket figyelembe veszem. (vagyis követni lehet, csak meglepetést nem szeretnék ez miatt)

Ha lehetne konkrétan 7.0-ra vagy 7.2-re upgradelni, majd arról 7.4-re, akkor tiszta sor.

Ezeken felesleges aggódni, mindegy hogy melyik minor verzióra frissítesz, 7.0-ra vagy 7.4-re. A leírás akkor készült amikor kijött 7.0, ezért van 7.0 a leírásban, de működik is akkor is ha már kijött 7.1,7.2, stb. Lényeg hogy kövesd a leírást, megfelelő sorrendben csináld meg a ceph és proxmox frissítéseket, a minor verziószámokkal pedig nem kell foglalkozni. Közel 30 gépet frissítettem proxmox 5.x-ről 7.x-re (ceph-el), többé kevésbé gond nélkül. EFI bootra váltásnál egyes gépeknél BIOS-t kellett matatni hogy bootoljon (secure boot off ha jól emlékszem), 

vps4you.hu kupon VPS szolgáltatásra: HUP2023

Magával a proxmox-szal tényleg nem lesz baj de én pl beszoptam a 7.4-es upgrade után az lxc alatt futó dockerrel (tudom, ellenjavallt).
Meg a proxmox-api is más (terraformnak fontos pl).

Szóval azért felhasználás-függő hogy melyik minor upgrade mit okoz.

Gábriel Ákos

( gabrielakos v | 2024. 06. 11., k – 22:13 )

Szerkesztve: 2024. 06. 12., sze – 07:16

8-ast még nem is biztos hogy raknék, van valami probléma a kernel és a ksmd között, a szokásosnál sokkal több ramot tud kérni. Írja is a doksiban.

Gábriel Ákos

Az oké, de már írja a frissített 7.4, hogy a támogatása lejár 2024.07.31-én, ergo aki meg kell tartsa mondjuk az IBSZ miatt a frissességet, annak sok ideje nem maradt várni a megoldásra.

Nekem is van olyan 7.x friss cluster-em, amit kellene 8-ra frissíteni e miatt, és már nem soká tudom eladni, hogy miért nem frissítünk.

Az IBSZ (jó esetben...) nem azt mondja, hogy mindenkor naprakészen frissen kell mindent tartani, hanem azt, hogy éles rendszereket legfeljebb x, teszt/dev/egyéb rendszereket meg legfeljebb x/z/w időközönként kell frissíteni (cizelláltabban esetleg a sérülékenység súlya, illetve kockázatelemzés alapján sűrűbben).
Azaz lehet olyan olvasata is, hogy az utolsó kiadott frissítés/javítócsomag után x (y,z,w) időn belül kell megejteni a verziócserét. Amire egyébként megint csak lehet kockázatelemzés alapján plusz időt nyerni, mondván, hogy a legutolsó ismert és már nem javított hibák, valamint a rendszer tényleges üzemeltetési környezete alapján alacsonyabb a kockázata a további működtetésnek, mint úttörőként éles üzembe állítani az új főverziót.

Ha van tesztrendszered, akkor lehet arra "mutogatni", hogy ott x időpontban lesz meg a verziócsere, és azt követően, ha ott nem jön ki blokkoló probléma, akkor fogtok éles leállást kérve az éles környezetben főverziót váltani. Infrastruktúrában ilyen jellegű váltás késedelmét elég jól lehet indokolni ;)

( gabrielakos v | 2024. 06. 12., sze – 07:18 )

Ceph-ben van bármi extra plugin? Pl. S3? 
Láttam olyan upgrade-t ahol egyszercsak elfelejtettek jönni a S3 notification-ök.

Gábriel Ákos

( ggallo | 2024. 06. 12., sze – 12:16 )

Rám is vár egy pont ilyen folyamat, PVE 6+Ceph 15-ről tovább menni...

Tapasztalatom nincs vele, előtte állok, viszont az eddig általam fellelt leírások, dokumentált frissítések alapján - ahogy hunti írja - Proxmox leírás szerint csinálva működnie kell. A 7.4-en ugyan úgy kell futnia a Ceph 15-nek, mert a 7-es sorozat frissítései során soha nem írtak arról, hogy PVE minor verzió váltás miatt Ceph major verziót kellene váltani.

Ha fent van Ceph 15 mellett a PVE 7.4, akkor mehet a Ceph 16-ra frissítés, és azzal már lehet tovább menni PVE 8-ra. PVE8 és Ceph 16 felállásból meg mehet a Ceph 17-re majd 18-ra váltás, mert ugye a 16 EoL lett márciusban a 17 meg mostanában lesz az.

( ggallo | 2024. 07. 24., sze – 00:19 )

Nekromantaként a jövőben ide találóknak beírom, hogyan alakult eddig a frissítés Proxmox VE 6.4-ről és Ceph 15.2-ről. Merthogy rászántam végre magam.

Az alap felállás 4 node-os rendszer Dell R630-akkal, kiindulásként Proxmox VE 6.4-15 és Ceph 15.2.15 verziókkal. Uptime 765 nap. Előzőleg már megcsináltam a grub->proxmox-boot-tool váltást, mert ez a javasolt, és később kelleni fog ahhoz, hogy legacy boot-ról uefi-re lehessen váltani, ami meg azért kell, hogy a ZFS root pool-t upgrade-elni lehessen (merthogy a grub nem tudja használni az újabb ZFS pool-okat, így Proxmox-ék átálltak systemd-boot-ra ZFS_on_root+uefi esetén).

  • Elsőre a 6.4-et frissítettem az összes node-on a legutolsóra, ami 6.4-18, ezzel jött a Ceph 15.2.17 is.
  • Ceph-nél beállítottam a noout-ot, nehogy az újraindítások során elkezdje a rebalance-ot.
  • Minden node-on a Ceph ajánlás szerint először a MON, majd az MGR, majd az OSD-k és a végén az MDS-ek újraindításával a Ceph friss lett. Minden lépés egyesével (nem párhuzamosan), és megvártam, amíg a Ceph helyreáll és csak a noout miatt reklamál. Fontos, hogy a Ceph a PVE 7-re frissítés előtt a legutolsó 15.2.x-en legyen, mert a PVE 7 mellett is az lesz.
  • Ezután minden egyes node-nál úgy játtam el, hogy
    • Egyszerre csak egy node-on dolgoztam, ez az ajánlas is, meg így logikus
    • Migráltam a VM-eket a másik 3 node-ra elosztva
    • Amikor a node üres lett, akkor reboot a 6.4 utolsó kernelével, tiszta lap a 7-re frissítés előtt
    • Reboot után PVE upgrade 6-ról 7-re a gyári leírás alapján. Ilyenkor a Ceph marad 15.2.17, csak buster helyett bullseye a build alap
    • Amikor a dist-upgrade kész, akkor reboot, és azon a node-on már a PVE 7.4-18 fut 5.15.158 kernellel, Ceph Octopus 15.2.17-tel
    • Ekkor minden addig rajta lévő VM vissza migrálása a többi node-ról, és ha ez kész, jöhet a következő node. Fontos, hogy a régi node-ról újabbra a VM migrálás problémamentes, de visszafelé nincs garancia, hogy működik
  • Amikor minden node kész, és 7.4-en fut, akkor jöhet a Ceph frissítés, mert Proxmox VE 8-ra csak Ceph Quincy 17.2-vel lehet váltani. A Ceph frissítés igazából egyszerű, a gyári leírás szerint csinálva nem mondanám meredeknek, mert minden le van írva, és egyébként is egyszerű, logikus lépések. Nem lehet kettőt lépni, először 15.2 Octopus -> 16.2 Pacific, majd utána 16.2 Pacific -> 17.2 Quincy sorrend kell.
    • Elsőre, a többi lépés előtt minden node-on át kell írni az octopus-t pacific-re (majd a következő körben a pacific-et quincy-re), majd apt update, apt full-upgrade
    • Ezután jöhet a szokásos sorrendben a gyári leírás szerint a MON, MGR, OSD, MDS újraindítás, egyesével, megvárva a rendszer hibamentesre visszaállását.
    • Amikor minden újraindult, akkor mehet a leírás szerint OSD minimum elvárás emelés, majd a noout törlése, és kész
  • A Pacific->Quincy pont ugyan így történik

A PVE 7.4 -> 8.2 frissítést és a Ceph 17.2 Quincy -> 18.2 Reef frissítést 1-2 nap múlva beírom (volt-e ettől eltérő érdekesség vagy szívás), annak most már nem fogok neki (megcsinálni, nem leírni).

Ez a folyamat kb. 10 órát vett igénybe a 4 node-ra. A folyamat során a VM-ek működésében kiesés természetesen nem volt, futott minden zökkenőmentesen.