HA with standalone servers
Hello,
I have a customer that would like to install RTC 3.0.1 in a HA configuration in a cold-standby approach but, instead of using WAS cluster for the installation (like supported InfoCenter information), they would like to have separate WAS standalone servers installed and balance the service stopping and starting each server. The main advantange for them is to have 2 separate consoles. As this WAS configuration is usually seen, is there any problem for using this type of infrastructure configuration for RTC? The main configuration tips I can think of are: - The two IHS instances should be exactly configured not to have problems with public URI configuration - teamserver.properties configuration needs to be exactly the same. Maybe we could share installation and configuration disks or is it safely to repeat the installation and clone the configuration? - WorkItem cache directories can balance when getting service to stand-by server but access should only be to one server at time to avoid data corruption (like a SAN disks model), right? Any tips or caveats? Thanks in advance! Regards, Jorge. |
6 answers
This setup is what we did for a customer, the main difference being it was RTC 2.0.0.2.
We installed the first using the installation wizard. Then we installed the second using the installation wizard again and specifying the same information for things such as the DB connection and the file share to use for indexing. Each site has it's own IIS server, a plugin was generated from WAS for it's IIS server. The RTC address (URI) doesn't change but is pointed to whichever IIS/site is up. We use radware for this, but you could use any other mechanism, including DNS. In testing, each site was brought up/down independently of each other with no problems. This approach was confirmed and verified by IBM support. |
|
Thanks a lot for the info!
Just a couple of questions ... Do you share disks between the installed software? For example: - WokrkItem Index disks - "conf" directory - ... Thanks! Regards, Jorge. |
|
We didn't share the conf directory, although in theory I suppose you could. I'm sure there are pros and cons to doing this, it adds another point of failure, but systems/networks are pretty reliable these days.
The workitem index we did share, since this was easily configurable. In a situation where a switch to the other system was required, our plan (verified and tested in our environment) was to rebuild all the indices, not just the workitem index, and then to bring the alternate site up. |
|
|
|
Just a last question regarding this configuration ... How did you manage update of RTC plugins? (Preconditons and Follow-up). I mean, when new code is deployed, you mark the server for reset and restart the apps ..., when a change of the service occurs, do you need to repeat the reset operation to make the code be picked up by the second WAS server?
Thanks in advance. Regards, Jorge. |
|
It's been a while, so I don't remember the details....
We were doing extension development at the time, and I vaguely remember that we deployed a change to an existing extension to the primary server, and when we went to the backup, the changes didn't exist. The upshot was that we also had to deploy on the backup server as well. Sorry, I can't remember the specifics, the exact details, what caused it, or how we discovered the problem (I think it was during our DR testing, but I'm not totally sure). |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.