Planning Your HA Group Deployment

This section describes important considerations and constraints to keep in mind as you plan your High-Availability (HA) group deployment. 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

>Sample Configuration

Performance and Load Balancing

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 Firmware Versions

All HSMs in an HA group must have the same firmware version installed.

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. Password-authenticated partitions must all be initialized with the same Crypto Officer password. Multifactor Quorum-authenticated partitions must all be initialized with the same black Crypto Officer PED key and activated with the same CO challenge password.

It is not possible to create an HA group made up of both password- and multifactor quorum-authenticated partitions.

Common HSM/Partition Policies (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. See FM Deployment Constraints for details. FMs are not supported for Luna Cloud HSM services.

Sample Configuration

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.