I am working on AWS. I have a doubt regarding how many applications a load balancer can support.
Like if I have an application whose traffic is routed and managed by one load balancer, then can I use that LB for another application also???
Also if I can use that ELB for another applications also than how ELB will get to know that which traffic should be routed to Application A server and which to Application B server??
Thanks
I think you may be misunderstanding the role of the load balancer. The whole point of a load balancer is that any of the servers behind it can provide any of the services. By setting it up this way you ensure that the failure of any one server will not affect availability of the service.
You can load balance any TCP service such as HTTP just by adding it as a "listener" for the ELB. The ELB can therefore support as many applications as you want to forward to the servers behind it.
If you set up an image of a server that provides all the services you need, you can even have the ELB auto scale the number of servers up and down by launching or terminating instances from that image as the load varies.
Related
I have a server (apache/php) running the front end of saas platform.
This will not receive high traffic and therefore does not need load balancing.
Does it make sense to add load balancer and auto scaling group (with count of 1 server) for security reasons?
It allows the server to be isolated in the VPC + it allow services such as WAF that increase security. The extra cost is not a problem.
It does make sense in the following ways,
It can help you in configuring health checks for your instance. If
you instance fails for some reasons, the load balancer will
instantiate another EC2 instance for you hence minimizing the
downtime of your application
Naturally makes your instance more secure by hiding it in a VPC (as you suggested)
Lastly, it will future-proof your architecture and will enable you
to quickly scale up your infrastructure if need be
As you said you have a single server and do not get much traffic add a load balancer to your server.
You can enable health checks so that by integrating it with SNS you will get notified if a health check fails( server unhealthy)
By adding WAF to your application load balancer you can monitor HTTP/S requests and control access to web applications.
It depends upon your requirement like with WAF you can
Block or allow traffic to your application from a specific region
Block or allow traffic to your application from a specified IP range
You can mention the specific number of requests to your application within 5 minutes if it exceeds you can block or count.
I have two VM's (in AWS cloud) connected to single DB. Each VM is having same application running. I want to load balance those two VM's and route based on the traffic. (Like if traffic is more on one VM instance then it should switch to another VM).
Currently I am accessing 2 different instances with 2 different IP addresses with HTTP. Now I want to access those 2 VM's with HTTPS and route the instances with same DNS like (https://dns name/service1/),
(https://dns name/service2/)
How can I do load balancing using nginx ingress.
I am new to AWS cloud. Can someone help me or guide me or suggest me some appropriate related references in getting the solution to it.
AWS offers an Elastic Load Balancing service.
From What is Elastic Load Balancing? - Elastic Load Balancing:
Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets, and routes traffic only to the healthy targets. Elastic Load Balancing scales your load balancer as your incoming traffic changes over time. It can automatically scale to the vast majority of workloads.
You can use this ELB service instead of running another Amazon EC2 instance with nginx. (Charges apply.)
Alternatively, you could configure your domain name on Amazon Route 53 to use Weighted routing:
Weighted routing lets you associate multiple resources with a single domain name (example.com) or subdomain name (acme.example.com) and choose how much traffic is routed to each resource. This can be useful for a variety of purposes, including load balancing and testing new versions of software.
This would distribute the traffic when resolving the DNS Name rather than using a Load Balancer. It's not quite the same because DNS information is cached, so the same client would continue to be redirected to the same server until the cache is cleared. However, it is practically free to use.
I managed to set up autoscaling based on an external load balancer, but I didn't find a way to do the same for an internal load balancer.
Is this feature supported, how to go about auto-scaling my instance group based on the internal load balancer?
The issue is, when you configure an instance group to scale by HTTP requests, you need an HTTP load balancer, which is internet facing, So, the UDP load balancer, which can be internal doesn't work for that.
The Internal Load Balancer uses a backend service which can use a managed instance group. You can assign a managed instance group to the backend or target pools of both internal and network load balancers.
Keep in mind that the Network Load Balancer uses target pools instead of backend services, but target pools can use managed instance groups as well.
Take a look at the documentation for more details. Alternatively I found this and this posts that I believe can be useful to you.
From your last comment:
I'm not able to setup a TCP load balancer which has a backend service, I only get a REGIONAL backend service, which doesn't support http load balancing..
As stated in the Internal Load Balancing Concepts, "internal client requests stay internal to your VPC network and region", so there is neither need of HTTP here, nor a multi-regional setup.
On the same page, under section "About Internal Load Balancing", the schema shows a classic load balancing architecture, featuring one global (http) and multiple internal (tcp/udp) load balancers for each region.
Further on, under "Deploying Internal Load Balancing with clients across VPN or Interconnect", the following is stated in an "Important" note:
Internal Load Balancing is a regional product. [...] An internal load balancer cannot forward or receive traffic to and from VM instances in other regions.
Basically, if your managed instance group has instances across multiple regions, then you need an external load balancer, but if all your instances are within the same region (instances can be split across zones within this same region, e.g. us-west1-a/b/c), then you can rely on an internal load balancer.
I've got an ECS cluster where I have a couple of services running. All of them have their own load balancer so for every service I have a URL like http://my-service-1234554321.eu-west-1.elb.amazonaws.com. But I would like to open only one service of all these (f.ex. 10) services for the whole world while all the others I would like to be hidden and have access to them only from services in this cluster via HTTP. Is it possible and how can I do that?
Elastic Load Balancers can be either be internet facing (open to traffic from the Internet) or internal facing (accepting traffic from within a VPC).
When you create the load balancer for your service, specify the scheme as internal for the services you only wish to access from within the cluster. For the service that needs to be external, set it as internet facing.
The ECS documentation talks about setting the Load Balancer scheme here.
Just remember that a load balancer cannot be both internet facing and internal at the same time. If you decide that you want to expose services that were internal over the Internet at a later date, you will probably need to create a second internet facing ELB for that.
I am trying to understand in which scenario I should pick a service registry over a load balancer.
From my understanding both solutions are covering the same functionality.
For instance if we consider consul.io as a feature list we have:
Service Discovery
Health Checking
Key/Value Store
Multi Datacenter
Where a load balancer like Amazon ELB for instance has:
configurable to accept traffic only from your load balancer
accept traffic using the following protocols: HTTP, HTTPS (secure HTTP), TCP, and SSL (secure TCP)
distribute requests to EC2 instances in multiple Availability Zones
The number of connections scales with the number of concurrent requests that the load balancer receives
configure the health checks that Elastic Load Balancing uses to monitor the health of the EC2 instances registered with the load balancer so that it can send requests only to the healthy instances
You can use end-to-end traffic encryption on those networks that use secure (HTTPS/SSL) connections
[EC2-VPC] You can create an Internet-facing load balancer, which takes requests from clients over the Internet and routes them to your EC2 instances, or an internal-facing load balancer, which takes requests from clients in your VPC and routes them to EC2 instances in your private subnets. Load balancers in EC2-Classic are always Internet-facing.
[EC2-Classic] Load balancers for EC2-Classic support both IPv4 and IPv6 addresses. Load balancers for a VPC do not support IPv6 addresses.
You can monitor your load balancer using CloudWatch metrics, access logs, and AWS CloudTrail.
You can associate your Internet-facing load balancer with your domain name.
etc.
So in this scenario I am failing to understand why I would pick something like consul.io or netflix eureka over Amazon ELB for service discovery.
I have a hunch that this might be due to implementing client side service discovery vs server side service discovery, but I am not quite sure.
You should think about it as client side load balancing versus dedicated load balancing.
Client side load balancers include Baker Street (http://bakerstreet.io); SmartStack (http://nerds.airbnb.com/smartstack-service-discovery-cloud/); or Consul HA Proxy (https://hashicorp.com/blog/haproxy-with-consul.html).
Client side LBs use a service discovery component (Baker Street uses a stateless pub/sub service discovery mechanism; SmartStack uses ZooKeeper; Consul HA Proxy uses Consul) as part of their implementation, but they provide the health checking / end-to-end functionality you're probably looking for.
AWS ELB and Eureka differ at many points:
Edge Services vs Mid-tier Services
AWS ELB is a load balancing solution for edge services exposed to end-user web traffic. Eureka fills the need for mid-tier load balancing.
Mid-tier server refers to an application server that sits between the user's machine and the database server where the processing takes place in. The middle tier server performs the business logic.
While you can theoretically put your mid-tier services behind the AWS ELB, in EC2
Classic you expose them to the outside world and thereby losing all the usefulness of the AWS security groups.
Dedicated vs Client side Load Balancing
AWS ELB is also a traditional proxy-based load balancing solution whereas with Eureka it is different in that the load balancing happens at the instance/server/host level in a round robin fashion. The client instances know all the information about which servers they need to talk to.
If you are looking for a sticky user session (all requests from a user during the session are sent to the same instance) based load balancing which AWS now offers, Eureka does not offer a solution out of the box.
Load Balancer Outages
Another important aspect that differentiates proxy-based load balancing from load balancing using Eureka is that your application can be resilient to the outages of the load balancers since the information regarding the available servers is cached on the Eureka client.
This does require a small amount of memory but buys better resiliency. The Eureka client gets all the registry information at once and in subsequent requests to the Eureka server, it only receives the delta i.e the changes in the registry information rather than the whole registry information. Also, Eureka servers can operate in cluster mode where each peer is not affected by the performance of other peers.
Scale and convenience
Also, imagine, 1000s of microservices running and each having multiple instances. You will require 1000 ELBs, one for each of the microservice, or something like HAProxy that sits behind the ELB to make layer 7 decisions based on the hostname, etc. and then forward the traffic to a subset of instances. While with Eureka, you only play with the application name which is far less complicated.
Service Discovery component usually has a notification component. It is not a load balancer eventhough some might have the capability to do so. It can notify registered clients about changes, for example a loadbalancer going down.
A client can query a service discovery/registry to get a load balancer that is running. Whereas a load balancer does not noitfy a client when it is down.
You should also read about EUREKA
Amazon ELB provides the EC2 instances to your service requests based on Load balancer and the IP addresses of the EC2 instances are not consistent so you can also use EUREKA which does the same job but is based on service registry and client side load balancing in which the Application client for each region has the registry.
You can read more about it here :
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance