11 pcs commands you should know 

The pcs command line interface controls and configures cluster services such as corosync, pacemaker,booth, and sbd by providing an easier interface to their configuration files.

Note that you should not edit the cib.xml configuration file directly. In most cases, Pacemaker will reject a directly modified cib.xml file.

1. PCS Help 

The following command displays the parameters of the pcs resource command.

# pcs resource -h

2. Viewing the raw cluster configuration

The pcs cluster cib command allows you to inspect the raw cluster configuration even if you shouldn't directly edit the cluster configuration file.

You can save the raw cluster configuration to a specified file with the pcs cluster cib filename command. If you have previously configured a cluster and there is already an active CIB, you use the following command to save the raw xml file.

pcs cluster cib filename

For example, the following command saves the raw xml from the CIB into a file named testfile.

# pcs cluster cib testfile

3. cluster status

You can display the status of the cluster and the cluster resources with the following command.

# pcs status

You can display the status of a particular cluster component with the commands parameter of the pcs status command, specifying resources, cluster, nodes, or pcsd.

pcs status commands

For example, the following command displays the status of the cluster resources.

# pcs status resources

The following command displays the status of the cluster, but not the cluster resources.

# pcs cluster status

4. Authenticating the Cluster Nodes

pcs cluster auth [node] [...] [-u username] [-p password]

root@z1 ~]# pcs cluster auth z1.example.com z2.example.com
Username: hacluster
Password:
z1.example.com: Authorized
z2.example.com: Authorized

5. Starting Cluster

pcs cluster start [--all] [node] [...]

--all : all nodes

pcs cluster start --all 

6. Stopping Cluster

The following command stops cluster services on the specified node or nodes. As with the pcs cluster start, the --all option stops cluster services on all nodes and if you do not specify any nodes, cluster services are stopped on the local node only.

pcs cluster stop [--all] [node] [...]

You can force a stop of cluster services on the local node with the following command, which performs a kill -9 command.

pcs cluster kill

7. Adding Cluster Nodes

Use the following procedure to add a new node to an existing cluster. 

1. Install the cluster packages. 
   [root@newnode ~]# yum install -y pcs fence-agents-all

2. If you are running the firewalld daemon, execute the following commands to enable the ports that are required by the Red Hat High Availability Add-On.
   # firewall-cmd --permanent --add-service=high-availability
   # firewall-cmd --add-service=high-availability

3. Set a password for the user ID hacluster. It is recommended that you use the same password for each node in the cluster.
   [root@newnode ~]# passwd hacluster
   Changing password for user hacluster.
   New password:
   Retype new password:
   passwd: all authentication tokens updated successfully.
   

4. Execute the following commands to start the pcsd service and to enable pcsd at system start.
   # systemctl start pcsd.service
   # systemctl enable pcsd.service

On a node in the existing cluster, perform the following tasks.

1. Authenticate user hacluster on the new cluster node.
   [root@clusternode-01 ~]# pcs cluster auth newnode.example.com
   Username: hacluster
   Password:
   newnode.example.com: Authorized

1. Add the new node to the existing cluster. This command also syncs the cluster configuration file corosync.conf to all nodes in the cluster, including the new node you are adding.
   [root@clusternode-01 ~]# pcs cluster node add newnode.example.com

On the new node to add to the cluster, perform the following tasks.

1. Start and enable cluster services on the new node.
   [root@newnode ~]# pcs cluster start
   Starting Cluster...
   [root@newnode ~]# pcs cluster enable

8. Removing Cluster Nodes

The following command shuts down the specified node and removes it from the cluster configuration file, corosync.conf, on all of the other nodes in the cluster.

pcs cluster node remove node

9. Standby Mode

The following command puts the specified node into standby mode. The specified node is no longer able to host resources. Any resources currently active on the node will be moved to another node. If you specify the --all, this command puts all nodes into standby mode.

You can use this command when updating a resource's packages. You can also use this command when testing a configuration, to simulate recovery without actually shutting down a node.

pcs cluster standby node | --all

The following command removes the specified node from standby mode. After running this command, the specified node is then able to host resources. If you specify the --all, this command removes all nodes from standby mode.

pcs cluster unstandby node | --all

10. Cluster Maintenance

If you need to stop a node in a cluster : 

pcs cluster standby node

If you need to move an individual resource off the node on which 

it is currently running without stopping that resource, you can 

use the pcs resource move

N.B: When you execute the pcs resource move command, this adds a constraint to the resource to prevent it from running on the node on which it is currently running. When you are ready to move the resource back, you can execute the pcs resource clear or the pcs constraint delete command to remove the constraint. 

If you need to stop a running resource entirely and prevent the cluster from starting it again, you can use the pcs resource disable

If you want to prevent Pacemaker from taking any action for a resource use the pcs resource unmanage command.

If you need to put the cluster in a state where no services will be started or stopped, you can set the maintenance-mode cluster property.

11. How to update Changes to a Working Cluster Configuration?

When configuring a cluster, you can save configuration changes to a specified file without affecting the active CIB. This allows you to specify configuration updates without immediately updating the currently running cluster configuration with each individual update.

Procedure

The following is the recommended procedure for pushing changes to the CIB file. This procedure creates a copy of the original saved CIB file and makes changes to that copy. When pushing those changes to the active CIB, this procedure specifies the diff-against option of the pcs cluster cib-push command so that only the changes between the original file and the updated file are pushed to the CIB. This allows users to make changes in parallel that do not overwrite each other, and it reduces the load on Pacemaker which does not need to parse the entire configuration file.

1. Save the active CIB to a file. This example saves the CIB to a file named original.xml.

   # pcs cluster cib original.xml

2. Copy the saved file to the working file you will be using for the configuration updates.

   # cp original.xml updated.xml

3. Update your configuration as needed. The following command creates a resource in the file updated.xml but does not add that resource to the currently running cluster configuration.

   # pcs -f updated.xml resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 op monitor interval=30s

4. Push the updated file to the active CIB, specifying that you are pushing only the changes you have made to the original file.

   # pcs cluster cib-push updated.xml diff-against=original.xml

Alternately, you can push the entire current content of a CIB file with the following command.

pcs cluster cib-push filename

When pushing the entire CIB file, Pacemaker checks the version and does not allow you to push a CIB file which is older than the one already in a cluster. If you need to update the entire CIB file with a version that is older than the one currently in the cluster, you can use the --config option of the pcs cluster cib-push command.

pcs cluster cib-push --config filename

Thanks . Please share.