Admin Console Procedures
This section covers the following topics:
•Adding a Node to a Cluster Through the Admin Console
•Failing Over the VIP to Another Node
•Changing the IP Address of a Cluster Node
•Adding Multiple Cluster Nodes
•Re-Adding a Node to a Cluster
•Restarting or Rebooting Cluster Nodes
•Modifying the Cluster Properties
•Synchronizing the Cluster State
•Using the Serial Console for Cluster Administration
Creating a Cluster
To create a cluster and add members:
1.Select System > Clustering > Create Cluster and complete the configuration.
|
Settings |
Actions |
|
Specifies a name to identify the cluster. |
|
|
Cluster Password |
Specifies the cluster password. You need to enter the password again when specifying additional nodes to join the cluster. All nodes in the cluster use this password to communicate. |
|
Confirm Password |
Specifies the password that is confirmed. |
|
Member Name |
Specifies the name of the member. |
2.Click Create Cluster. When prompted to confirm the cluster creation, click Create. After the device initializes the cluster, the Clustering page displays the Status and Properties tabs.
Adding a Node to a Cluster Through the Admin Console
Before you can add a node to a cluster (through either the Web or the serial console), you need to make its identity known to the cluster. Note that if a node has a cluster license key, it has only a Clustering > Join tab.
To add a node to a cluster through its admin console:
1.From an existing cluster member, select System > Clustering > Cluster Status, and specify the node you want to add to the cluster.
2.From the admin console of the node you want to add to a cluster, select System > Clustering > Join, and enter:
•The name of the cluster to join
•The cluster password you specified when defining the cluster
•The IP address of an active cluster member
3.Click Join Cluster. When you are prompted to confirm joining the cluster, click Join. After the node joins the cluster, you may need to sign in again.
The following figure shows the Join Cluster page.
While the new node synchronizes its state with the existing cluster member, each node's status on the Status page indicates Enabled, Enabled; Transitioning; or Enabled, Unreachable.
Deleting a Cluster
If you delete a cluster, all of the nodes begin running as standalone systems.
To delete a cluster:
1.From the admin console of an active cluster member, select the System > Clustering > Properties page.
2.Click the Delete Cluster button.
3.Click Save Changes.
The following figure shows the properties for the Clustering page.
Failing Over the VIP to Another Node
In an active/passive cluster, you might need to fail the VIP to the other node, regardless of which node you are currently using.
To fail-over the VIP:
1.Select System > Clustering > Cluster Status from the admin console.
2.Click the Fail-Over VIP button to move to the other node. The Fail-Over VIP button is a toggle button, so you can move from one node to the other, regardless of which is the leader. The fail-over occurs immediately.
VIP failover does not occur when the management port fails.
The following figure shows the fail-over VIP option on the Clustering page.
Changing the IP Address of a Cluster Node
Changing the IP address of a cluster while it belongs to a cluster is not supported. In order to change the IP address, you must first remove it from the cluster, update the IP address and then add it back.
If you attempt to change the IP address of a node while it belongs to a cluster, unpredictable results might occur.
For example:
1.Select System > Clustering > Cluster status.
2.Select the check box for the name of the node whose IP address you want to change.
3.Click Remove.
4.After the node is removed, sign in to that node, change its IP address and click Save Changes.
5.In the main node, add the changed node to the cluster configurations.
6.Log in to the changed node and rejoin the cluster.
The following procedure is a model for changing both node IP addresses in an active/passive cluster:
1.Select System > Clustering > Cluster status.
2.Click Delete Cluster.
3.Change the IP address of each node.
4.Log in to the main node and re-create the cluster, changing it from active/active to active/passive and defining the internal and/or external VIP addresses.
5.Add the other node to the cluster configurations.
6.Log in to the passive node and add it to the cluster.
Adding Multiple Cluster Nodes
To add multiple nodes to a cluster:
Select System > Clustering > ClusterStatus.
1.Click Add Members.
2.Enter the node name and internal IP address.
3.Modify or add the default internal netmask and internal gateway addresses, if necessary.
4.Click Add.
The following figure shows the Add Cluster Member page.
5.Repeat the process until you have added all of the nodes.
6.Click Save Changes to save the node configurations.
The system automatically enables the added nodes, even if they are unreachable.
Re-Adding a Node to a Cluster
With some maintenance operations, you might need to remove a node from a cluster, then re-add and re-join it to the cluster.
When a node joins a cluster, all of its node-specific settings (including network interface addresses, route tables, virtual ports, ARP caches, VLAN interface, SNMP settings) are overwritten by the corresponding configuration setting it receives from the cluster.
To populate the newly joined node with the correct node-specific settings:
1.Add the node to the cluster.
2.On any of the existing nodes in the cluster, manually configure the appropriate node-specific settings for the newly added node by selecting the node from the menu in the settings page.
3.Add the node to the cluster.
When the node joins the cluster, it receives its newly configured node-specific settings from the cluster.
You configure the node-specific settings for the newly added node manually because binary import options are not useful. The only recommended binary import option into a cluster is "Import everything except network settings and licenses" from the Maintenance > Import/Export > Configuration page, which restores cluster-wide configuration (sign-in, realms, roles, resource policies etc.) from a backup binary file. Because this option skips node-specific settings, you must perform step 2 manually to populate the newly joined node with the right set of node-specific settings.
Restarting or Rebooting Cluster Nodes
When you create a cluster of two or more nodes, the clustered nodes act as a logical entity. When you reboot one of the nodes using either the serial console or the admin console, all nodes in the cluster restart or reboot.
To reboot only one node:
1.Select System > Clustering > Status to disable the node you want to restart or reboot within the cluster.
2.Select Maintenance > System > Platform.
3.Reboot the node, then enable the node within the cluster again.
The system reconciles session state with the Infranet Enforcer upon restart or cluster failover. If the Infranet Enforcer is running ScreenOS 6.0r2 or later, a Policy Secure restart or failover does not interrupt network traffic of existing sessions, as long as the restart or failover occurs within two minutes.
The following figure shows the System Maintenance page.
Modifying the Cluster Properties
To modify the cluster properties:
1.Select System > Clustering > Properties.
The following figure shows the properties of the Clustering page.
2.Complete the configuration with following details.
Settings | Actions |
Identifies the cluster. | |
Configuration Settings | |
Active/Passive configuration | Runs a cluster pair in active/passive mode. Then specify an internal VIP (virtual IP address) and an external VIP if the external port is enabled. |
Active/Active configuration | (Default) Runs a cluster pair in active/active mode. This configuration runs a cluster of two or more nodes in active/active mode using an external load balancer. To change a two-unit active/passive cluster to an active/active cluster with more than two nodes, first change the configuration of the two-unit cluster to active/active and then add the additional nodes. |
Synchronization Settings | |
Synchronize log messages | Propagates all log messages among the devices in the cluster. |
User/Session Synchronization Configuration only cluster | Select this option to disable synchronization of session data and to replicate only configuration data and user records (for example, web bookmarks, NFS and windows shared files, terminal servers, telnet sessions, SAM, preferences, and passwords).
Enabling this option limits data transfers between the cluster nodes. User and Session specific limits are only enforced on the node and not across the cluster. Do not activate this feature when the user sessions are in progress. Session failover is not supported in configuration only cluster mode. |
Synchronize user sessions | Synchronizes all user session information (for example, instances of access to intranet services) among all the devices in the cluster. |
Synchronize last access time for user sessions | Propagates the latest user access information across the cluster. |
If you select both the Synchronize log messages and Synchronize user sessions check boxes, everything is replicated on the cluster nodes, including networking information. Even though networking information, including syslog and SNMP settings, can be configured per node or per cluster, all of the networking information is synchronized between nodes when these two options are set. If your cluster node configurations diverge because of changes made to one node while another is disabled or unavailable, the system manages the remerging of the configurations automatically for up to 16 updates. Beyond the maximum number of allowable updates, you might need to intervene and remerge the configurations manually. In some instances, the system might be unable to remerge the configurations if there is not enough overlapping configuration information between two nodes to manage the internode communication. For example, for a two-node cluster in which the two nodes are partitioned from each other because of a network outage, if the internal network IP address of one of the nodes changes in one of the partitions, the two partitions are unable to rejoin, even when the network is repaired. In such a case, you must remerge the configurations manually. | |
Network Healthcheck Settings | |
Number of ARP Ping Failures | Specifies the number of ARP ping failures allowed before the internal interface is disabled. |
Disable external interface when internal interface fails | Disables the external interface of the device if the internal interface fails. |
Advanced Settings | |
Enable Advanced Settings | Select the Advanced Settings check box to specify the timeouts for the underlying cluster system. Do not change any values under this setting unless instructed to do so by Ivanti Technical Support. |
Network Type | Select the appropriate network type. Network type selection controls the timeouts used by the underlying cluster system. Change this value only when you observe repeated cluster partitions that may be related to long network delays or significant load in any of the cluster nodes. A non-default network type cannot be used in conjunction with non-default timeout multipliers. If a non-default network type is picked, the timeout multiplier will silently get reset to the default value. |
Timeout Multiplier | Default cluster timeouts have been picked to be optimal for typical cluster installations. Administrators have the ability to adjust the cluster timeouts over a linear scale of 1-20. Smaller timeouts result in faster failure detection. Larger timeouts minimize the risk of cluster splits during transient network glitches. The system can be instructed to pick a reasonable default for the current cluster configuration by specifying a value of 0. A non-default timeout multiplier can only be used in conjunction with the default network type. If a non-default network type is picked, the timeout multiplier will silently get reset to the default value. |
3.Click Save Changes.
Synchronizing the Cluster State
State synchronization occurs only by means of the internal network interface cards (NICs), and each cluster member is required to possess the cluster password to communicate with other members. Cluster members synchronize data when there is a state change on any member. Cluster state data is either persistent-permanently stored on the device-or transient-stored on the device only for the user's session. State data is divided into the following major categories:
•System state - This state is persistent and does not change often.
•Network settings
•Authentication server configurations
•Authorization group configurations, such as access control list, bookmark, messaging, and application data
•User profile - This data can be either persistent or transient, depending on whether or not you have enabled persistent cookies and persistent password caching. If you have not enabled these features, then the data is transient and falls into the next category.
•User bookmarks - persistent
•Persistent user cookies - if the persistent cookies feature is enabled, the device stores user cookies for web sites that issue persistent cookies
•Persistent user passwords - if the password caching feature is enabled, the user can choose to store her credentials for applications and web sites
•User session -This state is transient and dynamic. The user session consists of the following data:
•The user session cookie
•Transient user profile information, which includes cookies and passwords stored only for during the user's session
•Monitoring state - This persistent information consists of log messages.
Whether you deploy a cluster in active/passive or active/active mode, the Ivanti Connect Secure is responsible for synchronizing data between cluster members. The Ivanti Connect Secure synchronizes all system data, user profile data, and the user session cookies immediately, so if one cluster member goes off-line, users do not need to sign in to the device again. A small amount of latency occurs when the device synchronizes user session profile and monitoring state data, so if a member goes off-line, the user may need to sign in to some back-end Web applications again and administrators may not have access to the logs on the failed machine.
If you notice too much latency occurring on one or more nodes, you might need to change the Clustering Timeouts Settings.
When you add the device to a cluster, the cluster leader does not send log messages to the new member. Log messages are also not synchronized between cluster members when one member restarts its services or when an offline machine comes back online. Once all machines are online, however, log messages are synchronized.
If you are running an active/active cluster, you must not allow the cluster to switch to active/passive mode unless the active/active and active/passive clusters share compatible spread timeout settings.
You may also configure synchronization settings to improve performance:
•Specify the synchronization protocol - When running three or more devices in a multi-unit or multi-site cluster, you can choose to use the synchronization protocol (Unicast, Multicast, or Broadcast) that best suits your network topology.
•Synchronize log messages - Log messages may create a huge payload on the network and affect cluster performance. This option is disabled by default.
•Synchronize user sessions - This option synchronizes all user session information (instances of access to intranet services, for example) among all devices in the cluster.
You must select this option if your cluster is an IF-MAP client. If you do not select this option, your IF-MAP client may not work as expected.
•Synchronize last access time for user sessions-This option allows you to propagate user access information in the cluster. If this option is the sole synchronization item among the cluster nodes, you can significantly reduce CPU impact among the cluster devices.
•If you configure your cluster as active/passive, the Synchronize user sessions and Synchronize last access time for user sessions options are automatically checked.
•If you select both the both Synchronize log messages and Synchronize user sessions check boxes, everything is replicated on the cluster nodes, including networking information. Even though networking information, including syslog and SNMP settings, can be configured per node or per cluster, all of the networking information is synchronized between nodes when these two options are set.
•If your cluster node configurations have diverged due to changes made to one node while another is disabled or unavailable, the devices manage the remerging of the configurations automatically, for up to 16 updates. Beyond the maximum number of allowable updates, you may need to intervene and remerge the configurations manually. In some instances, the devices may be unable to remerge the configurations if there is not enough overlapping configuration information between two nodes to manage the internode communication.
For example, given a two-node cluster in which the two nodes are partitioned from each other because of a network outage, if the internal network IP address of one of the nodes gets changed in one of the partitions, the two partitions are unable to rejoin, even when the network is repaired. In such a case, you must manually remerge the configurations.