On NetBackup 8.2 or higher, vnetd on a client consumes large amounts of CPU, backup and restore is slow.
Problem
Backup and restore performance degrades on a NetBackup client running version 8.2 or higher. It is also noticed that the vnetd -proxy process is consuming significant CPU, perhaps as much as 100% of one CPU or even more than one CPU if the backup or restore is using multiple streams.
Higher CPU usage by the vnetd proxy processes may also be noticed on the media servers used by the jobs.
This behavior is observed for both database agent and file system operations.
The behavior does not affect all clients backing up across the network. It does not affect any clients using Fiber Transport/SAN Client or Client-Direct.
Error Message
No error is reported and jobs do complete successfully.
Cause
NetBackup 8.2 includes a new feature to support clients located behind a dynamic network address translation (DNAT) gateway. This feature, by default enables encryption of the data-in-flight between the NetBackup client host and the media server host. The encryption (sending host) and decryption (receiving host) is handled by the vnetd proxy outbound and inbound processes respectively. Platforms that support hardware acceleration of encryption/decryption may show little or no effect from the extra work load. Platforms that do not support hardware acceleration of encryption/decryption may see significant increases in CPU use during the backup and restore.
Even if the NAT feature is not configured or enabled on the master server, having it configured on the client host will cause the encryption of the data-in-flight. If not configured anywhere, the connections would be auth-only with encryption only during the TLS handshake and not during the image transfer. Encryption during the image transfer is what is causing increased work load on the client and media server hosts.
Solution
On the client host, check to see if NetBackup is configured to use the NAT feature; the default is FALSE.
nbgetconfig ACCEPT_REVERSE_CONNECTION
If inadvertently enabled (ACCEPT_REVERSE_CONNECTION=TRUE|YES|1), simple disable the setting. Stop and restart the NetBackup services afterwards to ensure that the NAT related processes are also terminated on this host.
echo ACCEPT_REVERSE_CONNECTION=FALSE | nbsetconfig
If the NetBackup NAT feature is configured on the master server, and meant to be used with this client, but it is not necessary to encrypt the data-in-flight (the default is TRUE), then the encryption can be disabled on the client.
echo ENABLE_DATA_CHANNEL_ENCRYPTION=FALSE | nbsetconfig
But otherwise, the increased work load and potential transmission delays are normal and expected. Platforms running on Intel (or similar) chipsets that support both the AES/AES-NI and DRAND/SecureKey instruction sets should see minimal increases.
To learn more about NAT support in NetBackup, refer to the NetBackup Administrator's Guide, Volume I.