test

Sun Java System Directory Server Enterprise Edition 6.0 Migration Guide

Migration Scenarios

This section provides sample migration scenarios for a variety of replicated topologies.

Migrating a Replicated Topology to an Identical Topology

Before you start migrating replicated servers, determine whether your deployment might not be better served by changing the architecture of the topology. This section describes how to migrate if you want to keep your existing topology. Migrating a replicated topology to an identical topology, involves migrating the consumers, then the hubs, then the masters. The following sections demonstrate a sample migration of a simple multi-master topology.

Migrating the Consumers

    For each consumer in the replicated topology:

  1. Reroute clients to another consumer in the topology.

  2. Disable any replication agreements to the consumer you want to migrate.

  3. Stop the consumer.

  4. Migrate the consumer according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.

  5. Start the consumer.

  6. Enable the replication agreements from the hubs to that consumer.

  7. If you have migrated the data, check that replication is in sync.

  8. If you have not migrated the data, reinitialize the consumer.

  9. Reroute clients back to the consumer.

The following sequence of diagrams illustrate the migration of a consumer, as described above. The first diagram shows the version 5 topology before the migration.

Figure 4–1 Existing version 5 Topology

Figure shows basic multi-master topology

The first step involves rerouting clients and disabling replication agreements, effectively isolating the consumer from the topology.

Figure 4–2 Isolating the Consumer From the Topology

Figure shows consumer removed from topology

The next step involves migrating the version 5 consumer.

Figure 4–3 Migrating the version 5 Consumer

Figure shows migration of one consumer

The next step involves enabling the replication agreements to the new consumer, initializing the consumer if necessary, and rerouting client applications to the new consumer.

Figure 4–4 Placing the 6.0 Consumer Into the Topology

Figure shows topology with one migrated consumer

Migrating the Hubs

    For each hub in the replicated topology:

  1. Disable replication agreements from the masters to the hub you want to migrate.

  2. Disable replication agreements from the hub you want to migrate to the consumers.

  3. Stop the hub.

  4. Migrate the hub according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.

  5. Start the hub.

  6. Enable the replication agreements from the masters to that hub.

  7. Enable the replication agreements from that hub to the consumers.

  8. If you have migrated the data, check that replication is in sync.

  9. If you have not migrated the data, reinitialize the hub.

The following sequence of diagrams illustrate the migration of a hub, as described above. The first diagram shows the topology before migrating the hubs.

Figure 4–5 Existing version 5 Topology With Migrated Consumers

Figure shows basic multi-master topology with migrated consumers

The first migration step involves disabling replication agreements, effectively isolating the hub from the topology.

Figure 4–6 Isolating the Hub From the Topology

Figure shows hub removed from topology

The next step involves migrating the version 5 hub.

Figure 4–7 Migrating the version 5 Hub

Figure shows migration of one hub

The next step involves enabling the replication agreements to the new hub and initializing the hub if necessary.

Figure 4–8 Placing the 6.0 Hub Into the Topology

Figure shows topology with migrated consumers and hub

Check that the replication on the consumers is in sync with the rest of the topology before migrating another hub. A server that has just been migrated does not have a change log, and can therefore not update consumer servers that are out of sync. Allow the topology to stabilize and all servers to synchronize before migrating the next supplier server.

Migrating the Masters

    For each master in the replicated topology:

  1. If you have client applications that write to the master you want to migrate, reroute these applications to write to another master in the topology.

  2. Ensure that the master is no longer receiving write requests. You can do this by enabling read-only mode on the master.

  3. Check that replication is synchronized between the master and all its consumers.

    Migration of the change log is not supported if you are migrating manually, so the preceding two steps are mandatory in this case. Although automatic migration does migrate the change log, you should still perform the above steps to avoid the risk of losing changes.

  4. Disable any replication agreements to and from the master you want to migrate.

  5. Stop the master.

  6. Migrate the master according to the instructions under Chapter 1, Overview of the Migration Process for Directory Server.

  7. Start the master.

  8. Enable the replication agreements from the master to the hubs and other masters in the topology.

  9. If you have migrated the data, check that replication is in sync.

  10. If you have not migrated the data, reinitialize the master from another master in the topology.

  11. If you rerouted client applications (Step 2), you can now route the applications to write to the migrated master.

The following sequence of diagrams illustrate the migration of a master, as described above. The first diagram shows the version 5 topology before the migration of the masters.

Figure 4–9 Existing version 5 Topology With Consumers and Hubs Migrated

Figure shows basic multi-master topology with 6.0 consumers and hubs

The first step in migrating a master involves disabling replication agreements, effectively isolating the master from the topology.

Figure 4–10 Isolating the Master From the Topology

Figure shows master removed from topology

The next step involves migrating the version 5 master.

Figure 4–11 Migrating the version 5 Master

Figure shows migration of one master

The next step involves enabling the replication agreements to and from the new master and initializing the master if necessary.

Figure 4–12 Placing the 6.0 Master Into the Topology

Figure shows topology with one migrated master

Check that the replication on all hubs and consumers is in sync with the rest of the topology before migrating another master. A server that has just been migrated does not have a change log, and can therefore not update servers that are out of sync. Allow the topology to stabilize and all servers to synchronize before migrating the next supplier server.

Migrating a Replicated Topology to a New Topology

Before you start migrating replicated servers, determine whether your deployment might not be better served by changing the architecture of the topology. This section describes how to migrate a basic version 5 topology to a new all-master topology. Migrating to an all-master topology involves migrating the consumers, hubs, and masters, then promoting the hubs to masters and the consumers to hubs, then to masters. The following sections demonstrate a sample migration of a simple multi-master topology to a new all-master topology.

The following figure shows the existing version 5 topology.

Figure 4–13 Existing version 5 Topology

Figure shows existing version 5 topology

Migrating All the Servers

The first step is to migrate all the servers individually, as described in Migrating a Replicated Topology to an Identical Topology. The resulting topology is illustrated in the following figure.

Figure 4–14 Existing Topology With Migrated Servers

Figure shows existing topology with 6.0 servers

Promoting the Hubs

The next step involves promoting the hubs to masters, and creating a fully-meshed topology between the masters. To promote the hubs, follow the instructions in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

The following diagram illustrates the topology when the hubs have been promoted.

Figure 4–15 Migrated Topology With Promoted Hub Replicas

Figure shows migrated topology with four masters and two consumers

Promoting the Consumers

The next step involves promoting the consumers to hubs, and then to masters, and creating a fully-meshed topology between the masters. To promote the consumers, follow the instructions in Promoting or Demoting Replicas in Sun Java System Directory Server Enterprise Edition 6.0 Administration Guide.

The following diagram illustrates the topology when the consumers have been promoted.

Figure 4–16 New Fully-Meshed All-Master Topology

Figure shows new migrated topology with six fully-meshed masters

Migrating Over Multiple Data Centers

Migrating servers over multiple data centers involves migrating each server in each data center individually. Before you start migrating replicated servers, determine whether your deployment might not be better served by changing the architecture of the topology. If you want to keep your existing topology, follow the examples in Migrating a Replicated Topology to an Identical Topology for each data center. To migrate to a new topology, follow the examples in Migrating a Replicated Topology to a New Topology for each data center.