Ariano Bertacca wrote:
> Am 04.06.2008 um 22:13 schrieb Martin Simmons:
>
>   
>>>> The client connects using the Address field of the Director's  
>>>> Storage
>>>> resource, so it doesn't have to be the fqdn, just something that  
>>>> resolves to
>>>> the correct IP address on all machines.
>>>>
>>>> What kind of syntax would you use in the Director's config to  
>>>> specify a
>>>> different name/ip for different clients?  Maybe it should allow a  
>>>> mapping from
>>>> the client's subnet to the SD address?
>>>>
>>>>
>>>>         
>>> I believe the problem is when SD is multi-homed. For example, the
>>> clients on the 10.1.2.0/24 network connect to the SD at 10.1.2.10 and
>>> the clients on 10.1.3.0/24 connect to the SD at 10.1.3.10.
>>>       
>> Yes, that is one case.  OTOH, you could make it more general, so  
>> that clients
>> on the x.x.x.x/X network should connect to a.a.a.a and those on the  
>> y.y.y.y/Y
>> should connect to b.b.b.b.  I.e. the IP for the SD might not be  
>> within the
>> client's own subnet, but it might still vary.
>>     
>
>
>
> I think that normal routing rules should be enough to find the right  
> ip. Since the server has (most probably) a default route, it should be  
> reachable using the interface that resides in the network with the  
> default gateway. The second network is only being used by directly  
> connected clients.
>
> Now when the dircetor has to give the name/ip to the client that has  
> to send the backup data, it could probably check from what network the  
> client connects and then make its decision based on the sd's routing  
> table.
>
> Since we have to think about having dir and sd on different machines,  
> the decision can't be made based on the directors local routing table,  
> but the dir could be asking the sd for it's data, or probably even  
> better, the sd could make the decision and let the director know, what  
> ip he should give to the client.
>
> Otoh it's probably easier to add a config statement to the FD that  
> contains the correct ip to connect to, overriding the storage config  
> from the director. Ugly solution, because it can lead to confusion  
> once the operator forgets what he has done, but that could be covered  
> by giving feedback to the director, when reporting error/success like  
> "contacting SD based on forced name/IP: 1.2.3.4".
>   

This would not work if there were multiple SDs.

> Personally i'd prefer the logic inside the sd, so that fd and dir  
> don't have to think about anything, as long as the storage ressource  
> contains a valid name/ip for the dir to contact the sd. Any other  
> decision would be made "on the fly", using the current routing table  
> on the sd and the clients ip.
>   

I'm not sure this is needed. I think all that is needed is to ensure 
name resolution does not return IPs that are unroutable. Views can be 
used in bind to return different answers to name queries depending on 
where the query came from. That seems the simplest way to handle 
multi-homed SDs and wouldn't require any changes to Bacula. It would 
only require the use of a FQDN for the Address directive in the 
Director's Storage resource and a DNS that never anwered with unroutable 
IPs. This would apply also to a multi-homed Director.

>
> Kind regards
>
> Ariano Bertacca
> Systemmanagement
>
>
> fon +49 211 7357-834 | fax +49 211 7357-859
>
>   

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users