•  untoreh-light

Distribuerade filsystem

En sammanställning av distribuerade filsystem

Mål

Distribuerade filsystem?

A distribuerat filsystem generellt ge en helst POSIX kompatibelt filsystemgränssnitt. Detta är den största delen av dess definition eftersom att bygga ett kluster av noder som håller data på ett distribuerat sätt kan uppnås på många olika sätt, men att bygga en som ger tillgång till en användbar filsystemgränssnittet är utmanande. Ett filsystem antas vanligtvis vara lokaloch som sådan antar många applikationer snabb åtkomst till det, bortser från möjliga latensproblem som kan uppstå på ett filsystem som stöds av fjärradata. Mycket få applikationer skiljer mellan lokala och fjärranslutna filsystem.

Att byta ut ett filsystem med ett distribuerat kan betraktas som en form av bakåtkompatibilitet ... i det fall du vill distribuera en applikation i en molnmiljö som är beroende av filsystemåtkomst för dess datalager, måste molnet tillhandahålla ett filsystemgränssnitt som godtyckligt kan replikera över maskiner. Men i ett enskilt användarfall kan det också betraktas som ett sätt att minska hanteringen av omkostnader ... istället för att spåra säkerhetskopior för data från varje enskild server du kör kan du spåra hälsan hos det nätverksbaserade filsystemet och schemalägga säkerhetskopior på det.

Om du inte behöver strikt åtkomst till filsystems semantik är ett distribuerat objektlagringsgränssnitt enklare och lika portabla och universell som ett filsystem, med mindre synkronicitetsbelastning på nätverket eftersom ett objektlagring i sig inte innehåller metadata. Vissa objektlagringsprogramvara erbjuder ett filsystemsgränssnitt byggt ovanpå.

Runda upp

Eftersom vårt mål är inte big data ignorerar vi lösningar som HDFS.

Här resulterar vissa riktmärken i en tabell, de täcker inte alla filsystem och kan vara föråldrade vid denna tidpunkt och if2fs resultat cachning kan ha glidit igenom :)

Bandbredd

FS seq rread rrw files create read append rename delete
raw 78793 1.0409e6 89958 179483 17300.0 23550.0 14408.0 4677 5373
zfs 102121 1.3985e6 92391 198410 29180.0 4470.0 18980.0 4695 8468
f2fs 2.064e6 1.455e6 101674 184495 28320.0 10950.0 16890.0 4233 3912
xtreemefs 159310 29117 29468 1690 510.0 1190.0 520.0 274 330
glusterfs 178026 17222 18152 5681 4380.0 7620.0 3110.0 413 1076
beegfs 79934 103006 85983 24867 9830.0 12660.0 10470.0 2889 3588
orangefs 330781 54735 41611 5523 5120.0 7020.0 6130.0 638 1989

IOPS

FS seq rread rrw files create read append
raw 76 266440 22489 44870 4430 6028 3688
zfs 99 358000 23097 49602 7470 1146 4860
f2fs 2064 372524 25418 46123 7250 2803 4325
xtreemefs 155 7279 7366 422 131 306 134
glusterfs 173 4305 4537 1420 1123 1951 798
beegfs 78 25751 21495 6216 2518 3242 2682
orangefs 323 13683 10402 1380 1310 1979 1571

Resurser

FS CPU (Server) CPU (Client) RAM (Server) RAM (Client)
xtreemefs 100 25 300 201
glusterfs 100 50 92 277
beegfs 80 80 42 31
orangefs 15 75 60 20

Data

Här är riktmärkesdata

Sysctl -rattarna var inställda för maximal genomströmning, men de borde utan tvekan vara värdelösa och förmodligen skeva riktmärkena, eftersom dessa rattar inte alltid tillämpas i ett heterogent nätverk, och i alla fall är de nätverksberoende , så även om de tillämpas kan det finnas andra flaskhalsar på plats.

Ytterligare jämförelser, från wikipedia, från tångar.

Inläggstaggar: