Text Size

Linux za sve

Syndicate content
Regionalna web publikacija posvećena Linuxu i otvorenim sustavima.
Updated: 2 hours 5 min ago

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

18. September 2016 - 15:08
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:

 

 

 

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

Oslobodite se: FOSS na Androidu

16. September 2016 - 19:20
Zaranjamo u dubine Androidove male, ali snažne FOSS zajednice i nalazimo… blago?

 

Još prije nekoliko godina Android je bio zlatno dijete Linux zajednice. Sva ta prilagodljivost Linuxa, otvorenost platforme, pregršt mogućnosti i sve njegove slobode došli su i na mobitele! Bili su to prekrasni dani, ispunjeni entuzijazmom oko novog launchera ili custom ROM-a na kojemu nam baterija izdrži par sati više. Divna suprotnost konkurentskim, zatvorenim sustavima poput Windows Mobilea i iOS-a. Branili smo svoj Android kad su ga Apple i Microsoft napadali patentnim tužbama.

I onda, korak po korak, Google je (zanemarujući svoju krilaticu “Don’t be evil”) krenuo zatvarati Android dio po dio u suradnji s proizvođačima uređaja, stavljajući ga pod isključivo svoju kontrolu i čineći ga gotovo neupotrebljivim bez Googleovih servisa na koje se većina aplikacija na toj platformi oslanja. Većina aplikacija postajala je zatvorenog koda i vlasnička, pa tako i bivše jezgrene aplikacije poput telefona*, lomeći snove svih korisnika slobodnog softvera – korak po korak.

Tračak nade krenuo je pružati projekt F-Droid u obliku repozitorija slobodnih aplikacija za Android, stvarajući kontrast Google Play Storeu (nekadašnjem Android Marketu) koji je svakim danom imao sve više neslobodnih aplikacija.

Danas, Play Storeom dominiraju vlasničke aplikacije – niti jedna od Top 100 aplikacija nije slobodna. No negdje u njegovim dubinama, nalazi se još uvijek aktivna i jaka zajednica koja razvija slobodan softver za Android. Neke od tih aplikacija možda i koristite, a kako to običava, dobar dio njih je bolji od svojih vlasničkih alternativa.

Tako sam, u misiji da otkrijem Androidove slobodne aplikacije, krenuo u istraživanje kako bih izdvojio neke od meni omiljenih slobodnih aplikacija za tu platformu i kako bih saznao što razvijatelje motivira da učine svoje aplikacije slobodnima, umjesto da se krenu vjerojatno plodonosnijom rutom vlasničkog softvera.

 

Red Moon

Ekranski filteri su jedna od onih aplikacija za koje stvarno ne znate da su vam potrebne ili čak korisne dok ih ne počnete koristiti. Uglavnom, ideja iza ekranskih filtera je ta da ljudsko tijelo koristi plavu svjetlost kao zeitgeber – odnosno, da se ona koristi za sinkronizaciju našeg biološkog sata s prirodom, kako bismo bili budni preko dana, a spavali preko noći. Problem je što (plava) svjetlost računala zbunjuje tijelo zbog čega ono smanji proizvodnju melatonina, pa ako pišete rad (ili članak :D) do tri ujutro na računalu, možda vam se neće spavati kad legnete u krevet. Taj problem ekranski filteri nastoje riješiti kontroliranjem temperature boje svjetlosti koja iz vašeg računala izlazi, spašavajući vaš ciklus sna. Iako možda neće spasiti vaš ciklus sna nakon Star Wars maratona, vaše oči će vam svakako biti zahvalne.

Trend ekranskih filtera započeo je f.lux na Windowsu (koji se kasnije širio i na druge operativne sustave), na Linux ga je prenio Redshift, a na Android Twilight. Ako ne želite dati prava kontroliranja vašeg ekrana zatvorenoj aplikaciji ili jednostavno želite podržati slobodan softver, Red Moon je odlična alternativa.

Stiže s dva ugrađena filtera, a možete definirati vlastite uz parametre poput temperature boje, razine intenziteta i zamračenja te opcije za automatsko smanjivanje osvjetljenja uz mogućnost ručnog i automatskog kontroliranja aktiviranja filtera, bilo korištenjem vremenskog intervala ili dnevnog svjetla kao regulatora.

 

Sučelje Red Moon aplikacije

 

 

Istina, naići ćete na stvari koje će vam možda smetati poput crvenkastih screenshota ili nemogućnosti instaliranja aplikacija dok je filter pokrenut (zbog Androidovog ograničenja iz sigurnosnih razloga – automatsko pauziranje filtera kad se aplikacije instaliraju će stići u nekoj od idućih verzija aplikacije). No, evo nekoliko crvenkastih screenshota kako bih demonstrirao što ova aplikacija radi:

 

 

 

Razgovarao sam s razvijateljem te aplikacije, Marienom Raatom, oko odluke da Red Moon bude slobodan softver:

“I decided to open source Red Moon, because I love the idea of free software. Because it gives the user full control over their device, and also because it fosters innovation, by making it easy to build things on top of other projects. For example, before I started working on Red Moon I had no idea how an screen filter app would work on Android, but because Chris Nguyen had open sourced his app Shades. Without that base to build on I might not have even made Red Moon.”

Odlučio sam otvoriti kod Red Moona jer obožavam ideju slobodnoga softvera, jer ona daje korisniku potpunu slobodu nad njihovim uređajem i jer također potiče inovaciju, olakšavajući izgradnju stvari na temeljima drugih projekata. Primjerice, prije nego što sam krenuo raditi na Red Moonu, nisam imao ideju kako bi ekranski filter radio na Androidu, ali jer je Chris Nguyen otvorio kod svoje aplikacije Shades, [mogao sam naučiti]. Bez te baze za daljnju izgradnju, možda ne bih čak nikada napravio Red Moon.

Ako vam se Red Moon čini kao nešto što bi vam moglo biti korisno, aplikacija je dostupna na F-Droidu i GitHubu besplatno ili na Google Play Storeu za $2.24, u pokušaju financiranja njena razvoja. Kod aplikacije dostupan je u GitHub repozitoriju raatmarien/red-moon pod GPLv3 licencom, a bazirana je na Shades aplikaciji Chrisa Nguyena obljavljenoj pod MIT licencom.

Marien je također odlučio podijeliti 10 promo kodova za besplatnu instalaciju Red Moona s Google Play Storea čitateljima LZS-a, koji se nalaze na slici ispod:

Promo kodovi za Red Moon aplikaciju. Hvala, Marien <3

 

Slide for Reddit

Reddit, omiljena web stranica svakog prokrastinatora koji nema dovoljno zanimljivih Facebook prijatelja. Ako ne koristite Reddit, ova aplikacija vam neće koristiti, no za sve koji trebaju svoj dnevni fiks, Slide je odličan način za postići ga.

Iako je sama Reddit jezgra slobodan softver, klijenti za nju su većinom zatvoreni, uključujući i one službene, uz rijetke iznimke, od kojih je Slide možda najkvalitetnija.

Krcat mogućnostima poput alata za moderiranje, multireddite, preuzimanje sadržaja za offline čitanje tako da možete čitati Reddit i u tunelu, podrškom za višestruke račune i svim drugim što biste očekivali od Reddit klijenta, pa i više.

Sučelje je dizajnirano u skladu s Googleovom Material Design specifikacijom, tako da će se uklapati s ostatkom aplikacija na vašem uređaju, a ujedno je izuzetno prilagodljivo pa neće biti one boje koja bi trebala biti samo maaaalo svjetlija. Slide od ostatka Reddit klijenata razlikuje mogućnost pristupa svim vašim subredditima kroz kartice koje možete mijenjati klizanjem prsta između njih, kao i podrška za subreddit wikije i, zapravo, većinu mogućnosti samog Reddita.

 

 

 

Carlos Crane (u/ccrama na Redditu) je u razgovoru rekao ovo o svojim iskustvima sa slobodnim softverom:

“I decided to make Slide as a way to learn Java and Android Programming and had an idea for a sliding Reddit client, which was different from the rest of the Reddit app competition. I decided to make Slide open source to further my commitment to making Slide totally free and ad-free, and I was quite interested in having Slide available for download on F-Droid. I was also entering my freshman year of university at the time, and knew having a large open-source project on a repository I created would be a big boost to my CV and would help in finding internships and potential jobs in the Software Engineering field after getting my degree!”

Odlučio sam napraviti Slide kako bih naučio Javu i programiranje za Android te sam imao ideju za kližući Reddit klijent, što je bila drugačija ideja od ostalih konkurentskih Reddit aplikacija. Odlučio sam učiniti Slide otvorenim kako bih produbio svoju odanost pružanju Slidea besplatno i bez reklama, a ujedno sam bio izrazito zainteresiran za Slideovu dostupnost za preuzimanje na F-Droidu. Također sam upisivao prvu/brucošku godinu sveučilišta tada i znao sam da bi rad na velikom open source projektu dostupnom na repozitoriju bio velik poticaj mom CV-u i da bi pomogao u traženju staža i potencijalnih poslova u polju softverskog inžinjeringa nakon diplome.

 

“At first I did not expect much to come from putting Slide’s source on Github, but soon after release there were many members of my community willing to contribute their time to adding awesome new features and fixing the many bugs that riddled the first versions of Slide. I feel like open sourcing Slide definitely put it on the map in the FOSS and GAPPS-less community, and I have made some great relationships with Slide Github and IRC regulars. Overall, I am extremely pleased with my decision to make Slide open source and as free as possible, and I am a big proponent of open source software, especially with mobile applications.”

U početku nisam očekivao mnogo od stavljanja Slideovog izvornog koda na GitHub, ali nedugo nakon objavljivanja mnogi članovi moje zajednice bili su voljni posvetiti svoje vrijeme dodavanju zakon novih mogućnosti i popravljanju mnogih bugova koji su mučili prve verzije Slidea. Osjećao sam se kako je otvaranje Slidea definitivno ga stavilo na kartu u FOSS i GAPPS-less zajednici** i uspostavio sam odlične odnose sa čestim posjetiteljima Slideovog GitHuba i IRC-a. Sve u svemu, ekstremno sam zadovoljan sa svojom odlukom da učinim Slide otvorenim i besplatnim/slobodnim koliko je moguće te sam veliki podržavatelj open source softvera, pogotovo mobilnih aplikacija.

 

 

 

Kao i prethodno spomenuti Red Moon, Slide je dostupan na GitHubu pod GPLv3 licencom u repozitoriju ccrama/Slide te kao besplatna aplikacija na F-Droidu i Google Playu, uz mogućnost nadogradnje na plaćenu (no svejedno slobodnu) verziju koja omogućava korištenje nekih naprednijih mogućnosti aplikacije. Baziran je na JRAW-u, Java wrapperu za Reddit, pa ako tražite slobodni Reddit klijent koji će učiniti vašu prokrastinaciju ugodnijom, Slide je možda baš ta aplikacija za vas.

 

 

Wikipedia

Wikipedia mi je jedan od najdražih projekata na Internetu, a na Androidu je dostupna kroz otvoreni, službeni klijent kojeg razvija Wikimedia Foundation. Bilo da se često informirate na Wikipediji ili tek tu-i-tamo pročitate neki članak, ova aplikacija pruža izuzetno ugodno iskustvo čitanja (pa i uređivanja) slobodne enciklopedije.

 

Naslovna stranica Wikipedije u aplikaciji

 

 

Wikipedijina aplikacija prekrasno je dizajnirana te slijedi Material Design smjernice i svakako preporučam da je isprobate. Nažalost, nisam stupio u kontakt s razvijateljima ove aplikacije, no kao i gotovo svaki Wikimedijin projekt, dostupna je besplatno pod slobodnom licencom (u ovom slučaju Apache v2.0) na Google Playu i F-Droidu, a njen kod možete pronaći na Wikimedijinom Gerritu ili na GitHubu u repozitoriju wikimedia/apps-android-wikipedia.

 

 

Tisuće drugih slobodnih aplikacija

Nažalost, ne možemo pokriti svaku FOSS aplikaciju na Androidu, ali na sreću – to je zato što ih ima na tisuće. Većinu njih možete naći na F-Droidu, ranije spomenutom repozitoriju slobodnih/open source aplikacija za Android i možete za sebe vidjeti snažnost Androidove male FOSS zajednice. Naići ćete na sve, od izuzetno jakih malih projekata poput Conversationsa, odličnog open source XMPP klijenta za Android (kojeg čak možete i koristiti kao alternativni način pristupanja porukama na platformama poput Facebook Messengera), do već kultnih projekata poput Firefoxa u njihovim izdanjima za Android. Iako se na površini možda ne čini tako, Androidova FOSS zajednica diše punim plućima i svakako, ako već niste, zaronite malo u njene dubine – možda nađete blago.

*Postoje verzije većine tih aplikacija u AOSP-u kao otvoren kod, ali su značajno manje funkcionalne od njihovih zatvorenih dvojnika

**GAPPS-less zajednica je zajednica korisnika Androida koji ne koriste Googleove servise poput Play Storea

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

11. September 2016 - 11:00
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. Prethodno smo govorili o osnovama NAS i SAN sustava, te upoznali važne savjete za njihovo postavljanje. U drugom dijelu bavimo se kompleksnijim klasterskim sustavima, kao i ZFS datotečnom sustavu. Na kraju donosimo i praktičan primjer za vježbu.

 

 

Sljedeći korak: Klasterski i/ili redundantni NAS sustavi

Š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 proširenju 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 lete u nebo.
  • U konačnici daju nam redundanciju (sigurnost od gubitka podataka) uz ekstra cijenu.
  • Uz 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 (EMC2, 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? Donosimo shemu:

 

 

 

Klasterizirani NAS Sustavi

NAS sustavi koji se nalaze u klasteru (grozd) su obično znatno kompleksnijeg dizajna koji uključuje i razne dodatne hardverske i softverske komponente. Svi klijenti u pravilu pristupaju vršnoj klasterskoj komponenti, koja je često izvedena samo u softveru, a brine se za raspodjelu podataka unutar klastera na pojedine NAS uređaje.

Sama replikacija tih (odnosno svih) podataka između pojedinih NAS sustava se često izvodi i u softveru i na specijaliziranom hardveru (na slici bi to odgovaralo donjem sloju). Zbog ovakvog, složenog dizajna i potrebe za posebnim hardverom i njihova cijena je poprilično veća od redundantnih NAS sustava. Klasterizirani NAS sustavi logički izgledaju ovako:

 

 

 

Softverska rješenja

Postoje i mnoga open source softverska rješenja koja nam omogućavaju osnovnu redundanciju ili klasterizirane NAS sustave. Neka od njih su:

  • GlusterFS: Omogućava osnovne i nekoliko naprednih razina redundancije:
    • mirror – poput RAID 1 između dva NAS sustava (poslužitelja) – min. 2 poslužitelja,
    • stripe – poput RAID 0 između dva NAS sustava (poslužitelja) – min. 2 poslužitelja,
    • mirror + stripe – poput RAID 10 između dva para NAS sustava (poslužitelja) – min. 4 posluž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),
  • pNFS (Parallel NFS – od verzije NFS 4.1+): paralelni/distribuirani NFS – stabilna (produkcijska verzija) je još u izradi,+
  • OCFS2 (Oracle Open Source): ima slične mogućnosti kao GlusterFS.

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

 

Dilema: redundantni ili klasterizirani SAN sustavi?

Slično kao i za redundantne ili klasterizirane NAS sustave – osim sigurnosti, jer se sada svi podaci mogu zapisivati na dva ili više uređaja istovremeno – ovdje imamo sljedeće mogućnosti i ograničenja:

  • Omogućavaju veće horizontalno skaliranje (nadogradnju), ali uz znatno više troškove – znatno više od cijene za NAS sustave.
  • Ograničeni su na ekspanziju prostora tj. kapaciteta (proširenje dodavanjem diskova ili dodatnih uređaja). Pri proširenju dodavanjem dodatnih uređaja (ako je to uopće moguće jer za svaki model odnosno seriju redundantnih NAS uređaja postoji ograničenje koliko ih je moguće proširivati) – cijene lete u nebo.
  • U konačnici daju nam redundanciju (sigurnost od gubitka podataka) uz ekstremno visoku cijenu i vrlo kompleksan dizajn.
  • Uz 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 (EMC2, IBM, …).

Klasterizirani SAN sustavi logički izgledaju slično poput klasteriziranih NAS sustava, ali su znatno kompleksniji (i samim time skuplji):

 

 

Softverska rješenja za SAN i klasterske SAN sustave

I u ovoj kategoriji imamo nekoliko open source rješenja koje možete proučiti, a vrlo su česta u upotrebi – obično u kombinaciji s drugim elementima tj. 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!),
    • DRBD9 (u aktivnom razvoju): omogućava rad s više poslužitelja, višestruke replikacije i sl.
  • iscsid (open-iscsi iSCSI initiator) servis/daemon za Linux (sam po sebi nije redundantan već pruža osnovnu iSCSI funkcionalnost),
    • device-mapper-multipath – DM-Multipath (“Device Mapper Multipathing”) servis/daemon koji omogućava redundanciju (ili load balancing) prema iSCSI uređajima (SAN storage-ima; ostaje pitanje kako sinkronizirati dva ili više SAN storage-a) – koristi se najčešće kod active/passive SAN sustava,
    • ALUA (“Asymmetric Logical Unit Assignment”) nudi load balancing prema SAN storage-u (ostaje isto pitanje sinkronizacije SAN storage-a) – koristi se za active/active SAN sustave.

 

 

ZFS – negdje između

Za početak ukratko o ZFS-u i tvrtki Sun Microsystems. ZFS je razvila tvrtka SUN Microsystems, danas u vlasništvu tvrtke Oracle. Ideja je bila riješiti dosad 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 zapravo kombinacija:

  1. Naprednog RAID kotrolera odnosno “Logical Volume Managera” i
  2. 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ć sljedeć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 nakon samo nekoliko mjeseci čitav izvorni kod ZFS-a se više nije održavao od strane Oraclea. Dakle, Oracle je prestao s razvojem OpenSolarisa pa je zajednica morala sav kod prebaciti u novi projekt imena Illumos (tu se nalazio i izvorni 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, kao i sve veći broj tvrtki. Svi zajedno su nastavili s razvojem open source verzije ZFS-a koja se razvija i danas.

Kao i većina programa ili sustava koji su izašli iz tvrtke SUN Microsystems, ZFS je razvijan od strane inženjera za inženjere, na najbolji mogući način, kao nedostižni uzor svim ostalim tvrtkama (ili barem za 99.9999% njih).

 

Borba s open source licencama

Budući da je ZFS razvijan pod CDDL licencom (koja nije kompatibilna s Linux GPL licencom pod kojom se razvija Linux kernel) već od početka javnog razvoja (krajem 2005. i početkom 2006. godine) postalo je jasno da se ZFS ne smije direktno implementirati u Linux kernel. Za Linux je stoga osmišljeno privremeno rješenje: upotreba preko FUSE frameworka unutar kojega su se smjeli pokretati programi s drugim licencama. Problem je bio u tome što se FUSE izvršava na višoj razini iznad kernela te je samim time znatno sporiji. Ipak, ovo je kakav-takav početak.

Istovremeno s ovom borbom krenulo se u ponovni razvoj ZFS-a od nule te je 2013. razvijena prva stabilna verzija (v.0.6.1). Iste je godine pokrenut i projekt OpenZFS. Godine 2016. ZFS je uključen u Linux Ubuntu 16.0.4.

Ostali open source UNIX operacijski sustavi (poput onih koji su razvijani s BSD licencom – FreeBSD, NetBSD, OpenBSD i dr.) nisu imali problema s korištenjem ZFS-a, koji je na njima vrlo brzo zaživio. Nakon godina korištenja, testiranja i popravljanja smatra se jednom od najboljih implementacija u open source operacijskim sustavima. OpenZFS projekt također nudi implementaciju ZFS-a za Mac OS X.

ZFS je nastao u želji da se riješe problemi koje niti najnapredniji RAID kontroleri nisu mogli riješiti. Osim rješenja problema, plan je dodati i neke napredne mogućnosti koje su većini korisnika bile poželjne i dobrodošle. Neki od problema koji su poznati, a ZFS ih rješava:

  • Problemi s RAID5 i RAID6 poljima (pogledajte WIKI),
  • Problem kada želimo zamijeniti neispravni tvrdi disk novim diskom (koji na većini RAID kontrolera mora biti identičan onome koji se mijenja (npr. po broju glava/cilindara/sektora),
  • Problemi odnosno komplikacije kod proširenja RAID polja ovisno o RAID polju,
  • Problem u slučaju da nam se RAID kontroler pokvario te ga moramo zamijeniti s novim (ovo je ponekad nemoguće jer možemo izgubiti sve podatke),
  • Problem kada nam se, primjerice pokvari matična ploča te moramo prebaciti sve diskove i RAID kontroler na novi hardver (ovo ponekad može poći po zlu),
  • Problem koji nastaje s vremenom – podaci na površini tvrdih diskova postaju nekonzistentni a RAID kontroleri nisu toga svjesni sve dok ne naiđu na problematični dio površine diska. Ovaj problem se naziva “Data decay” ili “Data rot”. On je znan i kao degradacija podataka na površini diska, a tek najnapredniji RAID kontroleri imaju mogućnost korekcije (disk-scrubbing) ovakvih grešaka, ali samo do određene granice. Sličan problem nastaje i uslijed grešaka u firmware-u diska ili RAID kontrolera, “fantomskog” zapisivanja (podatak nije stvarno zapisan na površinu diska), grešaka pri zapisivanju ili čitanju, zbog pristupa prema/od krivih bokova sa površine diska i dr.

 

Dodatne funkcionalnosti ZFS-a :

  • Komprimiranje podataka “u letu”, prema konfigurabilnom tipu (algoritmu) i razini kompresije. S obzirom na dostupne algoritme za ovu namjenu i brzine, ali i mogućnosti modernih CPU-a, komprimiranje i dekomprimiranje podataka “u letu” je gotovo neprimjetno. ZFS trenutno podržava sljedeće algoritme za komprimiranje: LZJB, LZ4, ZLE i GZIP.
  • ZFS je i tzv. “Copy On Write” i “transakcijski” datotečni sustav što znači da se operacije snimanja rade transakcijski (poput transakcija u SQL bazama podataka). To znači da se svaka operacija zapisivanja završava tek kada je potvrđeno uredno zapisivanje (kada je transakcija uredno završila). Performanse su i dalje zadržane naprednim modelom transakcija te uvođenjem posebnog ZIL log-a za operacije snimanja. Ovaj “Copy On Write” model uvodi i:
    • mogućnost izrade tzv. “snapshota” odnosno snimke stanja diska/podataka u vremenu te mogućnost povratka na bilo koji trenutak kada je izrađen bilo koji od “snapshot”,
    • mogućnost izrade “klonova” odnosno verzije “snapshota” na kojoj se može i zapisivati,
  • mogućnost naprednih ACL-a (sigurnosnih postavki/prava na datotečni sustav, ali i na NFS share direktno),
  • … te cijeli niz drugih funkcionalnosti

 

 

ZFS u radu

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). Na taj način moguće je 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,
  • … i još mnogo toga.

Jedina iznimka je što sve navedeno radi bez grešaka i problema koje možemo imati na bilo kojem RAID kontroleru, a posebno ako nismo prethodno testirali sve scenarije u slučaju nekog kvara. Uz to, 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)

Za obije navedene metode (L2ARC i ZIL log) mogu se koristiti zasebni SSD diskovi koji dodatno mogu biti i u nekom ekvivalentu RAID polja kako bi se dodatno dobilo na brzini i/ili pouzdanosti.

 

Iz opisanih primjera postaje jasan odabir ZFS-a (povezan s NFS-om, SMB/CIFS ili nekim drugim NAS sustavom za dijeljenje datoteka) 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 poput korištenja RAID kontrolera ili 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, sigurno 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.

 

 

Proces učenja

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

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

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 na 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). U nastavku donosimo primjer za vježbu.

Kreirajte jedno ZFS polje:
a.Mirror (Ekvivalent RAID 1).
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).
1. Izvadite jedan disk iz ZFS polja, pa ga vratite.
     2. Ponovite 1. korak, ali prije vraćanja diska ga obrišite.
3. Zamijenite mjesta diskovima (prvi na mjesto drugog i sl.).
4. Izvadite sve diskove, reinstalirajte cijelo računalo pa vratite diskove i pokušajte importirati staro ZFS polje
b. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-Z). Ponovite sve točke: 0-4.
c. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-Z2). Ponovite sve točke: 0-4.
d. Obrišite postojeće ZFS polje i kreirajte novo (Pr. RAID-10 : 2 x “mirror” u “stripe”). Ponovite sve točke: 0-4.

Napravite što više scenarija te:

  • sve isprobajte (testirajte i performanse) i dokumentirajte,
  • isprobavajte rad s osnovnim postavkama, pa sve probajte optimizirati (za svaki scenarij) – testirate i stabilnost i izdržljivost ovisno o scenariju i opcijama koje ste mijenjali – uz:
    • restart poslužitelja,
    • restart servisa/daemona,
    • namjerno stopirane servise/daemone (uz ručno pokretanje – naknadno).

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

 

 

Autor: Hrvoje Horvat

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

Izvor: Open Source Osijek

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

10. September 2016 - 18:02
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. Prvi članak donosi osnove NAS i SAN sustava, kao i savjete za njihovo postavljanje.

 

 

Što su NAS sustavi?

NAS (eng. 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 putem mrežnih protokola za dijeljenje datoteka.

 

Svako dijeljenje datoteka preko mreže (eng. Network Share), korištenjem nekog od mrežnih protokola koji postoje za tu namjenu možemo nazvati upotrebom NAS sustava.

 

Dijeljeni pristup datotekama preko mreže omogućavaju nam sljedeći mrežni protokoli. Navesti ćemo one najčešće u upotrebi:

  • NFS (Network Files System) – koristi se uglavnom na Linux/Unix operacijskim sustavima (ili ponekad u Windows okruženju). Open source varijanta podrazumjeva korištenje nekog od nfs daemona (servisa).
  • SMB/CIFS (Server Message Block / Common Internet File System) – koristi se uglavnom na Windows ili Linux okruženjima. Koristi se osim za dijeljenje datoteka i za dijeljenje pisača i drugih uređaja, te dodatnih funkcionalnosti, preko mreže.
    • Open source riješenje se zove samba.
    • Windows Share je integriran u sve Windows operacijske sustave s ograničenjem od maksimalno 10 paralelnih (otvorenih) konekcija na Windows dijeljeni direktorij ako se radi o verziji Windowsa koja NIJE: Windows Server: 2003/2003 R2/2008/2008 R2/2012/2012 (R2).
  • AFP (Apple Filing Protocol) – koristi se za dijeljenje datoteka na Mac OS računalima.
  • Istoj kategoriji pripadaju i FTP (File Transfer Protocol) i TFTP (Trivial File Transfer Protocol) protokoli, s time da su oni jednostavniji i nemaju naprednije mogućnosti kao gore navedeni.
  • Često se koristi i WebDAV (Web Distributed Authoring and Versioning) koji je svojom funkcionalnošću negdje između FTP i gore navedenih protokola.
  • Brojni ostali.

 

Najosnovniji primjer upotrebe sustava za koji bi mogli reći da je neka vrsta NAS sustava bi bio klasično dijeljenje nekog direktorija preko mreže iz Windows OS-a. Nešto poput dijeljenja (eng. Sharing) ovog direktorija (D:\BKP) na slici:

 

Windows Sharing

 

 

U slučaju upotrebe na Windows operacijskom sustavu sve se za jednostavno mrežno dijeljenje svodi na odabir željenog direktorija te njegovog dijeljenja preko SMB/CIFS sustava.

Ako govorimo o “samostalnom” NAS sustavu odnosno uređaju pod nekom od varijanti Unix ili Linux operacijskih sustava, ova procedura se u konačnici uglavnom svodi na nekoliko koraka:

  1. Kreiranje nekog RAID polja diskova koje ćemo dalje koristiti kao jedan “logički” disk,
  2. Particioniranje “logičkog” diska koji ćemo koristiti za dijeljenje datoteka,
  3. Formatiranje kreiranih particija (Linux ext3/4, Linux XFS, Windows NFS ili sl. – ovisno o operacijskom sustavu NAS uređaja i našim potrebama),
  4. Mountanje formatirane particije u neki direktorij,
  5. Odabir mountanog direktorija te konfiguracija i aktivacija nekog od mrežnih protokola za dijeljeni pristup preko mreže – pogledajte niže opisane (NFS, SMB/CIFS, AFP ili sl.).

 

 

Osnovne pretpostavke i planiranje za NAS ili SAN sustav

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

  1. Specijalizirani open source OS poput:
    • OpenFiler,
    • OpenMediaVault,
    • FreeNAS,
    • Nas4Free,
    • NexentaStor (Nexenta Community Edition),
  2. … ili neko od komercijalnih rješenja za NAS/SAN:
    • NexentaStor (Nexenta Enterprise Edition),
    • TrueNAS,
    • Open-e,
  3. … ili OS za opću upotrebu koji ćemo dodatno konfigurirati prema našim potrebama:
    • Neka Linux distribucija koju želimo prilagoditi našim potrebama,
    • Windows server koji već imamo te ga želimo optimizirati ili prenamijeniti za NAS/SAN sustav,
    • Nešto drugo.

Postoje i gotovi “samostojeći” uređaji koji dolaze zajedno s operacijskim sustavom. Proizvode ih: EMC2, IBM, Dell, NetApp i drugi (oni nisu tema ove priče ).

 

2. Korak: Nakon što smo odabrali operacijski sustav za NAS ili SAN poslužitelj, moramo biti svjesni i njegovih zahtjeva za hardverom:

  • Koji CPU će zadovoljiti naše potrebe,
  • Koliko RAM memorije (i koji tip),
  • Koje mrežne kartice: 1Gbps ili 10Gbps, koji modeli (chipovi) i koliko ih je potrebno (jedna, dvije, tri, …),
  • Koji mrežni preklopnik (switch) odabrati, s kojom verzijom firmware-a (OS-a) i s kojim funkcionalnostima. Za više detalja pogledajte članak “Switching i routing: jučer, danas, sutra”,
  • Koji RAID kontroler, s koliko RAM memorije, BBU i sl. odabrati,
  • Koje tvrde diskove odabrati.

 

Nakon planiranja resursa koji će nam trebati, potrebno je revidirati točku 2.

Budući da govorimo o NAS i SAN sustavima, u nastavnu ćemo se detaljnije fokusirati na dio o RAID kontrolerima i diskovima, jer bi bez njihovog dobrog odabira kasnije u radu često dolazilo do problema ili (što je najgore) gubitka podataka, a tek to bi mogli vrlo skupo platiti ($$$).

 

 

Zbog čega RAID kontroler i tolika pažnja pri odabiru diskova?

Krenimo od diskova. Diskovi se u grubo dijele prema namjeni. U svakom slučaju želimo diskove koji su pouzdani ali i koji su proizvedeni za tzv. serversku namjenu u kombinaciji s RAID kontrolerima. Budite svjesni činjenice da postoje i “serverski” diskovi koji nisu dizajnirani odnosno optimizirani za rad s RAID kontrolerima. Za više detalja pogledajte knjigu “Uvod u Linux i Linux napredno”, poglavlje: “Podjela prema namjeni diskova”.

RAID kontroleri su svakako priča za sebe, ali svakako želimo imati pošteni hardverski RAID kontroler provjerenoga proizvođača. Dodatno, važna je i verzija firmware-a za RAID kontroler u kombinaciji s driverom za operacijski sustav na kojemu ga koristite. U praksi su se čak i kombinacije određenih verzija firmware-a i drivera, kao i kombinacije firmware RAID kontrolera i firmware-a drugih komponenti poslužitelja (npr. matične ploče), pokazale katastrofalnim odabirom.

Zaključak: treba si dati malo truda i proučiti što kupujemo (kao i komentare korisnika) za što konfiguraciju sličnu vašoj: OS, driveri (RAID, LAN, MB, …), firmare, softver, …

Cjenovni opseg “poštenih” RAID kontrolera (ovisno o broju diskova koje možete spojiti na njega), kreće se od minimalno tisuću KN na više. Sve jeftinije od toga, kao i odabir tzv. “integriranih RAID” kontrolera na matičnim pločama (osim ako su u pitanju prave serverske matične ploče od 5.000+ KN), nemojte niti pomišljati koristiti. Za više detalja pogledajte poglavlje “hardverski RAID”.

 

Rješenje prvo: Integrirana RAID rješenja

U ovim “integriranim” kombinacijama dobivate upravljački program (driver) i pripadajući softver, koji:

  • je loše dokumentiran ili
  • se jako rijetko održava ili
  • je pun grešaka,
  • u slučaju katastrofe nema definirane korake (što i kako) ili su oni nejasni (a uglavnom i ne rade).

Kod rješenja ovog tipa zapravo ne postoji pravi hardverski RAID kontroler nego se većina ili gotovo sve funkcionalnosti RAID kontrolera odrađuju unutar upravljačkog programa (drivera) koji se pretvara da je RAID kontroler. On operacijskom sustavu prijavljuje RAID polje diskova o kojem se brine kao jedan fizički disk – slično kako bi to napravio i pravi RAID kontroler.

Na kraju sve je zapravo prepušteno navedenom softveru (driveru) i operacijskom sustavu, pa što bude. Nakon nekog vremena obično se dogodi situacija: “Nešto ne radi. A kako da vratimo svoje podatke…?”. E, pa lijepo sam vam rekao.

Na kraju priče s krivim odabirom tehnologije ili uređaja uvijek završite sa slanjem diskova u neku od tvrtki specijaliziranih za povrat podataka. Ova zabava će vas obično koštati znatno više nego da ste odmah kupili možda i najskuplje komponente koje postoje na (našem) tržištu.

Povrat odnosno spašavanje podataka se često naplaćuje po GB, pa cifre vrlo brzo mogu narasti na desetke tisuća KN.

 

Rješenje drugo: Logical Volume Manager

Zaboravimo na “integrirane RAID” kontrolere. Prihvatljivija opcija je upotreba tzv. “Logical Volume Managera” unutar operacijskog sustava (govorimo o Linuxu). U Linuxu se radi o Logical Volume Manageru verzije 2 (LVM2). Za više detalja o LVM2 pogledajte poglavlje LVM2. I ovdje se radi o softverskom RAID-u odnosno njegovoj funkcionalnosti. Ipak, ovo je puno sigurnije i stabilnije rješenje od onoga koje dobivamo s upotrebom “Integriranih RAID kontrolera” na matičnim pločama za stolna računala (tj. neserverskim matičnim pločama). Ovo je dokazano rješenje koje koristi velika zajednica ljudi, a koje se razvija s otvorenim kodom čime se svaka novootkrivena greška vrlo brzo popravlja. Uz to, dokumentacija je vrlo detaljna te postoje dobro definirane procedure u slučaju havarije (što i kako napraviti u pojedinom slučaju).

 

Zbog čega je ipak bolji hardverski RAID kontroler i pripadajuće RAID polje?

Upravo stoga što će vam na budućem NAS ili SAN sustavu biti pohranjeni važni podaci. Stoga ne želite da se sve snima na samo jedan tvrdi disk već na više njih i to u RAID polju koje vam osigurava najbolji odnos:

  • sigurnosti podataka (koliko kopija podataka želite – na dva, tri ili više tvrdih diskova istovremeno),
  • brzine rada,
  • brze zamjene neispravnog diska i povratka u normalan rad,
  • lakoće proširenja kapaciteta RAID polja.

Dodatno, želite RAID kontroler jer nije pametno prepustiti nekom traljavom programčiću (mislim na “Integrirana RAID rješenja”) da vam odrađuje ovako važne zadatke pohranjivanja vama osjetljivih i za život tvrtke važnih podataka. Istodobno, želite iskoristiti hardversku snagu pravog RAID kontrolera koji ne opterećuje sustav (CPU/RAM) pošto ima svoj specijalizirani CPU i pripadajuću RAM memoriju. Dakle, želite ozbiljan zadatak oko RAID-a prepustiti tvrtki koja RAID kontrolere proizvodi profesionalno, kao i njihov pripadajući firmware/softver. Neka najbolji proizvođač specijaliziranog hardvera i softvera zaradi na onome što radi najbolje.

 

Odabir RAID polja

Kao što je i odabir dobrog RAID kontrolera važan, važno je i pravilno odabrati RAID polje, ovisno o vašem budžetu i potrebama. Sada ponovno bacite pogled na RAID polja u već navedenoj knjizi, u poglavlju: “Koja su najčešća RAID polja u upotrebi i koje su im prednosti i mane“. Ovdje donosimo samo nekoliko često korištenih RAID polja):

 

 

Na kraju, zbog čega tolika priča o diskovima, RAID kontrolerima i RAID poljima?

Kada smo kreirali neko RAID polje (na RAID kontroleru, po mogućnosti) sljedeće na redu je upotreba tog RAID polja odabirom nekog mrežnog protokola za NAS (NFS, SNB/CIFS, AFP ili dr.) ili SAN, preko kojeg dijelite podatke preko mreže (vrlo jednostavno

Kako je slobodan softver izgubio bitku

4. September 2016 - 12:17

Trideset i jednu godinu nakon manifesta za slobodan softver, kojeg je Richard Stallman objavio pod naslovom “GNU Manifesto” i time postavio ideološki kamen temeljac pokretu za slobodan softver, može se reći da situacija nikad nije izgledala gore iz perspektive osnovnih ciljeva slobodnog softvera. Slobodan softver je osmišljen s nakanom da obrani slobodu korisnika računala, a 2016. godine korisnici su daleko veći robovi “svojih” mašina i mobitela nego ikad prije.

Iako slobodan softver i otvoreni standardi nikad nisu bili rasprostranjeniji kao danas, ono što se promijenilo jest prisutnost digitalne tehnologije i njezina integracija u svakodnevnom životu. Možda je Linux prisutan na milijardama uređaja diljem svijeta, ali to je svojevrsna Pirova pobjeda jer je Linux u većini slučajeva postao samo platforma za dostavljanje novih vlasničkih programa i usluga. U doba nastanka Stallmanovog manifesta bilo je važno da korisnik kontrolira ondašnju okolinu u kojoj radi te podatke koje koristi i zato je zahtijevao slobodu da posjeduje i mijenja tekstualni editor koji koristi, kompajler i u konačnici operacijski sustav. Danas se može reći da korisnik ima na raspolaganju slobodan editor, zapravo mnogo njih, slobodan internetski preglednik, zapravo više njih, i masu drugih slobodnih programa različite namjene te u konačnici i slobodan operacijski sustav, međutim okolina i način na koji danas ljudi koriste računala su se značajno promijenili: usluge u tzv. oblaku, društvene mreže, pametni telefoni sa svojim aplikacijama, opamećeni televizor i set-top boxovi novi je kontekst u kojem prosječan korisnik digitalnih tehnologija provodi većinu svog vremena. Ono što predstavlja poraz slobodnog softvera je to što sve te platforme i konteksti ne osiguravaju korisniku nikakve slobode, već nasuprot, kontroliraju njegovu svakodnevicu. Ne da više ne postoji mogućnost da se tuđi podaci i sadržaji isporučuju i prikazuju na način na koji korisnik želi (zbog sveprisutnog Digital Right Managmenta – DRM-a), nego u sve više slučajeva nije moguće zadržati nadzor ni nad vlastitim podacima koje korisnik stvara kroz razne internetske platforme. Flash na webu živi posljednje godine, ali zato EME, Encrypted Media Extensions, vlasnička platforma za distribuciju multimedijalnih sadržaja, dolazi kao njegov dostojni nadomjestak koji je prihvaćen i od strane Mozille. Izgleda da je i Mozilla podigla bijelu zastavu i ugradila tu tehnologiju u Firefox.

Najgora noćna mora slobodnog softvera je da računalo, pametni telefon i drugi uređaji postanu samo terminal za posluživanje sadržaja “izvana” konačno se i obistinila. Osim podataka koji se nalaze na raznim poslužiteljima nepoznate lokacije, također se i softver koji ih obrađuje i izračunava nalazi izvan mogućnosti korisnika da ih prouči i nadzire. Pod pojmom softver kao usluga (SaaS), koji svakim danom postaje sve prisutniji, skriva se cijeli đavolji orkestar mehanizama koji oduzimaju slobodu korisnika. GMail, Viber, Skype, Flickr, Googleove usluge za Android, Appleov iOS, Dropbox, Netflix, cijela Facebookova platforma – samo su nasumično odabrani primjeri ovog problema i da stvar bude apsurdnija svi oni pod svojim skutima uvelike koriste slobodan softver, ali korisnik od tog slobodnog softvera nema apsolutno ništa. Kad WhatsApp podijeli podatke korisnika s Facebookom, nakon što ih je “transparentno” pokupio s korisnikovog mobilnog uređaja, može li korisnik ikako utjecati na to? Može li korisnik promijeniti program za gledanje Netflixovog filma da mu prikaže vlastite podnaslove? Može li Skype korisnik na Linuxu možda sudjelovati u konferencijskom pozivu? Može li jednostavno isključiti nove reklame u Facebooku? Odgovor je na sve: ne može.

Na prvu loptu, čini se da postoje razni načini da se izbjegne taj zatvoreni ekosustav i receptura je stara, ali cijena je svakim danom sve viša i viša. Da bi sačuvao ili vratio kontrolu nad svojim podacima, a opet ne ostao u prošlim desetljećima, korisniku ostaje mogućnost podizanja i održavanja vlastitog poslužitelja sa svim slobodnosoftverskim web aplikacijama i servisima, međutim znanje, novac i vrijeme koje je za to potrebno daleko nadmašuje ono što je pojedinac koji se ne bavi sistemskim administriranjem ili razvojem weba (polu-)profesionalno voljan izdvojiti. No čak i da uspije izbjeći stranputice poput GMaila, Dropboxa, Skypea, Flickra i drugih usluga osiguravajući alternative koje kontrolira, dolazi iduća plima problema manifestirana u sveopćoj digitalizaciji usluga koje nisu primarno vezane za računala i digitalne podatke u užem smislu.

Internetsko bankarstvo, kartično plaćanje, javne usluge i prijevoz, posudba knjiga, filmova i serija, kupovina roba, potrošačka elektronika, dječje igračke, osobni automobili i mnoge druge stavke prilikom svoje digitalizacije zahtijevaju ili će zahtijevati neki oblik softvera kao usluge što će u većini slučajeva biti neki oblik vlasničke platforme ili barem one ovisne o vlasničkoj platformi. Čak i kad je web ili mobilna aplikacija financirana javnim novcem jer se radi o javnoj usluzi, onda je u pravilu dostupna samo preko vlasničkih kanala distribucije, Google Playja ili iTunesa, jer to je, kako kažu, sigurnije za distribuciju i zaštitu od malicioznih aplikacija te zaštitu autorskih prava. Prva je pomisao da je možda u tom slučaju moguće naprosto odbiti koristiti sve te aplikacije i vlasničke usluge. No tada si taj “poludjeli” pojedinac veže ruke jer više nije jednostavno naručiti taksi, popuniti poreznu prijavu, kupiti kartu za vlak ili avion, platiti  račun za komunalne usluge, unajmiti gradski bicikl, iskoristiti nove funkcionalnosti potrošačke elektronike ili dječjih igračaka, posuditi knjigu, pogledati novu seriju ili film, poslati poštanski paket, platiti račun karticom u trgovini… a u budućnosti će se taj skup vjerojatno proširiti i na to da se bez Googleovog, Appleovog ili Facebook računa i neke pripadajuće vlasničke platforme neće moći ni kupiti osnovne namirnice u lokalnoj trgovini mješovitom robom, a možda ni završiti školovanje. Baš kao što već danas treba skinuti aplikaciju preko tih vlasničkih platformi da bi poslušao poruku svog kandidata možda mu omiljene političke stranke.

Vjerojatno će još neko vrijeme postojati stari kanali naručivanja usluga i roba, interakcije s birokracijom, i to telefonom, papirnatim formularom ili posebnom kasom ili šalterom za “tehnološki zaostale”, no oni će biti sve rjeđi i opskurniji kako će se većina stanovništva “digitalizirati”: “Ako ne želite instalirati našu aplikaciju za izdavanje potvrde o položenom vozačkom ispitu možete doći na šalter broj 5. utorkom i četvrtkom od 9:30 do 10 sati.” završi govorni automat MUP-a kojeg planiraju ukinuti jer ga nitko ne zove mjesecima. Tada će nepokoreni pojedinac u želji da kontrolira svoje podatke i softver ostati na margini društva – pustinjak i čudak koji se očito, sa stajališta većine, ne može prilagoditi modernim tokovima. Ili se prilagodi ili živi u šumi. I tu je slobodan softver izgubio svoju bitku jer pitanje slobode je oduvijek pitanje individualnosti, a ako se svi moraju ponašati isto, onda slobode u suštini nema, već samo “sloboda” da se pojedinac ponaša onako kako je zamišljeno i propisano – zašto bi uopće želio drugačije? Što je društveni sustav efikasniji u nametanju svojih normi i procedura, to je manje slobode na pojedincu da zadrži svoj identitet.

Razlog ovakvog raspleta borbe za slobodan softver kriva je strategija samog pokreta, a to je da se on bazira na tehnološkim rješenjima i utjecanjem da svijest pojedinca, a ne jasnom na političkom stavu i utjecaju na društvo u cjelini. Umjesto iscrpljivanja na slobodnim implementacijama vlasničkih programa, više bi se postiglo insistiranjem na zakonskom okviru koji bi garantirao te slobode koje pokret promiče, što je svojevremeno dobro uočio Eben Moglen. U početku pokreta za slobodan softver može se još pričati o postojanju nekakvoga ideološkog okvira, međutim dolaskom i prevladavanjem termina softver otvorenog koda svaka ambicija za političkom artikulacijom problema je nestala. Danas je slobodan softver, odnosno softver otvorenog koda omiljen svakome, pa i starim dušmanima poput Microsofta, ali bez ikakvoga značenja za slobodu korisnika. Tako da se popularna u krugovima Linux korisnika Red Hatova reklama za Linux “Prvo te ignoriraju. Zatim ti se smiju. Zatim se bore protiv tebe. I tada pobjeđuješ.” može nastaviti pojašnjenjem “…zato što si u procesu toliko izgubio svoj smisao da više nikome ne smetaš.”

Baš kao mnogi drugi progresivni pokreti koji su se javljali u različitim kontekstima u želji da isprave nepravde i kontradikcije sustava, tako je i slobodni softver kapitulirao jer nije djelovao politički i nije udarao u glavu problema. Na primjer, isti epitaf ide i pokretima za očuvanje okoliša gdje sve vođe svijeta unisnono pjevaju o važnosti očuvanja okoliša, a zapravo samo govore o biznisu preprodaje kvota za stakleničke plinove i rasipanju javnog novca na kojekakve privatne komercijalne inicijative koje po cijenu vlastitog preživljavnaja na oltaru tržišta ne mogu staviti okoliš ispred profita. U oba slučaja forma je tu – svima su puna usta i ekologije i softvera otvorenog koda, ali izvornog sadržaja nažalost više nema.

Tek udruživanjem snaga sa svim drugim progresivnim pokretima i formiranjem radikalnih političkih zahtjeva, slobodan softver može oživjeti nadu da je ovo samo izgubljena bitka, ali ne i rat. Ipak nije vjerojatno da će slobodan softver biti nosilac takve globalne promjene – on jedino što može jest prepoznati i pridružiti se onim pokretima koji imaju veću mobilizacijsku snagu i tako sačuvati svoje ideje i vrijednosti za jedno novo društvo – društvo slobodnih i kreativnih, društvo u kojem svaki pojedinac, svako dijete može rastaviti, ispitivati, učiti i doživljavati svijet oko sebe te tako stvarati nove vrijednosti, pronalaske, rađati nove ideje i ostvariti se i kao umjetnik i kao inženjer i kao filozof. Društvo pojedinaca koji su stvaraoci i mislioci, a ne konzumenti.

Sretan 25. rođendan Linuxu

25. August 2016 - 8:07
Prije četvrt stoljeća, započela je priča o softveru kojeg gotovo većina ljudi u današnjem svijetu svakodnevno koristi u uređajima koji nas okružuju, nesvjesni njegovog postojanja i njima je današnji dan kao i svaki drugi. Oni, koji su se ipak odvažili i “zagrebli” malo dublje ispod površine, znaju da danas ipak nije dan kao i svaki drugi jer je 25. kolovoza 1991. godine Linus Benedict Torvalds predstavio Linux, inspiriran Minixom.

Sretan 25. rođendan Linuxu

Linux za sve, povodom ovog posebnog dana, želi svim članovima Linux zajednice sretno i dugo korištenje njihovih omiljenih Linux distribucija te da svojim nesebičnim radom i zalaganjem pomognu da Linux živi još dugo.

Linukše, sretan ti 25. rođendan!

Predavanje – Virtualizacija, linux kontejneri i Proxmox VE

3. June 2016 - 9:39
U subotu, 18. lipnja 2016. godine od 10:00 do 12:30 sati, u organizaciji Open Source Osijek, u prostoru Poduzetničkog inkubatora BIOS d.o.o. na adresi J.J.Strossmayera 341 – Osijek, održat će se predavanje pod nazivom: Virtualizacija, linux kontejneri i Proxmox VE.

 

 

Predavanje je podijeljeno u dvije cjeline pa će tako zainteresirani polaznici u uvodnom dijelu moći saznati:

  • Što je to virtualizacija i zbog čega ju uopće koristiti ?.
  • Što su to Linux kontejneri ?.
  • Koje sve vrste virtualizacije postoje i u čemu su razlike
  • Koje su sve platforme za virtualizaciju dostupne na tržištu, što nude i za koju su namjenu.

… dok će u drugom dijlu naglasak biti na Proxmox VE platformi za virtualizaciju i linux kontejnerima:

  • razvoj i funkcionalnosti te licenca i podrška
  • osnovne i napredne mogućnosti same platforme
  • virtualizacija i njene prednosti i mane te funkcionalnosti unutar platforme
    paravirtualizacija i VirtIO
  • linux kontejneri i njihove prednosti i mane te funkcionalnosti unutar platforme
  • upotreba u praksi i iskustva korisnika (gosti).

Predavanje je besplatno, a organizator moli zainteresirane da na vrijeme izvrše registraciju radi planiranja i rezervacije broja mjesta. Registracija je dostupna na: https://www.opensource-osijek.org/wordpress/events/virtualizacija-linux-kontejneri-i-proxmox-ve/

 

[PR] Open Source Osijek