ConnNetFilterFile / ConnInterfacesFile

389 views
Skip to first unread message

Ilya Bychkov

unread,
Mar 1, 2013, 5:45:06 AM3/1/13
to fhgfs...@googlegroups.com
Hi,

does anyone know how to use this options? I tried it under Linux with creating 2 simple files with following content ( and wrote the path to this files into every storage.conf und the client.conf ) :

ConnNetFilterFile          ConnInterfacesFile
   12.0.0.1/24                       eth0
   14.0.0.1/24                       eth1

1 Client should write the files over eth0 and if i pull out the cable, it should simply switch and write over eth1....But it's not worked. What did I do wrong? 

Kind Regards,

Ilya

Frank Kautz

unread,
Mar 4, 2013, 2:34:36 AM3/4/13
to fhgfs...@googlegroups.com
Hi Ilya.

Am 03/01/2013 11:45 AM, schrieb Ilya Bychkov:
> Hi,
>
> does anyone know how to use this options? I tried it under Linux with
> creating 2 simple files with following content ( and wrote the path to
> this files into every storage.conf und the client.conf ) :

Did you use the absolute path to the config files (ConnNetFilterFile,
ConnInterfacesFile) in the fhgfs-client.conf, fhgfs-storage.conf,
fhgfs-mgmtd.conf and the fhgfs-meta.conf.

>
> _*ConnNetFilterFile*_ _*ConnInterfacesFile*_
> 12.0.0.1/24 eth0
> 14.0.0.1/24 eth1

You are using strange IP-addresses. You are using public IP addresses
and not private IP addresses. Is your fhgfs working across the internet
or only in a local network?

>
> 1 Client should write the files over eth0 and if i pull out the cable,
> it should simply switch and write over eth1....But it's not worked. What
> did I do wrong?

Normally it works so easy. Look into the logfiles of the client, there
must be a other reason why it doesn't work. Maybe the other servers are
not reachable over the other interface.

kind regards,
Frank

>
> Kind Regards,
>
> Ilya
>
> --
> You received this message because you are subscribed to the Google
> Groups "fhgfs-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fhgfs-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Ilya Bychkov

unread,
Mar 4, 2013, 3:49:22 AM3/4/13
to fhgfs...@googlegroups.com, frank...@itwm.fraunhofer.de


Did you use the absolute path to the config files (ConnNetFilterFile,
ConnInterfacesFile) in the fhgfs-client.conf, fhgfs-storage.conf,
fhgfs-mgmtd.conf and the fhgfs-meta.conf.

   It looks like:

   ConnNetFilterFile     =    /root/Desktop/netfile

   Is it right or should it be a .txt - File like     /root/Desktop/netfile.txt   ?

>
> _*ConnNetFilterFile*_          _*ConnInterfacesFile*_
>    12.0.0.1/24                       eth0
>    14.0.0.1/24                       eth1

You are using strange IP-addresses. You are using public IP addresses
and not private IP addresses. Is your fhgfs working across the internet
or only in a local network?

    Why are they strange?^^ I have no connections to the public net (192.x.x.x), this adresses (12.x.x.x. / 14.x.x.x.) are private, so only my servers are communicating over this IP-Addresses...
 
Normally it works so easy. Look into the logfiles of the client, there
must be a other reason why it doesn't work. Maybe the other servers are
not reachable over the other interface.

   I just "tailed" the fhgfs-client.log files... It estabilishes a connection to the 12.x.x.x. net and begins to write, good so far...
   After I pull out the cable, it stops and after ~ 1 min it's estabilishing a connection to the 14.x.x.x net for the one node , that has lost the connection to the 12.x.x.x. net ( with fhgfs-net I can see that the client is actually connected to 14.x.x.x. net, it seems to be alright)...
   but it changes nothing, so the write process is still stopped until I put the cable in, so the client can connect to the 12.x.x.x. net...
   I am using a special tool to write/read the files, so maybe there are some incompatibility problems... do you maybe have any other easy way to test this feature?

   I mean in worst case I could try it with "Bonding" under RHEL, but it would be nice to know that I also can use this feature for some failover^^

   Best Regards,

   Ilya

Ricardo J. Barberis

unread,
Mar 5, 2013, 1:35:38 PM3/5/13
to fhgfs...@googlegroups.com
El Lunes 04/03/2013, Ilya Bychkov escribió:
> Did you use the absolute path to the config files (ConnNetFilterFile,
>
> > ConnInterfacesFile) in the fhgfs-client.conf, fhgfs-storage.conf,
> > fhgfs-mgmtd.conf and the fhgfs-meta.conf.
>
> It looks like:
>
> *ConnNetFilterFile = /root/Desktop/netfile*
>
> Is it right or should it be a .txt - File like *
> /root/Desktop/netfile.txt * ?
>
> > > _*ConnNetFilterFile*_ _*ConnInterfacesFile*_
> > > 12.0.0.1/24 eth0
> > > 14.0.0.1/24 eth1

I might be completely off here, but my gues is your clients are trying to
reach your 14.0.0.1/24 servers through eth0, as that's the preferred
interface, no matter the network (or tha's what I believe).

What happens if tou define only ConnNetFilterFile?

> > You are using strange IP-addresses. You are using public IP addresses
> > and not private IP addresses. Is your fhgfs working across the internet
> > or only in a local network?
>
> Why are they strange?^^ I have no connections to the public net
> (192.x.x.x), this adresses (12.x.x.x. / 14.x.x.x.) are private, so only my
> servers are communicating over this IP-Addresses...

They are strange beacuse those are publicly routable IP ranges, you shouldn't
use them for private networks.

According to whois, 12.0.0.0/8 belongs to AT&T, and 14.0.0.0/8 to Chinanet.

More info:

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml


> > Normally it works so easy. Look into the logfiles of the client, there
> > must be a other reason why it doesn't work. Maybe the other servers are
> > not reachable over the other interface.
>
> I just "tailed" the fhgfs-client.log files... It estabilishes a
> connection to the 12.x.x.x. net and begins to write, good so far...
> After I pull out the cable, it stops and after ~ 1 min it's
> estabilishing a connection to the 14.x.x.x net for the one node , that has
> lost the connection to the 12.x.x.x. net ( with fhgfs-net I can see that
> the client is actually connected to 14.x.x.x. net, it seems to be
> alright)...
> but it changes nothing, so the write process is still stopped until I
> put the cable in, so the client can connect to the 12.x.x.x. net...
> I am using a special tool to write/read the files, so maybe there are
> some incompatibility problems... do you maybe have any other easy way to
> test this feature?
>
> I mean in worst case I could try it with "Bonding" under RHEL, but it
> would be nice to know that I also can use this feature for some failover^^
>
> Best Regards,
>
> Ilya

One more debug: can youn 'ping -I eth0 14.0.0.X' and 'ping -I eth1 12.0.0.X'?

Cheers,
--
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - Dattatec.com

Frank Kautz

unread,
Mar 7, 2013, 3:49:36 AM3/7/13
to fhgfs...@googlegroups.com
Hello Ilya,

Am 03/05/2013 07:35 PM, schrieb Ricardo J. Barberis:
> El Lunes 04/03/2013, Ilya Bychkov escribi�:
>> Did you use the absolute path to the config files (ConnNetFilterFile,
>>
>>> ConnInterfacesFile) in the fhgfs-client.conf, fhgfs-storage.conf,
>>> fhgfs-mgmtd.conf and the fhgfs-meta.conf.
>>
>> It looks like:
>>
>> *ConnNetFilterFile = /root/Desktop/netfile*
>>
>> Is it right or should it be a .txt - File like *
>> /root/Desktop/netfile.txt * ?
>>
>>>> _*ConnNetFilterFile*_ _*ConnInterfacesFile*_
>>>> 12.0.0.1/24 eth0
>>>> 14.0.0.1/24 eth1

I think the configuration with ConnNetFilterFile and ConnInterfacesFile
works. You description in this email shows that both IP address networks
are used. Which behaviour do you expect?

>
> I might be completely off here, but my gues is your clients are trying to
> reach your 14.0.0.1/24 servers through eth0, as that's the preferred
> interface, no matter the network (or tha's what I believe).
>
> What happens if tou define only ConnNetFilterFile?
>
>>> You are using strange IP-addresses. You are using public IP addresses
>>> and not private IP addresses. Is your fhgfs working across the internet
>>> or only in a local network?
>>
>> Why are they strange?^^ I have no connections to the public net
>> (192.x.x.x), this adresses (12.x.x.x. / 14.x.x.x.) are private, so only my
>> servers are communicating over this IP-Addresses...

The IP address which you are using are not the cause for the problem you
might have. But the IP addresses which are you using let me assume that
you are using fhgfs across the Internet. You told me you do not use
fhgfs across the Internet, so I can rule out this as cause for the
problems which you might have.

>
> They are strange beacuse those are publicly routable IP ranges, you shouldn't
> use them for private networks.
>
> According to whois, 12.0.0.0/8 belongs to AT&T, and 14.0.0.0/8 to Chinanet.
>
> More info:
>
> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
> http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml
>

More information about the classification of IP addresses you could find
in the RFC1597 (http://tools.ietf.org/html/rfc1597).

>
>>> Normally it works so easy. Look into the logfiles of the client, there
>>> must be a other reason why it doesn't work. Maybe the other servers are
>>> not reachable over the other interface.
>>
>> I just "tailed" the fhgfs-client.log files... It estabilishes a
>> connection to the 12.x.x.x. net and begins to write, good so far...
>> After I pull out the cable, it stops and after ~ 1 min it's
>> estabilishing a connection to the 14.x.x.x net for the one node , that has
>> lost the connection to the 12.x.x.x. net ( with fhgfs-net I can see that
>> the client is actually connected to 14.x.x.x. net, it seems to be
>> alright)...

It works as designed. The client tries several times to connect to the
used IP address. After 90 seconds the client use the other interfaces.

>> but it changes nothing, so the write process is still stopped until I
>> put the cable in, so the client can connect to the 12.x.x.x. net...
>> I am using a special tool to write/read the files, so maybe there are
>> some incompatibility problems... do you maybe have any other easy way to
>> test this feature?

You could use the program dd. But your description above shows me that
it works. Start your program, pull the cable out and wait for the
fail-over. After the fail-over your program will work again and will
finish successful.

kind regards,
Frank
Reply all
Reply to author
Forward
0 new messages