SPOF mentes nfs

Linux-haladó

Hogyan váltanátok ki egy single point of failure nfs-t?
Olyan megoldás kellene, ami kiesésmentes (*) szolgáltatást tudna nyújtani a klienseknek?
Tehát bármi tervezett karbantartás történik az nfs szolgáltatással, a nagy számú kliens azt nem veszi észre, a file műveletek nem szakadnak meg, a mount-ok nem halnak el.

(*) nyilván a hálózat szakadást nem értem ide, de pl. egy OS patch miatti tervezett reboot-ot igen, DRP tesztet igen, stb.

  • 47077 megtekintés

( Elbandi v | 2014. 05. 19., h – 13:27 )

sub, mert erre kivancsi vok.

mi is kerestunk megoldast, aztan vegulis moosefs lett belole.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

kivancsi vok
A sütőtál, ami túl sokat akart tudni... :)

Hogy ontopic is legyek, ha nem muszáj az NFS, akkor xtreemfs is lehet. Bár emlékeim szerint a teljesítménye nem valami fényes, cserébe eléggé ráfeküdtek a hibatűrésre.
---
Régóta vágyok én, az androidok mezonkincsére már!

Kellene rw.
Meg persze egy csillagromboló, toronyóra aranylánccal, egy lézerkard és egy soha ki nem ürülő söröskorsó is :)

Egyébként az igazi igény az, hogy ne szakadjon meg, ne kerüljön stale állapotba a mount és amikor visszajön a szolgáltatás (ugyanazon v. másik nfs szerveren), akkor tudjon menni tovább, mintha mi se történt volna. Ilyen szempontból igen, talán a ro is jó.

Nekem akár egy köztes réteg is jó lenne, ami a kliensek felé eltakarja az nfs szerver kiesését amíg az vissza nem tér.

A témában guglizgatva ezt találtam: https://www.suse.com/documentation/sle_ha/singlehtml/book_sleha_techgui… és itt van egy mondat arról, miért kell service IP-t használni és ott a mellékmondat arról szól, hogy "otherwise the clients will suffer service interruptions on cluster failover. ". Tehát én ezt most úgy értem, hogy a site-on ismertetett megoldás kiesés mentes nfs szolgáltatást tud biztosítani. Bár az egész nagyban függ az nfs lease time-tól.

Szóval úgy látom, ezt ki kell próbálni.

Nfs-ben nincs kulonosebb hibatures, nem tudsz megadni tobb szervert ami kozott automatan atvalt mar nfs szinten vagy hasonlo.
Legtobb amit tehetsz peldaul az altalad is vazolt lehetoseg, hogy HA megoldassal 2 gep kozott failover nfs szervert csinalsz es minimalizalod a billenes idejet plusz annal nagyobb timeout-ot allitasz be kliensekben (arra az idore mig egyik szerverrol atkerul masikra az nfs szerver service es hozza tartozo ip igy is meg fog akadni es orulhetsz ha csak ennyire...).

( dap | 2014. 05. 19., h – 18:46 )

Nálam van pár aktív-passzív HA cluster NFS-re, régen SAN, ma már DRBD backend-del. Az NFS szerver a megszokott nfs-kernel-server, pacemaker clusterrel.

A trükk annyi, hogy a /var/lib/nfs/ osztott partición kell hogy legyen, illetve az /etc/exports -ban statikusan meg van adva az egyedi fsid minden sorhoz.

Működik, bár az utolsó squeeze-wheezy upgrade-nél stale-be minden kliens a kernelváltás miatt, újra kellett csatolni. Illetve az is probléma, hogy failovernél hideg a cache és a backend nagy IO-t kap amíg fel nem töltődik a page cache, ezt DRBD-vel talán csak a dual primary mód oldaná meg, ami meg más miatt necces.. Mondjuk ha SAN vagy SSD van alatta saját cache-sel, esetleg nincs nagy IO igény, akkor ez nem gond.