HA With AWS OpsWorks
Download as PPTX, PDF0 likes169 views
The document discusses high availability using AWS OpsWorks and highlights the evolution and benefits of cloud computing, such as low cost and agility. It emphasizes the importance of using templates for orchestration and adaptable recipes for managing deployments, along with considerations for scaling and failover strategies. The key takeaway is the significance of dynamic solutions and iterative improvements in achieving effective cloud infrastructure.
HA With AWS OpsWorks
- 1. High Availability with AWS OpsWorks shane.davis@linkdigital.com.au @link_sdm SHANE DAVIS Lead Architect ANZ
- 2. Introduction 2 Link Digital Service Delivery Manager Lead Architect ANZ Data Shades Key Contributor AWS User Group CBR Organiser
- 3. PCs and Pet Mentality 3 Cute, precious and adorable Not scalable Timely to set up
- 4. The Computing Evolution 4 • Desktop PCs • Server in a cupboard • Virtualisation • Virtual Dedicated Servers • Cloud Computing
- 5. Cloud Benefits 5 • Low Cost • Agile • Easily Managed Cents per hour to run Pay for what you use Scales up and down easily Point and Click: • Provisioning • Monitoring • Management
- 7. 7The Orchestration Journey Bash/Python scripts CLI: Command Line Interface Orchestration Suites
- 8. 8Why OpsWorks? Templates Build Stacks Serverless Iterative Consistent Transparent Design Access Management Clone capable
- 9. 9OpsWorks Design Layers Instances Time Based Load Based Apps Deployments Monitoring Resources Permissions Instances can belong to 1 or more layers Separate Instances out later • App Source • Data Source • Domains • SSL App Definition Deploy to one or more layers Recipes perform: • Setup • Configure • Deploy • Undeploy • Shutdown
- 10. 10HA Design Tips Disposable Nodes Truly HA = no pets Versatile Recipes • Able to manage failed states • Capable of upgrades • Adaptive and aware Dynamic Resources Don’t paint the cogs
- 11. 11HA Considerations • Use AWS Services when possible • Use self hosted services as a bridge • Use Route53 Failover and Health checks
- 12. 12Scaling Options Bare Metal Deploy AMI + Autoscale Group Latest versions Failure risks Slower Deployment No setup No Updates Faster Deployment AMI + Deploy Failsafe setup Fast Deployment Latest versions
- 13. 13Main Take Away • The Real Magic is in the sauce (recipe) • Dynamic is the key - stateless, non-static • Iteration is the way forward. Build & Improve
Editor's Notes
- #4: When I started in IT, this was the state of the art PC. Everything was hand coded and time consuming to set up. People have DR plans because they’re scared of losing their one off masterpieces. Their pets.
- #5: Over the last 30 years we’ve moved from desktops to the cloud.
- #6: Cloud is low cost, Agile; scales up and down easily Easy to manage via GUI
- #7: As organisations adopt cloud they benefit early from the scalability Next they utilise automation; scaling policies, light weight orchestration The ultimate goal is typically full orchestration where all provisioning and application deployment is fully automated.
- #8: The journey many take to orchestration is initially to develop standard approaches using the CLI This leads to a collection of scripts in Bash or Python that usually require manual set up and provisioning The next evolution is usually some kind of orchestration suite depending on time and requirements. Many go for lightweight approaches that don’t require a provisioning server; making Ansible a popular choice. There is however another server less option; using CloudFormation and OpsWorks together.
- #9: Use templates to build stacks. No need for an orchestration server Use templates to reply apps, layers and instances See stack architecture at a glance Simple serverless SSH control using AWS STS
- #10: Create one layer per service role. EG: Solr; Piwik etc Instances can belong to one or more layers; providing 1 or more services Apps define what software should run on what layers. Layer contain Chef recipes to perform the actual setup, deploy and configuration Deployments are triggered on events. Setup, config and deploy when an instance is created. Updates and new deployments can be triggered manually, or externally via API calls from GitHub web hooks for example. Resources such as RDS, on-prem servers and EBS volumes can be assigned to the stack. Permissions control who has access to instances in the Stack. Security Token Service goes hand in hand with this.
- #11: When building HA stacks, nodes need to be truly disposable. This is accomplished via smart recipes. Use dynamic resources. Don’t paint the cogs means avoiding pet names for things, and not expecting EBS volumes to be mounted as specific devices. Just define the mount point instead. Adaptive and aware recipes means those that can update settings and config based on what is on or offline. EG: Memcache configs
- #12: AWS services are managed, scalable and HA by default Use existing services like NFS and GlusterFS as a bridge to AWS replacements Use Route53 Failover and Health checks for services that don’t necessarily support HA
- #13: The two main scaling options are bare metal builds, or AMIs. You can use OpsWorks to create and update the AMI A hybrid approach is to have a base AMI built by OpsWorks, then use this image in a layer that performs failsafe updates when scaling
- #14: The Chef recipes are where all the real magic happens. OpsWorks provides a great insight into your stacks. Everyone can see how they’re built; what’s installed etc Be Dynamic and don’t be tempted by static hosts, volumes, IPs etc. The price you’ll pay is flexibility. Iteration is the way forward. Don’t try to build the perfect stack on day one. Convert your existing scripts and move forward from there. You can retrospectively apply improvements to existing stacks or use Blue Green migrations.