Moving an existing Clarity Installation to new application servers.

[Terry Becker]

Hi, I've been tossing around various scenarios for how I am going to both upgrade my Clarity installation (12.0.6 to 12.1.1 and finally 13.0 ) as well as move the application to new VM servers. I've been playing around with copying the clarity root folder to the new server as well as doing a fresh install of the 12.0.6 version prior to the upgrade.

I found one article where someone installed Clarity against a blank database schema, then pointed the new install to the existing database before running the upgrade. That seems to make sense to me.

Here is my environment.

Application is on Windows and is deployed in WebLogic
Database is Oracle.


I am currently working on my QA environment so that I can practice the upgrade without impacting my users. If all goes well, I will follow the same process when I go to PROD.

So, what is the concensus out there in the community?

Option 1. Install Clarity 12.0.6 on my new server using a copy of the existing 12.0.6 database. Then upgrade 12.0.6 to 12.1.1.
Option 2. Copy the Clarity 12.0.6 root directory to the new server, then upgrade the 12.0.6 to 12.1.1.
Option 3. Install Clarity 12.0.6 against a new Clarity database, drop the database and point the fresh install to the existing 12.0.6 database. Then upgrade 12.0.6 to 12.1.1.
Option 4. something else??

NOTE: I have been asked by my management to upgrade to 12.1.1 before going to 13.0 for testing.

Thanks for any help, I'll be interested in hearing what experiences everyone has had with these scenarios.
Terry

[Deactivated User]

Not using Weblogic or Oracle just Windows and MS SQL and Actuate but on VMWare

My vote goes on
Using a copy of the existing db and doing either clean Clarity install (12.0.6) or copying the folders if you are happy with them. Which would be Options 1 and 2.
I take BO has to be installed fresh.
Off hand I can't see the benefit in Option 3.

Martti K.

[Anon Anon]

Note done it with those particular versions but....

Do a fresh install of 12.1.1.
Throw the (empty/vanilla) database away and point the 12.1.1 install at your 12.0.6 database.
Run the DB upgrade in the NSA.

(To be honest though thats not much less elapsed time than doing a new install of 12.0.6 and then just running the full upgrade process).

--

FWIW I don't ever think "copying the folders around" is a supported option (it might well work OK, but thats not the point).

[Deactivated User]

Doing a fresh install would skip some parts of what the install script does.

I've been attitude adjusted to Windows programs writing to registry and therefore making simple copying and delete less useful.
On the other hand java programs were supposed to be platform independent.

You can see some opinions on where Clarity is in this relation in
Copying the application binaries from 32 bit to 64 bit
2297972

If you are not happy with copying, you could use nikuadmin backup and restore the backup to you new server.



Martti K.

[Deactivated User]

There is another thread on copying

Clarity Upgrade to 12 on Windows 2008 server
15619659

Martti K.

[Terry Becker]

Thanks for the great suggestions. I'm going to read through all of this tonight and come up with my plan of attack. I'm kind of leaning towards a new install against a throw-away database. I hadn't even considered a nikuadmin backup and restore, so that is very interesting.

Thanks again,
Terry

[Robert_Ensinger]

I'll toss in my tuppence. Installing fresh, switcharoo-ing the underlying database then running the upgrade may be in theory the most efficient (undocumented? unsupported?) concept... but it fails gloriously in our environment (CA Clarity Small Architecture on Windows).

Nikuadmin backup and restoring the existing application to the new architecture first, then upgrading has been solid and is our migration strategy. As currently planned, we're migrating from 12.1, Win Server 2003 32bit to 13.01 Win Server 2008 R2 64bit, CA Clarity Small Architecture.

Migrating in stages like this is also prudent. Should trouble arise you get to handle it definitively in series instead of guessing in parallel. Less variables, provides 'bake time' on the new architecture to build confidence, and it's one less (major!) activity on upgrade day.

Prototype, design a strategy, then test test test!

[ShameemAhmed]

Dave wrote:

Note done it with those particular versions but....

Do a fresh install of 12.1.1.
Throw the (empty/vanilla) database away and point the 12.1.1 install at your 12.0.6 database.
Run the DB upgrade in the NSA.

(To be honest though thats not much less elapsed time than doing a new install of 12.0.6 and then just running the full upgrade process).

--

FWIW I don't ever think "copying the folders around" is a supported option (it might well work OK, but thats not the point).

Hi Dave,

Can you please help me in understanding if we go via the route you have suggested ; dont we have to install preupgrade, xdm and postupgrade too from the nsa, or only Database is enough. Checked the preupgrade script and it seems to be updating some tables in the database.

Thanks

[Anon Anon]

ShameemAhmed wrote:

Can you please help me in understanding if we go via the route you have suggested

Please DO NOT assume that just because I have said something "works" that you can just use it! :what:

As for your question - I don't know.... probabl? depends what the NSA makes you install? depends on the exact versions you are going from/to? depends on your systems? - you have to dry-run anything like this in DEV systems (probably many times) - that will give you the answer rather than me GUESSing.

[Nick Darlington]

This approach isn't going to work well I'm afraid, and I've had to field problems related to it several times - the answers aren't happy answers either, it's usually a case of requiring the exercise to be redone in a way that will work and can be supported. So never restore an 'old' version database to a newer Clarity and then perform the NSA steps or else I might have to reply to your support issues with the bad news.

Copying folders isn't so bad, there may be some gotchas (leaving behind default-hidden folders and files on unix because their names began with a period), but certainly shouldn't be undertaken by anybody without a full knowledge of Clarity's folders and dependent paths (filestore, etc.).

The preferred and simplest method would be to reinstall 12.0.6 fresh and fully against a brand new database schema on the new server, then switch the database to point to the restored one you want to use with all your data in, then upgrade it in-place on the new server to 12.1.1.

[Nick Darlington]

Option 1 is likely to overlook some requirements. Like the need to have XDM installed on that server (even though your database already believes it has been done, the application code is missing it) for example. I'd suggest dropping this from consideration.

Option 2 is OK so long as your paths to filestore, jdk, tomcat are all good after you copy it across, check the properties.xml before starting up any services to be sure. As a rule, I tend to remove all services first, then take my copy across, then add/deploy them fresh. Avoids any strangeness with it having the services being out of sync with Clarity's expectations of them. I do this for speed in my labs, but it requires more experience to do and get it right.

Option 3 is an OK option but you must take the installation against the fresh/new database schema right to the end (including database and xdm steps in the NSA). You might also have to consider the restoring of your filestore separately, if it's not being held in the database backup that you'll be using but is on disk instead. This is the one I typically end up coaching customers through if something went wrong with their migration/upgrade and an issue is raised, so I would consider it the easiest to get right at this point.

Filestore considerations don't usually amount to much more than network shares and permissions in a clustered environment, or a files/folders copy (which may or may not be a path below the $NIKU_HOME installation root folder) to the new server, and in all cases ensuring the backup or last change of these files is taken during the same maintenance window as the DB backup was taken (i.e. no possibility of either one being newer and out of sync between data and files).

[Terry Becker]

Hi all, I'm back to report on my efforts to migrate my Clarity application to 12.1.1 on new hardware.

I eventually decided to go with option 3, doing a fresh install of Clarity against a new database, then copy the existing database over the blank database prior to the upgrade to 12.1.1.

1) I asked my dba to create the empty niku schema. I then ran the install of 12.0.6. (The install required an older version of java than what 12.1.1 wants) My testing was limited because I really didn't have any data to run jobs/proceses against. I started Beacon and BG.

2) After stopping the app, NSA and BG, I asked my dba to overlay the newly installed database with the data files from my production 12.0.6 database. I had to update a few custom parameters in cmn_custom_script_params to point to the correct server.

3) I started NSA to make sure all of my settings were still correct. I did a save on each page just to make sure everything was correctly saved.

4) Started the app and logged in to validate the application was working. Started BG to make sure it would run. (I had paused all jobs when I took the backup of my production database).

5) Stopped everything, took a backup and performed the upgrade to 12.1.1.

Everything seems to go very well. The only error I ran into was that a few of my timeslices didn't want to upgrade. CA Support asked me to rename then and then readd them post upgrade. Otherwise the install/upgrade plan seemed to work out very well for me.

I'm now playing with the second server in my environment. Since I am using weblogic, I'm trying out different combinations of what needs to be loaded on the second (non NSA) server. At this point I have copied the clarity_home folder over to the second server and then deployed the niku.ear file under weblogic. I'm also wondering if I need BEACON running there since I am using weblogic.

Thanks to everyone who jumped in to discuss these options. I'll add another post when I get my production system migrated to its new servers.

[Deactivated User]

Thanks.
It is always interesting to hear how did it go.

Martti K.

[Shalinee Chauhan]

nick_darlington wrote:

Option 2 is OK so long as your paths to file store, jdk, tomcat are all good after you copy it across, check the properties.xml before starting up any services to be sure. As a rule, I tend to remove all services first, then take my copy across, then add/deploy them fresh. Avoids any strangeness with it having the services being out of sync with Clarity's expectations of them. I do this for speed in my labs, but it requires more experience to do and get it right.



Hi Nick,

In our enviornment we have small level of customization in out of the vxsl and xml files as well as custom jsp's and java jobs. In that kind of setup we are planning to go with Option 2-

We are on CA Clarity 12.0.4, OS-Windows and SQL 2205 database server with Tomcat web server.

Could you please suggest what will be the best approach to copy the root folder from existing production server setup to Sandbox setup. Also what would be the best upgrade approach for small size customized setup ?


Thanks

[Nick Darlington]

The only thing I would advise about customizations like that, is be sure you can back them out before doing a server migration and/or upgrade, and then apply again after the upgrade, if and where appropriate, and re-test them.

Anything else and all bets are off, too much scope for problems.

[Shalinee Chauhan]

Thanks Nick,

I am assuming the same. let see how does this go.

Shalinee

[Anon Anon]

Hi Nick,

The preferred and simplest method would be to reinstall 12.0.6 fresh and fully against a brand new database schema on the new server, then switch the database to point to the restored one you want to use with all your data in, then upgrade it in-place on the new server to 12.1.1.

Thank you for the suggestion. So at what point does one carry over the application settings in the above scenario? I'm not sure what the proper term is: cutomizations (i'm talking about like attributes creates, the way the page is laid out, all the settings)?

[Nick Darlington]

The information you're referring to is all part of the configuration in Clarity that is done through Studio. This information is all retained within your database.

So when you switch to the restored database and begin to upgrade it, all that configuration will come with it.

[Anon Anon]

oh (sorry if this is a stupid question) so option 2 above had stated to copy the root directory to the new server. So why would I want to do that? I thought that was carrying over my customizations.

[Deactivated User]

If Nick is not there my crack at it is that

Copying the folder from the old system would among other bring the settings in NSA/CSA which you normally do fresh when you do a new install.
On the other hand that would also bring over the unsupported customization you might have in those folders.

A fresh install would give you a system "in supported condition".


Martti K.

[Deactivated User]

Two other reasons are.
- backup and restore (for copying) is usually faster than installin a base version and SP and patch
- you don't have to locate the install media for the old version


Martti K.

[Anon Anon]

This is an awesome thread by the way.