NetBackup™ Deployment Guide for Azure Kubernetes Services (AKS) Cluster
- Introduction to NetBackup on AKS
- Deployment with environment operators
- Assessing cluster configuration before deployment
- Deploying NetBackup
- Preparing the environment for NetBackup installation on AKS
- Recommendations of NetBackup deployment on AKS
- Limitations of NetBackup deployment on AKS
- About primary server CR and media server CR
- Monitoring the status of the CRs
- Updating the CRs
- Deleting the CRs
- Configuring NetBackup IT Analytics for NetBackup deployment
- Managing NetBackup deployment using VxUpdate
- Migrating the node pool for primary or media servers
- Upgrading NetBackup
- Deploying MSDP Scaleout
- Upgrading MSDP Scaleout
- Monitoring NetBackup
- Monitoring MSDP Scaleout
- Managing the Load Balancer service
- Performing catalog backup and recovery
- Managing MSDP Scaleout
- About MSDP Scaleout maintenance
- Uninstalling MSDP Scaleout from AKS
- Troubleshooting
- View the list of operator resources
- View the list of product resources
- View operator logs
- View primary logs
- Pod restart failure due to liveness probe time-out
- Socket connection failure
- Resolving an invalid license key issue
- 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 inconsistency in file ownership
- 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
- Appendix A. CR template
About the Load Balancer service
Key features of the Load Balancer service:
Load balancer services are created in primary server and media server deployment that lets you access the NetBackup application from public domains.
In primary server or media server CR spec, networkLoadBalancer section is used for handling the IP address and DNS name allocation for load balancer services. This section combines to sub fields , , and whereas these fields are optional. If is provided in CR spec, IP address count must match the replica count in case of media server CR whereas in case of primary server CR, only one IP address needs to be mentioned.
In CR yaml, networkLoadBalancer is an optional field. If not defined in CR yaml, by default value of type is and services are added with annotations
service.beta.kubernetes.io/azure-load-balancer-internal: "true". In this case, by default internal load balancer is selected for deployment.If networkLoadBalancer section is not defined, by default internal load balancer with dynamic IP address allocation are done. In this case, DNS names for the services can be obtained from in CR status using the kubectl describe <CR name> -n <namespace> command.
Whenever, in CR status is not in FQDN format, you must add entry of hostname and its corresponding IP address in
/etc/hostto access the primary server and its corresponding IP address in hosts file of computer accessing the primary server. Hosts file is present at the following location:For Linux:
/etc/hostsFor Windows:
c:\Windows\System32\Drivers\etc\hosts
In case of media server, FQDN per media server replica is generated using mentioned in media server CR and listed under status attributes of the media server CR.
In this deployment, it is recommended to use internal load balancer using type as with static IP allocation and DNS name allocation.
For details about internal load balancer, see Microsoft documentation.
However, if type is , then external load balancer is used and for more details to create and use public loadbalancer, see Microsoft documentation.
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 below sections for different allowed scenarios.
Case 1: Internal load balancer with static IP address allocation
Example: In Primary section in environment CR
networkLoadBalancer: ipList: - ipAddr: 10.123.45.123In media server section in environment CR
networkLoadBalancer: ipList: - ipAddr: 10.123.45.124 - ipAddr: 10.123.45.125In this case, number of IP addresses for primary server should be one, and for media server, the number of IP addresses should match with the replica count mentioned in CR spec. Dynamically created FQDN mentioned in CR status attribute is used directly as DNS name for primary/media server services.
Example: In primary CR
In this case, the number of IP addresses for primary server should be one, and for media server, it should match with the replica count mentioned in CR spec. IP address and DNS name mentioned in CR spec is used as DNS name for primary/media server services.
networkLoadBalancer: ipList: - ipAddr: 10.123.45.123 fqdn: abc.eastus.cloudapp.azure.comIn media server section in environment CR
networkLoadBalancer: ipList: - fqdn: xyz.eastus.cloudapp.azure.com ipAddr: 10.123.45.124 - fqdn: pqr.eastus.cloudapp.azure.com ipAddr: 10.123.45.125
Case 2: Internal load balancer and dynamic IP address allocation
Example: In primary/media CR
In this case, IP address and DNS name are allocated dynamically and internal load balancer is used. User needs to add entry of Hostname (FQDN) mentioned in CR status attribute and IP address allocated to load balancer service in
/etc/hostslocation on Linux machine. Whilec:\Windows\System32\Drivers\etc\hostslocation on Windows computer to access primary server webUI.
Case 3: Internal load balancer for different subnet with dynamic IP
In this case, IP addresses for load balancer service are allocated dynamically. The subnet mentioned in annotations is bound to internal load balancer service.
Example: In primary CR
networkLoadBalancer: annotations: - service.beta.kubernetes.io/ azure-load-balancer-internal-subnet: "apps-subnet"
Media CR
networkLoadBalancer: annotations: - service.beta.kubernetes.io/ azure-load-balancer-internal-subnet: "apps-subnet"
Case 4: Internal load balancer for different subnet with static IP
In this case, load balancer service gets assigned with the static IP addresses mentioned in the
ipList, DNS name is generated dynamically, and gets bound to the subnet given in the annotations.Example: In primary section in environment CR,
networkLoadBalancer: annotations: - service.beta.kubernetes.io/azure-load-balancer- internal-subnet: apps-subnet ipList: - ipAddr: 10.123.45.123
Media server section in environment CR
networkLoadBalancer: annotations: - service.beta.kubernetes.io/azure-load-balancer- internal-subnet: apps-subnet ipList: - ipAddr: 10.123.45.125 - ipAddr: 10.123.45.124
Case 5: 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.123Media server section in environment CR -
networkLoadBalancer: annotations: - service.beta.kubernetes.io/azure-load-balancer- resource-group: ""<name of network resource-group>"" ipList: - fqdn: media-1.eastus.cloudapp.azure.com ipAddr: 40.123.45.123 - fqdn: media-2.eastus.cloudapp.azure.com ipAddr: 40.123.45.124
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:
1556
Used as bidirectional port. Primary server to/from media servers and primary server to/from client require this TCP port for communication.
8443
Used to inbound to java nbwmc on the primary server.
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.
13782
Used by primary server for bpcd process.
Port 22
Used by NetBackup IT Analytics data collector for data collection.
Media server:
1556
Used as bidirectional port. Primary server to/from media servers and primary server to/from client require this TCP port for communication.
13782
Used by media server for bpcd process.