|
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 for 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 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.
HA operation requires that the client(s) be able to access all member HSM partitions and the objects they contain.
For password-authenticated HSMs, this means that the HA client must provide the relevant Crypto Officer or Crypto User password. For PED-authenticated HSM, the group-member partitions must be in logged-in/activated state, and the HA client must provide the relevant challenge secret or password.
Prior to firmware 6.27.0, the Crypto Officer could create public objects, but could not clone them, which blocked HA replication of such objects when Crypto User authentication was used. With HSM firmware 6.27.0 and later, the Crypto User can clone objects that it creates. This facilitates HA operation and synchronization of such objects by Crypto User, without the need for your applications to invoke Crypto Officer authority.
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 Scalable Key Storage) 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.
When an application is addressing a single HSM, all objects in the application partition can be addressed by their handles. When an application is addressing an HA group, a layer of abstraction overlays the physical slots and presents a virtual slot to represent them. All calls and operations by applications should be directed against the virtual (HA) slot. Asserting HAOnly avoids potential problems that can arise if applications interfere directly with physical slots when HA is in force.
For best ongoing functioning of an application with HA, the application makes calls to examine specific objects in the virtual slot, or to perform operations on those objects. Objects are represented by handles in the physical slots, but the same object might have a different handle in two-or-more HSMs. Furthermore, those handles could change if an HSM drops out (fails or loses communication) and is replaced. The HA functionality deals with the differences by establishing a virtual-to-physical mapping, such that an application requests a virtual handle, and HA "invisibly" takes care of matching that virtual handle to actual physical objects.
In order to make those mapping connections, HA refers to a Virtual Object Table that establishes a virtual handle for OUIDs in the group. If the mapping of virtual handle to physical already exists, it was previously determined from that Virtual Object Table. If there is no existing match of virtual handle to physical, then HA looks in the Virtual Handle Table to discover the OUID associated with that virtual handle, then goes to the physical slot (HSM application partition) to retrieve the physical handle that matches the OUID. The physical handle is matched to the virtual handle, and now the application can examine attributes or perform crypto operations on the mapped object, needing only to know the virtual handle.
The next question, of course, is where did the Virtual Object Table come from? The Virtual Object Table, that assigned virtual handles to physical-object OUIDs in the group, was created by HA responding to your application's C_FindObjects call sometime after the client application was launched - that is, the table is ephemeral and must be recreated for each instance of your application. It is then maintained by HA while your application is open. The table is populated:
•partially if your C_FindObjects asks for specific attributes, or
•fully if your C_FindObjects searches for ALL objects.
A non-specific C_FindObjects ALL can be a lengthy process, since it must search through all physical objects. A more narrow, focused and specific C_FindObjects generally takes less time.
If an earlier call to C_FindObjects resulted in a partial Virtual Object Table, and then a later call to C_FindObjects looks for objects that were not previously included, then the Virtual Object Table is expanded incrementally.
The HA client builds a Virtual Object Table for each running application that loads the Luna library.
In the previous section, most of the described action is invisible to your application. Your application makes a call to a crypto slot (the HA virtual slot) and gets a response back. Between those two events, HA is taking care of
•intercepting the call,
•translating virtual to physical,
•launching actions on the appropriate HSM,
•receiving the result, and
•forwarding that result to your application,
•as well as ensuring that any changes in objects on the physical HSM that performed the action are propagated to all members of the HA group.
Some client applications launch once and then run continuously for a long time. In this case, once the mapping of physical object handles to virtual object handles has completed, the Virtual-to-Physical table is available and can be referred instantly, with no need to rebuild (the time-consuming part).
Some client applications launch, perform a search, then close quickly. If such an application can search by description, handles, or other attributes, then minimal performance penalty is imposed. If such an application (open-and-shut type) performs C_FindObjects ALL before running a call against an object, then this imposes a significant performance penalty, as the complete Virtual Object Table must be constructed each time.
HA needs to be aware of only the objects that your application needs to use; a larger or less-specific search that returns more objects than required by your application is wasteful, and degrades performance unnecessarily.
Note: The cached object list is ephemeral, and only exists for the current session. If you restart the application, HA must recreate the object list cache. Best practice is to execute C_FindObjects to create the cached object list at application start up.
Note: Beginning with release 6.2.1, the initial call to C_FindObjects ALL is optimized, but we still recommend that you avoid running "C_FindObjects" with the "all" option if you can avoid it by using a more limited and focused search.