brainstorming-ul de joi (in avampremiera pentru flame-ul de vineri :-P) salutare; incerc sa ma documentez pentru doua chestii: 1. poor man dfs pentru a folosi 'commodity hardware' si/sau spatiul neutilizat pe anumite servere caut un DFS cu urmatoarele caracteristici: - cat mai simplu si usor de instalat (cat mai putine pachete instalate, interventii in kernel - module, dependinte, si mai ales resurse alocate, cel putin pe brick-uri/osd-uri; pentru metacache server sau cum s-o numi in solutia respectiva putem face exceptie) - brick-uri/osd-uri de marimi cat mai diferite (de genul pot sa am unul de 10 giga, unul de un tera) - de preferinta sa ruleze peste o partitie deja existenta (gen glusterfs, cel putin in versiunile mai vechi, mai nou am inteles ca au bagat si astia chunk-uri); adica ii specific un director si mai departe isi face el ce structura vrea acolo - chunk-ul poate fi la nivel de fisier (ba chiar as prefera sa fie asa, pentru recuperare cat mai usoara in caz de probleme); la nivel de director cu atat mai bine, dar cred ca deja se complica prea mult problema - redundanta (fiecare fisier sa fie pus macar in 2 locuri; daca se poate in mai multe si eventual si granularitate la nivel de fisier, cu atat mai bine) - fisiere medii si mari (nu cred ca va fi cazul de fisiere mici si multe); ca numar de fisiere, relativ redus, maxim zeci de mii (desi initial mii ca ordin de marime) - acces redus la fisiere (din cand in cand pus / scos / tras ceva de acolo) - adaugare / scoatere de brick-uri cat mai facila si transparenta; atat soft (de genul: vreau sa scot de pe brick-ul x, muta ce ai acolo, si dupa aia zi-mi sa dezactivez brick-ul) cat si hard (dat la cap, sa-si faca el recovery automat, copiind datele ramase neduplicate pe alte brick-uri cu spatiu disponibil) - modificare dimensiune brick cat mai facila (crestere / descrestere spatiul alocat) - NU javra (prietenii stiu de ce :-P) - ma intereseaza durabilitatea, mai putin HA si performante, doar sa existe o metoda de backup ceva la meta server (nu ma doare sa se piarda ceva timp la restaurarea 'bazei de date' de fisiere dintr-un backup ceva, dar sa nu se piarda baza de date in caz de failure)
pana acum din ce am studiat xtreemfs-ul suna promitator, pana cand am vazut cuvantul magic javra, deci pas; mai era inca unul tot in java (nici nu i-am retinut numele), l-am sarit instant si pe acela au mai ramas pe lista moosefs si urmasul lui, soparlafs, care ar indeplini marea majoritate a cerintelor mele; a folosit cineva sa dea feedback ? daca aveti alte idei de implementari cat mai simple si low profile (javra exclus), let me know, sa arunc un ochi si pe ele practic la nevoie se poate face si un soft care sa indexeze fisierele si sa le trimita mai departe prin ceva REST catre brick-uri (dupa cum ziceam operatiile sunt mai rare si nu ma intereseaza 'realtime'); la REST insa e mai complicat cu vfs-ul, daca vreau sa le vad ca fisiere pe disc, slabe sanse sa ma apuc eu sa programez un modul de vfs 2. chestii (mai) serioase cautand zilele trecute pe net am gasit niste success stories al celor de la wikimedia folosind un 'cluster' de ceph (care de ceva mai multa vreme a devenit si recomandat pentru productie), si care pentru HA, IO in draci samd suna chiar bine pe hartie a folosit cineva prin ograda si poate sa dea feedback ? aici deja vorbim de hard / partitie alocata exclusiv, fara necesitate de low profile etc. sau alte solutii (in afara de Lustre de care am tot citit si tot citesc, si gluster care nu a fost pe gustul meu cand am testat), evident fara java (sunt cam alergic, deci hdfs-ul iese de pe lista) nu ma intereseaza neaparat (de fapt nu ma intereseaza mai deloc) solutii de shared storage, dupa experiente nu tocmai multumitoare cu ocfs (ca sa nu mai vorbesc de gfs unde cand mergea mergea, cand nu mergea rebutam serverele mai ceva ca in windows) mersi (in primul rand pentru rabdarea de a citi iar un mail lung :-P) Alex _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
