Re: [Bacula-users] dual-NICs and traffic balancing
> > > The only way to prevent this behavior as I see it is to add static routes > > > on both internal network client and DIR/SD server to route all traffic > > > to/from external interface to internal one transparently for bacula > > > services. For this to work I would also need to enable routing on both > > > machines and reconfigure firewall on DIR/SD server. Not an elegant > > > solution by any means... > > > > The Director tells the FD the hostname of the SD. You put the hostname > > of the SD into the hosts file of the computer the FD is running on. When > > the client computer resolves the hostname of the SD it will check the > > hosts file first to see which address to connect to. > > Now I got it ;-). This may work if I edit hosts files on all of my dual-NIC > clients as well as on bacula server by substituting external IP address with > internal one for machines' own hostnames. This however will screw up hosts > resolution for all network applications and no doubt will have implications. > For one, mailing system will fail to work since it uses institutional mail > gateway on external network which is set up with strict security and will > hence reject messages from hostnames not registered in our DNS. There may be > other problems as well (OSCAR is rather picky about host name resolution). It > is most possible to work around these problems but I'd rather stick with the > static cross-routing for now. Sure, it will consume some CPU cycles to route > all traffic between two interfaces but at least it is as transparent as > possible solution. > > Thanks for the advice however and for being persistent with it! I admit my > brains have started to fail after two weeks of struggle with bacula ;-). If > static routing won't work as expected I may still give your suggestion a try No problem. But do note you only need to set up the hosts for the hostname of the SD, you shouldn't have to mess with any other hosts at all if they are already working. I've had to set mine up this way because my backup server has three networks it is a member of. To make it easy on myself, I call the SD "backup3" a name that will does not resolve in DNS for any server and is not used for any other purpose. Then on the client servers I only need one line added to the hosts: 172.30.0.253backup3 just changing the address depending on what network the client is on. -- Kenny Dail <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
> Now I got it ;-). This may work if I edit hosts files on all of my dual-NIC > clients as well as on bacula server by substituting external IP address with > internal one for machines' own hostnames. This however will screw up hosts > resolution for all network applications and no doubt will have implications. Isn't the only ip address needed in the host files is the one for the machine with the SD? Also I believe you can get away with using a second host name for the sd machine. John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
On Tuesday 21 August 2007 06:49:27 pm Kenny Dail wrote: > > > I use the client's hosts file to take care of directing the client to > > > the right address. > > > > This does not work for SD. There is no way to tell file client on which > > host SD resides. There is no such configuration option for FD. It gets > > this information from director and I can't configure director and SD on > > the server to only listen on internal interface because the majority of > > clients are on external network and they won't be able to reach SD in > > that case. If you think it works for you then grab tcpdump and check for > > yourself - it does not. FD indeed will connect via configured interface > > but then it will also connect to SD on whatever hostname/interface *SD* > > has in its configuration file and will proceed sending all file data and > > attributes via this interface, not the first one. Only commands exchange > > protocol between FD and the director will be carried over the > > FD-configured interface. > > > > The only way to prevent this behavior as I see it is to add static routes > > on both internal network client and DIR/SD server to route all traffic > > to/from external interface to internal one transparently for bacula > > services. For this to work I would also need to enable routing on both > > machines and reconfigure firewall on DIR/SD server. Not an elegant > > solution by any means... > > The Director tells the FD the hostname of the SD. You put the hostname > of the SD into the hosts file of the computer the FD is running on. When > the client computer resolves the hostname of the SD it will check the > hosts file first to see which address to connect to. Now I got it ;-). This may work if I edit hosts files on all of my dual-NIC clients as well as on bacula server by substituting external IP address with internal one for machines' own hostnames. This however will screw up hosts resolution for all network applications and no doubt will have implications. For one, mailing system will fail to work since it uses institutional mail gateway on external network which is set up with strict security and will hence reject messages from hostnames not registered in our DNS. There may be other problems as well (OSCAR is rather picky about host name resolution). It is most possible to work around these problems but I'd rather stick with the static cross-routing for now. Sure, it will consume some CPU cycles to route all traffic between two interfaces but at least it is as transparent as possible solution. Thanks for the advice however and for being persistent with it! I admit my brains have started to fail after two weeks of struggle with bacula ;-). If static routing won't work as expected I may still give your suggestion a try. --Ivan The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
> > I use the client's hosts file to take care of directing the client to > > the right address. > > This does not work for SD. There is no way to tell file client on which host > SD resides. There is no such configuration option for FD. It gets this > information from director and I can't configure director and SD on the server > to only listen on internal interface because the majority of clients are on > external network and they won't be able to reach SD in that case. If you > think it works for you then grab tcpdump and check for yourself - it does > not. FD indeed will connect via configured interface but then it will also > connect to SD on whatever hostname/interface *SD* has in its configuration > file and will proceed sending all file data and attributes via this > interface, not the first one. Only commands exchange protocol between FD and > the director will be carried over the FD-configured interface. > > The only way to prevent this behavior as I see it is to add static routes on > both internal network client and DIR/SD server to route all traffic to/from > external interface to internal one transparently for bacula services. For > this to work I would also need to enable routing on both machines and > reconfigure firewall on DIR/SD server. Not an elegant solution by any > means... The Director tells the FD the hostname of the SD. You put the hostname of the SD into the hosts file of the computer the FD is running on. When the client computer resolves the hostname of the SD it will check the hosts file first to see which address to connect to. -- Kenny Dail <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
On Tuesday 21 August 2007 04:47:41 pm Kenny Dail wrote:
> > On Friday 17 August 2007 04:46:24 pm you wrote:
> > > > where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> > > > server's external address; 192.168.0.{253,200} are the corresponding
> > > > private addresses. As you can see, while fd daemon on client has
> > > > indeed been bound to the private address, it still uses external one
> > > > for communicating with sd daemon on the remote bacula server. I've
> > > > been through all configuration options to no avail. Unfortunately,
> > > > binding sd on the server to private net only is not an option since
> > > > it also has numerous other clients configured, that are only
> > > > accessible via external net (desktop boxes all around the building,
> > > > etc). Is there any solution? I am running bacula 1.36.1.
> > >
> > > The FD is told to connect to the "Address" from the Director's Storage
> > > resource, so maybe you can set that to something that resolves to the
> > > internal network on the dual-NIC clients?
> >
> > AFAIK, in this case SD will always attempt to connect via internal
> > network upon request from any clients and that won't work for (the
> > majority of) my clients that are on external network. I am assuming there
> > is no way to specify multiple aliases for the same Storage resource in
> > bacula-dir.conf, but with different Addresses. Anyway, such setting
> > clearly belongs to client's configuration, so I consider it a bug. FD
> > should ensure that all of its communications with other daemons go
> > exclusively through the network address specified in its conf file (if
> > any). But I have no clue how to implement this since current bacula
> > networking model obviously contradicts.
>
> I use the client's hosts file to take care of directing the client to
> the right address.
This does not work for SD. There is no way to tell file client on which host
SD resides. There is no such configuration option for FD. It gets this
information from director and I can't configure director and SD on the server
to only listen on internal interface because the majority of clients are on
external network and they won't be able to reach SD in that case. If you
think it works for you then grab tcpdump and check for yourself - it does
not. FD indeed will connect via configured interface but then it will also
connect to SD on whatever hostname/interface *SD* has in its configuration
file and will proceed sending all file data and attributes via this
interface, not the first one. Only commands exchange protocol between FD and
the director will be carried over the FD-configured interface.
The only way to prevent this behavior as I see it is to add static routes on
both internal network client and DIR/SD server to route all traffic to/from
external interface to internal one transparently for bacula services. For
this to work I would also need to enable routing on both machines and
reconfigure firewall on DIR/SD server. Not an elegant solution by any
means...
--Ivan
The information transmitted in this electronic communication is intended only
for the person or entity to whom it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
information in error, please contact the Compliance HelpLine at 800-856-1983
and properly dispose of this information.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
> On Friday 17 August 2007 04:46:24 pm you wrote:
> > > where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> > > server's external address; 192.168.0.{253,200} are the corresponding
> > > private addresses. As you can see, while fd daemon on client has indeed
> > > been bound to the private address, it still uses external one for
> > > communicating with sd daemon on the remote bacula server. I've been
> > > through all configuration options to no avail. Unfortunately, binding sd
> > > on the server to private net only is not an option since it also has
> > > numerous other clients configured, that are only accessible via external
> > > net (desktop boxes all around the building, etc). Is there any solution?
> > > I am running bacula 1.36.1.
> >
> > The FD is told to connect to the "Address" from the Director's Storage
> > resource, so maybe you can set that to something that resolves to the
> > internal network on the dual-NIC clients?
>
> AFAIK, in this case SD will always attempt to connect via internal network
> upon request from any clients and that won't work for (the majority of) my
> clients that are on external network. I am assuming there is no way to
> specify multiple aliases for the same Storage resource in bacula-dir.conf,
> but with different Addresses. Anyway, such setting clearly belongs to
> client's configuration, so I consider it a bug. FD should ensure that all of
> its communications with other daemons go exclusively through the network
> address specified in its conf file (if any). But I have no clue how to
> implement this since current bacula networking model obviously contradicts.
>
I use the client's hosts file to take care of directing the client to
the right address.
--
Kenny Dail <[EMAIL PROTECTED]>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
Ivan Adzhubey wrote:
> Hi Martin,
>
> On Friday 17 August 2007 04:46:24 pm you wrote:
>>> where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
>>> server's external address; 192.168.0.{253,200} are the corresponding
>>> private addresses. As you can see, while fd daemon on client has indeed
>>> been bound to the private address, it still uses external one for
>>> communicating with sd daemon on the remote bacula server. I've been
>>> through all configuration options to no avail. Unfortunately, binding sd
>>> on the server to private net only is not an option since it also has
>>> numerous other clients configured, that are only accessible via external
>>> net (desktop boxes all around the building, etc). Is there any solution?
>>> I am running bacula 1.36.1.
>> The FD is told to connect to the "Address" from the Director's Storage
>> resource, so maybe you can set that to something that resolves to the
>> internal network on the dual-NIC clients?
>
> AFAIK, in this case SD will always attempt to connect via internal network
> upon request from any clients and that won't work for (the majority of) my
> clients that are on external network. I am assuming there is no way to
> specify multiple aliases for the same Storage resource in bacula-dir.conf,
> but with different Addresses. Anyway, such setting clearly belongs to
> client's configuration, so I consider it a bug. FD should ensure that all of
> its communications with other daemons go exclusively through the network
> address specified in its conf file (if any). But I have no clue how to
> implement this since current bacula networking model obviously contradicts.
>
IMO, I dont think it counts as a Bacula bug.
You've bound the FD to the internal network, but are telling to to talk
to an address on the external one.
It's the networking on the FDs host that is deciding to go out the
external interface, as that's the only way it knows to reach the
external SD address.
I'm not sure the FD has any control over this behavior at all. Even if
it does, the default behaviour of 'reach the sd regardless so we get
this critical backup completed' is desirable in a backup solution.
You could try setting up 2 SDs on the one box, one internal, one
external, but if you are using tapes for backups you'll have to resolve
resource conflicts possibly.
Anyone know if having 2 Storage resources in the directors conf, point
to one actual SD has a chance of working?
It's not something I've tried, so I have no idea personally.
Only other suggestion I have is hostname based resolution. Use
'Address=StorageDaemonHostName' and have entries in the host files on
your 'internal clients' that map this to the internal address. Have your
DNS map it by default to the external address for your external clients
use, and see how it goes.
Just a thought,
Cheers,
Troy.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
Hi Martin,
On Friday 17 August 2007 04:46:24 pm you wrote:
> > where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> > server's external address; 192.168.0.{253,200} are the corresponding
> > private addresses. As you can see, while fd daemon on client has indeed
> > been bound to the private address, it still uses external one for
> > communicating with sd daemon on the remote bacula server. I've been
> > through all configuration options to no avail. Unfortunately, binding sd
> > on the server to private net only is not an option since it also has
> > numerous other clients configured, that are only accessible via external
> > net (desktop boxes all around the building, etc). Is there any solution?
> > I am running bacula 1.36.1.
>
> The FD is told to connect to the "Address" from the Director's Storage
> resource, so maybe you can set that to something that resolves to the
> internal network on the dual-NIC clients?
AFAIK, in this case SD will always attempt to connect via internal network
upon request from any clients and that won't work for (the majority of) my
clients that are on external network. I am assuming there is no way to
specify multiple aliases for the same Storage resource in bacula-dir.conf,
but with different Addresses. Anyway, such setting clearly belongs to
client's configuration, so I consider it a bug. FD should ensure that all of
its communications with other daemons go exclusively through the network
address specified in its conf file (if any). But I have no clue how to
implement this since current bacula networking model obviously contradicts.
Cheers,
Ivan
The information transmitted in this electronic communication is intended only
for the person or entity to whom it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
information in error, please contact the Compliance HelpLine at 800-856-1983
and properly dispose of this information.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
> On Thu, 16 Aug 2007 16:36:48 -0400, Ivan Adzhubey said:
>
> Hi,
>
> I am having trouble with my dual-NIC servers: it seems there is no way to
> force bacula client on a remote server use a particular fixed
> interface/address for data transfers. Even though I have set FDAddress to a
> preferred one in bacula-fd.conf on the client, it will still bind to a wrong
> interface to do the actual file data transfer. The problem is, the unwanted
> interfaces are the ones on external 100Mbit/s network which is much slower
> than a dedicated Gigabit private LAN which I want bacula-fd to use. I noticed
> this problem while doing full backup of a large file tree, which was spooling
> at ca. 10Mbyte/s instead of expected 100Mbyte/s. I then confirmed it by
> looking at the output of lsof command on the remote client during initial
> spooling phase (running only bacula-fd):
>
> # lsof -n |grep bacula|grep IPv4
> bacula-fd 16145 root3u IPv4 115553 TCP
> 192.168.0.253:bacula-fd (LISTEN)
>
> bacula-fd 16145 root4u IPv4 115584
> TCP 192.168.0.253:bacula-fd->192.168.0.200:33119 (ESTABLISHED)
>
> bacula-fd 16145 root5u IPv4 115585
> TCP x.x.x.227:43711->x.x.x.136:bacula-sd (ESTABLISHED)
>
> where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> server's
> external address; 192.168.0.{253,200} are the corresponding private
> addresses. As you can see, while fd daemon on client has indeed been bound to
> the private address, it still uses external one for communicating with sd
> daemon on the remote bacula server. I've been through all configuration
> options to no avail. Unfortunately, binding sd on the server to private net
> only is not an option since it also has numerous other clients configured,
> that are only accessible via external net (desktop boxes all around the
> building, etc). Is there any solution? I am running bacula 1.36.1.
The FD is told to connect to the "Address" from the Director's Storage
resource, so maybe you can set that to something that resolves to the internal
network on the dual-NIC clients?
__Martin
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] dual-NICs and traffic balancing
Hi,
> where x.x.x.227 is client's external NIC address, x.x.x.136 is bacula
> server's
> external address; 192.168.0.{253,200} are the corresponding private
> addresses. As you can see, while fd daemon on client has indeed been bound to
> the private address, it still uses external one for communicating with sd
> daemon on the remote bacula server. I've been through all configuration
> options to no avail. Unfortunately, binding sd on the server to private net
> only is not an option since it also has numerous other clients configured,
> that are only accessible via external net (desktop boxes all around the
> building, etc). Is there any solution? I am running bacula 1.36.1.
>
I had a similar problem and solved it by making the SD listen on the
'backup network' address only. I then added routing entries on the
servers that dont have direct access to this address telling them they
could find the backup network via the SD machine.
When those machines try to reach the SD this routes them to the
appropriate box.
I only had a handful of these machines so adding this to each wasn't hard.
Cheers,
Troy.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
