Elastic Load Balancing Deep Dive and Best Practices - Pop-up Loft Tel Aviv
•Télécharger en tant que PPTX, PDF•
11 j'aime•8,069 vues
The document provides an overview of Elastic Load Balancing (ELB) on AWS. It discusses how ELB automatically distributes traffic across EC2 instances, provides high availability and fault tolerance. It covers key ELB concepts like public/private load balancing, health checks, cross-zone load balancing and integration with other AWS services like CloudWatch, Route 53, ACM and VPC. The document also provides best practices for ELB configuration and monitoring to ensure high performance and reliability of applications.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Elastic Load Balancing Deep Dive and Best Practices - Pop-up Loft Tel Aviv
Similaire à Elastic Load Balancing Deep Dive and Best Practices - Pop-up Loft Tel Aviv (20)
Plus de Amazon Web Services
Plus de Amazon Web Services (20)
Dernier
Dernier (20)
Elastic Load Balancing Deep Dive and Best Practices - Pop-up Loft Tel Aviv
- 1. Elastic Load Balancing Deep Dive & Best Practices Iftach Ragoler Senior Manager Elastic Load Balancing AWS Loft – Tel Aviv March 2016
- 2. Hardware Load Balancers • Plan for peak time • High Cost • High Maintenance
- 3. Software Load Balancers • Manual Scaling • High Maintenance • Lack of fault tolerant
- 4. Elastic Load Balancing automatically distributes incoming application traffic across multiple Amazon EC2 instances.
- 5. SecureElastic Integrated Cost Effective
- 6. EC2 Instance
- 7. Load Balancer used to route incoming requests to multiple EC2 instances. ELB EC2 Instance EC2 Instance EC2 Instance
- 8. Load balance over classic EC2 instances. Support for public IP addresses only. No control over the load balancer security group. Load balance over EC2 instances within a VPC. Support for both public and private IP addresses. Full control over the load balancer security group. Tightly integrated into the associated VPC and subnets. EC2-Classic EC2-VPC
- 9. Architecture Customer VPC EC2 Instance EC2 Instance us-west-1aus-west-1b Amazon Route 53 ELB VPC ELB ELB
- 10. HTTP/HTTPSTCP/SSL Incoming client connection bound to server connection No header modification Proxy Protocol prepends source and destination IP and ports to request Round robin algorithm used for request routing Connection terminated at the load balancer and pooled to the server Headers may be modified X-Forwarded-For header contains client IP address Least outstanding requests algorithm used for request routing Sticky session support available
- 11. Health checks allow for traffic to be shifted away from failed instances
- 12. ELB EC2 Instance EC2 Instance EC2 Instance Health checks ensure that request traffic is shifted away from a failed instance. Health Checks
- 13. Support for TCP and HTTP health checks. Customize the frequency and failure thresholds. Must return a 2xx response. Consider the depth and accuracy of your health checks. Health Checks
- 14. Idle timeouts allow for connections to be closed by the load balancer when no longer in use.
- 15. Length of time that an idle connection should be kept open. For both client and back-end connections. Defaults to 60 seconds but can be set between 1 and 3,600 seconds. Timeouts should decrease as you go up the stack. Idle Timeouts
- 16. 15s 3s 3s ELB 15s EC2 Instances Amazon S3 Amazon RDS Amazon SWF 3s 9s Idle Timeouts
- 18. Multiple Availability Zones ELB VPC Customer VPC EC2 InstanceELB ELB EC2 Instance us-west-1aus-west-1b Amazon Route 53
- 19. Multiple Availability Zones ELB VPC Customer VPC EC2 InstanceELB ELB us-west-1aus-west-1b Amazon Route 53
- 20. Always associate two or more subnets in different zones with the load balancer
- 21. Using multiple Availability Zones does bring a few challenges.
- 23. Imbalanced Instance Capacity ELB VPC Customer VPC EC2 InstanceELB ELB us-west-1aus-west-1b Amazon Route 53 EC2 Instances
- 24. Cross-Zone Load Balancing ELB VPC Customer VPC EC2 InstanceELB ELB us-west-1aus-west-1b Amazon Route 53 EC2 Instances
- 26. Load balancer absorbs impact of DNS caching. Eliminates imbalances in back-end instance utilization. Requests distributed evenly across multiple Availability Zones. Check connection limits before enabling. No additional bandwidth charge for cross-zone traffic. Cross-Zone Load Balancing
- 27. Each load balancer domain may contains multiple records. Round robin used to balance traffic between Availability Zones. DNS records will to change over time; never target IP addresses directly. After being removed from DNS, IP addresses are drained and quarantined for up to 7 days. Understanding DNS
- 28. DNS caching by clients and ISPs can often cause clients to target a specific IP address or stop resolving at all. Register a wildcard CNAME or ALIAS within Amazon Route 53. // Create a wildcard CNAME or ALIAS in Route 53. *.example.com ALIAS … elb-12345.us-east-1.elb.amazon.com *.example.com CNAME elb-12345.us-east-1.elb.amazon.com // prepend random content for each lookup made by the application. PROMPT> dig +short 25a8ade5-6557-4a54-a60e-8f51f3b195d1.example.com 192.0.2.1 192.0.2.2 DNS Optimization
- 29. SSL Offloading Support for both SSL and HTTPs is provided. Support for latest ciphers and protocols including Elliptical Curve Ciphers and Perfect Forward Secrecy. Ability to fully customize ciphers and protocols to be used by each load balancer. SSL Negotiation Suites provided to remove complexity of selecting ciphers and protocols.
- 30. SSL Negotiation Policies Provide selection of ciphers and protocols that adhere to the latest industry best practices. Balance security best practices with client’s ability to negotiate a connection, generated using traffic to Amazon.com. Released on a regular cadence or when new vulnerabilities are published. Default for all new load balancers.
- 31. AWS Certificate Monitor Integration with ELB • aws acm request-certificate --domain-name demo2.example.us --idempotency-token demo2 --endpoint-url --region ap- southeast-2 • Verify certificate via link attached to email • aws elb create-load-balancer-listeners --load-balancer-name Demo2 --listeners Protocol=HTTPS,LoadBalancerPort=443,InstanceProtocol=HTTP,InstancePort=80,SSLCertificateId= arn:aws:acm:ap- southeast-2:015209794502:certificate/6beab518-24b4-4893-9b81-85af49c9f977 --region ap-southeast-2 • aws acm describe-certificate --certificate-arn arn:aws:acm:ap-southeast-2:015209794502:certificate/6beab518-24b4- 4893-9b81-85af49c9f977 --region ap-southeast-2 • aws elb set-load-balancer-listener-ssl-certificate --load-balancer-name <your elb name, e.g. ELB2> --load-balancer- port 443 --ssl-certificate-id arn:aws:acm:us-east-1:<your ACM cert ARN> Provision, manage, and deploy SSL/TLS certificates to ELB with ACM Makes it very simply to manage certificates when offloading SSL to ELB
- 32. POODLE Mitigation Within 24 hours, 62% of load balancers migrated to the latest SSL Negotiation Policy, disabling SSLv3.
- 33. @awscloud Thank-you #AWS for making it so easy to prevent #sslv3 #poodleattack Only took about 3 clicks of my mouse.“ ”@granticini
- 34. 13 CloudWatch metrics provided for each load balancer. Provide detailed insight into the health of the load balancer and application stack. CloudWatch alarms can be configured to notify or take action should any metric go outside of the acceptable range. All metrics provided at the 1-minute granularity. Amazon CloudWatch Metrics
- 35. HealthyHostCount The count of the number of healthy instances in each Availability Zone. Most common cause of unhealthy hosts are health check exceeding the allocated timeout. Test by making repeated requests to the back- end instance from another EC2 instance. View at the zonal dimension.
- 36. Latency Measures the time elapsed in seconds after the request leaves the load balancer until the response is received. Test by sending requests to the back-end instance from another instance. Using min, average and max CloudWatch stats provide upper and lower bounds for latency. Debug individual requests using Access Logs.
- 37. SurgeQueue and Spillovers Count of the number of requests that could not be sent to back-end instances. Queue up to 1024 requests per load balancer node, after which 503 errors will be returned. Often caused by not being able to open connections to the back-end instance. Normally a sign of an under-scaled application.
- 38. CloudWatch and AutoScaling All load balancer metrics can be used for AutoScaling. Allow you to scale dynamically based on the load balancers view of the application. Important to consider all metrics when using AutoScaling, may not be aware of resource contention on another metric. You may be at peak multiple times a day.
- 39. Provide detailed information on each request processed by the load balancer. Includes request time, client IP address, latencies, request path, server responses, negotiated cipher. Delivered to your Amazon S3 bucket every 5 or 60 minutes. Access Logs
- 40. Access Logs ELB VPC ELB ELB ELB Amazon S3 Logs indexed by date but include the IP address of the load balancer node itself.
- 41. • timestamp • elb name • client:port • backend:port • request_processing_time • backend_processing_time • response_processing_time • elb_status_code • backend_state_code • received_bytes • sent_bytes • “request” • negotiated cipher and protocol 2014-02-15T23:39:43.945958Z my-test-loadbalancer 192.168.131.39:2817 10.0.0.0.1 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/HTTP/1.1" Access Logs
- 42. “Everything fails all the time” Werner Vogels, CTO, Amazon.com
- 43. Be prepared to do nothing!
- 45. Mitigation All load balancers scaled to handle loss of single Availability Zone. Amazon Route 53 health checks shift traffic away from the failed Availability Zone. Completed within max of 150 seconds. No other external or control plane dependencies.
- 46. Isolation Other zones must remain unaffected. Avoid dependencies between zones. Be careful of work generated as a result of the event. Operating at reduced capacity but stable.
- 47. Health checkers and edge locations perform the same volume of activity whether endpoints are healthy or unhealthy. Constant Work time System activity Time to react When nothing is failing, volume of API calls is zero. When failure occurs, volume of API calls spikes. time System activity Time to react Work on Failure
- 48. Restore Redundancy Restoring the system back to full capacity. Avoid putting additional load on the system by rushing this step. Ensure that recovered resources are left in a consistent state. Full recovered when done.
- 49. Classic Link: Migration from Classic to VPC Network • VPC has better isolation, management and functionality • Classic link enables you to register classic instances behind VPC ELB • Help with slow migration of complex stacks
- 50. Thank you!
Notes de l'éditeur
- Elastic: scales dynamically as request load increases Secure: support for end-to-end traffic encryption using latest protocols and ciphers Integrated: Amazon EC2, Auto Scaling, CloudWatch and Route 53. Cost Effective: only pay for what you use - ~$18.50 per month.
- We’ve all started here, a single instance serving a basic application. It does not take much to realize that this is not an architecture you’d want to take into production. From an availability point of view, you don’t have much hope. From a scalability point of view, you’re down to what a single EC2 instance can support with no plan to add capacity if required.
- Elastic Load Balancing allows you to route application request traffic over 1 to many EC2 instances and ensures that any failed instances does not impact your customers by removing them from service.
- Today, in most AWS regions we offer two types of load balancers, namely EC2 classic and VPC. Since all new accounts have been VPC only since early 2013, I’ll be focusing the majority of this talk on load balancers within a VPC. It is important however, to note some of the key differences between EC2 classic and VPC load balancers.
- EC2-VPC Architecture for the load balancer. Customers instances in their VPC, spread across two subnets (shown in blue). Load Balancer nodes in a separate VPC, owned by the ELB account. Customer associates subnet with ELB when it is created. ELB takes 2 ENIs from the customers account and attaches them to each load balancer node (requires that you have 8 free ENIs in your subnet. Amazon Route 53 used for DNS and used round robin to direct traffic to each of the load balancer nodes.
- Connections: TCP: each connection is bound to the connection on the back-end; HTTP: a connection pool is used to the back-end instance. Headers: TCP: the headers are left unchanged and forwarded to the back-end instance HTTP: headers may be inserted depending on the features that are enabled on the load balancer. Source IP: Since ELB proxies all incoming connection, the back-end instance will see the connection coming from the ELB nodes themselves. TCP: proxy protocol can be used to retrieve the source IP address and port. HTTP: X-Forwarded-For appended to header contains the source IP address. Algorithms: TCP: round robin is used. HTTP: least outstanding requests, which is a request-based form of the leastconns algorithm is used. Sticky Sessions: although we always recommend architectures that utilize caching off instance, such as ElastiCache, we do support cookie-based sticky sessions for HTTP listeners.
- Connections: for TCP, each connection is bound to the connection on the back-end; for HTTP, a connection pool is used to the back-end instance and a request will be sent on an existing connection, if one exists. Headers: for TCP, the headers are left unchanged and forwarded to the back-end instance as is; for HTTP, headers may be inserted depending on the features that are enabled on the load balancer. Source IP: Since ELB proxies all incoming connection, the back-end instance will see the connection coming from the ELB nodes themselves. For TCP, proxy protocol can be used to retrieve the source IP address and port. For HTTP, the source IP address is appended to the header in the X-Forwarded-For header. Algorithms: For TCP, round robin is used. For HTTP, least outstanding requests, which is a request-based form of the leastconns algorithm is used. Sticky Sessions: although we always recommend architectures that utilize caching off instance, such as ElastiCache, we do support cookie-based sticky sessions for HTTP listeners.
- Elastic Load Balancing allows you to route application request traffic over 1 to many EC2 instances and ensures that any failed instances does not impact your customers by removing them from service.
- Timeouts should decrease as you go down the stack.
- Idle timeouts should get shorter as you progress deeper into the stack. The basic principle here is that you should avoid doing work when the client has disconnected. Understanding your client timeouts is therefore critically important. We experienced this first hand during a high several event within the EC2 APIs, where a single request was present in the system for 70 minutes. Since requests only logged their full details on completion, we were unable to find the request that was causing load problems within the control plane. 70 minutes later, this request showed up in our log files. It taught us a very valuable lesson, treat high latencies as error and avoid doing additional work.
- As always, we strongly recommend that you always use multiple Availability Zones.
- [Provide a detailed description of the ELB architecture] [Need to say something about the number of ENIs that are required when creating a new load balancer; we have recently dropped these to 8 from 20]
- [Provide a detailed description of the ELB architecture] [Need to say something about the number of ENIs that are required when creating a new load balancer; we have recently dropped these to 8 from 20]
- [Provide a detailed description of the ELB architecture] [Need to say something about the number of ENIs that are required when creating a new load balancer; we have recently dropped these to 8 from 20]
- Connections: for TCP, each connection is bound to the connection on the back-end; for HTTP, a connection pool is used to the back-end instance and a request will be sent on an existing connection, if one exists. Headers: for TCP, the headers are left unchanged and forwarded to the back-end instance as is; for HTTP, headers may be inserted depending on the features that are enabled on the load balancer. Source IP: Since ELB proxies all incoming connection, the back-end instance will see the connection coming from the ELB nodes themselves. For TCP, proxy protocol can be used to retrieve the source IP address and port. For HTTP, the source IP address is appended to the header in the X-Forwarded-For header. Algorithms: For TCP, round robin is used. For HTTP, least outstanding requests, which is a request-based form of the leastconns algorithm is used. Sticky Sessions: although we always recommend architectures that utilize caching off instance, such as ElastiCache, we do support cookie-based sticky sessions for HTTP listeners.
- Connections: for TCP, each connection is bound to the connection on the back-end; for HTTP, a connection pool is used to the back-end instance and a request will be sent on an existing connection, if one exists. Headers: for TCP, the headers are left unchanged and forwarded to the back-end instance as is; for HTTP, headers may be inserted depending on the features that are enabled on the load balancer. Source IP: Since ELB proxies all incoming connection, the back-end instance will see the connection coming from the ELB nodes themselves. For TCP, proxy protocol can be used to retrieve the source IP address and port. For HTTP, the source IP address is appended to the header in the X-Forwarded-For header. Algorithms: For TCP, round robin is used. For HTTP, least outstanding requests, which is a request-based form of the leastconns algorithm is used. Sticky Sessions: although we always recommend architectures that utilize caching off instance, such as ElastiCache, we do support cookie-based sticky sessions for HTTP listeners.
- Connections: for TCP, each connection is bound to the connection on the back-end; for HTTP, a connection pool is used to the back-end instance and a request will be sent on an existing connection, if one exists. Headers: for TCP, the headers are left unchanged and forwarded to the back-end instance as is; for HTTP, headers may be inserted depending on the features that are enabled on the load balancer. Source IP: Since ELB proxies all incoming connection, the back-end instance will see the connection coming from the ELB nodes themselves. For TCP, proxy protocol can be used to retrieve the source IP address and port. For HTTP, the source IP address is appended to the header in the X-Forwarded-For header. Algorithms: For TCP, round robin is used. For HTTP, least outstanding requests, which is a request-based form of the leastconns algorithm is used. Sticky Sessions: although we always recommend architectures that utilize caching off instance, such as ElastiCache, we do support cookie-based sticky sessions for HTTP listeners.
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. On October 15th @ 3:30 PM, the POODLE SSLv3 Vulnerability was announced.
- On October 15th @ 3:30 PM, the POODLE SSLv3 Vulnerability was announced.
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- ELB takes care the details involved in SSL so that you don’t have to. Recent events have shown that this is a complex space with new vulnerabilities being exposed monthly. ELB provides custom cipher
- You may be at peak multiple times a day! Important to consider all possible bottlenecks, you may be scaling on CPU, but need to watch IO, memory, etc.
- Example of customer with very high latencies that were able to diagnose the issue using Access Logs.
- [Provide a detailed description of the ELB architecture] [Need to say something about the number of ENIs that are required when creating a new load balancer; we have recently dropped these to 8 from 20]