OEM Scalable Architecture Tips

by Rampant author Porus Homi Havewala

As a real-life example, let us look at the first Enterprise Manager Grid Control production site in the world, which was a large telecommunications company in Australia. The example is described in detail in the book.

The corporate database team was involved in this major project, in close association with Oracle Support consultants (from ACS – Oracle Advanced Customer Services) in Sydney and Melbourne who guided the client in on-site Beta testing as well as the first production implementation of Grid Control Release 1, and later the upgrade to Release 2. The objective of the project was to set up a centralized Enterprise Manager Grid Control site at the company headquarters in Melbourne.

Normally when a DBA team or their management decides to implement Grid Control, they  would use a test or development server to install the product, on unix, or linux, or windows. In this scenario all Grid Control components would be installed on a single server. This includes the Repository database, the Management Service (OMS), and the EM agent.

However, this is the wrong approach. The main working component engine of Grid Control is the Oracle Management Service (OMS). This is a J2EE application previously deployed on Oracle Application Server, and now on Oracle WebLogic Server. We find that only limited scalability will be achieved if all Grid Control components are placed on a single server. Doing this limits us to one Java Machine process with its inherent limits of memory and processor speed. If this process was under heavy load, it would reach its limits quickly and the process would slow down, not respond, or even reboot – however this woud happen less frequently in the case of Oracle WebLogic due to its better memory management.

In production scenarios, it is generally not recommended to place all the Grid Control components on a single server, and these components should also not be shared with a production or test database on the same server. Grid Control should preferably be allocated its own server, or its own set of servers as per a well architected and documented solution.

We strongly advise to spend quality time to plan any Grid Control installation that is meant for production, since it is a management solution for the enterprise and should be treated as a professional project – and not as a minor database tool to be implemented on a single workstation.

With the release of Grid Control, Oracle altered the internal architecture and changed it to the N-tier model. Grid Control was then divided into three components – the Repository database, the Management Service (OMS), and the EM agent. The OMS which was the main engine now ran on the application server as a Java Machine component, and therefore became inherently scalable.

The reason that makes this possible is that Grid Control is not tied to one single PC or one single server. It  runs as a Java Machine application on the application server tier. Multiple EM applications can be placed on the application server on numerous servers, and these can all be directed to the same EM repository.

It is to be noted that in Grid Control, performance scale-out is more of a necessity on the management service level rather than the database level. The Java Machine is where the bulk of the Grid Control work is performed, therefore scalability is more desired on the management services.

In the case of a large Grid Control setup, the architecture should include three or more load balanced management servers. Load balancing is a very important requirement of this architecture. We could use for this purpose a hardware load balancer – like a BIG-IP Application Switch Load Balancer from F5 Networks.

Setting up the Load Balancer in the appropriate way and balancing requests from management servers is further elucidated in the book. This architecture, using hardware load balancers and multiple management servers, has proved to be extemely powerful. The concept sits well with Oracle’s GRID vision. It is possible to manage, with ease, hundreds or even thousands of GRID targets with this configuration.