NetBackup™ Snapshot Manager Install and Upgrade Guide
- Introduction
- Section I. NetBackup Snapshot Manager installation and configuration
- Preparing for NetBackup Snapshot Manager installation
- Deploying NetBackup Snapshot Manager using container images
- Deploying NetBackup Snapshot Manager extensions
- Installing the Snapshot Manager extension on a VM
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (AKS) in Azure
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (EKS) in AWS
- Installing the Snapshot Manager extension on a managed Kubernetes cluster (GKE) in GCP
- NetBackup Snapshot Manager cloud plug-ins
- NetBackup Snapshot Manager application agents and plug-ins
- Installing and configuring Snapshot Manager agent
- Configuring the Snapshot Manager application plug-in
- Microsoft SQL plug-in
- Oracle plug-in
- NetBackup protection plan
- Protecting assets with NetBackup Snapshot Manager's agentless feature
- Volume Encryption in NetBackup Snapshot Manager
- NetBackup Snapshot Manager security
- Preparing for NetBackup Snapshot Manager installation
- Section II. NetBackup Snapshot Manager maintenance
- NetBackup Snapshot Manager logging
- Upgrading NetBackup Snapshot Manager
- Uninstalling NetBackup Snapshot Manager
- Troubleshooting NetBackup Snapshot Manager
Snapshot Manager extension sizing recommendations
The Snapshot Manager extension serves the purpose of scaling the capacity of the Snapshot Manager host to service a large number of requests concurrently running on the Snapshot Manager at its peak performance capacity. You can install one or more Snapshot Manager extensions on-premise or 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 Snapshot Manager.
The Snapshot Manager extension can have the configuration same or higher as the Snapshot Manager host.
See Meeting system requirements.
Supported Snapshot Manager extension environments:
VM based extension for on-premise
Cloud based extension with managed Kubernetes cluster
Note:
For 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 Snapshot Manager extensions:
Table: Typical Snapshot Manager extension configuration for VM based extension (Azure stack)
Workload metric | Snapshot Manager extension configuration |
---|---|
Up to 16 concurrent operational tasks |
CPU: 4 CPUs Memory: 16 GB For example, in Azure stack, the 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 Snapshot Manager extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS. |
Table: Typical Snapshot Manager extension configuration for Kubernetes based extension (Azure, AWS and GCP)
Workload metric | Snapshot Manager extension configuration |
---|---|
Up to 24 concurrent operational tasks | For Azure
Note: Above configuration would run 16 jobs per node at once. |
Up to 24 concurrent operational tasks | For AWS CPU: More than 2 CPU's RAM per node: 8 GB Autoscaling enabled, with minimum =1 and maximum =3 Note: Above configuration would run 8 jobs per node at once. |
Up to 24 concurrent operational tasks | For GCP CPU: More than 2 CPU's per node Memory: 8 GB per node Autoscaling enabled, with minimum =1 and maximum =3 |
General considerations and guidelines:
Consider the following points while choosing a configuration for the Snapshot Manager extension:
To achieve better performance in a high workload environment, Veritas recommends that you deploy the 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 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 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 Snapshot Manager host can get really large in size. 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 Snapshot Manager host and the extensions together can handle, Snapshot Manager automatically puts the operations in a job queue. The queued jobs are picked up only after the running operations are completed.