|
Home > |
|---|
This page describes the HA-Group concept as it applies to Luna PCI-E HSMs.
For Luna PCI-E, an HA Group is an identified group of Luna PCI-E HSM cards in one workstation or server. The purpose is to provide load balancing among HSM cards on one computer.
The members of the group are identified in the HA section of the Luna configuration file.
A single HSM card can show performance up to 7000 RSA 1024-bit signings per second (assuming ideal conditions). Two Luna PCI-E HSM cards, configured as an HA group, can achieve almost 14000 signings per second, and the increase is linear for additional HSM cards. For asymmetric algorithms, there is little overhead. For symmetric operations, some overhead is noticeable, but performance scales very well, regardless.
Luna PCI-E HA creates a virtual slot against which your application can run, instead of the application making direct use of the individual HSMs. This can be further emphasized by setting the "HAOnly" option, which hides the physical HSM cards from your application, presenting only the virtual slot. Your application does not need to know about physical HSM slots - identity, the number that are present, etc. - it directs all calls to the virtual slot, and receives all responses from the virtual slot.
Luna PCI-E HA is not High Availability as it is usually understood. Failover does occur - a failed member that is restarted does automatically rejoin the group - however, because both/all HSMs in the group are connected to the same computer, that single host is the point of vulnerability.
Individual HA Group members are unaware of each other. HA is controlled at the software level.
A Luna PCI-E HA group cannot include HSMs from more than one host computer.
HA group membership is tracked through the configuration file, but the order of appearance carries no meaning, other than that the primary is the first HSM assigned a call from the newly started client application. Once the application has been in operation against the virtual slot, with physical-slot activity being assigned on a round-robin, least-busy basis, any of the physical slots can be the first to experience a change (addition, deletion of objects) which is then cloned to the other physical slots in the process of synchronization. In normal operation, there is no hierarchy of physical HSMs.
Applications can see all slots - the virtual slot and the physical slots (the HSMs) - and perform actions upon them, unless the "haonly" option is set (which hides all but the virtual slot). However, only object creations and deletions that are ordered at the virtual slot are automatically synchronized to all physical members of the group. If an application addresses a physical slot directly (bypassing the virtual slot) and creates an object, that object becomes an "orphan", residing on just that one slot. The HA group continues to function, but it is unsynchronized. If you (your application) send a call to the virtual slot that needs the orphan object(s), the result could be an error message, since the virtual slot has not been made aware of the objects and has not replicated them across the group.
If you wish to replicate such an "orphan" object, perform synchronization manually.
You can perform such "orphan" actions without problem as long as you ensure that calls to use the object are directed to only the relevant physical HSM. All other calls to the HA group can continue via the virtual slot.
The recommended method is for your application(s) to always deal with the virtual slot, ensuring that synchronization occurs automatically.