RHCs Principle and operation
RHCs Component Description:
1.1 Distributed Cluster Manager (CMAN)
Cluster Manager, referred to as Cman, is a distributed cluster management tool that runs on each node of the cluster and provides cluster management tasks for RHCS. Cman is used to manage cluster members, messages, and notifications. It is through monitoring the running state of each node to understand the relationship between node members, when a node in the cluster fails, the node member relationship will change, Cman timely notice the change to the bottom, and then make corresponding adjustments.
1.2 Lock Management (DLM)
Distributed lock manager, referred to as DLM, represents a distributed lock manager, which is a basic component of RHCS and provides a common locking mechanism for the cluster, in which the DLM runs on each node of the cluster in the RHCs cluster system. GFS accesses file system metadata synchronously through the lock mechanism of the lock manager. CLVM synchronizes update data to LVM volumes and volume groups through the lock manager. DLM does not need to set the lock Management Server, it adopts the equivalent lock management mode, greatly improves the processing performance. At the same time, DLM avoids a performance bottleneck that requires overall recovery when a single node fails, and the DLM request is local and does not require a network request, so the request takes effect immediately. Finally, DLM can implement the parallel lock mode of multiple lock spaces through the layered mechanism.
1.3 Configuration file Management (CCS)
Cluster configuration System, referred to as CCS, is primarily used for cluster configuration file management and synchronization of configuration files between nodes. CCS runs on each node of the cluster, monitoring the state of the single profile/etc/cluster/cluster.conf on each cluster node, updating the change to each node in the cluster whenever the file changes, keeping the profile of each node synchronized at all times. For example, the administrator updates the cluster configuration file on Node A, and when CCS discovers that a node's configuration file changes, the change is propagated to the other nodes immediately. The RHCs configuration file is cluster.conf, which is an XML file that contains the cluster name, cluster node information, cluster resources and service information, fence device, and so on.
1.4 Grid equipment (FENCE)
Fence equipment is an essential part of the RHCS cluster, through the fence device can avoid the unpredictable situation caused by the "brain crack" phenomenon, fence equipment, is to solve similar problems, Fence equipment is mainly through the server or storage itself hardware management interface, or external power management device, to the server or storage directly issued hardware management instructions, the server restart or shutdown, or disconnected from the network. Fence working principle is: when the unexpected cause of the host exception or downtime, the opportunity to first call the fence device, and then through the fence device to restart the exception host or from the network isolation, when the fence operation successfully executed, the return of information to the standby machine, after receiving the fence successful information, Start taking over the services and resources of the host. This frees up the resources occupied by the exception node through the fence device, ensuring that the resources and services are always running on a single node. RHCs's fence devices can be divided into two types: internal fence and external fence, common internal fence with IBM Rsaii cards, HP's ILO cards, and IPMI devices, and external fence devices with UPS, SAN SWITCH, NETWORK Switch, etc.
RHCs Operation:
First, start RHCs cluster
RHCS Cluster core process has Cman and Rgmanager, to start the cluster, in turn, each node in the cluster execute the following command:
Service Cman Start
Service Rgmanager Start
It is important to note that the execution of these two commands is sequential and requires starting Cman first and then starting Rgmanager. After all nodes of the cluster have successfully started the Cman service, then continue to start the Rgmanager service on each node in turn.
Second, close the RHCs cluster
Just as opposed to starting the Cluster service, the command to close the RHCs cluster is:
Service Rgmanager Stop
Service Cman Stop
The entire Cluster service can be shut down by shutting down the Rgmanager service in turn each node in the cluster, waiting for the Rgmanager service of all nodes to shut down successfully, and then closing each node's Cman service in turn.
Sometimes when you turn off the Cman service, you may be prompted to fail, at which point you can check if the shared storage GFS2 file system has been uninstalled, and you can check that the Rgmanager service of the other nodes has shut down gracefully.
Third, management application services
When the cluster system starts, the app service is started automatically by default, but if an app service does not start automatically, it needs to be started manually. The command to manage app service is Clusvcadm, which enables you to start, shut down, restart, and switch application services in the cluster.
1. Start an app service
You can start an app service for a node in the following ways:
CLUSVCADM-E-M
which
? Service: Represents the name of the app service created in the cluster.
? Node: Represents the cluster node name.
For example, to start the Webserver service on the node Web1, do the following:
[Root@web1 ~]# clusvcadm-e webserver-m web1
Member Web1 trying to enable service:webserver ... Success
Service:webserver is now running on Web1
You can view the details of starting app service from the/var/log/messages file. When webserver is started, the cluster resources associated with the service, such as virtual IP and application service scripts, can be viewed with the following command to see if the cluster resources are loading properly:
2. Close an app service
You can turn off app service for a node as follows:
Clusvcadm-s-M
For example, to turn off the MySQLServer service on the node MYSQL1, do the following:
[ROOT@MYSQL1 ~]# clusvcadm-s mysqlserver-m MYSQL1
Member MYSQL1 stopping Service:mysqlserver ... Success
You can view the details of closing app service through the/var/log/messages file. When MySQLServer is closed, the cluster resources associated with the service: such as virtual IP, and application service scripts are also released.
3. Restart an app service
You can restart the app service for a node in the following ways:
Clusvcadm-r-M
For example, to restart the webserver service on the node Web1, do the following:
[Root@web2 ~]# clusvcadm-r webserver-m web1
Member web1 trying to restart Service:webserver ... Success
This command is executed on the WEB2 node, but the webserver on the WEB1 node can also be restarted successfully, so CLUSVCADM commands can be executed at any node of the cluster.
4. Switch a service
You can switch an app service from one node to another in the following ways:
Clusvcadm-r-M
For example, to switch a node Web1 service to a node web2, do the following:
[Root@web1 ~]# clusvcadm-r webserver-m web2
Trying to relocate service:webserver to web2 ... Success
Service:webserver is now running on WEB2
Iv. monitoring the status of RHCS clusters
Through the monitoring of RHCS, help to understand the health status of each node of the cluster, and can identify problems, solve problems in a timely manner, RHCS cluster provides a rich view of the status of the command, here the main introduction of Cman_tool, Clustat, ccs_tool the use of methods.
1. Cman_tool command
Cman_tool parameters are more, but the usage is relatively simple, the basic usage format is:
Cman_tool [Options]
Here are a few simple examples of use:
[Root@web1 ~]# Cman_tool nodes-a
Node Sts Inc Joined Name
0 M 0 2010-08-23 01:24:00/dev/sdb7
1 M 2492 2010-08-23 01:22:43 web2
addresses:192.168.12.240
2 M 2492 2010-08-23 01:22:43 MYSQL1
addresses:192.168.12.231
3 M 2492 2010-08-23 01:22:43 Mysql2
addresses:192.168.12.232
4 M 2488 2010-08-23 01:22:43 web1
addresses:192.168.12.230
This command shows the node name, along with the corresponding node IP address and time to join the cluster.
If you want to learn more about cluster node information, you can use the following command:
[Root@web1 ~]# cman_tool Status
version:6.2.0
Config version:35 #集群配置文件版本号
Cluster Name:mycluster #集群名称
Cluster id:56756
Cluster Member:yes
Cluster generation:2764
Membership State:cluster-member
Nodes:4 #集群节点数
Expected Votes:6 #期望的投票数
Quorum Device Votes:2 #表决磁盘投票值
Total Votes:6 #集群中所有投票值大小
Quorum:4 #集群法定投票值, below this value, the cluster will stop service
Active Subsystems:9
Flags:dirty
Ports bound:0 177
Node Name:web1
Node Id:4 #本节点在集群中的ID号
Multicast addresses:239.192.221.146 #集群广播地址
Node addresses:192.168.12.230 #本节点对应的IP地址
2. Clustat command
The Clustat command uses a very simple, detailed use method that can be used to obtain help information through "clustat-h", here are just a few examples.
[Root@web1 ~] #clustat-I 3
Cluster Status for Mycluster @ Mon 23 18:54:15 2010
Member status:quorate
Member Name ID Status
------ ---- ---- ------
WEB2 1 Online, Rgmanager
MYSQL1 2 Online, Rgmanager
MYSQL2 3 Online, Rgmanager
Web1 4 Online, Local, Rgmanager
/DEV/SDB7 0 Online, Quorum Disk
Service Name Owner (last) state
------- ---- ----- ------ --------
Service:mysqlserver MYSQL1 started
Service:webserver Web1 started
The content of the output has the following meanings:
The "-i" parameter of Clustat can display in real time each node in the cluster system and the running state of the service, "-I 3" means to refresh the cluster state every three seconds.
In this output, you can see each node is in the "online" state, indicating that each node is running normally, if a node exited the cluster, the corresponding state should be "Offline", but also can see that the cluster of two services are also in the "Started" state, Run on the MYSQL1 node and the Web1 node, respectively.
In addition, the "ID" column can be used to know the corresponding relationship between cluster nodes, for example, WEB2 in this cluster is the "Node 1" nodes, in the same vein, web1 corresponding to the "Node 4" nodes. Understanding the sequence of cluster nodes helps to interpret the cluster logs.
3. Ccs_tool command
Ccs_tool is primarily used to manage cluster profile cluster.conf, Ccs_tool can add/remove nodes in the cluster, add/Remove fence devices, update cluster configuration files, and more.
Here are a few examples of ccs_tool applications:
After a node has modified the configuration file, you can perform an "Ccs_tool update" instruction to update the configuration file on all nodes, for example:
[Root@web1 cluster]# Ccs_tool update/etc/cluster/cluster.conf
Proposed updated config file does not has greater version number.
Current config_version:: 35
Proposed config_version:: 35
Failed to update config file.
Ccs_tool is based on the "config_version" value in cluster.conf to decide whether to update, so after modifying the cluster.conf file, be sure to cluster.conf The version value is updated so that the configuration file can be updated when Ccs_tool is executed.
[Root@web1 cluster]# Ccs_tool update/etc/cluster/cluster.conf
Config file updated from version 36
Update complete.
V. Management and maintenance of the GFS2 file system
GFS2 file system provides a lot of management and maintenance tools, commonly used are gfs2_fsck, Gfs2_tool, Gfs2_jadd, Gfs2_quota, Gfs2_convert, etc., here focus on the use of the first three commands.
1. gfs2_fsck command
Similar to the FSCK.EXT3 command under the ext3 file system, it is primarily used to detect and repair file system errors. In fact, GFS2 also has a FSCK.GFS2 command, which is exactly the same as the GFS2_FSCK command.
The usage of gfs2_fsck is as follows:
gfs2_fsck [-afhnpqvvy]
Here are a few examples of use:
[Root@mysql1 ~]# gfs2_fsck-y/DEV/SDB5
Initializing fsck
Validating Resource Group Index.
Level 1 RG check.
(Level 1 passed)
Starting Pass1
Starting pass1c
PASS1C Complete
............
PASS5 Complete
Gfs2_fsck Complete
2. Gfs2_tool command
Gfs2_tool command parameters are many, but the use is not complex, it is mainly used to view, modify the GFS2 file system related parameter information.
Here are a few examples of use:
1) View GFS2 file system mount information
[Root@web1 ~]# Gfs2_tool DF/GFS2
/GFS2:
SB lock proto = "LOCK_DLM"
SB Lock table = "MYCLUSTER:MY-GFS2"
SB ondisk format = 1801
SB multihost format = 1900
Block size = 4096
Journals = 4
Resource Groups = 19
Mounted lock proto = "LOCK_DLM"
Mounted lock table = "MYCLUSTER:MY-GFS2"
Mounted host data = "Jid=2:id=65539:first=0"
Journal Number = 2
Lock Module flags = 0
Local flocks = FALSE
Local caching = FALSE
Type Total Blocks used Blocks free Blocks use%
--------------- ----------------- ------------- ---------------- -----------
Data 1220724 136578 1084146 11%
Inodes 1084263 117 1084146 0%
(2) Gfs2_tool command
2) lock and unlock the GFS2 file system:
[Root@node1 gfs2]# Gfs2_tool FREEZE/GFS2
[Root@node1 gfs2]# Gfs2_tool UNFREEZE/GFS2
After the GFS2 file system is locked, read and write operations cannot be performed until it is unlocked.
3) Query GFS2 the number of points that can be mounted
[Root@web1 ~]# Gfs2_tool JOURNALS/GFS2
Journal2-128mb
Journal3-128mb
Journal1-128mb
Journal0-128mb
4 Journal (s) found.
This shows that the number of Mount nodes is 4, and the size of each journal is 128M.
4) Displays the version information of the GFS2:
[Root@web1 ~]# Gfs2_tool version
Gfs2_tool 0.1.62 (built Mar 31 2010 07:34:25)
Copyright (C) Red Hat, Inc. 2004-2006 All rights reserved
(3) Gfs2-jadd command
Gfs2-jadd is mainly used to configure the number and size of GFS2 journals, and is very simple to use:
Gfs2_jadd [-CDHJJQV]/path/to/filesystem
Several use cases are listed below:
Set the size of the journals to 64M
[Root@mysql1 ~]# gfs2_jadd-j 64M
Increase the number of nodes GFS2 can mount simultaneously to 5
[Root@mysql1 ~]# gfs2_jadd-j 5/GFS2
In addition, Gfs2_quota is used for GFS2 file system disk quota management, Gfs2_convert is a data conversion application that can update the GFS file system metadata to convert it to a GFS2 file system. To learn more about their use, please refer to the Help information, which is not being narrated here.
http://www.bkjia.com/PHPjc/1068091.html www.bkjia.com true http://www.bkjia.com/PHPjc/1068091.html techarticle RHCs principle and Operation RHCs Component description: 1.1 Distributed Cluster Manager (CMAN) Cluster Manager, abbreviated as CMAN, is a distributed cluster management tool that runs on various nodes of the cluster ...
