Egy évnyi csend után a fejlesztésben a hibatűrő elosztott fájlrendszer új ágán és a második jelölt a kiadásokban. Nemrégiben a LizardFS-t fejlesztő cég tulajdonosváltása, új vezetőség került megválasztásra és a fejlesztők is megváltoztak. Az utolsó két évben a projekt eltávolodott a közösségtől, és nem fordított rá megfelelő figyelmet, de az új csapat szándéka, hogy helyreállítsa a korábbi kapcsolatokat a közösséggel és szoros együttműködést alakítson ki vele. A projekt kódja C és C++ nyelveken íródott és a GPLv3 licenc alatt áll.
A LizardFS elosztott klaszteres fájlrendszer, amely lehetővé teszi az adatok különböző szerverekre való elosztását, de azokhoz való hozzáférést egyetlen nagy partíció formájában mutatja be, amelyet a hagyományos lemezmegosztásokhoz hasonlóan kezelnek. A LizardFS-sel csatlakoztatott partíción támogatottak a POSIX fájlattribútumok, ACL, zárak, socketek, csatornák, eszközfájlok, szimbolikus és hard linkek. A rendszernek nincs egyetlen meghibásodási pontja, minden összetevő párhuzamosítva van. Támogatott az adatokkal végzett műveletek párhuzamosítása (több kliens egyidejűleg férhet hozzá a fájlokhoz).
A hibatűrés biztosítása érdekében az adatok replikákra bontódnak, amelyeket különböző csomópontok között osztanak el (több másolat több csomóponton helyezkedik el), — ha csomópontok vagy tárolók hibásodnak meg, a rendszer folytatja a működést adatvesztés nélkül és automatikusan újraelosztja az adatokat a megmaradt csomópontok figyelembevételével. A tároló bővítéséhez elegendő új csomópontokat csatlakoztatni anélkül, hogy leállítanák a szolgáltatást (a rendszer magától replikálja az adatok egy részét az új szerverekre, és kiegyensúlyozza a tárolót az új szerverek figyelembevételével). Hasonló módon a klaszter méretének csökkentésére is lehetőség van — egyszerűen le lehet kapcsolni a régi, elavult berendezéseket.
Az adatok és a metaadatok elkülönítve tárolódnak. A működéshez javasolt, hogy két metaadat-szervert telepítsenek master-slave üzemmódban, valamint legalább két adattároló szervert (chunkserver). Továbbá a metaadatok biztonsági mentésére log szerverek is alkalmazhatók, amelyek nyilvántartják a metaadatok változásait és lehetővé teszik a működés helyreállítását, ha minden meglévő metaadat-szerver meghibásodik. Minden fájl darabokra (chunk) van bontva, legfeljebb 64 MB méretben. A darabok a tároló szervereken a választott replikációs mód szerint vannak elosztva: standard (a másolatok számának explicit meghatározása a különböző csomópontokon, beleértve a különböző könyvtárakhoz való kötést - fontos adatok esetén a másolatok számát növelhetjük, míg a nem lényeges adatoknál csökkenthetjük), XOR (RAID5) és EC (RAID6).
A tároló petabájt méretig skálázható. Az alkalmazási területek közé tartozik az archívumok vezetése, virtuális gépek képeinek tárolása, multimédiás adatok, biztonsági mentések, DRC (Katasztrófa-helyreállító Központ) használata és tárolás nagy teljesítményű számítási klaszterekben. A LizardFS rendkívül magas fájlolvasási sebességet biztosít bármilyen méretű fájl esetén, és íráskor jó teljesítményt mutat, amikor nagy és közepes fájlokat egyben írnak, ha nincs folyamatos módosítás, intenzív munka nyitott fájlokkal és tucatnyi kisebb fájl egyedi műveletekkel.
A fájlrendszer jellemzői közé tartozik a pillanatképek támogatásának megléte, amelyek egy adott időszak fájlállapotát tükrözik, valamint a beépített „kukás” implementáció (a fájlok nem törlődnek azonnal, és egy ideig helyreállíthatók). A hozzáférés IP-cím vagy jelszó alapján korlátozható (azonos módon, mint az NFS). A kvóta- és szolgáltatásminőség-kezelési mechanizmusok lehetővé teszik a méret és a sávszélesség korlátozását bizonyos felhasználói kategóriák számára. Területi elosztott tárolók létrehozása lehetséges, amelyek szegmensei különböző adatközpontokban találhatók.
A LizardFS projekt 2013-ban indult, mint forkolt , és főként a Reed-Solomon kódok alapú replikációs mód miatt különbözik (azonos a raidzN-nel), kiterjesztett ACL támogatásával, Windows platformra készült klienssel, további optimalizálásokkal (például, a kliens és a tárolószerver összevonásakor a blokkok lehetőség szerint a jelenlegi csomópontból kerülnek kiosztásra, és a metaadatok a memóriában vannak cache-elve), rugalmasabb konfigurációs rendszerrel, előrelátó adatolvasási támogatással, könyvtárkvótákkal és belső feldolgozásokkal.
A LizardFS 3.13.0 kiadását december végére tervezik. A LizardFS 3.13 fő újdonsága, hogy a hibatűrés biztosításához (a master szerverek átváltása hiba esetén) konszenzus elérésére szolgáló algoritmust használ. (a saját uRaft megvalósítást használják, amelyet korábban kereskedelmi termékekben alkalmaztak). Az uRaft használata egyszerűsíti a beállítást és csökkenti a késleltetést hiba helyreállítása során, de legalább három működő csomópont szükséges, amelyek közül az egyik a kvórumhoz van felhasználva.
További változások: új kliens a FUSE3 altalapján, hibajavító problémák megoldása, az nfs-ganesha plugint C nyelven írták át. A 3.13.0-rc2 frissítésben számos kritikus hibát javítottak, amelyek a korábbi 3.13-as tesztkiadásokat használhatatlanná tették (a 3.12-es ághoz tartozó javítások még nem kerültek közzétételre, és a 3.12-ről 3.13-ra való frissítés továbbra is teljes adatvesztést eredményez).
2020-ban a munka az
, újonnan teljesen átírt LizardFS mag fejlesztésére összpontosít, amely a fejlesztők állítása szerint háromszoros teljesítménynövekedést fog biztosítani a 3.12-es ághoz képest. Az Agama eseményalapú architektúrára (event driven) vált, aszinkron I/O-val , a munka főként a felhasználói térben (a kernel cache mechanizmusoktól való függőség csökkentésére). Kiegészítőleg új hibakereső alrendszert és hálózati aktivitáselemzőt fognak javasolni, teljesítmény automatikus optimalizáló támogatással.
A LizardFS klienshez teljes körű verziókezelés támogatását fogják hozzáadni, amely növeli a hibahelyreállítás megbízhatóságát, megoldja a különböző kliensek egyes adatokhoz való hozzáférésekor felmerülő problémákat, és lehetővé teszi a teljesítmény jelentős növelését. A kliens saját felhasználói térben működő hálózati alrendszerre kerül át. Az Agama alapú LizardFS első működő prototípusát 2020 második negyedévére tervezik elkészíteni. Ebben az időszakban ígéretük szerint az integrációs eszközök is megvalósulnak a LizardFS és a Kubernetes platform között.
Forrás: opennet.ru
