NetBackup™ Deployment Guide for Kubernetes Clusters
- Introduction
- Section I. Configurations
- Prerequisites
- Recommendations and Limitations
- Configurations
- Configuration of key parameters in Cloud Scale deployments
- Tuning touch files
- Setting maximum jobs per client
- Setting maximum jobs per media server
- Enabling intelligent catalog archiving
- Enabling security settings
- Configuring email server
- Reducing catalog storage management
- Configuring zone redundancy
- Enabling client-side deduplication capabilities
- Parameters for logging (fluentbit)
- Section II. Deployment
- Section III. Monitoring and Management
- Monitoring NetBackup
- Monitoring Snapshot Manager
- Monitoring fluentbit
- Monitoring MSDP Scaleout
- Managing NetBackup
- Managing the Load Balancer service
- Managing PostrgreSQL DBaaS
- Managing fluentbit
- Performing catalog backup and recovery
- Section IV. Maintenance
- PostgreSQL DBaaS Maintenance
- Patching mechanism for primary, media servers, fluentbit pods, and postgres pods
- Upgrading
- Cloud Scale Disaster Recovery
- Uninstalling
- Troubleshooting
- Troubleshooting AKS and EKS issues
- View the list of operator resources
- View the list of product resources
- View operator logs
- View primary logs
- Socket connection failure
- Resolving an issue where external IP address is not assigned to a NetBackup server's load balancer services
- Resolving the issue where the NetBackup server pod is not scheduled for long time
- Resolving an issue where the Storage class does not exist
- Resolving an issue where the primary server or media server deployment does not proceed
- Resolving an issue of failed probes
- Resolving token issues
- Resolving an issue related to insufficient storage
- Resolving an issue related to invalid nodepool
- Resolving a token expiry issue
- Resolve an issue related to KMS database
- Resolve an issue related to pulling an image from the container registry
- Resolving an issue related to recovery of data
- Check primary server status
- Pod status field shows as pending
- Ensure that the container is running the patched image
- Getting EEB information from an image, a running container, or persistent data
- Resolving the certificate error issue in NetBackup operator pod logs
- Pod restart failure due to liveness probe time-out
- NetBackup messaging queue broker take more time to start
- Host mapping conflict in NetBackup
- Issue with capacity licensing reporting which takes longer time
- Local connection is getting treated as insecure connection
- Primary pod is in pending state for a long duration
- Backing up data from Primary server's /mnt/nbdata/ directory fails with primary server as a client
- Storage server not supporting Instant Access capability on Web UI after upgrading NetBackup
- Taint, Toleration, and Node affinity related issues in cpServer
- Operations performed on cpServer in environment.yaml file are not reflected
- Elastic media server related issues
- Failed to register Snapshot Manager with NetBackup
- Post Kubernetes cluster restart, flexsnap-listener pod went into CrashLoopBackoff state or pods were unable to connect to flexsnap-rabbitmq
- Post Kubernetes cluster restart, issues observed in case of containerized Postgres deployment
- Request router logs
- Issues with NBPEM/NBJM
- Issues with logging feature for Cloud Scale
- The flexsnap-listener pod is unable to communicate with RabbitMQ
- Troubleshooting AKS-specific issues
- Troubleshooting EKS-specific issues
- Troubleshooting issue for bootstrapper pod
- Troubleshooting AKS and EKS issues
- Appendix A. CR template
- Appendix B. MSDP Scaleout
- About MSDP Scaleout
- Prerequisites for MSDP Scaleout (AKS\EKS)
- Limitations in MSDP Scaleout
- MSDP Scaleout configuration
- Installing the docker images and binaries for MSDP Scaleout (without environment operators or Helm charts)
- Deploying MSDP Scaleout
- Managing MSDP Scaleout
- MSDP Scaleout maintenance
Elastic media server
All the replicas for the media server are always up and running which incurs unnecessary cost to customers. The basic media server pod power management (Elastic media server) feature provides Auto scaling of media server replicas based on the CPU and memory usage as well as the jobs queued due to maximum jobs per media server settings to reduce the cost.
For enabling/disabling the auto scaling feature, following media server CR inputs are required:
: Describes the maximum number of replicas that the media server can scale up to.
: Describes the minimum number of replicas of the media server running. This is an optional field. If not specified, the value for field will be set to the default value of 1.
From version 10.5 and later, along with CPU and memory usage, the media server scaleout is also seen if the jobs are found in queued state due to the maximum job per media server settings. To configure this setting, refer to the configuration parameter bpsetconfig below.
To enable the elasticity of media server, the value of must be more than value of .
To disable the autoscaling feature of media server, ensure that the value of is equal to the value of .
Note:
The values of and must be greater than 0 to enable the elasticity of media server.
Following table describes the ElasticityAttributes that describes the attributes associated with the media server autoscaler. These attributes are only applicable if autoscaler is running.
Fields | Description |
|---|---|
ExpectedReplicas | Indicates the ideal number of replicas computed by media server autoscaler that must be running. Default value is 0. It will be 0 if media server autoscaler is disabled. Note: If autoscaler is enabled (after that autscaler is tuned off) the value would be set to the value of . It will be even if media server autoscaler is disabled. |
ActiveReplicas | Indicates the actual number of replicas that must be running to complete the ongoing operations on the media servers. Default value is 0. It will be 0 if media server autoscaler is disabled. Note: If autoscaler is enabled (after that autscaler is tuned off) the value would be set to the value of . It will be even if media server autoscaler is disabled. |
NextIterationTime | Indicates the next iteration time of the media server autoscaler that is, the media server autoscaler will run after NextIterationTime only. Default value is empty. |
NextCertificateRenewalTime | Next time to scale up all registered media servers for certificate renewal. |
ConfigMap
A new ConfigMap with name
nbu-media-autoscaler-configmapis created during deployment and the key-value pairs would be consumed for tuning the media server autoscaler. This ConfigMap is common to all the media server CR objects and supports the following keys:Parameters
Description
memory-low-watermark-in-percent
Low watermark for memory usage.
memory-high-watermark-in-percent
High watermark for memory usage.
cpu-low-watermark-in-percent
Low watermark for CPU usage.
cpu-high-watermark-in-percent
High watermark for CPU usage.
scaling-interval-in-seconds
Interval after which media server autoscaler should run.
stabilitywindow-time-in-seconds
CPU and memory usage is calculated between two time intervals. This key indicates the time interval to be considered for collecting usage.
stability-count
CPU and memory usages are calculated by averaging out on multiple readings. This key indicates the number of readings to be considered.
graceful-shutdown-interval-in-seconds
The time interval after which the media server autoscaler should run incase it is not able to scale in due to running jobs on media server pods.
delayed-scalein-notifications-interval-in-minutes
The time interval between two successive notifications in the event that a scale in does not occur.
Note:
If you are upgrading to latest version, change the default values of the following parameters: scaling-interval-in-seconds : "90" stability-window-time-in-seconds : "10" stability-count : "3" graceful-shutdown-interval-in-seconds : "120" cpu-high-watermark-in-percent: "80"
bpsetconfig
A new entry has been added in the primary server
bp.confthat is consumed by media server autoscaler. This value applies to all the Cloud Scale Technology managed media servers.Parameters
Description
MAX_JOBS_PER_K8SCLUSTER_MEDIA_SERVER
Maximum number of jobs that can run on each media server. This value can be set using bpsetconfig CLI.
Media server scaling
Parameters
Description
Scale-out
If all the active media servers managed by the Cloud Scale Technology are at their capacity due to the maximum jobs per media server settings and if there are more jobs in queue, scale-out is performed and multiple replicas may get scaled out due to the media server settings.
Additionally, if there are no jobs in queue due to this settings and if the CPU or memory consumption in the specified value provided in configMap but if any existing media server is idle that is, no jobs are running on it, then scale-out will not be performed. If all the existing media servers which are ready have jobs running on them, media server autoscaler will scale out a media server pod.
Scale-in
If the CPU and memory consumption is below the specified values provided in configMap, media server autoscaler will scale in the media server pods. Ensure that the running jobs are completed.
Note:
The scale-in does not happen until there are jobs in the queue due to the maximum job per media server settings.
Note:
The media server autoscaler scales out a single pod at a time in case a scale-out happens due to CPU and memory usage. It may exit from the multiple pods in case the scale-out happens due to the throttled jobs. The media server autoscaler can scale-in multiple pods at a time.
Note:
If the scale-in does not happen due to background processes running on the media server, a notification would be sent on NetBackup Web UI after regular time interval as configured in the autoscaler ConfigMap. For more details, see the following section:
The time taken for media server scale depends on the value of configuration parameter. During this interval, the jobs would be served by existing media server replicas based on NetBackup throttling parameters. For example, Maximum concurrent jobs in storage unit, Number of jobs per client, and so on.
Cluster's native autoscaler takes some time as per attribute, which decides on the time a node should be unneeded before it is eligible to be scaled down. By default this is 10 minutes. To change this parameter, edit the cluster-autoscaler's current deployment settings using the following commands and then edit the existing value:
AKS: az aks update --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --cluster-autoscaler-profile scale-down-unneeded-time=5m
EKS: kubectl -n kube-system edit deployment cluster-autoscaler
Note the following:
For scaled in media servers, certain resources and configurations are retained to avoid reconfiguration during subsequent scale out.
Kubernetes services, persistent volume claims and persistent volumes are not deleted for scaled in media servers.
Host entries for scaled in media servers are not removed from NetBackup primary server. Hence scaled in media server entries will be displayed on Web UI / API.
For scaled down media servers, the deleted media servers are also displayed on Web UI/API during the credential validation for database servers.
In order to ensure that the certificates are renewed on the media server replicas for which the pods were scaled in by media server autoscaler for longer duration, the NetBackup operator would scale out all the media server replicas once in a month for which certificate was issued. The scaled-out media server replicas would be then scaled in as per media server autoscaler.
Based on the configured schedules, if a large number of jobs are expected to run at certain time, the maximum number of jobs per media server should be configured to ensure that the required number of media server pods are scaled out and the jobs are properly distributed.
For configuration related parameters, see 'Media server scaling' table in Configuration parameters
More Information