The acceptable format for connNetFilterFile?

[zack....@sbcglobal.net]

I am tasked to run two BeeGFS deployment on the same subnet.  For discussion's sake, lets say it's 192.168.11.0/24.

1. The 1st one uses four nodes on 192.168.11.{100..103}
2. The 2nd one uses another four nodes on 192.168.11.{104..107}

How can I list the IP addresses for each deployment in the connNetFilterFile  (e.g. /etc/fhgfs/connection_networks) to keep BeeGFS services from the two deployments from confusing each other?

Thanks,

-- Zack

[Adam Brenner]

Zack,

I am not familiar with the connNetFilterFile setting but reading up on
the documentation[1] it sounds like connNetFilterFile is only useful
if you have more then one network interface and want to direct traffic
to use one or the other.

If that is the case, then connNetFilterFile sounds like the way to go.


However, if its the same interface but different BeeGFS deployments
then I think the simplest solution is to use the connPortShift
setting. This is what we use on our cluster. I am not sure if this is
what you are asking or if connNetFilterFile is better then
connPortShift.

If you want one client to be able to mount both BeeGFS instances, then
you will also need to enable Multi-Mode. The following past postings
should give you a good starting point [2][3] for connPortShift and
Multi-Mode.


[1]: http://www.fhgfs.com/wiki/FAQ#multiple_nics
[2]: https://groups.google.com/forum/#!topic/fhgfs-user/v5FWJjkyMcE
[3]: https://groups.google.com/forum/#!topic/fhgfs-user/N-MvsRPjdAs

Hope that helps,
-Adam

--
Adam Brenner
Computer Science, Undergraduate Student
Donald Bren School of Information and Computer Sciences
University of California, Irvine
www.ics.uci.edu/~aebrenne/
aebr...@uci.edu

[Christian Mohrbacher]

Hi,
if I understood correctly the two FhGFS installations are completely independent, so each deployment will have a seperate management daemon and there will be no cross mounts. In this case the deployments will not interfere each other, as they will use a seperate management daemon each.

But nevertheless, somewhere you mentioned that you have several network interfaces, so you might still need a netFilter (and probably a network interface file). If the nodes cannot communicate freely using any of the interfaces, you have to define which interface(s) is/ are allowed. You can do so by following the guide in the wiki: http://www.fhgfs.com/wiki/FAQ#multiple_nics

Regards,
Christian

Am 23.09.2014 um 01:37 schrieb fang...@zettar.com:

Adam,

Thanks for responding.

On Monday, September 22, 2014 3:45:54 PM UTC-7, aebrenne wrote:

[...]

Zack,

I am not familiar with the connNetFilterFile setting but reading up on
the documentation[1] it sounds like connNetFilterFile is only useful
if you have more then one network interface and want to direct traffic
to use one or the other.

Yes. All nodes have multiple NICs on different subnets.  So, we have to use connNetFilterFile.

 

If that is the case, then connNetFilterFile sounds like the way to go.

Yes.

 

However, if its the same interface but different BeeGFS deployments
then I think the simplest solution is to use the connPortShift
setting. This is what we use on our cluster. I am not sure if this is
what you are asking or if connNetFilterFile is better then
connPortShift.

Perhaps we can couple the two. The two deployments are on two small clusters of 4 nodes each.

If you want one client to be able to mount both BeeGFS instances, then
you will also need to enable Multi-Mode. The following past postings
should give you a good starting point [2][3] for connPortShift and
Multi-Mode.

No. We don't need clients to be able to mount from both deployments.  The four nodes of each cluster are also clients to their respective BeeGFS services.  No other clients.

 

[...]

-- Zack

 

--
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/d/optout.