Oracle EBS R12 implementation scenarios

Question

Dear All,
We have below 3 different scenarios, please give your comments/suggestions; keep in mind client wants cheeper solution.
HP DL580 G5 servers will be used with 64bit Redhat Linux 5.0 on all scenarios.
Scenario 1:)
Oracle EBS R-12 implementation with RAC & Load Balancer
Required H/W - 8 Server (4 Production & 4 UAT / Development), Hardware Load balancer
Software - RHEL 5.0 OS
Licenses - Oracle RAC
Advantages – High Availability solution, Redundancy
Disadvantages – Specialized network administrator required for load balancer management, Complex System and costly
Scenario 2:)
Oracle EBS implementation with Active Passive mode / fail safe
Required H/W - 8 Server, 4 Production (2 active & 2 passive) & 4 UAT / Development as replica of production environment
Software - RHEL 5.0 OS & Cluster software on OS Level clustering
Licenses – OS Cluster from Red Hat
Advantages – OS Level clustering is cheaper compared to Oracle RAC
Disadvantages – 2 Servers will used as Passive will not be optimally utilized they will only come into play when primary servers fail.
Scenario 3:)
Oracle EBS implementation Dual tier (DB & APPS)
Option – I (Active + Active)
Required H/W – 2 Servers for production and 2 UAT / Development as replica of production environment
Software – RHEL 5.0 OS & Cluster software on OS Level clustering
Licenses - OS Cluster from Red Hat
Advantages – All the servers are optimally utilized
Disadvantages -if one of the servers fails you might experience performance issues as both application and database services run on one node till server that failed is brought live.
Option – II (Active / Stand BY)
Required H/W - 2 Servers for production and 2 UAT / Development as replica of production environment, 2 server of UAT will be configured for stand by
Software – Oracle data guard
Licenses – oracle data guard
Advantages – Simple configuration and easy to maintain when compared to RAC and OS clustering
2) Will not experience performance problems when one of the primary fail .This is achieved by shutting down UAT or test instances till the issue on primary server is addressed
Disadvantages - Sudden spike in load cannot be addressed since load balancing feature is not available.
Best Regards,

Answer 1

Scenario 1:) Oracle EBS R-12 implementation with RAC & Load Balancer
When designing for "High Availability", this is quite a common infrastructure. It is pretty straightforward, though you are right, you need additional skills in managing RAC and Network. On the other hand, most larger companies have load balancers operational already. RAC may be expensive, however, if you want availability, it is what you will have to pay for, if you really cannot afford any downtime. Consider RAC when either of the following will be answered "No"
1) Can your customer really not afford more (unplanned) downtime than 20 minutes.
2) Is the maximum size of your hardware (single node database tier) sufficient to handle the amount of concurrent users in peak and will it be able to handle the expected growth for the next 12 months.
If either of the above questions answers no, consider RAC. Otherwise, one of the two alternative scenarios will probably be better.
Scenario 2:) Oracle EBS implementation with Active Passive mode / fail safe
This scenario requires additional skills as well: OS Cluster Administration skills. The main advantage in this situation is that the architecture in which EBS has to operate is quite simple. No clustering (EBS will operate on one db node and one appnode). Issues you might encounter: If dbnode fails, what will your appnode do? Will it have to be restarted? What about downtime in such a case? How much can you afford (see scenario 1). You will end up with some 'dirty' data in your database (concurrent manager). It might be necessary to clean that out first.
Another question to answer is how much do you trust your hardware/os. If it (almost) never failed on you for the past years, why would it be different in this situation. Having an active/passive cluster can be a costly architecture as well (half of your capacity being passive...)
Scenario 3:) Oracle EBS implementation Dual tier (DB & APPS)
Option – I (Active + Active)
I suspect you mean to establish a cluster that runs database package on node 1 and application package on node 2, each of them having the other node as failover node. In this situation, you will definitely encounter a performance degradation, but this can be managed by oversizing each of the nodes and/or defining a threshold for performance degradation and keeping this in mind when sizing the hardware. You would still need the cluster managing skills, though.
Option – II (Active / Stand BY)
This option will deliver you more High Availability, because this is a truly disaster resilient solution. Dataguard will duplicate the database, taking away the Single Point Of Failure(SPOF), which the database is in all previous scenarios. You should keep in mind though that the UAT environment will be affected by the standby database activity (not very much, but nevertheless). You will need additional skills, like Dataguard administration skills. I could argue about your statement that it will be easy to maintain, compared to RAC. However, like I said in my comments about Scenario 2, the operational architecture for EBS is quite simple in this architecture as well. Consider the implications on the application tier when your database switches/fails over to the standby.
Conclusion: There is no yes/no to each of the proposed scenarios. You will have to discuss with your customer to find out what the requirements are on a business level and translate them to an IT solution.
The solution should meet the needs for which it is realized and the people should be able to manage/maintain the solution. Additionally, the investment should be in line with the solution the customer requires.
Regards,
Arnoud Roth
Oracle E-Business Suite Technical Architect
Inter Access
The Netherlands