I'm looking for clarification about an article in the documentation for PASOE. This is one of the options that is available for load-balancing.
Amazon Elastic Load Balancer (ELB):
Has anyone had any success with this load balancer in production? I don't have access to the Amazon ELB but we have another load balancer, called Citrix Netscaler, and I think it can serve a similar purpose.
I am particularly interested in that load-balancing strategy. It is described as using a "proprietary cookie" (AWS_ELB). In order for this strategy to work, does PASOE need to be configured in any special way? The documentation does NOT say anything about what needs to happen on the PASOE side of things for the load-balancer to be able to work properly. I'm guessing that the PASOE applications need to be configured to use HTTP sessions provided by tomcat. Is there anything else?
On a conceptual level, do the PASOE instances even know that the AWS ELB is sitting out in front? Or are they totally unaware of that detail?
I'd also like to understand how the load-balancing strategy works. I think it injects its own cookie into the HTTP headers that are sent back and forth to tomcat. It then uses this cookie to determine how to redirect future HTTP traffic from the same client. I suspect that as long as the tomcat session hasn't timed out, then the load balancer will continue to send HTTP traffic to the same tomcat instance. So as long as the PASOE hasn't lost track of the session, then the load balancer should work properly, right?
Please let me know if I have gotten anything wrong. In the case of citrix netscaler, there are a couple "persistence" strategies that the load-balancer uses. The one that we've used thus far is called "client IP persistence". It is straight-forward and easy to configure. All traffic from the same client machine is directed to a single tomcat instance. This is fine if there are lots of independent clients that do small amounts of work. But it is a problem if there is a really *big* client machine that runs batch processes, services, reports, and such. All the activity from that machine will be sent to a single pasoe instance and swamp it. The alternative is another "persistence" strategy based on HTTP cookies. I haven't had any experience with it yet, but I suspect it works in a way that is similar to the Amazon ELB. I'd appreciate any additional details about that type of load balancing before we start blindly experimenting with it.
PS. Here is the info on the "persistence" strategy in citrix netscaler that uses HTTP cookies.
I'd love to hear if anyone has tried load-balancing for PASOE. In particular I'm curious about a strategy that would use cookie insertion, similar to the amazon ELB. It isn't clear to me if this should work, based on my reading. The problem is that there are several transports in PASOE, and different types of clients for the APSV transport (we use .net openclients). I'm not sure what the support matrix would look like, after taking these variables into account.
There are some places in the documentation where it appears we will not be able to use load-balancing (ie. this link seems to say .Net openclients aren't supported for HTTP sessions). I would tend to doubt this; perhaps the docs are outdated.https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/pasoe-admin/overview-of-http-sessions.html
"Note: If you want to use HTTP sessions, the ABL client must be OpenEdge 11.6 or a later release. Open Clients (.NET and JAVA) are not supported."
But there are other places that sound a lot more promising. Here is a place where I'm hoping it says HTTP-based load-balancing will work for APSV (and .Net openclients?) So long as they are using HTTP sessions.https://knowledgebase.progress.com/articles/Article/PASOE-with-load-balancing-getting-error-Communication-layer-message-General-Error-9998-7175
"In 11.6 and later load balancing is supported for all transports, however, if load balancing is needed for the APSV transport then the load balancer must be configured to use sticky sessions."
It would be nice to hear from someone who actually has first-hand experience with this. Otherwise we will be experimenting by trial-and-error and could waste a day or two...