I am looking for a solution that would allow me to configure jira to use several LDAP/AD servers.
All servers are supposed to be identical (replicas).
I know that Jira does not allow you to configure alternative/fallback LDAP servers and that configuring several AD is not a solution due to group memebership limitations.
Still, I would like to know if I can trick the system to be more redundant in case of AD going down for some reason.
One thing I am considering is using a special DNS entry for this but I am not sure how I should configure it to make it work well.
Would this be a good idea, or not? What alternatives do we have?
This problem is actually outside of JIRA. This is the same case when a user tries to login to computer connected to an LDAP for authentication. The redundancy should be set outside of the system with the LDAP failing over to redundant systems as mentioned by Harry. It should be an IP failover, as DNS will still result in requests going to the old IP till the DNS cache expires, I believe.
It should be an IP failover, as DNS will still result in requests going to the old IP till the DNS cache expires, I believe.
Why would it? A well-written application could try connecting to all IP-addresses behind the given hostname in parallel and using the one, which respods first. It could also maintain a pool of such connections for reuse the way database-connections are pooled, or the way web-proxies keep open HTTP-connections to the back-end origins they are fronting for.
If implementing such parallel access is too much for a programmer, he could, at least, implement sequentional access -- if a connection to the first IP returned by gethostbyname(), keep trying until the return list is exhausted.
Not really. Let's take the example of a Windows Desktop/Laptop that connects to the Active Directory. The failover is not implemented at the desktop/laptop side (AFAIK) and this is taken care at the AD/LDAP level to have a redundancy at the AD side (this is also true AFAIK about even *nix based clusters).
Isn't only fair that way to leave the logic of failover/redundancy at the server side rather than every client connecting to the AD/LDAP to implement such procedures?
The failover is not implemented at the desktop/laptop side (AFAIK)
Renjith, you are quite misinformed. Kerberos clients -- both "original" Unix ones and the Active Directory implementation -- have always allowed you to provide multiple server-entries. Exactly for this purpose -- should one of the servers fail, the entire fleet of workstations can continue to function. It was done this way long before Virtual IPs and GTMs were invented.
DNS client-libraries too support talking to multiple servers -- if it can't reach the first one listed in /etc/resolv.conf, it will try the next one.
For another example, Sun's NIS (a.k.a. Yellow Pages) also allows multiple servers -- and clients could switch from one to another one the fly. Sybase, for yet another example, as well have always allowed for multiple redundant servers behind a single name (they, actually, have their own layer above DNS).
Isn't [it] only fair that way to leave the logic of failover/redundancy at the server side rather than every client connecting to the AD/LDAP to implement such procedures?
No, it is not fair. First, because, it is much easier for a client to try another IP, than for a VIP to function properly. In fact, VIPs are pretty horrible hacks -- they are necessary, because applications programmers tend to be inexperienced and ignorant. To work, a VIP needs to constantly check all of its multiple back-ends so as not to send a client to a failed back-end once in a while -- and it still happens causing an error on the client.
And second, when your clients all share the same code, you don't implement it on "every client" -- only once.
As JIRA /CROWD? don't support mulitple repositories, if you want realtime failover between mirror LDAP/AD servers (been there) then you have two choices, if you are lucky enough to have an F5 you may be able to load balance over a group of mirrors through an F5 managed IP. If you aren't, then you can get good mileage out of a simple software TCP proxy, I did this in my last role with PEN for JIRA and Confluence. If you aren doubly unlucky and run windows, then maybe you can find a similar product.
More on load balancing at loadbalancing.org
The Jira Marketing team is putting together an ebook on migrating to Data Center. We're looking for pro tips on how you staffed your project team and organized your Proof of Concept. Share yo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG