In an HA cluster, you modify the number of cores given to CoreXL on only one member
using cpconfig and then issue a reboot. What is the expected ClusterXL status of this
member when it comes up?
A.
Standby
B.
Ready
C.
Active
D.
Down
What is the expected ClusterXL status of this member when it comes up?
In an HA cluster, you modify the number of cores given to CoreXL on only one member
using cpconfig and then issue a reboot. What is the expected ClusterXL status of this
member when it comes up?
Correct answer is B, as per the SecureXL admin guide.
correct is A
Ready:
State Ready means that the machine recognizes itself as a part of the cluster and is literally ready to go into action, but, by design, something prevents the machine from taking action. Possible reasons that the machine is not yet Active include:
Not all required software components were loaded and initialized yet and/or not all configuration steps finished successfully yet. Before a cluster member becomes Active, it sends a message to the rest of the cluster members, checking whether it can become Active. In High-Availability mode it will check if there is already an Active member and in Load Sharing Unicast mode it will check if there is a Pivot member already. The member remains in the Ready state until it receives the response from the rest of the cluster members and decides which state to choose next (Active, Standby, Pivot, or non-Pivot).
Software installed on this member has a higher version than the rest of the members in this cluster. For example, when a cluster is upgraded from one version of Check Point Security Gateway to another, and the cluster members have different versions of Check Point Security Gateway, the members with a new version have the Ready state and the members with the previous version have the Active / Active Attention state.
If the software installed on all cluster members includes CoreXL, which is installed by default in versions R70 and higher, a member in Ready state may have a higher number of CoreXL instances than other members. See sk42096 for a solution
From the article mentioned above, sk42096, “The number of CoreXL FireWall instances on cluster members is different [member with greater number of CoreXL FW instances will go into state ‘Ready’].”. This would seem to indicate B as the correct answer. But I am now working with an HA cluster that has a different number of firewall instances on each cluster member, and they read Active/Standby. They do not fail over though and I am still trying to find out why that is.
Active, irrespective on which member the number of cores are changed. Other member will be in ready state.
Reference:
1.Number of cores changed on active member.
[Expert@GW1:0]# cphaprob stat
Cluster Mode: Virtual System Load Sharing
Number Unique Address Assigned Load State
1 (local) 172.16.1.6 100% Active
[Expert@GW2:0]# cphaprob stat
Cluster Mode: Virtual System Load Sharing
Number Unique Address Assigned Load State
1 172.16.1.6 0% ClusterXL Inactive or Machine is Down
2 (local) 172.16.1.7 0% Ready
(*) ‘Ready’ state might be caused due to configuration inconsistency between members:
32bit/64bit/usermode, number of CoreXL instances or different SW version.
2.Number of cores changed on standby member.
[Expert@GW1:0] cphaprob stat
Cluster Mode: Virtual System Load Sharing
Number Unique Address Assigned Load State
1 (local) 172.16.1.6 0% Ready
2 172.16.1.7 0% ClusterXL Inactive or Machine is Down
(*) ‘Ready’ state might be caused due to configuration inconsistency between mem bers:
32bit/64bit/usermode, number of CoreXL instances or different SW version.
[Expert@GW2:0]# cphaprob stat
Cluster Mode: Virtual System Load Sharing
Number Unique Address Assigned Load State
2 (local) 172.16.1.7 100% Active