[OpenAFS] about failover - 2 servers (one "master" one replicas) - a bit long
Vladimir Konrad
v.konrad@lse.ac.uk
Mon, 22 Mar 2010 09:43:51 +0000
Hello,
I have 2 servers (lets called them A and B). The A holds all of the read/write
volumes, all of these volumes are replicated to B (read only). The OpenAFS services
run on both, in pretty much identical set-up. Both servers also have the OpenAFS clients.
[A]<--------------------------------------->[B]
read/write wolumes read only replicas (of the stuff on [A])
There are few linux desk-tops with OpenAFS clients which user these servers, and
also, the servers have OpenAFS clients on them.
The strange thing is, that when server B went down, pretty much everything went to halt,
e.g. periodic downloads running on A would not be able to write to AFS anymore a the
linux desktops would loose access to AFS.
The both servers run Debian Etch, the OpenAFS versions are:
A:
openafs-client 1.4.7.dfsg1-3~bpo40+1
openafs-dbserver 1.4.2-6etch2
openafs-fileserver 1.4.2-6etch2
B:
openafs-client 1.4.12 build from source
- this is recent addition, it was as in A: when crash happend
openafs-dbserver 1.4.2-6etch2
openafs-fileserver 1.4.2-6etch2
The clients are mix of different versions of debian, the OpenAFS clients on them would be mainly:
1.4.7.dfsg1-6+lenny2
1.4.2-6etch2
Would you please give me few pointers on what to try to have AFS clients work even if
the B goes down? Ideally, it should work even if A goes down and the read-only volumes
are converted to read/write.
It is quite possible I missed something when configuring this (switch,
option or something like that)...
Kind regards,
Vladimir
------
> because it reverses the logical flow of conversation + it is hard to follow.
>> why not?
>>> do not put a reply at the top of the message, please...
Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/planningAndCorporatePolicy/legalandComplianceTeam/legal/disclaimer.htm