|
Home > |
|---|
This section deals with reconnection of the operating client to the HA group, when the client has lost connection to all members of the HA group. This might occur due to network connectivity issues, or if a socket is closed by any of:
•firewall rules/operation
•switch problems
•actions of operating systems, including User Account Control (UAC)
•settings and actions of ESXi hosts
•migration of running Virtual Machines (such as using VMotion)
•other causes
If an application is Java or C based, then the application can call c_finalize, c_initialize, c_opensession, and c_login in order to continue without need for an application restart. But when, for example, an application is using Microsoft-based products with LunaCSP or LunaKSP, there is no opportunity to perform the sequence of calls to resume operation. We address this problem with improvements to HA recovery mode, in which the PKCS#11 context and sessions are preserved.
Older versions of HA used a passive recovery process that was triggered only in conjunction with a PKCS#11 library call. This method was not sufficiently robust, and was replaced in release 6.2 by active automatic recovery using an HA Active Recovery Thread (ARCT). The ARCT sends a non-session-based message that is processed by NTLS. This allows recovery as soon as a failed member returns, and does not wait for a PKCS#11 operation. Thus, if a failed member returns to duty before an active member fails, then synchronization occurs immediately, and the secondary member is ready to take over from the active member if that now fails.
Members can reconnect without the need to call finalize/initialize in the client application, which allows, for example multiple services that use a single JVM to recover connections independently.
In the event that all HA members failed to respond to the ARCT managing message, the HA slot was deemed to be unrecoverable.
Note: As of release 6.2.2, "passive" recovery mode is discontinued, and two modes of active recovery are available:
"activeBasic" using manual opening of session and manual login
and
"activeEnhanced" with automatic reopening of sesseion and auto login
The above feature discussion dealt with scenarios where individual HA group members suffered a fault or lost network connection with the client, but left a client-and-HA group vulnerable to the situation where a connection failure cut the client off from the entire HA group.
With Client Release 6.2.2, the client HA context is preserved, and Token Object status is retained, allowing reconnection to the HA group without need to restart client applications, and with no need to finalize the existing session and start a new one. Only ephemeral session objects are lost. In summary, previous enhancements improved the handling where individual members were disconnected, but the client maintained connection to at least one group member. The enhancement described here handles the situation where the HA client loses contact with the entire group; it can now recover and resume operation if the connection is restored.
OPTION:hagroup recoverymode -mode activeBasic implies that context is automatically preserved, but the recovery from a complete client disconnection and reconnection requires intentional manual intervention. The known object handles (result of the most recent findobject search) allow the application to continue to use those known-object handles after the owner of the application manually intervenes to reopen a session and re-login.
This allows customers, who wish to do so, to use the HA feature while conforming to PKCS#11 standard handling after a CKR_TOKEN_NOT_PRESENT error.
OPTION:hagroup recoverymode -mode activeEnhanced implies that context is automatically preserved (including known-object handles), and the recovery from a client disconnection and reconnection does not require any manual intervention. Reopening a session and re-logging-in are automatic.
This option serves customers who require hands-off recovery.
The boundaries of this feature are established by the general HA settings. That is, the ability to reconnect from a total separation of the client from its HA group is constrained by the retry, interval, and timeout settings that govern the loss and recovery of individual members from and to the group. No additional settings are possible or required.
The number and frequency of connection retries for an individual member also applies to retries for the entire group. Any limit that you have set, after which the client will no longer attempt to reconnect to a member, is also the limit after which the client will no longer attempt to reconnect to a lost group, and will need manual intervention.
LunaCM commands affected include hagroup recoverymode and hagroup listgroups
The feature is useful when your application is making use of token objects. Use activeBasic mode when strict PKCS#11 compliance is necessary. Use activeEnhanced mode when hands-free resumption of your application upon HA reconnect is the primary concern.
1.Configure an HA group, as instructed in Configuring HA
2.HA reconnect depends on HA autoRecovery. Enable HA autoRecovery by setting the recovery retry count with hagroup retry :
lunacm:> hagroup retry -count -1
3.Specify the interval, in seconds, between retry attempts with command hagroup interval :
lunacm:> hagroup interval-interval 120
4.Enable HAOnly with command hagroup haonly :
lunacm:> hagroup HAOnly enable
5.HA logging is highly recommended. Set it with command hagroup halog :
lunacm:> haGroup halog -maxlength 2560000 HA Log maximum file size was successfully set to 2560000.
Command Result : No Error
lunacm:> hagroup halog -path "c:\Program Files\SafeNet\LunaClient\halog" HA Log path successfully set to c:\Program Files\SafeNet\LunaClient\halog. Command Result : No Error
6.Set the recovery mode to "activeEnhanced" with command hagroup recoverymode :
lunacm:> hagroup recoverymode -mode activeEnhanced
7.Resume using your application with the HA group.
Note: Use of HA Auto Reconnect is transparent to your application. You can change between activeBasic and activeEnhanced modes without restarting your application.
Note: If you encounter error CKR_TOKEN_NOT_PRESENT, modify your application to retry the operation every minute.
If your application is generating session objects, those are not preserved. They will need to be recreated, and will appear with new handles.