火星人 @ 2014-03-04 , reply:0



但是在裡面看到的確實cman根本就不會使用openais.conf,它是從CCS內置的openais數據結構讀取參數值,並映射進openais.conf文件,因此,你可以在CCS里的<totem>部份添加條目並使用這個標誌,查閱openais.conf man手冊來獲得詳細的配置方法。

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
configuration keys.
So, those people who like to tweak heartbeat settings and suchlike, have some new concepts and
new CCS keys to learn!



紅帽的官方的文檔上是有的,如果沒有特殊的需要未必一定要使用rhcsChapter 6. Clustering and federation

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:  Bcast:  Mask:      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, and the network mask (in this case, The result is 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 Iface20.0.10.0     *     U     0      0     0 eth1192.168.122.0 *     U     0      0     0 virbr010.16.40.0    *     U     0      0     0 eth0169.254.0.0   *       U     0      0     0 eth1default        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
bindnetaddr:[*]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       1         1     5      1  1    7       2     1      1       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:,tcp:,tcp:  clusterSize   1property  status        ACTIVEproperty  members       amqp:tcp:,tcp:,tcp:
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 的帖子



3、cluster.conf里的節點名稱,必須是運行hostname命令所得到的主機名,那麼ccs_tool來做群集節點間的通訊和信息交換是否是依賴於hosts文件里所設置的主機名和對應的IP呢?如果是,那麼心跳信息不是全部從public網路走了嘛?集群管理手冊里硬體部份所需要的private網路僅僅是為了接Power switch?

發帖子的目的就是想弄明白,RHCS5的心跳到底從哪個網路走,我的客戶2個網卡做bonding提供publice networking ,另2個網卡做bonding提供private networking,fence設備是用HP的ilo設備,集群也做成功了,就是不太明白這個private networking是否是必須的,quorum 機制在2節點的集群用的人多不多?

原帖由 hbwangting 於 2009-3-6 11:20 發表

但是在裡面 ...


兩個節點用quorum disk沒有太大意義。

回復 #6 jerrywjl 的帖子

在A description of networking in Red Hat Cluster (一文中提到:
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 的帖子




[火星人 via ] cman與openais已經有250次圍觀