In the first post for this topic I covered a bit of the history of full-text index (see it here), what xPlore is bringing to the table and I introduced the migration options. This post will focus on the migration options and what is entailed in each.

I could have taken a leaf out of the Lawrence Maynard Book of Controversial Writing style but I think I’ll leave the Boat People out of this one….

Firstly, some quick facts about the migration:

• No additional license is required
• xPlore is compatible with Content Server 6.5 SP2 (with latest hot fixes) and above
• No client side upgrade required (5.3+ compatible)
• Zero downtime upgrades can be easily achieved

In the last post I listed the key migration options as Cold Swap, Straight Migration and Dual Mode. Let’s look at each in more detail.

A Cold Swap

By far, the simplest approach to migrating to xPlore is a straight technology swap. This approach is basically an installation of xPlore and having it create the indexes. FAST is turned off during this process.

It can be over the existing FAST hardware or on a new server but remember that if you reuse the FAST hardware you complicate your roll back option! The supported way of restoring a backup of FAST is to restore the application and the FIXML and then rebuild the indexes from the FIXML.

One of my main dislikes with FAST is that it has never supported restoring the binary indexes directly limiting both backup/restore and replication for Disaster Recovery.

So when would I go with the “Cold Swap” option?  When the repositories are small (and therefore index time is short) or an extended period of downtime for full text search is acceptable for your implementation. Remember that in extreme cases indexing could take weeks with FAST. While xPlore will perform better, that magnitude of data will still take a long time to full text index.

A Straight Migration

This twist on the migration theme uses additional hardware to run a parallel full text index but using xPlore:

New hardware is added to the infrastructure to house xPlore and an additional Index Agent. Both FAST and xPlore are running at the same time so the system is fully available while xPlore is doing its initial index build. At this point all searching is performed through FAST. The limitation is that only one set of indexing hardware can be used for searching at a given time.

Once the index build is finished the search is repointed to use xPlore. At this point FAST can be turned off and eventually decommissioned.

A system outage is required to repoint the searching from FAST to xPlore as the Content Server needs to be restarted after each switch. This typically would be about an hour but would vary depending on number of Content Servers, etc.

So when would I choose this option? When I had restrictions on the amount of downtime I could impose and I was in a budgetary/procurement position that allowed me to add additional indexing servers.

Dual Mode Indexing

This brings us to the last and perhaps most extreme of the options. Dual Mode indexing and search is similar to the “Straight Migration” configuration but also adds an additional content server and an additional WebTop server into the mix enabling both FAST and xPlore to be available on the same repository:

Both FAST and xPlore are performing full text indexing and both can be used to search (via the specific WebTop instance).

Users can be migrated over time between FAST and xPlore (again via the WebTop instances) with FAST being eventually decommissioned.

This approach is clearly the most costly but minimises migration risk and business disruption. It is most suited to those circumstances where ANY downtime of search and index is unacceptable to the user base.

Concluding note

This covers the key options for migrating from FAST to xPlore. Clearly more complicated infrastructures offer more possibilities and challenges. For example, a highly available FAST install may enable use of the second row (the second set of nodes for redundancy) to add xPlore with non-HA indexing being acceptable during the swap over. We have virtualisation options now, and so on.

If you are interested in some of these scenarios it might be time for a chat with your friendly EMC IIG Services professional……

xplore