Pairing the complex load balancing features of NetScaler with the ease of AWS AutoScaling Groups has been a challenge for us. I’ll attempt to describe our setup in a way that allows others to set up a similar setup if they so wish.
For all traffic from the greater internet into our servers, we have to pass it through NetScaler and Palo Alto. This has posed a bit of a challenge with resolving IPs. Pointing directly to a server is a simple task, simply add the IP of the server to a NetScaler service group.
But what if you want to use AutoScaling? AWS provides great autoscaling features that make it almost trivial to quickly scale up and down. Unfortunately, they are built to work best with AWS ELBs, which is great if that’s all you need.
The dirty solution
The first thing we tried to do is point NetScalers to ELBs. The thinking was we could point the NetScaler to the DNS entry of the ELB, which we would add when the ELB was created. This seemed like it worked, but stress testing revealed a critical flaw with the AutoScaling Group (ASG) spanning multiple Availability Zones. The ELB would switch IPs, and the DNS wouldn’t catch up with the requests. As a result, every so often you’d see a spurt of failures.
Can we find a better solution?
Even before this issue cropped up, red flags were cropping up. The ELB is an extra hop, which is never preferable if it can be avoided. Furthermore, the NetScaler is a load balancer, so we were effectively load balancing a load balancer.
The solution is to add the instances in the ASG to the NetScaler service group as they come up and down.
ASGs offer a feature to add notifications on on instance creation and termination. You simply provide the ASG an SNS topic. We then created a lambda subscribed to the SNS topic to process the events. A python script then adds the server to a service group in the NetScaler.
In my next post, I’ll post some code of how we actually do this, and get into the details.