AWS Elasticity and Auto Scaling
•Descargar como PPTX, PDF•
1 recomendación•159 vistas
David Jones and Chris Williams talk about best practices when using the Amazon Web Services (AWS) services Auto Scaling and RDS.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a AWS Elasticity and Auto Scaling
Similar a AWS Elasticity and Auto Scaling (20)
Último
Último (20)
AWS Elasticity and Auto Scaling
- 1. 1 Presented by David Jones and Chris Williams AWS Elasticity and Auto Scaling
- 2. 2 Who Are These Yahoos? • David Jones (@virtualJonesie) • Practice Director – Hybrid Cloud Data Center • AWS Solutions Architect - Professional • VMware Certified Implementation Expert – Data Center Virtualization (VCIX-DCV) • VMware VCP-DCV, CMA, NV • Chris Williams (@mistwire) • Enterprise Cloud Consultant • AWS Solutions Architect - Professional • VCIX, vExpert Cloud, VCP, MCSE, CCNA, LMNOP… • vBrownBag host/presenter • http://mistwire.com
- 3. 3 Agenda • ASG 101 • What Is It & Why is it SO COOL? • The Components • Your Friends: Elastic Load Balancers & Target Groups • RDS 101 • HA (not the VMWare type) & Multi-AZ architecture • Scalability != Elasticity • LIVE DEMO! • All the appropriate sacrifices to the demo gods have been made* • Q&A *no animals were harmed in the creation of this demo
- 5. 5 What Is Amazon EC2 Auto Scaling? “Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application.”
- 6. 6 What Is Amazon EC2 Auto Scaling? “Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application.”
- 7. 7 What Is Amazon EC2 Auto Scaling? “Amazon EC2 Auto Scaling helps you ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application.” Why do you need Amazon EC2 Auto Scaling? 1. Variable load patterns 2. Hardware/Software* Failure 3. Cost Optimization
- 8. 8 The Components of Auto Scaling: The Launch Configuration
- 9. 9 The Components of Auto Scaling: The Launch Configuration
- 10. 10 The Components of Auto Scaling: Auto Scaling Groups
- 11. 11 The Friends of Auto Scaling: Target Groups
- 12. 12 The Friends of Auto Scaling: Load Balancers
- 13. 13 Tying the front end together 1 Dashingly handsome yet humble end- user goes to website 2 Traffic goes across internet to IGW 3 IGW sends traffic to ELB. ELB routes traffic to healthy instances 4 ASG uses scaling policy to decide if more instances are needed. If yes = MOAR SERVERS! 5 New instances run through launch config, which includes updates & mounting EFS drive
- 14. 14 ASG Gotchas! Prep your AMI! Give your instances sufficient time to come up Tune your health checks
- 15. 15 RDS 101
- 16. 16 Region Availability Zone RDS DB Master Instance Availability Zone RDS DB Standby Instance (Multi-AZ) Application webdemo.us-east-1.rds.amazonaws.com Synchronous Replication RDS 101: High Availability In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to: • Provide data redundancy • Eliminate I/O freezes – snapshots and backups • Minimize latency spikes during system backups
- 17. 17 Region Availability Zone RDS DB Master Instance Availability Zone RDS DB Standby Instance (Multi-AZ) Application webdemo.us-east-1.rds.amazonaws.com Synchronous Replication Region Availability Zone RDS DB Master Instance Availability Zone RDS DB Standby Instance (Multi-AZ) Application webdemo.us-east-1.rds.amazonaws.com Synchronous Replication Amazon RDS handles failovers automatically so you can resume database operations as quickly as possible without administrative intervention. RDS 101: High Availability The primary DB instance switches over automatically to the standby replica if any of the following conditions occur: • An Availability Zone outage occurs. • The primary DB instance fails. • The DB instance's DB instance class is changed. • The operating system of the DB instance is undergoing software patching. • A manual failover of the DB instance was initiated using Reboot with failover.
- 18. 18 RDS 101: High Availability Gotchas: • DB instances using Multi-AZ deployments may have increased write and commit latency compared to a Single-AZ deployment, due to the synchronous data replication that occurs. • You may have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. • For production workloads, AWS recommends that you use Provisioned IOPS and DB instance classes (m4.large and larger) that are optimized for Provisioned IOPS for fast, consistent performance. The high-availability feature is not a scaling solution for read-only scenarios; you cannot use a standby replica to serve read traffic. To service read-only traffic, you should use a Read Replica
- 19. 19 RDS 101: Scalability http://mistwire.com/2018/03/how-to-change-the-size-of-your-aws-rds-with-zero-downtime Amazon RDS Read Replicas provide enhanced performance and durability for database (DB) instances. • Read Replicas allow you to “elastically” scale out beyond the capacity constraints of a single DB instance for read- heavy database workloads. • Create one or more replicas of a DB Instance and serve high-volume read traffic from multiple copies of your data, thereby increasing aggregate read throughput. • Read replicas can also be promoted to become standalone DB instances. • This provides a complementary availability mechanism to Amazon RDS Multi-AZ Deployments.
- 21. 21 RDS 101: Scalability When to use Read Replicas • Scaling beyond the compute or I/O capacity of a single DB instance for read-heavy DB workloads. • Serving Read traffic while the source DB instance is unavailable. • If your source DB instance cannot take I/O requests - I/O suspension for backup/maintenance • Business Reporting or Data Warehousing scenarios • Business Reporting queries run against a Read Replica, rather than you primary production DB instance.
- 22. 22 Database Engines: Scalability != High Availability Multi-AZ Deployment Read Replicas Synchronous Replication – Highly Durable Asynchronous Replication – Highly Scalable Only database engine on primary instance is active. All read replicas are accessible and can be used for read scaling. Automated backups are taken from standby. No backups configured by default. Always span two AZs within a single Region. Can be within an AZ, Cross-AZ, or Cross-Region. Database engine version upgrades happen on primary. Database engine version upgrade is independent from source instance. Automatic failover to standby when a problem is detected. Can be manually promoted to a standalone database instance.
- 23. 23 Live Demo
- 26. 26 What Can You Do With This?
- 27. 27 What Can You Do With This?
- 28. 28 greenpages.com greenpages.com/blog twitter.com/GreenPagesIT Online Toll Free (800) 989-2989 Direct (207) 439-7310 Fax (207) 439-7334 Contact Headquarters: 33 Badgers Island West Kittery ME 03904 Additional Offices: Boston MA New York NY Alpharetta GA Tampa FL Locations Thank you
Notas del editor
- Chris and I have been accused of bickering like an old married couple. We could talk about this all night, we slimmed it down as best we could…
- CPU Utilization Network throughput Custom Metric SQS queue # ELB SurgeQueueLength SpilloverCount
- Creating a launch config is very similar to making a new EC2 instance except that it doesn’t actually spawn a new instance.
- All of the things you want do to the new instance while it’s getting added to the ASG
- Scaling Policies – where you define the trigger for scaling Target Groups – The load balancing target group associated with the ASG Health Check Grace Period – how long to wait before checking the health of a newly created instance
- Load balancer that is associated with this target group The health checks used to determine if the instance is “healthy” (i.e. http or https for web servers)
- Multi-AZ Uses synchronous replication from primary AZ to second AZ If primary AZ instance fails, AWS will automatically fail over to secondary AZ instance. Will use the same DNS endpoint, no need to change the connection string(s) in your EC2 instances. Multi-AZ allows you to have an exact copy of your production DB in another AZ. AWS handles the replication for you. When Prod DB is written to, this write will automatically be synchronised to the standby DB. Multi-AZ DBs available for SQL Server Oracle MySQL Server PostgreSQL MariaDB
- Running a DB instance with high availability can enhance availability during planned system maintenance, and help protect your databases against DB instance failure and Availability Zone disruption. In the event of DB Maintenance, DB instance failure, or an AZ failure, Amazon RDS will automatically failover to the standby so DB operations can resume quickly without admin intervention. Multi-AZ deployments for Oracle, PostgreSQL, MySQL, and MariaDB DB instances use Amazon's failover technology. SQL Server DB instances use SQL Server Mirroring. Amazon Aurora instances stores copies of the data in a DB cluster across multiple AZs in a single AWS Region, regardless of whether the instances in the DB cluster span multiple AZs.
- May have increased write commit latency – write not committed until written in both primary and standby. If failed over, may have increased latency going from app across AZs to DB – despite high-speed backend network Multi-AZ is used for DR only. It is NOT used for performance.
- Scalability - Increase instance size. Elasticity - Not very elastic, can't scale RDS based on demand. Read Replicas Allow you to have a read-only copy of your Prod DB. Achieved using asynchronous replication from the primary RDS instance to the read replica. Use Read Replicas for very read-heavy DB workloads Read Locally, Write Globally Good for reporting, test/dev, etc. Used for Scaling, NOT DR! Must have automatic backups turned on in order to deploy a read replica. Once the Read Replica is created, DB updates on the source DB instance will be replicated using supported engine's native. asynchronous replication.
- Reads stay within the region, writes go to the master. Could also have a BI/Reporting system pulling from a Read Replica. Good exam topic!
- You CAN have Read Replicas of Read Replicas for scaling - Watch out for latency! Asynch replication from Primary to Read Replica, then Asynch Replication from Read Replica to child Read Replica can instroduce latency in data on child replica. Up to 5 copies/read replicas of your primary DB instance. Each Read Replica has it's own DNS end point Cannot have Read Replicas that have Multi-AZ enabled. If you create a Read Replica, it woll NOT be a Multi-AZ Read Replica - only a single instance of the Read Replica in a single AZ. You CAN have a Read Replica of a Multi-AZ source DB. Read Replicas can be promoted to their own DB instances. This breaks replication. Can have Read Replicas in a second Region Only for MySQL and MariaDB NOT for PostgreSQL Read Replica can be larger than the source DB Use the Engines' native asynch replication to update the Read Replica MySQL PostgreSQL MariaDB Not on the exam yet Aurora Employs SSD-backed virtualized storage layer purpose-built for DB workloads. Aurora replicas share the same underlying storage as the source instance Lowers the cost and voids the need to copy data to the replica nodes.
- You can combine Multi-AZ deployments and read replicas to enjoy the benefits of each. For example, you can configure a source database as Multi-AZ for high availability and create a read replica (in Single-AZ) for read scalability. With RDS for MySQL and MariaDB, you can also set the read replica as Multi-AZ, allowing you to use the read replica as a DR target. When you promote the read replica to be a standalone database, it will already be Multi-AZ enabled. Note that RDS for PostgreSQL does not yet support this feature.