In an age of always-on solutions, mobility is no exception. If a mobile service goes down for an hour, your users will notice.
We're going to leverage how IBM Notes Traveler allows you to extend your mobile servers to be highly available in order to give you a rock-solid mobile solution. IBM Notes Traveler is an application that provides two-way, over-the-air synchronization of email, contacts, and calendar between IBM Domino servers and wireless handheld devices. If you're an existing IBM Notes/Domino customer, it's a free entitlement, allowing you to extend your existing messaging and collaboration infrastructure to include mobile devices.
I've covered the steps on how to configure Traveler in a previous TechTip, so you can get started there. You can download and configure a Traveler server on IBM i in about a half hour.
The real question is "how do I get IBM Notes Traveler working in my high availability environment?"
It's simple. Essentially two things need to happen:
1. Configure Traveler to use DB2 on IBM i instead of the default Derby database.
2. Your DB2 database must reside in your high availability environment.
For the purposes of this example, I'll be using POWERHA and an Independent Auxiliary Storage Pool (IASP), taking for granted that you have a functioning POWERHA environment.
Before we do anything, we must first power down the Domino server for Traveler.
Create a user profile that will access Traveler via JDBC. Make note of the IP address or FQDN of the IBM i partition that will store the Traveler database.
Create a symbolic link to the jt400.jar file that will facilitate the JDBC connection. The documentation suggests you copy the file to the Traveler Domino server's /traveler directory. I'd suggest you don't do that because, if the file is copied, it's never updated if the source jt400.jar file is updated. Creating the symbolic link will allow you to reference an always-updated jt400.jar file.
On IBM i 6.1, the jt400.jar file is in QIBM/ProdData/HTTP/Public/jt400/lib. On IBM i 7.1 it's in /QIBM/ProdData/OS400/jt400/lib.
The command for adding a symbolic link for 7.1 would be ADDLNK OBJ('/QIBM/ProdData/OS400/jt400/lib/jt400.jar') NEWLNK('/qibm/proddata/lotus/domino900/traveler/lib/jt400.jar')
If you already have Traveler running on DB2, the LNT library will by default be in your system ASP (*SYSBAS). If that's the case, backup, delete, and then restore the LNT library into the IASP. Since you can't have the same library existing in your IASP and in *SYSBAS at the same time, you need to delete the library from *SYSBAS before attempting to restore it to the IASP.
The next step is running the travelerUtil script from Qshell, which will set the Traveler server to use DB2 for i, and more specifically the IASP the Traveler library now lives in. If you already use DB2, after you run the travelerUtil script, upon server start your Traveler server will find the LNT library which now resides in the IASP and operate normally. If you used Derby before this exercise, your Traveler server will create the LNT library in the IASP.
When running the travelerUtil script, the "database name=IASP1" component of the command isn't documented, but with a little playing around I found the solution.
./travelerUtil db set url=jdbc:as400://192.168.1.12/LNT;database name=IASP1 would seem logical as I'm just appending the database name parameter (where IASP1 is the name of my IASP) to the command. However, this is incorrect because Qshell treats a semicolon (;) as a command separator.
Ouch. What we non-UNIX guys must learn the hard way.
Here's the right way:
Run travelerUtil, but provide the DB2 for i user id and password first.
./travelerUtil db set user=username pw=password
You'll be prompted for the path at that point, so enter your connection info in with this string. Substitute your own IP for the example one.
Once the command finishes, you just power up your Domino server for Traveler.
If coming from Derby, you'll see Domino console messages stating that it's migrating users to the high availability pool. If the server doesn't start, power down Domino and re-read the instructions. You'll know pretty quickly if something got botched.
From this point, you can create other Domino servers, attach Traveler to them, and then follow the steps to point them to the live DB2 instance. During a POWERHA failover, Traveler won't skip a beat because POWERHA does an optional step of varying off and on IP interfaces so the same DB2 related IP address will start up on another machine. If for some reason you have machines with different IP addresses (in different physical networks) and it's more of a manual switch, use a fully qualified address (e.g., db2fori.domain.com) instead of an IP address so that DNS does the job for you of finding your LNT library.
People recommend IP sprayers to do the dirty work of pointing to load-balanced Traveler addresses. That's the ideal solution. Personally, with about 50 mobile users, I'm just using old-school round-robin for our public and private DNS requests and network address translation (NAT) to get Traveler requests through the firewall. It works for me, but if you have hundreds or thousands of users, it's probably best to invest in some proper network hardware to do the load balancing.