Forum Discussion
ppltam_183867
Cirrus
CirrusSession Persistent based on the HTTP Header
Hi DevCentral,
I am relatively new to Load Balancer technology. Our organization has just installed a LTM BIG-IP 2000s Version 11.6 as our Internal Servers node Load Balancer. The traffic flow is described as follows:
The actual Load Balancer clients are Mobile Apple IOS Device (e.g. Iphone, Ipad ..) and will somehow connect to an "Application Server" running a web services. All IOS clients initiate sessions connection to this "Application Server" first, then the "Application Server" will then initiate one Pool session to the Load Balancer LTM BIP-IP 2000s on behalf of the multiple IOS clients. It is a mandatory requirement to have "Session Persistent" on an application perspective based on each individual clients. Due to the above traffic flow behaviour, adopting both "Cookies" persistent and "Source Address" persistent methodology on the LTM persistent profile are not appropriate as the BIG-IP LTM is facing all traffic coming from this one and only "Application Server". Our application service provider proposed to inject an Parameter on the HTTP header e.g. "iSession" with a running unique session number for each IOS clients connection which initiate the traffic from the "Application Server" to the BIG-IP LTM in order to address the issue.
Our question is whether BIG-IP LTM can able to retrieve this session number from the HTTP Header provider by the application and based on this retrieved session number forward all subsequent requests with the same session to the same Node member. I understand this can only be done by using iRule as it seems all the "persistent profile" mechanism (i.e. cookies, source address, destination address, hash ..) can not achieve our requirement.
Highly appreciate your technical advice in advance and provide some guideline or implementation steps which will really help our project implementation.
Thanks & Regards Patrick
See this solution article:
If the HTTP Request contains the header value upon which to persist:
when HTTP_REQUEST { if { [HTTP::header exists iSession] } { persist uie [HTTP::header iSession] } }
ppltam_183867Really appreciate the quick response from Vernon and I am doing some research over that direction on the area of UIE (Universal Inspection Engine) in order to fit our project application requirements. As far as the details application requirements are concerned, we would like to take one step further as follows: The application server will in fact provide two pieces of information on the "HTTP Header", one of them is the "iSession" with a running session number for session persistent purpose. The other one is the "Priority Group Indicator" e.g. "iPGroup" which includes the Priority Group information One or Two (We are going to implementation two priority Groups" in our environment. Also, within a priority group, we will load balance the traffic according to a predefined Ratio for the pool members. The whole application logic would become : If the HTTP request contains the parameter "iSession" with the running unique session IDs, the LTM will route and persistent traffic to a particular node/pool member else If the HTTP request contains the parameter "iPGroup", the traffic will be forward to priority group define in the "iPGroup" value. Meanwhile, within the priority group the traffic will be load balanced to the group pool members according to a predefined ratio (e.g. 30 % / 70 %) for the two group members that belong to that group. end We would like to know if the UIE (Universal Inspection Engine) iRule <<********************>> when HTTP_REQUEST { if { [HTTP::header exists iSession] } { persist uie [HTTP::header iSession] } } <<*******************>> can combine with the logic of "Priority Group" as well as "Ratio" load balancing for the pool members and if so how can it be implemented. Your kind advice is much appreciated. Thanks & Regards Patrick
VernonWellsEmployee
See this solution article:
If the HTTP Request contains the header value upon which to persist:
when HTTP_REQUEST { if { [HTTP::header exists iSession] } { persist uie [HTTP::header iSession] } }- ppltam_183867Really appreciate the quick response from Vernon and I am doing some research over that direction on the area of UIE (Universal Inspection Engine) in order to fit our project application requirements. As far as the details application requirements are concerned, we would like to take one step further as follows: The application server will in fact provide two pieces of information on the "HTTP Header", one of them is the "iSession" with a running session number for session persistent purpose. The other one is the "Priority Group Indicator" e.g. "iPGroup" which includes the Priority Group information One or Two (We are going to implementation two priority Groups" in our environment. Also, within a priority group, we will load balance the traffic according to a predefined Ratio for the pool members. The whole application logic would become : If the HTTP request contains the parameter "iSession" with the running unique session IDs, the LTM will route and persistent traffic to a particular node/pool member else If the HTTP request contains the parameter "iPGroup", the traffic will be forward to priority group define in the "iPGroup" value. Meanwhile, within the priority group the traffic will be load balanced to the group pool members according to a predefined ratio (e.g. 30 % / 70 %) for the two group members that belong to that group. end We would like to know if the UIE (Universal Inspection Engine) iRule <<********************>> when HTTP_REQUEST { if { [HTTP::header exists iSession] } { persist uie [HTTP::header iSession] } } <<*******************>> can combine with the logic of "Priority Group" as well as "Ratio" load balancing for the pool members and if so how can it be implemented. Your kind advice is much appreciated. Thanks & Regards Patrick
- VernonWells
It can. You cannot use the BIG-IP priority group activation method for this, because it has a different meaning than what you describe above, but you can define two pools, one for each "priority group". You would then select the "priority group" based on the header field. You would set the Virtual Server LB method to "Ratio" and define the pool member ratios in each pool. It would look something like this (untested!):
when HTTP_REQUEST { if { [HTTP::header exists "iSession"] && [persist lookup uie [HTTP::header "iSession"]] } { persist uie [HTTP::header "iSession"] } else { switch [HTTP::header "iPGroup"] { "One" { pool pool-One } "Two" { pool pool-Two } } if { [HTTP::header exists "iSession"] } { persist uie [HTTP::header "iSession"] } } }In this configuration, you should also define a default pool for the Virtual Server, which would be used if iPGroup is not set or is not a value in the set ["One", "Two"].
- ppltam_183867Really Thanks Vernon for sharing the technical insight and would like to go a bit further. Traffic from the LTM Virtual Server going to the actual Node members who run web services are actually encrypted running SSL. On the LTM virtual server, we have defined two SSL profiles (One Client SSL and One Server SSL profile) as end-to-end encryption is a mandatory requirement due to confidentiality of the application. Question is can we still use the iRules suggested e.g. <<********************>> when HTTP_REQUEST { if { [HTTP::header exists "iSession"] && [persist lookup uie [HTTP::header "iSession"]] } { persist uie [HTTP::header "iSession"] } else { switch [HTTP::header "iPGroup"] { "One" { pool pool-One } "Two" { pool pool-Two } } ......... <<*****************> in combination with the SSL profiles defined or do we have to perform encryption / decryption/ re-encryption on the iRules level and write extra iRule coding in order to achieve the end-to-end traffic encryption as well as the persistent session requirements. Many thanks in advance. Regards Patrick
- VernonWellsAs long as the Virtual Server has a client-ssl profile and an http profile, the rules above will work. The addition of a server-ssl profile does not change that.
It can. You cannot use the BIG-IP priority group activation method for this, because it has a different meaning than what you describe above, but you can define two pools, one for each "priority group". You would then select the "priority group" based on the header field. You would set the Virtual Server LB method to "Ratio" and define the pool member ratios in each pool. It would look something like this (untested!):
when HTTP_REQUEST { if { [HTTP::header exists "iSession"] && [persist lookup uie [HTTP::header "iSession"]] } { persist uie [HTTP::header "iSession"] } else { switch [HTTP::header "iPGroup"] { "One" { pool pool-One } "Two" { pool pool-Two } } if { [HTTP::header exists "iSession"] } { persist uie [HTTP::header "iSession"] } } }In this configuration, you should also define a default pool for the Virtual Server, which would be used if iPGroup is not set or is not a value in the set ["One", "Two"].
- ppltam_183867Really Thanks Vernon for sharing the technical insight and would like to go a bit further. Traffic from the LTM Virtual Server going to the actual Node members who run web services are actually encrypted running SSL. On the LTM virtual server, we have defined two SSL profiles (One Client SSL and One Server SSL profile) as end-to-end encryption is a mandatory requirement due to confidentiality of the application. Question is can we still use the iRules suggested e.g. <<********************>> when HTTP_REQUEST { if { [HTTP::header exists "iSession"] && [persist lookup uie [HTTP::header "iSession"]] } { persist uie [HTTP::header "iSession"] } else { switch [HTTP::header "iPGroup"] { "One" { pool pool-One } "Two" { pool pool-Two } } ......... <<*****************> in combination with the SSL profiles defined or do we have to perform encryption / decryption/ re-encryption on the iRules level and write extra iRule coding in order to achieve the end-to-end traffic encryption as well as the persistent session requirements. Many thanks in advance. Regards Patrick
- As long as the Virtual Server has a client-ssl profile and an http profile, the rules above will work. The addition of a server-ssl profile does not change that.
