You are here: B - Administration & Maintenance > HA and Load Balancing > HA with Luna SA

Administration & Maintenance - HA & Load Balancing

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. However, 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.

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.
  However, operation requests directed at the virtual slot are served by the primary (the first member in the client's list) until that member reaches its capacity - at that point, operations are directed to other members.

 

The Luna SA HA feature provides load-balancing and the safety of redundancy, as well as recovery. The recovery ability requires operator intervention and so is not a completely dynamic re-allocation or “hotswap” capability. If a failed/removed unit is replaced, the Client application does not need to be stopped and re-started in order for the new/replaced unit to join the HA Group. However, the administrator must issue commands in order to re-integrate the new/returning appliance to the HA group.

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

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 - not supported

Luna SA was originally the 2U-format rack-mount appliance, based on the K3 keycard/HSM, followed a few years later by a newer-generation 1U-format appliance, based on the K5 HSM. With release 5.0, Luna SA is a newer more resilient 1U device incorporating the K6 HSM. For Luna SA 5.x, HA is supported only with other Luna SA 5.x appliances.

Mixing older Luna SA appliances (pre-5.x) for HA is not a supported configuration.

Performance

 

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 2nd physical HA slot.  This creates a tremendous amount of 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".

See Also