Puncte:1

Aveți nevoie de o partajare simplă de fișiere de înaltă disponibilitate

drapel nc

Caut cel mai simplu mod de a partaja un singur fișier într-un mod de înaltă disponibilitate între o pereche de servere Linux. (Versiunea și distribuția nu sunt importante, caut o soluție generică.)

Am două servere, fiecare cu propriile discuri locale și partajări NFS și alte servicii între ele. Am un fișier pe care trebuie să îl acceseze ambele servere, dar nimic altceva decât acele servere nu trebuie să îl acceseze.

Dacă oricare dintre servere se blochează, vreau ca cel mai recent conținut posibil al acelui fișier să fie disponibil pentru serverul rămas. (Evident că celălalt server ar trebui să preia modificări la recuperare.)

Fișierul este un fișier de stare și, probabil, doar un server la un moment dat va scrie în el. Dimensiunea fișierului de stat este necunoscută, dar mică. Probabil intre 1 bloc si 2M. Este posibil ca dimensiunea fișierului de stare să crească în funcție de durata timpului de nefuncționare.

Fără a adăuga hardware extern, ce opțiuni există pentru o partajare de fișiere de înaltă disponibilitate ca aceasta?

djdomi avatar
drapel za
există o restricție care ar trebui utilizat?
user10489 avatar
drapel nc
Restricția este că nu vreau să adaug hardware (cum ar fi un iscsi nas) și că serviciile existente nu pot fi întrerupte. De exemplu, poate folosi NFS, dar nu vreau să distrug NFS până la punctul în care alți clienți din cluster au probleme cu utilizarea NFS. Sper să obțin o gamă de opțiuni din care pot alege, deoarece știu că există sisteme de fișiere HA, dar cele mai multe dintre cele pe care le-am analizat au o configurație destul de complexă, care este total exagerată pentru această aplicație.
djdomi avatar
drapel za
ați putea adăuga, vă rog, dimensiunea fișierului, dacă acesta este singurul lucru care trebuie sincronizat?
djdomi avatar
drapel za
M-am interesat și de această întrebare, dacă am o sarcină similară în viitor, am găsit articole interesante pe [StackExchange](https://unix.stackexchange.com/questions/307046/real-time-file-synchronization)
user10489 avatar
drapel nc
@djdomi: e interesant. S-ar putea să funcționeze, dar aplicația este suficient de vagă cu privire la modul în care utilizează fișierul de stare, încât nu știu dacă ar funcționa. Dacă se blochează sau alt IPC în fișierul de stare, acest lucru s-ar putea rupe. Dacă nu apare o soluție mai bună, va trebui să experimentez cu asta.
djdomi avatar
drapel za
în mod normal, pe Linux, niciun fișier nu va fi blocat vreodată, spre deosebire de Windows în mintea mea - ce fel de fișier este acesta?
user10489 avatar
drapel nc
Linux acceptă pe deplin blocarea fișierelor de consiliere, la fel ca Windows. Doar mai puține aplicații îl folosesc.
djdomi avatar
drapel za
Nu am spus că nu îl acceptă, este puțin probabil să o facă ;) totuși am găsit un al doilea instrument precum [bsync](https://github.com/dooblem/bsync)
user10489 avatar
drapel nc
bsync arată groaznic și exagerat. Și sunt de acord că este puțin probabil să folosesc blocarea fișierelor, dar ar trebui să cercetez asta (sau să experimentez) pentru a afla.
djdomi avatar
drapel za
Atâta timp cât nu descoperi adevărul despre dosarul tău, pot doar să dau sfaturi și să încerc să găsesc ceva în bila mea de sticlă ;)
user10489 avatar
drapel nc
Aruncând o a doua privire, lsyncd și bsync sunt foarte asemănătoare, nu le pot exclude încă.
user10489 avatar
drapel nc
@djdomi: M-am uitat la mai multe soluții bazate pe rsync și, de fapt, rezolvă o problemă similară pe care o am, dar nu și aceasta. Dacă puneți asta ca răspuns cu link-uri către diferitele variații rsync, aș da cel puțin un vot, dar cred că vreau cu adevărat un sistem de fișiere în acest sens, mai degrabă decât un serviciu de sincronizare a fișierelor.
Puncte:1
drapel cn

Există o mulțime de soluții - pentru un fișier probabil aș folosi GlusterFS - dar cred că ar trebui să aveți 3 servere pentru cvorum sau va trebui să rezolvați split-brains la recuperare. Ar trebui să îl puteți instala cu ușurință pe fiecare distribuție populară și să îl configurați nu mai mult de o oră.

user10489 avatar
drapel nc
O să dau bonusul la asta fără să-l accept deocamdată. M-am uitat la celelalte două soluții sugerate și le-am găsit lipsite, dar nu o pot accepta pe aceasta până nu am încercat-o. Dacă îl încerc și mi se pare ușor de configurat și funcționează, îl voi accepta.
Kszysiu avatar
drapel cn
Dacă alegeți soluția drbd, va trebui să configurați o configurație primară dublă (în opinia mea este încă nevoie de al treilea nod - altfel puteți avea splitbrain dacă apare o problemă de rețea) și apoi un fel de sistem de fișiere în cluster (dacă doriți să montați în 2 locuri în același timp) - nu puteți utiliza ext/xfs clasic sau orice alt sistem de fișiere. Dacă doriți să utilizați sistemul de fișiere clasic, atunci trebuie să-l montați doar într-un singur loc în același timp și să utilizați nfs sau ceva pentru a-l monta pe al doilea server. Aveți nevoie de un dispozitiv de blocare gratuit (sau lvm) pentru a utiliza drbd. Există o mulțime de straturi în care ceva poate eșua.
user10489 avatar
drapel nc
La testare, se dovedește că aplicația mea de fapt nu dorește deloc NFS din motive de performanță (prea multă latență). GlusterFS oferă un echilibru bun între performanța locală și sincronizarea la distanță, fără niciuna dintre problemele de sincronizare întârziate pe care le-ar oferi o soluție de tip rsync.
Puncte:1
drapel cn

Dacă perechea de servere rulează la cald-rece (adică numai unul dintre ele accesează fișierul odată), DRBD este o modalitate rapidă și stabilă de a-ți îndeplini obiectivul. DRBD este proiectat cu protecții split-brain, așa că ar trebui să fie „suficient de bun”.

O scurtă informație de pe site-ul DRBD:

Dispozitivul de bloc replicat distribuit (DRBD) este un software bazat pe soluție de stocare replicată, care oglindește conținutul blocați dispozitivele (hard disk-uri, partiții, volume logice etc.) între gazde.

DRBD oglindește datele

  • in timp real. Replicarea are loc continuu în timpul aplicațiilor modificați datele de pe dispozitiv.
  • în mod transparent. Aplicațiile nu trebuie să știe că datele sunt stocate pe mai multe gazde.
  • în mod sincron sau asincron. Cu oglindire sincronă, aplicațiile sunt notificate cu privire la finalizarea scrierilor după ce scrierile au au fost efectuate pe toate gazdele. Cu oglindire asincronă, aplicațiile sunt notificate cu privire la finalizarea scrierii atunci când scrierile au completate local, ceea ce de obicei este înainte ca acestea să se propagă la alte gazde.

Deoarece aceasta este o replicare la nivel de bloc, veți avea nevoie de puțină configurare suplimentară.De exemplu, va trebui să creați un sistem de fișiere deasupra dispozitivului replicat și va trebui să montați acel sistem de fișiere. Configurația recomandată implicită permite doar unei gazde să monteze sistemul de fișiere (pentru a evita situațiile de split-brain), astfel încât să puteți accesa datele doar pe un singur nod la un moment dat.

Întregul proces este bine documentat și există și niste ghiduri usoare disponibil.

Dacă ești mai interesat de automatizare, Stimulator cardiac + DRBD este o combinație foarte comună, este chiar documentată în Ghiduri stimulatoare cardiace care este, de asemenea, o introducere bună pentru DRBD în sine.

P.S. Amuzant cum ghidul stimulatorului cardiac pentru DRBD Legătura de mai sus descrie aproape perfect întrebarea ta.

Chiar dacă difuzați site-uri web statice, trebuie să faceți acest lucru manual sincronizați conținutul acelui site web cu toate mașinile din cluster nu este ideal. Pentru site-urile web dinamice, cum ar fi un wiki, nu este chiar și o opțiune. Nu toată lumea își poate permite stocarea atașată la rețea, dar cumva datele trebuie menținute sincronizate.

Introduceți DRBD, care poate fi considerat RAID-1 bazat pe rețea.

user10489 avatar
drapel nc
DRDB a fost de fapt prima soluție la aceasta pe care m-am uitat și am respins-o acum câteva luni. La suprafață, arată foarte bine, dar când am început să lucrez la complexitatea instalării efective a acestuia, cu transferul la eroare la cald schimbând exporturile NFS și distrugerea grosolană a NFS pentru a suporta failoverul la cald, am considerat că este prea perturbator pentru alte NFS. clienți cărora nu le-a păsat starea de failover la cald, plus alte complexități excesive.
user10489 avatar
drapel nc
PS: Votarea oricum pentru asta, deoarece este în general, pare o soluție bună.
drapel cn
Sunt de acord că a face NFS deasupra DRBD poate fi epuizant (greu de oprit accesul la punctul de montare pentru a putea dezactiva dispozitivul DRBD). Dar pentru cazul dvs. de utilizare, puteți utiliza monturi locale fără NFS. Un sistem de fișiere deasupra DRBD pe care îl montați atunci când este necesar.
user10489 avatar
drapel nc
Sistemul de fișiere este întotdeauna necesar, deoarece aplicația va avea întotdeauna fișierul deschis, chiar și atunci când acesta nu este primar și nu este scris.
drapel cn
De acord. DRBD este bun numai pentru configurarea cald-rece, unde „rece” înseamnă că aplicația nu rulează. Pacemaker ajută la automatizarea unora dintre acestea (adică, montați sistemul de fișiere înainte de a deschide aplicația). Se pare că nu este o soluție pentru cazul dvs. de utilizare.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.