Kritikus szerver patchelése előtt készítesz-e a gyors visszaállás érdekében snapshot-ot?

Egyéb

Igen. Online állapotban.
31% (75 szavazat)
Igen. Offline állapotban.
15% (37 szavazat)
Nem.
10% (24 szavazat)
Én nem, de a rendszer automatikusan készít.
6% (15 szavazat)
Csinálnék, de nincs rá lehetőségem.
10% (25 szavazat)
Egyéb, leírom.
2% (5 szavazat)
Csak az eredmény érdekel.
26% (63 szavazat)
Összes szavazat: 244

( norbertkiss | 2018. 11. 15., cs – 17:34 )

Sőt, apt-btrfs-snapshotot is használok már mindenhol, így minden változást okozó apt művelet előtt magától készül snapshot.

( asch v | 2018. 11. 15., cs – 17:43 )

Szerencsére nem menedzselek kritikus szervert, de ha menedzselnék, akkor már régen rossz lenne, ha lenne 1db kritikus vas vagy oprendszer.

Ha meg úgyis elbírja a rendszer egy node kiesését, akkor már úgy kell megtervezni, hogy az upgradek miatti kiesést is bírja, oszt lehet nyomni ész nélkül neki :-)

Mondom ezt pálya széléről bekiabálva mert egész másfajta rendszerekkel foglalkozom.

Lehet "SoHo Kritikus"-ra vonatkozott a kérdés. ;)

Itt is van apt-btrfs-snapshot, csak az IBTV rendelkezéseinek értelmében el is kellene titkosítani (kár, hogy a "mibülről" még mindig nem rendelkezik, mint ahogy arról se, hogyha lerohad melyik "IT papersec guy" tenné működőképessé pillanatok alatt, ha maga alá tenne (már ha egyáltalán lenne btrfs-nél encryption) :D).

( andrej_ v | 2018. 11. 15., cs – 18:02 )

Azt azért tegyük hozzá, hogy az "online állapot" vagy "offline állapot" önmagában nem pontos. A lényeg, hogy lehetőség szerinti legkonzisztensebb mentésre érdemes törekedni.

(Több megoldás ad legalább fs szinten vagy jobb esetben magasabb szinten is konzisztens mentést VM-ről vagy az OS-en belülről.)

( hobord | 2018. 11. 15., cs – 20:16 )

Kritikus rendszernél nem patchelek.
Rebuild and redeploy a clasterbe...

Egyrészt könnyebb belátni, hogy pont az került oda, amit gondoltál, hogy oda fog, mert nincs egy bazi nagy bizonytalansági tényező a kiindulási állapotban. Értem én, hogy pl az ansiblesek megmagyarázzák, hogy ez deklaratív, mert az van odaírva, hogy 'state: present', de ettől még mögé lesz dugva a logika, hogy nézzük meg, hogy fent van-e. ( Hasonlóan attól még, hogy ifet átnevezték whenre, attól az még if marad :) ) Ha újraépíted, akkor a kiinduló állapot, és ezért a folyamat általában egyszerűbb.

Másrészt meg nulláról telepítőt úgyis kell csinálni, általában sokkal olcsóbb (munkaórában) ha nem kell minden update előtt új automatát írni, és azt tesztelni.

Természetesen ez nem jelenti azt, hogy ez mindenhol jó, vagy mindenhol jobb, mint a hagyományosabb (régebbi, fasz se tudja minek nevezzem) metodikák, vagy hogy azokkal ne lehetne, vagy hogy ne lennének néha hátrányai, de határozott előnyei is vannak
.

Kevesebb a frissítésből adódó bizonytalanság, egyszerűbb tud lenni a váltás, szolgáltatáskiesés minimalizálható vagy nullára csökkenthető, stb.. Nyilván pontos előnyök/hátrányok konkrét scenariótól függnek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Vamp | 2018. 11. 15., cs – 22:58 )

Alap a snapshot frissites elott, de nem csak ekkor, minden nagyobb modositas elott is. Altalaban Online allapotban nyomjuk, addig az adott szolgaltatast futtato vas (VM) "maintenance" modba kapcsol, hogy ne keletkezzen uj adat felhasznaloi reszrol. Ha minden ok, akkor megy minden tovabb, ha gebasz van, akkor online snapshot vissza es szinten megy minden tovabb.

( uid_228 | 2018. 11. 15., cs – 23:41 )

A "rendszer automatikusan készít" nem fedi teljesen a valóságot: Solarison a patchelés már rögtön egy új boot environmentbe telepít mindent, ami aktiválható a karbantartási ablakban.

--
ldm start-reconf primary

Van ennek valami értelme, hogy a patchelést is ne pont a karbantartási ablakban csináld meg?

Arra gondolok csak, hogy ha teszem azt, megcsinálod pénteken a patchelést. Megcsinálja az új BE-t, beadm activate, etwas.
Majd hétfőn újraindítod.
Akkor a kettő közt eltelt egy hétvége, és a /var/adm nagy valószínűséggel ugyanaz az fs, mint amin a rendszered többi része van, akkor a kettő közti logokat egy másik BE-ből kell minden egyes alkalommal előbányászni (vagy központi logszerverről), ha netán közben történt volna.

Persze lehet, hogy ez a stratégia tud jól működni.

Tud jól működni? Gondoltatok minden ilyen lehetőségre? Van rá valami best practice gyűjteményetek, mert avval párban lenne értelme a dolognak.

Igen, van értelme, nem kell kapkodni. Meg amikor előkészíted az új BE-t, akkor semmilyen módosítást nem csinál a jelenleg futó éles rendszeren.

A régi BE-ben közben keletkező pl. naplók problémáját jól látod, de vannak logszerverek és azok amúgy is gyűjtenek mindent (műszaki és jogi okokból is kell). Ezért az nem gond, hogy a helyben tárolt logok a régi BE-ben maradnak.

Az előzetes patchelésnek az a nagy előnye, hogy le lehet rövidíteni a karbantartási ablakot. Vannak olyan fontos adatbázisaink, amik ugyan RAC-ok, de ha csak a redundanciájuk csökken, akkor se lesz őszinte a C-level mosolya. Ráadásul Superclusteren, vagy egy kisebb T-series SPARC-on, ha patcheled a firmware-t (amiben a hypervisor is van), akkor kell a Pdomnak, vagy a teljes gépnek egy power cycle. Ez több Ldomot (+zónákat) is érint egyszerre, tehát érdemes az összesen előkészíteni az új BE-t, kiüríteni a clusterszolgáltatásokat ezekről a node-okról és párhuzamosan leállíthatóak mind.

--
ldm start-reconf primary

( Gyuszk v | 2018. 11. 16., p – 15:35 )

Attól függ, de amikor kritikus rendszereket üzemeltettem dockerben, akkor ezt csináltam: online állapotban tolok a disken tárolt adatokról egy rsync-et, majd leállítom és újra rátolom az rsyncet. A második rsync deltája nagyon kicsi lesz, és gyorsan lefut. Mehet fel a patch, majd restart. Igy lesz mentés is, és az offline window is kicsi lesz. Az online állapotban futtatott rsync lementi az adatok 99%át (esetleg inkonzisztensen), amit a második rsync gyorsan megjavit.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

( freeoli v | 2018. 11. 16., p – 16:55 )

Friss backupot indítok ami ha lefutott akkor snapshot, ha vm.

Ha alkalmazás upgrade, nem csak sec fix akkor clone példányon tesztelem az eljárást.

( turul16 v | 2018. 11. 19., h – 12:34 )

Attol fugg mi az elvaras.
Maximialsina kialkaudhato downtime mellet mi a maximalis biztonsag,
es mi az kockazati szint amit elfogadnak.

Altalaban, a maximalis biztonsagot kerik, nem a minimalis downtimeot,
Ugyohogy jobb donwtime mutatot kapnak a kertnel, mikozben
kockazat kozel zero (ha nagy borulas van/lenne meg akkor is megvan a time limit)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.