Mistä on kyse :
Jos ajattelet tai keskustelet Ceph:stä , yleisin mieleesi tuleva kysymys on “Minkälainen laitteisto minun pitäisi valita CEPH-tallennusklusteriini?” ja kyllä, jos todella ajattelit tätä kysymystä mielessäsi , onnittelut , näytät olevan tosissasi ceph-teknologian suhteen ja sinun pitäisikin olla, koska CEPH ON VARASTOINNIN TULEVAISUUTTA.
Ceph pyörii Commodity-laitteistolla , Ohh Joo !! kaikki tietävät sen nyt . Se on suunniteltu rakentamaan monen petatavun tallennusklusteri samalla kun se tarjoaa yritysvalmiita ominaisuuksia. Ei yksittäistä vikaantumispistettä , skaalautuminen exatavuihin , itsehallinta ja itsehoito ( säästää käyttökustannuksia ) , toimii Commodity-laitteistolla ( ei myyjäsidonnaisuutta , säästää pääomasijoituksia )
Ceph Yleiskatsaus :-

Ceph-tallennusklusterin ainoa nimi on RADOS ( Reliable Autonomic Distributed Object Store ) . Ceph käyttää tehokasta CRUSH ( Controlled Replication Under Scalable Hashing ) algoritmia tietojen sijoittelun optimointiin , itsehallintaan ja itsehoitoon. RESTful-rajapinnan tarjoaa Ceph Object Gateway (RGW) aks Rados GateWay ja virtuaalilevyt provisioidaan Ceph Block Device (RBD)

Ceph Overview – Image Credit : Inktank

# Ceph OSD ( Object Storage Daemons ) tallentaa dataa objekteihin , hallitsee datan replikointia , toipumista , uudelleentasapainottamista ja tarjoaa etappitietoja Ceph Monitorille. Sen suositellaan käyttävän 1 OSD:tä fyysistä levyä kohden.
# Ceph MON ( Monitors ) ylläpitää klusterin yleistä kuntoa pitämällä yllä klusterin karttatilaa, mukaan lukien Monitor-kartta , OSD-kartta , Placement Group ( PG ) -kartta ja CRUSH-kartta. Monitors vastaanottaa tilatietoja muilta komponenteilta karttojen ylläpitämiseksi ja kierrättää näitä karttoja muille Monitor- ja OSD-solmuille.
# Ceph RGW ( Object Gateway / Rados Gateway ) RESTful API -rajapinta yhteensopiva Amazon S3 , OpenStack Swiftin kanssa.
# Ceph RBD ( Raw Block Device ) Tarjoaa lohkotallennustilaa VM:lle / paljaalle metallille sekä tavallisille asiakkaille , tukee OpenStackia ja CloudStackia . Sisältää Enterprise-ominaisuuksia kuten snapshot , thin provisioning , compression.
# CephFS ( File System ) hajautettu POSIX NAS-tallennus.
Joitakin peukalosääntöjä :-

• Käynnistä OSD dedikoidussa tallennussolmussa ( palvelimessa, jossa on useita levyjä ) , varsinainen data tallennetaan objektien muodossa.
• Käynnistä Monitori erillisellä dedikoidulla laitteistolla tai rinnakkain ceph-asiakassolmujen kanssa ( muiden kuin OSD-solmun kanssa ), kuten esimerkiksi RGW- ja CephFS-solmun kanssa . Tuotantoa varten on suositeltavaa ajaa Monitorit erillisillä edullisilla palvelimilla, koska Monitorit eivät ole resurssinälkäisiä.

Monitorin laitteistokonfiguraatio :-
Monitor ylläpitää koko klusterin terveyttä , se sisältää PG lokit ja OSD lokit . Vähintään kolme monitorisolmua suositellaan klusterin päätösvaltaiseksi. Ceph monitor solmut eivät ole resurssinälkäisiä ne voivat toimia hyvin melko pienellä cpu ja muistin määrällä. Useimmissa tapauksissa 1U-palvelin, jossa on edullinen E5-2603-prosessori, 16 Gt RAM-muistia ja 1 GbE-verkko, pitäisi riittää. Jos PG-, Monitor- ja OSD-lokit tallennetaan monitorisolmun paikalliselle levylle, varmista, että sinulla on riittävästi paikallista tallennustilaa, jotta se ei täyty.
Epäterveet klusterit vaativat enemmän tallennustilaa lokitiedostoja varten, jotka voivat olla jopa gigatavuja ja jopa satoja gigatavuja, jos klusteri jätetään epäterveeksi hyvin pitkäksi aikaa. Jos monitorisolmujen verbose-tulostus on asetettu, ne tuottavat väistämättä valtavan määrän lokitietoja. Katso ceph-dokumentaatiota monitorin lokiasetuksista.
Suositellaan monitorin suorittamista kaukana sijaitsevissa solmuissa mieluummin kaikissa kaikissa yhdessä solmussa tai virtuaalikoneissa fyysisissä erillisissä koneissa yhden vikaantumispisteen estämiseksi.
Suunnitteluvaihe :-
Ceph-klusterin käyttöönotto tuotannossa vaatii hieman kotitehtäviä , sinun pitäisi kerätä alla olevat tiedot, jotta voit suunnitella paremman ja luotettavamman ja skaalautuvamman ceph-klusterin IT-tarpeisiisi sopivaksi. Nämä hyvin spesifiset tarpeisiisi ja IT-ympäristöösi. Nämä tiedot auttavat sinua suunnittelemaan tallennustarpeesi paremmin.

• Liiketoimintatarpeet
• Budjetti ?
• Tarvitsetko Ceph-klusteria päivittäiseen toimintaan vai ERITYISIIN
• Tekniset vaatimukset
• Mitkä sovellukset tulevat toimimaan ceph-klusterissasi ?
• Minkä tyyppistä dataa ceph-klusteriin tallennetaan?
• Pitäisikö ceph-klusteri optimoida kapasiteetin ja suorituskyvyn suhteen?
• Minkä pitäisi olla käyttökelpoinen tallennuskapasiteetti?
• Minkälainen on odotettu kasvuvauhti?
• Minkä verran IOPS:ia klusterin pitäisi tukea?
• Minkä verran läpimenoa klusterin pitäisi tukea
• Minkä verran datan replikointia ( luotettavuustaso ) tarvitset?

Kerää mahdollisimman paljon tietoa suunnitteluvaiheessa , se antaa kaikki vastaukset, joita tarvitaan paremman ceph-klusterin rakentamiseen.
Fyysinen solmu ja klusterointitekniikka:-
Yllä kerättyjen tietojen lisäksi , ota huomioon myös telineen tiheys ja tehobudjetti , datakeskuksen tilan vauhti kustannus optimaalisen solmukokoonpanon mitoittamiseksi. Ceph replikoi tietoja useisiin solmuihin tallennusklusterissa tietojen redundanssin ja paremman saatavuuden tarjoamiseksi. Sen on tärkeää ottaa huomioon.

• Pitäisikö replikoidun solmun olla samassa telineessä vai useammassa telineessä SPOF:n välttämiseksi?
• Pitäisikö OSD-liikenne pysyä telineen sisällä vai ylittääkö se telineet dedikoidussa tai jaetussa verkossa?
• Miten monta solmun vikaantumista voidaan sietää?
• Jos solmut on hajautettu useisiin telineisiin, verkkoliikenne lisääntyy ja latenssin vaikutus sekä verkkokytkimen hyppyjen määrä on otettava huomioon.

# POC-ympäristö – Voi olla vähintään 3 fyysistä solmua, joissa kussakin on 10 OSD:tä. Tämä takaa 66 %:n klusterin käytettävyyden fyysisen solmun vikaantuessa ja 97 %:n käytettävyyden OSD:n vikaantuessa. RGW- ja Monitor-solmut voidaan sijoittaa OSD-solmuihin, mutta tämä voi vaikuttaa suorituskykyyn, eikä sitä suositella tuotantoympäristöön.
# Tuotantoympäristö – Vähintään 5 fyysisesti erillistä solmua ja vähintään 100 OSD:tä @ 4TB per OSD klusterin kapasiteetti on yli 130TB ja tarjoaa 80 %:n käytettävyyden fyysisen solmun vikaantuessa ja 99 %:n käytettävyyden OSD:n vikaantuessa. RGW:n ja monitorien tulisi olla erillisissä solmuissa.
Suunnitteluvaiheen ja fyysisten solmujen ja klusterin muodostamisvaiheen tulosten perusteella voit tarkastella markkinoilla saatavilla olevaa laitteistoa budjettisi mukaisesti.
OSD-suorittimen valinta :-
< Under Construction … Stay Tuned >