Corosync V2 + Pacemaker High-availability MARIADB service

High-availability clusters have a variety of solutions, such as the Keepalived program, and many more ways to implement a highly available cluster in the AIS family, the earlier Heartbeat,openais only as a reference model, and then the Cman that Red Hat developed on openais basis,

There is also openais reference, the implementation of the independent Corosync of the project can be used for high-availability clusters, but these applications are originated from the earliest heartbeat program developed.

The Openais family of high-availability clusters in the implementation of the same mode of operation, all through the cluster approach to improve the availability of the system, that is, by providing redundant host nodes, to complete the system availability improvement;

To realize the high availability of the Cluster service, we have to integrate all the service nodes into the cluster, the cluster is responsible for the management, the allocation of resources to which node to run, and also to check the health status of each node, there is a drop line, to move the service to other nodes to run, in order to realize the service is not off line, to achieve

However, to achieve this is very complex, need to go through multiple levels of control, for example, each node can also be unicast, multicast, broadcast to other nodes in the same cluster to advertise their heartbeat information, as well as other related to the current cluster of transaction class information, this level is only responsible for the delivery of cluster transactions, It is called the messaging layer message tier. This message layer has a primary role of two points: through the configuration of the interface and address and the way to complete the heartbeat of the cluster and transaction information delivery.

Any application (service) that wants to be able to work itself into a highly available model, will run as highly available on the messaging layer basis, which means it must be able to communicate with the message layer.

Some programs can communicate directly to the message layer, but some applications cannot, in order for each application to communicate with the message layer, design a common middle tier to communicate with the message layer on its own, which means to accept management. Therefore, programs that cannot communicate directly with the message layer are hosted on this middle tier when they are run in a highly available manner, and are managed by the middle tier, which is highly available, and this middle tier is called Cluster Resource Manager CRM.

In order to facilitate the control of each node, the CRM needs a LRM Local resource manager, which is responsible for the service management on a specific node, such as monitoring service, starting service, stopping service, etc. but the real monitoring, starting and stopping operation is not done by CRM or LRM.

We all know that on a Linux system, the normal start of a service, such as the CentOS 7 start Web service is using the Systemctl start Httpd.service, to start, use the service httpd on CentOS 6 start Using different styles, CentOS 7 uses systemd, while CENTOS6 uses SYSV style. Therefore, high-availability clusters, the various startup services of the script called the RA resource Agent. A highly available cluster actually eventually starts the service by invoking the service's resource agent.

Messaging layer, CRM, RA these three levels are AIS family to achieve the three basic level of cluster function;

Summarize:

Messaging Layer main role: through the configuration of the interface and address and mode, to complete the heartbeat and transaction information transmission of the cluster;

CRM role: For non-ha-aware (can not directly communicate with the message layer) program to provide the middle tier, because the non-Ha-aware program cannot call messaging layer, and CRM can call the messaging layer, while there can provide a managed interface, Let any non-ha-aware application that wants to run in Ha mode is hosted on this middle tier;

and the main role of RA: The main implementation of specific resource management operation functions.

These three layers are conceptual models and each layer has its own implementation:

Messaging layer:3 species Scheme

Heartbeat procedure, Corosync, Cman;

Crm:3 species Program

Haresource, CRM, pacemaker;

RA: Resource proxies are of course provided by the package itself that has a specific service.

Messing layer and CRM combination methods:

Heartbeat v1 (Haresource): Self is independent and complete;

Heartbeat v2 (CRM): Self is independent and complete;

Corosync + pacemaker (manual combination): where Corosync has 2 versions;

Corosync v1 + pacemaker (plugin): no independent voting system, pacemaker run as a plug-in;

Corosync V2 + pacemaker (standalone service): Corosync version of the V2 has a complete voting system;

Cman + Rgmanager (RHCS): Red Hat's own development program.

Corosync v1 + cman + pacemaker: Corosync as Cman plug-in to run, vice versa, because Corosync only provide messaging layer and pacemaker work together, Cman provides a voting system but other functions are too poor.

For an in-depth understanding of the concepts in high-availability solutions for learning Corosync or AIS families, check out the official documentation for SUSE's official high-availability clusters.

The concept of the quorum mechanism, which is common to most distributed systems, is mainly used to solve the brain fissure caused by network partitioning;

There are two strategies, which are in accordance with the statutory number of votes and non-compliance with the statutory number of votes; In the case of non-compliance with the quorum policy, 4 mechanisms are used to avoid contention, stop: Stop all resources, default; ignore: ignore the legal votes or not, continue to work; suicide: suicide; freeze: Freeze The resource is still running, but the new request is not received.

To ensure a successful suicide, using the fencing mechanism, there are two scenarios: enabling the Stonith mechanism and the fibre switch.

Note: In a highly available cluster, it is a special case that a two-node cluster or even-numbered node has a brain fissure.

The transmission mode of cluster information and heartbeat information: unicast, broadcast, multicast.

Cluster resource management: The term DC, the unified dispatcher of the cluster, the PE, the policy engine.

Resource stickiness: The tendency to define resources running on the current node; default is 0;

The tendency of resources: Also called the constraint relation of resources, the tendency of resources to nodes, the arrangement of resources and the order of resource initiation.

Types of resources: 4 types

Primitive: Indicates that the resource can and can only run on one node; is a basic resource or a master resource, is the most common resource type, can only run one copy, can only run on one node;

Group: A resource that organizes all the resources needed to compose an HA service;

Clone: Cloning resources, the same resource can appear multiple copies, you can run multiple nodes;

Multi-State (Master/slave): Multi-state resources, is a special clone of the resources, there is a master-slave relationship between replicas;

RA: Resource agent, 5 kinds

Lsb:linux Standard library, located in/etc/rc.d/init.d/*, supporting at least start,stop,restart,status,reload,force-reload; Note: Do not start automatically run;

Ocf:open Cluster Framework, this script is more flexible than the LSB script,/usr/lib/ocf/resource.d/provider/, similar to the LSB script, but requires support for Start,stop,status, Monitor,meta-data;

STONITH: Implement the function of management call STONITH device;

SYSTEMD: Implemented with unit file file,/usr/lib/systemd/system/; Note: must be set to enable state; otherwise, CRM agent cannot be managed;

Service: Invoking user-defined scripts;

Demo: Configure an NFS-based high-availability MARIADB service:

Physical machine for Win7, virtual machine using CENTOS7 system

Time server: 172.18.0.1

Server for NFS: 172.18.11.113

The MARIADB has two nodes:

node1:172.18.11.111, host name: node1.stu11.com

node2:172.18.11.112, host name: node2.stu11.com

Do the following on both nodes:

First Step: Time synchronization

]# ntpdate 172.18.0.1 to time server sync time

]# crontab-e Define time synchronization cycle tasks

*/5 * * * */usr/sbin/ntpdate 172.18.0.1 &>/dev/null

Second step: Be able to parse each other based on host name and resolve hostname to match the hostname used

]# vim/etc/hosts

172.18.11.111 node1.stu11.com Node1

172.18.11.112 node2.stu11.com Node2

Ensure that the name used and the resolved name must be the same; the resolved name setting why, the use is the hostname command to see must be the same; otherwise, a highly available cluster is not available.

Step three: Permanent, set host name:

] #hostnamectl set-hostname node1.stu11.com

] #hostnamectl set-hostname node2.stu11.com

Two-node, installation mariadb, Pacemaker

]# yum-y Install Mariadb-server

]# Systemctl Enable Mariadb.service

]# yum-y Install Pacemaker

]# systemctl start Corosync.service pacemaker.service

To configure Server for NFS:

]# yum-y Install Nfs-utils

]# Vim/etc/exports

/mysql 172.18.11.0/24 (Rw,no_root_squash)

To create a database storage path on a two node:

]# Mkdir/mysql

]# Chown Mysql.mysql/mysql

Test whether the two-node mount was successful:

]# showmount-e 172.18.11.113

]# mount-t NFS 172.18.11.113:/mysql/mysql

]# Mount

]# vim/etc/my.cnf

Datadir=/mysql

Skip_name_resolve=on

Innodb_file_per_table=on

]# CRM Ra

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/82/21/wKioL1dMNSDhVYgWAAA6L1eGPSg298.png "title=" 1.png " alt= "Wkiol1dmnsdhvygwaaa6l1egpsg298.png"/>

Ensure that the resource agent already exists;

To view cluster status:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/82/21/wKioL1dMNA_jGetxAAA7Pv4cjfE644.png "title=" 2.png " Width= "702" height= "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:702px;height:170px; "alt=" Wkiol1dmna_ Jgetxaaa7pv4cjfe644.png "/>

To define a cluster resource:

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/82/21/wKioL1dMM9bzSig0AABEAz5tVzc957.png "title=" 3.png " Width= "701" height= "119" border= "0" hspace= "0" vspace= "0" style= "WIDTH:701PX;HEIGHT:119PX;" alt= " Wkiol1dmm9bzsig0aabeaz5tvzc957.png "/>

To view cluster status:

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/82/21/wKioL1dMNFzSMvnhAABOV2oAwGo468.png "title=" 4.png " Width= "708" height= "196" border= "0" hspace= "0" vspace= "0" style= "width:708px;height:196px;" alt= " Wkiol1dmnfzsmvnhaabov2oawgo468.png "/>

Bind the resources together:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/82/22/wKiom1dMNBnx9WFFAAAZdnwq1Gc779.png "title=" 5.png " alt= "Wkiom1dmnbnx9wffaaazdnwq1gc779.png"/>

To view cluster status:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/82/21/wKioL1dMNKGTj8oiAABJ5C12DIA742.png "title=" 6.png " Width= "702" height= "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:702px;height:220px; "alt=" Wkiol1dmnkgtj8oiaabj5c12dia742.png "/>

Manually make Node1 offline to see if resources are migrated

]# CRM node Standby

To view cluster status:

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M02/82/21/wKioL1dMNPniXNXuAABWr7tSU7I744.png "title=" 7.png " Width= "726" height= "236" border= "0" hspace= "0" vspace= "0" style= "width:726px;height:236px;" alt= " Wkiol1dmnpnixnxuaabwr7tsu7i744.png "/>

The above demo enables the high availability of NFS-based MARIADB

Corosync V2 + Pacemaker High-availability MARIADB service