Showing posts with label ELB. Show all posts
Showing posts with label ELB. Show all posts
Monday, August 23, 2021
Thursday, April 8, 2021
DNS Route 53 and ELB - AWS - Routing Policies
https://medium.com/awesome-cloud/aws-amazon-route-53-routing-policies-overview-285cee2d4d3b
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to queries:
Simple routing policy – Use for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website.
Failover routing policy – Use when you want to configure active-passive failover.
Geolocation routing policy – Use when you want to route traffic based on the location of your users.
Geoproximity routing policy – Use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another.
Latency routing policy – Use when you have resources in multiple AWS Regions and you want to route traffic to the region that provides the best latency.
Multivalue answer routing policy – Use when you want Route 53 to respond to DNS queries with up to 8 healthy records selected at random.
Weighted routing policy – Use to route traffic to multiple resources in proportions that you specify.
- ELB is one of many AWS services that have a regional scope and can span across zones in a given region.
- Other services like Route 53 is global in scope, as shown below, and provides services to multiple Regions.
Thursday, April 1, 2021
Elastic Load Balancer , AWS,Healthy Threshold,UnHealthy Threshold, Response Timeout,Health Check Interval,Ping, ELB
7. Application Layer
6. Presentation Layer
5. Session Layer
4. Transport Layer - TCP/UDP
3. Network Layer - Routing Packets based on IP Address
2. Data Link Layer
1. Physical Layer
6. Presentation Layer
5. Session Layer
4. Transport Layer - TCP/UDP
3. Network Layer - Routing Packets based on IP Address
2. Data Link Layer
1. Physical Layer
OSI Reference Model
--------------------------------------------------------------------
- Application Load Balancer - Based on HTTP Header
- Allows You to route requests on the basis of HTTP Request
- N/W Load Balancer - Very Expensive/High Performance - Operates at Transport Layer (Layer 4)
- Classic Load Balancer - Supports Layer7(HTTP(s)/Layer 4 (Legacy)
--------------------------------------------------------------------
Load Balancer Algorithm
- Round-Robin
- Least Loaded Server
"X-Forwarded-For" Header - Tells us about Originating IP
Common LB Error - HTTP 504
LB Could not connect to Target Server/Database
LB Could not connect to Target Server/Database
7. Application Layer|
6. Presentation Layer|
5. Session Layer|
4. Transport Layer - TCP/UDP|
3. Network Layer - Routing Packets based on IP Address|
2. Data Link Layer|
1. Physical Layer|
OSI Reference Model|
https://www.howtogeek.com/367129/what-is-a-504-gateway-timeout-error-and-how-can-i-fix-it/
--------------------------------------------------------------------
Application Load Balancer - Based on HTTP Header|
Allows You to route requests on the basis of HTTP Request |
N/W Load Balancer - Very Expensive/High Performance - Operates at Transport Layer (Layer 4)|
Not at Network layer, At Transport layer
Classic Load Balancer - Supports Layer7(HTTP(s)/Layer 4 (Legacy)|
--------------------------------------------------------------------
Load Balancer Algorithm|
Round-Robin|
Least Loaded Server|
"X-Forwarded-For" Header - Tells us about Originating IP|
Common LB Error - HTTP 504 |
LB Could not connect to Target Server/Database DNS - Elastic Load Balancer - Route 53|
--------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------
ELB is Region Specific - 1 Region = 1 ELB
VPC
ELB is not concerned with "Outbound" Traffic
ELB only concerned with inbound Traffic and can be redirected to registered EC2 Instances
ELB is charged Hourly
If You delete ELB, Then Configure "Route 53" to somewhere else.
Listener listens to incoming Connection Requests
FrontEnd Listener - Virtual
BackEnd Listener - Virtual
FrontEnd Listener - Checks for Traffic from Internet to ELB
Backend Listener - Checks for Traffic from ELB to Instances based on port/protocol
ELB Will direct traffic to primary IP address /eth0
ELB - Works only in IPv4
IPv6 is not supported currently
Subnet
AZ
VPC
ICMP Protocol - "Ping" Application
RDP - MSTSC - 3389 port
HTTP -80
HTTPs - 443
Load Balancer is tied to VPC
Load Balancer -> only directs Traffic Its meant for - Protocol its enabled for
Usually EC2 Don't have Public IP
Internally They Connect via Private IP
Load Balancer has 3 Imp Components
Listener => Target Group (Health Check) => Target
Listener -> Which Protocol it wants to go
Target Grp -> Grp of EC2 Instances
Health Check - Every Target Group has Health Check - Hearbeat , If a Node is down - It updates LB regarding this
Target -> can be -> IP, Lambdas, EC2
Targets are across Availability Zones
Internet Facing Elastic Load Balancer - Public DNS Name
DNS Route 53 -> Elastic Load Balancer[ELB] -> EC2
----------------------------------------------------------------------------------------------------
193.1.4.0/27 = 32-27 = 5
2^5 = 32 Instances
32 - 5 (AWS Resrved) = 27
27 -8 =19 (8 is kept for Load Balancer) -
If increase load on ELB, ELB can allocate IPs to ELB Nodes - 8 Nodes of ELB
192.168.10.0/27 - For Network Address
192.168.10.1/27 - VPC Router
192.168.10.2/27 - VPC DNS Server
192.168.10.3/27 - Unknown /Future Use
192.168.10.31/27 - VPC Netcast
5 Reserved
27 Remaining
ELB - 8 Reserve
Total 19 IP Addresses
Minimum 2 AZ in VPC needs to be connected to ELB -Elastic Load Balancer
LB -> Distributes Load across Availability Zones
Keep Same number of EC2 Instances in all Availability Zones
Load Balancer Keeps track on Health of Instances
Registered Instances has default time period 5 seconds - "Response Timeout"
"Health Check Interval" - 30 Sec - Default (Time between 2 Seconds)
You can set to 5 -300 sec
"UnHealthy Threshold" - Number of Consecutive Failed Health Checks = Default 2
Range 2-10
"Healthy Threshold" - Number of Consecutive Sucessful Health Checks = Default 10
Range 2-10
Healthy/UnHealthy Instances
Load Balancer monitors health of its registered Instance
Cross-zone load balancing
The nodes for your load balancer distribute requests from clients to registered targets. When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones. When cross-zone load balancing is disabled, each load balancer node distributes traffic only across the registered targets in its Availability Zone.
Cross-zone load balancing reduces the need to maintain equivalent numbers of instances in each enabled Availability Zone, and improves your application's ability to handle the loss of one or more instances. However, we still recommend that you maintain approximately equivalent numbers of instances in each enabled Availability Zone for higher fault tolerance.
PING
Ping uses the ICMP protocol to check the network reachability of the device you are checking. This works at a low level and tells you that the device is there and has power to the network interface. Just because something responds to a ping request, it is not a true indication that the service on the device is running but it does help in troubleshooting
HTTP Monitor
The monitor work by looking at the HTTP Response Code for the configured page. If a page exists, the web server will return a status code of 200, which means OK. This is a simple check to ascertain if a page exists on a website.
ELB is region specific - 1 ELB can work with multiple Availability Zones within same region.
ELB can be internal or internet facing
ELB is accessed via DNS Name
ELB
Subscribe to:
Posts (Atom)