|
Home > |
Administration Guide > High-Availability (HA) Configuration and Operation > Using HA With Your Applications
|
|---|
This section describes how HA affects your applications, and describes the settings your can use and actions you can take to mitigate any performance or stability issues.
By default, the client lists both the physical slots and virtual slots for the HA group. Directing applications at the physical slots bypasses the high availability and load balancing functionality. An application must be directed at the virtual slots to activate the high availability and load balancing functionality. A configuration setting referred to as HAonly hides the physical slots, and is recommended to prevent incorrect application configurations. Doing so also simplifies the PKCS #11 slot ordering given a dynamic HA group.
The “haonly” flag shows only HA slots (virtual slots) to the client applications. It does not show the physical slots. We recommend that you use "haonly", unless you have particular reason for not using it. Having "haonly" set is the proper way for clients to deal with HA groups - it prevents the possible confusion of having both physical and virtual slots available.
Recall that automatic replication/synchronization across the group occurs only if you cause a change (keygen or other addition, or a deletion) via the virtual HA slot. If you/your application changes the content of a physical slot, this results in the group being out-of-sync, and requires a manual re-sync to replicate a new object across all members. Similarly, if you delete from a physical slot directly, the next manual synchronization will cause the deleted object to be repopulated from another group member where that object was never deleted. Therefore, to perform a lasting deletion from a single physical slot (if you choose not to do it via the virtual slot) requires that you manually delete from every physical slot in the group, or risk your deleted object coming back.
Also, from the perspective of the Client, a member of the HA group can fail and, with "haonly" set, the slot count does not change. If "haonly" is not set, and both virtual and physical slots are visible, then failure of unit number 1 causes unit number 2 to become slot 1, and so on. That could cause problems if your application is not designed to deal gracefully with such a change.
An application that continuously generates key material will need to have its HA group carefully selected. Contact SafeNet support for help in architecting your HA group for these applications.
Multi-token is a general-purpose demonstration/exercise
tool for SafeNet HSMs. It is not optimized for all tasks. If you run the
extract/insert options (for SIM) in multitoken against SafeNet Network HSM with several
threads against the HA slot, performance appears to be about 10 times
slower than in non-HA single slot mode.
The reason is that in this mode multitoken continuously creates
session objects that need to be replicated to the additional physical HA slots.
This creates
overhead that does not exist in single slot mode.
For optimum
real-life performance, your applications should avoid this approach.
Application developers should be aware that the PKCS #11 object handle model is fully virtualized with the SafeNet HA logic. As such, the application must not assume fixed handle numbers across instances of an application. A handle’s value remains consistent for the life of a process; but it might be a different value the next time the application is executed.
If your applications use the C_FindObjects function to list the objects on an HA slot, the client will iterate between each member of the HA group to determine the list of objects. That is, C_FindObjects queries each HSM/partition in the group, for each object, and creates a virtual object list that contains a virtual object handle for each object found. Because the client must iterate through each HA member, performance is much slower than is observed when querying a single HSM or partition, and degrades linearly for each additional HA group member. For small HA groups containing only a few objects, this is not an issue. If, however, your HA group contains a large number of objects, or consists of several members, application performance may suffer.
To mitigate performance degradation when using the C_FindObjects function to list the objects on an HA slot, we recommend that you structure your applications such that they use C_FindObjects to iterate over the members of the HA group only once, and cache the resulting object list. Subsequent C_FindObjects function calls would then use the cached object list to look up existing objects, and only iterate over the members of the HA group to find new objects, which are appended to the cached object list.
Note: The cached object list is ephemeral, and only exists for the current session. If you restart the application, you must recreate the object list cache. Best practice is to execute C_FindObjects to create the cached object list at application start up.