Replicarea vs. clustering: Un aspect comparativ între ele
Știm că toți (sau aproape toți) termenii de calculator provin de la cuvintele standard în limba engleză. Astfel de cuvinte au devenit obișnuite, obișnuite pentru auz și multe sunt asociate numai cu IT. Dar dacă vă uitați la aceste cuvinte din punctul de vedere al definiției inițiale, atunci vă permite să înțelegeți mai profund de ce a ales acest cuvânt englez special pentru acest sau acel termen.
Combinând toate aceste valori ne permite să înțelegem bine ce înseamnă replicarea pentru cei care lucrează în IT:
REPLICAREA este repetarea înregistrării datelor, creând astfel o copie exactă a datelor, astfel încât să se reducă erorile (și timpul de nefuncționare) pe măsură ce crește baza de date.
Clusterul este o altă problemă. Pentru el, există opt definiții în dicționarul Collins (a doua ediție). Toate acestea conțin aceeași bază (care oferă doar indicații de bază despre ceea ce înseamnă clustering în IT): combinarea acestor lucruri în grupuri. În dicționarul mare enciclopedic toți termenii sunt, de asemenea, asociați cu unificarea obiectelor de un singur tip în grupuri. Astfel, un cluster în IT poate fi descris după cum urmează:
CLUSTER este unirea mai multor elemente omogene, care pot fi considerate ca o unitate independentă cu anumite proprietăți
Înțelegem etimologia engleză a acestor termeni în IT, dar ce înseamnă replicarea și gruparea în bazele de date? Care sunt meritele și dezavantajele relative ale fiecărei abordări pentru asigurarea unei disponibilități ridicate a sistemelor?
Grupuri de escală
Clusterele oferă posibilitatea de a elimina o anumită mașină ca punct de eșec, protejând accesul la baza de date de la defecțiunile hardware ale serverului.
Un cluster de sistem este alcătuit din două sau mai multe mașini (cunoscute ca noduri) care sunt integrate cu hardware și software pentru a funcționa ca o singură mașină virtuală. În cluster de hardware și software redundante sunt colectate pentru redundanță: dacă ceva nu merge bine pe un singur nod, sau un nod trebuie să fie luate offline pentru întreținere, resursele de cluster sunt transferați la un alt nod pentru a asigura accesul continuu.
Pentru ca bazele de date Progress® OpenEdge® să poată folosi clusterele în Progress, inițial au oferit un produs separat, Clusters Fathom® High Availability. De-a lungul timpului, această funcționalitate a fost inclusă în produsul OpenEdge 10B Enterprise și acum este pur și simplu numită "cluster-uri de tip failover".
Funcționalitatea "cluster-elor de tip failover" este independentă de furnizorii de sisteme de operare și hardware. Interfața "Failover Clustering" este ușor de utilizat și simplifică foarte mult administrarea OpenEdge într-un mediu în grup.
Funcționalitate „Failover Clustering“ nu înlocuiește sistemul de operare asociat cu software-ul pentru gestionarea cluster, doar vă permite să integreze OpenEdge managerul de cluster, astfel încât OpenEdge este corect definit ca o resursă de cluster. Astfel, baza de date include capacitatea de administrare a resurselor de cluster și a mecanismelor de remediere a erorilor, care vor furniza automat toleranță la erori în timpul unei opriri programate sau neplanificate.
Funcționalitatea „failover clustering“ înseamnă că sprijinul pentru grupurile nu necesită OpenEdge 10 de baze de date de către administratorii de baze de date Progress pentru a deveni experți în grupuri, cu toate că acestea trebuie să aibă cunoștințe de bază despre managerul cluster-ului. Cu toate acestea, este important să înțelegem că implementarea clusterelor este complexă, iar cineva din organizație ar trebui să aibă experiență în implementarea și gestionarea acestora.
Pe administratorii de baze de date Failover Cluster pur și simplu nevoie pentru a avansa să se decidă modul în care resursele de cluster se va comporta în timpul failover prin stabilirea unei reziliență politici coerente de acțiune decisivă în restaurare, care ar trebui să urmeze în mod automat resursa și toate dependențele sale, atunci când apare condiția, care necesită o tranziție către o altă resursă. Astfel de politici includ, de exemplu, numărul de încercări de a reporni baza de date pe nodul curent sau dacă aplicația ar trebui să revină la utilizarea nodului primar după ce a fost restaurat.
Grupurile de dezactivare au o interfață simplă de linie de comandă (PROCLUSTER), care oferă acces la software-ul clusterului sistemului de operare. PROCLUSTER înregistrează resursele care trebuie să fie prezente într-un mediu în grup. Cu aceasta, puteți înregistra baza de date ca o resursă de cluster, dar nu este nevoie să definiți dependențele pentru baza de date - funcționalitatea clusterului "failover" va avea grijă de acest lucru pentru dvs.
Funcționalitatea clusterului "failover" integrează OpenEdge într-un cluster utilizând software-ul de manager de cluster existent și extensia corespunzătoare a funcțiilor OpenEdge. Când utilizați clustere, puteți utiliza în continuare comenzile PROSERVE sau PROSHUT și echivalentele acestora. De asemenea, puteți utiliza PROCLUSTER pentru a porni și opri baza de date. De asemenea, puteți utiliza Admin Server pentru a porni și opri baza de date. Software-ul managerului de cluster al sistemului de operare știe despre OpenEdge și îl va procesa corect în caz de eșec.
Dacă structura bazei de date este modificată sau baza de date este transferată pe un nou dispozitiv de stocare, PROCLUSTER face foarte ușor salvarea bazei de date de protecție împotriva defecțiunilor. De exemplu, dacă modificați structura bazei de date, care funcționează într-un cluster (folosind PROSTRCT), funcționalitatea failover clustering determina automat ce resurse doriți să le includeți, opriți resursa în cazul în care se execută, și dezactivați și apoi reactivați automat resursa.
OpenEdge corespunde modelului de securitate definit de furnizor de sisteme de operare în ceea ce privește ceea ce pot crea și modifica utilizatorii; drepturi de acces la diferite directoare și dispozitive; și drepturi de pornire și oprire a resurselor, cum ar fi bazele de date.
Performanța bazei de date nu ar trebui să fie afectată de utilizarea clusterelor, cu excepția procesului separat suplimentar necesar pentru a verifica viabilitatea bazei de date și a raporta acest lucru software-ului de gestionare a cluster-elor.
Pentru grupurile OpenEdge failover, este necesară o configurație cu cel puțin două noduri care utilizează o arhitectură de stocare partajată. Baza dvs. de date trebuie să locuiască pe unul sau mai multe dintre dispozitivele partajate (cunoscute și ca magazine partajate).
Cel mai important avantaj al clusterelor cu defectare este capacitatea de a asigura ușurința utilizării și întreținerea unei baze de date într-un cluster prin automatizarea multor proceduri manuale care altfel ar trebui efectuate pentru a asigura o tranziție adecvată la o altă resursă. Cu toate acestea, rețineți că gruparea nu vă protejează de funcționarea defectuoasă a discurilor pe care se află baza de date.
replică
Replicarea datelor are două avantaje principale: abilitatea de a distribui copii ale informațiilor către unul sau mai multe site-uri și / sau de a furniza recuperare în caz de catastrofe pentru a menține un acces constant la date pentru clienți. Open replicarea OpenEdge replică automat modificările de la baza de date industrială OpenEdge la baza de date OpenEdge găzduită pe serverul de așteptare.
Replicarea OpenEdge elimină, de asemenea, baza de date ca punct de eșec într-un mediu cu disponibilitate ridicată.
Astfel, replicarea OpenEdge oferă utilizatorilor posibilitatea de a menține identitatea bazelor de date OpenEdge, oferind o rezervă caldă în cazul unei eșecuri a bazei de date. Când o bază de date nu reușește, o altă bază de date devine activă. Prin urmare, datele critice sunt întotdeauna disponibile pentru utilizatori.
Replicarea OpenEdge împiedică actualizarea bazei de date țintă prin orice alt mijloc decât replicarea în sine. Cu toate acestea, atunci când se utilizează OpenEdge Replication Plus, baza de date țintă este deschisă pentru cererile și rapoartele utilizatorilor, precum și pentru orice activități care nu au legătură cu scrierea în baza de date (de exemplu, pentru utilitarele bazei de date). O astfel de configurație poate îmbunătăți semnificativ performanța, permițându-vă să generați rapoarte și alte acțiuni asociate citirii intensive pe baze de date separate dar identice.
Desigur, bazele de date sursă și țintă pot fi pe aceeași mașină, însă vor fi destul de inutile, deoarece unul dintre principalele avantaje ale replicării este că baza de date țintă va fi conectată atunci când mașina sursă se prăbușește.
Replicarea OpenEdge acceptă două metode de replicare: sincron și asincron. În modul asincron, serverul de replicare OpenEdge trimite blocuri AI din jurnalul de tranzacții AI către agentul de replicare care rulează pe baza de date țintă.
În mod sincron, replicarea OpenEdge blochează procesarea ulterioară pentru utilizator până când tranzacția este aplicată complet bazei de date țintă.
Dintre cele două configurații (sincrone și asincrone), asincronul este mai productiv. Sincronă este cea mai sigură, dar deoarece utilizatorul din modelul sincron este blocat, performanța devine mai rea decât în modelul asincron.
Pentru a asigura funcționarea normală a replicării, trebuie să furnizați o comunicare de încredere TCP / IP între bazele de date sursă și țintă. Fără o conexiune fiabilă, replicarea OpenEdge va petrece sincronizarea bazelor de date în timp ce se recuperează de la o eroare de comunicare, ceea ce poate duce la întreruperea accesului utilizatorilor la bazele de date.
În lumea ideală a "disponibilității ridicate" ar trebui să încercați să implementați ambele tehnologii. Ele sunt, în esență, două fețe ale aceleiași medalii de continuitate a afacerii. Clustering minimizează timpul de nefuncționare de la eșecurile calculatorului și replicarea minimizează timpul de nefuncționare din cauza eșecurilor bazei de date.
Atât gruparea, cât și replicarea sunt opțiuni foarte atractive și ne permit să facem un pas semnificativ spre atingerea scopului final - disponibilitatea datelor non-stop. În ceea ce privește costul, replicarea în OpenEdge este un produs separat, în timp ce gruparea face parte din licența OpenEdge 10 Enterprise.
Soluții cluster acceptate în OpenEdge (PROCLUSTER)
HPUX (PA-RISC pe 64 de biți și Itanium)
- Software-ul HP:
- HPUX 11.i sau mai târziu
- HP mc / ServiceGuard 11.x sau o versiune ulterioară
SUN Solaris Sparc (64-bit)
- Software-ul SUN:
- SUN Solaris Sparc 10
- SUN Cluster Versiunea 3.1