lynn said the following on 06/26/2012 05:08 AM:
On 26/06/12 10:31, Per Jessen wrote:
lynn wrote:
Hi
Let's say the nfs server has crashed. I have a backup on another machine in the same Kerberos realm. What's the quickest way I can get the LAN back up? Anyone done it by substituting another box? Are we talking minutes, hours. . .?
Try 'replicas' http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.co... IS that facility available in NFS4? The syntax reminds me of an article I read years ago about a NFS client being able to use a second destination if the first was unavailable. Something like mount -t nfs ip-server1,ip-server2:/home /home (See http://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch06_05.htm) Nothing to do with IP clustering, all done with NFS config syntax. That seems lost to us now ... ? My "Days in the SUN" are past :-) You might also check the applicability of RFC 3530 to your situation. (for example at nfsv4.bullopensource.org/doc/migration-and-replication-0.2.pdf) <quote> 1.4.3.3. Filesystem Replication and Migration With the use of a special file attribute, the ability to migrate or replicate server filesystems is enabled within the protocol. The filesystem locations attribute provides a method for the client to probe the server about the location of a filesystem. In the event of a migration of a filesystem, the client will receive an error when operating on the filesystem and it can then query as to the new file system location. Similar steps are used for replication, the client is able to query the server for the multiple available locations of a particular filesystem. From this information, the client can use its own policies to access the appropriate filesystem location. </quote> and <quote> 6.1. Replication It is expected that filesystem replication will be used in the case of read-only data. Typically, the filesystem will be replicated on two or more servers. The fs_locations attribute will provide the list of these locations to the client. On first access of the filesystem, the client should obtain the value of the fs_locations attribute. If, in the future, the client finds the server unresponsive, the client may attempt to use another server specified by fs_locations. </quote> I'm not happy about that 'read only' but don't know if its enforced or simply a precaution since the second server may not be 'up to date' or in phase with the first if they are both r/w. I suspect its a precaution. DRDB is about building high end clusters; surely there is a simple solution? -- ASCII stupid question, get a stupid ANSI -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org