2.556 pregleda

Osnove NAS i SAN sustava (i malo više) – treći dio

1

U seriji članka autor Hrvoje Horvat upoznat će nas s osnovama i načinom rada NAS, SAN, ZFS i složenih klasterskih poslužitelja, te će podijeliti brojne korisne savjete iz praktičnog iskustva.

 

Kolega Hrvoje Horvat član je udruge Open Source Osijek na čijim je mrežnim stranicama tekst izvorno objavljen. U posljednjem članku govorimo o ograničenjima klasterskih sustava, kao i odgovoru na praktične probleme (CEPH).

 

 

Problemi klasterskih NAS i SAN sustava

Kao što smo vidjeli u prethodnom članku, klasterski NAS i SAN sustavi imaju svoje limitirajuće faktore. Kod većine je to cijena ali i ograničenja skalabilnosti. Naime veći sustavi često trebaju sve veći i veći kapacitet pohrane podataka, koji postaje ili preskup u startu ili zahtjeva vrlo velika ulaganja kod proširenja. I na kraju krajeva svi oni opet imaju svoje limite, najviše sa strane proširenja.

Kod najvećih igrača poput cloud providera pružanje usluge pohrane velike količine podataka pr. za spremanje virtualnih računala i sl. je svakodnevni posao. Proširivost ovakvih sustava je krucijalna. Rani odgovor na ovu problematiku je bio razvoj (i kasnija upotreba) sustava koji uopće ne rade na način na koji rade tradicionalni klasterski NAS ili SAN sustavi.

 

Object storage

I rodio se “Object storage”, koji podatke “promatra” i pohranjuje kao objekte, za razliku od tradicionalnih sustava kod kojih postoji neka struktura datoteka i direktorija (odnosno klasičan datotečni sustav) kod NAS sustava. Ovo je drugačije i od SAN sustava koji rade s blokovima podataka koji se spremaju u sektore na disku (logičkom ili fizičkom).

Kao što RAID kontroler “razlama” neku datoteku na male blokove podataka koje dalje raspoređuje na diskove, ovisno o RAID polju, tako i ovi sustavi “razlamaju” podatke na Tzv. objekte (uz pripadajuće metapodatke), koje onda raspoređuju na poslužitelje u klasteru.

 

Objektni “storage” trebao bi nam nuditi, skalabilni (proširivi) sustav otporan na greške. Ovakvi sustavi su se počeli znatnije razvijati od 1995. godine iako su neki radovi i ideje nastali i znatno ranije. Prvo komercijalno riješenje je razvila tvrtka “Centera Technology” koju je odmah kupila tvrtka “EMC²” te je 2002. izbacila na tržište pod tržišnim nazivom “EMC Centera”. Ova linija proizvoda se i danas razvija.

Smatra se da se u razvoj ove tehnologije od strane neovisnih investitora u prvim godinama uložilo oko 300 milijuna dolara (ova cifra je rasla sve više). Ne računajući ulaganja tvrtki poput : DataDirect Networks, Centera, Atmos, HDS, EMC2, HP, IBM, NetApp, Redhat i drugih a kasnije i od strane cloud providera poput: Amazon AWS, Microsoft (Microsoft Azure), Google (Google Cloud Storage) i drugih.

Pogledajmo listu nekoliko visoko skalabilnih, redundantnih “Object storage” sustava dostupnih pod nekom od open source licenci:

  • CEPH (info)
  • Lustre (info)
  • LizardFS (info)
  • Hadoop Distributed File System (info)
  • Moose File System (info)
  • Quantcast File System (info)
  • i dr.

 

Kod većih sustava, kao i kod sustava kod kojih korisnici NE žele kupovati super skupi hardver i softver za “Object Storage” sustave, jedno od open source rješenja je “CEPH” o kojemu ćemo govoriti dalje u tekstu.

 

 

CEPH je distribuirani objektni sustav za pohranu podataka (eng. storage) koji je dizajniran za postizanje odličnih performansi, te sustav koji je visoko dostupan i pouzdan. Osim toga on je krajnje skalabilan odnosno proširiv do razine exabyte-a.

Ovo je sustav koji je zbog svog dizajna otporan na greške i kvarove cijelih poslužitelja i/ili pojedinačnih diskova ili grupe diskova, a u većim implementacijama, cijelih ormara punih poslužitelja pa čak i cijelih podatkovnih centara a samim time i desetcima, stotinama ili tisućama diskova. Sve ovisno o konfiguraciji i raspoloživoj opremi.

Razvio ga je Sage Weil kao temu za doktorski rad na sveučilištu “University of California, Santa Cruz”. Razvoj se nastavio u tvrtki “Inktank”. Navedenu tvrtku je kupio “RedHat” 30. travnja 2014. godine (za 175 milijuna $ u gotovini). Tvrtka “Red Hat” ga nastavlja razvijati do danas (kao i zajednica koja ga koristi). Projekt i dalje planira ostati open source. Naravno, vrlo brzo nakon učlanjenja u obitelj “Red Hat” svi važniji proizvođači hardvera počeli su nuditi sustave koji su certificirani za CEPH (npr. Supermicro, HP, DELL i mnogi drugi).

Osim navedenog hardvera, CEPH se može koristiti i na bilo kojem hardveru koji imate a na kojem se može pokretati bilo koja RedHat ili Debian bazirana distribucija Linuxa, imalo novije generacije. Dakle dostupni su RPM i Debian paketi. Osim toga dostupan je i izvorni kod CEPH-a, pa je sve moguće kompajlirati i za druge distibucije Linuxa. CEPH klijent se već standardno nalazi unutar Linux kernela. Server je dostupan ionako kao open source.

Osim navedenog, CEPH je trenutno integriran s dvije platforme za virtualizaciju:

  • Open Stack
    • Integriran je sa: Nova, Cinder i Glance za “Block storage”,
    • Integriran je sa Keystone i Swift za “Object storage”,
  • Proxmox VE
    • “Block storage” za virtualna računala i za Linux kontejnere.

Koriste ga i najveći igrači, poput:

  • Amazon AWS – prema nekim informacijama, koristi se za neke dijelove S3 Storage sustava,
  • Facebook – za neke dijelove sustava,
  • CERN – prema podacima od prošle godine – koriste ga za ukupno 1+ PB (za spremanje podataka),
  • DreamHost (Web hosting provider):
    • 2+ PB za S3,
    • 3+ PB kao “Block Device” – za virtualke,
  • … i mnogi drugi (mnogi i ne žele iznositi što točno koriste iz sigurnosnih razloga).

 

CEPH iako radi s objektima na najnižoj razini, na vršnoj se može koristiti za tri različite “upotrebe” i to:

  1. Kao “Block Device” i to ako se koristi kao “Rados Block Device” (RBD) – vidljiv dalje kao “Block Device” ili logički disk koji se koristi za opću upotrebu (pr. za spremanje diskova virtualki i sl.).
  2. Kao “Object Storage” preko “RADOSGW”-a, a koji je “S3” i “Swift” kompatibilan – najčešće se koristi za snimanje/čitanje datoteka bilo kojeg tipa preko web-a (korištenjem “put” ili “get” metoda).
  3. Kao “Filesystem” tj. direktno kao datotečni sustav, preko “CEPHFS” – može se “mountati” kao običan datotečni sustav.

Pogledajte i malo više detalja :

 

 

 

Odabirom pojedinog modela (“CEPH Block Device”, “CEPH Object Stoage” ili “CEPH FIlesystem”) moramo koristiti i dodatne servise odnosno funkcionalnosti koje su nužne za ovakav rad. Prema tome potrebno je detaljnije se upoznati sa zahtjevima i načinom implementacije te konfiguracije svakoga od njih.

 

 

Prednosti CEPH-a

Osnovne prednosti CEPH-a (i u kombinaciji s Proxmox VE platformom za virtualizaciju) su:

  • (Relativno) jednostavan setup i management iz naredbene linije i grafičkog sučelja Proxmox VE.
  • “Thin provisioning” (minimalno zauzeće stvarnog diskovnog prostora s podacima).
  • Izrada snapshota podataka (datoteka) “u letu” (dok se radi na njima).
  • Automatsko popravljanje grešaka u radu (kod ispada diska, poslužitelja i sl.).
  • Ne postoji niti jedna komponenta sustava koja nije redundantna (zalihost).
  • Sustav je skalabilan (proširiv) do razine Exabyte-a.
  • Moguća je konfiguracija više segmenata (eng. Ceph Pools) polja za pohranu podataka, te razina performansi/replikacije za svaki segment.
  • Svi podaci unutar polja su replicirani, čineći cijelo polje otpornim na kvarove.
  • CEPH je moguće instalirati i na pristupačan hardver.
  • Nema potrebe za RAID kontrolerima (“zabranjena” je njihova upotreba – kao i kod ZFS-a kod kojega je to izričito ZABRANJENO!).
  • CEPH je razvijan kao “open source” prema licenci LGPL 2.1.

 

 

Kako se podaci distribuiranju unutar cijelog CEPH clustera?

Koristi se tzv. CRUSH algoritam i pripadajuća “CRUSH” tablica (koja je distribuirana na više poslužitelja), a zadužen je za distribuciju, replikaciju i redistribuciju podataka unutar CEPH clustera. CRUSH je dizajniran da omogućava raznoliku upotrebu, ovisno o veličini implementacije. U skladu s tim postoje “CRUSH” tipovi koji opisuju fizičku poziciju CEPH-a unutar cijelog CEPH clustera. Drugim riječima definiramo fizičku hijerarhijsku strukturu svakog elementa unutar hijerarhije:

  • root (predstavlja vršnu komponentu cijelog CEPH-a – nazovimu ju “cijelom planetom”),
  • region (predstavlja prvu nižu hijerarhiju – recimo kontinent),
  • datacenter (predstavlja pojedini podatkovni centar),
  • room (predstavlja “sobu” unutar podatkovnog centra),
  • pod (predstavlja logičku podjelu unutar jedne “serverske” sobe) – može predstavljati i jedan dio podatkovnog centra koji može biti podjeljen na više ovakvih potencijalno nezavisnih (što se tiče mreže, napajanje, klimatizacije i sl.) cjelina,
  • pdu “Power Distribution Unit” odnosno podjela prema izvoru napajanja (u podatkovnim centrima ih imamo više pa je ovo dobrodošla dodatna razdioba),
  • row (predstavlja jedan red s ormarima punim poslužitelja),
  • rack (predstavlja jedan ormar s poslužiteljima),
  • chassis (predstavlja jedno kućište unutar kojega može biti više poslužitelja – misli se na “Blade” učilišta),
  • host (predstavlja jedan poslužitelj),
  • osd (predstavlja, u konačnici, pojedinačni disk.

Pogledajmo kako to izgleda:

 

 

 

Osim toga, u svakoj kategoriji u hijerarhiji može biti i više elemenata na istoj razini – poput primjera na slici dolje:

 

 

 

Ovakav hijerarhijski model nam omogućava stvarno raznolike scenarije upotrebe. Stoga CEPH može biti implementiran od najmanjih sustava (npr. minimalno tri poslužitelja s diskovima) do sustava koji imaju tisuće poslužitelja s diskovima i raspoređeni u velikom broju podatkovnih centara. Pogledajmo nekoliko mogućih scenarija:

1. Dva podatkovna centra, svaki s par poslužitelja:

Izvor: http://cephnotes.ksperis.com/blog/2015/02/02/crushmap-example-of-a-hierarchical-cluster-map

Vidljivo je da unutar svakog podatkovnog centra (datacenter) imamo dva poslužitelja (host) od kojih svaki ima po tri tvrda diska (osd).

 

2. Prošireni scenarij u kojemu isto imamo dva podatkovna centra ali sada imamo poslužitelje s običnim (tvrdim diskovima) i poslužitelje sa SSD diskovima. Poslužitelji s “običnim” diskovima su u jednoj “grupi” a oni s SSD diskovima u drugoj “grupi”:

Izvor: http://cephnotes.ksperis.com/blog/2015/02/02/crushmap-example-of-a-hierarchical-cluster-map

 

2.a Logička shema dolje prikazuje i inicijalizaciju tzv. Pool-a. U CEPH terminologiji Pool je ono što bi u RAID-u bilo RAID polje diskova. Moguće je imati više “Pool”-ova, svaki sa svojom konfiguracijom. Pri tome, svaki pojedini Pool može biti za svoju namjenu: brzina, pouzdanost, vrijeme odziva, georeplikacija…

Izvor: http://cephnotes.ksperis.com/blog/2015/02/02/crushmap-example-of-a-hierarchical-cluster-map

 

U primjeru na slici u svakom podatkovnom centu imamo poslužitelje sa SSD i poslužitelje s običnim tvrdim diskovima.

  • Vršno Pool “hdd” koristi sve poslužitelje koji imaju obične diskove.
  • Vršno Pool “ssd” koristi sve poslužitelje koji imaju SSD diskove.

Kod kreiranja Pool-a (to je korak koji možete vidjeti u tekstu o radu CEPH-a) odabiremo koliko replika će imati, kao i druge parametre.

 

 

Kako se zapisuju podaci na CEPH cluster?

Nakon što je definirana hijerarhijska struktura za CEPH cluster (CRUSH) te kreiran ekvivalent RAID polja koji se prema CEPH terminologiji naziva Pool sve je spremno za rad (to je opisano negdje od koraka ”CEPH pools“). Pojednostavljeno, svaka datoteka koja se zapisuje razlama se na manje blokove koji se onda u konačnici zapisuju odnosno distribuiraju na dostupne poslužitelje i njihove diskove. Dakle, ako smo za određeni Pool na kojem radimo, kod kreiranja odabrali da je broj replika (prema CEPH terminologiji “CEPH Pool Size”) jednak tri, to znači da se podaci zapisuju na odredišni poslužitelj a potom na još druga dva poslužitelja. Tako da ćemo u ovom slučaju isti podatak imati sveukupno na tri mjesta.

Veličina bloka je standardno 4 MB ali se može promijeniti do razine više MB – ovisno o vrsti podataka koje zapisujemo ili čitamo. To znači da je za neke primjene ova veličina zadovoljavajuća a za neke je ova veličine premalena jer se zapisuju ili čitaju podaci koji zahtijevaju dohvaćanje većih blokova podataka odjednom. Promjenom veličina bloka možemo poboljšati performanse i smanjiti opterećenje sustava – zbog smanjenja broja operacija dohvaćanja velikog broja malih objekata.

Ulazno/izlazne operacije prema diskovnom sustavu kod pisanja ili čitanja se zovu IOPS-i. Klasični (magnetski) odnosno “mehanički” diskovi su znatnije pogođeni ovim operacijama od SSD diskova. Dakle SSD diskovi u prosjeku mogu podnijeti desetke, stotine i tisuće puta više ulazno/izlaznih operacija u sekundi, od mehaničkih/magnetskih diskova.

 

Proces distribucije podataka

Podaci se distribuiraju na cijeli CEPH cluster, sve njegove poslužitelje i njima dostupne tvrde diskove, te se istovremeno radi replikacija, svakog bloka podataka na drugi poslužitelj odnosno disk na njemu. Sve prema tome kako je konfigurirana hijerarhija za CRUSH te koliko replika smo odabrali za određeno CEPH polje odnosno Pool. Proces zapisivanja (i dodatno replikacije) radi se transakcijski (pogledajte ZFS i transakcijski model) – zbog konzistentnosti podataka.

Kod procesa čitanja se također prema klasterskoj tablici i CRUSH algoritmu zna (određuje/izračunava) koji blok podataka je završio na kojem poslužitelju, i na kojem disku na njemu, te se počinje s čitanjem blokova podataka – sa svih poslužitelja i svih diskova. U konačnici sve se svodi na to da se podaci zapisuju na sve poslužitelje te se kod čitanja također čitaju sa svih njih. Ovime se znatno povećavaju performanse: što više poslužitelja to je brže zapisivanje ili čitanje.

Što u slučajevima kada se primjerice:

  • poslužitelj gasi (zbog kvara, održavanje ili bilo kojeg razloga),
  • dodaje se novi poslužitelj,
  • dodaju se novi diskovi u postojeće poslužitelje ili se neki diskovi vade

… tada CEPH radi tzv. redistribuciju podataka. Pogledajmo sliku upotrebe CEPH-a na Proxmox VE platformi za virtualizaciju:

 

 

 

Na slici su vidljiva samo dva poslužitelja 225x i 224x (iako su u testu bila tri (i 223x)) od njih svaki ima po 8 tvrdih diskova:

 

posluzitelj

 

 

Pogledajte stupac “Used” i to postotke (kreću se od 0.27 do 0.31). Kod dobro balansiranog sustava, postotak zauzeća (upotrebe) svih diskova mora biti podjednak. Za to su zaduženi automatizmi o kojima ćemo malo kasnije.

Dodavanjem novog diska, vađenjem jednog od njih ili dodavanjem/izbacivanjem cijelog poslužitelja sa svim diskovima CEPH kreće u redistribuciju svih podataka. To znači da ako smo recimo dodali novi poslužitelj s osam diskova (detaljnije se radi i o koeficjentu svakog diska ovisno o njegovom kapacitetu i drugim parametrima) podaci se preraspoređuju unutar cijelog klastera i svih diskova, tako da svi diskovi na svim poslužiteljima budu podjednako zauzeti. Ovo je vrlo važno jer se nakon dovršetka redistribucije podaci tada počinju zapisivati ili čitati i s tog novog poslužitelja ili novog diska, ravnomjerno koristeći sve resurse (poslužitelje i diskove) klastera.

Za redistribuciju kao i za replikaciju podataka, koristi se (preporuča) zasebna mreža – da se ne opterećuje “radna” mreža.

Prema CEPH preporukama, potrebno je imati dvije zasebne mreže:

  1. “Public Network” – preko nje čitamo i pišemo podatke na CEPH,
  2. “Cluster Network” – preko nje se odrađuju sve ostale radnje poput redistribucije i replikacije podataka.

 

Logička shema je vidljiva na slici:

 

Opis:

  • Podaci se spremaju kao objekti,
  • Objekti se nalaze unutar Pool-a,
  • Standardna veličina objekta je 4MB,
  • Objekti se grupiraju u “Placement Grupe” (PG). Placement Grupe su distribuirane preko više OSD-ova (diskova),
  • OSD-ovi se koriste za stvarnu distribuciju (“read” i “write” operacija) objekata na tvrde diskove,
  • “CRUSH” tablica/konfiguracija se koristi za kreiranje i kasniju upotrebu i distribuciju objekata (podataka) unutar svakog pojedinog Pool-a za cijeli CEPH klaster. (Moguće je imati i više Pool-ova s različitim konfiguracijama).

Pool promatrajte kao RAID polje.

 

Iako se podaci u konačnici zapisuju kao objekti, odnosno najmanji blok podataka je jedan objekt, standardne veličine 4MB, objekti se prvo grupiraju u tzv. “Placement” grupe. Ove “Placement” grupe prema tome povezuju niz objekata koji su dalje raspoređeni na niz OSD-ova. Pohrana objekata na OSD-ove znači pohranu na niz tvrdih diskova, raspoređenih na više poslužitelja – ovisno o Pool-u i hijerarhijskoj strukturi definiranoj u CRUSH tablici/konfiguraciji.

Prisjetimo se da “CRUSH maps” tablica/konfiguracija definira fizičku topologiju cijelog CEPH klastera koju koristi CRUSH algoritam za određivanje (izračun) točnih pozicija na koje će se podaci (u konačnici objekti) i njihove replike spremati odnosno čitati.

 

Sve operacije čitanja i pisanja se zapravo rade na razini svake pojedine “Placement” grupe a ne na razini svakog pojedinog objekta. U protivnom bi rad na razini svakog pojedinog objekta uz dohvaćanje metapodataka za svaki objekt drastično usporilo cijeli sustav. “Placement” grupe rješavaju problem s performansama, jer se transakcije događaju na razini PG-a, kao i pohranjivanje ili baratanje s pripadajućim metapodacima, koje su definirani za cijelu placement grupu a n pojedini objekt u njoj. CEPH kod čitanja ili pisanja radi na razini “placement” grupa i njihovih metapodataka (koji ih opisuju), i to transakcijski.

Osim poboljšanja performansi, uvođenjem “Placement” grupa, poboljšala se i skalabilnost (proširivost) cijelog CEPH sustava. Odnos između broja objekata i broja “Placement” grupa se može okvirno izračunati ili utvrditi testiranjem. Prema preporukama, osnovna formula za izračun je:

Za što bolji odabir odnosno izračun broja “Placement grupa” potrebo je uzeti i druge parametre (o tome kasnije).

Možemo promatrati “Placement” grupe (PG) kao segmente unutar svakog logičkog Pool-a odnosno polja (objekata) na koje se logički “spaja” svaki CEPH klijent za čitanje ili pisanje na CEPH klaster. CEPH, vršno gledano, sprema podatke unutar Pool-a, koji predstavlja logičku grupu PG-ova. Pool se brine i o tome koliko je primjerice replika potrebno izraditi kod svakog zapisivanje podataka. CEPH može raditi i “snapshot” Pool-a, u bilo kojem trenutku – kao “snimku stanja u vremenu”.

 

 

CEPH Block Device (Rados Block Device – RBD)

Mi ćemo se dalje u tekstu fokusirati na upotrebu “CEPH Block device”-a. Prema tome, druga dva modela (“CEPH Object Storage” i “CEPH Filesystem”) više nećemo spominjati.

Potrebne funkcionalnosti (CEPH Roles) za RBD

Kao što smo rekli za svaki od CEPH modela, potrebne su određene funkcionalnosti na strani CEPH poslužitelja u CEPH klasteru. Za upotrebu CEPH-a kao “Block device”-a tj. kao RBD-a, potrebne su nam dvije funkcionalnosti odnosno “uloge” poslužitelja. To prema definiciji znači da moramo imati poslužitelje od kojih je svaki zadužen samo i isključivo za jednu ulogu:

  • uloga Monitor poslužitelja (eng. Monitor Node),
  • uloga OSD poslužitelja (ovo su poslužitelji na kojima se nalaze tvrtdi diskove koje ćemo koristiti u CEPH klasteru).

Preporuka za najosnovniju upotrebu kao CEPH RBD bila bi:

  • minimalno 3 poslužitelja s ulogom “Monitor”,
  • minimalno 3 poslužitelja s ulogom “OSD”.

 

Mi ćemo, s obzirom da imamo samo tri poslužitelja s diskovima (koje želimo koristiti kao CEPH kalster za “Block device”) te stoga što što ne tražimo ekstra/turbo brz/proširiv/… sustav, napraviti slijedeće.

Uloge poslužitelja:

  • Poslužitelj 1 : OSD i MONitor
  • Poslužitelj 2 : OSD i MONitor
  • Poslužitelj 3 : OSD i MONitor.

Dakle, svaki poslužitelj će imati i OSD i MONitor ulogu. S ovime smo na malo zaobilazan način osigurali da imamo i tri OSD-a i tri MONitora.

 

Zbog čega minimalno tri (3) poslužitelja za klaster?

Većina klastera u radu rade na principu ”Quoruma“, dakle tri je najmanji broj poslužitelja u kojemu minimalna većina (dva) poslužitelja sudjeluju u dogovaranju i provjerama rada. Ovdje se radi o sustavu “glasovanja” i izbora što znači da svaki poslužitelj ima jedan glas za glasovanje. Ako su samo dva poslužitelja u sustavu glasovanja izbori su nemogući. Prema tome za sustav glasovanja je potrebno minimalno troje.

 

Quorum pojednostavljeno

U ovakvim minimalnim klasterima s tri poslužitelja, u svakom trenutku moraju biti aktivna i funkcionalna dva (2) poslužitelja. Ovo ne mora čak značiti da je jedan poslužitelj ugašen već možda ne radi kako treba, pa daje pr. krive rezultate (ili ih ne daje uopće) tada se ta zadnja dva pokušavaju sustavom “glasovanja” dogovoriti. Ovakav sustav “Quoruma” se koristi i kod klasterskih sustava za virtualizaciju pr. Proxmox VE cluster.

Zamislimo tri poslužitelja koja imaju “Cluster Map” tablicu s pripadajućom verzijom tablice i njen hash/checksum koji govori o tome da li je integritet tablice narušen.

Primjer:

Prva dva poslužitelja kažu da im je zadnja verzija v.234 te HASH : A348F3609D a treći poslužitelj tvrdi da je njegova zadnja verzija v.252 te HASH : 35D56FAB5D. Dogoditi će se to da će prva dva nadglasti treći iako ima veći broj verzije (što bi značilo da je novija) te se on IZBACUJE iz klastera te se više ne uzima u obzir koje slijedeće provjere (sve dok i on ne bude imao sve iste “podatke” kao i preostala dva). Obično kod ovakvih sustava postoje tzv. “Izbori” za klaster “Mastera”, a koji se događaju svakih nekoliko sekundi (pr. svakih 15. sekundi). Dakle u jedinici vremena unutar koje se događaju izbori (ili reizbori) za “Mastera” tj. “Primarnog” poslužitelja, svaki poslužitelj ima određeni prioritet:

  • Prvi poslužitelj – prioritet 1,
  • Drugi poslužitelj – prioritet 2,
  • Treći poslužitelj – prioritet 3.

Ako se recimo onaj s najmanjim brojem prioriteta bira za “Master”-a (tj. “Primarnog”) , tada će “Prvi poslužitelj” postati “Master” ako je sve u redu s njegovim verzijama i integritetom. Ako nije tada će “Master” postati onaj s prioritetom 2 tj. “Drugi poslužitelj” itd. Dakle svakih recimo 15. sekundi se odabire novi “MAster”.

“Master” je obično zadužen za vrlo važne operacije odlučivanja – koji će poslužitelj biti izbačen iz klastera te će on to i fizički napraviti (obično zapisati u datoteku u kojoj je lista aktivnih poslužitelja u klasteru). Ova funkcionalnost je ne zahtjevna prema resursima ali kao što je vidljivo, vrlo važna. “Master” osim toga radi još nekoliko resursno ne zahtjevnih zadaća – ovisno o vrsti i tipu klastera.

Ovo znači da ako primjerice restartamo cijeli klaster (recimo zbog nadogradnji sustava), da to radimo oprezno. Prvo jedan poslužitelj, pa kada je on potpuno funkcionalan nakon restarta, drugi, pa kada je drugi nakon restarta funkcionaln, tek onda treći.

 

 

MONitor uloga u CEPH clusteru

  • MONitor uloga mora biti instalirana na minimalno tri poslužitelja. Ona se brine o:
  • tome koji poslužitelji u CEPH klasteru su živi OSD poslužitelji i koji su sve dostupni diskovi (OSD-ovi).
  • Pohranjuje i održava 5 “tablica/konfiguracija”:
    • Monitor map – tablica s MONitor poslužiteljima,
    • OSD map – tablica s OSD poslužiteljima/diskovima,
    • PG map – tablica s PG (Placement Group)- grupama za pohranu objekata,
    • CRUSH map – “CRUSH” hijerarhijska tablica/konfiguracija,
    • MDS map (za MDS ulogu [koristi se samo za S3 ili Swift tj. za upotrebu kao “Object Storage”]).

 

OSD = Object Storage Daemon. Servis (daemon) je to zadužen za rad s objektima i njihovu distribuciju te u konačnici snimanje na tvrdi disk. Jedan OSD daemon (servis) je zadužen za jedan tvrdi disk. Dakle, OSD poslužitelj koji ima osam (8) tvrdih diskova, ima i pokrenuto osam (8) OSD daemona (servisa).

 

 

OSD uloga u CEPH clusteru

Ovu ulogu moraju imati minimalno tri (3) poslužitelja. OSD uloga je zadužena za:

  • Spremanje objekata na lokalni datotečni sustav (u konačnici na “OSD” tvrtde diskove ) i omogućavanje pristupa objektima preko mreže.
  • Za replikaciju objekata koji se zapisuju na konkretni OSD (Daemon/servis) odnosno tvrdi disk. Dakle, radi replikaciju objekata koji završe zapisani na OSD (Tvrdi disk) prema drugom OSD (tvrdi disk) – ovisno o “Cluster Map”-i i drugim parametrima (tj. o Pool-u ili ekvivalentu RAID polja koje se rsprostire na poslužitelje i diskove u CEPH klasteru).
  • Za korištenje journaling mehanizama kod zapisivanja podataka na OSD (disk) prema transakcijskom modelu. Svaka operacija zapisivanja  na CEPH sustav se radi transakcijjski s privremenim zapisivanjem transakcije na “Journaling” particiju. Kod visoko optimiziranih sustava, koriste se “Serverske” verzije SSD diskova za “Journaling”.

 

Pogledajmo kako logički izgleda cijeli CEPH, sada kada smo se upoznali sa svim važnijim elementima.

 

 

U gornjem dijelu slike je vidljiv izgled jednog OSD poslužitelja s pet tvrdih diskova. Svaki tvrdi disk mora imati minimalno jednu particiju, koju možemo formatirati s nekim od predloženih datotečnih sustava (xfs – preporuka, ext4 ili btfrs). Dodatno, potrebna nam je još jedna particija (ili zaseban disk ili polje diskova s dodatnom particijom za “Journaling”). U konačnici, na postojeću particiju koja je namjenjena za CEPH, na datotečni sustav kreira se struktura direktorija u koju se spremaju CEPH objekti kao i njihovi pripadajući metapodaci.

U donjem dijelu slike je vidljiva pozicija svakog pojedinog OSD poslužitelja (s svim njegovi “OSD” diskovima) te pozicije svih MONitor poslužitelja. Dakle vidljiv je CEPH sustav sa ukupno 30 poslužitelja i to:

  • tri CEPH MONitor poslužitelja i
  • 27 CEPH OSD poslužitelja.

 

Sada zamislimo upotrebu u kojoj imamo poslužitelje za virtualizaciju, koji koriste ovakav CEPH sustav (sa svih 30 poslužitelja) kao disk storage sustav, dakle za spremanje virtualnih diskova virtualki. Pogledajmo sliku kako to izgleda sa strane virtualnog računala odnosno platforme za virtualizaciju prema CEPH sustavu (od gore do dolje):

 

 

Ovdje je vidljiv način pristupa CEPH “Block device”-u tj. logičkom “blok” uređaju odnosno disku koji predstavlja cijeli CEPH cluster. Na primjeru su dvije česte platforme za virtualizaciju: OpenStack i Proxmox VE. Platforma za virtualizaciju za svako virtualno računalo koje koristi virtualni tvrdi disk (koji je zapravo “blok uređaj” tj. logički tvrdi disk od cijelog CEPH klastera), koristi QEMU (i Linux KVM).

QEMU i Linux KVM su zaduženi za sve potrebne funkcionalnosti da bi se virtualizacija uopće mogla koristiti. Dakle oni simuliraju sve virtualne komponente svakog pojedinog virtualnog računala (matična ploča i njen BIOS, CPU, mrežna kartica i njen BIOS, disk kontroler i njem BIOS, pripadajući virtualni tvrdi disk, …).

Qemu kao Hipervizor ima nadalje metodu za korištenje svakog pojedinog virtualnog diska koji se zapravo nalazi unutar CEPH klastera (kao “Block device”). QEMU se tada spaja kao klijent na CEPH klaster i to na točno određeni CEPH Pool te njega koristi kao da je “polje diskova” na nekom SAN sustavu (jer govorimo o upotrebi CEPH-a kao “Block device-a” tj. kao RBD).

A sada pogledajmo kako to izgleda sa strane “CEPH Block Device”-a odnosno blok uređaja, kao krajnje komponente, koja na kraju stvarno pristupa CEPH klasteru za čitanje ili zapisivanje podataka. Ovdje zapravo QEMU kao CEPH klijent pristupa CEPH polju:

 

 

Klijent 1 piše ili čita na ili sa CEPH RBD

  1. Kod procesa čitanja ili pisanja na “Block device” tj. CEPH RBD ,klijent koji žali nešto zapisati ili pročitati iz CEPH clustera koji koristi kao blok uređaj (logički kao tvrdi disk), prvo kontaktira CEPH klaster i to MONitor poslužitelje i od njih traži “CLuster Map” tablicu/konfiguraciju.
  2. CEPH cluster MONitor poslužitelj(i) mu šalju traženu tablicu/konfiguraciju.
  3. Na osnovi tablice/konfiguracije koju je dobio, klijent pomoću CRUSH algoritma traži od OSD poslužitelja i OSD diskova podatke za čitanje ili traži pisanje. Do točnih OSD poslužitelja i točno određenih OSD diskova je pomoću CRUSH algoritma izračunao koji su te od njih i traži/šalje podatke.
  4. S OSD-ova dobiva odgovor na traženi zahtjev (čitanje ili pisanje).

Klijent 2 piše ili čita na ili sa CEPH RBD – ponavlja se proces kao i za prvog klijenta.

 

 

 

Autor: Hrvoje Horvat

Članak preuzet, uređen i objavljen uz izričito dopuštenje autora.

Izvor: Open Source Osijek

VN:F [1.9.22_1171]
Rating: 4.5/5 (2 votes cast)
Osnove NAS i SAN sustava (i malo više) – treći dio, 4.5 out of 5 based on 2 ratings

Povezani članci:

Osijek – predavanje: Uvod...
Open Source Osijek - Uvod...
Predavanje - Virtualizaci...
Osnove NAS i SAN sustava ...
Osnove NAS i SAN sustava ...

One Response

  1. Alex kaže:

    Veliki naklon autorima ovog izuzetnog clanka. Pozdrav iz Kragujevca!

Ostavi komentar

© 2016 Linux Za Sve. | Impressum | Sadržaj je licenciran pod CC-SA-3.0 ako nije drugačije naznačeno.
Proudly designed by Theme Junkie.