Gluster Blog

Do people perceive this to be more cost effective than backing up data?

What is the total cost in terms of down-time, failing audits, disclosing to customers and employees that control of their data has been lost? Would that loss be greater than a backup solution? Has it become taboo in 2020 to do backups that can't be tainted by attackers or dodgy automation? It was not a problem 20 years ago. What changed?

If it's cost, even a low end gluster cluster [0] or Ceph with an archive read-only share that has rsnapshot [1] diffs for 5 days would mitigate this, assuming you know within 2 or 3 days to sound the alarm. Rsnapshot would run on the server. People would just see multiple folders with the last 5 days of changes. The snapshots would not be writable by employees or malware. To further reduce cost, perhaps de-duplicate data with ZFS or VDO [2]. Everything mentioned here is open source and has multiple enterprise supported options that your engineering and IT staff are likely already aware of. If not, there are plenty of documents on integrating gluster into active directory.

[0] - https://www.gluster.org/community/

[1] - https://github.com/rsnapshot/rsnapshot

[2] - https://blog.delouw.ch/2018/12/17/using-data-deduplication-and-compression-with-vdo-on-rhel-7-and-8/

I have used AWS on 2 projects now.

On the first project, we used 2 small instances as web servers, 1 small instance as a database master, and another as a slave. The slave machine handled backup of db and uploaded files by zipping everything up and throwing it onto s3. There was no EBS or RDS at this time. The main problem we had was sharing user uploaded files between instances. We used Gluster (http://www.gluster.org/) for this, but it was complicated and gave us problems. In general this setup worked fine and we could add webserver instances to handle traffic spikes. Even this limited setup took a bit of effort to maintain and I often wondered if we could have just handled the whole thing with one large or extra large instance. Does anyone know if there is some bottleneck that comes from vertically scaling like this?

Sadly, on the second project we haven't really needed to scale at all, so we just use one small instance for everything and have our mysql files and user uploaded files in an EBS volume. I haven't really figured out backup and restore from snapshots yet, so I just zip up the contents of the EBS and transfer it to S3. We are using cloudfront to serve static files and it seems to work fine.

I was going to agree but decided to load up web site to be sure:

https://www.gluster.org/

I don't see a list of features at all here or an obvious link to them. Most sites have something like this (see "Why Sector/Sphere?"):

http://sector.sourceforge.net/

Or this:

http://lustre.org/about/

Wait, that one almost sucks as much as GlusterFS site. It could also use a page detailing exactly what it can and can't do with obvious link on front-page. At least it had obvious link and basic description, though.

So, hard to judge writer of recent post on what features were in GlusterFS, etc if their page doesn't go through the trouble to list them without us having to dig. I'd have to point two fingers. Fortunately, Wikipedia to rescue doing what site didn't do:

https://en.wikipedia.org/wiki/GlusterFS

Note: Oh shit, it still doesn't mention encryption. Not in the comparison or list of distributed filesystems either. Still undocumented for casual researcher.

Let me Google "GlusterFS encryption" for you.

http://www.gluster.org/community/documentation/index.php/Features/disk-encryption

https://www.gluster.org/community/documentation/images/e/e2/GlusterFS_transparent_encryption.pdf

...and more. I think that still falls under "casual research" ... besides which, implementers and promoters should be doing more than casual research anyway. The fact that the Gluster documentation sucks doesn't change that. Plenty of others have implemented such end-to-end encryption as well, and the trend is already increasing. (I find that quite gratifying BTW since I felt like a lone voice in the wilderness when I was writing about the importance of keeping keys on the clients five-plus years ago.) What they present as a differentiator is very much a me-too nowadays so, again, it calls their other claims of originality or uniqueness into question.

> "Glfs has a severe problem with small writes, both with writing small files and small writes into large files. FhGFS does not have this bottleneck."

GlusterFS has implemented many smallfile performance enhancements and with the latest release I am seeing a 20-50% improvement on smallfile performance. There are more improvements in the pipeline:

http://www.gluster.org/community/documentation/index.php/Features/Feature_Smallfile_Perf

I would be curious to see these tests run on a properly tuned(readahead on bricks is important for spinning disks and read workloads, I didn't see any mention of brick tuning in the article) and on the latest version of glusterfs with the smallfile performance enhancements.

Heyas,

Ex-GlusterFS person here (used to work at Red Hat on the project side, leaving mid last year).

"Small file access", and "lots of files in a directory" have been a pain point with GlusterFS for ages. The 3.7.0 release had some important improvements in it, specificially designed to help fix that:

https://www.gluster.org/community/documentation/index.php/Features/Feature_Smallfile_Perf

The latest Gluster release is 3.7.8 (the same series as 3.7.0), and is worth looking at if you're needing a good distributed file system. If you have something like 1Mill files in a single directory though... hrmmm... NFS or other technologies might still be a better idea. ;)