failover strategy from TS65 to TS741

Hello everyone,

I am planning to do a failover from TS65 to TS741 in linux environment. TS65 is running on solaris 8.

I have migrated all the contents from TS65 to TS741, everythin glooks good (user/groups/brach/pemissions)

Now for final failover where we need to shutdown TS65 and bring up TS741 in production server, i need to do a iw-store refresh to make sure everything is updated from TS65.

I have a question here

1) Is it possible to do iw-store refresh from TS65(solaris) to TS741(linux) without fail ?

2) Can it be avoided by manually adding editions and users if any change since i did refresh last time?

3) how to update WORKAREAs manually if needed?

TS Experts opinion needed Smiley Happy

Find more posts tagged with

Comments

Rick Poulin

1) Is it possible to do iw-store refresh from TS65(solaris) to TS741(linux) without fail ?

I do believe you can simply move the content store to the new server in this scenario, although you might want to "iwmigrate" the branches into a new store in order to get any performance optimizations in the content store format.

2) Can it be avoided by manually adding editions and users if any change since i did refresh last time?

Mostly, using my answer to #1. The issue is the user IDs will probably have changed, so you might have to go through the iwidmap exercise to map old uids to new uids.

3) how to update WORKAREAs manually if needed?

Depends on what you mean by "updating the workarea"

PS. "failover" is absolutely the wrong word in this context. I believe you meant "switchover" or "transition".

tsadminuser

Thanks for the response rpoulin!!

1) i was just wondering ..is all this can be done within 12 hour window?

as its gona be a switchover (like you said Smiley Happy it requires a downtime. How much time does it take usually incase of such migartion?

3) we have 200+ Workareas in current TS server and i have migrated all of them but still as this new ts 741 server was not in production user migat have created/updated so many contents from their WAs.

so how to get those things updated?

Rick Poulin

1) It could be done in a 12hr window if you've actually practiced this process on another server and you've documented exactly the steps you need to do and in what order. In terms of downtime, I tend to go with a period of 2-3 days so you're not rushed and make mistakes, but to each his own. All you need to do is 'freeze' your old server so users can read but not modify content during the switchover.

3) I don't know why you'd need to make changes to the content after moving it over, but you should have written a script to apply those changes if you had so many workareas. In this situation, the question answers itself -- migrate the content over from scratch and run your update script again.

tsadminuser

I find out a solution to update workareas by using opendeploy.not sure though it will work from OD 5.6 to OD741 server.But i need only 3 months updates.

Do you think its possible? i just want to avoid iwmigrate and all the migration complexity and most importantly downltime.

Rick Poulin

If you want to avoid the complexity, then iwmigrate is actually the way to go... The OpenDeploy route can only transfer the latest version of the content -- you could somewhat recreate the version history by iterations of deploying editions and submitting, but your timestamps would be all wrong.

Conversely, the iwmigrate approach is as follows:

* backup your old content store

* start deleting editions you don't care about, one by one, starting from the oldest and working your way forward

* copy the old store to the new server

* use iwmigrate to copy the branches you want to keep from the old to the new store

* optionally run iwfsshrink on the new store (recommended if you have that many workareas)

Adam Stoller

rpoulin wrote:
If you want to avoid the complexity, then iwmigrate is actually the way to go... The OpenDeploy route can only transfer the latest version of the content -- you could somewhat recreate the version history by iterations of deploying editions and submitting, but your timestamps would be all wrong.

Conversely, the iwmigrate approach is as follows:
* backup your old content store
* start deleting editions you don't care about, one by one, starting from the oldest and working your way forward
* copy the old store to the new server
* use iwmigrate to copy the branches you want to keep from the old to the new store
* optionally run iwfsshrink on the new store (recommended if you have that many workareas)

If you're copying the store over to mount it as a temporary second store and then perform an iwmigrate - you can specify which edition to start the migration from (see the '-s' flag).

You can also use the '-w -only' flags (check the manuals / help output to verify) to migrate the workareas.

I usually spend some time verifying the commands and writing a script to traverse the various branches and perform the migrations (and capture all the log data). This allows you to set the process to run over night and also, through pre-cutover-testing, allows you to get an idea of how long the whole process will take.