Distributed file systems

[zeroxcool]

Hallo iedereen,

Ik ben me sinds kort een beetje aan het verdiepen in gedistribueerde filesystemen. Omdat ik persoonlijk NAS, SAN en RAID systemen te duur vind ben ik op zoek naar een relatief. Na het lezen van een paper over het GoogleFS (erg interessant: http://labs.google.com/papers/gfs.html) vroeg ik me af of er ook opensource (het liefste onder Linux) alternatieven zijn die zo goed als dezelfde functionaliteit hebben.

Wat ik dus eigenlijk wil is het volgende: ik wil een fileserver cluster bouwen die ongeveer de zelfde dingen beheerst. Dus als er iets geschreven wordt naar het cluster, het cluster ervoor zorg draagt dat dit minimaal op twee locaties is opgeslagen. Zodat als er bijvoorbeeld een node uitvalt de file sowieso nog ergens in je cluster aanwezig is. Een stuk redundantie dus. Wat uiteraard samenhangt met availability. Ik ben namelijk op zoek - mede voor werk gerelateerde zaken - zo min mogelijk single point of failures binnen een productie omgeving.

Wat heb ik zoal al gedaan. Ik heb naar GFS gekeken. Wel een gedistribueerd filesystem. Maar dat stuk redundantie vind ik niet expliciet ergens terug, dat moet je behalen door als storage platform bijvoorbeeld SAN apparatuur te gebruiken. Dan zijn er nog OpenAFS, InterMezzo en ook interessant: OCFS2 (het Oracle (global) filesystem). Die komen naar mijn mening allemaal in de buurt, maar missen net dat stukje redundantie. Of lees ik er langs op?

Wat ik dus wil vragen is of iemand ervaringen heeft op dit gebied met de genoemde software. Of die mij kan vertellen welk distributed filesystem deze functionaliteit wel heeft.

Ik heb overigens ook de verschillende eerdere topics hierover bekeken. En ben wel benieuwd of Kees inmiddels iets verder hiermee is:
- [NOS] File mirroring, bijv Coda
- Network file systems (coda,nfs,samba,ftp,sftp,...)

[ Voor 8% gewijzigd door zeroxcool op 29-11-2006 18:16 . Reden: topics toegevoegd ]

[lckarssen]

In de wikipedia entry voor filesystems, sectie Distributed parallel filesystems vond ik Lustre. Misschien is dat wat?

[zeroxcool]

lckarssen schreef op woensdag 29 november 2006 @ 20:11:
In de wikipedia entry voor filesystems, sectie Distributed parallel filesystems vond ik Lustre. Misschien is dat wat?

Toevallig heb ik daar net de source van gedownload. Het is wel een heel erg RedHat of SuSe minded systeem. Ik vind de documentatie tot nu toe een beetje matig (https://mail.clusterfs.co...chments/LustreManual.html). Misschien omdat er ook betaalde support wordt geboden vanuit de ontwikkelaars .

Ik zie trouwens nergens expliciet het 'server valt weg, data staat ergens anders redundant' verhaal terugkomen. Maar het kan er goed in zitten (high availability, zie ik genoemd worden). Ik heb ook het gevoel dat Lustre een enorme overkill is voor wat ik wil. Het wordt gebruikt in de grootste supercomputers in de wereld . En de meeste software (of enkel de kernel, dat is me niet helemaal duidelijk) zal herschreven moeten worden om - snel - gebruik te kunnen maken van de cluster storage (het liblustre verhaal).

Op dit moment werkt hier de site van de Lustre users niet. Misschien dat die wat meer is toegespitst op de 'standaard' gebruiker.

[Kokkers]

Ik ben zelf al een tijd opzoek naar een vergelijkbare oplossing voor het probleem wat jij schetst.
Er is echter een wezenlijk verschil tussen een redundant filesystem en een distributed filesystem. Dit is niet per definitie hetzelfde.

Ik heb zelf een stuk storage wat ik redundant wil hebben. Niet alleen omdat de kans op dataverlies te verkleinen maar ook omdat van meerdere locaties tegelijkertijd betere IO performance te halen is.
Iets waar je rekening mee moet houden is dat een distributed filesystem niet per definitie veilig is. Als je DFS om wat voor een reden corrupt raakt ben je alsnog de sjaak.

Zelf was ik heel erg gecharmeerd van Peerfs (www.radiantdata.com).
Ze hebben een trial die je heel eenvoudig kunt proberen. Ik liep met het creeeren van een 8TB volume (limiet) echter tegen een aantal bugs aan waardoor het voor mij niet bruikbaar is. Ze doen geen actieve support meer vanwege andere projecten lijkt het.

Overige projecten die ik tegen ben gekomen.

- PeerFS (valt voor mij af)
- Coda (dood, ik zou er geen produktie op willen draaien)
- InterMezzo (dood, ik zou er geen produktie op willen draaien)
- Lustre (te complex, denk aan grid computing e.d.)
- OpenAFS
- SANFS
- WANSync
- Repliweb
- DRBD mirroring (alleen active, passive)

Sommige commerciele oplossingen kunnen redelijk in de cijfers lopen.
Ik heb nog geen zaligmakende oplossing gevonden.

(Zie ook mijn vraag in Uitbreiden capaciteit en performance HTTP videoserv)

[zeroxcool]

Kokkers schreef op woensdag 29 november 2006 @ 22:06:
Ik ben zelf al een tijd opzoek naar een vergelijkbare oplossing voor het probleem wat jij schetst.
Er is echter een wezenlijk verschil tussen een redundant filesystem en een distributed filesystem. Dit is niet per definitie hetzelfde.

Nee ok, maar wil je redundantie niet op een enkel systeem aan laten komen, dan komt er - naar mijn mening dan - toch een gedistribueerd systeem bij kijken?

Ik heb zelf een stuk storage wat ik redundant wil hebben. Niet alleen omdat de kans op dataverlies te verkleinen maar ook omdat van meerdere locaties tegelijkertijd betere IO performance te halen is.
Iets waar je rekening mee moet houden is dat een distributed filesystem niet per definitie veilig is. Als je DFS om wat voor een reden corrupt raakt ben je alsnog de sjaak.

Maar dat geldt ook voor een corrupt filesysteem. Je zal uiteraard backups moeten blijven maken. Iets wat ook een vereiste is voor het stuk software wat ik zoek .

Zelf was ik heel erg gecharmeerd van Peerfs (www.radiantdata.com).
Ze hebben een trial die je heel eenvoudig kunt proberen. Ik liep met het creeeren van een 8TB volume (limiet) echter tegen een aantal bugs aan waardoor het voor mij niet bruikbaar is. Ze doen geen actieve support meer vanwege andere projecten lijkt het.

Jammer dat het zo gesloten is. Dat komt inderdaad de support alswel de mede gebruikers groep niet ten goede. Maar ook betaalde support zit er niet meer in, volgens jouw?

Overige projecten die ik tegen ben gekomen.

- PeerFS (valt voor mij af)
- Coda (dood, ik zou er geen produktie op willen draaien) Las ik in eerdere topics inderdaad
- InterMezzo (dood, ik zou er geen produktie op willen draaien) Zelfde mening, zie eerste post
- Lustre (te complex, denk aan grid computing e.d.) Dat dacht ik zelf ook al
- OpenAFS De basis is oud, maar het stuk redundantie mis ik zover ik weet
- SANFS Van IBM voor de StorageWorks lijn, interessant, ga ik naar kijken
- WANSync Heeft wat weg van PeerFS, niet 'echt' opensource, niet p2p, niet erg, ga ik ook naar kijken
- Repliweb Ook weer niet 'echt' opensource, voornamelijk Windows based?
- DRBD mirroring (alleen active, passive) Ik zie in je vorige topic dat je hiermee bezig bent geweest, nog een aanvulling ten aanzien van die post daar?

Sommige commerciele oplossingen kunnen redelijk in de cijfers lopen.
Ik heb nog geen zaligmakende oplossing gevonden.

Dat probeer ik toch wel te ontwijken, dan zijn meestal SAN-achtige apparatuur goedkoper.

(Zie ook mijn vraag in Uitbreiden capaciteit en performance HTTP videoserv)

Zie je lijstje.

Ik heb in mijn zoektocht ook nog het nodige gevonden:
- DFS een filesystem wat gebruikt wordt binnen Hadoop, een framework voor cluster based applicaties, is gebaseerd op GoogleFS, interessant.
- IBRIX fusion, ze hebben partnerships met EMC, dus ik gok dat deze software in de wat geavanceerde SAN-apparatuur terug te vinden is.
- GFarm, wordt gebruikt door nogal wat grote wetenschappelijke doeleinden, lijkt overkill maar ziet er relatief eenvoudig uit om aan de gang te krijgen. Het doel was om data wereldwijd over netwerken te verdelen... Gebruikt PostgreSQL voor het storen van z'n metadata. Een interessante uitleg. Ik gok alleen wel dat je Postgres systeem dan weer een SPOF wordt.

Leuk topic, al zeg ik het zelf .

[Keeper of the Keys]

Ik ben totaal geen expert maar toen ik een tijdje geleden naar OpenAFS keek als mogelijk FS in plaats van NFS was een van de features die onder andere interesant waren dat je met OpenAFS (als ik het goed begreep) offline door kon werken.
Daarvoor zou je denk ik toch in elk geval een deel van het FS lokaal op je machine moet staan (gechached) wat toch zeker redundant + distributed is?

[laurencevde]

network block devices en daar een raid overheen?

[killercow]

Tjah ik ben ook al tijden op zoek naar een echt cluster FS, maar heb nog niks gezien wat ik in productie durf te draaien,.

Ik ben momenteel met NFS en cacheFS bezig, maar cacheFS is zo te zien alleen beschikbaar in redhat. Zo kun je lokaal een gedeelte van je NFS share cachen.

Lustre leek mij ook erg interessant, maar heb ik nog niet kunnen testen.

Voor m'n eigen projectjes ben ik begonnen aan een simpel python servertje dat via enkele python master servers aangewezen wordt om een bepaalde file uit te leveren. Als er nog meer devvers rond lopen, join the effort zou ik zeggen.

[eghie]

Hey cacheFS is wel een handige om even naar te kijken. Ik had namelijk ooit mijn homedirectory via smbfs aangekopeld aan mijn (Samba) domein schijf. Alleen als de netwerk verbinding weg was kon je er alleen ook niks meer mee.

[zeroxcool]

Keeper of the Keys schreef op woensdag 29 november 2006 @ 23:54:
Ik ben totaal geen expert maar toen ik een tijdje geleden naar OpenAFS keek als mogelijk FS in plaats van NFS was een van de features die onder andere interesant waren dat je met OpenAFS (als ik het goed begreep) offline door kon werken.
Daarvoor zou je denk ik toch in elk geval een deel van het FS lokaal op je machine moet staan (gechached) wat toch zeker redundant + distributed is?

Dat is waar. Maar dan staat het stukje data wat op je backend (lees: je cluster fs) weg is gevallen op één van je frontservers. Waardoor andere frontservers er toch niet bij kunnen...

laurencevde schreef op donderdag 30 november 2006 @ 02:16:
network block devices en daar een raid overheen?

Klinkt wel interessant. Je zit dan echter nog wel met een SPOF in de rol van de server die de RAID-devices beheert. Beetje een zelfde probleem als je met NFS hebt (wat gebeurt er met open files op het moment dat je server die de RAID-devices beheert).

killercow schreef op donderdag 30 november 2006 @ 13:37:
Tjah ik ben ook al tijden op zoek naar een echt cluster FS, maar heb nog niks gezien wat ik in productie durf te draaien,.

Ik ben momenteel met NFS en cacheFS bezig, maar cacheFS is zo te zien alleen beschikbaar in redhat. Zo kun je lokaal een gedeelte van je NFS share cachen.

Dat is puur op snelheid berust dus. Nu nog iets voor de redundantie .

Lustre leek mij ook erg interessant, maar heb ik nog niet kunnen testen.

Als ik eind van dit jaar wat tijd had wilde ik eerst wat met GFarm proberen. Ook Lustre staat me wel aan. Maar misschien komen er nog wel wat andere ideeën.

Voor m'n eigen projectjes ben ik begonnen aan een simpel python servertje dat via enkele python master servers aangewezen wordt om een bepaalde file uit te leveren. Als er nog meer devvers rond lopen, join the effort zou ik zeggen.

Behoorlijk high level voor zoiets, of zie ik dat verkeerd? Leg eens wat meer van de werking uit .

[killercow]

ZeRoXcOoL schreef op donderdag 30 november 2006 @ 19:02:

Dat is puur op snelheid berust dus. Nu nog iets voor de redundantie .

Yup, maar ik hoopte door de load en connecties richting de NFS server te verminderen het mogenlijk te maken NFS via een heartbeat te laten fail-overen in geval van problemen, of eventueel via een LVS clustertje te laten forwarden naar de juiste server.

ZeRoXcOoL schreef op donderdag 30 november 2006 @ 19:02:

Behoorlijk high level voor zoiets, of zie ik dat verkeerd? Leg eens wat meer van de werking uit .

Valt eigenlijk wel mee,
Ik heb nu eignelijk 3 progjes,.
* Client
Deze connect naar een of meer masterservers die gelist staan in een config file op het normale FS.

* Masterserver
Deze houdt een database bij (nu nog in memmory, en zonder filestore), van welke file, waar staat. elke file heeft een uniek ID, en de masters moeten nog met elkaar gaan kletsen over nieuwe files.

Hij heeft een lijstje van nodes, en per file welke node deze file bevat, en welk ID het bestand in de pool heeft.

* Node
Deze heeft alleen een grote map op disk, welke hij benaderd als er om een bepaald ID gevraagt wordt.

Hier moet nog een md5 slag in komen, waarbij er dus een check utigevoerd moet worden.
Files die dan stuk zijn worden afgemeld bij de master(s),
Files die minder dan n maal opgeslagen zijn worden door de master tot een nieuwe node aangewezen, en deze node zal dan de file downloaden van een andere node zoals een normale client dit doet.

De client vraagt aan de masterserver het id+node_id van file x.y.z
De master geeft deze gegevens terug, ip+port,file_id
De client connect naar de node, en vraagt om file id.
De node returned file ID.
Als de node een aanvraag krijgt voor een file die hij niet heeft, geeft hij een 404 terug, en raporteerd de master nogmaals dat de clients iig bij hem aan t verkeerde adres zijn voor file nr X.

ANyway, tis allemaal nog erg basic, langzaam, en single threaded, maar like i said, vele handen maken licht werk.

[zeroxcool]

killercow schreef op donderdag 30 november 2006 @ 22:08:
[...]

Yup, maar ik hoopte door de load en connecties richting de NFS server te verminderen het mogenlijk te maken NFS via een heartbeat te laten fail-overen in geval van problemen, of eventueel via een LVS clustertje te laten forwarden naar de juiste server.

Dan zit je volgens Kees nog met een probleem: Kees in "[NOS] File mirroring, bijv Coda" (één-naar-laatste alinea).

Zo maar even wat ingevingen van mijn kant uit , komen ze .

[...]

Valt eigenlijk wel mee,
Ik heb nu eignelijk 3 progjes,.
* Client
Deze connect naar een of meer masterservers die gelist staan in een config file op het normale FS.

* Masterserver
Deze houdt een database bij (nu nog in memmory, en zonder filestore), van welke file, waar staat. elke file heeft een uniek ID, en de masters moeten nog met elkaar gaan kletsen over nieuwe files.

Hoe zorg je ervoor dat de masters consistent met elkaar zijn. Of anders: wat als er een master wegvalt die net een file heeft gestored op enkele nodes maar dat nog niet heeft doorgegeven aan andere masters?

Opvangen door nodes om de x-tijd een report te laten maken naar alle actieve masters?

Hij heeft een lijstje van nodes, en per file welke node deze file bevat, en welk ID het bestand in de pool heeft.

* Node
Deze heeft alleen een grote map op disk, welke hij benaderd als er om een bepaald ID gevraagt wordt.

Hier moet nog een md5 slag in komen, waarbij er dus een check utigevoerd moet worden.
Files die dan stuk zijn worden afgemeld bij de master(s),
Files die minder dan n maal opgeslagen zijn worden door de master tot een nieuwe node aangewezen, en deze node zal dan de file downloaden van een andere node zoals een normale client dit doet.

De client vraagt aan de masterserver het id+node_id van file x.y.z
De master geeft deze gegevens terug, ip+port,file_id
De client connect naar de node, en vraagt om file id.
De node returned file ID.
Als de node een aanvraag krijgt voor een file die hij niet heeft, geeft hij een 404 terug, en raporteerd de master nogmaals dat de clients iig bij hem aan t verkeerde adres zijn voor file nr X.

Ik wil je graag verwijzen (als je dat nog niet gedaan hebt) naar de GoogleFS paper. Als je die brok informatie uit hebt kun je in deze presentatie een iets gedetailleerder uitleg vinden.

Je hele verhaal komt overigens grotendeels overeen hoor . Dit ging echter over de reads. In de presentatie vind je een stuk over het schrijven van files naar je cluster. Ben benieuwd wat je er van denkt .

ANyway, tis allemaal nog erg basic, langzaam, en single threaded, maar like i said, vele handen maken licht werk.

Helaas is Python niet mijn taal. Anders zou ik graag een handje willen helpen ...

[Verwijderd]

Zelf heb ik een eigen implementatie bij elkaar gesprokkeld:

- via AoE (ATA over Ethernet) block devices aanbieden van "storage servers" naar "frontend server"
- "frontend server" importeert de AoE devices en die verschijnen in /etc/etherd/e*.*
- "frontend server" draait software RAID (level 5, maar 6 kan natuurlijk ook als je veel schijven hebt) over de geimporteerde devices. Eventueel kun je ook een block device in de "frontend server" zelf plaatsen en die onderdeel van het RAID array maken.
- over 3 RAID arrays draai ik LVM
- over LVM draai ik CryptoLoop
- /dev/loop0 is gemount als /backups (EXT3) met een totale omvang van 2.1 TB

Al deze zaken worden ondersteund in de nieuwere kernel-versies, voor AoE heb je geloof ik 2.6.12 ofzo nodig (kijk dat zelf even na). Al met al draai ik gewoon een mix van Debian Stable met Debian Testing kernel, en dat gaat perfect. Gigabit switch ertussen, en de performance is ongeveer 20 megabyte/sec (incl. RAID, LVM en Cryptoloop overhead!).

Als er een node uitvalt ("storage server"), dan draait alles gewoon verder, de "frontend server" draait immers RAID5. Als de "frontend server" uitvalt, dan kan uiteraard een "storage server" die rol overnemen, dat zou je kunnen implementeren met LinuxHA, Heartbeat en dat soort zaken.

Succes ermee!

[zeroxcool]

Verwijderd schreef op zaterdag 02 december 2006 @ 16:12:
Zelf heb ik een eigen implementatie bij elkaar gesprokkeld:

- via AoE (ATA over Ethernet) block devices aanbieden van "storage servers" naar "frontend server"
- "frontend server" importeert de AoE devices en die verschijnen in /etc/etherd/e*.*
- "frontend server" draait software RAID (level 5, maar 6 kan natuurlijk ook als je veel schijven hebt) over de geimporteerde devices. Eventueel kun je ook een block device in de "frontend server" zelf plaatsen en die onderdeel van het RAID array maken.
- over 3 RAID arrays draai ik LVM
- over LVM draai ik CryptoLoop
- /dev/loop0 is gemount als /backups (EXT3) met een totale omvang van 2.1 TB

Al deze zaken worden ondersteund in de nieuwere kernel-versies, voor AoE heb je geloof ik 2.6.12 ofzo nodig (kijk dat zelf even na). Al met al draai ik gewoon een mix van Debian Stable met Debian Testing kernel, en dat gaat perfect. Gigabit switch ertussen, en de performance is ongeveer 20 megabyte/sec (incl. RAID, LVM en Cryptoloop overhead!).

Als er een node uitvalt ("storage server"), dan draait alles gewoon verder, de "frontend server" draait immers RAID5. Als de "frontend server" uitvalt, dan kan uiteraard een "storage server" die rol overnemen, dat zou je kunnen implementeren met LinuxHA, Heartbeat en dat soort zaken.

Succes ermee!

Klinkt erg interessant. Heb je de performance ook ooit eens getest zonder Cryptoloop? Dat is voor mijn doeleinden niet echt interessant.

En waar gebruik je LVM voor? Is dat voor het uitbreiden van bijvoorbeeld het aantal RAID-blocks?

Ik gok dat het wel moeilijk wordt om een frontend server op te vangen. Aangezien deze alle pariteits informatie bijhoudt. Of staat dat dus op één van de AoE-disks?

[Rainmaker]

Is dit niet lastig? Als een van je servers een keer uitvalt, moet je de RAID array toch rebuilden? Met 2.1 TB kan ik me voorstellen dat dit even duurt...

Wel een leuk systeem, ik heb hetzelfde in gedachten gehad, maar het is er (nog?) niet van gekomen het te maken...

[killercow]

ZeRoXcOoL schreef op zaterdag 02 december 2006 @ 01:05:
Dan zit je volgens Kees nog met een probleem: Kees in "[NOS] File mirroring, bijv Coda" (één-naar-laatste alinea).

True, daarom is het dus ook niet ideaal.

ZeRoXcOoL schreef op zaterdag 02 december 2006 @ 01:05:
Zo maar even wat ingevingen van mijn kant uit , komen ze .

Hoe zorg je ervoor dat de masters consistent met elkaar zijn. Of anders: wat als er een master wegvalt die net een file heeft gestored op enkele nodes maar dat nog niet heeft doorgegeven aan andere masters?

Opvangen door nodes om de x-tijd een report te laten maken naar alle actieve masters?

Dat is inderdaad een probleem punt, de masters moeten eigenlijk allebei on write de data ontvangen.

Aka, een client schrijft een file weg,
de master (a) verteld op welke node dit moet gebeuren, om master load te voorkomen.
De client connect naar de stornode,
De file wordt over gepompt,
De node meld aan zijn master en aan de client, succes.
De master gaat replicatie naar andere nodes voorbereiden.
Node X krijgt opdracht file Z van node Y te lezen en te storen.

Eventueel zou de node naar beide masters kunnen melden dat hij een write heeft gedaan, maar dan blijf je met een hoofd-master, en een slave master zitten.
Anders gaan ze allebei replicatie naar nog een node opstarten.
Dus lijkt het mij handiger dat de Node gewoon aan zijn default master terug kletst, en dat die master daarna zijn changes over pompt naar de andere master(s).

Writes wilde ik altijd in een nieuw file doen, welke daarna de pointer naar de oude vervangt. (de pointers staan op de master) (atomic dus)

Eventueel freed space wordt in het googleFS in idle time weer leeggemaakt op de nodes, en wordt dan bij de free-space opgeteld, en weer terug aan de master geraporteerd.

ZeRoXcOoL schreef op zaterdag 02 december 2006 @ 01:05:
Ik wil je graag verwijzen (als je dat nog niet gedaan hebt) naar de GoogleFS paper. Als je die brok informatie uit hebt kun je in deze presentatie een iets gedetailleerder uitleg vinden.

Je hele verhaal komt overigens grotendeels overeen hoor . Dit ging echter over de reads. In de presentatie vind je een stuk over het schrijven van files naar je cluster. Ben benieuwd wat je er van denkt .

Yup, ik ken ze, en heb ook contact met iemand die een excacte replica wilde bouwen.
GooleFS is wel zo'n beetje de lijdraad op dit gebied denk ik, vooral omdat heel veel lamp clusters en apps precies zo'n FS erg nuttig kunnen gebruiken.

ZeRoXcOoL schreef op zaterdag 02 december 2006 @ 01:05:


Helaas is Python niet mijn taal. Anders zou ik graag een handje willen helpen ...

Wat is je taal wel?
Ik schrijf dit in python als leer python projectje, dus echt veel soeps is het nog niet. (en de client is atm gewoon een telnet sessie.

Er zijn toch 3 delen te bouwen, de cient, de masters, en de nodes.

[zeroxcool]

killercow schreef op zondag 03 december 2006 @ 11:40:
[...]

True, daarom is het dus ook niet ideaal.

[...]

Dat is inderdaad een probleem punt, de masters moeten eigenlijk allebei on write de data ontvangen.

Dat zou kunnen. Of je zorgt ervoor - net zoals Google dat doet - dat in je ontwerp er maar één master server is. Dat vereenvoudigt je ontwerp. Wat je dan er nog bij zou kunnen maken is een soort high availibility tool, die binnen twee seconden voor een nieuwe master zorgt (een shadow).

Aka, een client schrijft een file weg,
de master (a) verteld op welke node dit moet gebeuren, om master load te voorkomen.
De client connect naar de stornode,
De file wordt over gepompt,
De node meld aan zijn master en aan de client, succes.
De master gaat replicatie naar andere nodes voorbereiden.
Node X krijgt opdracht file Z van node Y te lezen en te storen.

Eventueel zou de node naar beide masters kunnen melden dat hij een write heeft gedaan, maar dan blijf je met een hoofd-master, en een slave master zitten.
Anders gaan ze allebei replicatie naar nog een node opstarten.
Dus lijkt het mij handiger dat de Node gewoon aan zijn default master terug kletst, en dat die master daarna zijn changes over pompt naar de andere master(s).

Writes wilde ik altijd in een nieuw file doen, welke daarna de pointer naar de oude vervangt. (de pointers staan op de master) (atomic dus)

Als je één master hebt dan is dat atomic. Bij meerdere wordt het weer een lastig verhaal. Synchronisatie e.d.

Eventueel freed space wordt in het googleFS in idle time weer leeggemaakt op de nodes, en wordt dan bij de free-space opgeteld, en weer terug aan de master geraporteerd.

Goed idee inderdaad.

Yup, ik ken ze, en heb ook contact met iemand die een excacte replica wilde bouwen.
GooleFS is wel zo'n beetje de lijdraad op dit gebied denk ik, vooral omdat heel veel lamp clusters en apps precies zo'n FS erg nuttig kunnen gebruiken.

Wat is het resultaat van die interesse?

Zoals ik al heb aangegeven is het hele concept inderdaad erg duidelijk en netjes opgezet. Ik denk alleen wel dat de blocksizes (grootte van de chunks) een probleem op kunnen leveren. Google gaat uit van 64MB per chunk. Dat is voor normale (niet-Google) doeleinden lichtelijk te hoog . Voor LAMP storage kom je al snel bij een grootte van 1~4KB. Wat inhoudt dat als je bijvoorbeeld 1TB storage wilt hebben, je 536870912 records in je master database nodig hebt (bij een blocksize van 2KB). Je hebt dan een 'adresruimte' voor je chunks aan 32-bit genoeg. Maar met het oog op meerdere TB's zul je een 64-bits ID moeten gebruiken. Wat grofweg betekent dat je om alle chunks te adresseren op je master je zo'n 8 byte (64-bit ID) + 12 byte overigen (filename, metadata) = 20 byte * 536870912 = 10GB aan record informatie. Lastig om dat in je memory te proppen .

Puur een gedachte, en helemaal onderbouwd is het niet...

Wat is je taal wel?
Ik schrijf dit in python als leer python projectje, dus echt veel soeps is het nog niet. (en de client is atm gewoon een telnet sessie.

Er zijn toch 3 delen te bouwen, de cient, de masters, en de nodes.

Wat basic C, C#, Delphi en wat PHP. Niet echt interessant. Maar als het wat concreets wordt heb ik overigens wel interesse hier misschien wat tijd in te steken.

[killercow]

ZeRoXcOoL schreef op zondag 03 december 2006 @ 22:04:

Dat zou kunnen. Of je zorgt ervoor - net zoals Google dat doet - dat in je ontwerp er maar één master server is. Dat vereenvoudigt je ontwerp. Wat je dan er nog bij zou kunnen maken is een soort high availibility tool, die binnen twee seconden voor een nieuwe master zorgt (een shadow).

Met hearthbeat kan dat inderdaad prima, het grootste probleem met NFS (persistent connections) heb ik geen last van, en ik kan dus vrij simpel het IP naar een andere server pointen.
Het hebben van 2 of meer masters heeft echter meer voordelen dan alleen failover, maar geeft zeker in het begin erg veel problemen.

ZeRoXcOoL schreef op zondag 03 december 2006 @ 22:04:

Wat is het resultaat van die interesse?

Bijna niks, zijn programma draait, maar is erg ingewikkeld om te lezen, zijn development is gestopt, en het is dus erg lastig om verder te komen met zijn code.

ZeRoXcOoL schreef op zondag 03 december 2006 @ 22:04:

Zoals ik al heb aangegeven is het hele concept inderdaad erg duidelijk en netjes opgezet. Ik denk alleen wel dat de blocksizes (grootte van de chunks) een probleem op kunnen leveren. Google gaat uit van 64MB per chunk. Dat is voor normale (niet-Google) doeleinden lichtelijk te hoog . Voor LAMP storage kom je al snel bij een grootte van 1~4KB. Wat inhoudt dat als je bijvoorbeeld 1TB storage wilt hebben, je 536870912 records in je master database nodig hebt (bij een blocksize van 2KB). Je hebt dan een 'adresruimte' voor je chunks aan 32-bit genoeg. Maar met het oog op meerdere TB's zul je een 64-bits ID moeten gebruiken. Wat grofweg betekent dat je om alle chunks te adresseren op je master je zo'n 8 byte (64-bit ID) + 12 byte overigen (filename, metadata) = 20 byte * 536870912 = 10GB aan record informatie. Lastig om dat in je memory te proppen .

Puur een gedachte, en helemaal onderbouwd is het niet...

Ik denk dat mensen met kleine blockssize needs (php files, images), deze zonder problemen wel via rsync en lokale disks kunnen hosten.

Grotere files passen echter vaak niet meer op de lokale disks (scsi, snel maar duur), en juist dit soort files lijken mij dus nuttig om zo op te slaan.

Ook de overhead op een 4k file is nogal groot, bij een 10mb file is deze al verwaarloosbaar.

Ik heb op het moment geen speciale block-size keuzes, ik laat de files gewoon in bin op het bestaande FS schrijven. M'n enige limit is idd m'n address space, het aantal files lijkt mij zeker in het begin niet veel groter worden dan 32 bits.

Een vaste block size op een eigen raw FS is een leuke toevoeging, maar voegt nog een stuk development toe, en een dependency aan de gebruiker, er moet immers een lege partitie vrij zijn, op het moment vindt ik een dir met genummerde files al een hele oplossing.

ZeRoXcOoL schreef op zondag 03 december 2006 @ 22:04:
Wat basic C, C#, Delphi en wat PHP. Niet echt interessant. Maar als het wat concreets wordt heb ik overigens wel interesse hier misschien wat tijd in te steken.

Tof, ik mail je anders wel even, dat discussieert wat makkelijker.

[Kokkers]

killercow schreef op donderdag 30 november 2006 @ 13:37:

Ik ben momenteel met NFS en cacheFS bezig, maar cacheFS is zo te zien alleen beschikbaar in redhat. Zo kun je lokaal een gedeelte van je NFS share cachen.

Het je CacheFS toevallig al draaiend?
Het zo is frustrerend dat de documentatie zo verspreid, tegenstrijdig en verwarrend is.

Wat ik nu begrijp wordt CacheFS standaard meegeleverd met Fedora Core 6 en RedHat Enterprise linux 5. Zelf draai ik Redhat Enterprise linux 4 (U3 en U4), ik kan helaas nergens vinden of CacheFS uberhaupt zou kunnen werken onder de door mij gebruikte linux versie.

[bakkerl]

Kokkers schreef op woensdag 29 november 2006 @ 22:06:
- Lustre (te complex, denk aan grid computing e.d.)
- DRBD mirroring (alleen active, passive)

Lustre opzich doet niets aan redunatie. Op dit moment doen ze alleen nog een raid0 constructie over verschillende nodes. Pas bij een volgende versie willen ze raid5 constructie over verschillende nodes gaan ondersteunen.

Echte zijn er genoeg mensen welke Lustre en DRBD combineren om elke (data)node redunant te maken.

[killercow]

Kokkers schreef op dinsdag 05 december 2006 @ 11:03:
[...]


Het je CacheFS toevallig al draaiend?
Het zo is frustrerend dat de documentatie zo verspreid, tegenstrijdig en verwarrend is.

Wat ik nu begrijp wordt CacheFS standaard meegeleverd met Fedora Core 6 en RedHat Enterprise linux 5. Zelf draai ik Redhat Enterprise linux 4 (U3 en U4), ik kan helaas nergens vinden of CacheFS uberhaupt zou kunnen werken onder de door mij gebruikte linux versie.

Nope, ben thuis nog hard aan t klooien,
Ik draai gentoo, en in de MM kernel tree heb ik cacheFS wel kunnen vinden, maar m'n mount command snapt het nog niet erg.
Ook in /proc/filesystems (oid), staat cacheFS er niet bij, dus ik heb geen idee of ik nog wat anders moet veranderen aan m'n kernel voordat het ook echt werkt.

Daarnaast heb ik nog niet uitgevonden, of ik misschien gewoon het mount programma moet patchen met wat redhat patches, of dat ik nog ergens anders een mount script moet toevoegen.

[Kokkers]

Ik krijg toevallig net een mailtje van iemand uit de mailinglist die Gentoo draait.
Hij heeft vorige week een wiki gemaakt, http://gentoo-wiki.com/HOWTO_CacheFS.
Volgens mij loopt hij tegen hetzelfde probleem, https://www.redhat.com/ar...06-November/msg00137.html

Misschien heb je er iets aan.

[Verwijderd]

Heb zelf vandaag getest met Heartbeat & DRBD. Dit werkt echt wel goed, snel én feilloos. Het voorziet een active/passive failover met een virtueel IP.

Server1 is active
Server2 is passive

Server1's volume (aparte partitie !!) word bit per bit gesynched naar het gespecifieerde (offline) volume op Server2. Als server1 down gaat, heb je binnen de 2 seconden hetzelfde IP als je gebruikte op server1 nu op server2 met alle vereiste diensten.

Dit is geen cluster, nog DFS, maar wel een goed uitgewerkt failover plan welk volledig gratis is én nog goed ondersteund word ook. Tevens draait het op bijna alle populaire distro's (RH, Centos, SuSe, Debian, Gentoo ...)

Voor een goeie tutorial welke dit scenario voorzien in combo met een NFS server:
http://www.linux-ha.org/DRBD/NFS

Grtz,
Thanis

[Jap]

Mischien is Gluster wat?

GlusterFS is a clustered file-system capable of scaling to several peta-bytes. It aggregates various storage bricks over Infiniband RDMA or TCP/IP interconnect into one large parallel network file system. GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It borrows a powerful concept called Translators from GNU Hurd kernel. Much of the code in GlusterFS is in userspace and easily manageable.

Can GlusterFS store files redundantly?

Yes. There are 2 approaches to that. One by using mirror translator. Other by using one shared external disks (JBOD/iSCSI/IB-SER devices) for every 2 GlusterFS brick in the storage cluster.

en het schijnt makkelijk te mounten zijn als client:

How do I mount/umount GlusterFS?

Mounting GlusterFS can be performed directly by passing command-line arguments to "glusterfs" client module or through "mount -t glusterfs" or "mount.glusterfs" or "/etc/fstab". For unmounting, you can use the regular "umount" utility.

heb helaas nog geen ervaring ermee, maar ga zeker hiermee testen!

[Kokkers]

Gluster ziet er veelbelovend uit maar lijkt zo begin 2007 nog in de kinderschoenen te staan.
Deze pagina maar even in de gaten houden:
http://www.gluster.org/docs/index.php/GlusterStorage

Wellicht een (ander) interessant documentje voor geinteresseerden:

Distributed File Systems
Inzetbaar als data consistentie houder?
Jan van Lith en Maarten Michels
4 juli 2005
http://staff.science.uva....-2004-2005/p15/report.pdf

[ Voor 12% gewijzigd door Kokkers op 08-01-2007 17:28 ]

[MrBarBarian]

EVMS heeft ook wat mogelijkheden voor shared-filesystems. Ik heb het nog nooit geprobeert, maar de specs zijn we veel belovend