Cisco CSS LDAP loadbalancing?

nikolay_nenchev · ‎08-12-2010

Hi all,

our company is using Cisco CSS for loadbalancing an internal application ldap queries between multiple OpenLDAP servers.

Loadbalancing is working fine, here is CSS configuration that we are using:

service pmaster
keepalive maxfailure 6
ip address IP1
keepalive frequency 10
keepalive type script ap-kal-ldap "IP1"
keepalive retryperiod 10
active

service smaster
ip address IP2
keepalive frequency 10
keepalive maxfailure 6
keepalive type script ap-kal-ldap "IP2"
keepalive retryperiod 10
active

!*************************** OWNER ***************************
owner DS
! read ldap vip
content rldap
protocol tcp
vip address VIP_12
port 389
balance aca
add service pmaster
add service smaster
active

However our interbal application logic is to establish N ldap sessions/binds on startup to LDAP server (through VIP) and use these sessions for further queries/reads ldap opearations.

In case that one of OpenLDAP server is down, running sessions will be dropped and application will send ldap binds up to the number N ldap sessions.

Once failed LDAP server is up again, it will not receive any new binds, since internal application had reached binds number N.

Is there a way in Cisco CSS to tune this behaviour and utilized all LDAP servers, independant from applications bond logic?

chrhiggi · ‎08-12-2010

Nikolay-

If I understand what you are asking, once the intial sessions are up, the LDAP servers do not initiate any new sessions, it re-uses the existing ones for all quries. There are 2 aspects to consider - UDP and TCP.

With TCP, when a server comes online under a rule via probe activation or manually adding a new one in, the CSS will only ever send a new TCP sessions to it. (inbound SYN is considered a new session.)

UDP is a bit different since it is a connectionless protocol, you could in theory adjust idle timers to make the CSS think an inbound packet is a new session which would essentially force the sessions to the new server. I am not sure how your application operates, I know LDAP *can* use UDP over 389 for certain functions, but its food for thought.

Regards,

Chris Higgins

knutsong · ‎08-13-2010

We are doing something simular. We had to include a group to tie the sessions with the original source IPs. Beyond that, we added a flow-timeout-multiplier to prevent session timeouts.

Owner/ Group example:

owner LDAP_Owner

content LDAP_Rule
vip address X

    port 389
    protocol tcp
    flow-timeout-multiplier 19
    balance weightedrr
    add service LDAP_1
    add service LDAP_2
    add service LDAP_3
    add service LDAP_4
    active

group LDAP_Group
flow-timeout-multiplier 19
vip address X
add destination service LDAP_1
add destination service LDAP_2
add destination service LDAP_3
add destination service LDAP_4
active

nikolay_nenchev · ‎08-13-2010

true, we are always using source groups and flow timers. - just i tried to keep it simple here

question is how to keep connections to ldap servers equal, when some of the ldap servers fails and becomes available again.

As I mentioned, our application will just establish N number of ldap sessions/binds and used them for queries.

Do you have same problem, knutsong?

Or you application is binding / unbinding on a time intervals.

knutsong · ‎08-13-2010

We weight ours to put more load on one server than others. I would think you could use standard round-robin. If a server fails then comes back up, round-robin will eventually balance them out. As I mentioned, we had a issue with timeouts so we put in the flow timeout. That resolved it. The balancing works well.

nikolay_nenchev · ‎08-13-2010

i dont think that balance method matters here. we are using aca, but I dont see how round robin or weights will solve the case.

Here is my case again:

1 application that is establishing 16 ldap binds/sessions to VIP address.

Both ldap servers are active and every one gets 8 binds/sessions.

Application is quering ldap in over established connections.

first ldap server goes down. 8 sessions are reseted, and application is establishing new 8 sessions to VIP address.

as at that time only second ldap server is available, it must handle now all 16 ldap binds/sessions.

lets say in 1 hours, failed first ldap server is coming up again. But.. application is not establishing new binds as it has reached already the max number of 16 ldap connections - all of them through VIP address and directed to second ldap server.

first ldap server will stay unused till some of the binds fail or being reseted or second ldap server dies.

Then applicaiton must establish again its binds and LB will do balancing.