Sistemele de operare folosesc manageri de blocare pentru a organiza și coordona accesul la resurse . Managerul de blocare distribuit ( DLM [1] ) rulează pe fiecare mașină din cluster , cu o copie identică a bazei de date de blocare a clusterului. Astfel, DLM este un pachet software care permite computerelor dintr-un cluster să coordoneze accesul la resursele partajate.
Diverse implementări ale DLM au fost folosite ca bază pentru mai multe sisteme de fișiere cluster de succes, în care mașinile din cluster pot fi folosite pentru a stoca fișierele reciproc folosind un singur sistem de fișiere, cu beneficii semnificative de performanță și disponibilitate. Principalul beneficiu de performanță este atins prin rezolvarea problemei coerenței cache-ului pe disc între computerele participante. DLM este folosit nu numai pentru a bloca fișiere, ci și pentru a coordona toate tipurile de acces la disc. VMS Cluster (numit anterior VAX Cluster ) este primul sistem de clustering care a devenit larg răspândit și se bazează pe VAX/VMS (mai târziu OpenVMS ) DLM în acest fel.
DEC VAX/VMS a fost primul sistem de operare disponibil pe scară largă cu o implementare DLM. Această funcționalitate a fost introdusă în versiunea 4, deși interfața cu utilizatorul a fost aceeași cu managerul de blocare uniprocesor care a fost implementat pentru prima dată în versiunea 3.
DLM folosește conceptul generalizat de resursă ca obiect la care accesul trebuie controlat. Acesta poate fi un fișier, o înregistrare, o zonă de memorie partajată sau orice altceva alege dezvoltatorul aplicației . Dezvoltatorul însuși descrie ierarhia resurselor, astfel încât să poată determina numărul necesar de niveluri de blocare. De exemplu, o bază de date ipotetică ar putea descrie ierarhia resurselor după cum urmează:
Astfel, procesul din cadrul execuției are posibilitatea de a seta încuietorile necesare asupra bazei de date în ansamblu (resursa părinte), iar apoi asupra părților individuale ale bazei de date (resurse subordonate).
Un proces care rulează în interiorul unui cluster VMS poate obține o blocare a resurselor. DLM implementează șase moduri de blocare și fiecare dintre ele definește diferite niveluri de exclusivitate (compatibilitate) acordate. Pe măsură ce resursa este utilizată, puteți schimba nivelul modului de blocare la un nivel mai înalt sau mai jos. Când toate procesele deblochează resursa, informațiile sistemului despre resursă sunt distruse.
Următorul tabel de adevăr arată compatibilitatea fiecărui mod de blocare cu altele:
| modul | NL | CR | CW | relatii cu publicul | PW | EX |
|---|---|---|---|---|---|---|
| NL | da | da | da | da | da | da |
| CR | da | da | da | da | da | Nu |
| CW | da | da | da | Nu | Nu | Nu |
| relatii cu publicul | da | da | Nu | da | Nu | Nu |
| PW | da | da | Nu | Nu | Nu | Nu |
| EX | da | Nu | Nu | Nu | Nu | Nu |
Un proces poate bloca o resursă punând în coadă (SYS$ENQ) o solicitare de blocare. Aceasta este similară cu Queue IO , o tehnologie VMS care este utilizată pentru a efectua operațiuni I/O. O solicitare de blocare poate fi executată fie complet sincron, caz în care procesul așteaptă până când blocarea este acordată, fie asincron, caz în care mecanismul de captare a sistemului asincron (AST) este declanșat la obținerea blocării.
În plus, puteți seta un AST de blocare (Blocking AST), care este declanșat atunci când un proces a obținut o blocare, împiedicând un alt proces să acceseze resursa (în jargonul dezvoltatorilor VMS, denumit DoorBell AST ). Procesul inițial poate apoi, dacă este necesar, să ia măsuri pentru a permite accesul altora (de exemplu, prin coborârea sau eliberarea blocării). Blocarea AST oferă dezvoltatorilor de aplicații o modalitate convenabilă de a coordona instanțe de aplicație în cazurile în care o singură instanță este permisă să fie activă, în timp ce celelalte sunt puse în așteptare. Un exemplu de utilizare într-un cluster VMS este Cluster Node Alias, o adresă DECNet/LAT/IP care migrează în funcție de gradul de încărcare ( Load Balancing ) al nodului sau de disponibilitatea acestuia ( Failover ).
Fiecare resursă are asociat un bloc de valori de blocare de 32 de octeți. Poate fi citit la achiziționarea oricărui tip de blocare (cu excepția unei blocări NULL ) și poate fi actualizat printr-un proces care a dobândit o blocare a resurselor la nivel PW sau EX .
Poate fi folosit pentru a stoca informații despre resursa aleasă de dezvoltatorul aplicației. Exemplu de utilizare: stocarea numărului de versiune al unei resurse. De fiecare dată când obiectul asociat cu acesta (de exemplu, o intrare în baza de date) este actualizat, proprietarul lacătului incrementează blocul cu valoarea lacătului. Când un alt proces dorește să citească resursa, acesta dobândește blocarea corespunzătoare și compară valoarea curentă a blocării cu valoarea pe care a avut-o ultima dată când procesul a accesat resursa blocată. Dacă valoarea este aceeași, procesul știe că resursa asociată nu a fost actualizată de la ultima dată când a fost citită și, prin urmare, nu este nevoie să o citiți din nou. Prin urmare, această tehnică poate fi folosită pentru a implementa diferite tipuri de cache într-o bază de date sau aplicații similare.
Un alt exemplu de utilizare: comunicarea între procese ( IPC - InterProcess Communication ) - în cazurile în care este necesară o reactivitate ridicată pentru schimbul de porțiuni mici de date (în limita a 32 de octeți) între procese pe diferite noduri VMS Cluster cu cerințe de latență scăzute. Pentru schimbul de porțiuni mai mari de date (până la 1 Mb) - se folosește tehnologia ICC ( serviciul de comunicare IntraCluster , SYS$ICC [2] ).
Blocare reciprocă ( deadlock ) - o situație în care mai multe procese sunt într-o stare de așteptare nesfârșită pentru resursele ocupate de aceste procese în sine. E. Dijkstra a numit inițial această situație o „îmbrățișare a morții” [3] .
OpenVMS DLM verifică periodic procesele pentru situații de blocaj. În cazul în care un proces blochează resursa 1 în timp ce așteaptă ca resursa 2 să devină liberă, care este blocată de un al doilea proces care, la rândul său, așteaptă ca resursa 1 să devină liberă, al doilea proces determină o stare de blocaj. În acest caz, se fac pași pentru a ieși din starea de blocaj prin eliberarea blocării resursei care a fost blocată prima.
În ianuarie 2006, codul OCFS2 (Oracle Cluster File System) [4] propus de programatorii corporației cu același nume a fost inclus în versiunea 2.6.16 a nucleului Linux , în noiembrie 2006 codul [5] pentru suportul software de cluster de la corporația a fost adăugată la versiunea de kernel 2.6.19 Red Hat , în special, suport pentru sistemul de fișiere GFS2 . Ambele sisteme se bazează pe modelul de succes VMS DLM [6] . În același timp, managerul de blocare distribuit de la Oracle avea un API simplificat - funcția sa de bază dlmlock()avea doar 8 parametri, în timp ce un apel de sistem similar SYS$ENQîn VMS, precum și o funcție dlm_lockîn DLM de la Red Hat, aveau 11 parametri fiecare.
Google și-a dezvoltat implementarea unui serviciu de blocare pentru sistemele distribuite slab cuplate, pe care l-au numit Chubby [7] . Acest serviciu este conceput pentru a oferi blocare grosieră (Coarse Grained Lock), precum și pentru a sprijini un sistem de fișiere distribuit limitat funcțional, dar fiabil. Părțile majore ale infrastructurii Google, inclusiv sistemul de fișiere Google , BigTable și MapReduce , folosesc Chubby pentru a sincroniza accesul la resursele partajate. Deși Chubby a fost conceput inițial ca un serviciu de blocare, acum este utilizat pe scară largă de Google ca server de nume , înlocuind DNS [7] .
Apache Zookeeper , un proiect al Apache Software Foundation , este un depozit de chei și valori ierarhice distribuite care este utilizat pentru a furniza un serviciu de configurare distribuit, un serviciu de sincronizare și un registru de nume pentru sistemele mari distribuite [8] . ZooKeeper poate fi folosit și ca manager de încuietori distribuite [9] . Zookeeper a fost inițial un sub-proiect în cadrul Hadoop , dar acum face parte din lista principală a proiectelor ASF .
Arhitectura Zookeeper acceptă disponibilitate ridicată prin redundanța serviciului. Astfel, clienții pot iniția alegerea unui alt lider Zookeeper dacă cel actual nu răspunde. Nodurile Zookeeper își stochează datele într-un spațiu de nume ierarhic similar cu un sistem de fișiere sau cu o structură de date arborescentă [10] .
Zookeeper este folosit de multe companii, inclusiv Rackspace , Yahoo! [11] , Odnoklassniki , Reddit [12] , Yandex [13] și eBay , precum și platforma de căutare open source full-text Solr [14] .
Demonul etcd , care vă permite să actualizați setările nodurilor din infrastructura de cluster CoreOS , oferă și capabilitățile unui manager de blocare distribuit [15] .
SGBD -ul de înaltă performanță non -relațional Redis , care este un depozit de date cheie-valoare jurnalizat , bazat pe rețea , poate fi utilizat pentru a implementa algoritmul de gestionare a blocării distribuite Redlock [16] .