[hydra-dev] * Fault Tolerance vs High availability

[Tim Panton]

I was one of the people who advocated support for fail-over of live calls.
I had 2 reasons:
	1) We had a consultancy job for a 'blue lamp' service (police/fire/etc) where it was  
a requirement so asterisk was rejected. I feel the Hydra should be aiming to solve
problems that asterisk can't.
	2) If Hydra's natural habitat is the cloud, then the ability to migrate live calls
will be very handy. Imagine the case where you rolled out 100 instances
to cope with a traffic spike. Once the spike is over, you can't shut down the
instances until all the longer calls have finished. What you'd like is to migrate the
stragglers to a couple of instances and shut everything else down.

T.

On 3 Jun 2010, at 15:44, Malcolm C. Davenport wrote:

> Howdy,
> 
> When this sort behavior was first discussed internally, the conclusion was that we didn't want to make decisions that would preclude our ability to provide this kind of capability.  
> 
> It seemed to the participants in that discussion that the ability to actively migration of a call from one component to another without interruption (significant, like the dropping of a call, perhaps more so than just an audio artifact or silence) would be highly valued.  Were we placing too much emphasis on something that's too esoteric?
> 
> Cheers.
> 
> ----- Original Message -----
>> Hydrates,
>> 
>> During the meeting a couple months ago,
>> 
>> there was considerable discussion about fault-tolerance.
>> 
>> In my book, Fault tolerance implies that if there is a system failure
>> on a component that involves an active call, the call is migrated,
>> without significant
>> interruption, to another component.
>> 
>> is this really a requirement??? Most carrier grade systems merely
>> require high availability. i.e., if a
>> component fails, a call may drop, but the next call must go through. (
>> "fives-nines" or better of the time )
>> 
>> Fault tolerant architectures are very expensive and inefficient, but,
>> sometimes you cant afford any failure.
>> 
>> 
>> /ed
>> 
>> 
>> _______________________________________________ Project Hydra
>> Development Discussion List
>> NOTE: All content you receive from this list is should be treated as
>> confidential.
>> 
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/hydra-dev
> 
> -- 
> --------------------------------------------------
> Malcolm Davenport
> Digium, Inc. | Senior Product Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Tel: +1 256 428 6252
> Fax: +1 256 864 0464
> malcolmd at digium.com
> 
> 
> _______________________________________________
> Project Hydra Development Discussion List
> NOTE: All content you receive from this list is should be treated as confidential.
> 
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/hydra-dev

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk