Autoscaling an LSPHP cluster: How to set up External App PHP handler in Web ADC?

#1
Hi LiteSpeed community,

I'm currently exploring ways of getting autoscaling working for a cluster of LSPHP-only worker instances (no LSWS on these), which would handle PHP requests for one or two permanent LiteSpeed front-ends.

My initial idea was to put an ordinary LS Web Server (not ADC) in front of the cluster of LSPHP instances using Litespeed's built-in External App load balancing feature; having it pass PHP requests off to the autoscaled instances which solely run LSPHP as a daemon. The problem with this is that these worker instances have to be registered in the LS load balancer manually which means it's not readily suitable for autoscaling.

So to get around this I've set up an Amazon Network Load Balancer to pass the LSAPI connections off to the ephemeral autoscaled instances. This works, but the problem with this is that from LiteSpeed's perspective, the cluster just appears as a single LSPHP instance, so it's unable to intelligently manage connections as it has no idea how many worker hosts there are back there behind the EC2 load balancer.

So after a bit of reading I found that Litespeed Web ADC has Zeroconf functionality which I believe would allow new instances to register / deregister themselves with an LSAPI Worker Group on scale-out / scale-in events. So I've been trying to set this up instead of using the EC2 LB, but the Virtual Hosts section of the Web ADC control panel is missing a number of features of the vanilla LiteSpeed Web Server: there is nowhere to register External Apps or set up a Script Handler; and there are no PHP options.

I've tried adding a Virtual Host Context which matches *.php to pass requests on to a LSPHP cluster, but the Context feature doesn't seem to have any concept of scripts and so it treats the LSAPI worker group as HTTP servers, and this doesn't work.

So my question is:

How do you get LiteSpeed Web ADC to handle PHP requests properly; passing them off directly to an LSAPI worker group?

If this isn't possible, then what's the proper way to autoscale an LSPHP cluster?

Thanks in advance for your input.
 
#2
Another solution to this problem might be if vanilla LiteSpeed Web Server has a configuration API so that new LSPHP instances can modify the front-end server configs; adding their private IPs to the LS LB pool on start-up, and removing themselves on shutdown. I.e. a poor man's zeroconf. Does LiteSpeed feature a configuration API, or are editing httpd config files & the admin web UI the only options; with no programmatic access? If the latter then I guess I would I have to come up with a way of munging the httpd conf myself. Doable, but kludgey and potentially dangerous if my script does something dumb or 2 workers try to edit at the same time.
 
#3
One crazy thought I had was to just list every possible worker IP address that any new autoscaling instance might be assigned, and just have all 768 IPs permanently listed in the LiteSpeed LB config. So most of the time, 99% of these worker hosts will be marked as "unhealthy" because they do not exist; but when one does pop into existence due to a scale-out event, well: its IP is already in the pool, so it will start being used after the 10 second health check timeout.

This is a bit of a sledgehammer-to-crack-a-nut approach though and I can only imagine it comes with performance costs as LSWS has 765 "unhealthy" workers to ping every 10 seconds. There must be a better solution for autoscaling with LiteSpeed?

*edit: I tried this with a pool of 96 IP addresses and it's not really workable: LiteSpeed LB doesn't seem to keep track of healthy vs unhealthy instances on a graceful restart, so it takes ages going through all IPs to find the 3 or 4 live ones; and it only starts doing this upon a real client request for a page, so those unlucky users will get stuck for ages while LS goes through the motions.
 
Last edited:
Top