NGINX Plus on AWS
•Download as PPTX, PDF•
12 likes•3,253 views
Scott Ward's presentation during the the 2014 NGINX users conference.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to NGINX Plus on AWS
Similar to NGINX Plus on AWS (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
NGINX Plus on AWS
- 1. NGINX Plus on AWS Scott Ward— Solutions Architect scotward@amazon.com
- 2. NGINX on AWS Who is AWS? NGINX – Usage on AWS and best practices © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
- 3. A broad and deep platform that helps customers build sophisticated, scalable applications © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
- 4. A Culture of Innovation: Experiment Often & Fail Without Risk
- 5. Who is using AWS and what are they using it for?
- 6. Startups on AWS http://aws.amazon.com/solutions/case-studies/
- 7. Enterprises on AWS http://aws.amazon.com/solutions/case-studies/
- 8. Foundation Services Infrastructure Storage (Object, Block and Archive) Regions Availability Zones Networking Collaboration and Sharing Security & Access Control Platform Services Databases Relational NoSQL Caching Analytics Hadoop Real-time Data warehouse App Services Queuing Orchestration App streaming Transcoding Email Search Deployment & Management Containers Dev/ops Tools Resource Templates Mobile Services Identity Sync Mobile Analytics Notifications Enterprise Applications Virtual Desktops Data Workflows Usage Tracking Monitoring and Logs Compute (VMs, Auto-scaling and Load Balancing) CDN and Points of Presence
- 9. 10 regions 26 availability zones 52 edge locations Infrastructure
- 10. AWS Services Overview Amazon EC2 – Virtual Servers & resizable compute capacity Auto Scaling – Scale compute resources up and down Elastic Load Balancing – Load balancer for compute instances Amazon Elastic Block Storage (EBS) – Block storage for EC2
- 11. AWS Service Overview AWS Identity and Access Management – AWS Account Access Controls Amazon Route 53 – Scalable Domain Name System Amazon CloudWatch – Resource and Application Monitoring
- 12. NGINX on AWS
- 13. NGINX Who is using NGINX on AWS • Startups, Enterprises, Government Agencies • Example: NASA/JPL Mars Curiosity Mission
- 14. NGINX – NASA/JPL
- 15. Where NGINX fits
- 16. Installing NGINX Plus on AWS • Launch from AWS Marketplace http://aws.amazon.com/marketplace • Search on “NGINX Plus” – Amazon Linux – Ubuntu • 30 Day Free Trial !! • Launch and Verify – $ /etc/init.d/nginx status
- 17. NGINX - Security Recommendations Use SSH for accessing your hosts Security Groups to control inbound/outbound traffic Connection Method Control access here Protocol Port Range Source IP or Group Comments HTTP tcp 80-80 CIDR IP Range non-encrypted web traffic HTTPS tcp 443-443 CIDR IP Range encrypted web traffic SSH tcp 22-22 CIDR IP Range ssh access SSH tcp 873-873 CIDR IP Range rsync access SSH udp 5405-5405 CIDR IP Range corosync traffic
- 18. Load Balancing Behind ELB Route53 hosted zone Elastic Load Balancer region Web App 1 NGINX Plus EC2 instances Web App 2 Web App 3
- 19. Load Balancing DIY region Web App 1 NGINX Plus AMI Web App 2 Web App 3 Elastic IP
- 20. Load Balancing DIY Considerations – Being Auto Scaling Aware Command Line Option describe-auto-scaling-instances describe-instances Update NGINX configuration
- 21. Load Balancing DIY Considerations – Being Auto Scaling Aware SQS and SNS for notifications Current State NGINX Auto Scaling group Amazon SQS Scale up NGINX Auto Scaling group Scale down Amazon SQS Amazon SNS NGINX Auto Scaling group
- 22. Performance EC2 instance Sizing • Workloads vary – Start small and move up Testing Initial Launch Steady State T2 class M3 General Auto Scaling group Purpose Bigger or More EC2 EC2 EC2 EC2 EC2 EC2 EC2
- 23. Broad Set of Compute Instance Types… GPU enabled G2 General purpose M3 Memory optimized R3 M2 CR1 Storage and IO optimized Compute optimized C3 C1 CC2 I2 HI1 HS1 M1 CG1 © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
- 24. Performance Traffic profiles • SSL termination = CPU resources • Lots of small requests = CPU resources • Web Socket = CPU resources • Content Caching = Memory & Instance Storage • Bandwidth Heavy = Horizontal scaling
- 25. Performance Planning • Determine the right instance profile • Test, Test, Test, Test & Test • Run expected and un-expected traffic patterns against your environment • Analyze results and tweak where needed – Throw away what does not work • Monitor
- 26. Performance Baselines Performance testing tools – ab – jmeter – http_load – siege – curl-loader – weighttp – httperf – wrk – sslswamp – your favorite tool
- 27. Performance Baseline Approaches Different Instanc e Different Availability Zon e Different Region NGINX Test Instance region Availability Zone Availability Zone NGINX Test Instance NGINX Test Availability Zone region Instance Availability Zone region
- 28. High Availability – General Recommendations Use multiple AZs in a region Auto Scaling to help with load change EC2 EC2 region Availability Zone 2 Availability Zone 1 region EC2 EC2 Auto Scaling group Availability Zone 1 EC2 EC2 Auto Scaling group Availability Zone 2 s
- 29. NGINX High Availability Configuration • Highly available pair of NGINX instances on EC2 with a public IP Address • Active/Passive Configuration • Corosync and Pacemaker for clustering
- 30. NGINX High Availability Configuration Elastic IP Address Corosync/Pacema ker NGINX EC2 Primary NGINX EC2 Standby
- 31. NGINX High Availability Configuration Install and config steps • Allocate an Elastic IP address • Create IAM Instance Profile – Assign Elastic IP – Disassociate Elastic IP – EC2 Describe • Launch instances with IAM Instance Profile • Install NGINX HA – $sudo yum install nginx-ha – $sudo apt-get install nginx-ha • Start NGINX HA config on both instances – $ sudo nginx-ha-setup • Answer questions on both instances • Pick a primary • Done!!! Configuration Verification =========== Last updated: Wed Mar 19 02:46:49 2014 Last change: Wed Mar 19 02:46:42 2014 via cibadmin on nginxha101 Stack: openais Current DC: nginxha101 – partition with quorum Version: 1.1.6- 9971ebba4494012a93c03b40a2c58ec0eb60f50c 2 Nodes configured, 2 expected votes 2 Resources configured. ============ Node nginxha100: online ha-ip (ocf::heartbeat:IPaddr2) Started ha-nginx (ocf::nginx-ha:nginx-ha) Started Node nginxha101: online
- 32. NGINX High Availability Architecture Options Same Region Elastic IP Primary NGINX HA Instance Web App 1 Web App 2 Web App 3 region Availability Zone 1 Failover NGINX HA Instance Web App 1 Web App 2 Web App 3 Availability Zone 2
- 33. NGINX High Availability Architecture Options Different Regions Region 1 Elastic IP Failover NGINX HA Instance Web App 1 Web App 2 Web App 3 Availability Zone 2 Primary NGINX HA Instance Web App 1 Web App 2 Web App 3 Availability Zone 1 Elastic IP Failover NGINX HA Instance Web App 1 Web App 2 Web App 3 Availability Zone 2 Primary NGINX HA Instance Web App 1 Web App 2 Web App 3 Availability Zone 1 Region 2 Amazon Route53 hosted zone
- 34. NGINX High Availability Configuration Additional Considerations • Make sure that both NGINX instances are configured the same for their jobs • You get Active/Passive with two instances in cluster – Active/Active or more than two instances? Corosync and Pacemaker documentation
- 35. Monitoring Know what is going on with your environment at all times
- 36. Amazon CloudWatch Default Amazon EC2 metrics CPU Utilization (Percent) Disk Reads (Bytes) Disk Read Operations (Operations) Disk Writes (Bytes) Disk Write Operations (Operations) Network In (Bytes) Network Out (Bytes) Status Check Failed (Count) 1 or 5 minute intervals
- 37. NGINX Metrics into Amazon CloudWatch status.html CloudWatch Install Agent $ sudo yum install nginx-cw-agent $ sudo apt-get install nginx-cw-agent
- 38. NGINX Metrics into Amazon CloudWatch status.html CloudWatch Update Configuration $ /etc/nginx-cw-agent/nginx-cw-agent.ini [source1] name=exampleorg url=http://example.org/status [source2] name=examplecom url=http://example.com/status http_user=testuser http_pass=testpass
- 39. NGINX Metrics into Amazon CloudWatch status.html CloudWatch Start Background Agent Test - $ /usr/bin/nginx-cw-agent.py –f start All in - $ sudo service nginx-cw-agent start View Metrics
- 40. NGINX with Amazon CloudWatch Logs • Consolidate metrics and alarming for log files from 1 or many instances • Define filters to parse content from your log files • Measure and alarm on specific attributes • Define retention period for your log files EC2 CloudWatch
- 41. NGINX with Amazon CloudWatch Logs Filter Alarm
- 42. NGINX with Amazon CloudWatch Logs EC2 EC2 EC2 CloudWatch EC2 EC2 EC2 Capture logs from multiple instances in one place
- 43. Backup Strategy - Options Protect your configuration • Create an AMI with each new verified config • Snapshot the root volume • Store config files in Amazon S3 or source repository – Deploy via user-data when new Amazon EC2 instance launches • Continuous integration software to build new AMIs with your NGINX configuration
- 44. Scott Ward— Solutions Architect scotward@amazon.com AWS Pop-Up Loft 925 Market Street http://aws.amazon.com/start-ups/loft/ © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.
Editor's Notes
- What I am talking about here is partly from an upcoming whitepaper around NGINX and its usage on AWS. Going to start with an overview of AWS and who we are. Then jump into NGINX and go into some best practices around architecting on AWS with NGINX, security recommendations, specific NGINX configurations you can use with AWS and AWS product integrations you can achieve with NGINX. I will not be going into any design of our individual services and if they are using NGINX or not.
- The broad and deep platform that is AWS. If want to build new businesses from scratch or move some/all workloads to cloud, need a broad array of services and features to make this happen and not have to piecemeal it AWS Platform started in 2006 and it has grown rapidly since that time. Today it is the underlying infrastructure for companies around the world including startups, enterprises, and government agencies. AWS has hundreds of thousands of customers in 190 countries around the world. A little background… After over a decade of building and running the highly scalable web application, Amazon.com, the company realized that it had developed a core competency in operating massive scale technology infrastructure and datacenters, and embarked on a much broader mission of serving a new customer segment—developers and businesses—with a platform of web services they can use to build sophisticated, scalable applications. AWS is a comprehensive cloud services platform, offering compute power, storage, content delivery, and other functionality that enables businesses to cost-effectively deploy applications and services with greater flexibility, scalability, and reliability. The power of self-service through AWS means you can proactively address your internal plans and react to external demands when you choose and not have to wait for a salesperson to return your call. In response to customer needs and internal innovation on the customer’s behalf, In 2011, we released over 80 significant services and features; in 2012, nearly 160; and in 2013, 280. This trend does not show any sign of slowing.
- Experiment Often and fail without risk No time spent on ordering and waiting for infrastructure. Have an idea and try it out. Keep what you need return what you do not IT personnel can focus on more important pieces above the infrastructure or on more important infrastructure needing their attention.
- DropBox Pinterest AirBnB Flipboard
- Shell Netflix Samsung GE Philips Pfizer Bristol-Myers Squibb Intuit CBA Suncorp
- Quick focus on infrastructure because it is a key component that we will be discussing and utilizing throughout this presentation
- As you saw from the overall AWS platform and service overview slide there are a lot of services that AWS offers. What I am going to touch base on here are services that are going to be relevant to the rest of the discussion that I will be presenting on. ELB Health Checks AutoScaling Health Checks
- Route53- Route to infrastructure inside or outside of AWS * Routing – Latency, Geo, weighted round robin * health checks – DNS Failover. Route 53 monitors endpoint and if there is a failure traffic will be routed to an alternate endpoint
- When it comes to NGINX on AWS we see lots of use cases where it is part of the architecture. In the short time that I have been with AWS I hear it referred to regularly as being parts of architectures that people have implemented on AWS. Amazon Linux AMI now has it.
- Here is the architecture implemented by NASA/JPL for the Mars Curiosity mission. This comes from the AWS Case Study on the implementation. This architecture represents what was used to support the live video streaming of the rover landing. You will see that they are implementing 100s of EC2 instances running NGINX. In this case they are using it as cache servers for content that they needed to serve up during the live event.
- NGINX Plus is available in the AWS Marketplace. AWS Marketplace is an online store that allows you to find software and services that run on the EC2 cloud. Search on NGINX Plus to find the listing of marketplace offerings Go through the launch instance process to get the instances launched with your desired configuration Connect to and verify your instance. This will give you your basic NGINX instance ready to serve up web traffic and give you your baseline for going deeper
- Security is a top priority at AWS. We look to keep AWS secure as well as advise our customers on how they can keep themselves secure. Keep SSH restricted even if you open up HTTP and HTTPS. If you are really good at how you deploy you can even get away without using SSH.
- ELB Error checking and taking instances out of service. Multiple layers to do health checks on your stack. Route53, ELB, AutoScaling
- If you are using your NGINX installation as your primary load balancer and you are serving up traffic to servers that are an in an Auto Scaling group you need to make sure that your NGINX configuration is aware of instances coming and going from your Auto Scaling group.
- If you are using your NGINX installation as your primary load balancer and you are serving up traffic to servers that are an in an Auto Scaling group you need to make sure that your NGINX configuration is aware of instances coming and going from your Auto Scaling group.
- The T2 instance class is well served for initial testing of configuration and functionality for your deployments. First production deployment can be served by general purpose instances such as m3.medium or m3.large As traffic levels grow you can look to scale up or scale out depending on your needs
- SSL termination, lots of small requests or WebSocket are more CPU intensive so you want to be looking at instances that will allow you access to that resource. Content caching is going to be looking to retain as much in memory as well as be able to access disk storage quickly. You will be looking for appropriately sized instance storage as well as memory to hold as much of your content as possible so that you are minimizing disk hits. Bandwidth heavy such as serving files or large downloads – you may find that you are challenged by network bandwidth as a limiting factor and horizontal scaling may be the best option
- One of the great benefits of the AWS platform it that is facilitates the ability to experiment various scenarios and then return the infrastructure when you are done. You only pay for what you used during the time that you used the infrastructure. Test out some configurations you think will work for your expected and un-expected traffic patterns and if you are not getting performance that you want try different instance sizes or add more instances. When you are done testing turn off and return what you do not need. Monitoring once you have your desired configuration is critical as it allows you to verify that things are performing optimally as well as allow you to get in front of potential problems. Taking up front time to make sure that you are set up properly will pay benefits in the long run. Unexpected means things like AutoScaling and how you can launch enough instances to cover what you need. It is configurable based on the patterns that you are seeing. Test large traffic rates quickly. Do you need to change your monitoring.
- I did some research on web server load testing tools as well as asked around. I got a lot of different answers. End of the day you need to use what you are comfortable with and what allows you to execute the tests that you feel will help you get what you need out of your test.
- For your testing it is key that your tests reflect your actual traffic patterns. It is key that your test is executed on a different host so that the testing tool does not conflict with your instance performance or skew metrics. It is next key to test from a different availability zone to help simulate traffic coming from a different location It is next key to test traffic from a different region to help simulate traffic coming from other locations over the public internet
- As we dive into some NGINX use cases you will see examples of these recommendations.
- In addition to High Availability configuration that you may implement on AWS where you might have NGINX in multiple Azs and using AutoScaling, NGINX also has its own high availability configuration available to handle situations that require it.
- Different routing options from Route53. Outline from whitepaper Route 53 latency and round robin options.
- Lots of different options that you can employ for your monitoring needs and in the end you are going to choose the one that best suits your needs. There is an opportunity here to utilize CloudWatch as your centralized monitoring for not only what is going on with your EC2 instances that are running NGINX but also your overall NGINX and application environment.
- This requires a small agent to be running on your EC2 instance. Either need to use an instance role or provide access keys
- CloudWatch logs allows you the ability to capture log files from your instances for further analysis. You could be capturing one log file from one instance or you could be capturing the same log file from many instances in a fleet. Cloudtrail logs gives you the ability to interpret the data in these log files and turn them into CloudWatch metrics. You can view the metrics graphically or create alarms based on the metrics that came from your log files