[Pacemaker] Multiple independent two-node clusters side-by-side?

[Dan Frincu]

Hi,

Vadym Chepkov wrote:
> On Oct 28, 2010, at 2:53 AM, Dan Frincu wrote:
>
>   
>> Hi,
>>
>> Andreas Ntaflos wrote:
>>     
>>> Hi, 
>>>
>>> first time poster, short time Pacemaker user. I don't think this is a 
>>> very difficult question to answer but I seem to be feeding Google the 
>>> wrong search terms. I am using Pacemaker 1.0.8 and Corosync 1.2.0 on 
>>> Ubuntu 10.04.1 Server.
>>>
>>> Short version: How do I configure multiple independent two-node clusters 
>>> where the nodes are all on the same subnet? Only the two nodes that form 
>>> the cluster should see that cluster's resources and not any other. 
>>>
>>> Is this possible? Where should I look for more and detailed information?
>>>   
>>>       
>> You need to specify different multicast sockets for this to work. Under the /etc/corosync/corosync.conf you have the interface statements. Even if all servers are in the same subnet, you can "split them apart" by defining unique multicast sockets.
>> An example should be useful. Let's say that you have only one interface statement in the corosync file.
>>         interface {
>>                 ringnumber: 0
>>                 bindnetaddr: 192.168.1.0 
>>                 mcastaddr: 239.192.168.1 
>>                 mcastport: 5405 
>>         }
>> The multicast socket in this case is 239.192.168.1:5405. All nodes that should be in the same cluster should use the same multicast socket. In your case, the first two nodes should use the same multicast socket. How about the other two nodes? Use another unique multicast socket.
>>         interface {
>>                 ringnumber: 0
>>                 bindnetaddr: 192.168.1.0 
>>                 mcastaddr: 239.192.168.112 
>>                 mcastport: 5405 
>>         }
>> Now the multicast socket is 239.192.168.112:5405. It's unique, the network address is the same, but you add this config (edit according to your environment, this is just an example) to your other two nodes. So you have cluster1 formed out of node1 and node2 linked to 239.192.168.1:5405 and cluster2 formed out of node3 and node4 linked to 239.192.168.112:5405.
>>
>> This way, the clusters don't _see_ each other, so you can reuse the resource ID's and see only two nodes per cluster.
>>     
>
>
> Out of curiosity, RFC2365 defines "local scope" multicast space 239.255.0.0/16 and "organizational local scope" 239.192.0.0/14.
>
> Seems most examples for pacemaker cluster use later. But since most clusters are not spread across different subnets, wouldn't it be more appropriate to use the former?
>
> Thanks,
> Vadym
>
>   
You do realize that 239.0.0.0/8 has the same general purpose as RFC1918, 
only it references multicast addresses instead. Basically general 
guidelines dictate usage of 239.255.0.0/16 locally scoped address range 
(e.g.: all nodes are in the same general location, such as a building), 
but this just as saying use 192.168.0.0/16 instead of 10.0.0.0/16. It 
really boils down to the network engineer's choice of addressing, either 
solution works, but this kind of an elaborate multicast addressing 
scheme design implies also a large number of nodes in many locations, 
all under the same general administration.

Thinking that for each 2 node cluster with one communication channel you 
need one multicast address, and that you can put many nodes in the same 
cluster (where such should arise), the number of multicast addresses is 
usually small, so it makes little difference whether you choose from a 
2^16 range or from a 2^24 range of multicast addresses.

Going to another level with this, imagine your using vlan's for each 
cluster, all of a sudden, you can use the same multicast address :)

The main concern in this case should pertain less to the addressing 
scheme and more to the interconnecting devices' support for multicast.

Just my 2 cents.

Regards,

Dan
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>   

-- 
Dan FRINCU
Systems Engineer
CCNA, RHCE
Streamwide Romania

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20101029/523a1b2f/attachment-0002.htm>