No Isolation, Low PerformanceRecommended 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, ClusteredRecommended for development/test environmentsNo Isolation, Low Performance, No clusterRecommended 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.
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 PerformanceRecommended for development environmentMultiple WebLogic InstancesThis topology provides a viable solution for application consolidation in many circumstances andrepresents 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.
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 ClusterRecommended for Test/Production environments
Medium Isolation, High Performance, No Cluster,VirtualizationRecommended 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.
High Isolation, High Performance, session presistance,ClusteredRecommended for Test/Production environmentMedium Isolation, High Performance, Session Persistence,HA, VirtualizationRecommended for Test/Production environment
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.