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
Related
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 am creating a global HTTPS Load Balancer in Google Cloud and wondering how does location affect a global load balancer.
I am unable to find much detail about it on internet.
There are price differences based on location:
https://cloud.google.com/vpc/network-pricing#lb
but no idea how it affects routing of https requests:
https://storage.googleapis.com/gweb-cloudblog-publish/images/global_lb.max-1800x1800.png
For example: if my website receives most of its traffic from USA, India and Europe then what would be the best location I should choose while setting up global HTTPS Load Balancer and what difference it will make?
The primary difference is that the global load balancing is for Layer-7 (high-level application layer) traffic while regional load balance is for Layer-4 (transport layer) traffic and uses Maglev for traffic routing.
Let's say you want to do your own SSL terminations and operate your own Layer-7 reverse proxies, I believe regional is the correct option. For the vast majority of users I would wager that global is the better choice.
Have a look at the documentation Cloud Load Balancing overview section Global versus regional load balancing:
Use global load balancing when your backends are distributed
across multiple regions, your users need access to the same
applications and content, and you want to provide access by using a
single anycast IP address. Global load balancing can also provide IPv6
termination.
Use regional load balancing when your backends are in one region,
and you only require IPv4 termination.
and at section External HTTP(S) Load Balancing:
HTTP(S) Load Balancing is implemented on GFEs. GFEs are
distributed globally and operate together using Google's global
network and control plane. In Premium Tier, GFEs offer cross-regional
load balancing, directing traffic to the closest healthy backend that
has capacity and terminating HTTP(S) traffic as close as possible to
your users.
more information about Network Service Tiers you can find in this article.
To find more details have a look at the documentation External HTTP(S) Load Balancing overview:
HTTP(S) Load Balancing is a global service when the Premium Network
Service Tier is used.
and
When a user request comes in, the load balancing service determines the approximate origin of the request from the source IP address.
The load balancing service knows the locations of the instances owned by the backend service, their overall capacity, and their
overall current usage.
If the closest instances to the user have available capacity, the request is forwarded to that closest set of instances.
Incoming requests to the given region are distributed evenly across all available backend services and instances in that region. However,
at very small loads, the distribution may appear to be uneven.
If there are no healthy instances with available capacity in a given region, the load balancer instead sends the request to the next
closest region with available capacity.
also
HTTP(S) Load Balancing is a regional service when the Standard Network
Service Tier is used. Its backend instance groups or NEGs must all be
located in the region used by the load balancer's external IP address
and forwarding rule.
Meanwhile, Maglev is a distributed system for Network Load Balancing.
Even after a lot of googling, I could not find a simple answer to this question. All I could find was it's layer 4 load balancer that can handle millions of requests per second, and support for static/elastic ip. Could someone please give me an example where network load balancers are used in real life? A simple use case. When to pick network load balancer over application load balancer?
When compared to an Application Load Balancer a simple explanation goes like this: Network Load Balancer is used anywhere where the application behind the balancer doesn't work over HTTP(S), but uses some other protocol. Including, but not limited to:
Legacy applications that implement custom protocol.
NTP servers.
SMTP server.
Database servers.
MQTT brokers.
High performance queue servers (ActiveMQ, RabbitMQ, ZeroMQ etc.).
Message processing applications (think Kafka and Co.).
I would like to complement #Sergey list with few more scenarios where NLB is useful:
NLB provides static IP address, ALB does not. So use it when you require a static IP for your LB. Similarly, it is the only balancer that can use Elastic IP addresses.
Use NLB when you require end-to-end SSL encryption. ALB will always terminate SSL connection, which may be not desired due to strict security requirements.
NLB is the only balancer type that can be used for API Gateway VpcLink or VPC PrivateLink technologies.
NLB does not have Security Groups.
I have configured and passed the health check for my AWS ELB(load balancer), but I was trying to do a ping or send a packet to the tcp port 9300 there is no ip address for the ELB.
I have an EC2 instance at the end of the ELB which has Elasticsearch running on it.
The ELB that I configured is an internal ELB so it doesn't have a public IP address for it.
I was wondering if there is a way I can ssh? or do something to ping the ELB?
I am pretty new to AWS and read all the trouble shooting from AWS official website, but couldn't find a solution.
The goal that I am trying to achieve is to test whether my internal Amazon EC2 load Balancer is working properly.
I got the internal ELB ip address with the ping command, however, I am not able to ping or crul to that IP address.
I what to know what I am doing wrong.
Is it the way that I want to access a private network is in correct?
An Elastic Load Balancer is presented as a single service, but actually consists of several Load Balancing servers spread across the subnets and Availability Zones you nominate.
When connecting to an Elastic Load Balancer, you should always use the DNS Name of the Elastic Load Balancer. This will then resolve into one of the several servers that are providing the load balancing service.
Load Balancers are designed to pass requests and return responses. The next time a user sends a request, it might be sent to a different back-end service. Thus, it is good for web-type traffic but not suitable for situations requiring a permanent connection, such as SSH. You can configure sticky sessions for HTTP connections that will use cookies to send the user to the same back-end server if required.
The classic Elastic Load Balancer also supports TCP protocol, but these requests are distributed in a round-robin fashion to the back-end servers so they are also not suitable for long-lasting sessions.
Bottom line: They are great for request/response traffic that needs to be distributed across multiple back-end servers. They are not suitable for SSH.
Site-note: Using PING to test services often isn't a good idea. Ping is turned off in Security Groups by default since it can expose services and isn't good from a security perspective. You should test connectivity by connecting via the expected protocols (eg HTTP requests) rather than using Ping. This applies to testing EC2 connectivity, too.
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.