Sun Crypto Accelerator 6000 Board
 
Oracle Key Manager
 
Sun StorageTek Crypto Key Management System
 

PLA-Support>Sun Systems>Sun_Other>Sun Collections>SN-OTH: TAPE-CAP VCAP
 

In this Document

Goal

Solution

Oracle Confidential INTERNAL - Do not distribute to customer (OracleConfidential).
Reason: Procedure is intended to be performed by Oracle Field Engineer

Applies to:

Goal

How to replace SCA6000 crypto card in Oracle Key Manager KMA system

Solution

 DISPATCH INSTRUCTIONS
   WHAT SKILLS DOES THE FIELD ENGINEER/ADMINISTRATOR NEED?: Knowledge of Oracle Key Manager and KMA systems
   TIME ESTIMATE: 60 minutes
   TASK COMPLEXITY: 3

FIELD ENGINEER/ADMINISTRATOR INSTRUCTIONS:
   PROBLEM OVERVIEW: How to replace SCA6000 crypto card in Oracle Key Manager KMA system
   WHAT STATE SHOULD THE SYSTEM BE IN TO BE READY TO PERFORM THE RESOLUTION ACTIVITY?: KMA node should be powered down
   WHAT ACTION DOES THE FIELD ENGINEER/ADMINISTRATOR NEED TO TAKE?:

The SCA6000 (MARS) card has been made a consumable, so cards do not have to be zeroed, and returned.
Part number for the card is 375-3424

Customer should now just scrap the old card.

Customers are no longer required to return the card for repair if/when there is an issue and a replacement is needed.

Card Replacement:
This describes the conditions when a KMA's SCA 6000 card may be replaced (see preconditions) and the procedure for replacing it. The SCA 6000 card may be replaced on any flavor of KMA hardware (X2100, X2200, X4170 M2, or Netra Sparc T4-1) must be running KMS 2.1, or higher.

Pre-conditions:
1. A customer issue has been opened with Tier 3 and a corresponding KMA System Dump has been provided.
2. SCA 6000 card has been determined to be a failed component through failure analysis using the appliance ILOM, a KMS System Dump or recommendation by back-line support (presumably from their own analysis of a KMS System Dump).
3. A new SCA 6000 board has been obtained.
4. The service procedure has been coordinated with the customer to schedule the outage and minimize disruptions to the KMS cluster.
5. For X2100 or X2200 servers the customer should be informed that the "Warranty Void if Broken" stickers will not be replaced. This is a change in procedure and the newer 4170 servers will not come with any tamper evident stickers.
6. KMA was running KMS version 2.1 or higher. KMS 2.0 is not supported for SCA6000 FRU due to likely firmware incompatibilities between the older KMS code and newer preinstalled SCA6000 firmware.
7. Multiple SCA6000 cards are not supported with KMS. The KMS does not exploit the ability to have multiple SCA6000 cards for HA and load balancing. This restriction is a post condition too, a card must be removed before another card is added.

Replacement Procedure:
1. Have the customer perform Modify a KMA Passphrase to block replication to this KMA during the service procedure. By performing this step needless replication traffic from the other KMAs in the cluster will be prevented and the audit logs will not accumulate related error messages.
2. Have the customer perform Shutdown KMA.  This is done via the KMS Console.
  Refer to: KMS - How to Correctly Shutdown and Reboot a KMA Doc ID 1019656.1

3. Power off the server and disconnect the power cord (or cords) from the power supply (or supplies).
4. Follow the documented server (Sun Fire X2100M2 Server Service Manual, Sun Fire X2200M2 Server Service Manual, Sun Fire™ X4170, X4270, and X4275 Servers Service Manual, or Netra SPARC T4-1 Server Service Manual) procedure for servicing PCIe risers and PCIe cards.
5. Remove the failed SCA 6000 card from the server and from the PCIe riser noting which PCIe slot the card was installed into and supply that information later when the card is returned for Failure Analysis.
6. install the new sca6000 card.
7. Follow the documented server (Sun Fire X2100M2 Server Service Manual, Sun Fire X2200M2 Server Service Manual, Sun Fire™ X4170, X4270, and X4275 Servers Service Manual, or Netra SPARC T4-1 Server Service Manual) procedure for "Returning the Server to Operation" and bring the server to standby power state.
8. Use the ELOM/ILOM web interface to access the KMA console in order to observe system startup messages and then use the ELOM/ILOM web interface's Remote Control -> Remote Power Control->Power On to power up the host.
9. Software configuration and possible firmware upgrades to the card will occur as the KMA is brought up. Patience is required here as bootrom and firmware upgrades to the card may be required.
10. Observe the console for any messages indicating SCA 6000 issues with the new card.
11. If any issues with the card are observed on the console then have the customer perform Log into KMS Cluster and obtain a System Dump for Backline support. At this point it may be necessary to reboot the system, remove power and then boot or experiment with reinstalling the board in different PCIe slots before giving up on the card. There are no known restrictions on which PCIe slot can be used.  Note, several reboots may be required in order for the sca6000 card to be properly detected.
12. Verify that the KMA is performing correctly by observing the KMA console and having customer perform Log into KMS Cluster, then List KMA Details and verify that the HSM Status is "Hardware".
13. If HSM Status is "Hardware" then have the customer perform Log KMA into Cluster to have the KMA rejoin and synchronize with the KMS cluster.  Note, that the KMA may be in a locked mode after rejoining the cluster.  The customer can go into the OKM gui and "unlock" the KMA, this will allow the KMA to begin serving encryption keys.
14. The failed SCA 6000 card should be returned to the customer for them to dispose of the card.

OBTAIN CUSTOMER ACCEPTANCE
   WHAT ACTION DOES THE FIELD ENGINEER/ADMINISTRATOR NEED TO TAKE TO RETURN THE SYSTEM TO AN OPERATIONAL STATE?: See above acton plan

PARTS NOTE: FRU 375-3424

REFERENCE INFORMATION: N/A

This solution has no attachment