On Tue, 24 Sep 2013 18:01:08 -0400 (EDT) [email protected] wrote: > - Is there any obvious reason to choose multihoming of a fileserver > rather than link aggregation, assuming both are supported in a given > environment?
I don't think so, except multihoming can be easier, since you don't need to do anything for it. I think multihoming can be worse in some situations, since if the server is actually down, a client may retry reaching it for every IP it knows about for the server, so it can take longer to notice. > - The Admin Guide on docs.openafs.org indicates that multihomed DB > servers work.[1] That link seems to be about fileserver multihoming, but I'm just skimming it. Regardless: > Specifically, I'm curious about linux dbservers; clients may contact > the server via IP A but get an answer from IP B, if it is the default > interface. Will the clients care? What if the IP replying isn't in the > client's CellServDB (or DNS) at all? Does the answer change depending > on client version? dbserver vs fileserver doesn't seem to matter for this. If a client initiates an rx connection to a certain IP, it can get a reply from any other IP and continue; I believe that was deliberately done because of the potential problems you're talking about. This occurs at a much lower level than stuff dealing with DNS or CellServDB, etc. This situation might be different if dbservers initiated new connections to clients, but they don't do that. Fileservers do that for callback breaks, but I don't think we currently pay attention to the source IP for those at all. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
