<div dir="auto">Hi Karl,<div dir="auto"><br></div><div dir="auto">I think you should check out Syncthing too.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>> 于 2022年8月24日周三 20:21写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<font face="FreeSerif">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
--karl<br>
</font>
</div>
________<br>
<br>
<br>
<br>
Community Meeting Calendar:<br>
<br>
Schedule -<br>
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br>
Bridge: <a href="https://meet.google.com/cpu-eiue-hvk" rel="noreferrer noreferrer" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank" rel="noreferrer">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div>