Toon posts:

Ceph, an open source distributed file system

Pagina: 1
Acties:

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Hallo,

De laatste tijd is er veel te doen rondom storage, ook worden er veel mooie systemen ontwikkeld om aan onze vraag voor nog meer data opslag te voldoen.

Zo kwam ik zelf recentelijk Ceph tegen. Dit is een Open Source distributed filesystem voor Linux.

Heb inmiddels zelf een klein test cluster draaien en moet zeggen dat ik erg onder de indruk ben.

Toevallig is er gisteren op linux-mag.com een mooi artikel over Ceph gekomen die goed in beeld brengt wat het is: http://www.linux-mag.com/cache/7744/1.html

Nu wilde ik met deze post het filesystem onder aandacht brengen, dat is iets wat het namelijk (naar mijn idee) nodig heeft. De potentie is er zeker, als je kijkt naar wat het biedt is dit aardig (r)evolutionair, veel van dit soort filesystems kennen we nog niet.

Er bestaan inderdaad wel meerdere clustered filesystems, maar een near-Posix distributed filesystem ben ik verder nog niet tegen gekomen.

Mijn huidige tests geven aan dat er echt nog wel wat bugs zijn, ook kan de performance beter, maar daarvoor is input nodig :)

Ook wordt er gewerkt aan een block driver waar je eigen filesystem op kan draaien, het kan ook ideaal zijn voor gebruik met KVM!

Ik hoop met dit topic een discussie los te kunnen krijgen en hopelijk ook wat tweakers te vinden die willen gaan testen.

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Kun je de storage nodes als bricks aan elkaar hangen, of loopt het via een metadata/index server?
En is de splitsing van bestanden over het aantal nodes te regelen of pakt hij dat automatisch op?

Dit lijkt me wel een interessante. Ik ga hier in ieder geval even mee experimenteren.

- I Am Second - Rebels Guide to Joy - Werkelijke Christendom


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Je hebt 3 onderdelen, de monitors (cmon), de meta data servers (cmds) en de opslag bricks (cosd).

De data zelf gaat niet via de MDS, de MDS is alleen een lookup waar de client vraagt waar hij de data kán vinden, daarna contacteert hij de OSD direct.

De OSD's draaien los van elkaar, ze kennen elkaar via de config en houden zo van elkaar bij wie er nog leeft.

De files splitsen doet hij zelf, je kan wel aangeven op welk replication level hij moet werken. Standaard is 2x, maar dit kan je zo hoog zetten als je zelf wil.

Heb zelf een cluster draaien met 2 monitors, 2 meta data servers en 5 OSD's (elk 250GB), draait leuk moet ik zeggen.

Anoniem: 193142

Laten we weer eens terugpakken op deze mooie oplossing.
Met zowat elke hardware op te zetten. Niks dure oplossingen...

Wie heeft er al Ceph geïmplementeerd en wat is jullie ervaring?
Een plaatje van de infrastructuur is natuurlijk altijd welkom :)

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Ik ben aan m'n tweede test-opstelling bezig. Ik heb een jaar geleden een virtuele omgeving gebouwd om het te testen. Block storage werkte toen prima maar cephfs was niet stabiel. Ik ben nu wat oude servers aan het ombouwen tot een fysieke test-omgeving. Ik heb vier oude servers en wat lades schijven waar ik een cluster van aan het bouwen ben. De eerst host draait maar deployen op andere hosts lukt me nog niet.
En wat heb jij voor een omgeving?

This post is warranted for the full amount you paid me for it.


  • JMW761
  • Registratie: Oktober 2001
  • Laatst online: 15:15
Wij zijn hier ook bezig met het bouwen van een testopstelling.
Zodra ik meer duidelijkheid heb, zal ik me hier weer melden; tot die tijd lees ik mee 8)

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Ik werk nu al enkele jaren met Ceph en moet zeggen dat het érg bevalt.

Heb wat cluster gebouwd die inmiddels in productie zijn waar de gemiddelde grootte zo rond de 100TB ligt aangezien nog niet iedereen er helemaal in durft te gaan. Toevallig vanmorgen nog een 50TB cluster online gezet wat met de RGW gaat draaien.

CephFS is helaas nog niet stabiel genoeg, maar RBD en de RGW werken prima.

De RGW ben ik niet helemaal tevreden over zoals het nu is in een FastCGI proces achter Apache, maar hopelijk wordt dat snel een standalone webserver die je achter een proxy zet.

RBD begint nu ook integratie te zien met de grotere projecten zoals OpenStack en CloudStack.

Native RADOS is verder ook erg tof, je kan met bindings voor meerdere talen direct tegen RADOS objecten praten en daar erg leuke dingen mee bouwen indien je weet hoe het werkt.

[Voor 18% gewijzigd door Snow_King op 23-09-2013 15:38]


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Ik worstel momenteel met ceph-deploy. Ik ben onzeker over hoe die tool precies gebruikt moet worden. Ik volg deze handleiding. Die handleiding zegt dat ik een aparte gebruiker 'ceph' moet aanmaken en dan sudo-rechten geven. Dat suggereert dat ik geen root nodig heb. Als ik geen root gebruik dan loop ik tegen problemen aan omdat de 'ceph' gebruiker geen schrijfrechten heeft over files die uit packages komen. Als ik het wel als root draai dan gaat lokaal alles goed maar kom ik in de problemen met andere servers. ceph-deploy probeert namelijk te bepalen of er 'sudo' gebruikt moet worden maar kijkt daarbij naar het lokale systeem, ipv het systeem waar ik naar toe ssh. Sorry voor de warrige omschrijving maar dat is precies mijn probleem.

Draaien jullie ceph als een aparte gebruiker?
Draaien jullie ceph-deploy als die aparte gebruiker of als root?

Een vergelijkbaar probleem heb ik met ceph.conf . Die staat op de servers in /etc/ceph maar er blijft ook een kopie achter in de admin dir. Ik zou verwachten dat als ik met ceph-deploy een server toevoeg dat die dan ook aan de configfile wordt toegevoegd. Dat gebeurt echter niet maar na het herstarten van ceph werkt het toch. Ik vermoed dat de informatie ergens in /var/lib/ceph zit.

Wat is nu de bedoeling van ceph.conf?
Moet ik die met de hand bewerken en verspreiden?
Als ik iets wil veranderen (bv een OSD toevoegen), pas ik dan eerst de config aan of roep ik eerst ceph-deploy aan?

[Voor 3% gewijzigd door CAPSLOCK2000 op 24-09-2013 15:00]

This post is warranted for the full amount you paid me for it.


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
CAPSLOCK2000 schreef op dinsdag 24 september 2013 @ 14:59:

Draaien jullie ceph als een aparte gebruiker?
Draaien jullie ceph-deploy als die aparte gebruiker of als root?
Ik gebruik Ceph deploy niet, vind het een vreselijke tool die veel te veel dynamisch veel doen. Ik vermijd hem en doe het meeste manueel.
CAPSLOCK2000 schreef op dinsdag 24 september 2013 @ 14:59:Wat is nu de bedoeling van ceph.conf?
Die is niet altijd nodig. De OSD's hebben de meeste data (zoals de monmap) al in hun datadir en weten zo de mons al te vinden.

ceph-deploy gebruikt onder Ubuntu ook upstart om je OSD's automatisch te starten zodra je een disk in een machine prikt.
CAPSLOCK2000 schreef op dinsdag 24 september 2013 @ 14:59:Moet ik die met de hand bewerken en verspreiden?
Dat kan je nog wel doen als je specifieke configuratie wil wijzigen voor OSD's.
CAPSLOCK2000 schreef op dinsdag 24 september 2013 @ 14:59:Als ik iets wil veranderen (bv een OSD toevoegen), pas ik dan eerst de config aan of roep ik eerst ceph-deploy aan?
Nee, ceph-deploy zal zelf je ceph.conf aanpassen, maar zoals ik al aangaf, de tool gebruikt die niet echt.

Ik ben zelf meer fan van zelf de MON en OSD bootstrappen:
* http://eu.ceph.com/docs/master/dev/mon-bootstrap/
* http://eu.ceph.com/docs/m...perations/add-or-rm-osds/

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Mijn eerste ceph-cluster heb ik met de hand gebouwd en dat ging soepeler dan nu met ceph-deploy, al zijn we inmiddels een paar ceph-versies verder dus helemaal eerlijk is de vergelijking niet. Ik geloof dat ik ook meer van het handwerk ben, dan snap ik tenminste wat er gebeurd en kan ik problemen oplossen als ze voorkomen. Maarja, ik ben lui, en ceph-deploy klinkt heel handig.
Ik heb mijn proefopstelling nog eens doorgedacht en ga het nog één keer met ceph-deploy proberen, gewoon om te kijken of het dan wel werkt en omdat ik dan snel klaar ben met m'n test.
Daarna (of het nu lukt of niet) ga ik het nog een keer met de hand doen.

update
De eerste node ging nu vlekkeloos met ceph-deploy. De tweede hangt (zombie proces) op ceph-create-keys. Dat is wel zo apart dat ik het morgen nog een keer ga proberen.

[Voor 12% gewijzigd door CAPSLOCK2000 op 24-09-2013 18:15]

This post is warranted for the full amount you paid me for it.


  • Kees
  • Registratie: Juni 1999
  • Laatst online: 15:45

Kees

Serveradmin / BOFH / DoC
Ik heb ceph ook uitgeprobeert (voor deze website) maar ik liep toch nog tegen zoveel issues aan dat ik het nog niet handig vond om het in productie te zetten (crashende osd's enzo). Het is een heel mooi FS, maar voor kleinere datasets niet zo heel gunstig en bovendien hebben ze (nog steeds) een split-brain probleem.

Ook dat je niet teveel data per node moet hebben (omdat als de node dan uitvalt je gewoon heel lang bezig bent met rebalancen) en je nodes zo 'brak' zijn dat je je data op 3 plekken wil hebben. Dan kom je uit op 1u servers met 4x2TB aan disks en voor 24TB netto heb je dan zo'n 9 servers bruto voor nodig en mocht er een uitvallen dan is je cluster gewoon dik 18 uur lang aan het rebalancen (als hij vol staat).

Als de huidige storage (Sun 7120) over 3 jaar vervangen gaat worden is het zeker wel een idee om daarnaar te gaan kijken, hopelijk hebben we tegen die tijd ook een 10Gbit netwerk liggen waardoor de rebuildtijden omlaag kunnen :)

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


Anoniem: 193142

Kees, wanneer heb je naar de Ceph oplossing voor Tweakers gekeken? Is dit recentelijk geweest? In het laatste half jaar is er namelijk gigantisch veel vooruitgang geboekt, zeker ook op de stabiliteit. Het heeft een soort logaritmisch patroon van updates gehad.

Nu heb ik het hier ook in een testomgeving draaien en moet zeggen dat het prima stabiel draait. Dat zijn dan 3 nodes met elk 2TB, maar dat schalen we binnenkort op als we overstappen in de productieomgeving (met low power Xeons). Dan worden het minimaal 3 nodes van elk 8x2TB (dus 48TB, waarvan 24TB netto beschikbaar).

Waarschijnlijk dat we opschalen naar 5 nodes als totaal cluster (waarvan de laatste 2 dan elk 8x4TB krijgen). Het totaal is dan 112TB waarvan netto 56TB beschikbaar is. Snelheid, redundancy en de mogelijkheid om een complete server eruit te halen of te upgraden. Het mooie is er namelijk van dat je een oneindig opschaalbaar storage cluster krijgt. En dat is wel even wat anders dan andere oplossingen (tegen een zeer aantrekkelijke prijs ivm het gebruik van commodity hardware).

  • imp-
  • Registratie: September 2008
  • Laatst online: 00:19
Zelf nog geen ervaring met ceph, maar wel met gluster.
Draai het al zowat anderhalf jaar in een labo-setup met wat oudere machines.
Binnenkort ook een eerste productiesetup, normaal gezien deze week. Ik heb er alvast vertrouwen in.

Beide zijn erg vergelijkbaar naar mijn mening, misschien toch ceph ook eens uitproberen :)

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
imp- schreef op zondag 29 september 2013 @ 12:02:
Beide zijn erg vergelijkbaar naar mijn mening, misschien toch ceph ook eens uitproberen :)
Ceph != Gluster.

Ceph is in de basis een object store (RADOS) waar vervolgens diverse zaken bovenop zijn gebouwd waar Gluster vanuit een POSIX Filesystem idee gebouwd is.

Dat zijn twee fundamentele verschillen.

  • imp-
  • Registratie: September 2008
  • Laatst online: 00:19
Snow_King schreef op zondag 29 september 2013 @ 12:35:
[...]

Ceph != Gluster.

Ceph is in de basis een object store (RADOS) waar vervolgens diverse zaken bovenop zijn gebouwd waar Gluster vanuit een POSIX Filesystem idee gebouwd is.

Dat zijn twee fundamentele verschillen.
Heb je idd volledig gelijk in, ik was iets te snel in mijn conclusie.
Dat ik ceph nog nooit bekeken heb zal daar ook niet vreemd aan zijn :)
Niettemin zijn het beide wel interessante projecten.

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Mijn cluster werkt.
Ik heb

2 x OSD + MON
per OSD:
- 14 x 300GB schijven
- 10 gbit interconnect
- 20G ram

En dan nog een 1 losse MON-server (zodat ik er in totaal drie heb) en uiteraard een client.

Ik heb er op dit moment 1 client aan hangen. Daarop draai ik Ganeti, een handige cluster-manager met Ceph-support. Dat ganeti-"cluster" ga ik uiteraard nog uitbreiden met meer machines. Voorlopig ga ik eerst een de performance testen. Ik heb blind een paar schijven uitgetrokken en dat lijkt goed te worden opgevangen. Een schijf terugplaatsen lijkt echter redelijk ingewikkeld te zijn. Het toevoegen van een nieuwe schijf is makkelijker dan het vervangen van een defecte schijf. Helaas is het verwijderen van een schijf/osd net zo onhandig.

[Voor 5% gewijzigd door CAPSLOCK2000 op 05-10-2013 14:21]

This post is warranted for the full amount you paid me for it.


  • SadisticPanda
  • Registratie: Februari 2009
  • Niet online

SadisticPanda

Heet patatje :o

Ik ga vanaf ook beginnen te spelen met clustered filesystems en ik ben ook van plan om ceph es onder te loep te nemen. Ergens loop van volgende week, beschik ik over batch van tiental oudere pcs als tests opstelling. (Lees pentium 4 met 2gb ram en 80gb disks plus extra disks). Nuja meer dan genoeg voor test.

Probleem waar ik tegen aan kijk is, hoe laat ik dit systeem beste praten met niet native supported ceph os. Zoals bv windows of freebsd (geen fuse graag)

Rados mount en dan nfs of isci erover? Liefst in HA./ loadbalancing.

In local fiesystems vormt did niet echt problemen. Daar trek ik mijn plan mee, clustered is a whole new world.

Ik heb momenteel een FreeBSD HAST draaien (werk goed) maar enkel mirroring en niet evident om snel uit te breiden.

[Voor 8% gewijzigd door SadisticPanda op 06-10-2013 15:06]


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

NFS en/of iSCSI zou prima kunnen maar het voelt een beetje als een omweg. Ceph spreekt ook S3 (Amazon Storage) en Swift (OpenStack). Als je applicaties daar iets mee kunnen dan is dat een hele mooie oplossing.

This post is warranted for the full amount you paid me for it.


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
CAPSLOCK2000 schreef op maandag 07 oktober 2013 @ 15:25:
NFS en/of iSCSI zou prima kunnen maar het voelt een beetje als een omweg. Ceph spreekt ook S3 (Amazon Storage) en Swift (OpenStack). Als je applicaties daar iets mee kunnen dan is dat een hele mooie oplossing.
Juist!

Te veel mensen hangen nog in het idee dat ze NFS of iets dergelijke nodig hebben om bestanden te delen tussen machines, maar ik zou dat juist zo veel mogelijk vermijden en een object store gebruiken.

Overigens heeft tgt (iSCSI) wel de optie om RBD images als backend te gebruiken bij een iSCSI LUN, maar echt snel is het niet vanwege allemaal synchrone I/O.

  • SadisticPanda
  • Registratie: Februari 2009
  • Niet online

SadisticPanda

Heet patatje :o

yeah, klopt de S3/swift connectie had ik ook en is super handig als je applicatie het ondersteund. Ik ben helaas aan het uitzoeken inhoeveer ceph bv me kan dienen. De hoeveelheid aangeboden CFS-systemen is immens en ben ze allemaal beetje aan het bekijken.

Ik wil bijvoorbeeld dat de cluster kan ingezet worden bv als pure raw storage voor windows/linux/BSD/solaris systemen (blijft er niet veel keuze dan isci/NFS/CIFS).

Dus ik vrees dat er altijd een omweg zal nodig zijn. (of is ceph niet wat ik zoek, andere suggesties zijn ook welkom)

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Die tgt met RBD-backing ziet er interessant uit maar is misschien nog een beetje te nieuw.

This post is warranted for the full amount you paid me for it.


Anoniem: 193142

Inmiddels hebben we het Ceph cluster draaien. Wel met iets meer TB (bruto: 160, netto: 80) dan in eerste instantie gepland, maar we kunnen er in ieder geval weer even tegen.

Voor de geïnteresseerden, zie de build mijn inventaris of in deze post: http://gathering.tweakers.net/forum/view_message/41024434

  • renekluitenberg
  • Registratie: Oktober 2013
  • Laatst online: 23-11-2019
Het is inmiddels al weer een jaar geleden dat ik er mee heb gewerkt, maar we hadden destijds een Ceph opstelling draaien voor een HA ProxMox cluster. De performance viel op dat moment tegen in onze ogen, maar twee maand later viel de SAN om dus wellicht dat daar toen al problemen mee waren.

Wil binnenkort wel weer eens met wat servers gaan testen.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
renekluitenberg schreef op vrijdag 11 oktober 2013 @ 23:30:
Het is inmiddels al weer een jaar geleden dat ik er mee heb gewerkt, maar we hadden destijds een Ceph opstelling draaien voor een HA ProxMox cluster. De performance viel op dat moment tegen in onze ogen, maar twee maand later viel de SAN om dus wellicht dat daar toen al problemen mee waren.

Wil binnenkort wel weer eens met wat servers gaan testen.
Je richtte je denk ik vooral op de performance van één enkele VM?

Ceph repliceert en dat merk je in de latency, je zal vooral zien dat de parallele performance hoog ligt, maar niet zo zeer die van één enkele VM.

  • ppl
  • Registratie: Juni 2001
  • Niet online
Snow_King schreef op maandag 07 oktober 2013 @ 15:27:
Te veel mensen hangen nog in het idee dat ze NFS of iets dergelijke nodig hebben om bestanden te delen tussen machines, maar ik zou dat juist zo veel mogelijk vermijden en een object store gebruiken.
Nee, sommige mensen hangen teveel in het idee dat een bepaalde techniek het walhalla is en met iedereen en alles fatsoenlijk werkt. De realiteit is heel wat weerbarstiger. Ceph is leuk voor Linux maar als je dat niet gebruikt is het al heel wat minder interessant t.o.v. iets als NFS. Welke techniek het beste is wordt nou eenmaal bepaald door heel veel parameters. Uiteindelijk gaat het erom dat iets werkt in jouw omgeving, niet dat je techniek X gebruikt. Als je iets toepast is het wel handig om te kijken naar wat je al hebt want het is goed mogelijk dat dit datgene wat je op het oog hebt al kan. Dat is dan veel eenvoudiger dan iets nieuws op te gaan zetten. Als ik naar de features van Ceph kijk heb ik het idee dat het veel leuker is bij grote omgevingen. Voor de kleinere kun je de reeds bestaande technieken ook prima gebruiken.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
ppl schreef op zaterdag 12 oktober 2013 @ 15:54:
[...]

Nee, sommige mensen hangen teveel in het idee dat een bepaalde techniek het walhalla is en met iedereen en alles fatsoenlijk werkt. De realiteit is heel wat weerbarstiger. Ceph is leuk voor Linux maar als je dat niet gebruikt is het al heel wat minder interessant t.o.v. iets als NFS. Welke techniek het beste is wordt nou eenmaal bepaald door heel veel parameters. Uiteindelijk gaat het erom dat iets werkt in jouw omgeving, niet dat je techniek X gebruikt. Als je iets toepast is het wel handig om te kijken naar wat je al hebt want het is goed mogelijk dat dit datgene wat je op het oog hebt al kan. Dat is dan veel eenvoudiger dan iets nieuws op te gaan zetten. Als ik naar de features van Ceph kijk heb ik het idee dat het veel leuker is bij grote omgevingen. Voor de kleinere kun je de reeds bestaande technieken ook prima gebruiken.
Ik denk dat je mijn punt niet begrijpt, want NFS heeft wel degelijk problemen in veel situaties.

Zo wordt NFS vaak enkel gebruikt als een 'dump' om wat files (bijv facturen) op te slaan en te delen tussen webservers.

Het probleem met NFS is, het is je SPOF! Je kan wel hele fancy dingen doen met HA, VRRP, KeepAlived, echter als de NFS hangt, dan gaat je kernel ook per direct blocken.

Alle I/O richting de NFS server resulteert in processen in status D.

Het voordeel aan data zoals facturen over HTTP ophalen is dat het allemaal in userspace gebeurd en je ook degelijke loadbalancing en andere slimme technieken kan toepassen om je files op te halen.

Met proxy's kan je verkeer allerlei kanten op sturen wat met NFS niet kan.

NFS wordt te vaak misbruikt waar men denkt een shared filesystem nodig te hebben wat niet het geval is.

  • ppl
  • Registratie: Juni 2001
  • Niet online
Ik snap prima wat je bedoelt maar jij begrijpt mijn punt niet. Dat komt doordat je de verkeerde denkwijze erop nahoudt. Je bent nu de beste techniek aan het zoeken terwijl je dat nooit en te nimmer moet doen. Je omgeving dicteert wat je kunt gebruiken. Als er beslist is om alles op FreeBSD te doen is Ceph gewoon geen optie en NFS wel. Waarom? Omdat Ceph tot dusver Linux-only is en NFS juist niet. Leuk dat iets beter in elkaar steekt dan iets anders maar het gaat er nou juist om dat je het wel moet kunnen toepassen. Dat kunnen toepassen is vaak wat het gebruik van bepaalde zaken tegenhoudt en waardoor men nog bij "ouderwetse" zaken als NFS blijft hangen. Daarnaast geldt er op dit moment ook nog eens het leeftijdsverschil tussen de technologieën. Ceph is erg nieuw (1e stable in juli 2012!) terwijl NFS al heel wat jaren mee gaat. Bekendheid en complexiteit zijn andere zaken die een zeer belangrijke rol spelen in de keuze om voor een bepaalde technologie te gaan.

Kortom, er zijn voldoende legitieme redenen om bij iets als NFS te blijven en juist niet voor Ceph te gaan. Het is dan ook volledig onterecht om te stellen dat mensen niet weten waar ze mee bezig zijn. Het niet kiezen voor Ceph laat eerder zien dat je weet wat je doet omdat je niet op de eerste de beste nieuwe technologie springt die er maar voorbij komt (Ceph is niet de eerste). Het halleluja verkondigen over een of andere technologie is het domein van een manager, niet van een techneut.

Btw, ook bij Ceph heb je last van SPOF. Dat is bij vrijwel iedere technologie zo en kun je nooit zonder krijgen. Het is dan ook een kwestie van kijken of de SPOF(s) in kwestie acceptabel zijn of niet. Je kunt nou eenmaal niet alles afdekken. Zolang mensen nog configuratiefouten maken kun je ook met iets als Ceph in de penarie komen. Ook allemaal weer zaken die een rol spelen bij het kiezen van wat je gaat gebruiken.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
ppl schreef op maandag 14 oktober 2013 @ 22:48:
Ik snap prima wat je bedoelt maar jij begrijpt mijn punt niet. Dat komt doordat je de verkeerde denkwijze erop nahoudt. Je bent nu de beste techniek aan het zoeken terwijl je dat nooit en te nimmer moet doen. Je omgeving dicteert wat je kunt gebruiken. Als er beslist is om alles op FreeBSD te doen is Ceph gewoon geen optie en NFS wel. Waarom? Omdat Ceph tot dusver Linux-only is en NFS juist niet. Leuk dat iets beter in elkaar steekt dan iets anders maar het gaat er nou juist om dat je het wel moet kunnen toepassen. Dat kunnen toepassen is vaak wat het gebruik van bepaalde zaken tegenhoudt en waardoor men nog bij "ouderwetse" zaken als NFS blijft hangen. Daarnaast geldt er op dit moment ook nog eens het leeftijdsverschil tussen de technologieën. Ceph is erg nieuw (1e stable in juli 2012!) terwijl NFS al heel wat jaren mee gaat. Bekendheid en complexiteit zijn andere zaken die een zeer belangrijke rol spelen in de keuze om voor een bepaalde technologie te gaan.

Kortom, er zijn voldoende legitieme redenen om bij iets als NFS te blijven en juist niet voor Ceph te gaan. Het is dan ook volledig onterecht om te stellen dat mensen niet weten waar ze mee bezig zijn. Het niet kiezen voor Ceph laat eerder zien dat je weet wat je doet omdat je niet op de eerste de beste nieuwe technologie springt die er maar voorbij komt (Ceph is niet de eerste). Het halleluja verkondigen over een of andere technologie is het domein van een manager, niet van een techneut.

Btw, ook bij Ceph heb je last van SPOF. Dat is bij vrijwel iedere technologie zo en kun je nooit zonder krijgen. Het is dan ook een kwestie van kijken of de SPOF(s) in kwestie acceptabel zijn of niet. Je kunt nou eenmaal niet alles afdekken. Zolang mensen nog configuratiefouten maken kun je ook met iets als Ceph in de penarie komen. Ook allemaal weer zaken die een rol spelen bij het kiezen van wat je gaat gebruiken.
Ik heb het in dit geval niet enkel over Ceph, maar in een bredere zin.

Shared filesystems zoals NFS worden wel degelijk misbruikt door zaken in kernel-space te laten afhandelen die je in user-space veel beter kan doen.

Of je nu Ceph of een andere Object Store gebruikt, als je het in userspace gebruikt kan je veel beter acteren op hangs danwel niet reagerende machines.

In kernelspace hangt je fread() of fwrite() gewoon eindeloos en kan je daar geen timeouts omheen bouwen.

Dat is gewoon een groot nadeel van zaken in kernelspace uitvoeren en een shared filesystem.

  • ppl
  • Registratie: Juni 2001
  • Niet online
Jij leeft in een utopie terwijl de rest van de wereld dat niet doet. Dat betekent dat er bepaalde keuzes gemaakt moeten worden. Het gaat er uiteindelijk om dat je een goede en onderbouwde keuze maakt. Dat betekent dat je het gebruik van NFS ondanks al z'n nadelen kunt verantwoorden. Dat geldt natuurlijk voor ieder andere technologie want iedere technologie heeft nadelen en die zullen lang niet altijd voor iedere setup hetzelfde zijn.
Er zijn redenen waarom men voor Ceph kiest, er zijn redenen waarom men voor NFS kiest. Zonder enige kennis van die redenen kun je geen uitspraken doen. Doe ze dan ook niet.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
ppl schreef op vrijdag 18 oktober 2013 @ 14:53:
Jij leeft in een utopie terwijl de rest van de wereld dat niet doet. Dat betekent dat er bepaalde keuzes gemaakt moeten worden. Het gaat er uiteindelijk om dat je een goede en onderbouwde keuze maakt. Dat betekent dat je het gebruik van NFS ondanks al z'n nadelen kunt verantwoorden. Dat geldt natuurlijk voor ieder andere technologie want iedere technologie heeft nadelen en die zullen lang niet altijd voor iedere setup hetzelfde zijn.
Er zijn redenen waarom men voor Ceph kiest, er zijn redenen waarom men voor NFS kiest. Zonder enige kennis van die redenen kun je geen uitspraken doen. Doe ze dan ook niet.
Jij trekt wel een conclusie die érg kort door de bocht gaat.

Het lijkt alsof je je aangevallen voelt op het feit dat ik zeg dat NFS vaak misbruikt wordt.

Ik heb voldoende situatie gezien waar shared filesystems (en in de Linux wereld dus vaak NFS) wel degelijk misbruikt wordt voor iets waar het helemaal niet voor nodig is en enkel voor onnodige problemen zorgt, een goed voorbeeld is het delen van caches danwel PHP sessies waar Memcached en Redis veel beter zijn.

Logging over NFS heb ik ook vaak genoeg gezien of zelfs locks die men over NFS probeerde te doen waardoor hele applicaties gingen hangen.

Nee, ik heb wel degelijk genoeg gezien waar NFS misbruikt wordt.

Daaruit voort komt dat er veel te snel wordt gegrepen naar een shared filesystem en wat ik ook zie gebeuren met CephFS.

Mensen die Virtuele Machines vanaf CephFS willen gaan draaien waar RBD (Rados Block Device) volledig in userspace direct aan KVM kan worden gekoppeld. Daarmee ga je weer volledig langs kernelspace wat qua stabiliteit een stuk fijner is.

Anoniem: 193142


  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Ik vraag me af of er iemand hier is die iets met Ceph doet. Ik vind het zelf wel erg interessant. Met erasure encoding kun je nu RAID-style je data over de nodes distribueren. Dus nu is het echt mogelijk om schaalbare storage te bouwen die relatief betaalbaar is.

Heb zelf een test clustertje opgezet onder vmware workstation, maar dat performed voor geen fluit (storage op single gigabit). Maar het werkt wel. Echt heel erg leuk speelgoed voor wie interesse heeft in big storage.

HP Microservers Te Koop


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

We hebben het hier intern getest en waren er erg enthousiast over. Het project is uiteindelijk afgeketst, deels omdat Openstack niet door ging, deels omdat het niet wordt ondersteund door VMWare en deels om andere redenen.
De perfomance was uitstekend. Wij draaiden het wel op dedicated hardware met enkele tientallen schijven er achter. Daar staat tegenover dat de meeste van die hardware wel 10 jaar oud was. We kwamen vrij aardig in de buurt van de volledige snelheid van al die schijven.

This post is warranted for the full amount you paid me for it.


  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Leuk om te horen. VMware support etc zit er nog steeds niet in. Block storage lijkt wel stabiel en in een Linux-omgeving heb je dan aan het hele rados verhaal voldoende. Voor vmware achtige zooi moet je eigenlijk distributed iSCSI support hebben en dat is er nog steeds niet. Als Ceph iSCSI support doet en mature/stabiel is dan kan de hele SAN-industrie gewoon naar huis toe.

HP Microservers Te Koop


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

We hebben wel overwogen om er zelf isci- of FC-heads voor te zetten maar dan raak je weer een deel van de voordelen kwijt en je maakt je systeem ingewikkelder.

This post is warranted for the full amount you paid me for it.


  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

CAPSLOCK2000 schreef op maandag 09 maart 2015 @ 18:57:
We hebben wel overwogen om er zelf isci- of FC-heads voor te zetten maar dan raak je weer een deel van de voordelen kwijt en je maakt je systeem ingewikkelder.
Tja, groot gelijk. Volgens mij zoeken jullie met name shared storage, dus die block devices, het stukje wat wel goed werkt sinds lange tijd en wat zou integreren in jullie Linux platform, heeft niet zoveel waarde, klopt dat?

HP Microservers Te Koop


  • Bigs
  • Registratie: Mei 2000
  • Niet online
Een goeie multipath iSCSI/FC(oE) oplossing voor Ceph zou imo echt killer zijn. Het staat wel op de Ceph Enterprise roadmap, maar echt veel details komen er niet naar buiten. Ik heb wel gekeken naar oplossingen met LIO en stgt, maar qua multipath is dat sowieso allemaal een groot vraagteken en de integratie met RBD lijkt ook nog niet echt stabiel.

We hebben aan het begin van het jaar hier wel even gekeken naar een Proxmox+Ceph oplossing, maar hebben toch gekozen voor een traditioneel FC SAN + VMWare omdat dat een oplossing is waarvan je zeker weet dat hij gewoon werkt. Toch blijf ik Ceph wel in de gaten houden.. zeker als CephFS met meerdere metadata servers stabiel wordt zie ik allerlei use cases.

Ceph kent ook wel nadelen: veel abstractie lagen (XFS+journal -> OSD+journal en dan bv. weer XFS+journal op je RBD device), de ingewikkelde installatie van RADOSGW (waarom niet gewoon een lichtgewicht daemon ipv een FastCGI module in een webserver?) en het toch wel vrij complexe beheer (of je moet het niet erg vinden om elke keer op te zoeken hoe je een OSD vervangt en je CRUSH map aanpast e.d.).

Wat betreft dat laatste heb ik al wel gave voorbeelden gezien van mensen die alles in Puppet automatiseren waardoor er automatisch een OSD wordt gemaakt als je een nieuwe schijf in een server plaatst etc. Vette shit.

  • begintmeta
  • Registratie: November 2001
  • Niet online
Wilde men in DragonflyBSDs HAMMER2 niet ook zoiet doen? Wat komt daar eigenlijk van?

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Q schreef op maandag 09 maart 2015 @ 20:02:

Tja, groot gelijk. Volgens mij zoeken jullie met name shared storage, dus die block devices, het stukje wat wel goed werkt sinds lange tijd en wat zou integreren in jullie Linux platform, heeft niet zoveel waarde, klopt dat?
Openstack en andere op Linux gebaseerde virtualisatieomgevingen werken prima samen met Ceph. Die spreken direct het ceph-protocol (dus niet via de blockdevices) en dat werkt uitstekend. VMWare helaas niet, daarom hebben we nog overwogen om er iSCSI of iets dergelijks voor te zetten

This post is warranted for the full amount you paid me for it.


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Bigs schreef op maandag 09 maart 2015 @ 20:12:
en het toch wel vrij complexe beheer (of je moet het niet erg vinden om elke keer op te zoeken hoe je een OSD vervangt en je CRUSH map aanpast e.d.).
Wij losten dat op met udev en een klein scriptje. Dat werkte uitstekend.

This post is warranted for the full amount you paid me for it.


  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Ik blijf het toch erg interessant vinden allemaal. Ik draai nu een proef met 4 OSD hosts in een virtuele opstelling, maar ik zou wel willen zien hoe de zooi op echte hardware presteert. Misschien maar eens kijken naar een setje betaalbare nodes (proliant microserver?). Weet ik nog een goede besteding voor mijn vakantie geld ;)

[Voor 3% gewijzigd door Q op 09-03-2015 20:41]

HP Microservers Te Koop


  • Bigs
  • Registratie: Mei 2000
  • Niet online
CAPSLOCK2000 schreef op maandag 09 maart 2015 @ 20:25:
[...]

Wij losten dat op met udev en een klein scriptje. Dat werkte uitstekend.
Klopt, maar als je dan na 1,5 jaar ineens iets moet troubleshooten heb je geen idee hoe het eigenlijk ook alweer werkt. Met iets complex als Ceph vind ik dat wel gevaarlijk. Vandaar dat ik het pas echt zal overwegen als ik weet dat er iemand een paar uur per maand mee werkt zodat de kennis warm blijft.

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Als je het zo bekijkt dan zijn al die abstracties juist een voordeel. Het zijn namelijk abstracties over bestaande Linux-technologie. Mijn ervaring met Ceph is misschien beperkt, maar met udev, xfs en apache kan ik prima uit de voeten. Die kennis blijft ook warm omdat ik die techniek ook op andere plekken gebruik.

This post is warranted for the full amount you paid me for it.


  • Bigs
  • Registratie: Mei 2000
  • Niet online
Goed daar zit wat in.. het koppelt inderdaad allerlei bestaande bouwstenen aan elkaar op een manier die wellicht complex is (placement groups, CRUSH maps) maar wel inzichtelijk.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Q schreef op maandag 09 maart 2015 @ 17:20:
Ik vraag me af of er iemand hier is die iets met Ceph doet. Ik vind het zelf wel erg interessant. Met erasure encoding kun je nu RAID-style je data over de nodes distribueren. Dus nu is het echt mogelijk om schaalbare storage te bouwen die relatief betaalbaar is.

Heb zelf een test clustertje opgezet onder vmware workstation, maar dat performed voor geen fluit (storage op single gigabit). Maar het werkt wel. Echt heel erg leuk speelgoed voor wie interesse heeft in big storage.
Ik werk als Ceph consultant en heb inmiddels tientallen Ceph deployments gedaan, van klein, tot groot (PetaBytes) in grootte.

Het kent een flinke leercurve, maar als je native RBD/RADOS spreekt, dan is het iets wat gigantisch schaalt en performed.

De grootste omgeving die ik ken (niet gebouwd heb) is 70PB in grootte, bestaat uit 1600 fysieke machines met 25600 disks in totaal.

iSCSI e.d. moet je vergeten, dat zal niet performen en het ook nooit doen. Ceph is gemaakt voor parallele I/O en zolang je alle I/O eerst door een iSCSI Gateway heen trekt gaat dat hele voordeel verloren.

Inmiddels wordt er op de achtergrond zo ver ik weet wel gewerkt aan native RBD in VMWare, maar wanneer dat er gaat komen weet ik niet.

Je kan ook kijken naar RHEV van Red Hat, daar zit Ceph met RBD al een tijdje in. Bied veel features die mensen ook willen hebben.

  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Gave job! Ik begrijp wel nu je er op wjist dat iSCSI nooit zal schalen, je wilt native cluster clients hebben want anders heb je eigenlijk gewoon niets aan je cluster qua schaalbaarheid en reliability.

Je kunt met iSCSI wel iets bouwen waarbij je multipathing hebt en multiple ips voor fault-tollerance, maar je hangt dan altijd aan een aantal specifieke hosts en dat is precies wat je niet wilt.

Ceph is nu van Red Hat, dus ik neem aan dat jij als consultant bij klanten RH/SUSE neerzet? Of wordt je om redenen gedwongen om zelf iets in elkaar te boetseren? Niet dat ik je concurrent kan/ga worden, ik heb afgelopen zondag voor het eerst een test clustertje opgezet, maar ik ben benieuwd wat nu de contex is.

70 PB is absoluut onvoorstelbaar.

Wat ik me afvraag is dat een Ceph cluster dan als cluster zelf een soort van SPOF wordt, een bug in de Ceph code = nu nog sneller 70 PB aan data kwijt raken. Het upgraden van componenten lijkt mij best wel scary shit, zelfs al wordt het gesupport door de vendor.

Dus wordt er naast het productie cluster ook een test/acceptatie cluster er naast gedraaid, op kleinere schaal?

[Voor 48% gewijzigd door Q op 10-03-2015 12:22]

HP Microservers Te Koop


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Q schreef op dinsdag 10 maart 2015 @ 11:49:
Gave job! Ik begrijp wel nu je er op wjist dat iSCSI nooit zal schalen, je wilt native cluster clients hebben want anders heb je eigenlijk gewoon niets aan je cluster qua schaalbaarheid en reliability.

Je kunt met iSCSI wel iets bouwen waarbij je multipathing hebt en multiple ips voor fault-tollerance, maar je hangt dan altijd aan een aantal specifieke hosts en dat is precies wat je niet wilt.
Je kan iSCSI prima voor applicaties gebruiken die native geen RBD praten, maar dat schaalt gewoon niet goed door.
Q schreef op dinsdag 10 maart 2015 @ 11:49:Ceph is nu van Red Hat, dus ik neem aan dat jij als consultant bij klanten RH/SUSE neerzet? Of wordt je om redenen gedwongen om zelf iets in elkaar te boetseren? Niet dat ik je concurrent kan/ga worden, ik heb afgelopen zondag voor het eerst een test clustertje opgezet, maar ik ben benieuwd wat nu de contex is.
Ceph is niet van Red Hat, het bedrijf er achter, Inktank is gekocht door Red Hat.

In Ceph zitten commits van mij, van mensen uit de hele wereld. Het is GPLv2 en daarmee van "iedereen".

Ik werk verder niet voor Red Hat, dus ik deploy op RHEL, CentOS, SUSE en Ubuntu, dat maakt mij weinig uit.
Q schreef op dinsdag 10 maart 2015 @ 11:49:70 PB is absoluut onvoorstelbaar.
70.000TB 8)
Q schreef op dinsdag 10 maart 2015 @ 11:49:Wat ik me afvraag is dat een Ceph cluster dan als cluster zelf een soort van SPOF wordt, een bug in de Ceph code = nu nog sneller 70 PB aan data kwijt raken. Het upgraden van componenten lijkt mij best wel scary shit, zelfs al wordt het gesupport door de vendor.
Klopt, dat is inderdaad ook scary. Je moet per omgeving altijd afvragen of je dat wel wil.
Q schreef op dinsdag 10 maart 2015 @ 11:49:Dus wordt er naast het productie cluster ook een test/acceptatie cluster er naast gedraaid, op kleinere schaal?
Uiteraard draaien daar preflight clusters waar dingen eerst in gaan alvorens productie.

  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Ik heb nu een erasure encoded pool gemaakt met daarvoor een replicated pool als 'cache'. Dit is nodig omdat je een EC pool niet rechtstreeks als block storage kunt gebruiken helaas.

Het valt me op dat ik bij een read-only op de data ook heel veel schrijf activiteit zie. Ik vraag me af wat dit is. Een verklaring kan zijn dat data die gelezen wordt van de EC pool eerst naar de replicatie pool wordt geschreven. Of anders, de data wordt wel direct aan de client geleverd, maar ook naar het cache weggeschreven. Dat geeft nogal wat dataverkeer en I/O.

HP Microservers Te Koop


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Q schreef op donderdag 12 maart 2015 @ 13:06:
Ik heb nu een erasure encoded pool gemaakt met daarvoor een replicated pool als 'cache'. Dit is nodig omdat je een EC pool niet rechtstreeks als block storage kunt gebruiken helaas.

Het valt me op dat ik bij een read-only op de data ook heel veel schrijf activiteit zie. Ik vraag me af wat dit is. Een verklaring kan zijn dat data die gelezen wordt van de EC pool eerst naar de replicatie pool wordt geschreven. Of anders, de data wordt wel direct aan de client geleverd, maar ook naar het cache weggeschreven. Dat geeft nogal wat dataverkeer en I/O.
De data gaat eerst van de EC pool naar de Replicated pool inderdaad.

Caching is zeker niet in alle gevallen sneller dan gewoon puur replicated draaien. Achter RBD zou ik het zeker niet toe passen.

  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Bedankt, dat maakt toepasssing van EC pools nog wel lastig. EC maakt storage juist zo efficient. Grappig dat recent backblaze ook met een post kwam over dat ze EC toepassen nu in hun cluster.

HP Microservers Te Koop


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Q schreef op vrijdag 13 maart 2015 @ 00:04:
Bedankt, dat maakt toepasssing van EC pools nog wel lastig. EC maakt storage juist zo efficient. Grappig dat recent backblaze ook met een post kwam over dat ze EC toepassen nu in hun cluster.
Wees je wel bewust dat niets gratis is. Recovery met EC is vele, maar dan ook vele malen zwaarder dan dat met een replicated pool.

Je moet namelijk alle andere chunks lezen om de verloren chunk te kunnen berekenen.

Niets is gratis.

  • init6
  • Registratie: Mei 2012
  • Niet online
Ben nu bezig met Giant 0.87-1.0 op een Centos 7 omgeving.

Ben vorige week begonnen met installeren van een Ceph omgeving, nu op het niveau dat Monitors draaien, placement groups clean zijn (wat je ook doet, verwijder 20 OSD's in de juiste volgorde heb ik geleerd :')), ik met rados en qemu-img data kan schrijven, disken kan koppelen aan vm's. Alleen rbd doet een beetje raar. Een voorbeeld: Als ik met rados een ls doe zie ik alle images en benchmarks en files welke ik geplaatst heb, gooi ik er een rbd ls tegen aan dan krijg ik direct de prompt terug zonder enige vorm van logs. Ik ga er maandag maar een strace tegen aan gooien voor de lol voor ik de boel opnieuw ga deployen. Het is geen keyring issue oid want met de client key en rados / qemu-img kan ik alle data uitlezen.

Vage resultaat is dus als ik een VM start de disk wel aanwezig is, ik kan er naar schrijven (zie data getransfereerd worden). Maar als de disk voorzien word van een partitie tabel of formateer de acties wel gedaan worden echter direct kan de VM deze data niet meer vinden. De data is geschreven, als ik de disks converteer kan ik data uitlezen..

Iemand eens van gehoord? Ben wel nieuwsgierig wat dit kan veroorzaken, er is een sterk vermoeden dat dit gewoon een opstart issue is omdat ik veel heb zitten pielen met keyrings, pools.

:) Volgende week ga ik met de crush map spelen en wat tuning, haal maar 500M/s per schrijf actie :P.

  • Q
  • Registratie: November 1999
  • Laatst online: 08-12 19:10

Q

Au Contraire Mon Capitan!

Leuk dat je er ook mee aan het testen bent. Ik heb een paar goedkope servertjes gekocht om op native hardware te testen. Ga in de komende weken wat proberen op te zetten en kijken wat de performance wordt van de verschillende configuraties.

HP Microservers Te Koop


  • init6
  • Registratie: Mei 2012
  • Niet online
'oplossing' voor het probleem met rbd: Heb ceph firefly neergezet op een Centos7 omgeving. Werkt prima.

Iemand ervaring met Crush maps aanpassen terwijl je productie draait?

[Voor 26% gewijzigd door init6 op 31-03-2015 13:47]


  • init6
  • Registratie: Mei 2012
  • Niet online
Inmiddels heb ik een Ceph cluster draaien in beta en heb de volgende tool neergezet om het geheel te monitoren:
https://github.com/Crapworks/ceph-dash

Deze heb ik op onze monitoring server gezet (de tool is licht en heeft enkel een read only keyring nodig) en hiertegen doe ik checks om te zien wat de cluster status is (ipv tegen 3 monitors).

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
init6 schreef op donderdag 09 juli 2015 @ 20:42:
Inmiddels heb ik een Ceph cluster draaien in beta en heb de volgende tool neergezet om het geheel te monitoren:
https://github.com/Crapworks/ceph-dash

Deze heb ik op onze monitoring server gezet (de tool is licht en heeft enkel een read only keyring nodig) en hiertegen doe ik checks om te zien wat de cluster status is (ipv tegen 3 monitors).
Leuk dashboard ja! (Heb er nog een paar commits in)

Gebruik hem ook om enkele cluster te monitoren. Schaalt ook mooi op mobiele apparaten.

  • init6
  • Registratie: Mei 2012
  • Niet online
Snow_King schreef op dinsdag 10 maart 2015 @ 12:57:

[...]
Uiteraard draaien daar preflight clusters waar dingen eerst in gaan alvorens productie.
Helaas is mijn ervaring met clustered storage dat sommige bugs zich pas voordoen bij hoeveelheden data welke je niet zomaar even ter beschikking hebt in een test omgeving.

  • bartvb
  • Registratie: Oktober 1999
  • Laatst online: 17:25
Nice! Een Ceph topic :)
Had ik eerder moeten vinden, binnenkort eens bijlezen. *bookmarked*

Wij hebben Ceph nu een tijdje draaien, alles up and running krijgen was best een uitdaging. Ik vind het echt een erg mooi systeem, maar de documentatie is 'suboptimaal' zullen we maar zeggen. Vooral Ansible scripts door zitten pluizen om uit te vinden wat er nou moet gebeuren om een cluster up & running te krijgen.

Maar is uiteindelijk na een hoop experimenteren gelukt en draait allemaal prima tot nu toe. Nu is er alleen een disk overleden en het vervangen van een disk lijkt bijna een dagtaak. Enige dat ik daarover kan vinden op Ceph.org is:

http://ceph.com/planet/ad...d-disk-in-a-ceph-cluster/

Ik hoop dat dit sinds 2014 makkelijker is geworden?

Heb ook dit gevonden:
https://www.couyon.net/blog/swapping-a-failed-ceph-osd-drive

Dat ziet er een heel stuk eenvoudiger en logischer uit. Iemand daar ervaring mee?

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 15:45

Kees

Serveradmin / BOFH / DoC
Zo moeilijk is een disk vervangen toch niet? Wat ik uit die eerste link haal is:
- lokeer de juiste osd
- gooi die osd eruit
- vervang de disk
- zet een nieuwe osd op met die disk

Ik heb zelf nu ook sinds begin dit jaar een ceph cluster draaien voor deze website, draait nog in test, maar ziet er goed uit :)

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


  • bartvb
  • Registratie: Oktober 1999
  • Laatst online: 17:25
Het is niet moeilijk maar wel een hoop gedoe/stappen. Wat maintenance betreft is het vervangen van een disk toch wel een van de meest voorkomende acties lijkt me.
Ook verandert de structuur van het cluster niet dus het helemaal verwijderen van de OSD voelt vreemd. Daarom lijkt die tweede optie (maak nieuwe OSD aan door prepare te doen met de oude UUID) veel logischer.

Vooral benieuwd dus of hierin iets is veranderd/verbeterd. Hier:

https://access.redhat.com...ide/changing_an_osd_drive

Staat ongeveer hetzelfde verhaal als op ceph.com maar dan iets leesbaarder.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
bartvb schreef op dinsdag 21 maart 2017 @ 09:34:
Het is niet moeilijk maar wel een hoop gedoe/stappen. Wat maintenance betreft is het vervangen van een disk toch wel een van de meest voorkomende acties lijkt me.
Ook verandert de structuur van het cluster niet dus het helemaal verwijderen van de OSD voelt vreemd. Daarom lijkt die tweede optie (maak nieuwe OSD aan door prepare te doen met de oude UUID) veel logischer.

Vooral benieuwd dus of hierin iets is veranderd/verbeterd. Hier:

https://access.redhat.com...ide/changing_an_osd_drive

Staat ongeveer hetzelfde verhaal als op ceph.com maar dan iets leesbaarder.
Het staat wel op de planning om een soort 'replace' te maken met ceph-disk, maar dat is niet heel makkelijk.

Ceph is nu eenmaal anders dan een ouderwets RAID systeem en vereist daarom soms iets meer werk.

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Herkenbaar, ik vreesde ook dat het veel gedoe zou zijn maar als je hardware maar een beetje voorspelbaar is dan is het proces prima te automatiseren.

This post is warranted for the full amount you paid me for it.


  • init6
  • Registratie: Mei 2012
  • Niet online
Snow_King schreef op dinsdag 21 maart 2017 @ 20:44:
[...]

Het staat wel op de planning om een soort 'replace' te maken met ceph-disk, maar dat is niet heel makkelijk.

Ceph is nu eenmaal anders dan een ouderwets RAID systeem en vereist daarom soms iets meer werk.
Inmiddels kan ik ook mee praten in dat het een flink stuk complexer is dan een raid systeem...

Helaas is mijn eerdere post werkelijkheid in onze setup geworden:
init6 schreef op vrijdag 17 juli 2015 @ 16:29:
[...]

Helaas is mijn ervaring met clustered storage dat sommige bugs zich pas voordoen bij hoeveelheden data welke je niet zomaar even ter beschikking hebt in een test omgeving.
We hebben een aantal ceph clusters in house draaien, ander team heeft geen issues maar wij ervaren stormen van heartbeat verkeer welke zowel front als back network niet meer reageert. Nu is Ceph strenger geworden op issues met OSD's in Jewel en gooit het disken uit het cluster als ze zoveel attempts niet terug keren waardoor we een paar honderd disken zijn verloren in een paar minuten tijd. Hebben letterlijk een thundering herd issue gehad, how awesome. :)

Van memory, disks tot netwerk heb ik uitgeplozen: Alles ziet er normaal uit, op 1 melding na. Het mooie is: Het is intermittent en beweegt zich at random 1-2x per week over ons cluster heen. Debug in Ceph levert een hoop logs op kan ik je vertellen... Meer dan onze hadoop setup.

[Voor 56% gewijzigd door init6 op 22-03-2017 08:28]


  • Bigs
  • Registratie: Mei 2000
  • Niet online
Ceph beheer lijkt mij vrij specialistisch. Wij hebben er kort naar gekeken als VM storage, maar na wat experimenten heb ik moeten concluderen dat het niet is is 'wat je erbij doet'. Overigens geldt dat voor de grote traditionele storage systemen net zo goed.

Er was een paar jaar geleden wel sprake van tooling via Puppet die bij een hardware wijziging (plaatsen/uitnemen van een schijf in een server) automatisch een OSD aanmaakt/verwijdert etc., is dat ooit nog wat geworden?

  • init6
  • Registratie: Mei 2012
  • Niet online
Bigs schreef op woensdag 22 maart 2017 @ 08:19:
Ceph beheer lijkt mij vrij specialistisch. Wij hebben er kort naar gekeken als VM storage, maar na wat experimenten heb ik moeten concluderen dat het niet is is 'wat je erbij doet'. Overigens geldt dat voor de grote traditionele storage systemen net zo goed.

Er was een paar jaar geleden wel sprake van tooling via Puppet die bij een hardware wijziging (plaatsen/uitnemen van een schijf in een server) automatisch een OSD aanmaakt/verwijdert etc., is dat ooit nog wat geworden?
Een disk eruit halen is het probleem niet, het zijn 4-5 acties die je moet doen naast het fysiek swappen van de disk. In ons geval heeft Ceph sinds 2015 tot begin 2017 zonder enige hickup gedraaid, nu hebben we issues die wat complexer zijn. Resultaat is dat je dan ook meer tijd besteed, zodra die opgelost zijn zal ik eens per paar weken weer een diskje moeten vervangen. Niet het meeste werk.

Het belangrijkste in een ceph cluster is planning hoe je het geheel opzet, ik heb destijds een maand uitgetrokken en na 4x een herinstall stond ons productie cluster. Goed nadenken over je setup, vooral welke hardware er in moet, is eigenlijk het belangrijkste.

[Voor 14% gewijzigd door init6 op 22-03-2017 08:32]


  • bartvb
  • Registratie: Oktober 1999
  • Laatst online: 17:25
Disk wisselen viel idd nogal mee. Die blogpost is vooral bijzonder wazig :)

Verder erg blij met Ceph. Vandaag moest er een disk worden gewisseld maar ook de stroomfeeds moesten worden vervangen. Niet alle servers hebben een redundante voeding dus er moest het e.e.a. worden uitgeschakeld. Dat liep even niet helemaal volgens het vooraf bedachte plan en toen we klaar waren bedacht ik me pas dat ik daardoor helemaal vergeten was om Ceph in maintenance mode te zetten (ceph osd set noout) :o

Dat was even een flink stressmoment. Zag al gebeuren dat Ceph weigerde om de weer ingeschakelde nodes te accepteren als valid data. Bergen resync en kans op verloren data. Maar niets van dat alles :) Geen diee hoe Ceph het gedaan heeft maar helemaal niets raars tijdens of na het onderhoud. Nice!

Resync duurt wel eventjes. 1 disk vervangen waar zo'n 330GB heen moet en dat lijkt zo'n 6 uur te gaan duren. Maar is geen probleem, alles draait ondertussen zonder hiccups door.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Gaan er nog Tweakers naar de Ceph Day in Ede op 20 September?

http://ceph.com/cephdays/netherlands2017/

  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 16:34

CAPSLOCK2000

zie teletekst pagina 888

Goed moment om er over te beginnen, er is bij ons net weer wat momentum om naar een CEPH-oplossing te kijken. Het maar het programma voor die dag is wel een beetje leeg...

This post is warranted for the full amount you paid me for it.


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Programma volgt nog begreep ik, zijn ze nog druk mee bezig.

Ceph days zijn altijd wel boeiend

  • c-nan
  • Registratie: Juni 2008
  • Laatst online: 23:45
Snow_King schreef op donderdag 24 augustus 2017 @ 10:13:
Gaan er nog Tweakers naar de Ceph Day in Ede op 20 September?

http://ceph.com/cephdays/netherlands2017/
Volgens mij heb ik die week hele week cursus :(

Ben momenteel 2 clusters aan het bouwen, met ieder 3 mon + 4 nodes met per node 5x 1TB SSD. Bedoeling is om in 2018 Q2 aantal nodes en OSDs te verdubbelen.

  • axis
  • Registratie: Juni 2000
  • Laatst online: 01-07 14:24
Snow_King schreef op donderdag 24 augustus 2017 @ 10:13:
Gaan er nog Tweakers naar de Ceph Day in Ede op 20 September?

http://ceph.com/cephdays/netherlands2017/
Bedankt voor de tip! Heb me net ook aangemeld, ben wel benieuwd!

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Programma van de Ceph day staat inmiddels ook al tijdije online. Ik vind ze altijd wel boeiend, veel leuke talks.

Zelf erg benieuwd naar de CephFS update van John Spray.

De Luminous release is sowieso een hele mooie release.

[Voor 34% gewijzigd door Snow_King op 15-09-2017 08:02]


  • Bigs
  • Registratie: Mei 2000
  • Niet online
Wauw Luminous bevat inderdaad wel veel mooie ontwikkelingen. Tijd om weer eens met Ceph te gaan spelen, het laat me niet los en ik zou het graag eens ergens inzetten.

https://ceph.com/releases/v12-2-0-luminous-released/

  • init6
  • Registratie: Mei 2012
  • Niet online
Snow_King schreef op donderdag 24 augustus 2017 @ 10:13:
Gaan er nog Tweakers naar de Ceph Day in Ede op 20 September?

http://ceph.com/cephdays/netherlands2017/
Yep. Ik wil eens met wat mensen praten over de Jewel release. Ben er niet heel blij mee, hoop op wat tips.

  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
init6 schreef op vrijdag 15 september 2017 @ 12:58:
[...]

Yep. Ik wil eens met wat mensen praten over de Jewel release. Ben er niet heel blij mee, hoop op wat tips.
Ik heb weinig problemen met Jewel eigenlijk. Welke problemen loop je tegenaan?

  • init6
  • Registratie: Mei 2012
  • Niet online
Snow_King schreef op vrijdag 15 september 2017 @ 13:04:
[...]

Ik heb weinig problemen met Jewel eigenlijk. Welke problemen loop je tegenaan?
Massale heartbeat storms, dit zou wijzen op netwerk issues of netwerk split als ik alle blog posts mag geloven. Maar al mijn andere tools blijven gewoon verkeer versturen over deze netwerk verbindingen. Heb op een gegeven moment ook maar mijn monitoring tool gedraaid op de netwerken waar ceph op draait en heb geconfigureerd om elke seconde data te scrapen, geen enkel issue met het netwerk alleen de heartbeat storms houden aan. Het is op willekeurige momenten en bij elke belasting en lijkt vaker bij de weekly deep scrubs te zijn maar niet exclusief is het hieraan gerelateerd. Ook krijgen we op het moment dat deze heartbeat storms aanwezig zijn de melding van een xfs bug: attempt to access beyond end of device, alsof het een het andere triggert. De vraag is welke...

Sinds de update naar Jewel worden OSD's uit het cluster gegooid nadat ze meer dan 5x 300seconden niet reageren (of 300seconde). Met als hoogtepunt dat er 308 van de 450 OSD's op een zondag avond 5 uur uit gegooid werden. Wij dachten dat we safe waren met systemd, omdat deze de processen zou moeten bewaken en alle processes restarten bij fails. Echter werd alles netjes gereaped en het process word netjes afgesloten met een return code 0 dus dat was einde van het Ceph cluster toen.

Daarnaast hebben we sinds een paar weken op diverse OSD's de melding: replacing existing (lossy) channel (new one lossy=1). Oude bug reports melden dat dit is omdat er geen nieuwe file descriptor geopend kan worden. Resultaat was dat hierdoor het process blijft hangen en effectief alle pg's op die disk niet meer reageren, ceph detecteert dit niet dus je moet handmatig de betrokken OSD's een schop geven en dan is je cluster niet meer in stuck state.

Allemaal issues waar we in Hammer geen last van hadden.

  • init6
  • Registratie: Mei 2012
  • Niet online
Ben nu bezig met laatste Jewel release neerzetten: Tijdens het starten van een node worden zeer veel processen gestart zonder de processen af te wachten waar ze afhankelijk van zijn. Op een node waar 10 OSD's en 2 journals aanwezig zijn worden minstens 55 processen door elkaar opgestart. Er word tijdens het starten een:
/usr/bin/ceph-osd -f --cluster ceph --id 245 --setuser ceph --setgroup ceph
uitgevoerd terwijl een
/usr/bin/python /usr/sbin/ceph-disk --verbose activate /dev/sdi1
nog loopt. Het resultaat is dus falende disken, handmatige activates die je moet uitvoeren, chowns op de journal, systemctl reset-failed en daemon restarts tot alles weer in vorm is. Slordig, het is alleen jammer dat de alternatieven slechter zijn (uit mijn ervaringen met gluster)

  • Kees
  • Registratie: Juni 1999
  • Laatst online: 15:45

Kees

Serveradmin / BOFH / DoC
En ook True is over naar ceph \o/ https://www.true.nl/blog/object-storage-platform/

Gisteren ons cluster geupgraded naar luminous, blijf het verbazingwekkend vinden hoe soepel dat gaat. Updaten, reboot, alles werkt (bijna dan, moest 3 dingen aanpassen, maar dat waren warnings).

"Een serveradmin, voluit een serveradministrator, is dan weer een slavenbeheerder oftewel een slavendrijver" - Rataplan


  • Snow_King
  • Registratie: April 2001
  • Laatst online: 09-12 14:51

Snow_King

Konijn is stoer!

Topicstarter
Gaaf!

Denk er bij CephFS wel altijd aan om recente kernels te draaien op de clients, want dat is bij CephFS een belangrijk onderdeel.

Inmiddels ook al naar BlueStore toe?
Pagina: 1


Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee