|
Home > |
|---|
This section provides additional information by answering questions that are frequently asked by our customers.
NTLS will not work through a load-balancer because it is an end-to-end TLS pipe between client and Luna SA. That is why we have our own HA feature.
Yes. At the client, generate the client cert with the command " vtl create -n <any IP address, real or virtual> "
Both client computers must have the Luna SA appliance's server cert in their client-side server-cert folders.
The Luna SA appliance must have the client certificate (built with the virtual IP address)
Also the following lines in the Chrystoki.conf file must point to the same cert and Keyfile on the clustered application servers:
LunaSA Client ={ ClientCertFile=\usr\LunaClient\cert\client\<your-cert-filename>.pem
ClientPrivKeyFile=\usr\LunaClient\cert\client\<your-filename>Key.pem
Luna SA HA function is managed by the Client library. Individual Luna SA appliances are not in any way aware that they are members of an HA group. The Client takes care of that, based on the HA group configuration list.
There is no "master" HSM appliance in the Luna SA HA model. Where you might see or hear mention of a "Primary" member, that refers only to the member that happens to be the first on the configuration list. If you edit the list to place the name of a different Luna SA on top, then that becomes the new HA Group "primary" member.
When the Client has a request for HSM action, that request goes to the first member in the list, unless that member is busy. A member is busy if it has not yet responded to the most recent request that was sent to it.
Luna SA HA works on a "modified round-robin, least-busy" model. What that means is, if the primary member is busy, the client sends its next request to the next non-busy member of the HA Group. In practice, that means the primary member gets all the requests until the volume reaches a level that saturates the ability of the primary - OR a blocking request from another source prevents acceptance of new requests. Therefore, on a 7000 signings/second Luna SA doing exclusively 1024-bit RSA signings, your client would need to have approximately 30 simultaneous threads offering a total of nearly 7000 requests per second before the second member would begin seeing any requests. In other words, until the primary is fully occupied, the HA group looks like it is operating as a "hot-standby" arrangement.
The numbers above are ideal, of course. If you add network latency, or if you increase the key-size, or if you interleave other crypto operations, then the numbers must drop for the individual member, and the secondary member becomes part of the overall performance. And a third member, if you have a third active member in your group, and so on.
If you have any group members set to "Standby" status, then they do not contribute to group performance, even if the client can saturate the active members.
Note: Note that PED operations against an HSM can block crypto operations until the PED operation has returned control to that HSM.
No. HA provides redundancy and can increase performance, but not capacity. Every HSM in an HA group gets synchronized with the other member[s], which means that the content of any one HSM in an HA group must be a clone of the content of any other member of that group. So, with more HA group members, you get more copies, not more space.