I had a chance conversation with an Apps sysadmin late in the evening at the Collaborate conference. He wearily noted that he had to somehow cover increasing maintenance costs with reduced levels of staffing. The conversation suggested that our support for shared E-Business Suite application tier file systems may be one of our better-kept secrets. If you haven't come across this yet, here's a way of reducing the amount of time that you spend patching.
Scaling Up with Load-Balancers
When your E-Business Suite user base grows beyond a certain size, it's likely that you'll look into deploying multiple application servers in a load-balanced pool of nodes. Your deployment topology might look like this:
Regardless of whether you're running Release 11i or 12, each of these
nodes would need its own disk space and would to be maintained and
patched separately. What a pain.
Different File System Structures in Release 11i and 12
In Release 11i, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (8.0.6 and iAS ORACLE_HOMEs). In a traditional deployment, each one of these application servers would have its own Applications file system, like this:
In Release 12, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (10.1.2 and 10.1.3 ORACLE_HOMEs), plus a new INST_TOP. Each node would have the following:
Enter the Shared Application Tier File System
For Release 11i, starting with 11.5.10, it's possible to put the Applications tier file system on a shared disk resource mounted to each Application tier server node in the system, like this:
Similarly, in Release 12, you could put the Applications tier file system on a shared disk resource mounted to each Application tier server node, like this:
Migrating to Shared File Systems
There are a few prerequisites:
If you've gotten to this point, you're probably wondering, "Is my _____ SAN/NAS shared file system software certified with the E-Business Suite?" File system solutions that customers have recently asked about include:
The short answer is that your shared file system solution is supported but not certified with the E-Business Suite, for either Release 11i or 12. Remember that there's a key distinction between support and certification, which I've covered in detail in this article:
The complexities of whatever shared disk resource management solution that you're using must be transparent to the E-Business Suite. Aside from that, there aren't any special requirements for shared disk resources. They can be local to the server or on a standalone disk array.
Almost Irresistible
Regardless of which E-Business Suite release you're running, the main advantage of using an Application shared file system is simplicity and ease of patching: when you apply patches or changes to the shared disk resource, they're immediately visible on all application tier server nodes. You patch in a single place and deploy those changes across multiple servers. You save disk space for each additional application node you deploy, and it's easier to deploy additional nodes, too.
If you've been wondering how to squeeze more productivity out a packed roster of administration activities, I'd recommend setting up a testbed to try this out. Feel free to post a comment with your experiences with this; I'll make sure your feedback gets back our team.
Related
When your E-Business Suite user base grows beyond a certain size, it's likely that you'll look into deploying multiple application servers in a load-balanced pool of nodes. Your deployment topology might look like this:
Different File System Structures in Release 11i and 12
In Release 11i, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (8.0.6 and iAS ORACLE_HOMEs). In a traditional deployment, each one of these application servers would have its own Applications file system, like this:
In Release 12, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (10.1.2 and 10.1.3 ORACLE_HOMEs), plus a new INST_TOP. Each node would have the following:
For Release 11i, starting with 11.5.10, it's possible to put the Applications tier file system on a shared disk resource mounted to each Application tier server node in the system, like this:
Similarly, in Release 12, you could put the Applications tier file system on a shared disk resource mounted to each Application tier server node, like this:
Migrating to Shared File Systems
There are a few prerequisites:
- Different nodes must be running the same operating system and the same O/S patches
- You must be on a UNIX platform (Windows doesn't support shared file systems)
If you've gotten to this point, you're probably wondering, "Is my _____ SAN/NAS shared file system software certified with the E-Business Suite?" File system solutions that customers have recently asked about include:
- Sun StorageTek QFS or Sun Solaris ZFS
- Red Hat Linux Global File System
- Symantec / VERITAS File System (VxFS)
- Network File System (NFS) mounted disk or a disk array
The short answer is that your shared file system solution is supported but not certified with the E-Business Suite, for either Release 11i or 12. Remember that there's a key distinction between support and certification, which I've covered in detail in this article:
The complexities of whatever shared disk resource management solution that you're using must be transparent to the E-Business Suite. Aside from that, there aren't any special requirements for shared disk resources. They can be local to the server or on a standalone disk array.
Almost Irresistible
Regardless of which E-Business Suite release you're running, the main advantage of using an Application shared file system is simplicity and ease of patching: when you apply patches or changes to the shared disk resource, they're immediately visible on all application tier server nodes. You patch in a single place and deploy those changes across multiple servers. You save disk space for each additional application node you deploy, and it's easier to deploy additional nodes, too.
If you've been wondering how to squeeze more productivity out a packed roster of administration activities, I'd recommend setting up a testbed to try this out. Feel free to post a comment with your experiences with this; I'll make sure your feedback gets back our team.
Related
- Sharing the Application Tier File System in Oracle E-Business Suite 11i (Metalink Note 233428.1)
- Sharing the Application Tier File System in Oracle E-Business Suite Release 12 (Metalink Note 384248.1)
- In-Depth: Load-Balancing E-Business Suite Environments
- Advanced Configurations and Topologies for Enterprise Deployments of E-Business Suite 11i (Note 217368.1)
- Using Load-Balancers with Oracle E-Business Suite Release 12 (Metalink Note 380489.1)
Comments (18)
Hi, I've used this shared everything under 11.5.10.2 and highly recommend it. My only points of note are:
1. After applying a patch on the master server, if autoconfig was run as part of the patch, ensure autoconfig is run on the other servers.
2. Ensure your disk configuration includes mirroring because you are effectively reducing some of your "redundancy" with this configuration.
3. Be aware that anything that is server specific (including modifications) at the filesystem level need to be sympathetic to your configuration.Gareth
Posted by Gareth Roberts | May 9, 2007 8:24 PM
Posted on May 9, 2007 20:24
Nice post .. I was wondering during autoconfig patch (or any patch which updates context file), How context file (on other servers) is updated ?
Posted by Atul Kumar | May 10, 2007 9:36 AM
Posted on May 10, 2007 09:36
Hi, Atul,If you're applying a patch that requires AutoConfig to be run:To a multi-node environment that doesn't use a shared file system, you need to run AutoConfig on each of the application tier nodes. To a multi-node environment that uses a shared file system, you need to AutoConfig on each of the application tier nodes if you apply a TXK/ADX or any other product patch that brings in configuration changes. This particular point is documented in Note 233428.1 in Section 6.Regards,Steven
Posted by Steven Chan | May 10, 2007 4:11 PM
Posted on May 10, 2007 16:11
All excellent points, Gareth. Thanks for posting those tips. I think that our official documentation should be updated with some of these points. I'll work with the team to get these updates into a future version of our Notes.Regards,Steven
Posted by Steven Chan | May 10, 2007 4:14 PM
Posted on May 10, 2007 16:14
Does anybody have more details about INST_TOP and any documentation about it and any other new?
Thanks & Regards,
Carlos
Posted by Carlos Duarte | May 11, 2007 7:27 AM
Posted on May 11, 2007 07:27
Carlos,
If I find the time, I'll try to write an article as an introduction to this new R12 concept, too. Until then, more information about the Release 12 file system layout can be found in a couple of places. The first link covers this in a lot of detail:
Oracle Applications 12 Concepts Guide (OTN, PDF, 1.3 MB)Metalink Note 384248.1 (with particular details on shared file system implications)Regards,Steven Regards,Steven
Posted by Steven Chan | May 11, 2007 12:47 PM
Posted on May 11, 2007 12:47
Thanks Steven for your prompt reply, What I meant by my questions is that, if I apply an autoconfig patch from node1 which updates context file so this patch will update SID_node1.xml in $APPL_TOP on shared file system.
How these changes will be introduced in SID_node2.xml so that I can run autoconfig from node2.
Is patch update context parameters in database and with each execution of autoconfig context file is synched with database ?
or patch physically update context file which the update context file copy stored in database ?
Posted by Atul Kumar | May 13, 2007 1:02 PM
Posted on May 13, 2007 13:02
nice post, but i have qustion,
if i have multi-node installation for 2 nodes, the first node has DB, CM, Admin and the second node has froms and web. dose this can be consider for shared appl_top or shard application file system, i mean is it feasible? from my reading i guess it should be at least more than one froms/web nodes is that correct?
thanks
fadi
Posted by Fadi Hasweh | May 14, 2007 2:21 AM
Posted on May 14, 2007 02:21
Fadi,
The shared file system approach is intended to support sharing between multiple application tier server nodes. There's no advantage in setting this up if you only have one node running Forms.
Regards,Steven
Posted by Steven Chan | May 15, 2007 11:51 AM
Posted on May 15, 2007 11:51
Atul,Your first point neatly outlines the reason why we require AutoConfig to be run on all application tier server nodes. This is due to a known functional limitation in the way ADpatch and AutoConfig work together. We're tracking this as a possible enhancement in future versions of AutoConfig.In answer to your second question: each AutoConfig run updates the context file on the file system, then uploads the same into the database.Regards,Steven
Posted by Steven Chan | May 17, 2007 11:18 AM
Posted on May 17, 2007 11:18
Thanks steven for clarifying this.
Posted by Atul Kumar | May 29, 2007 3:51 PM
Posted on May 29, 2007 15:51
Steven,
Sorry for bugging you again with same question but when one apply autoconfig patch it will update context file of that node only & not other node context file (This is my understanding of autopatch, If patch updates all xml files then it makes sense to execute autoconfig i.e. after changes are introduced)
But if autopatch is going to update xml file only for node on which patch is applied so that changes will not be in xml file of other node .
If changes are not in xml file on other nodes how running of autoconfig (without new chnages in xml) will serve purpose ..
I hope I have not confused you :-(
Posted by Atul Kumar | May 29, 2007 3:56 PM
Posted on May 29, 2007 15:56
Steven,
any update to the question asked by atul
Regards,
Subbu
Posted by Subbu | August 25, 2007 4:23 AM
Posted on August 25, 2007 04:23
i am eager to know the answer for what atul asked above...
regards,
subbu
Posted by Subbu | August 25, 2007 4:24 AM
Posted on August 25, 2007 04:24
Hi Steven,
We are implementing eBusiness Suite 11.5.10.2 on Linux x86.
We already have shared APPL_TOP using NFS shared filesystem (our storage is NetApp).
We are about to replace our storage to EMC and we need to look for other alternative for shared filesystem.
We would like to use Veritas 5.0 for that but we were told by the local Symantec personal that Veritas 5.0 is not supported on Linux 32bit.
Is it correct ?
I know there is such a limitation for Oracle RAC, does it also exist for shared APPL_TOP ?
Revital
Posted by Revital Altshuler | June 1, 2009 4:45 AM
Posted on June 1, 2009 04:45
Hi, Revital,
I'm afraid that I don't have a lot of visibility into platform-specific questions about third-party filesystems like Veritas 5.0. We do not specifically certify or test Veritas with EBS, so I don't have any hands-on experience with this technology.
You might wish to investigate this further with Veritas Support to understand the limitations around this technology.
Regards,
Steven
Posted by Steven Chan | June 1, 2009 2:30 PM
Posted on June 1, 2009 14:30
Hi atul, I notice that this may be a dead thread but I belive the answer to your question is that when you run autoconfig and chek the log you will notice that there is a preliminary stage where it says updating contect values int he databse. at that point if the database has a higher serrial number than the filesystem file then the filesystem contect file will be updated by the values in the database ( i assume not all of the values. this will then result in createion of an updated xml file. in fact the xml file is rewritten every time you run autoconfig
Posted by Robin Chatterjee | August 10, 2009 6:08 AM
Posted on August 10, 2009 06:08
Hi, Robin,
Thanks for your comment; I appreciate your dusting off this old thread.
Regards,
Steven
Posted by Steven Chan
|
August 10, 2009 10:19 AM
Posted on August 10, 2009 10:19