High Availability and SKS
To address performance and availability requirements SKS supports high availability configurations similar to Luna HSM Cloning models, with some minor differences. High availability and load balancing is implemented in the Luna Cloud HSM software and is completely transparent to the application, in that the application is configured to use a virtual slot and not a physical slot on the HSM.
One difference, from cloning HSMs in HA configuration is that, for SKS HA, the hagroup addmember command clones the SMK from the initial SKS application partition to all other group member partitions as they are added. Thereafter, your application deals with the HA virtual slot, and HA operation is automatic.
NOTE V1 partitions: If you add an application partition with an existing SMK to an HA group, the primary member's SMK overwrites the existing SMK of the joining partition.
If a partition's SMK has ever been used to encrypt important SKS objects, save a backup of the SMK before adding that partition to any HA group.
NOTE If a remote partition is involved (Network HSM) on either side of the SMK cloning operation, the HSM that contains the remote partition must have Network Replication enabled. See HSM Capabilities and Policies "Policy 16 - Allow network replication".
When the application needs to perform a cryptographic operation, it employs the SKS API call, which imports an SKS object into the HSM. In an HA configuration, the Luna HSM Client also replicates the SKS blob to all HSMs that have been included in the defined HA group (by performing sksExtract from the source partition and sksInsert into the target partition as a single, combined operation, repeated for each), unless HA synchronization is turned off. When the application requests the "HSM" to perform a cryptographic operation (sign, encrypt, decrypt, etc.) the Luna HSM Client load balances the request to the application partition that is available, in essence making the SKS operation stateless. The SKS operation succeeds because all partitions in the HA group have a copy of the imported SKS object.
Replication of objects in HA is accomplished by SKS feature's SIMextract
and SIMinsert
in one call, transparently.
TIP If your primary use-case is to insert a key and use it for one signing operation, then consider using the multisign API for better performance with SKS under HA, since invoking multisign would use the key on just the one physical partition, and would avoid the overhead of having the inserted key replicated unnecessarily to other HA group members.
NOTE HA failover is not supported in the case of member failure during a SIMInsert, SIMExtract, or SIMMultisign operation.