|
Home > |
|---|
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.
Note: 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.
Note: 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.)
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. In the previous section, we indicate that HSM firmware can differ between members of an HA group, but this is not intended for ongoing operation; rather, it allows you to keep all members within a group while you individually update their firmware, to ensure minimal disruption during the updates.
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, see "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]".