20 Using Service Migration in an Enterprise Deployment
The Oracle WebLogic Server migration framework supports Whole Server Migration and Service Migration. Whole Server Migration requires more resources and a full start of a managed server, so it involves a higher failover latency than Service Migration. The products included in this EDG support Service Migration. Hence, Service Migration is recommended and this guide explains how to use Service Migration in an Oracle Fusion Middleware enterprise topology. Whole Server migration is out of the scope of this guide.
- About Automatic Service Migration in an Enterprise Deployment
Oracle WebLogic Server provides a migration framework that is an integral part of any highly available environment. The following sections provide more information about how this framework can be used effectively in an enterprise deployment. - Creating a GridLink Data Source for Leasing
Automatic Service Migration require a data source for the leasing table, which is a table that resides in a tablespace and schema created automatically as part of the Oracle WebLogic Server schemas by the Repository Creation Utility (RCU). - Configuring Automatic Service Migration in an Enterprise Deployment
The services used by the different SOA components in this Enterprise Deployment Guide are already configured with Automatic Service Migration when following the Configuration Wizard steps provided in this guide. For any other custom services, you can use the following steps to configure service migration.
About Automatic Service Migration in an Enterprise Deployment
Oracle WebLogic Server provides a migration framework that is an integral part of any highly available environment. The following sections provide more information about how this framework can be used effectively in an enterprise deployment.
- Understanding the Difference between Whole Server and Service Migration
- Implications of Service Migration in an Enterprise Deployment
- Understanding Which Products and Components Require Service Migration
Parent topic: Using Service Migration in an Enterprise Deployment
Understanding the Difference between Whole Server and Service Migration
The Oracle WebLogic Server migration framework supports two distinct types of automatic migration:
-
Whole Server Migration, where the Managed Server instance is migrated to a different physical system upon failure.
Whole server migration provides for the automatic restart of a server instance, with all its services, on a different physical machine. When a failure occurs in a server that is part of a cluster which is configured with server migration, the server is restarted on any of the other machines that host members of the cluster.
For this to happen, the servers must use a virtual hostname mapping to a floating IP, as listen address and the required resources (transactions logs and JMS persistent stores) must be available on the candidate machines.
See Whole Server Migration in Administering Clusters for Oracle WebLogic Server.
-
Service Migration, where specific services are moved to a different Managed Server within the cluster.
To understand service migration, it's important to understand pinned services.
In a WebLogic Server cluster, most subsystem services are hosted homogeneously on all server instances in the cluster, enabling transparent failover from one server to another. In contrast, pinned services, such as JMS-related services, the JTA Transaction Recovery Service, and user-defined singleton services, are hosted on individual server instances within a cluster—for these services, the WebLogic Server migration framework supports failure recovery with service migration, as opposed to failover.
See Understanding the Service Migration Framework in Administering Clusters for Oracle WebLogic Server.
Whole Server Migration requires more resources (virtual IP and virtual hostname) than Automatic Service Migration. It also involves a full start of the migrated managed server, so it provides a worse recovery time objective. All the different components in Oracle FMW SOA Suite support Automatic Service Migration and this is the recommend failover approach recommended and described in this Enterprise Deployment Guide. Whole Server migration is out of the scope of this guide.
Implications of Service Migration in an Enterprise Deployment
Using Automatic Service Migration (ASM) in an Enterprise Deployment has implications in the infrastructure and configuration requirements.
The implications are:
-
The resources used by servers must be accessible to both the original and failover system
In its initial status, resources are accessed by the original server or service. When a server or service is failed over/restarted in another system, the same resources (such as external resources, databases, and stores) must be available in the failover system. Otherwise, the service cannot resume the same operations. It is for this reason, that both whole server and service migration require that all members of a WebLogic cluster have access to the same transaction and JMS persistent stores.
Oracle allows you to use JDBC stores, which leverage the consistency, data protection, and high availability features of an oracle database and makes resources available for all the servers in the cluster. When you configure persistent stores properly in the database you must ensure that if a failover occurs (whole server migration or service migration), the failover system is able to access the same stores without any manual intervention.
-
Leasing Datasource
Service migration requires the configuration of a leasing datasource that is used by servers to store alive timestamps. These timestamps are used to determine the health of a server or service, and are key to the correct behavior of server and service migration (they are used to marks servers or services as failed and trigger failover).Note:
Oracle does not recommend that you use consensus leasing for HA purposes.
Table 20-1 summarizes the different aspects.
Table 20-1 Summary of Aspects of ASM
Cluster Protection | Failover Time | Capacity Planning | Reliability | Shared Storage/DB | VIP per Managed Server |
---|---|---|---|---|---|
ASM |
30 secs |
Mem/CPU of services |
DB Leasing |
Yes |
No |
Understanding Which Products and Components Require Service Migration
The following table lists the recommended best practice for optimal High Availability using Automatic Service Migration. As explained in the previous sections, Automatic Server Migration can also be used with all these components but it provides a worse failover time and requires more resources.
Component | Automatic Service Migration (ASM) |
---|---|
Oracle Web Services Manager (OWSM) |
NO |
Oracle SOA Suite |
YES |
Oracle Service Bus |
YES |
Oracle Business Process Management |
YES |
Oracle Enterprise Scheduler |
NO |
Oracle Business Activity Monitoring |
YES |
Oracle B2B |
YES |
Managed File Transfer |
YES |
Creating a GridLink Data Source for Leasing
Automatic Service Migration require a data source for the leasing table, which is a table that resides in a tablespace and schema created automatically as part of the Oracle WebLogic Server schemas by the Repository Creation Utility (RCU).
Note:
To accomplish data source consolidation and connection usage reduction, you can
reuse the WLSRuntimeSchemaDataSource
as is for database
leasing. This datasource is already configured with the
FMW1412_WLS_RUNTIME
schema, where the leasing table is
stored.
For an enterprise deployment, you should create a GridLink data source:
Parent topic: Using Service Migration in an Enterprise Deployment
Configuring Automatic Service Migration in an Enterprise Deployment
The services used by the different SOA components in this Enterprise Deployment Guide are already configured with Automatic Service Migration when following the Configuration Wizard steps provided in this guide. For any other custom services, you can use the following steps to configure service migration.
- Setting the Leasing Mechanism and Data Source for an Enterprise Deployment Cluster
- Configuring Automatic Service Migration
Parent topic: Using Service Migration in an Enterprise Deployment
Setting the Leasing Mechanism and Data Source for an Enterprise Deployment Cluster
Note:
To accomplish data source consolidation and connection usage reduction, you can
reuse the
WLSRuntimeSchemaDataSource
datasource as is for database leasing. This
datasource is already configured with the
FMW1412_WLS_RUNTIME
schema, where
the leasing table is stored.
The following procedure assumes that you have configured the Leasing data source
either by reusing the
WLSRuntimeSchemaDataSource
or a
custom datasource that you created as described in
Creating a GridLink Data Source for Leasing.
- Log into the WebLogic Remote Console.
- Navigate to the Edit Tree.
- In the structure tree, expand Environment > Clusters.
- The Summary of Clusters page appears. Click the cluster for which you want to configure migration.
- Click the Migration tab.
- Verify that Database is selected in the Migration Basis drop-down menu.
- In the Data Source for Automatic Migration drop-down menu,
select the Leasing data source that you created in Creating a GridLink
Data Source for Leasing. Select the
WLSRuntimeSchemaDataSource
for data source consolidation. - Click Save.
- Commit changes in the shopping cart
- Restart the managed servers for the changes to be effective. If you are configuring other aspects of ASM in the same configuration change session, you can use a final unique restart to reduce downtime.
After you complete the database leasing configuration, continue with the configuration of the service migration:
Configuring Automatic Service Migration
After you have configured the leasing for the cluster as described in Setting the Leasing Mechanism and Data Source for an Enterprise Deployment Cluster, you can configure automatic service migration for specific services in an enterprise deployment. The following sections explain how to configure and validate Automatic Service Migration for static clusters.
Changing the JTA Migration Settings for the Managed Servers in the Cluster
After you set the leasing mechanism and data source for the cluster, you can enable automatic JTA migration for the Managed Servers that you want to configure for service migration. Note that this topic applies only if you are deploying JTA services as part of your enterprise deployment.
Parent topic: Configuring Automatic Service Migration
About Selecting a Service Migration Policy
When you configure Automatic Service Migration, you select a Service Migration Policy for each cluster. This topic provides guidelines and considerations when selecting the Service Migration Policy.
For example, products or components running singletons or using Path services can benefit from the exactly-once policy. With this policy, if at least one Managed Server in the candidate server list is running, the services hosted by this migratable target are active somewhere in the cluster if servers fail or are administratively shut down (either gracefully or forcibly). This can cause multiple homogenous services to end up in one server on startup.
When you use this policy, you should monitor the cluster startup to identify what servers are running on each server. You can then perform a manual failback, if necessary, to place the system in a balanced configuration.
Other Fusion Middleware components are better suited for the failure-recovery policy.
Based on these guidelines, the following policies are recommended for an Oracle SOA Suite enterprise topology:
-
SOA_Cluster: failure-recovery
-
OSB_Cluster: failure-recovery
-
BAM_Cluster: exactly-once
-
MFT_Cluster: failure-recovery
See Policies for Manual and Automatic Service Migration in Administering Clusters for Oracle WebLogic Server.
Parent topic: Configuring Automatic Service Migration
Setting the Service Migration Policy for Each Managed Server in the Cluster
Parent topic: Configuring Automatic Service Migration
Validating Automatic Service Migration
Parent topic: Configuring Automatic Service Migration
Failing Back Services After Automatic Service Migration
When Automatic Service Migration occurs, Oracle WebLogic Server does not support failing back services to their original server when a server is back online and rejoins the cluster.
As a result, after the Automatic Service Migration migrates specific JMS services to a backup server during a fail-over, it does not migrate the services back to the original server after the original server is back online. Instead, you must migrate the services back to the original server manually.
To fail back a service to its original server, use WLST migrate command. For more information, see WLST Command Reference for Oracle WebLogic Server.
Parent topic: Configuring Automatic Service Migration