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@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
_______________________________________________
Pacemaker mailing list: Pacemaker@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
