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 <[email protected]> > 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 > <[email protected]> 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 > [email protected] > (303) 997-2823 _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
