Oracle SOA Service Infrastructure Startup and Shut Down of Processes
The Oracle SOA Service Infrastructure application is started by default whenever any Oracle WebLogic Managed Server to which the Oracle SOA Service Infrastructure has been deployed is started. Normally, you should not need to stop the Oracle SOA Service Infrastructure or any of its components by themselves. Some operations may require Oracle WebLogic Managed Server where the SOA Service Infrastructure runs to be rebooted. Only some patching scenarios could require stopping the application.You can use Oracle WebLogic Server Administration Console to verify status and to start and stop Oracle WebLogic Server. You can also use the WebLogic Server WLST command line to control the application. Oracle Enterprise Manager Fusion Middleware Control also allows multiple operations and configuration of the Oracle SOA Service Infrastructure application as well as monitoring its status. See the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for details on monitoring and controlling the Oracle SOA Service Infrastructure application.
Oracle SOA Service Infrastructure High Availability Architecture and Failover Considerations
The Below figure illustrates a two-node Oracle SOA Service Infrastructure cluster running on two Oracle WebLogic Servers. The Oracle WebLogic Servers are front ended by two Oracle HTTP Server instances on web tier hosts, which receive requests from a load balancer in front of them.
Oracle SOA Service Infrastructure High Availability Architecture
The Oracle SOA Service Infrastructure uses the front end host and port information configured for the Oracle WebLogic Server cluster as the server and callback URL. You define these settings with Oracle WebLogic Server Administration Console. Select Clusters, SOA_Cluster_Name, HTTP/HTTPS frontend host and then Port. If there is no address for the Oracle WebLogic Server cluster where the Oracle SOA Service Infrastructure is running, the system uses the physical host name as the server and callback URL.
For SOA high availability installations frontended by Oracle HTTP Server, monitoring should be done on the Listen ports of Oracle HTTP Server. This is the case when a deployment uses all components deployed to the SOA Managed Server. A simple HTTP monitor that pings the HTTP/HTTPS port and expects a pre-determined response in turn should suffice. If only a specific SOA component is being used (such as B2B), then a monitor that does a deeper level check all the way to the Managed server can be considered to validate the health of the component in use. Check with your load balancer vendor on setting up the HTTP monitors with your load balancer.
For more information about the server and callback URLs see the Oracle Fusion Middleware Administrator's Guide. Changing the HTTP front end address for a cluster requires a restart of the managed servers that are part of the cluster.
The deployment coordinator is configured and used for deployment and updates of composites. The deployment coordinator sends notifications to deployment coordinator cluster members to retrieve new artifacts from the MDS repository, when they are updated by the group leader. A leader node performs singleton operations for the cluster such as updating the MDS after deployments, or changes are made to the composites.
The Oracle SOA Service Infrastructure system uses the Oracle WebLogic Server cluster name as its key to confirm a deployment coordinator group. If all nodes in a WebLogic Server cluster can communicate (over multicast or unicast) the deployment coordinator cluster is the same as the WebLogic Server cluster in which the SOA Service Infrastructure runs.
The Administration Server runs in Active-Passive mode. Whenever a failure occurs in SOAHOST1, you can restart the Administration Server in SOAHOST2; it uses a virtual IP or virtual hostname as listen address.
For information about configuring virtual IPs for the Administration Server and configuring the Administration Server for high availability, see Chapter 12, "Transforming the Administration Server for Cold Failover Cluster."
Although SOA Service Infrastructure can run in full active-active mode, the architecture uses the Oracle WebLogic Server Migration feature to protect some SOA components against failures. This implies that each of the WebLogic Managed Servers in which the SOA Service Infrastructure runs is listening on a Virtual IP that is migrated to another box upon failover. The Administration Server and Enterprise Manager run in AdminServer, not the managed server.
As shown in the above figure WLS_SOA1 listens on VIP1, and WLS_SOA2 listens on VIP2. Each managed server uses the other node as a failover resource, therefore, the system is configured in a cross manner. In other words, WLS_SOA1 fails over to SOAHOST2, and WLS_SOA2 fails over to SOAHOST1. The appropriate capacity planning must be done to anticipate the scenario where the two SOA managed servers are running on the same node. For more information on Server Migration features, see Chapter 3, "High Availability for WebLogic Server" in this guide.
To resume transactions after a server migration, configure the transaction and JMS stores in a shared storage. In case of failure in one of the server infrastructure instances, other instances can resume transactions and JMS operation by reading the persistent stores from that shared storage.
The Metadata store is configured in an Oracle RAC database to protect from database failures. Similarly, the SOA process state information is also stored in an Oracle RAC database. In this example, both Oracle RAC databases are the same.
These high availability characteristics apply to most of Oracle SOA components contained in the composite applications deployed across the cluster. For specific two-node high availability characteristics of the individual components, see the specific component sections that follow in this chapter.
Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior
This section describes how an Oracle SOA high availability cluster deployment protects components from failure and the expected behavior if component failure occurs.The WebLogic Server infrastructure protects the SOA Service Infrastructure system from all process failures.
No comments:
Post a Comment