|
Home > |
Administration Guide > High Availability (HA) Configuration and Operation
|
|---|
This chapter explains Luna HA, and provides instructions and options for various high availability scenarios. It contains the following sections:
•"Cloning/HA Replication Security"
•"HA Replacing a Failed Luna SA"
Luna HSMs can be configured in HA groups in two ways:
•HSMs directly connected to the controlling LunaClient
–two or more Luna G5 HSMs, for redundancy
–multiple Luna PCI-E cards, for performance (roughly linear performance increase with each additional card; we normally test 3)
•HSMs remotely, network-connected to the LunaClient
–Luna SA application partitions connected via NTLS or STC (one per Luna SA, for both redundancy and performance)
HA is handled by the client. The LunaClient library acknowledges these constraints:
| Item Supported by Client | Constraints |
|---|---|
| Partitions | Maximum 300 in total (whether HA is involved or not) |
| Virtual slots (HA groups) | Maximum 100 in total |
| Partitions per HA group | Maximum 32 |
The above table refers to application partitions, so there would be one application partition per Luna G5 HSM, or one application partition per Luna PCI-E HSM, or as many as 100 application partitions per Luna SA HSM, however you would not normally include more than one partition from a given Luna SA within any one HA group as that would defeat the redundancy benefit.
An example with Luna SA, using more than one application partition per Luna SA, might be a software company with a signing server, where multiple Luna SAs at different locations would be configured in HA configuration, each with (say) two partitions, one for signing Windows drivers and applications, another for signing Java applications.
Applications that use Luna PCI-E HSMs in HA (which are necessarily all in the same client computer) are primarily looking for performance, and not redundancy, as the host computer itself represents the single point of failure that could stop the whole operation. HA with Luna SA can realize the benefits of both fail-over redundancy and performance, as each partition in an HA group is on a different Luna SA appliance, possibly in a different physical location, with completely independent power and network connections.
The constraints in the table are theoretical or hard-coded maximums. We do not test anywhere near those limits, as none of our customers has needed that many partitions or HA-group members yet. But in case you are considering an application configuration that might approach those limits, keep in mind that the 300 possible partitions for a client is the outside of the envelope, and the other two constraints shape that envelope. For example, an HA group of one partition would be pointless; you would want at least two in a group, for operation, plus a third for standby redundancy. Therefore, the maximum configuration would be 100 HA groups of 3 member partitions each, managed by the LunaClient running your application.
Another approach could be maximum-size HA groups, so the most you could connect to a single (very powerful...) LunaClient would be nine HA groups of 32 members each, plus a group of 12 to use up the remaining possible partitions that the LunaClient could theoretically address. Again, those limits, however you might care to rearrange them, are theoretical, and would need to be tested before you commit to an operational structure of that scope. Real-world constraints, like network latency, are likely to intrude before you approach the theoretical limits.