High Availability - The easy way

Presented at Web Directions What Do You Know? Sep 4th 2013 Canberra, Australia

Transcript

1. High Availability The easy way My talk tonight is on high availability and how it has become more feasible and accessible through cloud services.
2. Firstly though, I work with these amazing people.
3. At Icelab. We’re based here in Canberra and also Melbourne.
4. I’m going to briefly describe what high availability is and then look at how we implemented it for a client on a relatively small budget.
5. Ops Team Without an ops team.
6. IT Department And without involvement from an IT department.
7. What is high availability? High availability is a promise. A promise that you’ll have your services running for a stated percentage of time, known as…
8. The nines
9. 99.9% Let’s start with three nines. Three nines promises…
10. 8.7 hours of downtime per year Maximum.
11. 99.99999% Once you get to seven nines then downtime…
12. 3.1 seconds of downtime per year Downtime basically does not exist.
13. Why is it important? Availability is important for a variety of reasons. Financial rational is common, but it really depends on the service you’re running. You could imagine for a Tsunami alert system you’d want zero downtime.
14. How do you decide if you require it?
15. Making the decision could involve some sort of risk matrix…
16. But if you’re like me and you simply hate it when your services go down, you do everything you can ahead of time - and within your budget - to make sure your services are as highly available as possible.
17. How do you do it?
18. Single points of failure The main strategy is to eliminate as many single points of failure as you can in your application stack. Sometimes there are external services you can do nothing about, so simply choose them wisely upfront. You take this elimination of SPOFs all the way down to the data centre and even its geographic location…
19. Here we have a data centre in Hobbiton and another in Rivendale. Sensible choices really.
20. Mordor however might not be such a great choice… Besides, most of our users are in Eriador anyhow and geographic proximity is important to reduce latency.
21. Wait? Two locations?
22. Do you know how much complexity that introduces?
23. Option 1
24. You either build a failover stack in another data centre where a clone of your application stack sits relatively idle, although it’s constantly receiving data from the primary stack to stay in sync.
25. Ready to take over the traffic at a moments notice.
26. Option 2
27. You have two or more stacks, or nodes as they’re called in this model, running in two or more data centres, all serving live traffic. The nodes continuously syncronise data between themselves.
28. Nodes can go down.
29. Then come back up again. Resynconising their data from the other nodes. I prefer this model as you’re getting the most out of your resources. Plus you know that your other nodes are actually operational because they’re working all of the time, unlike the failover model.
30. WTF Hugh, you’ve chosen the most complex model!
31. It’s actually not that hard now
32. I figure the smaller I make their logo, the less of a shill I’ll sound… At the end of 2012 Amazon started offering their web services out of two data centres in Australia.
33. Data centre A
34. Data centre B - Known as “availability zones”.
35. The client we did this for recently is the Old Parliament House.
36. Icelab has had the fortune to work with the Old Parliament House over the last few years and in that time we’ve developed some really high quality resources together.
37. Just a quick video showcasing some of the nice interactions we’ve built.
38. A lot of this content has made its way in to classroom programs around the country. So having the sites available when those classes are run is very important. Having a resource unavailable could be highly disruptive to an educator’s learning plan.
39. Isn’t it great that HTML and CSS3 has come so far that screen shots simply don’t do it justice.
40. The setup
41. Route 53 DNS Cloud Front CDN Elastic Load Balancer You start with AWS’s DNS service Route 53. We point that at their CDN and their load balancing services.
42. Route 53 DNS Cloud Front CDN Elastic Load Balancer EC2 A (server A) Availability Zone A Availability Zone B EC2 B (server B) Then we set up EC2 instances in both availability zones.
43. Route 53 DNS Cloud Front CDN Elastic Load Balancer EC2 A (server A) Availability Zone A Availability Zone B EC2 B (server B) Then you add a multi availability zone MySQL RDS service. You could do this yourself, but having the replication and failover handled for you is a big win.
44. Route 53 DNS Cloud Front CDN Elastic Load Balancer EC2 A (server A) Availability Zone A Availability Zone B EC2 B (server B) S3 Then finally you have your static files sent to S3 buckets and served from CloudFront. Theoretically the fours services outside the boxes are already in a high availability configuration.
45. Configuration Management How do you set the EC2 instances up?
46. “If you can’t automate it, don’t do it” Automate it. Automate everything in fact.
47. With one of these.
48. All of AWS is API driven.
49. AWS OpsWorks AWS also now has OpsWorks and it gives you some solid point and click deployment options. It uses Chef under the hood.
50. I actually tried it out and was able to configure the aforementioned setup in about 30 minutes and deploy our Rails apps to it. It has good support for NodeJS too.
51. How much?
52. ~$240 USD a month Depends on how big your instances are and how much traffic you get.
53. @hughevans Any questions, just hit me up on Twitter.
54. hugh@icelab.com.au Or on my NSA hotline.
55. Thanks