Show the Table of Contents
Administration & Maintenance - HA & Load Balancing
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:
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.
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.
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.
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.
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".
If your situation requires that some HA group members be active, while others are kept synchronized, but in standby mode, see "HA Standby [optional]".
Show the Table of Contents