HA with Luna SA

This section describes setting up an HA (High Availability) environment with Luna SA.

For mission-critical applications that require uninterrupted up-time, the Luna SA's High Availability (HA) feature allows multiple Luna SA appliances to be grouped together to form one virtual device.

In an HA configuration, service is maintained even if one or several physical devices are unavailable. For example, if three Luna SA appliances are combined into an HA Group, service is maintained even if two Luna SA appliances are off-line. Similar to clustering or RAID technologies, the Luna SA HA feature groups two or more Luna SA appliances together to form a single logical unit, as seen from the Client.

When configured for HA, each Luna SA joins an HA Group, managed at the Client. To Clients, the HA Group appears as a single Luna SA. From an operational perspective, the members in the HA Group share the transaction load, synchronize data with each other, and gracefully redistribute the processing capacity in the event of failure in a member machine, to maintain uninterrupted service to Clients. However, all of this HA function is managed on the Client side. Individual HSMs have no awareness that they are part of an HA group.

Luna SA HA provides load balancing across all Group Members to increase performance and response time while providing the assurance of high-availability service.

All Luna SAs in the HA group are active (rather than one active and the rest passive). Calls are passed from each client application through the Luna SA client-side software (library) to one of the Luna SA appliances in the group on a least-busy basis.

The Luna SA HA feature provides load-balancing and the safety of redundancy, as well as recovery. See "HA Recovery " for more details.

To set up multiple Luna SA appliances in an HA group, follow the instructions in the subsequent pages of this section. You will:

perform the necessary setup on the Luna SA appliances that you will be including in the HA group
- the network setup and naming,
- the policy settings needed for HA,
- the initialization of the Luna SA appliances into a common cloning domain (same red PED Key for Trusted Path Authentication),
- the creation of partitions with matching Passwords across all the Luna SA appliances, and
- the recording of Partition serial numbers
register your Client(s) with each Partition that will be part of the HA group
on your Client, use the vtl utility to configure the HA group and then add the Partitions (on the respective Luna SAs) to that HA group
verify your setup, and then point your Client application at the "HSM" (in whatever manner that is usually done in your application) referring to the "HSM" by the HA group label that you assigned.
(Normally, your application would likely default to performing cryptographic operations in a software engine, with an option to call a named hardware module or "token", instead -- in this case, you give it the HA group label as the HSM/token identifier, rather than pointing to any specific member of the HA group; the SafeNet library makes the HA operation transparent, and your application appears to be dealing with a single hardware engine.)

Mix and Match Software Is Not Supported

All Luna SA appliances in an HA group must be at the same revision level. If you have Luna SA units at different version levels, perform updates as necessary, before attempting to create an HA group -this applies to the system software version, not to the HSM firmware, which can differ among group members.

Mix and Match Firmware Is Not Recommended

Generally, keep all HA members at the same firmware version. As well, all members should have the same optional capability updates applied. If mismatches are permitted among members, synchronization might be disrupted if your application attempts to use a mechanism or a capability that not all members support.

HA Performance

For repetitive operations, like a high volume of signings using the same key, an HA group can expand Luna SA performance in linear fashion as HA group members are added. HA groups of 16 members have undergone long-term, full-throttle testing, with excellent results.

Do keep in mind that simply adding more and more Luna SA appliances to an HA group is not an infallible recipe for endless performance improvement. For best overall performance, all HA group members should be driven near their individual performance "sweet spot", which for Luna SA 5.2 and later is around 30 simultaneous threads per HSM. If you assemble an HA group that is considerably larger than your server(s) can drive, then you might not achieve full performance from all.

The best approach is an HA group balanced in size for the capability of the application servers that will be driving the group, and the expected loads - with an additional unit to provide capacity for bursts of traffic and for redundancy.

Key Generation

An application that continuously generates key material will need to have its HA group carefully selected. Contact SafeNet support for help in architecting your HA group for these applications.

Example

Multi-token is a general-purpose demonstration/exercise tool for Luna HSMs. It is not optimized for all tasks. If you run the extract/insert options (for SIM) in multitoken against Luna SA with several threads against the HA slot, performance appears to be about 10 times slower than in non-HA single slot mode.

The reason is that in this mode multitoken continuously creates session objects that need to be replicated to the additional physical HA slots. This creates overhead that does not exist in single slot mode. For optimum real-life performance, your applications should avoid this approach.

To get started with HA, go to "Configuring HA".

HA Standby Mode [optional]

If your situation requires that some HA group members be active, while others are kept synchronized, but in standby mode, see "HA Standby [optional]".