Guidelines and Recommendations For Updating or Converting HA Member Partitions

This section lists some general guidelines for users that are updating High Availability (HA) member partitions to a new firmware version or converting them to V0 or V1. Refer to the following relevant topics before reading the information in this section:

>Updating the Luna HSM Firmware

>Special Considerations for Luna HSM Firmware 7.7.0 and Newer

>Compare Behavior of Pre-Firmware 7.7, and V0, and V1 Partitions

>Converting Partitions from V0 to V1 or V1 to V0

Adhere to the following guidelines and recommendations when you are updating or converting HA member partitions:

>Before beginning the update or conversion process, remove the partition from the HA group and stop all ongoing operations with HA.

>Update or convert members one at a time, leaving the primary member for last.

NOTE   You must update/convert secondary partitions first and the primary partition last. If you do not adhere to this guideline, you may experience issues while updating/converting.

>Resume HA group operation after all members have been updated or converted.

>If HA operation cannot be stopped for an update or conversion, you must be aware of the following constraints and guidelines:

Expect HA functionality (with some caveats) when members have been updated, but not during firmware update to Luna HSM Firmware 7.7.0 (or newer) or during conversion of member partitions from V0 to V1.

Thales does not recommend operating HA groups with mixed firmware and partition versions because the HA group will not work as expected. For proper HA functionality, all members of a working HA group should have the following properties:

Identical firmware versions. As a result, firmware updates should take place while the partition is not a member of an HA group.

Identical partition types; that is, either all partitions are V0 or all partitions are V1. As a result, partition conversions to V0 (which happens as a result of updating from pre-7.7.0 firmware to Luna HSM Firmware 7.7.0 or newer) or V1 should take place while the partition is not a member of an HA group.

Identical history of functionality module (FM) deployment; that is, either all members are FM-enabled or all members are FM-never-enabled, but not some of each.

Converting a partition from V1 to V0 is destructive, so the partition cannot remain an HA member.

Cloning of keys and objects can proceed only from a lower-security environment to a higher-security environment but not in the other direction; that is, cloning of keys and objects can proceed in the following directions:

Older firmware to newer firmware.

Pre-7.7.0 partitions to V0 partitions.

V0 partitions to V1 partitions.

Partitions of an HSM that has had FMs enabled to partitions that have never had functionality modules enabled.

The above constraint has implications for the update and conversion process; that is, the primary partition must be at the same firmware and partition version as the remaining HA member partitions, or lower. If this requirement is not met, attempts to synchronize the HA group will fail. For example, V1 partition can be added to an existing HA group that already has HA members made up of partitions from a pre-7.7.0-firmware HSM. However, when V1 partition becomes the primary member of the HA group, synchronization with remaining member of the HA group will no longer function.

Avoid direct access to individual HA group members when securing with STC. For more information, refer to Avoid direct access to individual HA group members when securing with STC.

>For best results, the client library that enables HA among several HSMs should be up-to-date.