SlideShare a Scribd company logo

High availability

•
•
W
WO Community

The document discusses various strategies for achieving high availability of web applications and databases. It covers evaluating business requirements, DNS configuration, using cloud infrastructure or owning hardware, basic setups with application and database servers, database replication and clustering options, load balancing tools for Linux and cloud environments, auto scaling features, and monitoring. The key strategies presented include replicating databases, load balancing web traffic, auto-scaling cloud resources, and configuring failover between redundant application and database servers.

1 of 26
Download to read offline
High Availability Pascal Robert Druide informatique
Business requirements • Check your requirements! • Recovery Time Objective (RTO) • Recovery Point Objective (RPO) • Budget • SLA from your providers
DNS • Think about it! • Use a solid DNS provider! • TTL!
Cloud or my own? • Cloud is more flexible and more scalable on demand • Easy grow with the cloud • Own hardware might cost less • Choose your provider wisely (read the fine prints!) • Snapshots!
Simple setup • One Web server + one or more app servers + one db server • Pros: • Cost is not too high • Scales your WO applications • Cons: • No high availability for your Web and database services
HA for databases • Replication/standby • Only failover, or read-only slaves • Great for multi locations • Clustering/load balancing • Might have some drawbacks • Not ideal for multi locations • Amazon RDS
Replication/clustering doesn’t replace backups!! ! Neither RAID!
Tools for the job
Tools for Linux • Heartbeat • HAProxy • DRBD
Heartbeat • Can mounts a virtual network interface • Monitor services and switch over • Failover or load balancing
HAProxy • Load balancer as software • Can use Heartbeat for LB failover • Can look for session ID in cookie or url path • Can act as basic firewall • Not only for HTTP(S)
DRBD • RAID 1 over a network • Failover or clustering, depends on file system
Basic HA setup • Two Web/apps servers with Heartbeat (active/passive) • Two database servers and Heartbeat and DRBD
Average HA setup • Two Web servers with Heartbeat • Two app servers with Heartbeat (for Monitor) • Two database servers and Heartbeat and DRBD
Fantastic HA setup • Two load balancers with HAProxy and Heatbeat • Two active Web servers • Two or more app servers • Two database servers, with Heartbeat and DRBD
Tools for the cloud • Auto scaling • RackSpace Auto Scale • Amazon Auto Scaling • Load balancers • Amazon Elastic Load Balancer • Linode NodeBalancers • Rackspace Cloud Load Balancers
Rackspace Auto Scale • Can check by memory, CPU, load, file system and network • Have APIs • NeedVM images • Specify minimum and maximum
Amazon Auto Scaling • Works with Cloud Watch • Will scale based on network requests or load • Needs AMIs • Have APIs • Specify minimum and maximum
Amazon Elastic Load Balancer • Supports TCP, HTTP, HTTPS and SSL • Can check path (URL) • Can load balance between regions • Integration with CloudWatch • Can use the application’s session cookie (wosid)
Linode Node Balancers • Supports TCP, HTTP and HTTPS • Session Stickiness works with tables of IPs or HTTP cookie • Health check can do a status (2xx, 3xx) check or regex on body
Rackspace Cloud Load Balancers • Can cache content (images, audio, video, css) • Can display error page when all nodes are down • Session persistence by cookie for http only • Required for Auto Scale
Mixing • You can use HAProxy and heartbeat in the cloud • DRBD might work, but I can’t confirm
Monitoring/relaunch • You can use Nagios’ event handlers to restart stuck instances • Amazon Cloud Watch and Rack monitoring are good too • Start new app instances orVMs based on memory or other criteria
Alternatives • Use mod_proxy_balancer and Direct Connect • Use Puppet/Chef
TODOs • Scripts to monitor state of apps for scaling • Event handlers for Nagios • Replace JavaMonitor with something else • Should we get away from wotaskd and the WO adaptor?
Q&A

More Related Content

High availability

  • 2. Business requirements • Check your requirements! • Recovery Time Objective (RTO) • Recovery Point Objective (RPO) • Budget • SLA from your providers
  • 3. DNS • Think about it! • Use a solid DNS provider! • TTL!
  • 4. Cloud or my own? • Cloud is more flexible and more scalable on demand • Easy grow with the cloud • Own hardware might cost less • Choose your provider wisely (read the fine prints!) • Snapshots!
  • 5. Simple setup • One Web server + one or more app servers + one db server • Pros: • Cost is not too high • Scales your WO applications • Cons: • No high availability for your Web and database services
  • 6. HA for databases • Replication/standby • Only failover, or read-only slaves • Great for multi locations • Clustering/load balancing • Might have some drawbacks • Not ideal for multi locations • Amazon RDS
  • 9. Tools for Linux • Heartbeat • HAProxy • DRBD
  • 10. Heartbeat • Can mounts a virtual network interface • Monitor services and switch over • Failover or load balancing
  • 11. HAProxy • Load balancer as software • Can use Heartbeat for LB failover • Can look for session ID in cookie or url path • Can act as basic firewall • Not only for HTTP(S)
  • 12. DRBD • RAID 1 over a network • Failover or clustering, depends on file system
  • 13. Basic HA setup • Two Web/apps servers with Heartbeat (active/passive) • Two database servers and Heartbeat and DRBD
  • 14. Average HA setup • Two Web servers with Heartbeat • Two app servers with Heartbeat (for Monitor) • Two database servers and Heartbeat and DRBD
  • 15. Fantastic HA setup • Two load balancers with HAProxy and Heatbeat • Two active Web servers • Two or more app servers • Two database servers, with Heartbeat and DRBD
  • 16. Tools for the cloud • Auto scaling • RackSpace Auto Scale • Amazon Auto Scaling • Load balancers • Amazon Elastic Load Balancer • Linode NodeBalancers • Rackspace Cloud Load Balancers
  • 17. Rackspace Auto Scale • Can check by memory, CPU, load, file system and network • Have APIs • NeedVM images • Specify minimum and maximum
  • 18. Amazon Auto Scaling • Works with Cloud Watch • Will scale based on network requests or load • Needs AMIs • Have APIs • Specify minimum and maximum
  • 19. Amazon Elastic Load Balancer • Supports TCP, HTTP, HTTPS and SSL • Can check path (URL) • Can load balance between regions • Integration with CloudWatch • Can use the application’s session cookie (wosid)
  • 20. Linode Node Balancers • Supports TCP, HTTP and HTTPS • Session Stickiness works with tables of IPs or HTTP cookie • Health check can do a status (2xx, 3xx) check or regex on body
  • 21. Rackspace Cloud Load Balancers • Can cache content (images, audio, video, css) • Can display error page when all nodes are down • Session persistence by cookie for http only • Required for Auto Scale
  • 22. Mixing • You can use HAProxy and heartbeat in the cloud • DRBD might work, but I can’t confirm
  • 23. Monitoring/relaunch • You can use Nagios’ event handlers to restart stuck instances • Amazon Cloud Watch and Rack monitoring are good too • Start new app instances orVMs based on memory or other criteria
  • 24. Alternatives • Use mod_proxy_balancer and Direct Connect • Use Puppet/Chef
  • 25. TODOs • Scripts to monitor state of apps for scaling • Event handlers for Nagios • Replace JavaMonitor with something else • Should we get away from wotaskd and the WO adaptor?
  • 26. Q&A