Edellisessä artikkelissa kävin läpi muutaman Cephin ja SUSE Enterprise Storagen perusasiat. Tällä kertaa pohdinnassa on, millaisella kokoonpanolla kannattaa lähteä liikenteeseen.

 

Ennen kuin on mahdollista päättää, montako palvelinta tarvitaan, ja millaisella kalustuksella, tulee Cephin perustoimintaa avata hieman tarkemmin.

rados(part1).png

Yksinkertaisimmillaan toimiva Ceph-klusteri koostuu kahdesta komponentista: Monitori-palvelusta ja Object Storage Daemon-palvelusta (=OSD). Monitoripalvelua ajavaa palvelinta kutsutaan Monitori-noodiksi, ja OSD-palveluita ajavaa noodia OSD- tai Storage-noodiksi.

 

Monitori-noodit muodostavat klusterin muiden monitori-noodien kanssa, ja niiden tavoitteena on pitää yllä klusterikonfiguraatiota, sekä karttaa klusterin käytettävissä resursseista mm. OSD:stä. Karttaa kutsutaan CRUSH-kartaksi (”Controller Replicatoin Under Scalable Hashing”), ja se sisältää resurssien lisäksi käytössä olevat replikointisäännöt.

 

Storage-noodilla on käytettävissä jotain fyysistä mediaa, yleensä levyjä, joille jokaiselle luodaan oma OSD-palvelu. OSD raportoi olemassaolonsa ja valvomansa median statuksen monitori-noodeille ja muille samaa dataa tallentaville OSD:ille, sekä keskustelee asiakkaiden kanssa.

 

Klusteriin tallennettava data pilkotaan tallennustilanteessa osiin, ja sijoitetaan OSD:ille objekteina.

Kun käyttäjä, palvelin, tai palvelu haluaa tallentaa Ceph-klusteriin jotakin, se kysyy monitori-noodilta, mitä resursseja klusterissa on käytettävissä. Monitori-noodi palauttaa asiakkaalle ajantasaisen klusterikonfiguraation, sekä listan käytettävissä olevista OSD:stä CRUSH-karttana. Näiden avulla asiakas laskee, mille noodeille pilkottua dataa tulee tallentaa. OSD replikoi tallennetun datan klusterin vaatimalle minimimäärälle muita OSD:tä vikasietoisuuden takaamiseksi.

 

Vastaavasti kun klusterista halutaan lukea jotakin, tehdään monitori-noodeille vastaava kysely kuin tallennuksessakin. Tämän jälkeen asiakas taas laskee, mistä kaikkialta kyseisen datan kappaleita löytyy. Jos varmistuksena käytetään suoraa replikaa, data on tallennettu useampaan kuin yhteen paikkaan, joten asiakas voi lukea samaa dataa useammalta kuin yhdeltä OSD:ltä.

 

SUSE tarjoaa lisäksi neljää muuta noodityyppiä helpottamaan roolitusta:

  • Admin-noodi – Käytetään klusterin pystyttämisessä ja muutoksissa, ja täällä voidaan pitää halutessaan web-käyttöliittymää.

  • iSCSI-gateway-noodi – Tarjoaa asiakkaille iSCSI-rajapintaa. Kahdennettavissa aktiivi-aktiivi.

  • Rados-gateway-noodi – Tarjoaa S3/Swift-objektitallennusrajapintaa. Kahdennettavissa aktiivi-aktiivi, edellyttää erillisen kuormantasaajan.

  • MDS-noodi – Metadata-noodi, joka mahdollistaa POSIX-yhteensopivan tiedostojärjestelmän (CephFS) tarjoamista suoraan asiakkaille. Kahdennettavissa aktiivi-passiivi.

 

Käytännön kannalta monitori-noodeja halutaan yleensä olevan vähintään kolme kappaletta, aina pariton määrä, ja enintään seitsemän kappaletta. Kolmen minimi ja aina pariton määrä varmistavat klusterin quorumin olemassaolon. Quorum on klusterissa päättävien noodien määräenemmistö, tällä varmistutaan klusterin tiedon eheys. Yli kolmen monitori-noodin ylläpitäminen lisää merkittävästi klusterin overhead-liikennettä, joten sitä ei yleensä suositella, ja maksimina SUSE pitää seitsemää noodia.

 

Storage-noodeja tarvitaan yksi enemmän, kuin mikä on klusterin ylläpitämä replikamäärä.

Esimerkiksi, jos datasta halutaan pitää aina vähintään kolme replikaa, tulee noodeja olla vähintään neljä kappaletta. Klusteri kestää tällöin yhden noodin hajoamisen ilman replikamäärän tippumista, sekä kahden noodin hajoamisen ilman datan menetystä. Hajoamistilanteessa klusteri tasapainotetaan uudestaan, mikä aiheuttaa merkittävän määrän noodien välistä liikennettä. Suurempi noodimäärä tasoittaa tästä aiheutuvaa suorituskykyrasitusta.

 

Monitori- ja OSD-palveluita voi ajaa samalla fyysisellä alustalla, mutta tämä on suositeltavaa vain pienissä kokoonpanoissa. Kun lähestytään 6-7 noodin kokonaiskokoonpanoa, on viimeistään suositeltavaa eriyttää monitori-palvelut omalle fyysiselle alustalleen, jotta storage-noodien välinen liikenne ei haittaa monitori-noodien välistä välttämätöntä liikennettä.

 

iSCSI- ja Rados-gateway-noodeja tarvitaan yksi, mutta käytännön kannalta vikasietoisuuden takaamiseksi niitä kannattaa olla vähintään kaksi. iSCSI-gatewayt saadaan kahdennettua suoraan multipathingilla, ja Rados-gatewayt tarvitsevat lisäksi erillisen kuormantasaajan. Gateway-noodeja suositellaan tuotannossa ajettavan omilla alustoillaan.

 

MDS-noodeja tarvitaan yksi. Vikasietoisuuden takaamiseksi suositellaan kahta noodia. Tätä noodityyppiä tarvitsee, mikäli haluaa käyttää CephFS:ää.

 

Mikä sitten on suositeltava määrä noodeja lähteä liikenteeseen?

SUSE tarjoaa Enterprise Storageen aloituspakettia, johon kuuluu lisenssi 4:lle OSD-noodille ja 5 infrastruktuuri-noodille, joilla voi asentaa minkä tahansa muista noodityypeistä.

Oma suositukseni aloitukseen on 7(+2) fyysistä alustaa, joista 3 on monitoreille ja 4 OSD-noodeille. Gateway-noodit saattavat kuormasta riippuen tarvita omat fyysiset alustansa, tai olla ajettavissa monitorien yhteydessä.

 

Seuraavassa blogissamme käsittelemme SUSE Enterprise Storagen suorituskyvyn mittaamista.

Ohjelmistopohjainen tallennus on täällä - lataa ostajan opas

SUSE Enterprise Storage 3 Documention

Kokeile SUSE Enterprise Storage tuotetta 60 päivää

 


Jätä yhteydenottopyyntö tai soittopyyntö, otamme sinuun yhteyttä 24 tunnin sisällä.

Ota yhteyttä