2015-06-18 16:42 GMT+02:00 Alex 'CAVE' Cernat <c...@cernat.ro>: > On 18/6/2015 5:08 PM, Vali Dragnuta wrote: > > 1.Daca excluzi java doar pentru ca java atunci esti mai tut decit pari. > cand o sa vad ceva functional cum trebuie in java, mai vorbim; oricum > una din cerinte la 1) era cat mai low profile, deci java exclusa din > principiu (sau poate mai nou java low profile nu mai e un oxymoron si eu > nu am aflat inca ... ) > da, stiu ca multa lume 'buna' foloseste la greu hadoop/hdfs care are la > baza java, dar la ce gust amar mi-a lasat intotdeauna 'balega de java' > (TM, am picat si un examen cu expresia asta) mai trebuie sa treaca > destul timp incat sa imi treaca alergia; mai vorbim dupa cativa ani ... > ps: chrome-ul e noul javra :P (asta ca subiect de discutie pentru maine) > pps: am mai vazut intr-o prezentare comparata de dfs-uri la xtreemfs > trecuta java la cons, deci nu sunt singurul nebun de pe planeta :-P > > 2.Am testat si eu si ceph si gluster, la fiecare am gasit cite ceva care > > m-a oprit (deocamdata) sa implementez mai departe. For the record eu > > caut pentru a tine volume de masini virtuale pe ele. Gluster is getting > > there, but still no cigar.La gluster spre exemplu un issue era ca > > writerul (clientul) scria simultan ambele copii ale datelor (adica daca > > ai un volum cu o replica, in momentul in care scrii ceva scrii in 2 > > locuri simultan, injumatatind performanta de scriere pt ca banda e in > > general limitata. Intr-o oarecare masura, depinzind si de hardware poti > > compensa cu interface bonding. > am crezut ca mi se pare mie chestia asta la gluster sau macar ca s-a mai > schimbat treaba intre timp (mai nou se lauda ca au facut sau sunt pe > cale sa implementeze chunk-ing-ul); problema principala la gluster in > varianta low cost e ca vrea brick-uri cat mai asemanatoare si ca nu poti > jongla foarte mult cu numarul brick-urilor (in nici un caz nu pui 1-2-3 > si mai departe sa-si faca el treaba, trebuie musai 2 * n, 3 * n si de > marimi cat adunate intre ele pe grupuri sa ajungi la sume asemanatoare) > oricum la masini virtuale deja vorbim de scriere random care mai > complica putin datele problemei; eu cautam pentru stocare de obiecte > (poze, video, arhive etc), exclus masini virtuale si/sau baze de date, > care necesita un tratament mai special > > > Implementari viitoare de glusterfs vor avea un mecanism ceva mai elegant > > in care scrii catre un nod si nodul la rindul sau propaga datele catre o > > replica. > asa sa fie ... > > 3. Nu am apucat inca sa testez asta, poate in perioada urmatoare. > > https://en.wikipedia.org/wiki/BeeGFS > mi-a trecut prin fata ochilor, nu mai stiu de ce l-am exclus (la ce > lista de DFS-uri am vazut in ultimul timp, nu am retinut chiar totul); > cred ca setup-ul era mai complex, si atunci daca tot vorbim de ceva > profi atunci ceph-ul parca parea cu mai multe facilitati > asa ca DFS mai era si cel de la fraunhofer (care vorba aia, e un nume), > nu mai stiu cum se numea ca si la astia e moda de a schimba numele > produsului la greu > > GPFS - robust, performant, etc, etc - nu este free :(
open source, in afara de cele mentionate (gfs1/2 - care mi s-au parut suficient de instabile incit sa nu le mai folosesc in veci ,gluster,ceph,hdfs): Lustre OrangeFS/PVFS > Alex > > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
