General Settings

This page contains settings that apply to the whole cluster including the webapp:

settings-general-main-window

Security settings

Setting	Description
`Inactivity timeout`	The period of time during which a user can be inactive in the webapp (that is, not interact with the system in any way) without any impact on their session. After the timeout expires, the user is logged out of the session and will have to log back in.
`Encrypted Heartbeats`	By enabling this option heartbeats exchanged between cluster nodes will be encrypted. This provides an extra level of security.

Miscellaneous settings

Setting

Description

Storage Web Interface URL (Optional) By entering a valid URL, a custom launcher button will be added to the ZFS->Pools page. When clicked the URL will be opened in a new browser window. This is intended to provide a shortcut the connected storage interface. Note please prefix the URL with http:// or https://

Storage Web Interface Label (Optional) Sets the name of the label on the storage interface launcher button.

All Targets All Ports Some disk arrays don't follow the scsi persistent reservations specification when making key registrations per I_T NEXUS. Instead the registration is shared by all target ports connected to a given host. This causes PGR3 reservations to fail whenever it tries to register a key, since it will receive a registration conflict on some of the paths.

This issue manifests itself when RSF-1 is attempting to place reservation keys on a disk. In the rsfmon log file a message of the form:

MHDC(nnn): Failed to register key on disk

is indicative of this issue. This setting remedies the problem by making a registration unique to each target port.

Log Level

Sets the detail level for logging:

Level	Description
`ERROR`	Log only errors.
`INFO`	Log error and informational messages.
`DEBUG`	Log everything including detailed debug information; Note! this can create large log files over time.

Reservation handling In normal operation the cluster will panic a node if it detects it has lost, or another node has taken, a reservation.

In certain configurations this may not be the desired behaviour, rather it is only when another node takes reservations that a panic should be triggered.

An example of this would be when a JBOD in a mirrored configuration is power cycled thus clearing its reservations. These missing reservations would normally trigger a panic; however, in this case this is not the desired outcome as the cluster will continue to run using the other half of the mirror.