<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="-1"><font face="serif">what I'm saying is that it was
possible in previous versions, don't know when this changed<br>
namely client(fuse) would mountpoint to just one brick/server
and then then bricks would sort replication out between
themselves<br>
it used to work this way, right? I'm sure I had it this way, afr
+ unity<br>
<br>
what I'm asking is whether it is possible to have similar in
3.2.x?<br>
<br>
I'm curious why would it change, it is now the client that looks
after replication,<br>
I did some quick manual tampering with configs for fuse and I
see that if client is told to mountpoint to only one brick, to
lets say the local one to the client, then operations of this
client do not get replicated over to other(s) brick(s)<br>
what's the benefit of having the client doing it, and logic
behind it? before glusted/server would be looking after such a
volume and one would think this would be the best place to drop
this trust and knowledge - server sides mange replicated volume
and let a client jump in wherever convenient<br>
<br>
and what about such setups where a client cannot access certain
brick for the brick is behind client's reach<br>
<br>
one practical test case, I'd imagine common, possible?<br>
<br>
<br>
CLIENTs <br>
<very congested net><br>
/ IP Ab IP Bb \<br>
brick A brick B<br>
\ IP Aa </font></font><font size="-1"><font face="serif"><
very fast net ></font></font><font size="-1"><font
face="serif"> IP Ba /<br>
<br>
<br>
one would would think clients access Ab & Bb<br>
replication via Aa & Ba<br>
I guess it goes as deep as inner-workings of gluster itself, for
me in the past(AFR) this worked really nicely when some clients
had only access to one brick(separate net) whereas others to the
second, and bricks had a fast link to each other, where the
replication happened.<br>
<br>
maybe I would be better off with some other 'mirroring'
solution, anybody recommends anything?<br>
cheers</font></font><br>
<br>
On 23/04/12 17:13, Brian Candler wrote:
<blockquote cite="mid:20120423161337.GB2746@nsrc.org" type="cite">
<pre wrap="">On Mon, Apr 23, 2012 at 04:44:32PM +0100, lejeczek wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> yes, precisely
in the past I had running AFRs, this way
box A looback client -> box A server <-> box B server <- box B
loopback client
but similarly replace local loopback client with legitimate separate
client that would have only access to one brick's one NIC
</pre>
</blockquote>
<pre wrap="">
Sorry, you've lost me again. What do you mean by a "loopback client" or a
"legitimate client"?
A client is a client, and a brick is a brick.
If you happen to run a client on the same physical hardware as a brick, that
makes no difference to the architecture.
So if you have server1 and server2, both running as bricks, that's fine.
Then you create an AFR volume out of those two bricks, that's fine too.
Then if a [FUSE native] client mounts this volume it will talk to both
bricks, that's fine too.
If the client happens to be located on server1, then it makes no difference
- it too will talk to server1 and server2.
Your diagram suggests that "box A server" (brick) talks to "box B server",
but I don't think it does, unless you're doing NFS. More accurately I'd
say it's like this:
+---------+ +----------+
| client | | .client |
| | `---------'-. | |
| | ,---------' | | |
| v v | | v v |
| brick | | brick |
+---------+ +----------+
</pre>
<blockquote type="cite">
<pre wrap=""> the simple idea was the client did not have to know about all the
bricks/servers
</pre>
</blockquote>
<pre wrap="">
The native FUSE client learns this from the volume info and configures
itself automatically. Is there a problem with this?
</pre>
<blockquote type="cite">
<pre wrap=""> and I'd think this would be what most of of us would like, there would
be quite a few situations where this is greatly helpful
nowadays this seems impossible, or am I wrong?
</pre>
</blockquote>
<pre wrap="">
Unfortunately I don't understand what you're asking for, so I can't really
give any suggestions!
Regards,
Brian.
</pre>
</blockquote>
</body>
</html>