Where Should EBS Concurrent Managers be Located?

This FAQ topic continues to bounce around, suggesting that this needs to be called out explicitly:

EBS concurrent managers do not need to be installed on database servers any more.

Nick Quarmby correctly noted this as one of five common mistakes that customers make when installed the E-Business Suite:

COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.

Where is this correctly documented?

This is currently noted in our official documentation here:

  • Oracle E-Business Suite Technology Stack Release Notes for Release 12.1.3 [ID 1098650.1]
2.6 Updated Architectural Guidance

With fast local networks and the typical co-location of database and application tier machines, it is now generally preferable to perform concurrent processing on a separate machine from the database. This facilitates ease of management and maintenance, and provides deployment flexibility.

This is updated guidance is already reflected in our 12.1.3 Concepts Guide and Installation Guides, and will continue to be included in future versions of our documentation.

A shibboleth of sorts

Interestingly, this question is a bit of a shibboleth in the EBS sysadmin community.  DBAs who instinctively place the concurrent processing server on the same physical server as the database have been around a long time -- before gigabit network speeds made the placement irrelevant.

In fact, sharp-eyed readers might notice that this is incorrectly-documented even in some versions of our official R12 Installation Guides, which may state erroneously: "Batch Processing services must be installed on the same node as the database."

This is a documentation artifact from a bygone time.  This guidance doesn't apply any longer.


Comments:

Having concurrent node along with DB sever is not a harm if it is not an exceptionally busy system. As in batch processing most of the work is done by the DB and there is very little application server side processing. Only disadvantage is patching but this could be avoided using shared APPLTOP.
So having Concurrent processing along with DB will not be like a very bad choice, I would think with these faster networks it doesnt matter if the conc node is in the DB or in the App server as long as the maintenance / patching is taken care of properly and as per customer's choice

Posted by guest on May 08, 2013 at 06:10 PM PDT #

We have a custom solution where pl/sql needs to read a file on the $APPLCSF/$APPLOUT directory. This worked fine when the conc mgrs were on the DB server however since moving to 12.1.3 the mgrs are on the middle tier and now we need to use a shared file system between the two hosts. Is the shared file system approach the only way around the issue?

Posted by guest on May 23, 2013 at 03:50 AM PDT #

Guest,
If the Database Tier is physically located on a different machine, then your only option is to make that file system accessible to that machine since the FNDFS Apps executable is not available.

Posted by Max Arderius on May 23, 2013 at 07:46 AM PDT #

Hi Steven,
We are planning to upgrade 11.5.10 to 12.1.3(finally). 11i architecture were setup years ago on Solaris, Server A has database, Concurrent manager and Reports, Server B has Web and Forms Services. We want to use this chance to change to AIX platform and also move database by itself on a separated lpar. My questions, for the rest of apps components, what is your recommendation? It is better to have Concurrent manager and admin server on one lpar, web and forms on second lpar. Or put all rest of components on one big lpar? Is there any document to have this 'best practices'? And the cpu/memory capacity calculation on AIX based on Solaris.
Thanks,
Vivian

Posted by Vivian Yao on August 14, 2013 at 05:53 AM PDT #

Vivian,

Thank you for the inquiry.

First, you need to determine why a multi-node environment is required for your environment. Customers will deploy multiple nodes for their Oracle E-Business Suite environment to meet scalability or high availability requirements. Another reason customers have multiple nodes is to support users that access Oracle E-Business Suite from the internet. Some questions you need to research for your environment include the following:
- What are your concurrency requirements? Do you have scalability requirements that cannot be met with your existing architecture?
- What are your high availability requirements? How much downtime (planned and unplanned) is documented in your Service Level Agreement?
- What are your recoverability requirements? If you have a failure, how much down time can your business incur? Do you need to setup a disaster recovery site?
- Does my Oracle E-Business Suite environment require access from the internet?

Once you understand the requirements for your environment, then you can begin to design the required infrastructure to support this plan. For this, you need to become familiar with the options available to you.

The logical three-tier architecture of the Oracle E-Business Suite provides a lot of flexibility to meet the varying requirements of our customers. For example, the following options and features are available:
- Load balancing can be achieved for the application tier web and forms services.
- Parallel Concurrent Processing is available for the concurrent processing node. Historically, the concurrent processing node was placed on the database server. With increased network speeds, we now recommend placing the concurrent processing node on the application tier.
- A Shared Application Tier Filesystem is available to assist with reducing the administrative overhead of multiple copies of the code. When using a Shared Application Tier Filesystem,
- Distributed AD may be used to take advantage of the resources available on all nodes in the environment when applying patches.
- For the database, you can use Oracle Real Application Clusters (RAC) to meet scalability and high availability requirements. You can create a reporting environment with Active Data Guard. You can also configure a standby database to meet disaster recovery requirements.

Planning the E-Business Suite architecture for any environment is not a simply task. This blog is meant to provide general guidelines and direction for Oracle E-Business Suite Applications Technology. If you find that you require assisting with your architecture design, please contact your Oracle Sales Account Manager who can direct your inquiries to Oracle Consulting for additional assistance.

Best of luck to you with your deployment.
Regards,
Elke

Posted by Elke Phelps (Oracle Development) on August 27, 2013 at 08:16 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
24
25
26
27
28
29
30
   
       
Today