Discussion:
[Gluster-users] GlusterFS Object Storage
Gandalf Corvotempesta
2015-12-18 11:46:16 UTC
Permalink
Hi,
I would like to test Gluster as Object Storage with APIs

Based on official docs, object storage is done by Swift. Is swift
really a requirements ? Should I install the whole swift stack with
keyrings and so on ?

Any plans to integrate an easier approch to object storage without
swift requirements, something like Ceph with native RadosGW ?

I don't like OpenStack, I prefere to not use Swift at all.
Niels de Vos
2015-12-18 16:30:36 UTC
Permalink
Post by Gandalf Corvotempesta
Hi,
I would like to test Gluster as Object Storage with APIs
Based on official docs, object storage is done by Swift. Is swift
really a requirements ? Should I install the whole swift stack with
keyrings and so on ?
The project that you would use is called SwiftOnFile. The Quick Start
Guide should give you a relatively simple setup:

https://github.com/openstack/swiftonfile/blob/master/doc/markdown/quick_start_guide.md
Post by Gandalf Corvotempesta
Any plans to integrate an easier approch to object storage without
swift requirements, something like Ceph with native RadosGW ?
Not that I am aware of.
Post by Gandalf Corvotempesta
I don't like OpenStack, I prefere to not use Swift at all.
If you do not require a full featured object API, you could use the
libgfapi-python bindings (there are Java and Ruby ones too) or the
glusterfs-coreutils for shell scripting:

https://github.com/gluster/libgfapi-python
https://github.com/gluster/glusterfs-coreutils

HTH,
Niels
Prashanth Pai
2015-12-21 05:19:04 UTC
Permalink
Hi Gandalf,

Adding to what Niels said...

Swift is unique. Unlike other openstack projects, one does not have to install rest of OpenStack to use Swift.

There are two ways to use Swift to provide object interface to GlusterFS volume:
1. swiftonfile project
2. gluster-swift project (resides in icehouse branch: https://github.com/openstack/swiftonfile/tree/icehouse)

While swiftonfile requires you to maintain sqlite DBs like vanilla Swift does, it results in faster object listings. However, with swiftonfile, you will have to exclusively access files over object API only as it currently has no capability to keep the DBs in sync with the real-time filesystem view. In other words, one cannot create objects over FUSE/NFS and expect them to be seen in object listings.

gluster-swift is an older project (we're reviving it soon) which does not require you to maintain any DBs, has a much simpler setup (easier than RadosGW) but at the cost of slower object listings. It does a "ls -lR" equivalent on container directory. Hence the slow listing.

The rationale of using Swift to provide object interface as against implementing our own radosgw sort of thing is simple. There are only two popular object APIs: S3 and Swift. Swift is open source, has a vibrant community and has no hard dependency on the rest of openstack. It also provides a crude way to plug-in any backend storage system. Further, using the swift3 (https://github.com/openstack/swift3) middleware, one can also provide access to files in glusterfs volume over Amazon S3 API.

Please feel free to reach out for any further help.

Regards,
-Prashanth Pai

----- Original Message -----
Sent: Friday, December 18, 2015 10:00:36 PM
Subject: Re: [Gluster-users] GlusterFS Object Storage
Post by Gandalf Corvotempesta
Hi,
I would like to test Gluster as Object Storage with APIs
Based on official docs, object storage is done by Swift. Is swift
really a requirements ? Should I install the whole swift stack with
keyrings and so on ?
The project that you would use is called SwiftOnFile. The Quick Start
https://github.com/openstack/swiftonfile/blob/master/doc/markdown/quick_start_guide.md
Post by Gandalf Corvotempesta
Any plans to integrate an easier approch to object storage without
swift requirements, something like Ceph with native RadosGW ?
Not that I am aware of.
Post by Gandalf Corvotempesta
I don't like OpenStack, I prefere to not use Swift at all.
If you do not require a full featured object API, you could use the
libgfapi-python bindings (there are Java and Ruby ones too) or the
https://github.com/gluster/libgfapi-python
https://github.com/gluster/glusterfs-coreutils
HTH,
Niels
_______________________________________________
Gluster-users mailing list
http://www.gluster.org/mailman/listinfo/gluster-users
Gandalf Corvotempesta
2015-12-22 20:20:22 UTC
Permalink
The old code is still usable, just that it's based off an older version of Swift. We intend to revive this within a month.
And AFAICT, slower listing is the only draw back when compared to swiftonfile.
So, waiting a couple of month would be the best choise, right ?
I'm not in a rush, so I can wait a couple of month, if needed.
Not bad at all. gluster-swift would be a good fit for this use case. One point to note here that, neither swiftonfile nor gluster-swift does file locking during creation or access.
In other words, you won't run into any problems as long as multiple clients do not modify the same file at the same time.
For example, if a client is writing to file over FUSE and another client downloads the same file over HTTP, he may get half written content. This is expected.
Ok.
Are you aware of any company offering this kind hybrid storage? Just
to know how they addressed these issues.

Loading...