Considerations When Performing Backups and Key Sharing

Backups and key sharing can be resource intensive. Take these considerations into account before backing up or sharing keys.

OKM backups and key sharing (import/export) are database intensive and reduce the response time on the KMA while it is performing the backup or key transfer operation. If possible, reduce tape drive workloads during the OKM backup and transfer window. If that is not possible, then consider the following options:

• Use the same KMA for backups and key sharing each time (most likely this is how cron jobs invoking the OKM backup utility will get set up).
• If the cluster is large enough, dedicate a KMA to be an administrative KMA.
  • This KMA should not have a service network connection so it would not be burdened with tape drive key requests at any time, especially during the backup or key transfer windows.
  • This KMA could also be used for OKM GUI sessions thus offloading the other KMAs from handling management related requests.
• Ensure fast management network connectivity of the backup and key transfer KMA. The faster the connection, the better it will be able to keep up with the additional load during backup and key transfer windows. This is true for all KMAs, but especially for the KMA performing backups as it will fall behind on servicing replication requests during the backup window. Having a fast network connection helps to minimize the replication backlog, such as lag.
• Put the backup and key transfer KMA in a site that is not used by tape drives. The tape drives then preference other KMAs within the site that they have been assigned and avoid using the backup and key transfer KMA.
• Add more KMAs to sites containing tape drives so that load balancing of key requests will occur across more KMAs. This reduces the number of key requests that the backup and key transfer KMA has to handle.