Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 30 章 Integrating non-corosync nodes into a cluster: the pacemaker_remote service

The pacemaker_remote service allows nodes not running corosync to integrate into the cluster and have the cluster manage their resources just as if they were real cluster nodes.

Among the capabilities that the pacemaker_remote service provides are the following:

  • The pacemaker_remote service allows you to scale beyond the Red Hat support limit of 32 nodes.
  • The pacemaker_remote service allows you to manage a virtual environment as a cluster resource and also to manage individual services within the virtual environment as cluster resources.

The following terms are used to describe the pacemaker_remote service.

  • cluster node - A node running the High Availability services (pacemaker and corosync).
  • remote node - A node running pacemaker_remote to remotely integrate into the cluster without requiring corosync cluster membership. A remote node is configured as a cluster resource that uses the ocf:pacemaker:remote resource agent.
  • guest node - A virtual guest node running the pacemaker_remote service. The virtual guest resource is managed by the cluster; it is both started by the cluster and integrated into the cluster as a remote node.
  • pacemaker_remote - A service daemon capable of performing remote application management within remote nodes and KVM guest nodes in a Pacemaker cluster environment. This service is an enhanced version of Pacemaker’s local executor daemon (pacemaker-execd) that is capable of managing resources remotely on a node not running corosync.

A Pacemaker cluster running the pacemaker_remote service has the following characteristics.

  • Remote nodes and guest nodes run the pacemaker_remote service (with very little configuration required on the virtual machine side).
  • The cluster stack (pacemaker and corosync), running on the cluster nodes, connects to the pacemaker_remote service on the remote nodes, allowing them to integrate into the cluster.
  • The cluster stack (pacemaker and corosync), running on the cluster nodes, launches the guest nodes and immediately connects to the pacemaker_remote service on the guest nodes, allowing them to integrate into the cluster.

The key difference between the cluster nodes and the remote and guest nodes that the cluster nodes manage is that the remote and guest nodes are not running the cluster stack. This means the remote and guest nodes have the following limitations:

  • they do not take place in quorum
  • they do not execute fencing device actions
  • they are not eligible to be the cluster’s Designated Controller (DC)
  • they do not themselves run the full range of pcs commands

On the other hand, remote nodes and guest nodes are not bound to the scalability limits associated with the cluster stack.

Other than these noted limitations, the remote and guest nodes behave just like cluster nodes in respect to resource management, and the remote and guest nodes can themselves be fenced. The cluster is fully capable of managing and monitoring resources on each remote and guest node: You can build constraints against them, put them in standby, or perform any other action you perform on cluster nodes with the pcs commands. Remote and guest nodes appear in cluster status output just as cluster nodes do.

Pacemaker supports two methods of securing the connection between Pacemaker nodes and pacemaker_remote nodes:

  • Transport Layer Security (TLS) with pre-shared key (PSK) encryption and authentication over TCP
  • TLS with SSL certificates. With this method, you can use existing certificates to secure the connection

TLS with PSK encryption

The connection between cluster nodes and pacemaker_remote nodes is secured using Transport Layer Security (TLS) with pre-shared key (PSK) encryption and authentication over TCP using port 3121 by default in the following situations:

  • When you configure a guest node with the cluster node add-guest command
  • When you configure a remote node with the cluster node add-remote command

This means both the cluster node and the node running pacemaker_remote must share the same private key. By default this key must be placed at /etc/pacemaker/authkey on both cluster nodes and remote nodes.

The first time you run the pcs cluster node add-guest command or the pcs cluster node add-remote command, it creates the authkey and installs it on all existing nodes in the cluster. When you later create a new node of any type, the existing authkey is copied to the new node.

Configuring SSL/TLS certificates

You can encrypt Pacemaker Remote connections using X.509 (SSL/TLS) certificates. With this method, you can reuse existing host certificates for Pacemaker Remote connections rather than private shared keys.

To configure SSL/TLS certificates, create a remote connection with the pcs cluster node add-guest command or the pcs cluster node add-remote command. You can then convert the remote connection to use certificates.

Procedure

  1. Create a remote connection with the pcs cluster node add-guest command or the pcs cluster node add-remote command. This sets up the authkey for guest nodes or remote nodes. The following example command creates a remote node and sets up the authkey for that node. 

    [root@clusternode1 ~] # pcs cluster node add-remote remote1

    For a full configuration procedure for remote nodes, see Configuring Pacemaker remote nodes. Configuring Pacemaker remote nodes.

  2. Convert the connection you have created to use SSL/TLS certificates by updating the following variables in the etc/sysconfig/pacemaker file on all cluster nodes and Pacemaker remote nodes:

    • PCMK_ca_file - The location of a file containing trusted Certificate Authorities, used to verify client or server certificates. This file must be in PEM format and it must allow read permissions to either the hacluster user or the haclient group.
    • PCMK_cert_file - The location of a file containing the signed certificate for the server side of the connection. This file must be in PEM format and it must allow read permissions to either the hacluster user or the haclient group.
    • PCMK_crl_file (optional) - The location of a Certificate Revocation List file, in PEM format.
    • PCMK_key_file - The location of a file containing the private key for the matching PCMK_cert_file, in PEM format. This file must be in PEM format and it must allow read permissions to either the hacluster user or the haclient group.
  3. Optionally, remove any /etc/pacemaker/authkey files from the cluster and remote nodes. Pacemaker uses certificates if certificates are configured, but removing the authkey files ensures that Pacemaker does not use PSK encryption if you have neglected to configure the certificates on a node.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部