For a few days we noticed that at least two (and sometimes more) instances idle far below the average CPU utilisation across the other EC2 instances in the Autoscaling Group.
I'd really like to be able to understand why some instances consistently idle much lower than the rest and if there are additional tools, techniques or investigation I can do to understand this better.
I have queried CloudWatch but don't seem to get an understanding or the information I require to further understand the issue at hand.
CloudWatch Metrics
Looking at the load balancer requests in SumoLogic, it seems as if the load balancer is equally distributing traffic amongst all instances that are currently in service.
SumoLogic Graph
Related
So basically I have this EC2 Linux Instance with 8GB memory and I am having multiple applications running on it. It doesn't happen often, but when there is huge traffic, 8GB memory isn't enough, and the whole instance stops responding. To make things work like normal, I have to reboot the instance every time.
I have heard that Elastic Load Balancing might scale the memory as required. But how to achieve that? Is there any other way to solve my problem? Is there a tutorial that'd guide me through this?
I have heard that Elastic Load Balancing might scale the memory
ELB does not scale a memory of your instance. Instead it can distribute your connections among multiple instances. Thus, instead of having one instance which servers all your traffic, you would have two or more. In this setup, ELB would distribute traffic equally among your instances, so that collectively they can server more connections then a single instance.
What's more you usually use ELB with autoscaling so that the number of instances is adjusted automatically up and down, depending on the incoming traffic.
Is there a tutorial that'd guide me through this?
You can start with offical AWS tutorial Set up a scaled and load-balanced application .
Currently I have hosted 150+ sites in one AWS EC2 instance. And continuously I am adding more websites, approximate 10 to 15 websites per month. So I need suggestion for this. One EC2 instance is good or I need to divide it in multiple EC2 instances. And another thing EC2 auto scaling is good for this or not ?. I can't use beanstalk due to the limitation.
Depends on what you mean by 'good'.
Good for your wallet is to host them all on a single ec2 instance, in a single region and hope that singe instance (or AZ) doesn't go down or have problems.
Good for uptime would be to host all of the websites together on multiple ec2 instances, across multiple AZ's and use a load balancer to distribute traffic across several identical instances.
Better for uptime and performance would be multiple larger ec2 instances in multiple AZ's behind a load balancer
Best for uptime, performance and your wallet would mean multiple smaller ec2 instances, behind a load balancer and with autoscaling enabled to bring up (and turn off) instances depending on traffic load.
Besides the above, you can also offload some of your static assets (css, js, images etc) to an s3 bucket which should save some $$ and reduce the load on your web servers (thus needing smaller or less of them) and then put cloudfront in front of everything to cache assets/pages closer to your end users.
So lots of options, but what you are doing now is perhaps a bit risky.
If you are looking on a perspective of cost saving I would suggest to go with docker and ECS. Since you are adding multiple websites there's a chance some of the websites will have more or less load. Use ECS tasks along with application load balancer and autoscaling group. You'll have reliability and separation between applications.
The title might be a little too much, but i am unable to find any statements regarding this. I am trying to set up computes in multiple AZ's (in a region) with auto-scaling. i am also trying to see if i can get away with only one ELB to do the load balancing act.
In this setup, the ELB is a single point of failure so, I would like to know, if anyone knows the recovery associated with ELB's. There are documentations about scaling in ELB but not the recovery/higher availability.
thanks
Make sure you select multiple AZs for the load balancer as well. You will have to in order for it to work with EC2 instances in multiple AZs anyway. When you do that, multiple ELB instances are created for you behind the scenes, one in each AZ. So the ELB isn't really a "single point of failure".
The most common issue you may see with an ELB is if you have a very quick, large burst of traffic, which will take the ELB a few minutes to scale up to meet the demand. If you know ahead of time you will be getting a large increase in traffic you can send a request to AWS support to pre-warm the ELB for you.
I recommend reading the section titled "Common Pitfalls When Testing Elastic Load Balancing" in this article.
An ELB is a logical entity that consists of multiple (at least 2 - one per AZ - and generally more) instances that route traffic to your back ends.
If an individual ELB instance were to fail, it would be replaced automatically, much in the way autoscaling replaces failed instances.
You can usually tell how many instances are in your ELB by doing a DNS lookup - you will see multiple IP addresses returned.
ELBs can become overloaded if you have a sudden burst of traffic, so they are not failure proof, but for most loads they do a very good job.
Please tell me what are the risk mitigation features to consider when choosing a cloud service provider for an organization? Reliability seems to be an issue considering Nirvanix's shut down and Amazon's outage in August 2013. Thank You.
-Nandhini
Quite the open-ended question, I'm sure just about everyone could spend weeks about risk mitigation. There are many procedures put in place and using Amazon as a provider I'll go through a few.
Amazon has a plethora of tools for disaster recovery, redundancy and general good practise for the Cloud Environment but it is totally up to you if you choose to use them. Let's take Availability Zones as an example.
In each AWS Region (a location where their datacentres are held) they have what they call Availability Zones which are completely separated datacentres in order to improve redundancy. An entire AZ could go offline and not affect the other AZ. A well executed Cloud migration strategy would utilise several of the following:
Spread of all necessary VMs, appliances, databases etc. spread evenly over a single or multiple geographic region
Utilising auto-scaling groups to allow rapid increase of Infrastructure of a single AZ in case of massive outage in another AZ (also good for flash traffic or periods of high server loads)
Utilising Route 53 DNS records to automatically re-route traffic through to nearby Elastic Load Balancers, thus causing your site to have near-zero downtime through an AZ failure as traffic switches over to a new Region or AZ in milliseconds (done at the Amazon level so no waiting for TTL DNS changes)
Elastic Load Balancers in general to near automatically place newly spun VMs straight into serving traffic
Managed Relational Database Service can place a warm back-up in another AZ in a single Region, instantly spin up multiple Read Replicas and second level Read Replicas
I could go on for days but for a service like AWS with a properly implemented Cloud Strategy they offer a plethora of services and techniques (their white papers at http://aws.amazon.com/whitepapers/ allow you to get your feet wet in Security and Deployment)
I am running couple of instances under my aws elastic load balancer. Say I have 6 large ubuntu instances running under the elb. The problem what I am facing right now is load is not evenly distributed across the availability zones. I am running 3 large instances on ap-southeast-1a and 3 in ap-southeast-1b. But elb is distributing more load on the 1b and the instances stop responding since it hits 100% CPU and elb automatically throws the instances out of it's control which causes the downtime. DNS is parked in Godaddy.com.
How do I make sure that elb distributes equally to the available regions.
Kindly help me!!!
There could be a number of reasons for this. Its without doing more digging, its hard to know which one you are experiencing.
Sticky sessions can result in instances traffic becoming unbalanced. Although this depends heavily on usage patterns and your application.
Cached DNS resolution. Part of how the ELB works is to direct traffic round robin on a DNS level. If a large number of users are all using the same DNS system provided by an ISP, they might all get sent to the same zone. Couple this with sticky sessions and you will end up with a bunch of traffic that will never switch. Using Route 53 with ALIAS records may reduce this somewhat.
If you can't get the ELB to balance your traffic better, you can set up something similar with vanish cache or other software load balancer. Not as convenient, but you will ultimately have more control.