NAS (Engl. Network Attached Storage) odnosno “mrežno spojena spremišta podataka” osiguravaju nam prostor za spremanje podataka, preko mreže. Ovo su zapravo mrežni dijeljeni sustavi za spremanje podataka, koji rade na razini datoteka (i naravno direktorija) koje pohranjujemo na njih i to preko mrežnih protokola za dijeljenje datoteka.

1. Kod odabira NAS ili SAN sustava odnosno poslužitelja, prvo moramo biti svjesni zahtjeva za softverom (operacijskima sustavom). Operacijski sustav za NAS ili SAN može biti :

• Specijalizirani open source OS poput :

    <ul>
      <li class="level2">
        <div class="li">
          OpenFiler
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          OpenMediaVault
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          FreeNAS
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          Nas4Free
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          NexentaStor (Nexenta Community Edition)
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1 node">
    <div class="li">
      ili neko od komercijalnih rješenja za NAS/SAN :
    </div>
  
    <ul>
      <li class="level2">
        <div class="li">
          NexentaStor (Nexenta Enterprise Edition)
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          TrueNAS
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          Open-E
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          …
        </div>
      </li>
    </ul>
  </li>
  

• ili OS za opću upotrebu, koji ćemo dodatno konfigurirati prema našim potrebama:

    <ul>
      <li class="level2">
        <div class="li">
          Neki Linux koji želimo prilagoditi našim potrebama ili
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          Windows server koji već imamo te ga želimo optimizirati ili prenamjeniti za NAS/SAN sustav
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          ili nešto drugo
        </div>
      </li>
    </ul>
  </li>
  

SAN (Storage Area Network) sustavi s druge strane ne nude mrežno dijeljenje datoteka, već nam osiguravaju mrežni pristup Tzv. “Block-based” mediju. Ovo u praksi znači da SAN sustavi preko mreže praktično dijele svoje diskove ili polja diskova vidljiva klijentskoj (drugoj) strani kao “običan tvrdi disk”. Nadalje takav disk se sastoji od blokova podataka kao i bilo koji lokalni ATA,SATA,SAS ili neki drugi disk. Za više detalja o diskovima pogledajte knjigu “Uvod u Linux”, poglavlje o diskovima.

Za ovakvo mrežno dijeljenje praktično “sirove” površine diska, potrebi su mrežni protokoli koji nam osiguravaju ovakav pristup.

Neki od SAN protokola su :

• Fibre Channel
• iSCSI
• ATA over Ethernet (AoE)
• HyperSCSI.

Nakon što se klijent preko nekog od gore navedenih SAN protokola spoji (na površinu diska), takav disk se mora prvo particionirati i formatirati kao da se radi o lokalnom disku odnosno disku spojenom na vaše lokalno računalo.

Zašto bi uopće koristili ovakve sustave ?

• Zbog potrebe za izradom sigurnosnih kopija vaših podataka (Engl. Backup), na centralni mrežni uređaj (obično NAS):

    <ul>
      <li class="level3">
        <div class="li">
          koji bi morao (i obično je) biti znatno sigurniji jer u pravilo snima podatke na više diskova istovremeno (obično koristi neko RAID polje)
        </div>
      </li>
  
      <li class="level3">
        <div class="li">
          i ima sve ostale komponente kvalitetnije i pouzdanije od “običnog” računala
        </div>
      </li>
    </ul>
  </li>
  

• Zbog centraliziranog pohranjivanja i upotrebe. Dakle želimo centralizirano mjesto za pohranu :

    <ul>
      <li class="level3">
        <div class="li">
          Svih podataka (datoteka) s kojima radimo
        </div>
      </li>
  
      <li class="level3">
        <div class="li">
          Virtualnih računala, a što je preduvjet za bilo koji rad u klasteru u slučaju potrebe za redundancijom (otpornosti na kvar pojedinog poslužitelja ili njegovog održavanja odnosno nadogradnje ).
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1">
    <div class="li">
      Zbog pohranjivanja sigurnosnih kopija virtualnih računala i drugih podataka (pr. dokumenti, slike, …) i to na dnevnoj, tjednoj, mjesečnoj, polugodišnjoj ili godišnjoj bazi.
    </div>
  </li>
  

Što kada se pokvari ovakav NAS ili SAN sustav odnosno poslužitelj ?

Obično ako niste imali još jedan sustav na koji ste izrađivali sigurnosne kopije – ostajete bez svih podataka.

Koliko vam je to važno – da izgubite sve podatke važne za poslovanje vaše tvrtke ?.

Što nam omogućavaju ovakvi sustavi ?

Osim sigurnosti, jer se sada svi podaci mogu zapisivati na dva ili više uređaja istovremeno, dolazimo i do njihovih ograničavajućih faktora, a to su :

• Omogućavaju horizontalno skaliranje (nadogradnju) ali uz više troškove – znatno više od cijene samog drugog uređaja
• Ograničeni su na proširenje prostora tj. kapaciteta (proširenje dodavanjem diskova ili dodatnih uređaja), Pri tome proširenje dodavanjem dodatnih uređaja (ako je to uopće moguće jer za svaki model odnosno seriju redundantnih NAS uređaja postoji ograničenje do koliko se mogu proširivati) – cijene ovdje odlaze u nebo.
• U konačnici daju nam redundanciju (zalihost/sigurnost od gubitka podataka) uz ekstra cijenu.
• Uz što veću cijenu, dobivamo i veću brzinu rada
• To su sve uglavnom rješenja koja su zaštićena i zatvorenog dizajna od strane proizvođača poput (EMC², IBM, …)

Redundantni NAS Sustavi

Redundantni sustavi su nešto jednostavnijeg dizajna jer se ispred njih logički nalazi sustav koji osigurava pristup jednoj jedinoj virtualnoj IP adresi kojoj klijenti i pristupaju (postoje i drugačije implementacije ali ova je najčešća).

U pozadini se redundantni NAS sustav brine da se svi podaci uredno kopiraju s prvog (NAS-1) na drugi (NAS-2) NAS sustav. U slučaju kvara prvog (NAS-1) sustava, drugi (NAS-2) preuzima njegovu funkciju i svi podaci su sačuvani. Ovakvi sustavi su često izvedeni sa samo dva NAS sustava i rade na principu : Active-Standby (jedan je aktivan a drugi je pričuva).

Kako logički izgledaju ovakvi sustavi ?

Redundantni NAS sustav, logički izgleda ovako:

Postoje i mnoga Open Source softverska rješenja koja nam omogućavaju osnovnu redundanciju ili klasterizirane NAS sustave.

Neki od njih su :

• GlusterFS : Omogućava osnovne i nekoliko naprednih razina redundancije :

    <ul>
      <li class="level3">
        <div class="li">
          mirror &#8211; poput RAID 1 između dva NAS sustava (poslužitelja) &#8211; min. 2 puslužitelja,
        </div>
      </li>
  
      <li class="level3">
        <div class="li">
          stripe &#8211; poput RAID 0 između dva NAS sustava (poslužitelja) &#8211; min. 2 puslužitelja,
        </div>
      </li>
  
      <li class="level3">
        <div class="li">
          mirror + stripe &#8211; poput RAID 10 između dva para NAS sustava (poslužitelja) &#8211; min. 4 puslužitelja (1 i 2 u RAID 1, 3 i 4 u RAID 1 , oba para poslužitelja (1,2 + 3,4), vršno u RAID 0, što zajedno čini RAID 10)
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1">
    <div class="li">
      <strong>pNFS</strong> (Parallel NFS &#8211; od verzije NFS v.4.1+) :Paralelni/Distribuirani NFS &#8211; stabilna (produkcijuska verzija ) je još u izradi
    </div>
  </li>
  
  <li class="level1">
    <div class="li">
      <strong>OCFS2</strong> (Oracle open source) : ima slične mogućnosti kao <strong>GlusterFS</strong>
    </div>
  </li>
  
  <li class="level1">
    <div class="li">
      …
    </div>
  </li>
  

Svaki od njih ima svoje prednosti i mane kao i ciljanu upotrebu (za koju je i razvijan ili se pokazao kao vrlo dobar)

I u ovoj kategoriji imamo nekoliko opensource rješenja koje možete proučiti,a koja su dosta česta u upotrebi – i to obično u kombinaciji s drugim elementima odnosno komponentama (ovisno da li se radi o SAN ili klasterskom SAN rješenju ).

• DRBD8 (Distribuirani – replicirani “Block Device”) – “Distributed Replicated Block Device” : – praktično RAID1 (mirror) preko mreže, prema principu : Primari poslužitelj → Sekundarni poslužitelj. Potrebna su dva poslužitelja ( nije za sve primjene !)

    <ul>
      <li class="level3">
        <div class="li">
          <strong>DRBD9</strong> (u aktivnom razvoju) : omogućava rad s više poslužitelja, višestruke replikacije i sl.
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1 node">
    <div class="li">
      <strong>iscsid (open-iscsi)</strong> (iSCSI initiator) servis/daemon za Linux (sam po sebi nije redundantan već pruža osnovnu iSCSI funkcionalnost )
    </div>
  
    <ul>
      <li class="level4">
        <div class="li">
          <strong>device-mapper-multipath</strong> &#8211; DM-Multipath (“Device Mapper Multipathing” ) servis/daemon koji omogućava redundanciju (ili load balancing) prema iSCSI uređajima (SAN storage-ima) (i dalje je pitanje kako sinkronizirati dva ili više SAN storage-a) &#8211; koristi se najčešće kod active/passive SAN sustava
        </div>
      </li>
  
      <li class="level4">
        <div class="li">
          <strong>ALUA</strong> (“Asymmetric Logical Unit Assignment”) nudi load balancing prema SAN storage-u (ostaje isto pitanje sinkronizacije SAN storage-a) &#8211; koristi se za active/active SAN sustave
        </div>
      </li>
    </ul>
  </li>
  

ZFS je razvila tvrtka SUN Microsystems, danas u vlasništvu tvrtke Oracle. Ideja je bila riješiti gore navedene probleme, uvesti mnoga poboljšanja i mogućnosti koje su do tada bile dostupne samo kao specijalizirana rješenja ili uopće nisu postojala, te sve integrirati u jednom “proizvodu”.

ZFS je prema svojoj funkcionalnosti praktično kombinacija:

• Naprednog RAID kotrolera odnosno “Logical Volume Managera” i
• Datotečnog sustava s naprednim sustavom kontrole ( ACL) odnosno “Access Listama” za prava pristupa

Izvorno je bio razvijan unutar tvrtke SUN Microsystems kao zatvoreni kod, unutar njihovog UNIX operacijskog sustava Solaris 2005. godine. Već slijedeće godine je prebačen u open source pod CDDL licencom unutar projekta “OpenSolaris” te je postao sastavni dio Solaris UNIX-a v.10, sredinom 2006. godine.

Naravno, nakon što ih je kupio Oracle, već nakon par mjeseci cijeli izvorni kod ZFS-a se više nije održavao od strane Oracle-a. Dakle Oracle je prestao s razvojem “OpenSolaris”-a pa je zajednica morala sav kod prebaciti u novi projekt imena “Illumos” ( tu se nalazio i kod ZFS-a ). Zajednica koja je stajala iza projekta “Illumos” preuzela je zadnju verziju dostupnog koda te ga nastavila razvijati. Nakon nekog vremena je pokrenut i projekt “OpenZFS” koji je prihvatila još veća zajednica programera i korisnika ili i sve veći broj tvrtki. Svi zajedno su nastavili s razvojem open source verzije ZFS-a, koja se razvija i danas.

Nakon što smo instalirali ZFS, na njega dodajemo diskove i kreiramo ekvivalente RAID poljima, slično kao što ih dodajemo u neki hardverski RAID kontroler (što se konfiguracije tiće). Tako je moguće kreirati ekvivalente gotovo svim RAID poljima :

• RAID 0 ( ovdje se naziva stripe ) ,
• RAID 1 ( ovdje se naziva mirror ),
• RAID 5 ( ovdje se naziva RAID-Z ili RAID-Z1 ),
• RAID 6 ( ovdje se naziva RAID-Z2 ),
• Nešto poput RAID “6” ali s tri paritetna diska umjesto dva – naziva se RAID-Z3
• RAID 10
• …

S jedinom razlikom da to sve radi bez grešaka i problema koje možemo imati na bilo kojem RAID kontroleru a pogotovo ako nismo prethodno testirali sve scenarije u slučaju nekog kvara. Osim toga na današnjem hardveru to sve radi ekstremno brzo a sve je moguće i dodatno drastično ubrzati uvođenjem :

• L2ARC-a za ubrzavanje operacija ćitanja (read) i /ili
• ZIL log-a za ubrzavanje operacija pisanja (write)

S time da se za obije metode (L2ARC i ZIL log) mogu koristiti zasebni SSD diskovi a koji dodatno mogu biti i u nekom ekvivalentu RAID polja, da bi se dodatno dobilo na brzini i/ili pouzdanosti.
Pošto je jasno da je ZFS povezan s NFS-om a i vrlo jednostavno sa SMB/CIFS ili nekim drugim sustavom za dijeljenje datoteka (NAS sustavom) vidljiva je njegova upotreba kao naprednog NAS sustava.

Jedna od naprednih stvari oko ZFS-a je i u tome što se na bilo kojem ZFS polju diskova (ekvivalent RAID polju) može kreirati poseban “Block device” koji se može koristiti kao iSCSI logički uređaj (disk). Taj logički disk je samo potrebno proslijediti nekom od iSCSI “serverskih” servisa/daemona. Ovime dobivamo upotrebu ZFS-a kao SAN sustava.

Potencijalna mana upotrebe ZFS-a leži u tome što nije trivijalan kao što je više manje korištenje RAID kontrolera i kreiranje nekog RAID polja. U svakom slučaju potrebna su vam neka naprednija predznanja. ZFS-ove mnogobrojne opcije i funkcionalnosti početnicima mogu izgledati komplicirane ali su profesionalcima definitivno vrlo važne.

Na kraju krajeva niti ne želite da vam NAS ili SAN sustav “složi” netko onako usput, za sat-dva, uz svoj svakodnevni posao koji obično nema veze s ovom temom, jer bi mogli zažaliti kada nešto krene po zlu. Namjerno nisam napisao “ako” već “kada” jer je uvijek pitanje vremena kada će doći do problema i dali ćete ih biti u stanju riješiti te koliko vremena i novaca će vam biti potrebno za tu “igru”.

O ZFS-u su napisane knjige i knjige te više nećemo ulaziti dublje u ovaj najbolji “Volume Manager” i datotečni sustav svih vremena. O njemu detaljnije u nekom od slijedećih postova.

Ako tek krećete s učenjem, prvo si dajte nekoliko dana da bi dobro savladali:

• osnove Storage tehnologija te napredne mogućnosti
• osnove rada RAID kontrolera te njihove mogućnosti, način rada i dodatne opcije (uz njihovo razumjevanje)

I na kraju dodajte još koji dan za proučavanje foruma koji se bave ovom tematikom, kao i foruma od strane proizvođača s pitanjima i odgovorima vezanim za pojedine (konkretne) modele RAID kontrolera koji vam je ušao u użi izbor (ako ste odlučili da čete koristiti RAID kontroler a ne ZFS).

Kada završite prvu fazu učenja i nakon što ste kupili RAID kontroler, slijedi novo učenje :

• proučite napredne parametre i testirajte ih (istovremeno testirajte i performanse sustava ovisno o promjeni parametara)
• testirajte razne scenarije havarija za barem nekoliko RAID polja (pogledajte dolje za ZFS) i povrata podataka , mjerite i vrijeme koje potrebno da se sve vrati na “staro stanje” – i vrijeme potrebno za “recovery” je ponakad ključno za konačan odabir vrste RAID polja (RAID 1, RAID 5, RAID 6, RAID 10, …)
• sve dobro i detaljno dokumentirajte (ovo ćete najviše cijeniti kad vam se dogodi prva veća greška – višestruko će se isplatiti dani i dani testiranja i dokumentiranja)

Ako ste krenuli prema ZFS-u tada krenite s proučavanjem osnova:

• WIKI ZFS info

Proučite si i pripremite upute iz nekoliko izvora te odvojite još par tjedana za upoznavanje i isprobavanje te smišljajte razne scenarije havarija (i smislite/pronađite najbolje riješenje ) :

• Kreirajte jedno ZFS polje:

    <ul>
      <li class="level2 node">
        <div class="li">
          a. Mirror (Ekvivalent RAID 1)
        </div>
  
        <ul>
          <li class="level3">
            <div class="li">
              0. Kreirajte share (NFS ili SMB/CIFS), dodjelite ovlasti i dobro ih naučite (proučite kako se dodjeljuju, nasljeđuju, ne nasljeđuju i sl.), Zapišite određene podatke i pratite performanse kod zapisivanja i čitanja (s različitim parametrima).
            </div>
          </li>
  
          <li class="level3">
            <div class="li">
              1. Izvadite jedan disk iz ZFS polja, pa ga vratite
            </div>
          </li>
  
          <li class="level3">
            <div class="li">
              2. Ponovite 1. korak ali prije vračanja diska, obrišite ga
            </div>
          </li>
  
          <li class="level3">
            <div class="li">
              3. Zamijenite mjesta diskovima (prvi na mjesto drugog i sl.)
            </div>
          </li>
  
          <li class="level3">
            <div class="li">
              4. Izvadite sve diskove, reinstalirajte cijelo računalo pa vratite diskove i pokušajte importirati staro ZFS polje
            </div>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  
  <li class="level1 node">
    <div class="li">
      b. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-Z)
    </div>
  
    <ul>
      <li class="level3">
        <div class="li">
          Ponovite sve točke : 0 &#8211; 4
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1 node">
    <div class="li">
      c. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-Z2)
    </div>
  
    <ul>
      <li class="level3">
        <div class="li">
          Ponovite sve točke : 0 &#8211; 4
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1 node">
    <div class="li">
      d. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-10 : 2 x “mirror” u “stripe”)
    </div>
  
    <ul>
      <li class="level3">
        <div class="li">
          Ponovite sve točke : 0 &#8211; 4
        </div>
      </li>
    </ul>
  </li>
  

Napravite što više scenarija te:

• sve isprobajte (testirajte i performanse) i dokumentirajte

<li class="level1 node">
  <div class="li">
    isprobavajte rad s osnovnim postavkama, pa sve probajte optimizirati (za svaki scenarij) &#8211; testirate i stabilnost i izdržljivost ovisno o scenariju i opcijama koje ste mijenjali &#8211; uz:
  </div>

  <ul>
    <li class="level3">
      <div class="li">
        restart poslužitelja
      </div>
    </li>

    <li class="level3">
      <div class="li">
        restart servisa/daemona
      </div>
    </li>

    <li class="level3">
      <div class="li">
        namjerno stopirane servise/daemone (uz ručno pokretanje &#8211; naknadno)
      </div>
    </li>
  </ul>
</li>

U ovim koracima/scenarijima ćete naučiti najviše, te se pribliżiti produkcijskoj primjeni i znanju o ovim sustavima.

Problemi klasterskih NAS i SAN sustava

Kao što smo vidjeli u prethodnom poglavlju 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.

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).

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 Snapshot-a 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 (Engl. 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

Koristi se Tzv. CRUSH algoritam i pripadajuća “CRUSH” tablica (koja je distribuirana na više poslužitelja) a koja je zadužen za distribuciju, replikaciju i redistribuciju podataka unutar CEPH clustera.

CRUSH je dizajniran da omogućava raznoliku upotrebu, ovisno o veličini implementacije.

Prema tome 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 :

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 odnosno prema CEPH terminologiji “CEPH Pool Size” jednak tri (3) to znači da se podaci zapisuju na odredišni poslužitelj a potom na jod druga dva (2) poslužitelja. Tako da ćemo u ovom slučaju isti podatak imati sveukupno na tri (3) 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.

Logička shema je vidljiva na slici:

Opis :

• Podaci se spremaju kao objekti
• Objekti se nalaze unutar Pool-a

    <ul>
      <li class="level2">
        <div class="li">
          Standardna veličina objekta je 4MB
        </div>
      </li>
    </ul>
  </li>
  
  <li class="level1">
    <div class="li">
      Objekti se grupiraju u “Placement Grupe” (PG). Placement Grupe su distribuirane preko više OSD-ova (diskova)
    </div>
  </li>
  
  <li class="level1">
    <div class="li">
      OSD-ovi se koriste za stvarnu distribuciju (“read” i “write” operacija) objekata na tvrde diskove
    </div>
  </li>
  
  <li class="level1">
    <div class="li">
      “CRUSH” tablica/konfiguracija se koristi za kreiranje i kasniju upotrebu i distribuciju objekata (podataka) unutar svakog pojedinog “<strong>Pool</strong>-a” za cijeli CEPH klaster. (Moguće je imati i više <strong>Pool</strong>-ova s različitim konfiguracijama).
    </div>
  </li>
  

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.

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 (Engl. 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, bi bila:

• 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: Pr. :

• 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 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”:

    <ul>
      <li class="level2">
        <div class="li">
          <strong>Monitor map</strong> &#8211; tablica s MONitor poslužiteljima
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          <strong>OSD map</strong> &#8211; tablica s OSD poslužiteljima/diskovima
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          <strong>PG map</strong> &#8211; tablica s PG (Placement Group)- grupama za pohranu objekata
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          <strong>CRUSH map</strong> &#8211; “CRUSH” hijerarhijska tablica/konfiguracija
        </div>
      </li>
  
      <li class="level2">
        <div class="li">
          <strong>MDS map</strong> (za <strong>MDS</strong> ulogu [koristi se samo za <strong>S3</strong> ili <strong>Swift</strong> tj. za upotrebu kao “Object Storage”])
        </div>
      </li>
    </ul>
  </li>
  

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
• zadužena je 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).
• korištenje journaling mehanizama kod zapisivanja podataka na OSD (disk) prema transakcijskom modelu. Dakle svaka operacija zapisivanja (Engl. Write) 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.