Let's begin with the end. First of all I show you what is my goal, what I will reach at the end of this post series.
I like diagrams. Usually a good diagram is much better then any number of text description.
So first here it is what I want to get at the end:
Yes, you see well, this is a simple network diagram.
At the end of the post series we will have these servers in the above configuration:
- a 2 node RAC database, (db01, db02)
- a 3 node Apps Tier
- 2 node for web and forms processing, (app01, app02)
- 1 node for concurrent program processing (conc01)
- and a load balancer
And yes again I haven't put on the diagram these hardwares:
- storage
- backup device
- monitoring tool
I will discuss them at a later, in an other post.
In the next post I try to collect all documentations what I had to read and use during the implemenation.
Architecting viewpoint of this configuration
There could be many, many question about this configuration. I will try to present some architecting viewpoint of this system:
- why I have choosed this configuration,
- what is the benefits of this system,
- what are the risks, the disadvantages of this system,
- what should I look for after implementing the system,
- is there any aftermath for a project if we choose this configuration.
Let's begin the answers.
"why I have choosed this"
In short: because the customer told this one.
I am kidding of course :) The customer usually never tell me what kind of configuration do they want. Instead of they are expecting functional and non functional requirements. Both of them has effect on arhictecture plan.
Functional means what modules, what functions do they want to use. So I have to consider on them, because between function and function there are many differences from resource viewpoint. (for example batch data handling needs other resources then a simple data input transaction).
Non functional means usually hardware, base software requirements (for example supported operating system, hardware vendor, storage type etc), but it means time, operating, maintenance etc requirements (for example operating time, expected response time, maximum outage, user numbers and so on, and so on)
At this example I could talk about non functional requirements
- 24/7 operating time
- minimize the outages
- hundreds of form users
- flexible, scalable architecture
- minimized maintenance cost
- use benefits of virtualization
- etc.
"what is the benefits of this system,"
The benefits? First of all, this architecture offer solutions for all non functioanl requirements above. Why?
Some answer.
- The RAC, think on it. It could server 24/7 operating time with minimized outages at database level. 2 node is not so much, but it is more than one :) So any problem with one node, the database will still available, it could still serve the data request. It is a good solution for flexiblity, scalablity requirement. If you need more resource you could easily add more nodes, if the additional resource claim is just a temporarly requirement, than after the resource peek you could easily drop the new nodes.
- The 2+1 application tier could server many form and web users, with separated batch processing. The 2 node web tier could serv parallely the users through load balancer. The users will know only one URL, they don't have to know anything about the architure. So they don't have to manully switch between application tiers, if one nodes goes down.
- Separated batch processing benefit comes out when users start many, many reports, batch data transactions at same time. In this case the web tier will don't stop, the standard user interaction will not stop, the users "only" have to wait for end of their started programs.
- Using of shared appl top benefits has many, some examples:
- If you need new application tier, you shouldn't install a new node, you have to configure it only. It's true for both purposes, not depends on that the new node what kind of services will handle.
- You don't need to patch all nodes, following one by one. You should patch only at once and all nodes will work with the new feature, with the new repaired function.
- It needs much less disk space. (I hope the new 12.2 EBS system will still support shared appl top, the 2 APPL_TOP sofware will require much more disk space if not)
- Of course maintance will not so simple as a 2 node EBS system, but RAC and shared APPL_TOP could minimize the extra maintenance resource requirements.
"what are the risks, the disadvantages of this system,"
"what should I look for after implementing the system,"
"is there any aftermath for a project if we choose this configuration."
Yes, of course. There aftermathes in developments, in project technical maintenance, in after go live support and so on.
Usually the development enviroment is much simplier than the configuration above. Allways talk with the project's team about the planned architecture. They have to know about it and of course they have to develop customization that work on planned system. Generally they like to "forget" the database and the application tier will not work on the same server.
The technical maintenance team life will not easier if you choose this kind of configuration. The test and live system implemantion, installation will take more times. Commonly the team could install the whole system much more tries than a simplier configuration. The backup, the restore, the disaster recovery tests will takes much more times too.
After go live, the support tasks takes longer than a simplier one. For example for any error handling on application tier you have to search error messages in much more log files than less complex configuration.
