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".

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.


Kind regards

Ariano Bertacca
Systemmanagement


fon +49 211 7357-834 | fax +49 211 7357-859

-- 
Vereinigte Verlagsanstalten GmbH
Höherweg 278 | 40231 Düsseldorf
fon +49 211 7357-0 | fax +49 211 7357-123

HR Düsseldorf HRB 658
Geschäftsführer Stefan Meutsch




-------------------------------------------------------------------------
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