Hi Karl, I think you should check out Syncthing too.
Karl Kleinpaste <k...@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@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users >
________ 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@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-users
