1

I'm trying to create an autoscaling group for my web server in AWS.

I do the following:

1.- Create a load balancer. This load balancer checks the first instance of the autoscaling group.

Health Check Tab

LOAD BALANCER HEALTH CHECK

Listeners Tab

LISTENERS TAB

2.- Create an autoscaling group with an AMI. The policies are:

  • INCREASE: If Maximum CPU is >= 70% for 1 min it start 1 instance based on the AMI. It waits 60 sec before allowing another scaling activity.
  • DECREASE: If Maximum CPU is <= 25% for 5 min it removes the newest instance. It waits 0 sec before allowing another scaling activity.

In the DETAILS TAB of the autoscaling group I have the folling: - Desired: 1

  • Min: 1

  • Max: 5

  • Health Check Type: EC2

  • Health Check Grace Period: 60

  • Termination Policies: NewestInstance

  • Default Cooldown 60

Those are the configurations.

Apparently it works well. When we charge the instance using JMeter, AWS starts a new instance using INCREASE policy. The problems is, that seems that the new instance isn't being used. Because, when I check the monitoring graphs of AWS, the CPU stays at 0 all time. So I think that the new instances that AWS launch aren't being used. I think this is because I have a bad configuration of the load balancer, but I really don't know. What can I do?

6
  • Is your loadbalancer connected to the autoscaling group so that Auto Scaling registers your instances with the load balancer when it launches them.
    – HBruijn
    Aug 5 '16 at 7:01
  • Yes it is. I forget to mention. In the autoscaling group, details tab: Launch Configuration: MyFirstLC Load Balancers: MyFirstLB I just check that the load balancer monitor the correct instance.
    – user333214
    Aug 5 '16 at 7:08
  • I have this other picture, but I can't attach it to the body because of my points. DETAILS TAB AUTOSCALING
    – user333214
    Aug 5 '16 at 7:18
  • If the instance is started you should see it in the ELB as an instance. So after the scaling check in there if the instance is connected to the ELB to actually pinpoint the problem (it could be a wrong health check or it isn't connected at all). Your screenshot shows an HTTPS health check but the listener tab shows an HTTP instance protocol - that's weird (you should always check on the protocol you're actually using and not a different one)
    – Osterjour
    Aug 5 '16 at 14:37
  • Thanks to all. I'll fix some things that you tell me. Working on some test. I'll let you know the results.
    – user333214
    Aug 8 '16 at 11:37
1

Many people miss this.

When load testing Elastic Load Balancers with multiple EC2 instances behind the ELB, you need to run your tests from multiple client locations. Each needs to be originating from a unique IP address.

The reason for this is based in how ELB handles DNS requests. Depending on the number of AZs used, the number of back-end EC2 instances you have, etc. ELB may keep sending requests that originate from the same remote IP address to the same back-end EC2 instance.

Some Notes:

This is different from "sticky sessions", which uses cookies to send the same browser session to the same back-end EC2 instance.

If you are using multiple clients to do your load testing, make sure your PCs are not behind the same NAT or firewall. Since all the connections are going through the NAT/firewall, the ELB will see all of the connections as originating from the same IP address (the NAT/firewall's IP address). So this is not good enough.

Use a tool like http://whatismyipaddress.com to see what your "outside" IP address is.

References:

So a single load test client would only ever hit one ELB instance

Update:

One more reference:

6
  • Do you have any documentation that supports this? AWS say ELB "uses the round robin routing algorithm for TCP listeners, and the least outstanding requests routing algorithm (favors the instances with the fewest outstanding requests) for HTTP and HTTPS listeners". docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/…
    – Tim
    Aug 11 '16 at 0:55
  • I've updated my answer with some references. Aug 11 '16 at 1:19
  • 2012/2013 resources may not be valid as things change quickly. For example one says "ELB doesn't give you logs", which they now do. The only documentation from Amazon that suggests it pins an IP to an ELB is the best practices link, and then only if your ELB has multiple IPs and your test client only does DNS lookup ones and hence stays on on IP/ELB. Personal experience and AWS support is valuable, but subjective. Note, I'm not saying you're incorrect, I'm just noting that documentation doesn't seem to support it.
    – Tim
    Aug 11 '16 at 2:46
  • One more recent article added. Aug 11 '16 at 16:51
  • Interesting. None of them are quite conclusive or exhaustive, but there's plenty of evidence that it happens. I'm studying for AWS Sysop right now, I might spin up some instances behind a load balancer, run JMeter, and document my findings well.
    – Tim
    Aug 11 '16 at 20:13
-1

2 Things to do here.

1) If you have attached a load balancer to your Auto Scaling group, you can optionally have Auto Scaling include the results of Elastic Load Balancing health checks when determining the health status of an instance. After you add these health checks, Auto Scaling also marks an instance as unhealthy if Elastic Load Balancing reports the instance state as OutOfService. It is recommended to set your HC to ELB rather EC2. Thats not the case as per the attached Screenshot.

2) Check the ELB --> Instances tab once you increase the traffic and see another instance spun up to verify if this is actually registered with the ELB you are referring too.

Cheers!

4
  • 1
    Thanks for help. I have do the following things: 1.- Change Health Check Type to ELB 2.- Change listener to HTTPS:443 I'll do some test and let you now.
    – user333214
    Aug 8 '16 at 11:34
  • 1
    After some test I could say that it works. The new instance get charged. I think that the problem was using EC2 Health Check instead ELB. Thanks all for help.
    – user333214
    Aug 9 '16 at 6:18
  • Setting your Auto Scaling group to use ELB health check simply tells the AS group to terminate OutOfService instances. It won't affect the traffic flow. Having an ELB with AS group using EC2 health check is a 100% valid configuration (Elastic Beanstalk does it). Aug 11 '16 at 17:37
  • You may want to read the comment again "you can optionally have Auto Scaling include the results of Elastic Load Balancing health checks when determining the health status of an instance." And check what does optional means. its recommended not mandatory.
    – C Singh
    Sep 22 '16 at 11:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy