New virtual synchrony API for the kernel: was Re: [Openais] New API in openais

From: Steven Dake (sdake_at_mvista.com)
Date: 08/31/04

  • Next message: V13: "Re: PATCH: Root reservations for strict overcommit"
    To: John Cherry <cherry@osdl.org>
    Date:	Tue, 31 Aug 2004 12:50:43 -0700
    
    

    John,
    As it appears the redhat clusters project is interested in a kernel
    implementation of cluster messaging, this interface would have to be
    available to both the kernel and user applications. It possible to
    provide EVS services to both kernel and user space applications. There
    currently is no kernel implementation of group messaging, though only a
    user space interface. TIPC could probably export this sort of
    interface, or openais's gmi could be ported to the kernel. Then
    openais, redhat's cluster technologies, linux ha, or other group
    messaging applications (and there are quite a few) could use that
    technology and standardize on the EVS API.

    It would be useful for linux cluster developers for a common low level
    group communication API to be agreed upon by relevant clusters
    projects. Without this approach, we may end up with several systems all
    using different cluster communication & membership mechanisms that are
    incompatible.

    Thanks
    -steve

    On Tue, 2004-08-31 at 10:35, John Cherry wrote:
    > Steve,
    >
    > This sounds like a low level cluster communication service which would
    > be potentially leveraged by other services, such as the event service or
    > a group messaging service. Are you envisioning this to be a public
    > interface for applications?
    >
    > We discussed a low level cluster communication interface at the cluster
    > summit. The rhat/sistina interface would be used by the cluster manager
    > (CMAN) and the lock manager (GDLM), but there was no real momentum to
    > make this a public application interface. It would be great if we could
    > derive a common cluster communication interface with the rhat/sistina
    > project as well as the TIPC project. What do you think?
    >
    > John
    >
    >
    > On Tue, 2004-08-31 at 01:31, Steven Dake wrote:
    > > Folks
    > >
    > > Its with alot of pleasure that I announce a new API that I implemented
    > > over the weekend.
    > >
    > > The api is called the "EVS" API and is provided by a seperate library
    > > libevs.so/.a. The standard openais executive is used. There are two
    > > test programs testevs and evsbench which demonstrate the API. evsbench
    > > will benchmark throughput rates. I get about 9MB/sec on my hardware,
    > > however, flow control in the group messaging protocol is slowing this
    > > down. I've gotten 10MB/sec with tweaking the algorithm some.
    > >
    > > The API name EVS means "Extended Virtual Syncrhony". This API provides
    > > EVS semantics for those that require the guarantees provided in the face
    > > of partitions and merges.
    > >
    > > The API provides the following
    > > multiple instances may exist at one time
    > > group keys of 32 bytes
    > > an instance may join one or more groups at one time
    > > an instance may leave one or more groups at one time
    > > an instance may multicast to the currently joined groups
    > > an instance may multicast to unjoined groups
    > > any message for a joined group will be delivered via callback
    > > configuration changes are delivered via callback
    > >
    > > Your comments welcome
    > >
    > > Thanks
    > > -steve
    > >
    > >
    > > ______________________________________________________________________
    > > _______________________________________________
    > > Openais mailing list
    > > Openais@lists.osdl.org
    > > http://lists.osdl.org/mailman/listinfo/openais
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: V13: "Re: PATCH: Root reservations for strict overcommit"

    Relevant Pages

    • Re: [PATCH 0/7] dlm: overview
      ... > aren't just unique within a single cluster (think clusters of clusters, ... How the configuration gets from the config file to kernel is a mystery to me ... By a message over a socket, ... Let's have no magical filesystems in the core interface please. ...
      (Linux-Kernel)
    • Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30
      ... security faults in the protocol can crash the kernel or violate ... cluster services for the kernel and cluster services for applications ... interface specification) utilizes redundant software components using ... failover, checkpointing, eventing, messaging, and distributed locks. ...
      (Linux-Kernel)
    • Re: Failover on public network failiure?
      ... There are a number of ways the cluster service checks the state of the ... If the network interface is determined to be failed then any ... the IP address on the current node the groupwill failover to another ...
      (microsoft.public.windows.server.clustering)
    • Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30
      ... >> in such a way as to ever cause memory overload. ... As soon as you have proved that cman's cluster protocol cannot be the ... target of attacks which lead to kernel faults or security faults.. ... There are userland implementations under way which will meet these ...
      (Linux-Kernel)
    • Re: [PATCH 0/7] dlm: overview
      ... the API. ... "How is the kernel component ... for the cluster stack, if you so please. ... This places the boundary in user-space. ...
      (Linux-Kernel)