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.
>HSM and Partition Prerequisites
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 Partition Versions
All partitions in an HA group must be the same version, either V0 or V1 (see V0 and V1 Partitions).
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 iKey.
Common Crypto Officer Credentials
An HA group essentially allows you to log in to all its member partitions simultaneously, using a single credential.
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, especially FIPS mode. Do not attempt to use an HA group combining HSMs with FIPS mode on and others with FIPS mode off.
Sample Configurations
Your ideal HA group configuration depends on the number of HSMs you have available and the purpose of your application(s). Sample configurations for different types of deployment are described below.
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 multiple 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 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.
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. The backup member can be a local HSM or a Luna Cloud HSM service. Refer to Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM.
