<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">yes, precisely<br>
in the past I had running AFRs, this way<br>
<br>
box A looback client -> </font></font><font size="-1"><font
face="serif">box A server <-> box B server <- box B
loopback client<br>
<br>
but similarly replace local loopback client with legitimate
separate client that would have only access to one brick's one
NIC<br>
the simple idea was the client did not have to know about all
the bricks/servers<br>
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<br>
<br>
nowadays this seems impossible</font></font><font size="-1"><font
face="serif">, or am I wrong?<br>
<br>
</font></font><br>
On 23/04/12 16:14, Brian Candler wrote:
<blockquote cite="mid:20120423151427.GA2620@nsrc.org" type="cite">
<pre wrap="">On Mon, Apr 23, 2012 at 03:46:01PM +0100, lejeczek wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> but is a true server-side replication?
</pre>
</blockquote>
<pre wrap="">
No you're right, it's driven from the client side I believe. This is so that
the client can connect to either server if the other is down.
</pre>
<blockquote type="cite">
<pre wrap=""> if I'm not mistaken, afr would take take care of it while client(fuse)
would suffice if only map/connect one brick
lets say two nodes/peers are clients at the same time, both
clients/bricks would only mountpoint themselves on 127.0.0.1 and
replication would still work, does it?
</pre>
</blockquote>
<pre wrap="">
Sorry, I don't understand that question.
Using the native client, the mount is only used to make initial contact to
retrieve the volume info. After that point, the client talks directly to
the brick(s) it needs to, as defined in the volume info.
So if you
mount 127.0.0.1:/foo /foo
(because 127.0.0.1 happens to be one of the nodes in the cluster), and
volume /foo contains server1:/brick1 and server2:/brick2, then the client
will talk to "server1" and/or "server2" when reading and writing files.
On server1, you could put "127.0.0.1 server1" in the hosts file if you like
to force communication over that IP, but in practice using server1's public
IP is fine - it's still a loopback communication.
Indeed, if you have three nodes in your cluster, you can
mount server3:/foo /foo
and once the volume is mounted, data transfer will only take place between
the client and server1/server2. (This is the native client remember - NFS is
different, the traffic will hit server3 and then be forwarded to server1
and/or server2 as required)
The only other "server side" replication that I know of is geo-replication.
Regards,
Brian.
</pre>
</blockquote>
</body>
</html>