|
Home > |
|---|
By default, all members in an HA group are treated as active so that they are kept current with key material and are used to load-balance cryptographic services. In some deployment scenarios, however, it makes sense to define some members as standby. Standby members are registered just like active members except that they are defined as “standby” after they are added to the HA group.
As depicted below, applications can be deployed in geographically dispersed locations. In this scenario, you can use Luna’s standby capability to use the HSMs in the remote data center to cost-effectively improve availability. In this mode, only the local units (non-standby) are used for active load-balancing. However, as key material is created, it is automatically replicated to both the active (local) units and standby (remote) unit. In the event of a failure of all local members, the standby unit is automatically promoted to active status. You can use this feature is to reduce costs, while improving reliability. This approach allows remote HSMs that have high latency to be avoided when not needed. However, in the worst case scenario where all the local HSMs fail, the remote member automatically activates itself and keeps the application running.
Note: In normal operation, the HA standby units do not perform any cryptographic operations. However, the HA service must log into all units in a group (C_OpenSession/Login is performed against all members), including standby units. This is necessary because, in the case where the standby unit is called into action, it must already be up-to-date with respect to key material that is being used in the group - it cannot synchronize with HSMs that have failed or that have gone off-line. Therefore, when the HA group consists of PED-authenticated HSMs, they must all be Activated, including the standby HSM(s).
Standby members become active only to keep the group alive. In an HA group that includes more than one standby member, if all active members go down/off-line, only one standby member becomes active in the group. Other standby members remain on standby until/unless that first standby member goes down, at which point the next standby member becomes active.
In other words, in an HA group, the load-sharing and redundancy capability is as large as all the active members, but if all active members become unavailable to the application, then the group load-sharing and redundancy consists of one member, even if other standby members are still available.
Note: Member configuration should be complete before implementing an HA group. Changing an HSM's status from active to standby while it is performing cryptographic operations may result in unexpected behavior.
In Configuring HA, we created an HA group with label "myHAgroup" and group number 742276409, with two active members, serial number 65003001 and serial number 65005001.
1.Create a third member, as previously described, and add it to the HA group.
lunacm: hagroup addmember -group 742276409 -serialnumber 66010002
Member 65005002 successfully added to group 742276409.
Group configuration is: HA Group Label: myHAgroup
HA Group Number: 742276409 HA Group Slot ID: Not Available Synchronization: enabled
Group Members: 65003001, 65005001, 66010002
Needs sync: no Slot # Member S/N Member Label Status ====== ========== ============ ====== 0 65003001 sa175legpar1 alive 1 65005001 sa172legpar1 alive 1 66010002 sa172legpar1 alive Command Result : No Error LunaCM v6.0.0 - Copyright (c) 2006-2015 SafeNet, Inc. Available HSMs: Slot Id -> 0 Label -> sa175legpar1 Serial Number -> 65003001 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 1 Label -> sa172legpar1 Serial Number -> 65005001 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 2 Label -> sa177legpar1 Serial Number -> 66010002 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 3 HSM Label -> myHAgroup HSM Serial Number -> 742276409 HSM Model -> LunaVirtual HSM Firmware Version -> 6.22.0 HSM Configuration -> Luna Virtual HSM (PW) Signing With Cloning Mode HSM Status -> N/A - HA Group Current Slot Id: 0
2.Set the member to standby status.
lunacm: hagroup addstandby -group 742276409 -serialnumber 66010002
Member 65005002 successfully added to group 742276409.
Group configuration is: HA Group Label: myHAgroup
HA Group Number: 742276409 HA Group Slot ID: Not Available Synchronization: enabled
Group Members: 65003001, 65005001, 66010002
Needs sync: no Slot # Member S/N Member Label Status ====== ========== ============ ====== 0 65003001 sa175legpar1 alive 1 65005001 sa172legpar1 alive 1 66010002 sa172legpar1 standby Command Result : No Error LunaCM v6.0.0 - Copyright (c) 2006-2015 SafeNet, Inc. Available HSMs: Slot Id -> 0 Label -> sa175legpar1 Serial Number -> 65003001 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 1 Label -> sa172legpar1 Serial Number -> 65005001 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 2 Label -> sa177legpar1 Serial Number -> 66010002 Model -> LunaSA Firmware Version -> 6.22.0 Configuration -> Luna User Partition, No SO (PW) Signing With Cloning Mode Slot Description -> Net Token Slot Slot Id -> 3 HSM Label -> myHAgroup HSM Serial Number -> 742276409 HSM Model -> LunaVirtual HSM Firmware Version -> 6.22.0 HSM Configuration -> Luna Virtual HSM (PW) Signing With Cloning Mode HSM Status -> N/A - HA Group Current Slot Id: 0