This section describes important considerations and constraints to keep in mind as you plan your Client-mediated High-Availability (HA) group deployment (NOTE: Not to be confused with Clusters and Keyrings). The benefits of HA are described in detail in High-Availability Groups. There are several sample configurations described in this section that take advantage of different HA features. Depending on your organization's security needs, you might choose one of these configurations, or your own variation.
>HSM and Partition Prerequisites
•Performance and Load Balancing
If you plan to create an HA group consisting of different kinds of Luna HSMs, refer also to:
>Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM, Password or Multifactor Quorum
HSM and Partition Prerequisites
The HSM partitions you plan to use in an HA group must meet the following prerequisites before you can use them in an HA group.
Compatible HSM Software/ Firmware Versions
Generally, Thales recommends using HSMs with the same software/firmware in HA groups; different versions have different capabilities, and a mixed-version HA group is limited to those functions that are common to the versions involved. This means they have access to fewer cryptographic mechanisms, or have different restrictions in FIPS 140 approved configuration (formerly FIPS mode). However, mixed-version HA groups containing Luna 6 and 7 member partitions and Luna Cloud HSM services are supported. See Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM, Password or Multifactor Quorum for more information.
Common Cloning Domain
All key replication in an HA group uses the Luna cloning protocol, which provides mutual authentication, confidentiality, and integrity for each object that is copied from one partition to another. Therefore, all HA group member partitions must be initialized with the same cloning domain. If you are planning to combine already-existing partitions into an HA group, you must first re-initialize them using the same domain string or red PED key.
Common Crypto Officer Credentials
An HA group essentially allows you to log in to all its member partitions simultaneously, using a single credential.
Formerly, it was not possible to create an HA group made up of both password- and multifactor quorum-authenticated partitions. From the advent of Extended Domain Management (see Allow Extended Domain Management ) it is possible to mix authentication types as long as:
>the affected partitions share the same cloning domain
>the multifactor quorum partition is activated (and preferably also auto-activated)
>the challenge secret for the multifactor quorum partition is the same as the password for the password authenticated partition.
Common HSM/Partition Policies (FIPS 140 approved configuration [formerly FIPS mode])
Generally, all HSMs/partitions used in an HA group must have the same policy configuration.
If you are planning to set up an HA group with a mix of FIPS and non-FIPS partitions as members, note the following:
>If you are using Luna HSM Client 10.4.0 or newer, you can set up an HA group with a mix of FIPS and non-FIPS partitions as members. However, some limitations must be considered. For more information, refer to Key Replication.
>If you are using Luna HSM Client 10.3.0 or older, you cannot set up an HA group with a mix of FIPS and non-FIPS partitions as members.
Functionality Modules
If you intend to use Functionality Modules (FMs) with your HA group, all HSMs containing HA group members must have FMs enabled and they must all have the same FM(s) loaded.
Sample Configurations
Your ideal HA group configuration depends on the number of HSMs you have available and the purpose of your application(s).
Performance and Load Balancing
If your application is designed to perform many cryptographic operations as quickly as possible, using keys or other objects that do not change often, you can create a large HA group using partitions on many HSMs. This deployment uses load balancing to provide linear performance gains for each HSM added to the group.
For example: your application uses keys stored on the HSM to perform many encrypt/decrypt or sign/verify operations. You want to minimize transaction latency by providing enough HSMs to handle capacity.
The Luna HSM Client allows HA groups with up to 32 member partitions. The best approach in this example is to add enough group members to handle the usual number of operations, plus enough extra members to handle periods of high demand.
TIP HA Benefits
While client-mediated HA can have benefits with respect to
>up time
>redundancy and failover
>performance increases
...be aware that HA also comes with costs, and that there are exceptions.
Replication of objects across the group takes time; this happens when objects are created or updated via the HA virtual slot.
Finding objects takes longer when multiple partitions are being searched.
Maximum benefit from HA is achieved when objects are created once and used many times, where
>all operations by your application should be directed toward the virtual slot, which takes care of replicating objects, and updates that are performed on objects, to all member partitions/slots and,
>all operations by your application should generally not be directed toward individual slots (in fact, the 'physical' slots that make up an HA group should be hidden by the HAOnly configuration option and not addressed directly) or you risk
•breaking synchronization among members,
•skew of contents with differing versions of objects or keys in different member slots
•error conditions if a call is made against the virtual HA slot and all members do not have the key or object that is expected to undergo parallel operations in the member partitions/slots
If your application creates objects frequently, against the HA virtual slot, the automatic replication across all slots will slow the overall performance. In the case where objects or keys are created to be used once it can be useful to address individual 'physical' slots independently. In such case, you retain standby/rollover advantage of HA, just not a performance enhancement. As soon as keys and objects are no longer useful, they must be deleted, or HA performance is affected by the lookup burden.
Redundancy and Failover
If your application requires continuous, uninterruptible uptime, operations assigned to an HA group are reassigned to other group members in the event of a member failure (see Failover for details). Additional group members can be added and set to standby mode for an extra layer of redundancy (see Standby Members for details).
To maximize the use of your HSMs, plan which member partitions you will set to standby mode. Although the configuration above is a straightforward example of an HA group with a single standby member, it is not an ideal production configuration, because the standby member is idle unless all the other members fail. The configuration below is a more useful implementation of two HA groups, each with standby members on the other's HSMs.
As depicted below, applications can be deployed in geographically dispersed locations. In this scenario, Luna’s standby capability allows you to use the HSMs in Datacenter B to cost-effectively improve availability for the local HA group at Datacenter A, and vice-versa. This approach allows the HA groups to avoid using remote HSMs with high latency, unless they are urgently required. If all local members fail, the standby partitions are automatically promoted to active status.
Automatic Remote Backup
Since the contents of member partitions are always kept up-to-date, you can use an HA group to keep an automatic backup of your cryptographic objects. Set the backup member to standby mode so that it does not perform operations. If the regular member(s) fail, the standby member takes over operations.
HA Group Sharing
Generally, an HA group is defined on a single client, which runs an application against the virtual HA group. You can share the HA group across multiple clients by assigning all member partitions to both clients and creating the HA group independently on each one.
TIP When an HA group is shared across multiple clients, the group can be defined with a different primary member (the first partition assigned to the group) on each client. This approach optimizes an HA group to distribute the key management and/or multi-part cryptographic operation load more equally.
