Setting Up an HA Group
Use LunaCM to create an HA group from partitions assigned to your client. This procedure is completed by the Crypto Officer. Ensure that you have met all necessary prerequisites before proceeding with group creation. For a detailed description of HA functionality, see High-Availability Groups.
NOTE Your LunaCM instance needs to update the Chrystoki.conf (Linux/UNIX) or crystoki.ini file (Windows) when setting up or reconfiguring HA. Ensure that you have Administrator privileges on the client workstation.
Back up the SMK in any partition where that SMK is likely to be overwritten, if that SMK is ever likely to be needed to insert (decrypt) any SKS blobs. If an SMK is cloned from one partition to another (such as must be done when adding members to an HA group), a pre-existing SMK already in the target partition is overwritten by the incoming SMK. Any blobs still encrypted with it are lost, unless a backup exists.
Prerequisites
HA groups are set up in LunaCM by the Crypto Officer. Before the CO can perform this setup, however, all HSMs and member partitions must meet the following prerequisites, completed by the HSM and Partition Security Officers.
HSMs
The HSM SO must ensure that all HSMs containing HA group member partitions meet the following prerequisites:
>All HSMs must use the same authentication method (Password/PED). Luna Cloud HSM Services support password authentication only.
>HA groups cannot contain both PCIe HSMs and Network HSMs.
>All must be running one of the supported software/firmware versions. Generally, Thales recommends using HSMs with the same software/firmware for HA. 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 for more information.
>For PCIe HSMs, all HSMs must have the same firmware version installed and must be installed in the same host server that will create the HA group.
>HSM policies 7: Allow Cloning and 16: Allow Network Replication must be set to 1
>HSM policies must be consistent across all HSMs, particularly 12: Allow non-FIPS algorithms. Do not attempt to use an HA group combining HSMs with FIPS mode on and others with FIPS mode off.
A client can have a session with an STC slot, making use of only one appID. When running an HA command if you are already logged in or have a session open with an appID to a member of that HA slot, you will not be able to log into that slot at this time. When you run a command like "ha list", lunacm logs into each member using a randomly created appID. If any one of these slots already has a login session, such an attempt is rejected with CKR_ACCESS_ID_ALREADY_EXISTS. The workaround is to close the problem session first.
Partitions
The Partition SO must ensure that all partitions in an HA group meet the following prerequisites:
>All partitions must be visible in LunaCM on the
>All partitions must be initialized with the same cloning domain:
•Password-authenticated partitions must share the same domain string.
•PED-authenticated partitions must share the same red domain PED key.
>Partition policies 0: Allow private key cloning and 4: Allow secret key cloning must be set to 1 on all partitions.
>Partition policies must be consistent across all member partitions.
>The Crypto Officer role on each partition must be initialized with the same CO credential
>PED-authenticated partitions must have partition policies 22: Allow activation and 23: Allow auto-activation set to 1. All partitions must be activated and have auto-activation enabled, so that they can retain their login state after failure/recovery. Each partition must have the same activation challenge secret set (see Activation and Auto-activation on Multi-factor- (PED-) Authenticated Partitions)
NOTE If HSM policy 21: Force user PIN change after set/reset is set to 1 (the default setting), the Crypto Officer must change the initial CO credential before using the partition for cryptographic operations
To set up an HA group
1.Decide which partition will serve as the primary member (see The Primary Partition). Create a new HA group, specifying the following information:
•the group label (do not call the group "HA")
• the Serial number OR the slot number of the primary member partition
•the Crypto Officer password or challenge secret for the partition
lunacm:>hagroup creategroup -label <label> {-slot <slotnum> | -serialnumber <serialnum>}
lunacm:> hagroup creategroup -label myHAgroup -slot 0
Enter the password: ********
New group with label "myHAgroup" created with group number 1154438865287.
Group configuration is:
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: Not Available
Synchronization: enabled
Group Members: 154438865287
Needs sync: no
Standby Members: <none>
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
Command Result : No Error
LunaCM generates a serial number for the HA group (by adding a "1" before the primary partition serial number), assigns it a virtual slot number, and automatically restarts.
lunacm (64-bit) v7.3.0. Copyright (c) 2018 SafeNet. All rights reserved.
Available HSMs:
Slot Id -> 0
Label -> par0
Serial Number -> 154438865287
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
Slot Id -> 1
Label -> par1
Serial Number -> 1238700701509
Model -> LunaSA 7.3.0
Firmware Version -> 7.3.0
Configuration -> Luna User Partition With SO (PW) Key
Export With Cloning Mode
Slot Description -> Net Token Slot
Slot Id -> 5
HSM Label -> myHAgroup
HSM Serial Number -> 1154438865287
HSM Model -> LunaVirtual
HSM Firmware Version -> 7.3.0
HSM Configuration -> Luna Virtual HSM (PW) Key Export With
Cloning Mode
HSM Status -> N/A - HA Group
Current Slot Id: 0
2.Add another partition to the HA group, specifying either the slot or the serial number. If the new member contains cryptographic objects, you are prompted to decide whether to replicate the objects within the HA group, or delete them.
lunacm:>hagroup addmember -group <grouplabel> {-slot <slotnum> | -serialnumber <serialnum>}
lunacm:> hagroup addmember -group myHAgroup -slot 1
Enter the password: ********
Warning: There are objects currently on the new member.
Do you wish to propagate these objects within the HA
group, or remove them?
Type 'copy' to keep and propagate the existing
objects, 'remove' to remove them before continuing,
or 'quit' to stop adding this new group member.
> copy
Member 1238700701509 successfully added to group myHAgroup. New group
configuration is:
HA Group Label: myHAgroup
HA Group Number: 1154438865287
HA Group Slot ID: 5
Synchronization: enabled
Group Members: 154438865287, 1238700701509
Needs sync: no
Standby Members: <none>
Slot # Member S/N Member Label Status
====== ========== ============ ======
0 154438865287 par0 alive
1 1238700701509 par1 alive
Please use the command "ha synchronize" when you are ready
to replicate data between all members of the HA group.
(If you have additional members to add, you may wish to wait
until you have added them before synchronizing to save time by
avoiding multiple synchronizations.)
Command Result : No Error
Repeat this step for each additional HA group member.
NOTE By default, lunacm:>hagroup addmember automatically adds a Luna Cloud HSM service as a standby HA member. If you prefer to use the Luna Cloud HSM service as an active HA member, you must first edit the following toggle in the Chrystoki.conf/crystoki.ini configuration file (see Configuration File Summary):
[Toggles]
lunacm_cv_ha_ui = 0
3.If you are adding member partitions that already have cryptographic objects stored on them, initiate a manual synchronization. You can tell whether this step is required by checking the line Needs Sync : yes/no in the HA group output. This will also confirm that the HA group is functioning correctly.
lunacm:> hagroup synchronize -group <grouplabel>
4.[Optional] If you created an HA group out of empty partitions, and you want to verify that the group is functioning correctly, see Verifying an HA Group.
5.Specify which member partitions, if any, will serve as standby members.
See Setting an HA Group Member to Standby.
6.Set up and configure auto-recovery (recommended). If you choose to use manual recovery, you will have to execute a recovery command whenever a group member fails.
See Configuring HA Auto-Recovery.
7.[Optional] Enable HA Only mode (recommended).
See Enabling/Disabling HA Only Mode.
8.[Optional] Configure HA logging.
See HA Logging for procedures and information on reading HA logs.
The HA group is now ready for your application.
