Hi Zach,
>
This is very difficult or complex to achieve and maintain. >
Option 1. 3 Gluster nodes, one large volume, divided up into subdirs (1 for each website), mounting the respective subdirs into their containers & using ACLs & LXD’s u/g id maps (mixed feelings about security here)
>
Which version of GlusterFS is in use here ? because gluster sub directory support patch is available in upstream, however I dont think its in a good state to consume. Yeah, if the subdirectory mount is performed we have to take enough care to make sure the isolation of the mounts between multiple user, ie security is a concern here.
>
>
Option 2. 3 Gluster nodes, website-specifc bricks on each, creating website-specific volumes, then mounting those respective volumes into their containers. Example:
gnode-1
- /data/website1/brick1
- /data/website2/brick1
gnode-2
- /data/website1/brick2
- /data/website2/brick2
gnode-3
- /data/website1/brick3
- /data/website2/brick3
>
Yes, this looks to be an ideal or more consumable approach to me.
>
>
Option 3. 3 Gluster nodes, every website get’s their own mini “Gluster Cluster” via LXD containers on the Gluster nodes. Example:
gnode-1
- gcontainer-website1
- /data/brick1
- gcontainer-website2
- /data/brick1
gnode-2
- gcontainer-website1
- /data/brick2
- gcontainer-website2
- /data/brick2
gnode-3
- gcontainer-website1
- /data/brick3
- gcontainer-website2
- /data/brick3
>
>
Also for safer side, you may need take snapshot of the volumes or configure a backup for these volumes to avoid single point of failure.
Please let me know if you need any details.
--Humble
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
