Reducing Patching Downtimes via Shared Apps File Systems

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:

Generic Apps Load-balancing:

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:

Distributed Application Tier Filesystem:

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:

Release 12 application tier structure 2:

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:

Shared Application tier file system:

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:

Release 12 shared filesystem:

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)
Certification of Shared File System Solutions

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:
Supported but not Certified

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.

References
Related Articles
Comments:

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 on May 09, 2007 at 01:24 PM PDT #

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 on May 10, 2007 at 02:36 AM PDT #

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 on May 10, 2007 at 09:11 AM PDT #

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 on May 10, 2007 at 09:14 AM PDT #

Does anybody have more details about INST_TOP and any documentation about it and any other new?

Thanks & Regards,
Carlos

Posted by Carlos Duarte on May 11, 2007 at 12:27 AM PDT #

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 on May 11, 2007 at 05:47 AM PDT #

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 on May 13, 2007 at 06:02 AM PDT #

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 on May 13, 2007 at 07:21 PM PDT #

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 on May 15, 2007 at 04:51 AM PDT #

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 on May 17, 2007 at 04:18 AM PDT #

Thanks steven for clarifying this.

Posted by Atul Kumar on May 29, 2007 at 08:51 AM PDT #

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 on May 29, 2007 at 08:56 AM PDT #

Steven,

any update to the question asked by atul

Regards,
Subbu

Posted by Subbu on August 24, 2007 at 09:23 PM PDT #

i am eager to know the answer for what atul asked above...

regards,
subbu

Posted by Subbu on August 24, 2007 at 09:24 PM PDT #

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 on May 31, 2009 at 09:45 PM PDT #

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 on June 01, 2009 at 07:30 AM PDT #

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 on August 09, 2009 at 11:08 PM PDT #

Hi, Robin,

Thanks for your comment; I appreciate your dusting off this old thread.

Regards,
Steven

Posted by Steven Chan on August 10, 2009 at 03:19 AM PDT #

I have a question regarding Shared APPL_TOP in a four node

Node 1 : Database - In App-DB DMZ

Node 2: Application Server 1 (Web/forms/Other Services etc) - IN App-DB DMZ
Node 3: Application Server 2 (Concurrent Manager) - IN App-DB DMZ

Node 3: Application Server 3 ( iModule) - IN Web DMZ

I would like to use Shared Application Tier File system (NFS) between all the application servers. Since our Application Server 3 will be deployed on Web DMZ(No NFS Between App-DB DMZ and Web DMZ), how can we implement Shared Application Tier File system. Chances of opening NFS Port between App-DB DMZ and Web DMZ is very slim

Is it possible to keep a copy of the "Shared File System" in Node 3 instead of NFS (And Manually sync it from the Primary Server using file system copy after each Patch).

Also, If I do this, would it be supported by oracle (Not Certified)?

Posted by Saji Jose on March 26, 2010 at 06:33 AM PDT #

Hi, Saji,

You can share the APPL_TOP between Nodes 2 and 3, since they're inside your intranet.

You must not share that APPL_TOP with Node 3. Node 3 should have its own APPL_TOP on a local filesystem. I would recommend maintaining this APPL_TOP in the same manner that you'd maintain a standalone application server. I would generally advise against copying the shared filesystem used by Nodes 2 and 3.

Regards,
Steven

Posted by Steven Chan on March 30, 2010 at 02:02 AM PDT #

Steve,
I would like ask a question on this old thread to clarify a position. I noticed that after a shared file system deployment, patches applied through the master node would fail to apply completely, unless changes are made to ad component
of the adconfig.txt file. i.e the xml file of the master node.

YES
YES
YES
YES

Effectively, making the context file to reflect a single node configuration. Is this the best way to work this out or I needed to do something else to ensure the patches are apllied correctly on all the three node?

Posted by Clive on November 17, 2010 at 06:13 AM PST #

Clive,

That doesn't sound like the behaviour that I'd expect in that situation. I'd like to have someone in our team look into this to see whether it's specific to your configuration or whether there's something deeper going on. Can you log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our adpatch specialists engaged?

Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.

Regards,
Steven

Posted by Steven Chan on November 17, 2010 at 06:34 AM PST #

Steve,
I found the answer to my question on this note:
Apply Patches in a Shared Application Tier File System Environment [ID 745580.1]

Thanks,

Clive

Posted by Clive on November 18, 2010 at 04:58 AM PST #

Hi Steve,

I know this is an old thread but I think a very important question around patching in Shared Application Tier (asked by someone in the thread) is still not completely answered.
The question --
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.

One proposed answer was --
Autoconfig checked the serial number of the database context and the file-system context and then updates the context file on the file-system if its on a lower version.

Is it really the case? I always thought that autoconfig actually updates/builds the context file from the autoconfig template files? and hence would like to clarify if it would ever compare the context values in the database and update them in the context file on the file server (in case they were on a lower version)?

Thanks,
Arvind

Posted by guest on September 02, 2012 at 03:18 PM PDT #

Guest,
adpatch generally does not update the "values" of a context file directly. Patches usually update templates. After the file is updated by adpatch, the autoconfig portion automatically launched from the patch session will replicate the templates into configuration files. The same applies for the context file. Having said that, if for some reason, a patch changes the setting of a context variable (which I really don't recall any particular case) then the autoconfig portion will update it in the database first and second it will also update the context file on the node where autoconfig was executed. If that is the case for a patch, autoconfig should be executed separately on all the nodes to make sure the configuration is transported. If such a patch exists, the README should include this clarification.
Regardless of this particular use case, it is always recommended to run autoconfig on all the nodes to assure consistency.

Posted by guest on September 04, 2012 at 11:44 AM PDT #

Additionally, the template of the context file is treated as any other file in EBS. If it has a lower version than the patch, then adpatch will replace the file and run AC. If the version in the file system is higher, then all the actions are skipped including the AC phase.
Adpatch has a smart criteria to run AC. In the same way, the AC phase will not be launched from adpatch if the files included in the patch don't belong to the "autoconfig template" category. In other words if a patch includes another file type not related with AC (ie .o file for binaries) then it will not run AC because is not necessary.

Posted by Max Arderius on September 05, 2012 at 06:53 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today