Guest Author: Ivo Dujmovic

Our documentation about sharing filesystems between multiple Oracle E-Business Suite Release 12 application servers recommends that you install the Instance Top (INST_TOP) on a local filesystem. This has prompted an interesting discussion about whether this is really mandatory, or whether it’s technically feasible to put the Instance Top on, say, a dedicated fibre-attached SAN. 

Release 12 shared filesystem:

Our guidance on the INST_TOP being installed on a local file system is based on three major considerations:

 
  1. Separation of duties and security implications
  2. Impact of SAN performance on Apache
  3. Additional troubleshooting complexity

1. Separation of Duties & Security Implications

Our recommended configuration allows for different file system privileges and ownership between the Instance Top (INST_TOP) and the Code Top (ORACLE_HOMEs & APPL_TOP). This allows for the segregation of duties between administrators for the respective servers. Patching can be done on the Code Top by central system administrators who own the central shared portion of the file system. Instance Tops can be owned by instance sysadmins, who usually already own the CPU box with local storage.

Some instance-specific, run-time-generated files (e.g. reports, temp files) can include unencrypted data. Contrast those with database files (DBFs), which can be self-encrypted or contain encrypted data. Even with encrypted file system solution in place, there is less depth in defenses around some of the INST_TOP files.

2. Impact of SAN Performance on Apache

Apache performance is highly sensitive to mutex file access latency, and at higher loads is also sensitive to I/Os per second.  We tried using a central SAN for INST_TOPs in our internal EBS development environments but found the performance to be unacceptable.  However, not all SANs are created equal, and depending on the SAN, it might be good for even production use.

A very good article on this point is available from the SQLTeam web site:

3. Additional Troubleshooting Complexity

A network storage access problem can have a spectrum of symptoms, including performance slow downs and even as intermittent end-user session failures. Some of the affected code paths were made more resilient over the years, but we still prefer to err on the side of prudence and not potentially cause these (hard to diagnose) problems.

Your Mileage May Vary

All that said, you might decide that your testing of SAN performance demonstrates that its latency and I/O transaction throughput are good enough for your requirements. 

Our Support and Development teams will attempt to reproduce any reported issues in a multinode environment where the INST_TOPs are stored on a local filesystem.  If the issues are isolated to the external placement of the Instance Tops, our recommendations would be to either revert back to local storage, or to work with your SAN vendor to optimize the SAN’s performance.

References

Related Articles