Sistemele distribuite oferă adesea replicare (copiere) fișiere ca fiind unul dintre serviciile oferite clienților. Replicarea - acesta este un transfer asincron de modificări de date în sistemul de fișiere sursă pentru sistemele de fișiere aparținând diferitelor noduri ale unui sistem de fișiere distribuit. Cu alte cuvinte, sistemul funcționează cu mai multe copii ale fișierelor, în care fiecare copie este stocată pe un server de fișiere separat. Există mai multe motive pentru furnizarea acestui serviciu, cele mai importante fiind:
1. Fiabilitate crescută datorită prezenței de copii independente ale fiecărui fișier de pe serverele de fișiere diferite.
2. Distribuția sarcinii între mai multe servere.
Ca de obicei, problema-cheie legate de replicare este transparenta. Măsura în care utilizatorii ar trebui să fie conștienți de faptul că unele fișiere reprodus? În cazul în care acestea joacă un rol în replicarea sau replicarea este realizată în întregime automat? În unele sisteme, utilizatorii sunt pe deplin implicați în acest proces, în celălalt sistem face totul fără știrea lor. În acest ultim caz, noi spunem că sistemul de replicare este transparent.
În figura 3.12, b prezintă o abordare alternativă - o replicare leneș. Acest lucru creează doar o singură copie a fiecărui fișier de pe un server. Mai târziu, serverul va fi replicat automat la alte servere, fără programator. Acest sistem trebuie să fie suficient de rapid pentru a actualiza toate copiile, dacă este nevoie.
Fig. 3.12. a) Replicarea fișier exactă; b) File Replication leneș;
b) File Replication folosind grup
Luați în considerare cum poate fi modificat fișierele replicate existente. Există două algoritm bine-cunoscut pentru rezolvarea acestei probleme.
Primul algoritm, numit „replicarea primul exemplar“, cere ca un server a fost selectat ca primar. Celelalte servere sunt secundare. Când fișierul replicat este modificat, schimbarea este trimis la serverul principal, care efectuează modificările la nivel local, și apoi trimite modificările la serverele secundare.
Pentru a preveni o situație în care din cauza defectării serverului primar nu are timp să se informeze despre modificările toate serverele secundare, modificările trebuie să fie stocate în memorie numai citite înainte de a schimba copia primară. În acest caz, după repornirea serverului are posibilitatea de a verifica, în cazul în care nu se efectuează nici o renovare la momentul colapsului. Dezavantajul acestui algoritm este tipic sistemelor centralizate - fiabilitate scăzută. Pentru aceasta, metoda propusă de Gifford și cunoscut ca un „vot“ evita. Să fie n copii, atunci modificări trebuie făcute în orice copii W. În acest caz, serverele care stochează copii, trebuie să urmăriți numerele de serie ale versiunilor lor. În cazul în care un server efectuează o operație de citire, se face o cerere la orice servere R. Dacă R + W> n, că cel puțin un server conține cea mai recentă versiune, care poate fi determinată de numărul maxim.
O modificare interesantă a acestui algoritm este algoritmul de „vot cu fantome.“ În cele mai multe aplicații, operația de citire sunt mult mai frecvente decât scrie operații, astfel încât, de obicei, face puțin R și W - aproape de N. În acest caz, eșecul unui număr de servere conduce la o lipsă de cvorum pentru înregistrare. Votarea cu fantome rezolvă această problemă prin crearea unui server de diskless fictive pentru fiecare server a eșuat sau deconectat. serverul fictiva nu este implicat în citirea unui cvorum (în primul rând, nu are nici un fișier), dar se poate alătura înregistrarea de cvorum, și el doar scrie în dosarul transmis oriunde. Înregistrarea cu succes numai atunci când cel puțin un server de reale.
Când serverul a eșuat este repornit, acesta trebuie să obțină un cvorum citit pentru a detecta cea mai recentă versiune, pe care a copiat-te înainte de a începe operațiunile normale. Restul algoritmului este similar cu miezul.
- Organizația lucrează în rețele eterogene.