[ipac] installing HIP 3.x

[Michael Silver]

Hello,

It depends what you mean by "no downtime" - if you really mean
absolutely no downtime for any user, then it's beyond what I try to do.
I minimize downtime and often try to do these things in the wee small
hours of the morning, but there are a few minutes of downtime.

These notes all deal with Linux installations - if you're running
Windows the general process should work but the paths and commands will
definitely be different!

Major parts of the move are:

* Installing HIP on the new server. DANGER, WILL ROBINSON!
* Copying your xsl stylesheets and configuration from the old server to
the new.
* Creating (or possibly copying old) HIP indices on the new server.
* Copying your ipacadmin.gdb database from the old server to the new.
INVOLVES DOWNTIME
* Updating word_index and matham tables in Horizon.
* Updating DNS records, firewall policies, etc.
* Bring up new server.

Notes:

Installing 
==========
I usually install from scratch rather than trying to copy the entire
/opt/dynix structure. Theoretically, if the operating system and
architecture are the same this might work, but I feel you get a cleaner
instance doing a fresh install. 

The DANGER note is because you must not start the indexer on the new
server while the indexer is running on the old server. Running multiple
indexers against the same database results in incomplete indices on both
servers!

XSL
===
I copy the /opt/dynix/xsl/xsl folder and the
/opt/dynix/xsl/xsltransformer.xml files to the new server after making a
copy of the original ones. If you've set up multiple xsl processors,
you'll need to copy the multiple start scripts or recreate them.

Start the xsl processor(s) and make sure it's (they're) running
correctly.

HIP indices
===========
The indexer updates the indices as the database changes. They'll work
just fine without the indexer running although they will be out-of-date.
To rebuild the indices on the new server, you have to stop the indexer
on the old server first. The old HIP will continue to operate while
building the new indices.

Start the mass indexer on the new server. Don't start hzsearch or hzapp
on the new server until at least 50000 records have been processed.
Since you're building a new server, I wouldn't start those processes
until the build is complete.

The mass indexer will automatically become a dynamic indexer after it's
run, but I usually stop the indexer totally, then start the dynamic
indexer. That's primarily because I run the mass indexer in the
foreground so I can monitor the progress.

Theoretically, you could copy the indices from
/opt/dynix/hznindexservices/indexes/ on the old server to the new if
you're using the same architecture and operating system. I haven't
tested this since I always rebuild from scratch.

There is a document on the SD support site about rebuilding indices in
the background. You basically create a second instance of the
hznindexservices directory, stop the indexer in the main one and start
the mass indexer in the temp one. Once the indices are rebuilt, you stop
the hzsearch in the live one, copy the indices from the temp directory
to the live directory (after making a backup, of course) then start
hzsearch and the dynamic indexer. Seems to work well, and minimizes
downtime. The document title is "Keeping a backup of healthy hip
indexes: Regular mass-indexing in the background".

ipacadmin.gdb
=============
Here's the downtime part. Shut down hzapp on both servers, then create a
transportable backup on the old server. Do this with the following
command all on one line:
/opt/firebird/bin/gbak -IG -V -B -T -USER SYSDBA -PASSWORD password
/opt/dynix/appserver/jboss/server/default/data/ipacadmin.gdb
/opt/dynix/appserver/jboss/server/default/data/backupfilename.gbk

Note that there are graphical tools to do this and the restore mentioned
below, but I don't use them so I can't give you any pointers there.
Check out 
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_admin_tools 
for a list of available tools. You would run them on your desktop and
connect using the network.

Once the backup is created, transfer it to the new server, and restore
from the backup using the following command all on one line:
/opt/firebird/bin/gbak -USER SYSDBA -PASSWORD password -C -REP -V -P
4096 /opt/dynix/appserver/jboss/server/default/data/backupfilename.gbk
/opt/dynix/appserver/jboss/server/default/data/ipacadmin.gdb

NOTE: The command above replaces the existing ipacadmin.gdb database
without making a backup. If I was overwriting a live database, I would
make sure I have an backup of the existing file before blowing it away!

Update Horizon
==============
Change the entries in the word_index and matham tables in Horizon to
point to the new server. (As an alternative, you could swap IP addresses
between the new and old servers - just make sure you never have two
machines with the same IP address!)

Update DNS, firewall rules, etc.
================================
Change the DNS entry for your server to point to the new IP address, and
make sure the appropriate rules exist on your firewall(s) for access to
the new server. (If you did the IP address swap mentioned above you
wouldn't need to do this - the old ones should still work!)

Start hzapp, hzsearch on new server
==================================
You're done! It may take a while for the DNS changes to propagate, but
the actual work is done at this point.

I think this covers it all. I find that the actual downtime doing it
this way is less than 5 minutes. YMMV, of course.

I hope this helps. If anyone sees any errors or places to improve,
please let me know, either on-list or off!

Michael

 
Michael Silver, Network Administrator 
Parkland Regional Library 
5404 56 Avenue Lacombe, AB T4L 1G1 
Phone: 403.782.3850    Fax: 403.782.4650
http://www.prl.ab.ca/  msilver at prl.ab.ca