Registering a Critical Device

Important - In a Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., you must configure all the Cluster Members in the same way.

Description

You can add a user-defined critical device A special software device on each Cluster Member, through which the critical aspects for cluster operation are monitored. When the critical monitored component on a Cluster Member fails to report its state on time, or when its state is reported as problematic, the state of that member is immediately changed to Down. The complete list of the configured critical devices (pnotes) is printed by the 'cphaprob -ia list' command or 'show cluster members pnotes all' command. Synonyms: Pnote, Problem Notification. to the default list of critical devices. Use this command to register <device> as a critical process, and add it to the list of devices that must run for the Cluster Member Security Gateway that is part of a cluster. to be considered active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism.. If <device> fails, then the Cluster Member is seen as failed.

If a Critical Device fails to report its state to the Cluster Member in the configured timeout, the Critical Device, and by design the Cluster Member, are seen as failed.

Define the status of the Critical Device that is reported to ClusterXL Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. upon registration.

This initial status can be one of these:

• ok - Critical Device is alive.

• init - Critical Device is initializing. The Cluster Member is Down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.. In this state, the Cluster Member cannot become Active.

• problem - Critical Device failed. If this state is reported to ClusterXL, the Cluster Member immediately goes Down. This causes a failover Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over..

Syntax

Shell	Command
Gaia Clish The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell).	N / A
Expert mode	cphaconf set_pnote -d <Name of Critical Device> -t <Timeout in Sec> -s {ok | init | problem} [-p] [-g] register

Notes: The "-t" flags specifies how frequently to expect the periodic reports from this Critical Device. If no periodic reports should be expected, then enter the value 0 (zero). The "-p" flag makes these changes permanent (survive reboot). The "-g" flag applies the command to all configured Virtual Systems.

Restrictions

• Total number of critical devices (pnotes) on Cluster Member is limited to 16.

• Name of any critical device (pnote) on Cluster Member is limited to 15 characters, and must not include white spaces.

Related topics

• Viewing Critical Devices

• Reporting the State of a Critical Device

• Registering Critical Devices Listed in a File

• Unregistering a Critical Device

• Unregistering All Critical Devices

Example use case

This example assumes that all other Critical Devices report their statues as "ok".

Do these steps on each Cluster Member:

1. Create a shell script that does these actions:

   1. Examine the used space in the critical disk partitions.

   2. If the used space in these partitions:

      • Is above the threshold, then register a user-defined Critical Device and report its status as "problem".

        As a result, the Cluster Member changes its cluster state to "Down" (if there is at least one Cluster Member in the status "Active").

      • Is below the threshold, then register a user-defined Critical Device and report its status as "ok".

        As a result, the Cluster Member changes its cluster state to "Standby" or "Active".

   Example script syntax:

   #!/bin/bash # Get the used % in the partition lv_current var_lv_current=$(df -h | grep lv_current | awk '{print $5}'| sed 's/[%]//') # Get the used % in the partition lv_log var_lv_log=$(df -h | grep lv_log | awk '{print $5}'| sed 's/[%]//') if [ "$var_lv_current" -gt 90 -o "$var_lv_log" -gt 90 ]; then # If the partition is full, then bring the cluster member down $FWDIR/bin/cphaconf set_pnote -d Storage -s problem report else # If the partition is free enough, then bring the cluster member up $FWDIR/bin/cphaconf set_pnote -d Storage -s ok report $FWDIR/bin/cphaconf set_pnote -d Storage unregister fi

2. Configure a scheduled job to run this shell script at the relevant time intervals.

   See the R82 Gaia Administration Guide.