2 Understanding a Typical Exalogic Enterprise Deployment

This chapter introduces and describes how an Oracle Fusion Middleware enterprise deployment is typically deployed on Exalogic hardware.

For information regarding specific product deployment architectures on Oracle Exalogic, refer to the appropriate product-specific enterprise deployment guide.

This guide gives an overview of what you need to consider when you are deploying a product on Exalogic. This guide focuses on the steps needed to set up the Exalogic appliance for deploying Oracle Fusion Middleware in an enterprise deployment. Note that this document does not cover how to install Oracle Fusion Middleware products. For information on installing Oracle Fusion Middleware, refer to the enterprise deployment guide specific to the product you are deploying.

Parent topic: Understanding an Enterprise Deployment on Exalogic

2.1 Why Install Oracle Fusion Middleware on Exalogic?

Oracle Exalogic is a highly available, highly performant integrated hardware appliance from Oracle. When deployed onto Exalogic, Oracle Fusion Middleware components benefit from Exalogic’s superior networking, resulting in improved application throughput.

In addition, Oracle WebLogic Server has had a number of optimizations put into place to enable it to run faster on Oracle Exalogic. These optimizations further increase the throughput of the applications deployed.

Deploying Oracle Fusion Middleware on Exalogic ensures that you have a highly available infrastructure that will provide you with maximum availability and performance.

2.2 Understanding the Types of Exalogic Deployment

This guide focuses on two primary reference topologies for deploying Oracle Fusion Middleware on Exalogic. Although the components installed are essentially the same, how the Exalogic appliance is commissioned is different for each topology.

The typical Exalogic deployments are the Physical Exalogic deployment and the Exalogic Elastic Cloud deployment:

  • Physical Exalogic Deployment. In this deployment type, the raw processing power of the Exalogic compute node is used directly. Because of the power of the compute node, more products are deployed on a single compute node to make the most of the processing resources available.

  • Exalogic Elastic Cloud Deployment. In this deployment, applications do not have direct access to the underlying power of the compute nodes. In an Exalogic Elastic Cloud deployment, the processing power is virtualized. This deployment allows users to create a number of virtual machines, which can be moved between base compute nodes as required. In this deployment, products are compartmentalized. In other words, products are divided into a large number of smaller virtual machines.

Going forward, this guide will refer to the two different types of deployment as physical and virtual.

These topologies are very similar to the standard platform topologies. That is, there is a distributed topology that is more suited to virtual Exalogic deployments and a consolidated topology that is more suited to physical Exalogic deployments. However, there is a third topology that is a hybrid topology, which uses some components installed in Exalogic and others namely the web tier, installed on commodity hardware outside of the Exalogic machine.

The exact Oracle Fusion Middleware topology you install and configure for your organization might vary, but for the three primary topologies, this guide provides the necessary steps to set up your Exalogic environment for an enterprise deployment.

2.3 Diagrams of the Primary Exalogic Enterprise Deployment Topologies

The following sections provide diagrams of the primary Exalogic enterprise deployment topologies.

Note:

Each of the diagrams below use arbitrary hostnames such as HOST1 or HOST2. These names are used for illustrative purposes only. In real deployments these names are changed to reflect the host names that are used in the deployment.

This section contains the following topics:

2.3.1 Diagram of a Typical Physical Exalogic Topology

The Figure 2-1 shows a diagram of the physical Exalogic enterprise deployment topology with Oracle Traffic Director.

Figure 2-1 Physical Exalogic Deployment with Oracle Traffic Director

Description of Figure 2-1 follows
Description of "Figure 2-1 Physical Exalogic Deployment with Oracle Traffic Director"

For a description of the standard elements shown in the diagram, see Understanding the Typical Enterprise Deployment Topology Diagrams.

2.3.2 Diagram of a Typical Virtual Exalogic Topology

The Figure 2-2 shows a diagram of the virtual Exalogic enterprise deployment topology.

Figure 2-2 Typical Virtual Exalogic Topology

Typical Virtual Exalogic Topology

For a description of the standard elements shown in the diagram, see Understanding the Typical Enterprise Deployment Topology Diagrams.

2.3.3 Diagram of an Exalogic Deployment with an External Web Tier

The Figure 2-3 shows a typical enterprise deployment, including the Web tier, application tier and data tier.

Figure 2-3 Typical Enterprise Deployment with Web Tier

Typical Enterprise Deployment with Web Tier

2.4 Understanding the Typical Enterprise Deployment Topology Diagrams

It provides information on Oracle Fusion Middleware and Exalogic networking and elements of a Enterprise deployment topology.

The following topics provide conceptual information about the typical enterprise deployment topology diagrams:

2.4.1 Understanding the Firewalls and Zones of a Typical Exalogic Enterprise Deployment

When you deploy Oracle Fusion Middleware on Exalogic, most (if not all) of the components are installed inside the Exalogic appliance. A typical platform enterprise deployment is distributed among various tiers. Each tier is separated by a firewall.

Since all the hardware components are incorporated into the Exalogic appliance, the number of tiers available is reduced.

There is no need for an application or directory tier. Also, if your Exalogic appliance is linked to an Exadata appliance, then there is no need for a data tier.

In the enterprise deployment topology diagrams, the following two zones are used, which are each separated by a firewall:

  • The DMZ, in which the load balancer resides. This zone is accessible only through virtual server names defined on the load balancer.

  • The Exalogic zone, in which all application components reside. In this zone, only those components requiring access to external resources are visible on the corporate network.

Note that a common variation on these topologies is to move the web server to the DMZ. This can offer increased security.

2.4.2 Understanding Oracle Fusion Middleware and Exalogic Networking

One of the core advantages of Exalogic is its fast, flexible network. When you are deploying Oracle Fusion Middleware on Exalogic, you have to consider how you want to use Oracle Exalogic networking.

This section contains the following topics:

  • Types of Network
    There are three types of network within an Exalogic appliance.
  • Considerations for Choosing your Exalogic Network
    By default, some components within Oracle Fusion Middleware only talk on a single network. Other components, such as WebLogic Managed Servers and Oracle Traffic Director, can be configured to talk on both the internal and external networks.

2.4.2.1 Types of Network

There are three types of network within an Exalogic appliance.

  • IP over Infiniband (IPoIB): This is the internal Infiniband network that connects the internal components of the Exalogic appliance. This network is fast, but it cannot be connected to the outside world. The benefit of this network is that it can be used to ensure that network traffic is kept private from the outside world. The downside to using this network is that external components cannot directly access application components inside the Exalogic appliance.

  • Ethernet Management Network (eth0): This management network is used for connecting to the Exalogic components through the built-in Ethernet network. This network is only used for management operations and should not be used for production deployments. This network is used to login to the Exalogic components to configure them.

  • Ethernet over Infiniband (EoIB): This network also uses the Exalogic Infiniband network, but it is possible to connect this network to the standard corporate network. This allows external components to talk directly to components inside Exalogic. This network is always used for communication between your hardware load balancer and Oracle Traffic Director.

2.4.2.2 Considerations for Choosing your Exalogic Network

By default, some components within Oracle Fusion Middleware only talk on a single network. Other components, such as WebLogic Managed Servers and Oracle Traffic Director, can be configured to talk on both the internal and external networks.

Oracle Traffic Director is the preferred load balancer for traffic once it enters the Exalogic appliance. Oracle Traffic Director is also the preferred Web Server for deployments that reside completely within Exalogic.

When choosing which Exalogic network to use, consider the following:

  • If you are using an external Web Tier, then you should configure your components where it listens on EoIB network and routes to IPoIB.

  • If you expect that all traffic will come through Oracle Traffic Director and will stay within the Exalogic appliance once it reaches there, then you should choose to configure your components to use the IPoIB network.

  • If you expect all of your LDAP traffic to originate within the Exalogic appliance, then you should configure your LDAP server to use the IPoIB network.

  • If your database resides in an Exadata appliance that is directly connected to the Exalogic appliance, then you should use the IPoIB network.

  • If you are using Exadata to host your databases and these databases are accessed from both Exalogic and Non-Exalogic sources then the Database Listeners need to be configured to Listen on both the IPoIB and EoIB networks.

Note that additional configuration is required if you want to configure WebLogic Managed Servers to listen on multiple networks using different channels. Your usage of the Exalogic network depends on your access requirements. It may be that the solution you adopt encompass elements of both the internal and external network.

There is no mandate rule on which network you use. There are no significant performance gains of one over the other. All components work equally well on either network.

2.4.3 Understanding the Elements of a Typical Enterprise Deployment Topology

The enterprise deployment topology consists of a hardware load balancer, web tier, application tier, directory tier and a data tier.

The enterprise deployment topology consists of the following high-level elements:

  • A hardware load balancer, which routes requests from the Internet to the Web servers in the Web tier. In this case, a Web server can either be an external Web server on commodity hardware or Oracle Traffic Director inside the Exalogic host.

  • A Web tier, which consists of two or more host computers hosting Web server instances (for load balancing and high availability).
The Web server instances are configured to authenticate users (via an external identity store and a single sign-on server) and then route the HTTP requests to the Oracle Fusion Middleware products and components running in the Application tier.
 The web tier instances are also used to load balance internal requests without the need for those requests to go through the external hardware load balancer. The Web Server used is typically an Oracle Traffic Director or in the case of an External Web Tier, it is an Oracle HTTP Server.

  • An Application tier, which consists of two or more hosts hosting a cluster of Oracle WebLogic Server Managed Servers and the WebLogic Administration Server for the domain. The Managed Servers are configured to run the various Oracle Fusion Middleware products, such as Oracle Identity and Access Management or Oracle SOA Suite.

  • A Directory tier, which consists of two or more servers hosting a LDAP-compliant directory, such as Oracle Unified Directory.

  • A data tier, which consists of either two or more physical hosts hosting an Oracle RAC Database or an Exadata appliance hosting an Oracle RAC database.

Note:

This topic describes the different tiers of a typical enterprise deployment topology. In this guide, tiers refer to logical separations. In a commodity deployment, tiers are typically separated by firewalls. However, in an Exalogic deployment, this is not necessary as the traffic is confined to the Exalogic machine. In an Exalogic deployment, a firewall typically exists only between the DMZ and the Exalogic appliance.

2.4.4 Receiving Requests from the Internet

The enterprise deployment topology is fronted by a hardware load balancer, which directs incoming HTTP and HTTPS requests from the Internet to the Web tier.

This section contains the following topics:

2.4.4.1 Purpose of the Hardware Load Balancer

The hardware load balancer balances the load on the Web tier by receiving requests to a virtual host name and then routing each request to one of the Web server instances, based on a load balancing algorithm.

In this way, the load balancer ensures that no one Web server is overloaded with HTTP requests.

For more information about the purpose of specific virtual host names on the hardware load balancer, see Summary of the Typical Load Balancer Virtual Server Names.

Note that in the reference topology, only HTTP requests are routed from the hardware load balancer to the Web tier. Secure Socket Layer (SSL) requests are terminated at the load balancer.

The load balancer provides high availability by ensuring that if one Web server is unavailable, requests will be routed to the remaining Web servers that are up and running.

Further, in a typical highly available configuration, the hardware load balancers are configured such that a hot standby device is ready to resume service in case a failure occurs in the main load balancing appliance. This is important because for many types of services and systems, the hardware load balancer becomes the unique point of access to make invocations and, as a result, becomes a single point of failure (SPOF) for the whole system if it is not protected.

2.4.4.2 Specific internal-only communications between the components of the Application tier

Communications between the Oracle Fusion Middleware components and applications on the application tier are handled by the load balancing capabilities of Oracle Traffic Director (OTD).

The internal-only requests are kept within the Exalogic appliance, using a unique virtual host name that is attached to an OTD failover group.
Specific internal-only communications

2.4.4.3 Summary of Virtual Server Names

This section describes the virtual server names recognized by the hardware load balancer and Oracle Traffic Director (OTD) in a typical enterprise deployment.

2.4.4.3.1 Summary of the Typical Load Balancer Virtual Server Names

To balance the load on Web hosts and to provide high availability, the hardware load balancer is configured to recognize a set of virtual server names.

As shown in the diagram, the following virtual server names are recognized by the hardware load balancer in this topology:

  • ‪product.example.com - This virtual server name is used for all incoming traffic. Users enter this URL to access the Oracle Fusion Middleware products and custom applications available on this server. The load balancer then routes these requests (using a load balancing algorithm) to one of the servers in the Web tier. In this way, the single virtual server name can be used to route traffic to multiple servers for load balancing and high availability of the Web server instances.

  • ‬‪ ‬‪admin.example.com - This virtual server name is for administrators who need to access the Oracle Enterprise Manager Fusion Middleware Control and Oracle WebLogic Server Administration Console interfaces. This URL is known only to internal administrators. It uses the Network Address Translation (NAT) capabilities of the load balancer to route administrators to the active Administration Server in the domain.

These virtual server names are normally defined in your corporate DNS. Intranet facing entry points, such as product.example.com, are published to the internet. However, management virtual servers, such as admin.example.com, are resolvable inside the corporate network only.

For the complete set of virtual server names you must define for your topology, see the chapter in your product enterprise deployment guide that describes the product-specific topology.

2.4.4.3.2 Summary of the Typical OTD Virtual Server Names

To balance the load on internal components and provide high availability, Oracle Traffic Director (OTD) is configured to recognize a set of virtual server names.

As shown in the diagram, the following virtual server names are recognized by OTD in this topology:

  • edginternal.example.com - This virtual server name is for internal communications only.
The load balancer uses its Network Address Translation (NAT) capabilities to route any internal communication from the Application tier components that are directed to the http://edginternal.example.com/ Intranet URL. This URL is not exposed to external customers or users on the Internet.

  • idstore.example.com – This virtual server name is for internal LDAP communications only.

OTD typically enables these virtual servers on the internal network. They are resolvable only inside the Exalogic appliance using local host entries.

2.4.4.4 HTTPS versus HTTP Requests to the External Virtual Server Name

When you configure the hardware load balancer, a best practice is to assign the main external URL to port 80 and port 443.

Any request on port 80 (non-SSL protocol) should be redirected to port 443 (SSL protocol). Exceptions of this rule include requests from public WSDLs and requests to Oracle Mobile Security Access Server. For more information, see the product-specific Enterprise Deployment Guides.

2.4.5 Understanding the Web Tier

The Web tier of the reference topology consists of two Oracle Traffic Director instances.

This section contains the following topics:

2.4.5.1 Benefits of Using Oracle Traffic Director Instances to Route Requests

A Web tier with Oracle Traffic Director (OTD) is not a requirement for many of the Oracle Fusion Middleware products. You can route traffic directly from the hardware load balancer to the WebLogic servers in the Application tier.

However, a Web tier does provide several advantages, which is why it is recommended as part of the reference topology:

  • If a load balancer routes directly to the WebLogic Server, requests move from the load balancer to the application tier in one single HTTP jump, which can cause security concerns. In the reference topology above, communication with the application tier is confined to the internal Exalogic network to which the load balancer does not have access. Using OTD provides an interface to the application tier with the added advantage of not exposing that tier to the corporate network.

  • The Web tier allows the WebLogic Server cluster membership to be reconfigured (new servers added, others removed) without having to change the Web server configuration (as long as at least some of the servers in the configured list remain alive).

  • Oracle Traffic Director provides HTTP redirection over and above what WebLogic Server provides. You can use Oracle HTTP Server as a front end against many different WebLogic Server clusters, and in some cases, control the routing via content based routing.

  • Oracle Traffic Director provides extra security by acting as an internal load balancer for internal requests.

  • Oracle Traffic Director provides the ability to integrate single sign-on capabilities into your enterprise deployment. For example, you can later implement single sign-on for the enterprise deployment, using Oracle Access Manager, which is a component of Oracle Identity and Access Management.

2.4.5.2 Benefits of Using Oracle HTTP Server Instances to Route Requests

A Web tier with Oracle HTTP Server is not a requirement for many of the Oracle Fusion Middleware products. You can route traffic directly from the hardware load balancer to the WebLogic servers in the Application tier.

However, Oracle HTTP Server does provide the following advantages:

  • Oracle HTTP Server can be placed on commodity hardware outside of the Exalogic host with a firewall, which adds extra security between the Web server and the Application servers.

  • Oracle HTTP Server can be used to host static content.

2.4.5.3 Alternatives to Using Oracle Traffic Director Server in the Web Tier

Oracle Traffic Director (OTD) provides a variety of benefits in an enterprise deployment topology, Oracle also supports routing requests to Oracle HTTP Server or directly from the hardware load balancer to the Managed Servers in the middle tier.

Advantages of Direct Access are:

  • Lower configuration and processing overhead than using a front-end Oracle HTTP Server Web tier front-end.

  • Monitoring at the application level since the load balancer can be configured to monitor specific URLs for each Managed Server (something that is not possible with OTD).

  • You can potentially use this load balancer feature to monitor SOA composite application URLs. Note that this enables routing to the Managed Servers only when all composites are deployed, and you must use the appropriate monitoring software.

Both of the approaches require exposing the internal components to the EoIB network. This would allow the provision of a firewall between the web tier and Exalogic tier. The downside to this approach is that all of the components inside the Exalogic appliance will need to be made visible on the external network.

2.4.5.4 About the Placement and Function of Oracle Traffic Director in a Physical Deployment

Oracle Traffic Director (OTD) is shown as being deployed onto the same compute nodes as the application. This allows the OTD instances to route specific application traffic to the appropriate application tier and makes the most of the computing power available in the compute node itself.

An alternative approach to this is to deploy OTD onto dedicated compute nodes to service the entire Exalogic appliance.

For example, if you have three applications deployed, such as Oracle Identity Management, Oracle SOA Suite, and Oracle WebCenter, you can choose to use common OTD instances to route requests to all of the deployed applications. This is a supported configuration. The individual product enterprise deployment guides use a dedicated OTD deployment for simplicity.

2.4.5.5 About the Placement and Function of Oracle Traffic Director in a Virtual Deployment

In a virtual deployment it is recommended that Oracle Traffic director be placed into dedicated vServers.

In this deployment you can dedicate an OTD cluster to a specific application deployment, this makes management easier. By creating separate distribution groups you can ensure that no 2 OTD instances run on the same underlying compute node.

2.4.5.6 About Routing Requests to Oracle Traffic Director

The load balancer can route requests directly to Oracle Traffic Director (OTD) in the same way that the load balancer would route requests to Oracle HTTP Server. If Oracle Traffic Director is used, you are depending on load balancer monitoring to determine if an Oracle Traffic Director instance is non-responsive.

Internal testing has shown that a faster method of failover detection is available. This involves creating two external OTD failover groups. This method allows the load balancer to direct requests to these external failover groups rather than to the OTD instances themselves. When an OTD failover group is used, then the internal OTD heartbeat is used to detect OTD instance failures. As soon as a failure is detected, a surviving instance will take over processing requests from the failed instance. This failover detection method is typically faster than relying on the failover detection of the load balancer.

2.4.6 Understanding the Application Tier

The application tier consists of two or more hosts, where Oracle WebLogic Server and the Oracle Fusion Middleware products are installed and configured.

The application tier hosts reside inside the Exalogic appliance.

This section contains the following topics:

2.4.6.1 About the Configuration of the Administration Server and Managed Servers Domain Directories

Unlike the Managed Servers in the domain, the Administration Server uses an active-passive high availability configuration.

This is because only one Administration Server can be running within an Oracle WebLogic Server domain.

In the topology diagrams, the Administration Server on HOST1 is in the active state, and the Administration Server on HOST2 is in the passive (inactive) state.

To support the manual fail over of the Administration Server in the event of a system failure, the typical enterprise deployment topology includes:

  • A Virtual IP Address (VIP) for the routing of Administration Server requests

  • The configuration of the Administration Server domain directory on the shared ZFS storage device.

  • If you have no requirement to access your Administration Server outside of the Exalogic appliance, then the VIP used for the Administration Server should be on the internal network. If however you wish to use direct external access to the Administration Server for such things as t3 requests or DMS monitoring, then it should be configured on the external network.

In the event of a system failure (for example, a failure of HOST1), you can manually reassign the Administration Server VIP address to another host in the domain, mount the Administration Server domain directory on the new host, and then start the Administration Server on the new host.

However, unlike the Administration Server, there is no benefit to storing the Managed Servers on shared storage. In fact, there is a potential performance impact when Managed Server configuration data is not stored on the local disk of the host computer because of disk contention issues. In an Exalogic deployment, this is achieved by creating a private file system on the ZFS appliance, which is exclusively mounted to each host.

As a result, in the typical enterprise deployment, after you configure the Administration Server domain on shared storage, a copy of the domain configuration is placed on the local storage device of each host computer, and the Managed Servers are started from this copy of the domain configuration. You create this copy using the Oracle WebLogic Server pack and unpack utilities.

The resulting configuration consists of separate domain directories on each host: one for the Administration Server (on shared storage) and one for the Managed Servers (on local storage). Depending upon the action required, you must perform configuration tasks from one domain directory or the other.

For more information about the structure of the Administration Server domain directory and the Managed Server domain directory, as well as the variables used to reference these directories, see Understanding the Enterprise Deployment Directory Structure.

An additional benefit to the multiple domain directory model is that it allows you to isolate the Administration Server from the Managed Servers.

2.4.6.2 About Using Unicast for Communications Within the Application Tier

Oracle recommends the unicast communication protocol for communication between the Managed Servers and hosts within the Oracle WebLogic Server clusters in an enterprise deployment.

Unlike multicast communication, unicast does not require cross-network configuration, and it reduces potential network errors that can occur from multicast address conflicts as well.

When you consider using the multicast or unicast protocol for your own deployment, consider the type of network, the number of members in the cluster, and the reliability requirements for cluster membership. Also, consider the following benefits of each protocol.

Benefits or characteristics of unicast in an enterprise deployment:

  • Uses a group leader that every server sends messages directly to. This leader is responsible for retransmitting the message to every other group member and other group leaders, if applicable.

  • Works out of the box in most network topologies.

  • Requires no additional configuration, regardless of the network topology.

  • Uses a single missed heartbeat to remove a server from the cluster membership list.

Benefits or characteristics of multicast in an enterprise deployment:

  • Multicast uses a more scalable peer-to-peer model where a server sends each message directly to the network once and the network makes sure that each cluster member receives the message directly from the network.

  • Works out of the box in most modern environments where the cluster members are in a single subnet.

  • Requires additional configuration in the router(s) and WebLogic Server (that is, Multicast TTL) if the cluster members span more than one subnet.

  • Uses three consecutive missed heartbeats to remove a server from the cluster membership list.

Depending on the number of servers in your cluster and on whether the cluster membership is critical for the underlying application (for example, in session-replication intensive applications or clusters with intensive RMI invocations across the cluster), each model may behave better.

Consider whether your topology is going to be part of an Active-Active disaster recovery system or if the cluster is going to traverse multiple subnets. In general, unicast will behave better in those cases.

Most Oracle Fusion Middleware components allow you to use either form of communication. Some, however, are restricted to one form or the other. Refer to the specific product guides as necessary.

2.4.6.3 Understanding OPSS and Requests to the Authentication and Authorization Stores

Many of the Oracle Fusion Middleware products and components require an Oracle Platform Security Services (OPSS) security store for authentication providers (an identity store), policies, credentials, keystores, and for audit data.

As a result, communications must be enabled so the Application tier can send requests to and from the security providers.

For authentication, this communication is to an LDAP directory, such as Oracle Internet Directory (OID) or Oracle Unified Directory (OUD), which typically communicates over port 1389 or 1636. When you configure an Oracle Fusion Middleware domain, the domain is configured by default to use the WebLogic authentication provider. However, for an enterprise deployment, you must use a dedicated, centralized LDAP-compliant authentication provider.

In an Exalogic deployment, the LDAP directory is inside the appliance, and communication with the LDAP servers is typically through the internal Exalogic network.

For authorization (and the policy store), the location of the security store varies, depending up on the tier:

  • For the application tier, the authorization store is database-based, so frequent connections from the Oracle WebLogic Server Managed Servers to the database are required for the purpose of retrieving the required OPSS data.

  • For the Web tier, the authorization store is file-based, so connections to the database are not required.

For more information about OPSS security stores, see the following sections of Securing Applications with Oracle Platform Security Services:

2.4.6.4 About Coherence Clusters In a Typical Enterprise Deployment

The standard Oracle Fusion Middleware enterprise deployment includes a Coherence cluster that contains storage-enabled Managed Coherence Servers.

This configuration is a good starting point for using Coherence, but depending upon your specific requirements, you can consider tuning and reconfiguring Coherence to improve performance in a production environment or to resolve possible port conflicts.

When reviewing port assignments, note that the Oracle Fusion Middleware products and components default to a Well Known Address (WKA) list that uses the port specified on the Coherence Clusters screen of the Configuration Wizard. The WKA list also uses the listen address of all servers that participate in the Coherence cluster as the listen address for the WKA list.

When configuring Coherence clusters on Exalogic, the coherence clusters are usually configured to use the internal network.

These settings can be customized using the WebLogic Server Administration Console.

For more information, refer to the following resources:

2.4.6.5 About WebLogic Replication Channels

By default, WebLogic Server will configure session replication to use the external network. When deploying on Exalogic, you will get better throughput if you configure extra replication channels that utilize the Sockets Direct Protocol (SDP).

For more information, refer to Enabling Cluster-Level Session Replication Enhancements.

2.4.7 Understanding the Directory Tier

Oracle Fusion Middleware Products often interact with an LDAP directory. The diagrams above topic depicts how an LDAP directory can be access in such a topology.

The purpose of including this in the diagrams is to show how the networking would be effected by the inclusion of an LDAP directory inside the Exalogic appliance.

This is shown for example purposes only and by no means assumes that every product will require the installation of an LDAP directory or that every product will interact with an LDAP directory. Refer to the individual product guides to determine whether that product interacts with LDAP. For details on how to set up an LDAP directory inside Exalogic refer to the Oracle Identity and Access Management Enterprise Deployment Guide.

If there is an LDAP directory inside the Exalogic Machine. The directory will typically be configured to listen on the internal IPoIB network. Requests to the LDAP instances will be load balanced through the Oracle Traffic Director. If there is an LDAP directory configured outside of the Exalogic machine then communication with the directory will be through the EoIB network and load balanced through a hardware load balancer.

2.4.8 Understanding the Data Tier

In the Data tier, an Oracle RAC database runs on the two hosts (DBHOST1 and DBHOST2). The database contains the schemas required by the Oracle Fusion Middleware components and the Oracle Platform Security Services (OPSS) policy store.

You can define multiple services for the different products and components in an enterprise deployment to isolate and prioritize throughput and performance. In this guide, one database service is used as an example. In an Exalogic deployment, the database can run on hardware accessible through any standard Ethernet network or on an Exadata system directly connected to Exalogic through Infiniband.

Further, you can use other high availability database solutions to protect the database:

The above solutions provide protection for the database beyond the information provided in this guide, which focuses on using an Oracle RAC Database, given the scalability and availability requirements that typically apply to an enterprise deployment.

For more information about using Oracle Databases in a high availability environment, see "Database Considerations" in the High Availability Guide.

2.5 Understanding the vServers

In an Exalogic virtual deployment physical servers are replaced with virtual servers.

When deploying applications on to virtual servers different deployment options can be considered.

  • Create smaller virtual servers with a single instance or JVM running per vServer. The advantages of this approach is it is easier to scale an individual JVM as needed.

  • Place dependent applications together in larger vServers. For example placing the components belonging to each domain into a larger vServer. The advantage of this approach is it is easier to scale out an entire domains functionality.

When sizing vServers add up the total memory requirements of the JVM's or instances being hosted in the vServer and add an extra 2GB for the vServer overhead.

2.6 Exalogic Enhancements in Oracle Fusion Middleware

Oracle Weblogic Server includes a number of enhancements to make the Oracle Fusion Middleware products take full advantage of the Exalogic infrastructure.

Enabling these enhancements will enable your Fusion Middleware installation to perform better. Complete list of enhancements are available at Tuning WebLogic Server for Exalogic Environments in the Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server Guide.