|
Home > |
|---|
For Luna G5 , an HA Group is an identified group of Luna G5 HSMs attached to one workstation or server. The purpose is to provide load balancing among HSMs connected to one computer. The members of the group are identified in the HA section of the Luna configuration file.
A single Luna G5 HSM can perform about 200 RSA 1024-bit signings per second (assuming ideal conditions and 10 threads). Two Luna G5 HSMs, configured as an HA group, are good for about 400 signings per second in the same conditions. For asymmetric algorithms, there is little overhead. For symmetric operations, some overhead is noticeable, but performance scales with additional units, regardless.
Luna G5 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 HSMs 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 G5 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 Luna Client software level.
A Luna G5 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.