The configuration and management tasks that may need to be performed on the enterprise deployment environment are detailed in this section.
These are some of the typical configuration and management tasks you are likely need to perform on an Oracle Fusion Middleware enterprise deployment.
In case a host computer fails, you can fail over the Administration Server to another host. The steps to verify the failover and failback of the Administration Server from SOAHOST1 and SOAHOST2 are detailed in the following sections.
Assumptions:
The Administration Server is configured to listen on ADMINVHN, and not on localhost or ANY address.
For more information about the ADMINVHN virtual IP address, see Reserving the Required IP Addresses for an Enterprise Deployment.
These procedures assume that the Administration Server domain home (ASERVER_HOME) has been mounted on both host computers. This ensures that the Administration Server domain configuration files and the persistent stores are saved on the shared storage device.
The Administration Server is failed over from SOAHOST1 to SOAHOST2, and the two nodes have these IPs:
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN : 100.200.140.206. This is the Virtual IP where the Administration Server is running, assigned to a virtual sub-interface (e.g. eth0:1), to be available on SOAHOST1 or SOAHOST2.
Oracle WebLogic Server and Oracle Fusion Middleware components have been installed in SOAHOST2 as described in the specific configuration chapters in this guide.
Specifically, both host computers use the exact same path to reference the binary files in the Oracle home.
The following procedure shows how to fail over the Administration Server to a different node (SOAHOST2). Note that even after failover, the Administration Server will still use the same Oracle WebLogic Server machine (which is a logical machine, not a physical machine).
This procedure assumes you’ve configured a per host Node Manager for the enterprise topology, as described in Creating a Per Host Node Manager Configuration. For more information, see About the Node Manager Configuration in a Typical Enterprise Deployment.
To fail over the Administration Server to a different host:
Stop the Administration Server on SOAHOST1.
Stop the Node Manager on SOAHOST1.
If you started the per host Node Manager using the procedure earlier in this guide, then return to the terminal window where you started the Node Manager and press Ctrl/C to stop the process.
Migrate the ADMINVHN virtual IP address to the second host:
Run the following command as root on SOAHOST1 (where X:Y is the current interface used by ADMINVHN):
/sbin/ifconfig ethX:Y down
Run the following command as root on SOAHOST2:
/sbin/ifconfig <interface:index> ADMINVHN netmask <netmask>
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Note:
Ensure that the netmask and interface to be used to match the available network configuration in SOAHOST2.
Update the routing tables using arping
, for example:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
From SOAHOST1, change directory to the Node Manager home directory:
cd NM_HOME
Edit the nodemanager.domains
file and remove the reference to ASERVER_HOME.
The resulting entry in the SOAHOST1 nodemanager.domains
file should appear as follows:
soaedg_domain=MSERVER_HOME;
From SOAHOST2, change directory to the Node Manager home directory:
cd NM_HOME
Edit the nodemanager.domains
file and add the reference the MSERVER_HOME.
The resulting entry in the SOAHOST2 nodemanager.domains
file should appear as follows:
soaedg_domain=MSERVER_HOME;ASERVER_HOME
Start the Node Manager on SOAHOST1 and restart the Node Manager on SOAHOST2.
Start the Administration Server on SOAHOST2.
Test that you can access the Administration Server on SOAHOST2 as follows:
Ensure that you can access the Oracle WebLogic Server Administration Console using the following URL:
http://ADMINVHN:7001/console
Check that you can access and verify the status of components in Fusion Middleware Control using the following URL:
http://ADMINVHN:7001/em
After you perform a manual failover of the Administration Server, it is important to verify that you can access the Administration Server, using the standard administration URLs.
From the load balancer, access the following URLs to ensure that you can access the Administration Server when it is running on SOAHOST2:
http://admin.example.com/console
This URL should display the WebLogic Server Administration console.
http://admin.example.com/em
This URL should display Oracle Enterprise Manager Fusion Middleware Control.
After you have tested a manual Administration Server failover, and after you have validated that you can access the administration URLs after the failover, you can then migrate the Administration Server back to its original host.
This procedure assumes you’ve configured a per host Node Manager for the enterprise topology, as described in Creating a Per Host Node Manager Configuration. For more information, see About the Node Manager Configuration in a Typical Enterprise Deployment.
It is important to understand how to enable SSL communication between the middle tier and the hardware load balancer.
Note:
The following steps are applicable if the hardware load balancer is configured with SSL and the front end address of the system has been secured accordingly.
In an enterprise deployment, there are scenarios where the software running on the middle tier must access the front-end SSL address of the hardware load balancer. In these scenarios, an appropriate SSL handshake must take place between the load balancer and the invoking servers. This handshake is not possible unless the Administration Server and Managed Servers on the middle tier are started using the appropriate SSL configuration.
For example, in an Oracle SOA Suite enterprise deployment, the following examples apply:
Oracle Business Process Management requires access to the front-end load balancer URL when it attempts to retrieve role information through specific Web services.
Oracle Service Bus performs invocations to endpoints exposed in the Load Balancer SSL virtual servers.
Oracle SOA Suite composite applications and services often generate callbacks that need to perform invocations using the SSL address exposed in the load balancer.
Finally, when you test a SOA Web services endpoint in Oracle Enterprise Manager Fusion Middleware Control, the Fusion Middleware Control software running on the Administration Server must access the load balancer front-end to validate the endpoint.
This section describes the procedure for creating self-signed certificates on SOAHOST1. Create these certificates using the network name or alias of the host.
The directory where keystores and trust keystores are maintained must be on shared storage that is accessible from all nodes so that when the servers fail over (manually or with server migration), the appropriate certificates can be accessed from the failover node. Oracle recommends using central or shared stores for the certificates used for different purposes (for example, SSL set up for HTTP invocations).For more information, see the information on filesystem specifications for the KEYSTORE_HOME location provided in About the Recommended Directory Structure for an Enterprise Deployment.
For information on using trust CA certificates instead, see the information about configuring identity and trust in Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.
About Passwords
The passwords used in this guide are used only as examples. Use secure passwords in a production environment. For example, use passwords that include both uppercase and lowercase characters as well as numbers.
To create self-signed certificates:
This section describes how to create an Identity Keystore on SOAHOST1.example.com.
In previous sections you have created certificates and keys that reside on shared storage. In this section, the certificate and private keys created earlier for all hosts and ADMINVHN are imported into a new Identity Store. Make sure that you use a different alias for each of the certificate/key pair imported.
Note:
The Identity Store is created (if none exists) when you import a certificate and the corresponding key into the Identity Store using the utils.ImportPrivateKey
utility.
To create the Trust Keystore on SOAHOST1.example.com.
For the SSL handshake to behave properly, the load balancer's certificate must be added to the WLS servers truststore. For adding it, follow these steps:
Note:
The need to add the load balancer certificate to the WLS server truststore applies only to self-signed certificates. If the load balancer certificate is issued by a third-party CA, you have to import the public certificates of the root and the intermediate CAs into the truststore.
setDomainEnv.sh
script is provided by Oracle WebLogic Server and is used to start the Administration Server and the Managed Servers in the domain. To ensure that each server accesses the updated trust store, edit the setDomainEnv.sh
script in each of the domain home directories in the enterprise deployment.To configure the identity and trust keystores:
In order to manage each product effectively within a single enterprise deployment domain, you must understand which products require specific administration roles or groups, and how to add a product-specific administration role to the Enterprise Deployment Administration group.
Each enterprise deployment consists of multiple products. Some of the products have specific administration users, roles, or groups that are used to control administration access to each product.
However, for an enterprise deployment, which consists of multiple products, you can use a single LDAP-based authorization provider and a single administration user and group to control access to all aspects of the deployment. For more information about creating the authorization provider and provisioning the enterprise deployment administration user and group, see Creating a New LDAP Authenticator and Provisioning a New Enterprise Deployment Administrator User and Group.
To be sure that you can manage each product effectively within the single enterprise deployment domain, you must understand which products require specific administration roles or groups, you must know how to add any specific product administration roles to the single, common enterprise deployment administration group, and if necessary, you must know how to add the enterprise deployment administration user to any required product-specific administration groups.
For more information, see the following topics.
The following table lists the Fusion Middleware products that have specific administration roles, which must be added to the enterprise deployment administration group (SOA Administrators
), which you defined in the LDAP Authorization Provider for the enterprise deployment.
Use the information in the following table and the instructions in Adding a Product-Specific Administration Role to the Enterprise Deployment Administration Group to add the required administration roles to the enterprise deployment Administration group.
Product | Application Stripe | Administration Role to be Assigned |
---|---|---|
Oracle Web Services Manager |
wsm-pm |
policy.updater |
SOA Infrastructure |
soa-infra |
SOAAdmin |
Oracle Service Bus |
Service_Bus_Console |
MiddlewareAdministrator |
Enterprise Scheduler Service |
ESSAPP |
ESSAdmin |
Oracle B2B |
b2bui |
B2BAdmin |
Oracle MFT |
mftapp |
MFTAdmin |
Oracle MFT |
mftes |
MFTESAdmin |
Oracle Insight |
insight |
InsightAdmin |
Table 22-1 lists the Oracle SOA Suite products that need to use specific administration groups.
For each of these components, the common enterprise deployment Administration user must be added to the product-specific Administration group; otherwise, you won't be able to manage the product resources using the enterprise manager administration user that you created in Provisioning an Enterprise Deployment Administration User and Group.
Use the information in Table 22-1 and the instructions in Adding the Enterprise Deployment Administration User to a Product-Specific Administration Group to add the required administration roles to the enterprise deployment Administration group.
Table 22-1 Oracle SOA Suite Products with a Product-Specific Administration Group
Product | Product-Specific Administration Group |
---|---|
Oracle Business Activity Monitoring |
BAMAdministrators |
Oracle Business Process Management |
Administrators |
Oracle Service Bus Integration |
IntegrationAdministrators |
MFT |
OracleSystemGroup |
Note:
MFT requires a specific user, namely OracleSystemUser, to be added to the central LDAP. This user must belong to the OracleSystemGroup group. You must add both the user name and the user group to the central LDAP to ensure that MFT job creation and deletion work properly.For products that require a product-specific administration role, use the following procedure to add the role to the enterprise deployment administration group:
For products with a product-specific administration group, use the following procedure to add the enterprise deployment administration user (weblogic_soa
to the group. This will allow you to manage the product using the enterprise manager administrator user:
For an enterprise deployment, Oracle recommends using JDBC persistent stores for transactions logs (TLOGs) and JMS.
This section analyzes the benefits of using JDBC versus File persistent stores and explains the procedure for configuring the persistent stores in a supported database. If you want to use File persistent stores instead of JDBC stores, the procedure for configuring them is also explained in this section.
Oracle Fusion Middleware supports both database-based and file-based persistent stores for Oracle WebLogic Server transaction logs (TLOGs) and JMS. Before deciding on a persistent store strategy for your environment, consider the advantages and disadvantages of each approach.
Note:
Regardless of which storage method you choose, Oracle recommends that for transaction integrity and consistency, you use the same type of store for both JMS and TLOGs.
When you store your TLOGs and JMS data in an Oracle database, you can take advantage of the replication and high availability features of the database. For example, you can use OracleData Guard to simplify cross-site synchronization. This is especially important if you are deploying Oracle Fusion Middleware in a disaster recovery configuration.
Storing TLOGs and JMS data in a database also means you don’t have to identity a specific shared storage location for this data. Note, however, that shared storage is still required for other aspects of an enterprise deployment. For example, it is necessary for Administration Server configuration (to support Administration Server failover), for deployment plans, and for adapter artifacts, such as the File/FTP Adapter control and processed files.
If you are storing TLOGs and JMS stores on a shared storage device, then you can protect this data by using the appropriate replication and backup strategy to guarantee zero data loss, and you will potentially realize better system performance. However, the file system protection will always be inferior to the protection provided by an Oracle Database.
For more information about the potential performance impact of using a database-based TLOGs and JMS store, see Performance Impact of TLOGs and JMS Persistent Stores.
Determining which installed FMW products and components utilize persistent stores can be done through the WebLogic Server Console in the Domain Structure navigation under DomainName > Services > Persistent Stores. The list will indicate the name of the store, the store type (usually FileStore), the targeted managed server, and whether the target can be migrated to or not.
The persistent stores with migratable targets are the appropriate candidates for consideration of the use of JDBC Persistent Stores. The stores listed that pertain to MDS are outside the scope of this chapter and should not be considered.
One of the primary considerations when selecting a storage method for Transaction Logs and JMS persistent stores is the potential impact on performance. This topic provides some guidelines and details to help you determine the performance impact of using JDBC persistent stores for TLOGs and JMS.
Performance Impact of Transaction Logs Versus JMS Stores
For transaction logs, the impact of using a JDBC store is relatively small, because the logs are very transient in nature. Typically, the effect is minimal when compared to other database operations in the system.
On the other hand, JMS database stores can have a higher impact on performance if the application is JMS intensive. For example, the impact of switching from a file-based to database-based persistent store is very low when you are using the SOA Fusion Order Demo (a sample application used to test Oracle SOA Suite environments), because the JMS database operations are masked by many other SOA database invocations that are much heavier.
Factors that Affect Performance
There are multiple factors that can affect the performance of a system when it is using JMS DB stores for custom destinations. The main ones are:
Custom destinations involved and their type
Payloads being persisted
Concurrency on the SOA system (producers on consumers for the destinations)
Depending on the effect of each one of the above, different settings can be configured in the following areas to improve performance:
Type of data types used for the JMS table (using raw vs. lobs)
Segment definition for the JMS table (partitions at index and table level)
Impact of JMS Topics
If your system uses Topics intensively, then as concurrency increases, the performance degradation with an Oracle RAC database will increase more than for Queues. In tests conducted by Oracle with JMS, the average performance degradation for different payload sizes and different concurrency was less than 30% for Queues. For topics, the impact was more than 40%. Consider the importance of these destinations from the recovery perspective when deciding whether to use database stores.
Impact of Data Type and Payload Size
When choosing to use the RAW or SecureFiles LOB data type for the payloads, consider the size of the payload being persisted. For example, when payload sizes range between 100b and 20k, then the amount of database time required by SecureFiles LOB is slightly higher than for the RAW data type.
More specifically, when the payload size reach around 4k, then SecureFiles tend to require more database time. This is because 4k is where writes move out-of-row. At around 20k payload size, SecureFiles data starts being more efficient. When payload sizes increase to more than 20k, then the database time becomes worse for payloads set to the RAW data type.
One additional advantage for SecureFiles is that the database time incurred stabilizes with payload increases starting at 500k. In other words, at that point it is not relevant (for SecureFiles) whether the data is storing 500k, 1MB or 2MB payloads, because the write is asynchronized, and the contention is the same in all cases.
The effect of concurrency (producers and consumers) on the queue’s throughput is similar for both RAW and SecureFiles until the payload sizes reach 50K. For small payloads, the effect on varying concurrency is practically the same, with slightly better scalability for RAW. Scalability is better for SecureFiles when the payloads are above 50k.
Impact of Concurrency, Worker Threads, and Database Partioning
Concurrency and worker threads defined for the persistent store can cause contention in the RAC database at the index and global cache level. Using a reverse index when enabling multiple worker threads in one single server or using multiple Oracle WebLogic Server clusters can improve things. However, if the Oracle Database partitioning option is available, then global hash partition for indexes should be used instead. This reduces the contention on the index and the global cache buffer waits, which in turn improves the response time of the application. Partitioning works well in all cases, some of which will not see significant improvements with a reverse index.
This section explains the guidelines to use JDBC persistent stores for transaction logs (TLOGs) and JMS. It also explains the procedures to configure the persistent stores in a supported database.
The following topics describe how to configure a database-based persistent store for transaction logs.
The following topics describe how to configure a database-based persistent store for JMS.
Before you can create a database-based persistent store for transaction logs, you must create a user and tablespace in a supported database.
Before you can create a database-based persistent store for JMS, you must create a user and tablespace in a supported database.
Before you can configure database-based persistent stores for JMS and TLOGs, you must create two data sources: one for the TLOGs persistent store and one for the JMS persistent store.
For an enterprise deployment, you should use GridLink data sources for your TLOGs and JMS stores. To create a GridLink data source:
After you create the tablespace and user in the database, and you have created the datasource, you can then assign the TLOGs persistence store to each of the required Managed Servers.
After you create the JMS persistent store user and table space in the database, and after you create the data source for the JMS persistent store, you can then use the Administration Console to create the store.
After you create the JMS tablespace and user in the database, create the JMS datasource, and create the JDBC store, then you can then assign the JMS persistence store to each of the required JMS Servers.
Oracle WebLogic Server uses the transaction logs to recover from system crashes or network failures.
Each Managed Server uses a transaction log that stores information about committed transactions that are coordinated by the server and that may not have been completed.
Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the Managed Servers within a cluster, store the transaction log in a location accessible to each Managed Server and its backup server.
Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. All Managed Servers in the cluster must be able to access this directory. This directory must also exist before you restart the server.
The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN). Note that it is important to set the appropriate replication and backup mechanisms at the storage level to guarantee protection in cases of a storage failure.
This information applies for file-based transaction logs. You can also configure a database-based persistent store for translation logs. For more information, see Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment.
For instructions to configure a default persistence store with static clusters, see Configuring a Default Persistence Store for Transaction Recovery with a Static Cluster.
By default, Web services use the WebLogic Server default persistent store for persistence. This store provides high-performance storage solution for web services.
Reliable Messaging
Make Connection
SecureConversation
Message buffering
You also have the option to use a JDBC persistence store in your WebLogic Server web service, instead of the default store. For information about web service persistence, see Managing Web Service Persistence.
It is recommended that you follow the below mentioned guidelines for making sure you back up the necessary directories and configuration data for an Oracle SOA Suite enterprise deployment.
Note:
Some of the static and run-time artifacts listed in this section are hosted from Network Attached Storage (NAS). If possible, backup and recover these volumes from the NAS filer directly rather than from the application servers.
For general information about backing up and recovering Oracle Fusion Middleware products, see the following sections in Oracle Fusion Middleware Administering Oracle Fusion Middleware:
Table 22-2 lists the static artifacts to back up in a typical Oracle SOA Suite enterprise deployment.
Table 22-2 Static Artifacts to Back Up in the Oracle SOA Suite Enterprise Deployment
Type | Host | Tier |
---|---|---|
Database Oracle home |
DBHOST1 and DBHOST2 |
Data Tier |
Oracle Fusion Middleware Oracle home |
WEBHOST1 and WEBHOST2 |
Web Tier |
Oracle Fusion Middleware Oracle home |
SOAHOST1 and SOAHOST2 (or NAS Filer) |
Application Tier |
Installation-related files |
WEBHOST1, WEHOST2, and shared storage |
N/A |
Table 22-3 lists the runtime artifacts to back up in a typical Oracle SOA Suite enterprise deployment.
Table 22-3 Run-Time Artifacts to Back Up in the Oracle SOA Suite Enterprise Deployment
Type | Host | Tier |
---|---|---|
Administration Server domain home (ASERVER_HOME) |
SOAHOST1 (or NAS Filer) |
Application Tier |
Application home (APPLICATION_HOME) |
SOAHOST1 (or NAS Filer) |
Application Tier |
Oracle RAC databases |
DBHOST1 and DBHOST2 |
Data Tier |
Scripts and Customizations |
Per host |
Application Tier |
Deployment Plan home (DEPLOY_PLAN_HOME) |
SOAHOST1 (or NAS Filer) |
Application Tier |
OHS Configuration directory |
WEBHOST1 and WEBHOST2 |
Web Tier |
These are some of the key configuration and management tasks that you will likely need to perform on an Oracle SOA Suite enterprise deployment.
Oracle SOA Suite applications are deployed as composites, consisting of different kinds of Oracle SOA Suite components. SOA composite applications include the following:
Service components such as Oracle Mediator for routing, BPEL processes for orchestration, BAM processes for orchestration (if Oracle BAM Suite is also installed), human tasks for workflow approvals, spring for integrating Java interfaces into SOA composite applications, and decision services for working with business rules.
Binding components (services and references) for connecting SOA composite applications to external services, applications, and technologies.
These components are assembled into a single SOA composite application.
When you deploy an Oracle SOA Suite composite application to an Oracle SOA Suite enterprise deployment, be sure to deploy each composite to a specific server or cluster address and not to the load balancer address (soa.example.com
).
Deploying composites to the load balancer address often requires direct connection from the deployer nodes to the external load balancer address. As a result, you will have to open additional ports in the firewalls.
For more information about Oracle SOA Suite composite applications, see the following sections in Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle Business Process Management Suite:
When redeploying a SOA infrastructure application or resource adapter within the SOA cluster, the deployment plan along with the application bits should be accessible to all servers in the cluster.
SOA applications and resource adapters are installed using nostage deployment mode. Because the administration sever does not copy the archive files from their source location when the nostage deployment mode is selected, each server must be able to access the same deployment plan.
To ensure deployment plan location is available to all servers in the domain, use the Deployment Plan home location described in File System and Directory Variables Used in This Guide and represented by the DEPLOY_PLAN_HOME variable in the Enterprise Deployment Workbook.
When the amount of data in the Oracle SOA Suite database grows very large, maintaining the database can become difficult, especially in an Oracle SOA Suite enterprise deployment where potentially many composite applications are deployed.
For more information, review the following sections in Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle Business Process Management Suite:
Cross-Component Wiring (CCW) enables the FMW components to publish and bind to some of the services available in a WLS domain, by using specific APIs.
CCW performs a bind of the wiring information only during the Configuration Wizard session or when manually forced by the WLS domain Administrator. When you add a Weblogic Server to a cluster (in a scale out/up operation in a static cluster), although the new server publishes its services, all the clients that use the service are not automatically updated and bound to the new service provider. The update does not happen because the existing servers that are already bound to a CCW table, do not automatically “know” about the new member that joins the cluster. It is the same case with ESS and WSMPM when they provide their services to SOA: both publish their service to the service table dynamically, but SOA servers do not know about these updates unless a bind is forced again.
Note:
Wiring Components to Work Together in Oracle Fusion Middleware Administering Oracle Fusion Middleware.
Oracle-Developed Modules for Oracle HTTP Server in Oracle Fusion Middleware Administering Oracle HTTP Server
The cross-component wiring t3 information is used by WSMPM and ESS to obtain the list of severs to be used in a JNDI invocation URL.
The CCW t3 information limits the impact of the lack of dynamic updates. When the invocation is done, the JNDI URL is used to obtain the RMI stubs with the list of members in the cluster. The JNDI URL does not need to contain the entire list of servers. The RMI stubs contain the list of all the servers in the cluster at any given time, and are used to load balance requests across all of them. Therefore, without a bind, the servers that are added to the cluster are used even if not present in the bind URL. The only drawback is that at least one of the original servers provided in the first CCW bind must be up to keep the system working when the cluster expands or shrinks. To avoid this issue, you can use the “cluster name” syntax in the service table instead of using the static list of members.
cluster:t3_cluster_name
When you use cluster:t3_cluster_name
, the CCW invocation fetches the complete list of members in the cluster at any given time, thus avoiding any dependencies on the initial servers and accounting for every member that is alive in the cluster then.
This procedure makes WSMPM use a t3 syntax that accounts for servers being added or removed from the WSMPM cluster without having to reupdate the CCW information.
Note:
The wiring table is updated with each cluster scale out or scale up, but it does not replace the cluster syntax until a manual rebind is used. Hence, it withstands all updates (additions and removals) in the lifecycle of the cluster.
You must set the front-end HTTP host and port for the Oracle WebLogic Server cluster that hosts the Oracle SOA Suite servers. You can specify these values in the Configuration Wizard while you are specifying the properties of the domain. However, when you add a SOA Cluster as part of an Oracle SOA Suite enterprise deployment, Oracle recommends that you perform this task after you verify the SOA Managed Servers.
To set the front end host and port from the Weblogic Server Administration Console: