关于sap应用在pacemaker集群下的资源与资源组设计

Posted 2023-04-23

关于sap相关的应用，如果建立两个节点组成的pacemaker集群，集群中有两个业务相关的应用资源如：ASCS 与 AERS

当然对于pacemaker集群来说、就无所谓资源/资源组运行在那个节点、因为在那两个节点上都是可以运行所有资源的

当然笔者还是建议是将两个应用资源/资源组能分别启动在两台不同的机器（建立条件约束可以实现），这样可以可以减轻一下单个节点的负载

需要注意的是，如果要保证业务资源都可以在两个节点上都能正常，那么就还应该有个先决条件，建立vip，即虚拟IP机制，对外始终只提供虚拟IP即可

对于Sonith/Fence资源，当然这个可以随机运行在某个节点都是可以的，不用刻意限定运行在那个节点，这样加上业务资源组、一共就是3部分了

最后，根据这样的原则，将集群设计完成后，通过pcs status 查看最后的状态，就如下所示了

[root@azphxxxapp01 qq-5201351]# pcs status
Cluster name: HxxxAppProdCluster
Cluster Summary:
  * Stack: corosync
  * Current DC: azphxxxapp01 (version 2.1.2-4.el8_6.5-ada5c3b36e2) - partition with quorum
  * Last updated: Sat Apr 22 05:22:07 2023
  * Last change:  Sat Apr 22 05:20:46 2023 by root via cibadmin on azphxxxapp01
  * 2 nodes configured
  * 7 resource instances configured

Node List:
  * Online: [ azphxxxapp01 azphxxxapp02 ]

Full List of Resources:
  * HxxxAppProdfence    (stonith:fence_azure_arm):       Started azphxxxapp01
  * Resource Group: g-Prod_ASCS:
    * vip_Prod_ASCS     (ocf::heartbeat:IPaddr2):        Started azphxxxapp01
    * nc_Prod_ASCS      (ocf::heartbeat:azure-lb):       Started azphxxxapp01
    * rsc_sap_Prod_ASCS01       (ocf::heartbeat:SAPInstance):    Started azphxxxapp01
  * Resource Group: g-Prod_AERS:
    * vip_Prod_AERS     (ocf::heartbeat:IPaddr2):        Started azphxxxapp02
    * nc_Prod_AERS      (ocf::heartbeat:azure-lb):       Started azphxxxapp02
    * rsc_sap_Prod_ERS05        (ocf::heartbeat:SAPInstance):    Started azphxxxapp02

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
[root@azphxxxapp01 qq-5201351]#

说明：当资源组中的业务资源发生切换时，其相应的nc端口与vip资源也会相应的发生切换，其中nc端口为上游负载切换器的健康检测端口~

 

 

 

尊重别人的劳动成果 转载请务必注明出处：https://www.cnblogs.com/5201351/p/17347194.html

 

作者：一名卑微的IT民工

出处：https://www.cnblogs.com/5201351

本博客所有文章仅用于学习、研究和交流目的，欢迎非商业性质转载。

博主的文章没有高度、深度和广度，只是凑字数。由于博主的水平不高，不足和错误之处在所难免，希望大家能够批评指出。

博主是利用读书、参考、引用、抄袭、复制和粘贴等多种方式打造成自己的文章，请原谅博主成为一个卑微的IT民工！

pacemaker+corosync/heartbeat高可用集群对比及资源代理RA脚本

一、Pacemaker概念

（1）Pacemaker(心脏起搏器)，是一个高可用的群集资源管理器。它实现最大可用性资源管理的节点和资源级故障检测和恢复，通过使用首选集群基础设施（Corosync或Heartbeat）提供的消息和成员能力。 它可以监测并恢复节点和服务级别的故障，实现进程级高可用。它适合各种大小集群，可以编写脚本，可以管理作为心脏起搏器集群的一部分。再次说明一下，pacemaker是个资源管理器，不是提供心跳信息的，因为它似乎是一个普遍的误解，corosync/heartbeat的工作才是提供心跳信息。pacemaker是一个延续的CRM（亦称Heartbeat V2资源管理器），最初是为心跳，但已经成为独立的项目，例如下图的Heartbeat3.0版本，pacemaker是其中的一个部分或者说是一个模块，heartbeat同样也是一个模块，可以替换为corosync，各个模块有各自的作用。

（2）Heartbeat3.0的组成部分

（3）Pacemaker内部结构

 

二、pacemaker+corosync/heartbeat 软件架构

1、Pacemaker - 集群资源管理器(CRM)，负责启动和停止服务，而且保证它们是一直运行着的以及某个时刻某服务只在一个节点上运行（避免多服务同时操作数据造成的混乱），利用集群基础构建提供的信息和成员管理能力，探测并恢复节点以及在其控制下的资源的失效切换，以实现高可用性。

2、Corosync - 消息层组件，管理成员关系、消息和仲裁。

3、Resource Agents - 资源代理，用来控制服务启停，监控服务状态的脚本集合，这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等。任何资源代理都要使用同一种风格，接收四个参数：{start|stop|restart|status}，包括配置IP地址的也是。

三、corosync和heartbeat对比

（1）共同点：

  都属于消息网络层，对外提供服务和主机的心跳检测，在监控的主服务被发现当机之后，即时切换到从属的备份节点，保证系统的可用性.

（2）不同点：

•    社区活跃度：

Heartbeat从2010年之后，就不再继续维护，而Corosync则仍然处于活跃期

• 配置复杂度:

Heartbeat非常容易进行配置，第一次配置可能只需要几分钟，而Corosync由于有一定的复杂度则需要一点耐心

• 管理资源的灵活性:

Heartbeat只能为所有的资源配置一个主服务，而corosync则允许为不同的资源组配置不同的主服务。

• Resource stickiness:

Heartbeat在主服务server1当机之后，切换到从服务节点server2;还会把之前的主节点server1继续放入从属节点列表之内。而corosync则不会存在这个情况。

• 配置文件的版本管理:

在corosync中，其会自行处理配置文件的同步问题，heartbeat则无此功能。

• 分组管理

Heartbeat只支持2个节点，而corosync则支持多个节点的集群，支持把资源进行分组，按照组进行资源的管理，设置主服务，自行进行启停

    故此可见，一般来说都是选择corosync来进行心跳的检测，搭配pacemaker的资源管理系统来构建高可用的系统。

 

四、Corosync

 

关于心跳的基本概念：

• 心跳：就是将多台服务器用网络连接起来，而后每一台服务器都不停的将自己依然在线的信息使用很简短很小的通告给同一个网络中的其它主机，告诉它们自己依然在线，其它服务器收到这个心跳信息就认为它是在线的，尤其是主服务器。
• 心跳信息怎么发送，由谁来收，其实就是进程间通信。两台主机是没法通信的，只能利用网络功能，通过进程监听在某一套接字上，实现数据发送，数据请求，所以多台服务器就得运行同等的进程，这两个进程不停的进行通信，主节点(主服务器)不停的向对方同等的节点发送自己的心跳信息，那这个软件就叫高可用的集群的基准层次，也叫心跳信息传递层以及事物信息的传递层，这是运行在集群中的各节点上的进程，这个进程是个服务软件，关机后需要将其启动起来，主机间才可以传递信息的，一般是主节点传给备节点

五、资源代理（Resource Agent - RA）

    一个 RA 是管理一个集群资源的可执行程序，没有固定其实现的编程语言，但是大部分RA都是用 shell 脚本实现的，Pacemaker 使用 RA 来和受管理资源进行交互，Pacemaker 支持三种类型的 RA： LSB Resource Agents、OCF Resource Agents、Legacy Heartbeat Resource Agents。

    主流的 RA 都是 OCF 类型的。RA 支持的主要操作包括： start、stop、monitor、meta-data、status

    （CIB 是个分布式的XML 文件，有用户添加配置 Pacemaker 和 Corosync 根据 CIB 控制 LRMD 的行为 LRMD 通过调用 RA 的接口控制各资源的行为）