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. |
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) |
(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-serverdeployment 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.