0
Answered

IdB and High Availability

Eddie Kirkman 8 years ago updated by anonymous 8 years ago 3

Since IdB is now presenting data to FIM via LDAP, is there any technical reason why two IdB server could not be load balanced behind an F5 or similar? Customer currently has FIM and IdB4 on a server and a second (warm standby) with the same. If idB5 were on separate servers (one active and the other warm standby) and if the FIM MA were pointing to a name that resolved to a VIP, then I assume that as long as the VIP could work out which IdB server had the service running that would work. Do we know if anyone has done/tried this, or do we generally recommend keeping FIM and IdB co-located on the same server?

Answer

Answer

Ah - we have a semantic issue - my definition of a cold standby is when the spare server is not running. My definition of a warm standby is where the server is running but the FIM and IdB services are stopped. Full on both running, which as you say would require separate databases and could cause all sorts of pain I would call hot standby.

At one of our customers they wrapped the service in small program that checked the other server and has some smarts built in to stop the service running on both. For my current engagement I think I will recommend their current design with FIM and IdB co-located and the services disabled on the standby server. Thanks

Searching answer

Hi Eddie,


I don't know of any sites that have had a warm standby, but I do know of at least one with a cold standby. At one point the standby was found to be running when it shouldn't have been, so it was effectively operating as a warm standby running off the same SQL database, which caused a huge number of problems with the two instances fighting over adapter change tokens. There is some documentation on cold standby (https://unifysolutions.jira.com/wiki/display/IDB50/Disaster+Recovery+and+Cold+Standby), but none on warm standby. They would at least need to have separate SQL databases, but you would also need to check whether all source systems support multiple consumers (e.g. the chris21 connector consumes change tokens in the source system, so you wouldn't be able to have two instances running together).


I would suggest advertising this topic on Yammer to see if anybody else has any experience running a warm standby.

Answer

Ah - we have a semantic issue - my definition of a cold standby is when the spare server is not running. My definition of a warm standby is where the server is running but the FIM and IdB services are stopped. Full on both running, which as you say would require separate databases and could cause all sorts of pain I would call hot standby.

At one of our customers they wrapped the service in small program that checked the other server and has some smarts built in to stop the service running on both. For my current engagement I think I will recommend their current design with FIM and IdB co-located and the services disabled on the standby server. Thanks