Comments on: Designing applications for cloud deployment http://gojko.net/2010/01/25/designing-applications-for-cloud-deployment/ Building software that matters Sat, 31 Jul 2010 09:50:52 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ron Dovich http://gojko.net/2010/01/25/designing-applications-for-cloud-deployment/comment-page-1/#comment-72603 Ron Dovich Tue, 26 Jan 2010 13:30:53 +0000 http://gojko.net/?p=1581#comment-72603 Hi Gojko - Great post, thank you! I couldn't agree more with your points. As my company continues to build more applications in the cloud (for both our customers and internal use) we are also learning that it requires a much different way of thinking about the architecture. Ron Hi Gojko – Great post, thank you! I couldn’t agree more with your points. As my company continues to build more applications in the cloud (for both our customers and internal use) we are also learning that it requires a much different way of thinking about the architecture.

Ron

]]> By: Owen Garrett http://gojko.net/2010/01/25/designing-applications-for-cloud-deployment/comment-page-1/#comment-72522 Owen Garrett Mon, 25 Jan 2010 18:05:21 +0000 http://gojko.net/?p=1581#comment-72522 Hi Gojko - that's a great article, good points well made. I might have been the guy (from Zeus) you refer to who spoke about putting load balancing software on the cloud! You're exactly right - the virtual machine running the load balancer is no more reliable than the ones running the webservers etc, and I/O constraints apply to the load balancer just as they do to other virtual machines. For this reason, Zeus software has measures in place to handle the failure of individual load balancing machines. For example, on EC2 you would normally deploy a pair of Zeus Traffic Managers; they would run in active-passive mode, sharing an Elastic IP between them. If the active device were to fail, the passive one would request that the Elastic IP is moved across. Failure detection takes a couple of seconds; there are frequent heartbeats and connectivity tests, and we allow for several seconds (tunable) before initiating the failover. Once the remaining machine instructs EC2 to transfer the Elastic IP, it typically takes the EC2 network about 20-30 seconds to reassign the IP; then the service is restored. If you need more network capacity than a single Amazon instance can handle, you can deploy a cluster of /N/ Zeus Traffic Managers, sharing /M/ elastic IPs. This will give you the aggregate capacity of /M/ amazon instances (each instance will take one elastic IP, with the remaining /N-M/ instances running passive). Use round-robin DNS (for example) to distribute traffic across the /M/ elastic IPs. regards Owen Hi Gojko – that’s a great article, good points well made.

I might have been the guy (from Zeus) you refer to who spoke about putting load balancing software on the cloud! You’re exactly right – the virtual machine running the load balancer is no more reliable than the ones running the webservers etc, and I/O constraints apply to the load balancer just as they do to other virtual machines.

For this reason, Zeus software has measures in place to handle the failure of individual load balancing machines. For example, on EC2 you would normally deploy a pair of Zeus Traffic Managers; they would run in active-passive mode, sharing an Elastic IP between them. If the active device were to fail, the passive one would request that the Elastic IP is moved across.

Failure detection takes a couple of seconds; there are frequent heartbeats and connectivity tests, and we allow for several seconds (tunable) before initiating the failover. Once the remaining machine instructs EC2 to transfer the Elastic IP, it typically takes the EC2 network about 20-30 seconds to reassign the IP; then the service is restored.

If you need more network capacity than a single Amazon instance can handle, you can deploy a cluster of /N/ Zeus Traffic Managers, sharing /M/ elastic IPs. This will give you the aggregate capacity of /M/ amazon instances (each instance will take one elastic IP, with the remaining /N-M/ instances running passive). Use round-robin DNS (for example) to distribute traffic across the /M/ elastic IPs.

regards

Owen

]]>