Replikovaný souborový systém SeznamFS (diskuse)

[lukas.ramlich]

Teď můžou všichni veřejně vidět, jak je Seznam technologicky pozadu. Místo pořádného clusterového filesystému typu BigTable + Map/Reduce procesů lepí takovéhle náhražky. Seznam radši bude objevovat hranaté kolo, jen proto, že jejich geekové chtějí zažít vzrušení z implementace vlastního interního řešení, o kterém jsou bláhově přesvědčeni, že je úplně nejlepší!

[kozzi]

Ale na tom není nic špatného. Linux taky vznikl jako vzrušení z vlastní implementace

[Karel]

No jistěěěěěě, só to fušeří

[David Jaša]

FUSEři.

[Max]

Á, seznam je tu, pojďme rychle kopat, dokud to jde ... Chjo ...
Zdar Max
PS: Co je vlastně špatného na tom, že si šijou FS na míru?

[kozzi]

Podle mě nic. Krom toho, mít potřebné znalosti udělám to samé. Udělal bych něco jako nfs, ale mnohem primitivnějšího a jednodušího.

[pasmen]

Co muze byt jednodussi nez sshfs Proc vymyslet ameriku.

[kozzi]

No sshfs je jdnoduche, ale ja bych si udelal neco co nebezi pres ssh, ani pres FUSE kvuli vykonu, sshfs je fajn ale vykonnostně to není nejlepší, ale ani nejhorší.

[Mti.]

...a to pak pouzijes jak? Budes na kaztem stroji (predpokladam, ze *.seznam.cz netaha jedno postarsi core2duo v krabici pod stolem...) kompilovat znovu kernel aby to slo pouzit? (nejsu odbornik, pouze se blbe ptam)

[Käyttäjä 11133]

Třeba chce napsat ty patche tak dobře, že se dostanou do Linusovy větve :D

[Ladicek]

Naprosto není problém napsat to jako modul, který distribuční jádro v klidu natáhne.

[Käyttäjä 11133]

A já snad řekl, že je to problém? :-p Mluvím o tom, že to bude děsná pruda to pořád přepisovat, když se něco zásadního v Linusově stromu změní.

[Ladicek]

No jistě, sorry, to byla v podstatě reakce na předřečníka.

Jinak trošku vím, o čem mluvím: před pár lety jsme jako semestrálku se dvěma kolegy dělali triviální read-only souborový systém pro Linux. To bylo v době 2.6.8.1. Těsně před předváděním vyšla 2.6.9, kolega upgradoval, modul přeložil… ale už nezavedl Nebo tak nějak to bylo. Naštěstí si nechal na disku i předchozí verzi Takže jo, pruda by to určitě byla, ale jádro v produkci přece neměním tak často. A VFS je hodně konzervativní rozhraní, AFAIK se jiné části jádra mění mnohem bouřlivěji.

[Ladicek]

On Google je Google. A BigTable není clusterový filesystém, nýbrž trochu zvláštní databáze nad clusterovým filesystémem Google File System

No a jak jsem to pochopil, oni ten bazmek u Seznamu zdaleka nepoužívají ke stejným účelům, jako GoogleFS u Googlu. Kdyby chtěli něco takového, budou se srovnávat třeba s HDFS nebo KosmosFS (nad kterými existují třeba HBase nebo Hypertable).

[MArtin]

Tohle už jsou jenom detaily.

Zásadní otázka je, proč vyvíjejí cosi vlastního a jednoúčelového, když můžou použít HA clusterový filesystém a nad ním tu "zvláštní databázi".

Problém Seznamu je, že každý projekt dělají jinak. Jeden projekt běží na NAS, druhý na dedikovaném stroji, třetí na obskurním clusteru. Jejich admini pak nevědí která bije a běhají od jednoho stroje ke druhému a lepí to jak se dá. To je podle mě dlouhodobě neudržitelné.

Proč nemít jednu pevnou infrastrukturu, která nabízí Storage/Map/Reduce a nad ní psát jednotlivé distribuované aplikace? Posílení kapacity či výkonu znamená jen automatickou instalaci X nových strojů (s jednotnou konfigurací) a jejich zapojení do sítě.

Je SeznamFS cesta tímto směrem?

BTW možná si někdo říká, proč to vůbec řeším. Otevření SeznamFS totiž nechápu jako "tady to leží, vemte si to", ale spíš jako pozvánku "podívejte se, co používáme, pojďte to vylepšovat s námi!". Aby se ale vývojář podílel na nějaké novince, musí si být jist jejím účelem. Pokud ten účel není jasný, proč raději nepracovat na vylepšování jiných řešení, jako je např. glusterfs & spol?

[Ladicek]

Já to nechápu. Máte snad v Seznamu peníze? Protože pokud ne, tak mlátíte prázdnou slámu, zcela bezúčelně. Namísto toho, abyste kriticky zhodnotil, zda může být ten projekt užitečný pro vás, tak hodnotíte interní infrastrukturu jeho tvůrce. To je pak ale debata efektivně bezpředmětná.

To ostatní mi přijde trochu naivní, takhle prostě open-source projekty fungují.

[burlog]

Pokud ta nase vlastni jednoucelova vec usetri polovinu stroju a sitove infrastruktury, ktere jsou potreba pro provoz nejake obecne viceucelove veci, tak se nam setsakra vyplati. Ostatne to UNIX prisel s tim, ze jsou lepsi jednoucelove veci, ktere presne plni sve zadani, nez viceucelovi molochove, kteri delaji vsechno....

[alblaho]

Seznam s Googlem srovnávat vůbec nejde. Ta návštěvnost co mají je srandovní. Řekl bych, že Seznam můžem srovnávat tak se Slashdotem

Ale dobře to nese, to se musí nechat.

[Chocolate Bear]

Jak může mít v logu operaci touch, mv.. na úrovni filesystému snad nic takového neexistuje, ne?

Všechna zapsaná data. Je to tedy i verzovací filesystém?

[MArtin]

Kdepak. Oni nehoní jedničky a nuly po fyzickém disku, oni jsou jen replikující mezivrstva. Pod tím ještě musí být klasický filesystém, třeba ext3.

Proto v jejich případě dávají high level operace typu touch a mv smysl. Ten jejich "filesystém" to jen šoupne do binlogu (který si může někdo další číst) a taktéž provede na storage FS. Z toho plyne, že to je docela tupé řešení. Pravém clusterovému FS řeknu "tenhle soubor chci mít minimálně ve třech kopiích na různých strojích" a on to nějak sám rozstrká. Můžu přidat za chodu do clusteru stroj a nejednou mám o 1TB víc místa. Když stroj chcípne, nějak si to samo poradí a soubory s nižším počtem kopií se nareplikují jinam. To tady nejde.

[edois]

Ono jde o to, ze to chovani, ktere popisujete, proste nepotrebujeme. Potrebujeme akorat mit solidni filesystem, do ktereho nahrajeme data a ona se sama rozdistribuuji na ostatni nody. Potrebujeme mit vsechno vsude a ne to nejak neustale honit pres sit (viz napr. glusterfs)..

[Radim Kolář]

No nestacilo by NFS4? kdyz klienti umi delat persistentni caching...

[edois]

Jak je to u NFS4 s vydejem souboru? Zvladne je to vydavat stejne rychle jako samotna ext3 nebo xfs?

[Radim Kolář]

z cache jede stejne rychle jako filesystem, jen tusim ma omezeni max 2GB u nacachovaneho souboru na 32bit architekture.

[lukas.ramlich]

Mě se spíš zdá, že to chování potřebujete, ale nevíte o tom. Proč většina velkých hráčů jde směrem HA datového skladu? Asi to bude mít nějaký důvod, ne? Mě se zdá myšlenka "mít všechno všude" totálně zcestná. Musíte udržovat všechny uzly v totožné HW konfiguraci a když naroste objem dat, musíte je všechny upgradovat. A když nějaký soubor (nebo jejich skupina) bude mít víc, než je nějaký technologický limit, tak končíte. Tohle není řešení do budoucna.

Ale jinak je super, že vaši geekové dělají o víkendu zdarma věci do práce jen proto, že je to baví :)

[honza]

Pochopil jsem, že se Seznamem máte nějaký problém, ale ani s vašeho blogu jsem nezjistikl jaký.

[Messa]

Třeba je seznamfs určen pro data, u kterých je jisté, že nerostou příliš rychle.