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
About the Load Balancer service
Key features of the Load Balancer service:
Note:
Load Balancer services are not created for media servers from NetBackup 10.5 release. If the setup is upgraded from a pre 10.4 release, the load balancer services are available post upgrade. It is recommended to clear the Load Balancer services. Refer to the following section:
See Steps for upgrading Cloud Scale from multiple media load balancer to none.
Load balancer services are created in primary server deployment that allows you to access the NetBackup application from public domains.
In the primary server CR spec, networkLoadBalancer section is used for handling the IP address and DNS name allocation for load balancer services. If is provided in CR spec, IP address count must not be less than the count specified in for media server and for primary server, only one IP address must be mentioned.
The networkLoadBalancer section can be used to provide static IP address and DNS name allocation to the Load Balancer services.
(AKS-specific)
The networkLoadBalancer section can be used to provide static IP address and DNS name allocation to the loadbalancer services. For more information to create and use static loadbalancer, see Microsoft documentation.
Static IP addresses and FQDN if used must be created before being used. Refer the below section:
Pre-allocation of static IP address and FQDN from resource group
In this case, it is required to provide the network resource group in annotations. This resource group is the resource group of load balancer public IPs that are in the same resource group as the cluster infrastructure (node resource group). This static FQDN and IP address must be valid in case of pod failure or upgrades scenarios as well.
In case user wants to use public load balancer, add in networkLoadBalancer section in primary and media server section in environment CR.
Example: In primary CR,
networkLoadBalancer: type: Public annotations: - service.beta.kubernetes.io/azure-load-balancer- resource-group:<name of network resource-group> ipList: - fqdn: primary.eastus.cloudapp.azure.com ipAddr: 40.123.45.123
(EKS-specific)
NetBackup supports the network load balancer with AWS Load Balancer scheme as .
FQDN must be created before being used. Refer below sections for different allowed annotations to be used in CR spec.
User must add the following annotations:
service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet1 name>
In addition to the above annotations, if required user can add more annotations supported by AWS. For more information, see AWS Load Balancer Controller Annotations.
For example:
CR spec in primary server,
networkLoadBalancer: type: Private annotations: service.beta.kubernetes.io/aws-load-balancer-subnets: <subnet1 name> ipList: "10.244.33.27: abc.vxindia.veritas.com"
The IP address, the subnet provided in ipList and annotations in networkLoadBalancer section in CR spec must belong to same availability zone that of the node group.
Note:
The subnet provided here should be same as the one given in node pool used for primary server and media server.
If NetBackup client is outside VPC or to access Web UI from outside VPC, then client CIDR must be added with all NetBackup ports in security group rule of cluster. Run the following command, to obtain the cluster security group:
aws eks describe-cluster --name <my-cluster> --query cluster.resourcesVpcConfig.clusterSecurityGroupId
For more information on cluster security group, see Amazon EKS security group requirements and considerations.
Add inbound rule to security group. For more information, see Add rules to a security group.
Table: Preferred annotations
Annotations | Value | Description |
|---|---|---|
service.beta.kubernetes.io/ azure-load-balancer- internal | true or false | Specify whether the load balancer should be internal. Added by default when type is selected as in load balancer service annotations. |
service.beta.kubernetes.io/ azure-load-balancer- internal-subnet | Name of the subnet | Specify which subnet the internal load balancer should be bound to. |
service.beta.kubernetes.io/ azure-load-balancer -resource-group | Name of the resource group | Specify the resource group of load balancer public IPs that are not in the same resource group as the cluster infrastructure (node resource group). |
Primary server:
8443
Used to access NetBackup Web UI from a machine which is not deployed in the same VPC as your EKS cluster.
In this case, open the Primary Load Balancer's Inbound security group to the machine's IP/CIDR with TCP port 443 and 8443.
For more information, refer to the "Update the security groups for your Network Load Balancer" section in the AWS documentation.
1556
Used as bidirectional port. Primary server to/from media servers and primary server to/from client require this TCP port for communication.
443
Used to inbound to vnet proxy tunnel on the primary server. Also, this is used Nutanix workload, communication from primary server to the deduplication media server.
13781
The MQBroker is listening on TCP port 13781. NetBackup client hosts - typically located behind a NAT gateway - be able to connect to the message queue broker (MQBroker) on the primary server.
13724
This port is required as a fall-back option when a legacy service cannot be reached through PBX and is required when using the Resilient Network feature.
Port 22
Used by NetBackup IT Analytics data collector for data collection.
Snapshot Manager server:
443
The Snapshot Manager user interface uses this port as the default HTTPS port.
5671
The Snapshot Manager RabbitMQ server uses this port for internal service communications. This port must be open to support multiple agents, extensions, backup from snapshot, and restore from backup jobs.
(EKS-specific) 2049
It is used for Amazon EFS access.
For more information, see Source ports for working with EFS.
Note:
Add the NFS rule that allows traffic on port 2049 directly to the cluster security group. The security group attached to EFS must also allow traffic from port 2049.