Search <book_title>...

Veritas NetBackup™ CloudPoint Install and Upgrade Guide

Last Published: 2022-03-28

Product(s): NetBackup (10.0)

CloudPoint extension sizing recommendations

The CloudPoint extension serves the purpose of scaling the capacity of the CloudPoint host to service a large number of requests concurrently running on the CloudPoint server at its peak performance capacity. You can install one or more CloudPoint 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 CloudPoint.

The CloudPoint extension can have the configuration same or higher as the CloudPoint host.

See Meeting system requirements.

Supported CloudPoint extension environments:

VM based extension for on-premise
Cloud based extension with managed Kubernetes cluster

Note:

For CloudPoint 10.0, the VM based extensions are supported on Azure Stack hub and Kubernetes based extension are supported on Azure and AWS.

Veritas recommends the following configurations for the CloudPoint extensions:

Table: Typical CloudPoint extension configuration for VM based extension (Azure stack)

Workload metric	CloudPoint extension configuration
Up to 16 concurrent operational tasks	CPU: 4 CPUs Memory: 16 GB For example, in Azure stack, the CloudPoint 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 CloudPoint extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS.

Workload metric

CloudPoint extension configuration

Up to 16 concurrent operational tasks

CPU: 4 CPUs

Memory: 16 GB

For example, in Azure stack, the CloudPoint 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 CloudPoint extension should be an equivalent of a t3.2xlarge or a higher type of instance in AWS.

Table: Typical CloudPoint extension configuration for Kubernetes based extension (Azure, AWS)

Workload metric	CloudPoint extension configuration
Up to 24 concurrent operational tasks	For Azure CPU: More than 2 CPU's per node Memory: 8 GB per node Maximum pods per node: 12 CP pods + 6 (system AKS pods) = 18 or more Autoscaling enabled, with minimum =1 and maximum =3
Up to 24 concurrent operational tasks	For AWS CPU: More than 2 CPU's per node Memory: 8 GB per node Autoscaling enabled, with minimum =1 and maximum =3

Workload metric

CloudPoint extension configuration

Up to 24 concurrent operational tasks

For Azure

CPU: More than 2 CPU's per node

Memory: 8 GB per node

Maximum pods per node: 12 CP pods + 6 (system AKS pods) = 18 or more

Autoscaling enabled, with minimum =1 and maximum =3

Up to 24 concurrent operational tasks

For AWS

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 CloudPoint extension:

To achieve better performance in a high workload environment, Veritas recommends that you deploy the CloudPoint 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 CloudPoint host. If it is not, then you can make use of the VNet peering mechanism available with the Azure cloud, to make sure that CloudPoint 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 CloudPoint 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 CloudPoint host and the extensions together can handle, CloudPoint automatically puts the operations in a job queue. The queued jobs are picked up only after the running operations are completed.