William Reich wrote: > > >> William Reich pisze: >>> Hello all... >>> >>> I have two machines that are in a Sun Cluster configuration. >>> In this configuration, I have two private LANs that are managed by >>> the Sun Cluster software. >>> >>> I have been able to successfully establish UDP connections over the >>> same LANs that are used by SUN CLUSTER. >>> by using the correct LAN names. >>> ( for example : clusternode1-priv-physical1 and >>> clusternode1-priv-physical2 ) >>> >>> I am now trying to establish SCTP connections over the same LANs that > >>> are used by SUN CLUSTER. >>> >>> Can anyone confirm whether or not it is allowed to establish SCTP >>> connections over the same LANs that are used by SUN CLUSTER? >>> ( My first attempts to do so have not been successful... ) >>> > >> William, >> >> SCTP connections are not allowed over the cluster private interconnect > because the >> protocol is not used by the cluster infrastructure, or any known agents > or utilities. The >SCTP packets are explicitly dropped. >> You can, of course, create SCTP connections between nodes over the > public network. > >> Can you give a bit more detail about your configuration? Are you > writing a cluster agent >that would like to use SCTP to communicate > between nodes? > >> Thanks, >> Nick > > > In this configuration, there are two sparc machines connected together > with > two private LANs. For the purposes of this discussion, you can think > of one machine as ACTIVE and the other as STANDBY. The two machines > will to stay in sync so that when the ACTIVE fails, the STANDBY can pick > up. > The applications on each machine are setup to accomodate this idea. > So, to stay in sync, the machines/applications send messages back and > forth to > each other. > > Now, in a normal deployment, everything is very generic. The > traffic over the private LANs is UDP. > > BUT, now there is a feature enhancement to convert the UDP traffic to > SCTP since SCTP is more reliable than UDP ( and our own home-grown > protocol that was placed over top of UDP ). > > So, everything is working fine with the SCTP. > > Now the issue - we have this one customer that is using SunCluster with > the > above configuration. After working with SUN previously, we were able to > get "our" UDP traffic used for machine sync to travel over > the private LANs used by SunCluster. The customer has been using this > for several years now.
Let me point out one key property of the SunCluster private interconnect: it "gangs together" the two physical LANs into a single IP address that is reliable. Sun Cluster monitors the two physical LANs and decides which one(s) are up and working. Traffic is directed across the working LAN. Thus the private inteconnect presents the abstraction of a single IP address that is reliable. But, as you have seen, this address only allows certain particular protocols. Our motivation for that is basicly security concerns for the private interconnect, that we have adopted a model that everything not specifically allowed is forbidden. There is a window here where UDP packets could be dropped whilst SC figures out that a physical LAN is no longer working, but, once SC does the switch to the other physical LAN underneath the covers, the packets will flow again. TCP will of course be reliable, because TCP has retransmission built in. I am mentioning all of this because there is a possibility that continuing to use UDP over the Sun Cluster interconnect will meet your requirements. That of course is your call. See other comments below... > > So, as you would expect, we have/want to bring our SCTP enhancement to > this customer that wants to use SunCluster. > Therefore, we need to get our SCTP traffic to traverse the private > SunCluster LANs. > ( In general, the configuration has two private LANs between the > machines. > We don't want to tell the customer that four private LANs are needed > just > because the customer wants to use SunCluster. ) > > Investigation reveals that the solaris kernel call > sctp_get_opt() with options SCTP_GET_NLADDRS and/or SCTP_GET_LADDRS > returns information that does not include the SunCluster private LANs. > > Interestingly, if the sctp_get_opt() calls are ignored ( by hacking ), > the sctp sockets that are needed can be created, and everything > that is required seems to work ( the SCTP traffic travels nicely over > the SunCluster private LANs) . I assume what you mean here is the two physical LAN ip addresses, and not the IP address that is implemented by the Sun Cluster private interconnect software layer. One possibility is to create additional software in your product that allows the IP addresses used by your code to be configurable by your customer, and to by convention require the customer admin to configure the two physical LAN ip addresses (four total) when SC is present. Off the top of my head, I do not have a better answer. > comments ? > > thanks > > wr > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss -- Email: Andrew.Hisgen at sun.com
