Bekijk Volledige Versie : Ceph, an open source distributed file system
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 (http://ceph.newdream.net/) 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 (http://ceph.newdream.net/2010/03/rbd-rados-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.
Even snel de boel bekeken en gelezen en klinkt veel belovend. Als ik tijd heb eens kijken of ik een testsituatie kan opzetten. Ben benieuwd.
Heb er ongeveer een jaar geleden naar gekeken. Het Is ontwikkeld door de founder van Dreamhost, en ook vanuit die behoefte is Ceph ontstaan. Het is dus een techniek die bij uitstek voor ons hosters interessant is. Weet niet hoe het er nu bijstaat, maar destijds was het allemaal nog erg fragiel. Ben benieuwd naar je ervaringen Wido.
het is redelijk stabiel. Heb wel wat segfaults gezien, maar die heb ik gerapporteerd en zijn inmiddels ook gefixed.
Gebruik zelf de unstable git branch en daar wordt hard in ontwikkeld.
De performance kan beter, zeker op random IOps, maar bij een distributed filesystem betaal je altijd een penalty, je kan niet verwachten dat het even snel is als een local filesystem.
De access times zullen wat hoger liggen, maar daar staat dan wel weer tegenover dat je voor een individuele client in principe een 'unlimited' IOPS hebt (gegeven je cluster size).
Heb je de bijbehorende papers al gelezen? Die zijn erg interessant.
Ik ga er ook weer eens mee spelen, en misschien gelijk maar eens wat aan gaan coden.
Welke papers bedoel je? Ik heb al heel wat gelezen, maar kan altijd iets over het hoofd hebben gezien.
Helaas heb ik geen C/C++ kennis om bij te kunnen dragen, had het anders gedaan! Nu maar bugs jagen!
Volgens mij staan de meeste, of alle, op http://ceph.newdream.net/publications/
Laat ik dit dan nog eens een schop geven. Inmiddels zijn we al weer enkele maanden verder en heb ik een testcluster van 16 machines draaien sinds een maand of 3.
Ik heb er één woord voor: briljant!
Zit er nu zelf ook aardig diep in, zo heb ik voor RADOS een PHP extensie geschreven, te vinden op:
git://ceph.newdream.net/git/phprados.git (http://ceph.newdream.net/git/?p=phprados.git;a=summary)
Docu's: http://ceph.newdream.net/wiki/Phprados
Wat verder ook echt de moeite waar is: http://ceph.newdream.net/wiki/Kvm-rbd
Ben je lazy en draai je Ubuntu 10.04 en wil je testen met KVM-RBD? Zie dan: http://ceph.newdream.net/2010/08/rbd-rados-block-device-status/
Inmiddels heb ik ook een backported libvirt 0.8.3 voor 10.04 gemaakt met RBD snapshot support, te vinden op:
deb http://pcx.apt-get.eu/ubuntu lucid-backport unofficial
De patches zijn te vinden op: http://zooi.widodh.nl/ceph/qemu-kvm/
Hoewel ik het POSIX filesystem (Ceph) gaaf vind is dat imho nog verre van stabiel en productie klaar, maar RADOS en daarbij de RBD driver zijn toch al aardig stabiel.
Inmiddels heb ik al wat VM's vanaf RADOS draaien en al wat applicaties gemaakt die via phprados data opslaan en dat draait lekker stabiel.
Vragen? Shoot! Ben inmiddels zo'n 30 uur per week met dat spul bezig, testen, testen, testen (Is hard nodig!) Of kom langs op IRC #ceph op irc.oftc.net ( Archives (http://irclogs.ceph.widodh.nl/) )
Interessant, zelf geen tijd gehad om er echt uitgebreid mee bezig te gaan. Leuk dat je toch na een vrij lange periode je ervaringen nog post.
Er is veel over te vertellen, maar dat is ook omdat ik vind dat dit een van de meest revolutionaire Open Source projecten is van de laatste tijd. Want data opslag blijft toch nog altijd een drama om goed voor elkaar te krijgen, zeker als je met grote omgevingen te maken krijgt.
Het is zeker aan te raden om eens mee aan de slag te gaan.
Vroeg me af of het inmiddels ook stabiel draait met andere onderliggende bestandssystemen dan BTRFS.
Changelog suggereert dat het mogelijk is:
osd: new filestore, journaling infrastructure. (lower latency writes, btrfs no longer strictly required)
Maar wiki staat nog vol met BTRFS referenties.
Lijkt me niet zo'n veilig idee, gezien met de huidige implementatie het risico bestaat dat je bestandssysteem een stroomstoring niet overleeft ( http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05749.html )
btrfs no longer strictly required
Ja, het is mogelijk om bijvoorbeeld ext4 te gebruiken, maar bij de snapshot support leunen ze aardig op BTRFS, waardoor je op ext4 een mindere performance hebt.
Overigens heb ik inmiddels twee stroomstoringen overleeft met mijn Ceph cluster (met BTRFS) en geen data verloren. (2.6.35) (Hier geef ik verder geen garanties op! ;) )
BTRFS heeft nu eenmaal een aantal features (zoals de snapshots) die erg makkelijk om te gebruiken zijn voor Ceph.
Ik volg dit project met veel interesse. Zelf heb ik met systemen als NexentaStor (ZFS) gespeeld, maar dit begint echt op de heilige graal van storage te lijken. Volgens de developers en de roadmap moeten we een stabiele (productie?) versie verwachten binnen vier maanden. Denk jij dat dit ook haalbaar is? Dan wordt het echt tijd om hier eens wat hardware voor te gaan vinden.
Overigens heb ik inmiddels twee stroomstoringen overleeft met mijn Ceph cluster (met BTRFS) en geen data verloren. (2.6.35) (Hier geef ik verder geen garanties op! ;) )
<OT>Ga dan ook naar een ander DC ;) Aan de overkant van de straat zit er wel 1.</OT>
Bevalt Ceph beter dan de (andere) setups die jullie in productie gebruiken (incl. die jullie beheren voor klanten)?
T. Verhaeg
25/09/10, 21:52
Wido,
Moet bekennen dat het erg interessant uitzoek. In hoeverre ben jij te spreken over Ceph als vervanger voor jullie infrastructuur? Wellicht dat ik er binnenkort eens na ga kijken, heb echter niet zoveel resources als dat jij hebt maar dat mag de pret niet drukken :)
Ik wacht nog even tot deze feature is toegevoegd :): http://tracker.newdream.net/issues/86
Ik volg dit project met veel interesse. Zelf heb ik met systemen als NexentaStor (ZFS) gespeeld, maar dit begint echt op de heilige graal van storage te lijken. Volgens de developers en de roadmap moeten we een stabiele (productie?) versie verwachten binnen vier maanden. Denk jij dat dit ook haalbaar is? Dan wordt het echt tijd om hier eens wat hardware voor te gaan vinden.Ja, de holy grail lijkt het wel, maar ik denk wel dat het gebruik weggelegt blijft (Zeker in de begin fase) voor mensen die er echt veel kennis van hebben. Het is namelijk niet zo maar een filesystem, je hebt met heel wat aspecten te maken. Die 4 maanden zijn wel haalbaar, maar op dat punt moet je zelf de afweging maken waarvoor je het in durft te zetten.
@ Mark_17: Over twee weken ;)
Maar wat er beter aan is dan iSCSI setups? De vrijheid. Diskspace te kort? Gewoon een machine er bij, het systeem balanceert alle data opnieuw voor je. Je krijgt daarmee ook direct meer disks, dus meer performance. Ook is het systeem volledig distributed, dus de uitval van één fysieke machine kan je veel beter hebben.
Daarnaast is een Master <> Slave setup qua kosten ook niet fijn, bij Ceph is dat anders.
Op dit moment ben ik zéér te spreken over Ceph en zou ik dit per direct verkiezen boven iSCSI en NFS als ik dat kon (Maar dat gaat nog wel een lange tijd duren).
Alleen (wat ik hier boven al zei), het systeem is aardig complex om te draaien. Heb nu al 3 maanden een cluster van 14 nodes en 3 clients, daar ben je wel even zoet mee en je moet ook goed weten wat je doet om het goed ingeregeld te krijgen.
systemdeveloper
26/09/10, 22:45
@Wido: Overleeft dit ook een totale clustercrash? Of een crash van evenveel nodes dan je redundatie level? Ik bedoel dan x clusternodes die tegelijk down gaan vanwege een stroomstoring of niet bereikbaar zijn vanwege een kapotte switch oid, niet waarbij de disks hun laatste adem uitblazen.
@Wido: Overleeft dit ook een totale clustercrash? Of een crash van evenveel nodes dan je redundatie level? Ik bedoel dan x clusternodes die tegelijk down gaan vanwege een stroomstoring of niet bereikbaar zijn vanwege een kapotte switch oid, niet waarbij de disks hun laatste adem uitblazen.Ja, de totale clustercrash heb ik nu twee keer meegemaakt ivm stroomuitval, kwam gewoon weer prima terug.
Een paar falende nodes zijn geen probleem, zolang jij je topologie maar goed in elkaar hebt steken.
RADOS (Onderliggende objectstore van Ceph) werkt dmv een boomstructuur, je moet er dan ook voor zorgen dat die goed in elkaar steekt, anders kan je wel eens een probleem krijgen.
Ook moeten je monitors op strategische plekken staan.
Die 4 maanden zijn wel haalbaar, maar op dat punt moet je zelf de afweging maken waarvoor je het in durft te zetten.
Voor mij zou dat het moment zijn om er mee te gaan spelen. Daarmee bedoel ik: gebruik in niet-kritieke toepassingen (temp file stores), waarbij ik een iSCSI oplossing heb om op terug te vallen.
Over wat voor hardware hebben we het eigenlijk? Is een kwestie van alles wat je nog hebt liggen uitrusten met 1TB schijven en dan er maar bij hangen? Of is snellere hardware wel gewenst? Is het zinvol om snelle en langzamere nodes door elkaar te gebruiken?
Ik ben benieuwd welke distributie als eerste officiële support zal gaan leveren hiervoor. Ubuntu?
Ik heb er al eens eerder naar gekeken en dit is ook zeer interessant voor backup storage natuurlijk. Maar nog iets te veel in ontwikkeling.
Vroeg me af of het inmiddels ook stabiel draait met andere onderliggende bestandssystemen dan BTRFS.
Wat is er mis met btrfs? Is juist met Ceph er bovenop een fijn systeem hiervoor.
Voor mij zou dat het moment zijn om er mee te gaan spelen. Daarmee bedoel ik: gebruik in niet-kritieke toepassingen (temp file stores), waarbij ik een iSCSI oplossing heb om op terug te vallen.
Over wat voor hardware hebben we het eigenlijk? Is een kwestie van alles wat je nog hebt liggen uitrusten met 1TB schijven en dan er maar bij hangen? Of is snellere hardware wel gewenst? Is het zinvol om snelle en langzamere nodes door elkaar te gebruiken?
Ik ben benieuwd welke distributie als eerste officiële support zal gaan leveren hiervoor. Ubuntu?Ik heb een berg oude bakken draaien, Opteron 170's met 1 tot 2GB Ram en daarbij wat 500GB disken.
Snellere hardware kan wel handig zijn ja. Overigens is mixen van hardware mogelijk, je kan gewichten per machine geven.
@t.bloo: BTRFS is nog wel alpha/beta, want ik heb toch al wat crashes gezien er mee.
Ik ben net druk bezig me te verdiepen in ZFS. Dat kan ik dus beter overslaan aangezien Ceph nog een stap verder is?
Yourwebhoster
27/09/10, 11:45
Ik ben net druk bezig me te verdiepen in ZFS. Dat kan ik dus beter overslaan aangezien Ceph nog een stap verder is?
Ja en nee. Ceph is nog niet stabiel genoeg voor productie als ik het zo lees, maar over 4 maanden wel. Uiteraard kan je wel in de tussentijd kennis maken met ceph.
Ik ben net druk bezig me te verdiepen in ZFS. Dat kan ik dus beter overslaan aangezien Ceph nog een stap verder is?Nee, want ZFS en Ceph zijn totaal andere filesystems.
Ceph is een distributed filesystem over een netwerk heen, waar ZFS alleen voor lokale disken is.
ZFS zal bijv altijd sneller zijn qua access-tijden dan Ceph dat zal zijn (ivm netwerk latency), voor een database wil je dus liever ZFS dan Ceph.
Dus je moet beide goed vergelijken en per situatie de vergelijking maken.
Daarnaast zal Ceph over 4 maanden nog echt niet stabiel genoeg zijn om er al je productie-werk vanaf te draaien.
Helder. Het zou dus eigenlijk zo moeten worden dat Ceph ZFS als bestandsysteem gaat ondersteunen? Of gaat BTRFS op termijn hetzelfde kunnen als zfs nu kan?
BTRFS is nog wel alpha/beta, want ik heb toch al wat crashes gezien er mee.
zeker, maar dat vangt Ceph dan weer op (of is dat ambtenarenlogica?)
Helder. Het zou dus eigenlijk zo moeten worden dat Ceph ZFS als bestandsysteem gaat ondersteunen? Of gaat BTRFS op termijn hetzelfde kunnen als zfs nu kan?Het kan beide kanten op die je stelt.
@t.bloo: Ja, in theorie wel. Maar ik zag deze week een BTRFS bug die ineens mijn hele cluster op zijn knieën bracht.
Zijn er nog noemenswaardige ontwikkelingen geweest op dit gebied? Ik zie dat de ontwikkeling van Ceph aardig vordert, hoewel we nog niet aan de gehoopte 1.0 zitten (deze staat op dit moment op 41 dagen van nu). Hebben anderen inmiddels testomgevingen draaien? Heeft Wido al zijn eerste totale data loss gehad? ;) Ben erg benieuwd!
Productie klaar is het nog zeker niet, maar noemenswaardige ontwikkelingen? Ja, zeker! Het gaat hard, zeer hard, maar bugs blijven er komen.
BTRFS gooit ook met enige regelmaat roet in het eten, maar dat wordt ook vaak snel gefixed.
Total data loss heb ik nog niet gehad, maar zoiets kan ook bijna niet gebeuren, alles is in losse objecten opgeslagen, die kunnen niet ineens allemaal weg zijn.
Ik had wat vragen over het design van een cluster. Hier is een begin:
http://ceph.newdream.net/wiki/Designing_a_cluster
Maar ik had wat alternatieve ideeën:
OSD: In plaats van een klein aantal met veel disks en dure RAID controllers, waarom niet een flink aantal kleine, low-power (Atom) servers met elk minder schijven? Op die manier verdeel je de writes toch alsnog tussen veel spindles?
MDS: Veel geheugen en een snelle processor. Maar wat voor load kan je in de praktijk verwachten? En hoe goed schalen de processen mee met meerdere cores? Kan ik hiervoor wat 'oude' quad cores uit de kast trekken, of moet ik echt aan splinternieuwe systemen denken?
Monitors: Volgens de wiki kan ik die rustig bij de MDS plaatsen.
Dan zou ik dus drie redelijk snelle servers met veel geheugen neerzetten voor MDS/Monitors, met snelle CPU's en veel geheugen. Voor de OSDs zou ik relatief zwakke servers gebruiken waar ik er meer van kan kopen. Als ik er OSDs met SSD's tussenhang, worden intensieve reads/writes dan automatisch hiernaar verplaatst? Of moet elke OSD ruwweg even snel zijn in I/O?
Toevallig kwam dat gisteren op de mailinglist voorbij, zie: http://marc.info/?l=ceph-devel&m=129950642717079&w=2
Daar staat alle informatie, maar om kort te zijn: Laat de dure RAID controllers voor wat het is, gebruik goedkope en kleine nodes als OSD's.