Friday, June 6, 2008

Re: Reliability in of the cloud

I have a better idea.

Start task 1, and start task 2 doing the same, but later, _not_
simultaneously. Cancel task 2, when you receive result from task 1.
Cancel task 1, when you receive the result from task 2.

The benefit is that task 2 will not spend the same amount of
time/CPU/resources, as task 1, when everything goes OK.

This will work only if cancelling tasks is supported. The timing of
starting task 2 is related to the amount of time you are prepared to
wait after the expected time of finishing task 1.


Sassa

2008/6/6 <ianrae@gmail.com>:
> Race them against each other and use the first result.
> Ian
>
> Ian Rae
> Syntenic Inc.
> 514-944-4008
>
> -----Original Message-----
> From: Alan Ho <karlunho@yahoo.ca>
>
> Date: Thu, 5 Jun 2008 17:41:47
> To:<cloud-computing@googlegroups.com>
> Subject: Reliability in of the cloud
>
>
> I guessed that about google app engine too.
>
> Things get really interesting when you need to do election leader decisions across data centers. E.g. If you are doing a big map-reduce task in one data center, it goes down, so you want to finish the task in another data center.
>
> How does one transfer the task ? Is it even worth solving ?
>
> Alan Ho
>
>
>
> ----------------
> From: Reuven Cohen <ruv@enomaly.com>
> Sent: June 05, 2008 10:03 AM
> To: cloud-computing@googlegroups.com
> Subject: Re: The Business of Building Clouds
>
> From what I've seen of Google App Engine, they distribute your python code to dozens of servers and then use some kind of round robin to spread the load. Nothing ground breaking.
>
> r/c
>
>
> On Thu, Jun 5, 2008 at 12:59 PM, wyim wyim <wingmanyim@hotmail.com <mailto:wingmanyim@hotmailcom> > wrote:
>
>
>
> In regards to failover, does Google App Engine have some sort of a LoadBalancer API?
>
> thanks
> Wayne Yim
>
>
>
> ----------------
> From: stuartcharlton@gmail.com <mailto:stuartcharlton@gmail.com>
>
> To: cloud-computing@googlegroups.com <mailto:cloud-computing@googlegroups.com>
>
> Subject: Re: The Business of Building Clouds
> Date: Thu, 5 Jun 2008 09:07:12 -0700
>
>
>
>
>
>
>
>
>
> On 5-Jun-08, at 8:35 AM, Alan Ho wrote:
>
> Picking a provider that has data center failover is critical - but it does mean that you write your application in a way that can failover gracefully. Cloud providers need to provide the base infrastructure to do so OR constrain the user to a particular programming paradigm (like the limitations of google app engine)
>
>
> That's a very astute observation, Alan. Constraining an architecture to induce certain properties (guarantees?) is likely the right approach.
>
>
> Though I wonder if AppEngine is a bit too "Nanny-ish" that limit its audience in ways that don't really impact the big picture qualities.
>
>
> For example, the choice of Python was easy because it was a standard Google language, but that doesn't seem to be inherently a more applicable language than say C#, Java or Ruby.
>
>
>
>
> I expect in the future that cloud computing systems will provide the concept of "cloud events" in case of major datacenter failures. I just don't see any way round it.
>
>
>
> I wonder if Google actually provides this sort of failover for AppEngine today. Certainly, they could, though they provide no such guarantees at the moment.
>
>
> As for "cloud events" - yup. In the traditional data centre, it's likely SNMP or JMX traps. On the cloud, it's not entirely clear if/where SNMP would play. Or WS-Man. Or something newer (?).
>
>
> Cheers
> Stu
>
>
>
>
>
>
>
>
> --
> --
>
> Reuven Cohen
> Founder & Chief Technologist, Enomaly Inc.
> www.enomaly.com <http://www.enomaly.com> :: 416 848 6036 x 1
> skype: ruv.net <http://ruv.net> // aol: ruv6
>
> blog > www.elasticvapor.com <http://wwwelasticvapor.com>
> -
> Get Linked in> http://linkedin.com/pub/0/b72/7b4 <http://linkedin.com/pub/0/b72/7b4>
>
>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---

No comments: