using virtual synchrony for CTDB
Tracy Camp
campt at openmars.com
Fri Oct 6 20:15:56 GMT 2006
I'm not sure we are talking about the same thing here at all... Wouldn't
some form of response be required within the GC layer to guarantee
delivery? I'm not familiar with the GC layer that you mentioned, but that
certainly seems to be the logical conclusion and implemented fact in
spread (which requires _two_ token rounds to deliver a guaranteed
message). Now if you don't care about delivery guarantees just message
ordering, certainly no response is necissary.
It is not clear that CTDB cares about message ordering at all (including
the reqid seems sufficient), so I'm not entirely sure what VS would
provide here except a way to know if a message was sent in the current
view of the cluster or not.
CTDB appears to want a semantic where every node is free to asynchronously
issue and handle messages without regard to other nodes issueing or
handling messages. The whole point of the DMASTER, LMASTER concepts
appears to avoid needing to broadcast state to every cluster member. I
can assure you that in large clusters this works out much better. VS
might provide a more elegant way to initiate recoveries than simply
relying on message timeouts (and broadcast message semantics in a recovery
are handy, though not necissary, since recovery is not unlike RAID-5
reconstruction).
Tracy Camp
On Fri, 6 Oct 2006, Steven Dake wrote:
> Tracey,
>
> If latency is an issue in messages, any message that has roundtrip
> response time over Ethernet medium will have higher latency then those
> messages that do not have round trip responses.
>
> If no response is required over Ethernet from the server before
> proceeding to do new operations, then ptp will have less latency then
> virtual synchrony.
>
> The performance problem that vs solves is removing the round trip
> response time, since every node has a copy of the data and can
> immediately handle the request and may continue processing as soon as
> the lock request is delivered (self-delivered) instead of waiting for a
> response from a server over TCP/IP or some other PTP protocol running
> over Ethernet.
>
> Regards
> -steve
>
> On Fri, 2006-10-06 at 11:09 -0700, Tracy Camp wrote:
>> Snake oil aside, 'DLM' like clustering schemes, which the CTDB proposal
>> seems like it could be grouped with, are best implemented with p-t-p
>> messages for the latency concerns already expressed. However also using a
>> VS group communications layer to provide a generation number than can then
>> be embedded in each P-T-P message provides P-T-P w/o the overhead of VS
>> for the latecy sensitive messages. Sort of a scheme that breaks the
>> 'control' apart from the 'data' transports.
>>
>> Tracy Camp
>>
>> On Fri, 6 Oct 2006, David Boreham wrote:
>>
>>> Steven Dake wrote:
>>>
>>>> I have a suggestion to use virtual synchrony for the transport mechanism
>>>> of CTDB. I think you will find using something like TCPIP unsuitable
>>>> for a variety of reasons.
>>>>
>>> I'm very far from being a VS expert, but when I looked into a few
>>> of the open source implementations available a while back it became
>>> clear (to me at least) that they have a kind of 'snake oil' property
>>> in that they appear to deliver magical services but do so only by
>>> using quite inefficient methods underneath the covers. For example
>>> it appears that one is avoiding network round-trips but in fact to implement
>>> its
>>> delivery guarantees the message middleware layer needs to propagate a token
>>> around the set of participating nodes which of course involves many sends and
>>> receives.
>>>
>>>
>>>
>>>
>>>
>>>
>
>
More information about the samba-technical
mailing list