cman does not use the openais.conf file at all. What it does do is load the values from CCS into
internal OpenAIS data structures that map onto the entries to openais.conf. So that's why you
can add an entry in a <totem> section in CCS and it will be used by totem. Refer to the
openais.conf(5) man page for the openaisspecific
So, those people who like to tweak heartbeat settings and suchlike, have some new concepts and
new CCS keys to learn!
Messaging ClustersA Messaging Cluster is a group of brokers that act as a single broker. Changes on any broker are replicated to all other brokers in the same Messaging Cluster, so if one broker fails, its clients can fail-over to another broker without loss of state. The brokers in a Messaging Cluster may run on the same host or on different hosts. Two brokers are in the same cluster if [*]They use the same OpenAIS mcastaddr, mcastport, and bindnetaddr, and
[*]They use the same cluster name.
Messaging Clusters are implemented using using OpenAIS, which provides a reliable multicast protocol, tools, and infrastructure for implementing replicated services. You must install and configure OpenAIS to use MRG broker groups. Once you have installed OpenAIS, configure MRG Messaging to run in a cluster as follows.
[*]Set the binding address for openais in /etc/ais/openais.conf. Use ifconfig to find the inet addr and the netmask for the interface you want:
# ifconfigeth0 Link encap:Ethernet HWaddr 00:E0:81:76:B6:C6 inet addr:10.16.44.222 Bcast:10.16.47.255 Mask:255.255.248.0 inet6 addr: fe80::2e0:81ff:fe76:b6c6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35914541 errors:6 dropped:0 overruns:0 frame:6 TX packets:6529841 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:20294124383 (18.9 GiB) TX bytes:12925473031 (12.0 GiB) Interrupt:98 Base address:0x8000The binding address in /etc/ais/openais.conf should be the network address for the interface, which you can find by doing a bitwise AND of the inet addr (in this case, 10.16.44.222) and the network mask (in this case, 255.255.248.0). The result is 10.16.40.0. As a sanity check, you can use route and make sure the address you computed is associated with the interface:
$ /sbin/routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface188.8.131.52 * 255.255.255.0 U 0 0 0 eth1192.168.122.0 * 255.255.255.0 U 0 0 0 virbr010.16.40.0 * 255.255.248.0 U 0 0 0 eth0169.254.0.0 * 255.255.0.0 U 0 0 0 eth1default 10.16.47.254 0.0.0.0 UG 0 0 0 eth0To use eth0 as the interface for the cluster, find the setting for bindnetaddr in /etc/ais/openais.conf, and set it to 10.16.40.0:
bindnetaddr: 10.16.40.0[*]Make sure that the primary group for the user running qpidd is 「ais」. For instance, if you are running qpidd as a daemon, the user is named qpidd. You can make ais the primary group for qpidd as follows:
# usermod -g ais qpidd[*]Set the name of the cluster in qpidd.conf.
cluster_name="Mick"[*]Use qpid-tool to see the cluster.
# qpid-tool localhost:5672The cluster is one of the objects shown by the list command.
qpid: listManagement Object Types:ObjectType Active Deleted====================================================com.redhat.rhm.store:journal 1 0com.redhat.rhm.store:store 1 0org.apache.qpid.broker:binding 5 0org.apache.qpid.broker:broker 1 0org.apache.qpid.broker:connection 1 0org.apache.qpid.broker:exchange 7 0org.apache.qpid.broker:queue 2 0org.apache.qpid.broker:session 1 0org.apache.qpid.broker:system 1 0org.apache.qpid.broker:vhost 1 0org.apache.qpid.cluster:cluster 1 0To see the properties of the cluster, use show cluster:
qpid: show clusterObject of type org.apache.qpid.cluster:cluster: (last sample time: 13:56:40)Type Element 112==================================================================================================property brokerRef 102property clusterName fooproperty clusterID da821ff9-2a88-4002-b976-f18680556290property publishedURL amqp:tcp:10.16.44.222:52265,tcp:184.108.40.206:52265,tcp:192.168.122.1:52265property clusterSize 1property status ACTIVEproperty members amqp:tcp:10.16.44.222:52265,tcp:220.127.116.11:52265,tcp:192.168.122.1:52265
Messaging Clusters can be used together with Red Hat Clustering Services (RHCS) by starting brokers with the --cluster-cman option.
FederationFederation is used to provide geographical distribution of brokers. A number of individual brokers, or clusters of brokers, can be federated together. This allows client machines to see and interact with the federation as though it were a single broker. Federation can also be used where client machines need to remain on a local network, even though their messages have to be routed out.
Federation is used primarily for connecting disparate locations across a wide area network. Full connectivity across an enterprise can be achieved while keeping local message traffic isolated to a single location. Departmental brokers can be specified with individual policies that control inter-departmental message traffic flow.
Some applications can benefit from having a broker co-resident with the client. This is good for situations where the client produces data that must be delivered reliably but connectivity can not be guaranteed. In this case, a co-resident broker provides queueing and durability that is not available in the client on its own.
Federation bridges disjointed IP networks. Message brokers can be configured to allow message connectivity between networks where there is no IP connectivity. For example, an isolated, private IP network can have messaging connectivity to brokers in other outside IP networks.
Links and routesFederation is configured through a series of links and routes.
A link is a connection between two brokers that allows messages to be passed between them. A link is a transport level connection (using a protocol such as TCP, RDMA, or SSL) that is initiated by a broker and accepted by another broker. The broker that initiates the link is considered the client in the connection. The broker that receives that connection will not treat it any differently from any other client connection, other than annotating it as being for federation.
Routes are the paths that messages take from one broker to another, and can run along one or more links to the final destination. A route is associated with an AMQP session established over the link connection. A route controls the flow of messages across the link between brokers, and multiple routes can share the same link. Messages will flow over a single route in only one direction. For bi-directional connectivity a pair of routes must be created, one for each direction of message flow. Routes always consist of a session and a subscription for consuming messages. Depending on the configuration, a route can have a private queue on the source broker with a binding to an exchange on that broker.
[ 本帖最後由 rainbow 於 2009-3-6 16:36 編輯 ]
回復 #3 rainbow 的帖子我在搜仲裁盤的時候看到如下描述：
發帖子的目的就是想弄明白，RHCS5的心跳到底從哪個網路走，我的客戶2個網卡做bonding提供publice networking ,另2個網卡做bonding提供private networking,fence設備是用HP的ilo設備，集群也做成功了，就是不太明白這個private networking是否是必須的，quorum 機制在2節點的集群用的人多不多？
回復 #6 jerrywjl 的帖子在A description of networking in Red Hat Cluster (http://sources.redhat.com/cluster/wiki/HomePage?action=AttachFile&do=get&target=CSNetworking.pdf)一文中提到：
cman tries hard to match the local host name(s) to those mentioned in cluster.conf. Here's how it does
1. It looks up $HOSTNAME in cluster.conf
2. If this fails it strips the domain name from $HOSTNAME and looks up that in cluster.conf
3. If this fails it looks in cluster.conf for a fully-qualified name whose short version matches the
short version of $HOSTNAME
4. If all this fails then it will search the interfaces list for an (ipv4 only) address that matches a
name in cluster.conf
cman will then bind to the address that it has matched.
回復 #8 jerrywjl 的帖子hostname命令得出的主機名，和/etc/hosts文件里的主機名肯定是一樣的啦
[火星人 via ] cman與openais已經有 次圍觀