[prev in list] [next in list] [prev in thread] [next in thread]
List: openais
Subject: Re: [Openais] [Corosync] Using TCP as a transport?
From: Alan Jones <falancluster () gmail ! com>
Date: 2010-02-22 20:55:52
Message-ID: 8269142d1002221255h57469d82o45978423c2564d37 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
This is what I'm looking for. If my team wants this I'll get back
to you such that we can build it to your specifications.
Alan
On Mon, Feb 22, 2010 at 9:45 AM, Steven Dake <sdake@redhat.com> wrote:
> We are kicking around the idea of a new transport mode called "udpu".
> Instead of requiring multicast, if a node needs to multicast, it will
> send a unconnected datagram UDP message to all nodes in the
> configuration. In this model, the user would specify a list of nodes
> that "could be" cluster members (rather then a multicast address and
> port).
>
> The advantage of this model is that it doesn't depend on multicast
> configuration by the network admins, etc. The disadvantage is that it
> would far less performant since the reason totem performs so well is
> that it depends on switch hardware to perform copies to each node rather
> then relying on the operating system to do that work.
>
> Regards
> -steve
>
> On Mon, 2010-02-22 at 10:45 -0700, hj lee wrote:
> > Hi,
> >
> > Currently I use TCP only for token transmit in operational mode. The
> > UDP is still used same as before in all other modes and also for
> > multicast messages. So the change for this work is minimal and most
> > changes are in udp layer. Using TCP completely will require more work
> > and bigger changes.
> >
> > hj
> >
> > On Fri, Feb 19, 2010 at 11:25 AM, Alan Jones <falancluster@gmail.com>
> > wrote:
> > The solution I would like to consider is configuring a list of
> > static peer addresses without
> > multicast. To that end I would like to evaluate HJ's patch
> > for using TCP.
> > It is not one cluster admin that I would have to train, but a
> > potential large number of
> > customers for a product. From the customer's prospective my
> > product will already
> > introduce an "extra" floating regular IP. If we ask for a
> > multicast address and port as
> > well I fear the product may be perceived as too complex,
> > particularly for a customer that
> > intends to deploy a large number of small clusters.
> > Alan
> >
> >
> >
> > On Thu, Feb 18, 2010 at 10:21 PM, Steven Dake
> > <sdake@redhat.com> wrote:
> > Totem as is implemented in corosync is not designed
> > for large scale
> > rejection of messages because administrators want
> > unique clusters on the
> > same multicast address and port. Corosync will have
> > very poor
> > performance characteristics in this model and spew a
> > ton of warnings and
> > also not scale particularly well. Best to get the
> > cluster admin to
> > configure the cluster's ports.
> >
> > I really cannot recommend at all using the secure key
> > to uniquely
> > identify clusters.
> >
> > Regards
> > -steve
> >
> >
> > > Requiring the user to configure each cluster's
> > membership is less
> > > onerous and is
> > > required for other components of my solution.
> > > Can you forward your patch for TCP?
> > > Alan
> > >
> >
> >
> >
> > --
> > Peakpoint Service
> >
> > Cluster Setup, Troubleshooting & Development
> > kerdosa@gmail.com
> > (303) 997-2823
>
>
[Attachment #5 (text/html)]
This is what I'm looking for. If my team wants this I'll get back<br>to you \
such that we can build it to your specifications.<br>Alan<br><br><div \
class="gmail_quote">On Mon, Feb 22, 2010 at 9:45 AM, Steven Dake <span \
dir="ltr"><<a href="mailto:sdake@redhat.com">sdake@redhat.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We are kicking around the \
idea of a new transport mode called "udpu".<br> Instead of requiring \
multicast, if a node needs to multicast, it will<br> send a unconnected datagram UDP \
message to all nodes in the<br> configuration. In this model, the user would specify \
a list of nodes<br> that "could be" cluster members (rather then a \
multicast address and<br> port).<br>
<br>
The advantage of this model is that it doesn't depend on multicast<br>
configuration by the network admins, etc. The disadvantage is that it<br>
would far less performant since the reason totem performs so well is<br>
that it depends on switch hardware to perform copies to each node rather<br>
then relying on the operating system to do that work.<br>
<br>
Regards<br>
-steve<br>
<div><div></div><div class="h5"><br>
On Mon, 2010-02-22 at 10:45 -0700, hj lee wrote:<br>
> Hi,<br>
><br>
> Currently I use TCP only for token transmit in operational mode. The<br>
> UDP is still used same as before in all other modes and also for<br>
> multicast messages. So the change for this work is minimal and most<br>
> changes are in udp layer. Using TCP completely will require more work<br>
> and bigger changes.<br>
><br>
> hj<br>
><br>
> On Fri, Feb 19, 2010 at 11:25 AM, Alan Jones <<a \
href="mailto:falancluster@gmail.com">falancluster@gmail.com</a>><br> > \
wrote:<br> > The solution I would like to consider is configuring a list \
of<br> > static peer addresses without<br>
> multicast. To that end I would like to evaluate HJ's patch<br>
> for using TCP.<br>
> It is not one cluster admin that I would have to train, but a<br>
> potential large number of<br>
> customers for a product. From the customer's prospective my<br>
> product will already<br>
> introduce an "extra" floating regular IP. If we ask for a<br>
> multicast address and port as<br>
> well I fear the product may be perceived as too complex,<br>
> particularly for a customer that<br>
> intends to deploy a large number of small clusters.<br>
> Alan<br>
><br>
><br>
><br>
> On Thu, Feb 18, 2010 at 10:21 PM, Steven Dake<br>
> <<a href="mailto:sdake@redhat.com">sdake@redhat.com</a>> \
wrote:<br> > Totem as is implemented in corosync is not \
designed<br> > for large scale<br>
> rejection of messages because administrators want<br>
> unique clusters on the<br>
> same multicast address and port. Corosync will have<br>
> very poor<br>
> performance characteristics in this model and spew a<br>
> ton of warnings and<br>
> also not scale particularly well. Best to get the<br>
> cluster admin to<br>
> configure the cluster's ports.<br>
><br>
> I really cannot recommend at all using the secure key<br>
> to uniquely<br>
> identify clusters.<br>
><br>
> Regards<br>
> -steve<br>
><br>
><br>
> > Requiring the user to configure each cluster's<br>
> membership is less<br>
> > onerous and is<br>
> > required for other components of my solution.<br>
> > Can you forward your patch for TCP?<br>
> > Alan<br>
> ><br>
><br>
><br>
><br>
> --<br>
> Peakpoint Service<br>
><br>
> Cluster Setup, Troubleshooting & Development<br>
> <a href="mailto:kerdosa@gmail.com">kerdosa@gmail.com</a><br>
> (303) 997-2823<br>
<br>
</div></div></blockquote></div><br>
_______________________________________________
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic