Este fezabil să aveți dosarul de acasă găzduit cu NFS? (Administrarea sistemului, Unix, Nfs, Gestionarea Utilizatorilor, Director Acasă)

voyager a intrebat.
a intrebat.

Am de gând să implementez câteva calculatoare de chioșc și aș dori să le las cu un mic pendrive ca disc de boot, păstrând restul la un server ușor de salvat, ala LTSP.

În acest moment mă gândesc la două opțiuni. Un /home/ prin NFS sau o copie locală a lui ~/ copiată la conectare, rsynced la deconectare.

Temerile mele sunt că lucrul cu fișierele ar putea deveni prea lent, sau că rețeaua mea ar putea deveni înfundată.

Comentarii

10 răspunsuri
Aaron Brown

Folosesc NFS pentru directoarele mele de acasă în mediul nostru de producție. Există câteva trucuri.

  1. Nu montați NFS pe /home – în acest fel, puteți avea un utilizator local care să vă permită accesul în cazul în care serverul NFS nu funcționează. Noi montăm la /mnt/nfs/home

  2. Folosiți soft mounts și un timeout foarte scurt – acest lucru va împiedica procesele să se blocheze la nesfârșit.

  3. Utilizați automounter. Acest lucru va menține utilizarea resurselor la un nivel scăzut și, de asemenea, înseamnă că nu trebuie să vă faceți griji cu privire la repornirea serviciilor atunci când serverul NFS revine, în cazul în care acesta cade din anumite motive.

    auto.master:
      +auto.master
      /mnt/nfs /etc/auto.home --timeout=300
    
    auto.home
       home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
    
  4. Utilizați un sistem de autentificare unică pentru a nu întâmpina probleme legate de permisiuni. Eu am un server OpenLDAP.

Comentarii

  • Întotdeauna am considerat că automonitorizarea este extrem de nesigură și predispusă să se blocheze, în special dacă serverul NFS se oprește. Dacă montați pe /mnt/nfs/home, acolo ați setat casa utilizatorului în /etc/passwd? –  > Por pjc50.
  • Ei bine, utilizarea /etc/passwd și montarea NFS a directoarelor de domiciliu este o idee proastă, deoarece trebuie să păstrați UID și GID sincronizate – utilizați ceva de genul OpenLDAP, dar da, directorul de domiciliu al utilizatorului este setat la /mnt/nfs/home/username. –  > Por Aaron Brown.
  • @AaronBrown Sunt de acord că, dacă aveți de gând să puneți $HOME în rețea, ar trebui să puneți, de asemenea, identitatea și autentificarea utilizatorului în rețea. Indiferent de modul în care faceți asta, $HOME trebuie să fie definit undeva și ați indicat că preferați să îl definiți la /mnt/nfs/home dar cum puteți utiliza atunci serverul local /home în timpul unei întreruperi? Mai exact, vă rugăm să consultați unix.stackexchange.com/questions/189404/… –  > Por JFlo.
  • Pe sistemele Ubuntu, instalați programul autofs pentru a activa caracteristicile automounter: apt-get install autofs. –  > Por Johnny Utahh.
wzzrd

Aveți grijă cu monturile moi! Montarea soft a unui sistem de fișiere NFS înseamnă că IO va eșua după ce apare un timeout. Fiți foarte sigur că asta este ceea ce doriți pe directoarele personale ale utilizatorilor! Bănuiesc că nu. Folosirea unei montări hard pe directoarele personale în combinație cu opțiunea intr este mult mai sigură în acest caz.

Hard nu va expira: Operațiunile IO vor fi reluate la nesfârșit. Opțiunea intr face posibilă întreruperea procesului de montare. Astfel, dacă montați exportul și întâmpinați o defecțiune, hard-mount vă va bloca sesiunea. Opțiunea intr va face posibilă întreruperea procesului de montare, astfel încât combinația este destul de sigură și vă asigură că nu veți pierde cu ușurință datele unui utilizator.

Oricum, autofs face ca totul să fie și mai ușor.

Comentarii

  • Rețineți că opțiunea intr mount a fost eliminată din Linux după kernelul 2.6.2, a se vedea, de exemplu, opțiunea mount. access.redhat.com/solutions/157873 –  > Por myrdd.
faultyserver

HowtoForge a postat un articol intitulat Crearea unui server de stocare autonom de tip NFS cu GlusterFS pe Debian Lenny, este posibil să doriți să-l verificați.

Iată o scurtă descriere a motivelor pentru care este o bună alternativă „fezabilă” la NFS, de pe GlusterFS de pe pagina de proiect:

GlusterFS se autoregenerează din mers. Nu există fsck. Backend-ul de stocare este accesibil direct ca fișiere și foldere obișnuite (în stil NFS). Cu replicarea activată, GlusterFS poate rezista la defecțiuni hardware.

Mai multe informații pot fi găsite în documentația proiectului.

De asemenea, un alt lucru bun în legătură cu utilizarea GlusterFS este că, dacă aveți nevoie de mai mult spațiu pe SAN, trebuie doar să adăugați o altă cărămidă de stocare (nod de server) și puteți să vă extindeți/creșteți spațiul de stocare în paralel atunci când este nevoie.

Xerxes

Singurul lucru de reținut este că, atunci când serverul NFS nu funcționează, montările dvs. vor îngheța – efectuarea unei montări soft nu va bloca, astfel încât „înghețarea” în sine poate fi evitată, însă acest lucru nu va rezolva problema directoarelor personale, deoarece, fără un director personal, utilizatorul este oricum terminat.

Chiar și atunci când serverul NFS își revine, dacă nu faceți ceva în acest sens, problema de înghețare va rămâne – va trebui să opriți procesul de pe calculatorul care face montajul și să remontați. Motivul este că atunci când serverul NFS revine, acesta a atribuit un alt fsid – așa că puteți cel puțin să rezolvați această problemă codificând hard-coding-ul fsids pe serverul NFS, de exemplu…

#. Home Directories
/usr/users 
  192.168.16.0/22(rw,sync,no_root_squash,fsid=1) 
  192.168.80.0/22(rw,sync,no_root_squash,fsid=1)

#. Scratch Space
/var/ftp/scratch 
  192.168.16.0/22(rw,async,no_root_squash,fsid=3) 
  192.168.80.0/22(rw,async,no_root_squash,fsid=3) 
  172.28.24.151(rw,async,root_squash,fsid=3)

Adresa exports(5) pagina de manual afirmă…

fsid=num
          This option forces the filesystem identification portion of the file handle
          and  file attributes used on the wire to be num instead of a number derived
          from the major and minor number of the block device on which the filesystem
          is  mounted.   Any 32 bit number can be used, but it must be unique amongst
          all the exported filesystems.

          This can be useful for NFS failover, to ensure that  both  servers  of  the
          failover  pair use the same NFS file handles for the shared filesystem thus
          avoiding stale file handles after failover.

…În timp ce acest lucru indică faptul că, atâta timp cât numerele major/minor nu se schimbă (ceea ce de obicei nu se întâmplă, cu excepția cazului în care exportați volume SAN/multipath, unde acestea se pot schimba), am constatat că am eliminat complet problema – adică, dacă serverul NFS se întoarce – conexiunea a fost restabilită rapid – tot nu știu de ce acest lucru a făcut diferența pentru dispozitive cum ar fi /dev/sdaX de exemplu.

Ar trebui să subliniez acum că argumentul meu este în mare parte anecdotic – nu are sens de fapt de ce a rezolvat problema, dar „pare” că a rezolvat-o – cumva – probabil că sunt și alte variabile în joc aici pe care nu le-am descoperit încă. =)

Comentarii

  • Sunteți sigur de acest fsid „aleatoriu” folosit de server? –  > Por Cristian Ciupitu.
  • Bună Cristian – am încercat să explic mai sus – dar nu pot explica pe deplin comportamentul față de descrierea din pagina de manual a flag-ului. Ai încercat și ai văzut altceva? –  > Por Xerxes.
Sam Morris

Câteva sfaturi generale care se vor aplica indiferent de sistemul de fișiere de rețea pe care îl adoptați: multe programe stochează datele în memoria cache din directorul de domiciliu al utilizatorului, ceea ce de obicei face mai mult rău decât bine atunci când directorul de domiciliu este accesat prin rețea.

În zilele noastre, puteți spune multor programe să își stocheze memoria cache în altă parte (de exemplu, pe un disc local) prin setarea parametrului XDG_CACHE_HOME variabila de mediu într-un script de conectare. Cu toate acestea, o mulțime de programe (de exemplu, Firefox) necesită încă o configurare manuală, așa că va trebui probabil să depuneți o muncă suplimentară pentru a le identifica și configura într-un mod uniform pentru toți utilizatorii dumneavoastră.

Comentarii

  • +1 Am avut probleme de performanță cu Google Chrome și cu NFS home dirs. am rezolvat-o mutând directoarele de lucru ale Chrome înapoi pe sistemul local, apoi plasând un symlink de la NFS home dir (unde Chrome se așteaptă să găsească dirsurile), înapoi la directorul local. Este posibil să existe o modalitate mai bună de a face ceea ce am făcut eu, dar pentru mine a rezolvat problema. –  > Por Bryan.
  • Bryan (9 martie) a lăsat un răspuns parțial bun, totuși, vreau să dezvolt această problemă. Vă rog să o faceți… Vă mulțumesc… Cum ați mutat directoarele de lucru pe mașina locală și ați plasat symlinks. –  > Por Jason.
  • De asemenea, verificați și XDG_RUNTIME_DIR descrisă pentru locația bazei de date Dconf la: developer.gnome.org/dconf/unstable/dconf-overview.html –  > Por JKnight.
kbyrd

Multe dintre locurile în care am lucrat folosesc directoare de domiciliu montate pe NFS. De obicei, nu există o diferență uriașă în ceea ce privește performanța (iar utilizatorii de chioșcuri sunt, probabil, un pic mai puțin pretențioși decât dezvoltatorii care știu cum să facă rost de tipul lor IT local). O problemă pe care am văzut-o este ceea ce se întâmplă atunci când sunt conectat la un desktop Gnome și serverul NFS dispare din orice motiv. Lucrurile devin cu adevărat insensibile.

cd1

Eu folosesc un NFSed acasă și funcționează bine. dar trebuie să vă asigurați că rețeaua este suficient de rapidă și că nu va fi niciodată indisponibilă.

Alexandre Carmel-Veilleux

În practică, NFS funcționează bine pentru home directory dacă există o rețea comutată de 100mbit sau mai bună. Pentru mai mult de 10-20 de chioșcuri, serverul ar trebui să aibă conectivitate gigabit. Nu veți câștiga concursuri de performanță, dar lucruri precum Firefox și Open Office vor funcționa bine.

Copierea în directorul de acasă va fi o mare pacoste în ceea ce privește întârzierile la conectare (pe o rețea de 100mbit, aceasta este de maxim 12MB/s. Un home directory de 100MB este aproape de 10 secunde). Rsync vă va bate la cap sincronizarea cache-ului browserului web… 10 minute și 500 de fișiere fac rău.

Cristian Ciupitu

Aruncați o privire la cachefilesd. Nu l-am folosit personal, dar pare promițător.

Daemonul cachefilesd gestionează fișierele de cache și directorul care sunt care sunt folosite de sistemele de fișiere de rețea, cum ar fi AFS și NFS, pentru a face caching persistent pe discul local.

De asemenea, nu uitați să reglați parametrii rsize și wsize și să folosiți cadre Jumbo dacă este posibil.

Comentarii

  • Am încercat cachefilesd timp de mai mulți ani, dar am renunțat din cauza instabilității pe care o aducea. YMMV –  > Por JFlo.
matt

Rețineți că, în unele cazuri (de exemplu, utilizarea privată la domiciliu sau configurarea unui chioșc), cel mai simplu lucru de făcut ar putea fi să folosiți legături simbolice pentru directoarele importante de nivel superior din interiorul directorului de domiciliu. Face mult mai ușor să nuke home „satelit” dacă setările de acolo se încurcă, trebuie păstrate local, etc.