Running an Application on an NFS filesystem (Oracle APPS).

[Arboned]

Currently we are running one RAC database which is accessed by two instances running on two servers. The application is also running on both nodes using a seperate installation of the software. Our DBA'er asked me if there are options to share the application software. I immediatly thought of NFS, but is it wise ? It has to be Highly avaible using MC/SG. NFS is not the most flexible and how wil it perform, the uplink between te two systems is 1Gbit.
Are there other options ? All is running on HP-UX 11.11 (Superdomes). Thanx ... Giedo

[Massimo Bianchi · Accepted solution]

Hi,
I absolutely do NOT raccomend going towards oracle executables shared via NFS. A temporary network problem could crash BOTH the instances.

Local storage, for a RAC, is always advisable.


Why your dba want to share the executables ?

THe only reason i can immagine is for upgrading purpose, to avoid multiple patching. BTW, if i recall well, for RAC instances local executables are a prerequisite.



There would be some UNSUPPORTED ways, like sharing a read-only vg from both nodes, but no-one is going to certify such a solution.



After all, oracle APPS are aroung 6/9 Gb, not very much with todays disks.

HTH,
Massimo

[BONNAFOUS Jean Marc]

Hello,

NFS must be prohibit if NFS clients are Microsoft systems because ugly performances.

But NFS is natural solution for sharing ressources between UNIX systems on same network. Of course you must take account of performance. Performances can be dramatically impacted by memory, network throughput, disk performance,... See http://www.docs.hp.com/hpux/onlinedocs/1435/NFSPerformanceTuninginHP-UX11.0and11iSystems.pdf

Other option can be HP CIFS/Samba. I have never use it between two UNIX systems but between UNIX - WIndows, performances increase noticeably.

Rgds
JMB

[Bill Hassell]

Actually, it isn't desirable to share the executables, even if NFS was robust. By keeping the executables separate, an upgrade can be performed on one node but if necessary, a node switch can be performed to return to the current version. And most admins will tell you that NFS in a production system is risky at best. NFS can be badly affected by network traffic conditions and does not tolerate temporary outages very well at all (hangs applications and logins).

Performance for executables over NFS is nominal since the executable is only needed during startup and if necessary, during pagein after deactivation/pageout. Once the process is in memory, the executable file is virtually unused.

[Massimo Bianchi]

Hi,
just a little note to Bill's quote:

"upgrade can be performed on one node but if necessary, a node switch can be performed to return to the current version"

In theory, this is perfect, but with oracle database ( RAC ) you cannot do this easily, mainly for two reason:

- when upgrading, the datafiles and some tables in the db, are changed. The only supported way is to restore

- when upgrading, the catalog of oracle product is updated accordingly, and the only supported way is to restore


Obviously restore is easier, if you have a copt on the second note, but , for example, config files are different, and must resize on the host.

Regards,
Massimo

[Dave Olker]

Hi all,

I figured I'd weigh in here since NFS is being tossed around.

If you're looking at trying to server up application binaries via NFS and your concern is either performance or network availability, one possible thing to investigate is CacheFS.

CacheFS allows you to set aside some space in a local filesystem on the NFS client (one of the Superdomes in this case) and then cache the data read from the NFS server into the local filesystem. That way, once the data is populated in the local filesystem, the amount of data that needs to be retrieved from the NFS server is minimal.

CacheFS is ideally designed for something like serving application binaries because they are typically only read, not written to, and they tend to change very infrequently. Obviously they can change if a patch or an update is applied to the application on the NFS server, but on the whole, application binaries tend to remain static for long periods of time and are usually read-only.

With the HP-only CacheFS mount option "rpages", you can effectively run an application across a CacheFS filesystem once and it will populate the local filesystem with intact copies of the application binaries that were run . Any future access to these binaries will be satisfied from the local filesystem, with the only requests going to the NFS server for these files being LOOKUP or GETATTR requests to ensure that the version on the server has not changed.

Once the NFS client's local cache was populated, CacheFS would reduce the need for NFS requests for these files, and would therefore be less likely to suffer any ill effects from a busy network where requests may get lost. Also, with a populated cache, CacheFS would perform nearly identical to local filesystem performance since the binaries would reside on the client's filesystem.

Also, once the cache is populated with intact copies of the binaries, the cache would be able to survive a CacheFS filesystem unmount/remount or even a client system reboot. Since the cache is disk based, it should remain until the cache is forcibly deleted or if the cache disk/inode thresholds are exceeded.

Anyway, I figured I'd throw out a plug for CacheFS since it may be a viable option for serving application binaries in this environment.

If anyone has any questions about CacheFS or what it can do let me know.

Regards,

Dave

[Steve Kurtz]

I agree in that applications should not be spread across a connectionless link which is what nfs is. Any input on how to better do this? Any experience with sharable arrays or a clustered FS for Linux?

[TwoProc]

Since we are speaking of "Application" software (not the Oracle Database binaries), you can sync them via "rsync" at predetermined times at night (if available). Another option is "rdist" to accomplish same.

You can do this also with binaries of pure-client/middle-tier (non-database) ORACLE_HOMES. That is, ORACLE_HOMEs associated purely with the Application software, and not the database tier - as these can be separate even if hosted on the same box.

Of course, you have the danger of stepping on log files, etc. So, you have to protect them before the syncs, and move them off to a good log destination, or put them back afterwards, or leave them out of the rsync or rdist operation.

This type of syncing pretty much requires exact same layout on both machines, and virtual IP names as reference points to servers and services.

Using ssh tunnels can help make this process secure.