Disk I/O thoughput of SAN disk arrays, application performance, isolation and ...

[Shivkumar]

Dear Sirs,

I am working on installing an application software on hpux server where some applications are already running.

we have got configured some new SAN file systems for installing new application.
Some of our team members are suggesting that componenents like JRE and oracle client
should go under defualt directory location.

I am of the opinion that we should be installing each and every component of the new application starting under the SAN file system already allocated (say, for example ) /opt/rose/pink/

Also, I am thinking that SAN file system has better I/O throughput than the direct attached disk drive. Second, installing all the application underneath one file system will enable us to know what are various application components installed for that particular application.

Some our team members suggested that if we install application components like JRE and oracle client in non-default file system (/opt/rose/pink/) it may cause shared memory issue but i don't agree with this suggestion and would like to know the opinions of the gurus and seasoned professionals of this forum.

Thanks,
Shiv

[Pete Randall · Accepted solution]

It is generally true that your SAN file systems will offer better performance. They also generally offer hot swap capability that your direct attached disks may not.

I am unable to see how the install location of any software will impact shared memory.


Pete

[A. Clay Stephenson]

1) Change "I am thinking that SAN file system has better I/O" to the "The SAN is or is not faster than direct attached disk". Do real measurements and then you can answer your own question and actually make a statement rather than "I am thinking". Only measurements made on your box can make that call. Even id the SAN is slower there may be valid reasons for installing there (space, data redundancy, ...)

2) In general, the shared memory issue is bunk; however, I can think of an example where deployment to the non-default path MIGHT cause a problem with shared memory. Typically IPCS (of which shared memory is a member) use the ftok() function to create a key. This function uses a pathname; poorly written software MIGHT make assumptions about the existence of that pathname and the call to ftok() might then return -1 indicating an error.

[Chan 007]

Shiv,

SAN gives a better I/O when compared.

I don't agree installing in non default locations will give shared memory problems.

Instead, not on all applications for few you may have to create a link as those applications are coded to use only those directories.

Also regarding having the applications I have one more thought, if the application is just a Application server sought, then I recon using Internal Disk. As they are just 20/25 GB & internal system will provide equally good performance for such a small application. Also saves 2 FC cart and 2 SAN ports and LUN..!!!

Chan

[Alzhy]

Shiv,

This is exactly the practice that we follow when we "grow" servers or co-host/co-locate applications on existing servers - locate the filesystem tree on a SAN storage so common components reside on one mount tree.

i.e.

/crm
-->/crm/jre
-->/crm/app
-->/crm/logs
-->/oracle
-->/oradata
-->/oraarch

with each segregated to each own filesystem. Generally, we use differennt/exclusive fibre channels to storage for a co-hosted storage tree. This allows for easy migration/DR of the applications to a different vPar/server.

JRE is one application component that can be safely relocated as the the Oracle client. In fact, JRE/Oracle client installations are aplenty on our typical server -- some bundled with whatever tool.software we are runinng hence have their own JAVAHOME or ORACLE_HOME, whatever.

I have not seen any UNIX canned application that is not flexible enought ot be relocated.