[hydra-dev] * Fault Tolerance vs High availability

[Chris Tooley]

I know Veraz switches have automated media gateway failover (as well
as signaling and processing systems). The media gateways are not SIP
specific either, SS7 fails over channels as well as some other media
types. There are some things that can't be handled, but they are the
minority and not majority.

On Thu, Jun 3, 2010 at 10:37 AM, Ed Guy <edguy at eguy.org> wrote:
> Tim,
>
> I suspect portions of the competing system were fault tolerant, but
> I suspect the system as a whole wasnt. (OTOH, I could be wrong...
> but this a two beer bet.)
>
> Migrating calls by an administrative action is a bit different than full
> fault tolerance.
> This requirement makes a great deal of sense and perhaps could be
> implemented
> by sort of phased reinvite ( in sip terms)  under the direction of some
> session supervisor.
>
> e.g,
>
> initial:
> Alice    ---> CP30  -----> Bob
>  ( where CP30 is the audio relay/translator, etc, component  )
>
> intermediate
> Alice    ---> CP30    ---> CPD2  -----> Bob
> ( where CPD2 is the second audio relay/translator, etc, component)
>
> final
> Alice    ---> CPD2  -----> Bob
>
> /ed
>
>
> On 6/3/10 11:05 AM, Tim Panton wrote:
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
>



-- 

Chris Tooley
mobile: 615-525-8067
Instant Messenger
MSN: ctooley at ntrc.net
AIM: mrchristooley
Yahoo: mrchristooley
Google Talk: ctooley at gmail.com