Apologies for the previous incomplete message. It seems an unintended Alt-Ret told Thunderbird to send prematurely.? So this time I'm composing outside Tbird so that it doesn't get that opportunity. I'm new to this world and trying to find my way around; I could use a bit of advice on how not to bump into corners.? I'm working a contract in which the client has one main office plus a remote office with inconsistent net.connectivity.? There will also be some very mobile laptops, sometimes a long way off and entirely disconnected, but when in the office it would be good if the results of whatever they were doing while elsewhere would be readily (automatically) imparted to storage there.? They have interest in gluster in a probable configuration based on a set of 3 servers at the main office and 1 at the remote.? Questions arise around how to involve the remote laptops (all Linux).? There is not a huge amount of data involved here at the moment, on the order of a few Tbytes, but it will surely grow; local concern in the main office is redundancy, plus making data available to the remote office + laptops. The data generation and usage model tends to be that a good amount of material is generated, but very local to each user, so that a lot of locality is present for who writes where.? But then everybody tends to read from everybody else's area.? It's almost like users have a $HOME within the volume, and people peruse others $HOMEs frequently. So far, I'm just playing with configuration, to see what's possible.? At the moment, I've defined a 1x3 at the mains plus a 1-node volume at the remote. geo-replication is active mains -> remote, but I decided to see what would happen if I also set it up in the other direction, remote -> mains.? This has had surprisingly good effect, in that anybody using either volume gets their content replicated to the other, and everyone gets volume access on a local fast network.? An odd downside is that geo-rep apparently induces the target volume to go read-only, but I am able to turn features.read-only off, it seems persistent, and geo-rep continues. The laptops are a stickier problem especially in being often disconnected.? A straightforward-but-dumb solution is to define a 1-node volume on a laptop, just to get it involved in the mechanism, and then again geo-rep to the mains...and possibly geo-rep the mains back to the laptop as well. Am I taking a wrong turn, or going off a deep end?? Is gluster overkill for the entire question?? The choices seem obvious so far, but I'm so new that such a level of obviousness also seems to look as much like na?v?t?.? If anyone might have a sentence or three of observation or suggestion about this sort of situation, I'd appreciate it. --karl -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220824/abe5cd0f/attachment.html>
Hi Karl, I think you should check out Syncthing too. Karl Kleinpaste <karl at kleinpaste.org> ? 2022?8?24??? 20:21???> Apologies for the previous incomplete message. It seems an unintended > Alt-Ret told Thunderbird to send prematurely. So this time I'm composing > outside Tbird so that it doesn't get that opportunity. > > I'm new to this world and trying to find my way around; I could use a bit > of advice on how not to bump into corners. I'm working a contract in which > the client has one main office plus a remote office with inconsistent > net.connectivity. There will also be some very mobile laptops, sometimes a > long way off and entirely disconnected, but when in the office it would be > good if the results of whatever they were doing while elsewhere would be > readily (automatically) imparted to storage there. They have interest in > gluster in a probable configuration based on a set of 3 servers at the main > office and 1 at the remote. Questions arise around how to involve the > remote laptops (all Linux). There is not a huge amount of data involved > here at the moment, on the order of a few Tbytes, but it will surely grow; > local concern in the main office is redundancy, plus making data available > to the remote office + laptops. > > The data generation and usage model tends to be that a good amount of > material is generated, but very local to each user, so that a lot of > locality is present for who writes where. But then everybody tends to read > from everybody else's area. It's almost like users have a $HOME within the > volume, and people peruse others $HOMEs frequently. > > So far, I'm just playing with configuration, to see what's possible. At > the moment, I've defined a 1x3 at the mains plus a 1-node volume at the > remote. geo-replication is active mains -> remote, but I decided to see > what would happen if I also set it up in the other direction, remote -> > mains. This has had surprisingly good effect, in that anybody using either > volume gets their content replicated to the other, and everyone gets volume > access on a local fast network. An odd downside is that geo-rep apparently > induces the target volume to go read-only, but I am able to turn > features.read-only off, it seems persistent, and geo-rep continues. > > The laptops are a stickier problem especially in being often > disconnected. A straightforward-but-dumb solution is to define a 1-node > volume on a laptop, just to get it involved in the mechanism, and then > again geo-rep to the mains...and possibly geo-rep the mains back to the > laptop as well. > > Am I taking a wrong turn, or going off a deep end? Is gluster overkill > for the entire question? The choices seem obvious so far, but I'm so new > that such a level of obviousness also seems to look as much like na?v?t?. > If anyone might have a sentence or three of observation or suggestion about > this sort of situation, I'd appreciate it. > > --karl > ________ > > > > Community Meeting Calendar: > > Schedule - > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC > Bridge: https://meet.google.com/cpu-eiue-hvk > Gluster-users mailing list > Gluster-users at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220824/f7899751/attachment.html>
Am 24.08.22 um 20:21 schrieb Karl Kleinpaste:> The laptops are a stickier problem especially in being often > disconnected.? A straightforward-but-dumb solution is to define a 1-node > volume on a laptop, just to get it involved in the mechanism, and then > again geo-rep to the mains...and possibly geo-rep the mains back to the > laptop as well.I would recommend to implement storage only in the main office and then run a file sync service (like syncthing, seafile or nextcloud) out of there. All laptops and desktops then sync their data to this file service. $HOME would be a local directory with only local data. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. ?35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin