Migrating servers from multi-broker replication domains to data replication domains

You can migrate multi-broker replication domains to data replication domains. Any multi-broker domains that exist in your application server environment were created with a previous version of the product.

Before you begin

Determine if the application server configuration you are migrating:

  1. Uses an instance of data replication service in peer-to-peer mode or in client/server mode.

    Before you begin migrating a client/server mode replication domain, consider if migrating your replication domains might cause a single point of failure. Because you migrate the servers to the new type of replication domain one at a time, you risk a single point of failure if there are 3 or fewer application servers. Before migrating, configure at least 4 servers that use multi-broker replication domains. Perform the following steps to migrate the multi-broker domains to data replication domains:

    Dynamic cache replication domains use the peer-to-peer topology.

  2. Uses HTTP session memory-to-memory replication that is overloaded at the application or web module level.

    If the application server configuration you are migrating uses HTTP session memory-to-memory replication that is overloaded at the application or web module level, you must upgrade your deployment manager to the current version of the product before you start the migration process.

About this task

For HTTP session affinity to continue working correctly when migrating Version 5.x application servers to Version 6.0 application servers, you must upgrade all of the Web server plug-ins for the product to the latest version before upgrading the application servers that perform replication.

After you upgrade your deployment manager to the latest version of the product, you can only create data replication domains. Any multi-broker domains that you created with a previous release of the product are still functional, however, you cannot use the administrative console to create new multi-broker domains or replicators.

The different versions of application servers cannot communicate with each other. When migrating your servers to the current version of the product, keep at least two application servers running on the previous version so that replication remains functional.

Make sure that all of your application servers that are using this multi-broker domain have been migrated to the current version of the product before you start to migrate any multi-broker domains that exist in your configuration.

To migrate the multi-broker domains that exist in your configuration:

Procedure

  1. Migrate two or more of your existing servers to the current version of the product. The remaining servers on the previous version of the productcan still communicate with each other, but not with the migrated servers. The migrated servers can also communicate with each other.
  2. In the administrative console, create an empty data replication domain. Click Environment > Replication domains > New to create an empty data replication domain.
  3. Add two of your migrated servers to the new data replication domain.

    For example, if you are migrated four servers, only add two of them to the new replication domain.

  4. Configure the two servers as consumers of the replication domain.

    Configuring the servers as consumers of the replication domain enables them to use the new domain to share data.

  5. Add some of the clients to the new data replication domain.

    Perform this step only if the application server configuration you are migrating uses an instance of data replication service in client/server mode.

  6. Configure these clients as consumers of the replication domain.
  7. Verify that the new data replication domain are successfully sharing data.

    Only the servers and clients that are added to the data replication domain and are configured as consumers of this domain can use the data replication domain functions.

  8. Add the rest of your migrated servers to the new data replication domain.

    When the servers can use the new data replication domain to successfully share data, migrate the rest of the servers that are using the multi-broker replication domain to the new data replication domain.

    For example, if you are migrated four servers, add the remaining two servers to the new replication domain.

  9. Configure these servers as consumers of the replication domain.
  10. Add the rest of the clients to the new data replication domain.

    Perform this step only if the application server configuration you are migrating uses an instance of data replication service in client/server mode.

  11. Configure these clients as consumers of the replication domain.
  12. Restart all of the application servers and clients.
  13. Delete the empty multi-broker replication domain.

What to do next

During this process, you might lose existing sessions. However, the application remains active through the entire process, so users do not experience down time during the migration. Create a new replication domain for each type of consumer. For example, create one replication domain for the session manager and another replication domain for dynamic cache.



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Comparison of multi-broker versus data replication domains

Data replication domains replace multi-broker domains for data replication between application servers in a cluster.

About this task

For transitioning users: trns
Any replication domains that are created with a previous version of the product might be multi-broker domains. Migrate any multi-broker domains to the new data replication domains. Although you can configure existing multi-broker domains with the current version of the product, after you upgrade your deployment manager, you can create only data replication domains in the administrative console.

Multi-broker and data replication domains both perform the same function, which is to replicate data across the consumers in a replication domain. Configure all the instances of replication that need to communicate in the same replication domain. You can also configure the session manager with both types of replication domains to use topologies such as peer-to-peer and client/server to isolate the function of creating and storing replicas on separate application servers. You can control the redundancy of replication for each type of replication domain. With a data replication domain, you can specify a specific number of replicas.

If you used multi-broker domains with earlier versions of the product, use the following comparison chart to learn the differences between how Version 5.x and Version 6.x application servers use the two types of replication domains:

Version 5.x application servers using replication domains Version 6.x application servers using replication domains
Replication domain types Uses only multi-broker replication domains for replication. Servers that are using the current version of the product can be configured to use both multi-broker replication domains and data replication domains for replication. The two types of domains provide backward compatibility with multi-broker domains that were created with a Version 5.x application server. You should migrate any multi-broker domains to data replication domains.
Data transport method Uses multi-broker domain objects that contain configuration information for the internal Java Message Service (JMS) provider, which uses JMS brokers as replicators. Uses data replication domain objects that contain configuration information to configure the high availability framework on the product. The transport is no longer based on the JMS API. Therefore, no replicators and no JMS brokers exist. You do not have to perform the complex task of configuring local, remote, and alternate replicators. The earlier version of the product do not support data replication domains. The current version of the product can be configured to perform replication using old multi-broker domains by ignoring any JMS-specific configuration and by using the other parameters to configure replication through the high availability framework.
Replication domain configuration The earlier version of the product encourages the sharing of replication domains between different consumers, such as session manager and dynamic cache. The current version of the product encourages creating a separate replication domain for each consumer. For example, create one replication domain for session manager and another replication domain for dynamic cache. The only situation where you should configure one replication domain is when configuring session manager replication and stateful session bean failover. Using one replication domain in this case ensures that the backup state information of HTTP sessions and stateful session beans are on the same application servers.
Partial partitioning You can configure partial partitioning. Partition the replication domain to filter the number of processes to send data. Partial partitioning is deprecated. When using data replication domains, you can specify a specific number of replicas for each entry. However, if you specify a number of replicas larger than the number of backup application servers that are running, the number of replicas is the number of application servers that are running. After the number of application servers increases above your configured number of replicas, the number of replicas that are created is equal to the number that you specified.
Domain sharing Multiple data replication service (DRS) instances share multi-broker domains. A limitation exists on the number of multi-broker domains that you can create because every multi-broker domain contains at least one replicator. A maximum of one replicator can be on each application server. All DRS instances in a replication domain use the same mode. Each replication domain must contain either client only and server only instances, or client and server instances only. For example, if one instance is configured to client and server, all other instances must be client and server. If one instance in a replication domain is configured to be a client only, you can add client only and server only instances, but not a client and server instance.



In this information ...


Related concepts

IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 9:31:45 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=trun_drs_migrate
File name: trun_drs_migrate.html