Oracle WebLogic 11g Topology
4 likes2,988 views
This document discusses different WebLogic topology strategies with varying levels of application isolation and performance. It recommends strategies such as running multiple WebLogic instances, multiple managed servers, or virtual machines on a single physical server for development/test environments, and using clusters, session persistence, or hardware partitions for production environments. The goal is to consolidate applications while balancing isolation and resource utilization.
Oracle WebLogic 11g Topology
- 1. WebLogic Topology Best Practices Name – Rakesh Gujjarlapudi Email Address – [email protected]
- 2. No Isolation, Low Performance Recommended for development environment Most obvious strategy of application consolidation using WebLogic is to simply run many applications in the same instance of the application server in a single JVM It ensures optimal resource utilization within a shared infrastructure (in both single-server and clustered environments) No Isolation, Medium Performance, Clustered Recommended for development/test environments No Isolation, Low Performance, No cluster Recommended for development environment A single JVM environment allows for only a superficial level of isolation between applications, and therefore presents the following issues: Errant applications can negatively impact other running applications. There is no way to guarantee performance service levels for different applications. All applications must work with the same WebLogic version, JVM version, and associated patch levels. All applications must work with the same operating-system version and patch level.
- 3. The potential for upgrade deadlocks between applications (i.e., an OS or JVM patch that one application requires ends up breaking another application). The potential for significant support issues when running third-party ISV applications in a shared infrastructure. JVMs tend not to scale well past four processor configurations, which limits the viability of the single-JVM model on larger machines. Medium Isolation, Low Performance Recommended for development environment Multiple WebLogic Instances This topology provides a viable solution for application consolidation in many circumstances and represents a good balance between application isolation and resource utilization. The next logical strategy for running multiple WebLogic applications on a shared infrastructure is to run multiple instances of the application server (multiple JVMs) on the same physical machine It affords much more application isolation than the single JVM model, while giving up only a small degree of resource utilization It allows different applications to use different WebLogic versions and different JVM versions and patch levels. Each instance has its own virtual machine, heap space, and database connection pools. Running multiple WebLogic instances makes it more difficult for an errant application to impact other applications While running multiple WebLogic instances clearly has some advantages over a singe-instance model, it also has some significant drawbacks, including: 1. Errant applications still have a chance (albeit a small chance) of negatively impacting other running applications. 2. There is no way to completely ensure performance service levels for different applications. 3. All applications must work with the same operating system version and patch level. Memory overhead from running multiple JVMs.
- 4. Multiple Managed Servers This logical strategy for running multiple WebLogic applications on a shared infrastructure is to run multiple Managed Servers (multiple JVMs) on the same physical machine Each Managed Server has its own virtual machine and heap space This scenario affords much more application isolation than the single JVM model, while giving up only a small degree of resource utilization. Running multiple Managed Servers makes it more difficult for an errant application to impact other applications Same disadvantages as multiple Managed Servers on the same physical machine. High Isolation, High Performance, No Cluster Recommended for Test/Production environments
- 5. Medium Isolation, High Performance, No Cluster, Virtualization Recommended for Test/Production environments In the virtual machine scenario, a single physical machine runs a primary operating system that serves as a "host" OS for various "guest" operating systems that run virtual memory spaces The host OS essentially virtualizes physical system resources (CPU, disk, I/O, etc.) and coordinates access to these resources by the guest operating systems Since each virtual machine/partition runs a completely independent operating system instance, they achieve a high degree of application isolation, including the ability to dedicate a certain percentage of system resources to particular virtual machines to achieve service-level commitments In effect, each application is completely unaware that it is running in a virtual, rather than a physical, machine. Each virtual machine/partition can also be quickly reconfigured based upon demand, giving system administrators a very high degree of flexibility. However, the price for such independence is the inherent overhead involved in managing multiple OS instances and their associated memory requirements.
- 6. High Isolation, High Performance, session presistance, Clustered Recommended for Test/Production environment Medium Isolation, High Performance, Session Persistence, HA, Virtualization Recommended for Test/Production environment
- 7. Aside from actually using multiple physical servers, the far extreme of the application isolation scale is the use of "hard" partitions on Exalogic A hard partition conceptually resembles a virtual partition, except that it is actually implemented in the hardware architecture of the machine. Each hard partition is physically allocated a certain number of CPUs, memory, storage, and so on from a pool of resources available within the machine. Once allocated, these partitions act, for all intents and purposes (including 14 fault tolerance), as separate physical machines, thus providing the highest possible degree of application isolation but the lowest overall resource utilization. From a consolidation standpoint, hard partitions can achieve a marginally higher level of resource utilization than independent machines due to their reconfiguration flexibility and manageability. The resources of hard partitions can quickly be reallocated to other partitions to meet the ever- changing needs of the organization.