Search <book_title>...

NetBackup™ Snapshot Manager for Cloud Install and Upgrade Guide

Last Published: 2024-03-27

Product(s): NetBackup (10.4)

NetBackup Snapshot Manager extension sizing recommendations

The NetBackup Snapshot Manager extension serves the purpose of scaling the capacity of the NetBackup Snapshot Manager host to service a large number of requests concurrently running on the NetBackup Snapshot Manager at its peak performance capacity. You can install one or more NetBackup Snapshot Manager extensions in cloud, depending on your requirements to run the jobs without putting the host under additional stress. An extension can increase the processing capacity of the NetBackup Snapshot Manager.

The NetBackup Snapshot Manager extension can have the configuration same or higher as the NetBackup Snapshot Manager host.

See Meeting system requirements.

Supported NetBackup Snapshot Manager extension environment:

Cloud based extension with managed Kubernetes cluster

Note:

For NetBackup Snapshot Manager 10.0, the VM based extensions are supported on Azure Stack hub and Kubernetes based extension are supported on Azure, AWS and GCP.

Veritas recommends the following configurations for the NetBackup Snapshot Manager extensions:

Table: Typical NetBackup Snapshot Manager extension configuration for VM based extension (Azure stack)

Workload metric	NetBackup Snapshot Manager extension configuration
Up to 16 concurrent operational tasks	CPU: 4 CPUs Memory: 16 GB For example, in Azure stack, the NetBackup Snapshot Manager extension should be an equivalent of a t3.xlarge instance in AWS.
Up to 32 concurrent operational tasks	CPU: 8 CPUs Memory: 32 GB or more For example, in Azure stack, the NetBackup Snapshot Manager extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS.

Workload metric

NetBackup Snapshot Manager extension configuration

Up to 16 concurrent operational tasks

CPU: 4 CPUs

Memory: 16 GB

For example, in Azure stack, the NetBackup Snapshot Manager extension should be an equivalent of a t3.xlarge instance in AWS.

Up to 32 concurrent operational tasks

CPU: 8 CPUs

Memory: 32 GB or more

For example, in Azure stack, the NetBackup Snapshot Manager extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS.

Table: Typical NetBackup Snapshot Manager extension configuration for Kubernetes based extension (Azure, AWS and GCP)

Workload metric	NetBackup Snapshot Manager extension configuration
Up to 24 concurrent operational tasks	For 2 CPU's and 8 GB RAM node configuration: CPU: More than 2 CPU's RAM per node: 8GB Maximum pods per node: 13 + 15 + 8*2=16 (Dynamic pods) = 44 or more Autoscaling enabled, with minimum=1, maximum=3 For one backup from Snapshot job, 2 pods are created. Where 15 is the buffer pod count for any intermittent operations. 13 is calculated as: 10 (number of Kubernetes and CSP pods) + 3 (listener + fluent collector + fluent daemon set).
For 2/4/6 CPU's and 16 GB node configuration CPU per node: More than 2/4/6 CPU's RAM per node: 16 GB Maximum pods per node: 13 + 15 + 16*2=32 (Dynamic pods) = 60 or more Autoscaling enabled, with minimum=1, maximum=3 For one backup from Snapshot job, 2 pods are created. Where 15 is the buffer pod count for any intermittent operations. 13 is calculated as: 10 (number of Kubernetes and CSP pods) + 3 (listener + fluent collector + fluent daemon set)

Workload metric

NetBackup Snapshot Manager extension configuration

Up to 24 concurrent operational tasks

For 2 CPU's and 8 GB RAM node configuration:

CPU: More than 2 CPU's

RAM per node: 8GB

Maximum pods per node: 13 + 15 + 8*2=16 (Dynamic pods) = 44 or more

Autoscaling enabled, with minimum=1, maximum=3

For one backup from Snapshot job, 2 pods are created. Where 15 is the buffer pod count for any intermittent operations. 13 is calculated as: 10 (number of Kubernetes and CSP pods) + 3 (listener + fluent collector + fluent daemon set).

For 2/4/6 CPU's and 16 GB node configuration

CPU per node: More than 2/4/6 CPU's

RAM per node: 16 GB

Maximum pods per node: 13 + 15 + 16*2=32 (Dynamic pods) = 60 or more

Autoscaling enabled, with minimum=1, maximum=3

(EKS-specific) Installing the Kubernetes Metrics Server

The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it is notdeployed by default in Amazon EKS clusters. The following procedure explains how to deploy the Kubernetes Metrics Server on your Amazon EKS cluster:

Deploy the Metrics Server with the following command:
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Verify that the metrics-server deployment is running the desired number of Pods with the following command:
kubectl get deployment metrics-server -n kube-system
An example output is as follows:
```
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
metrics-server   1/1     1            1           6m
```

General considerations and guidelines:

Consider the following points while choosing a configuration for the NetBackup Snapshot Manager extension:

To achieve better performance in a high workload environment, Veritas recommends that you deploy the NetBackup Snapshot Manager extension in the same location as that of the application hosts.
The cloud-based extension on a managed Kubernetes cluster should be in the same VNet as that of the NetBackup Snapshot Manager host. If it is not, then you can make use of the VNet peering mechanism available with the Azure cloud, to make sure that NetBackup Snapshot Manager host and extension nodes can communicate with each other over the required ports
Depending on the number of workloads, the amount of plug-in data that is transmitted from the NetBackup Snapshot Manager host can get really large. The network latency also plays a key role in such a case. You might see a difference in the overall performance depending on these factors.
In cases where the number of concurrent operations is higher than what the NetBackup Snapshot Manager host and the extensions together can handle, NetBackup Snapshot Manager automatically puts the operations in a job queue. The queued jobs are picked up only after the running operations are completed.