NetBackup™ Deployment Guide for Kubernetes Clusters

Last Published:
Product(s): NetBackup & Alta Data Protection (11.0)
  1. Introduction
    1. About Cloud Scale deployment
      1.  
        Decoupling of NetBackup web services from primary server
      2.  
        Decoupling of NetBackup Policy and Job Management from primary server
      3.  
        Logging feature (fluentbit) in Cloud Scale
    2.  
      About NetBackup Snapshot Manager
    3.  
      Required terminology
    4.  
      User roles and permissions
  2. Section I. Configurations
    1. Prerequisites
      1.  
        Preparing the environment for NetBackup installation on Kubernetes cluster
      2.  
        Prerequisites for Snapshot Manager (AKS/EKS)
      3. Prerequisites for Kubernetes cluster configuration
        1.  
          Config-Checker utility
        2.  
          Data-Migration for AKS
        3.  
          Webhooks validation for EKS
      4. Prerequisites for Cloud Scale configuration
        1.  
          Cluster specific settings
        2.  
          Cloud specific settings
      5.  
        Prerequisites for deploying environment operators
      6.  
        Prerequisites for using private registry
    2. Recommendations and Limitations
      1.  
        Recommendations of NetBackup deployment on Kubernetes cluster
      2.  
        Limitations of NetBackup deployment on Kubernetes cluster
      3.  
        Recommendations and limitations for Cloud Scale deployment
    3. Configurations
      1.  
        Contents of the TAR file
      2.  
        Initial configurations
      3.  
        Configuring the environment.yaml file
      4. Loading docker images
        1.  
          Installing the docker images for NetBackup
        2.  
          Installing the docker images for Snapshot Manager
        3.  
          Installing the docker images and binaries for MSDP Scaleout
      5.  
        Configuring NetBackup IT Analytics for NetBackup deployment
      6. Configuring NetBackup
        1. Primary and media server CR
          1.  
            After installing primary server CR
          2.  
            After Installing the media server CR
        2.  
          Elastic media server
    4. Configuration of key parameters in Cloud Scale deployments
      1.  
        Tuning touch files
      2.  
        Setting maximum jobs per client
      3.  
        Setting maximum jobs per media server
      4.  
        Enabling intelligent catalog archiving
      5.  
        Enabling security settings
      6.  
        Configuring email server
      7.  
        Reducing catalog storage management
      8.  
        Configuring zone redundancy
      9.  
        Enabling client-side deduplication capabilities
      10.  
        Parameters for logging (fluentbit)
      11.  
        Managing media server configurations in Web UI
  3. Section II. Deployment
    1. Deploying Cloud Scale
      1.  
        How to deploy Cloud Scale
      2.  
        Deploying the operators
      3.  
        Deploying fluentbit for logging
      4. Deploying Postgres
        1.  
          Enable request logging, update configuration, and copying files from/to PostgreSQL pod
      5. Deploying Cloud Scale environment
        1.  
          Installing Cloud Scale environment
        2. Single node Cloud Scale Technology deployment
          1.  
            Steps to deploy Cloud Scale in single node
      6.  
        Verifying Cloud Scale deployment
      7. Post Cloud Scale deployment tasks
        1.  
          Restarting Cloud Scale Technology services
  4. Section III. Monitoring and Management
    1. Monitoring NetBackup
      1.  
        Monitoring the application health
      2.  
        Telemetry reporting
      3.  
        About NetBackup operator logs
      4.  
        Monitoring Primary/Media server CRs
      5.  
        Expanding storage volumes
      6. Allocating static PV for Primary and Media pods
        1.  
          Expanding log volumes for primary pods
        2.  
          Recommendation for media server volume expansion
        3.  
          (AKS-specific) Allocating static PV for Primary and Media pods
        4.  
          (EKS-specific) Allocating static PV for Primary and Media pods
    2. Monitoring Snapshot Manager
      1.  
        Overview
      2.  
        Configuration parameters
    3. Monitoring fluentbit
      1.  
        Monitoring fluentbit for logging
    4. Monitoring MSDP Scaleout
      1.  
        About MSDP Scaleout status and events
      2.  
        Monitoring with Amazon CloudWatch
      3.  
        Monitoring with Azure Container insights
      4.  
        The Kubernetes resources for MSDP Scaleout and MSDP operator
    5. Managing NetBackup
      1.  
        Managing NetBackup deployment using VxUpdate
      2.  
        Updating the Primary/Media server CRs
      3.  
        Migrating the cloud node for primary or media servers
      4.  
        Migrating cpServer controlPlane node
    6. Managing the Load Balancer service
      1.  
        About the Load Balancer service
      2.  
        Notes for Load Balancer service
      3.  
        Opening the ports from the Load Balancer service
      4.  
        Steps for upgrading Cloud Scale from multiple media load balancer to none
    7. Managing PostrgreSQL DBaaS
      1.  
        Changing database server password in DBaaS
      2.  
        Updating database certificate in DBaaS
    8. Managing logging
      1.  
        Viewing NetBackup logs
      2.  
        Extracting NetBackup logs
    9. Performing catalog backup and recovery
      1.  
        Backing up a catalog
      2. Restoring a catalog
        1.  
          Primary server corrupted
        2.  
          MSDP-X corrupted
        3.  
          MSDP-X and Primary server corrupted
  5. Section IV. Maintenance
    1. PostgreSQL DBaaS Maintenance
      1.  
        Configuring maintenance window for PostgreSQL database in AWS
      2.  
        Setting up alarms for PostgreSQL DBaaS instance
    2. Patching mechanism for primary, media servers, fluentbit pods, and postgres pods
      1.  
        Overview
      2.  
        Patching of primary containers
      3.  
        Patching of media containers
      4.  
        Patching of fluentbit collector pods
      5.  
        Update containerized PostgreSQL pod
    3. Upgrading
      1. Upgrading Cloud Scale Technology
        1.  
          Prerequisites for Cloud Scale Technology upgrade
        2.  
          Upgrade the cluster
        3.  
          Upgrade the add-ons
        4.  
          Upgrade the operators
        5.  
          Upgrade fluentbit
        6.  
          Upgrade PostgreSQL database
        7.  
          Create db-cert bundle
        8.  
          Upgrade Cloud Scale
    4. Cloud Scale Disaster Recovery
      1.  
        Cluster backup
      2.  
        Environment backup
      3.  
        Cluster recovery
      4.  
        Cloud Scale recovery
      5.  
        Environment Disaster Recovery
      6.  
        DBaaS Disaster Recovery
    5. Uninstalling
      1.  
        Uninstalling NetBackup environment and the operators
      2.  
        Uninstalling Postgres using Helm charts
      3.  
        Uninstalling fluentbit using Helm charts
      4.  
        Uninstalling Snapshot Manager from Kubernetes cluster
      5. Uninstalling MSDP Scalout from Kubernetes cluster
        1.  
          Cleaning up MSDP Scaleout
        2.  
          Cleaning up the MSDP Scaleout operator
    6. Troubleshooting
      1. Troubleshooting AKS and EKS issues
        1.  
          View the list of operator resources
        2.  
          View the list of product resources
        3.  
          View operator logs
        4.  
          View primary logs
        5.  
          Socket connection failure
        6.  
          Resolving an issue where external IP address is not assigned to a NetBackup server's load balancer services
        7.  
          Resolving the issue where the NetBackup server pod is not scheduled for long time
        8.  
          Resolving an issue where the Storage class does not exist
        9.  
          Resolving an issue where the primary server or media server deployment does not proceed
        10.  
          Resolving an issue of failed probes
        11.  
          Resolving issues when media server PVs are deleted
        12.  
          Resolving an issue related to insufficient storage
        13.  
          Resolving an issue related to invalid nodepool
        14.  
          Resolve an issue related to KMS database
        15.  
          Resolve an issue related to pulling an image from the container registry
        16.  
          Resolving an issue related to recovery of data
        17.  
          Check primary server status
        18.  
          Pod status field shows as pending
        19.  
          Ensure that the container is running the patched image
        20.  
          Getting EEB information from an image, a running container, or persistent data
        21.  
          Resolving the certificate error issue in NetBackup operator pod logs
        22.  
          Pod restart failure due to liveness probe time-out
        23.  
          NetBackup messaging queue broker take more time to start
        24.  
          Host mapping conflict in NetBackup
        25.  
          Issue with capacity licensing reporting which takes longer time
        26.  
          Local connection is getting treated as insecure connection
        27.  
          Backing up data from Primary server's /mnt/nbdata/ directory fails with primary server as a client
        28.  
          Storage server not supporting Instant Access capability on Web UI after upgrading NetBackup
        29.  
          Taint, Toleration, and Node affinity related issues in cpServer
        30.  
          Operations performed on cpServer in environment.yaml file are not reflected
        31.  
          Elastic media server related issues
        32.  
          Failed to register Snapshot Manager with NetBackup
        33.  
          Post Kubernetes cluster restart, flexsnap-listener pod went into CrashLoopBackoff state or pods were unable to connect to flexsnap-rabbitmq
        34.  
          Post Kubernetes cluster restart, issues observed in case of containerized Postgres deployment
        35.  
          Request router logs
        36.  
          Issues with NBPEM/NBJM
        37.  
          Issues with logging feature for Cloud Scale
        38.  
          The flexsnap-listener pod is unable to communicate with RabbitMQ
        39.  
          Job remains in queue for long time
        40.  
          Extracting logs if the nbwsapp or log-viewer pods are down
      2. Troubleshooting AKS-specific issues
        1.  
          Data migration unsuccessful even after changing the storage class through the storage yaml file
        2.  
          Host validation failed on the target host
        3.  
          Primary pod goes in non-ready state
      3. Troubleshooting EKS-specific issues
        1.  
          Resolving the primary server connection issue
        2.  
          NetBackup Snapshot Manager deployment on EKS fails
        3.  
          Wrong EFS ID is provided in environment.yaml file
        4.  
          Primary pod is in ContainerCreating state
        5.  
          Webhook displays an error for PV not found
      4.  
        Troubleshooting issue for bootstrapper pod
  6. Appendix A. CR template
    1.  
      Secret
    2. MSDP Scaleout CR
      1.  
        MSDP Scaleout CR template for AKS
      2.  
        MSDP Scaleout CR template for EKS
  7. Appendix B. MSDP Scaleout
    1.  
      About MSDP Scaleout
    2.  
      Prerequisites for MSDP Scaleout (AKS\EKS)
    3.  
      Limitations in MSDP Scaleout
    4. MSDP Scaleout configuration
      1.  
        Initializing the MSDP operator
      2.  
        Configuring MSDP Scaleout
      3.  
        Configuring the MSDP cloud in MSDP Scaleout
      4.  
        Using MSDP Scaleout as a single storage pool in NetBackup
      5.  
        Using S3 service in MSDP Scaleout
      6.  
        Enabling MSDP S3 service after MSDP Scaleout is deployed
    5.  
      Installing the docker images and binaries for MSDP Scaleout (without environment operators or Helm charts)
    6.  
      Deploying MSDP Scaleout
    7. Managing MSDP Scaleout
      1.  
        Adding MSDP engines
      2.  
        Adding data volumes
      3. Expanding existing data or catalog volumes
        1.  
          Manual storage expansion
      4.  
        MSDP Scaleout scaling recommendations
      5. MSDP Cloud backup and disaster recovery
        1.  
          About the reserved storage space
        2. Cloud LSU disaster recovery
          1.  
            Recovering MSDP S3 IAM configurations from cloud LSU
      6.  
        MSDP multi-domain support
      7.  
        Configuring Auto Image Replication
      8. About MSDP Scaleout logging and troubleshooting
        1.  
          Collecting the logs and the inspection information
    8. MSDP Scaleout maintenance
      1.  
        Pausing the MSDP Scaleout operator for maintenance
      2.  
        Logging in to the pods
      3.  
        Reinstalling MSDP Scaleout operator
      4.  
        Migrating the MSDP Scaleout to another node pool

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.

Note:

For some of the cases such as import and duplication and so on, specifically selected elastic media server is ignored and is treated as any available media server. This is not applicable to cases where media server is used as backup host/client.

Enabling/disabling the auto scaling feature

For enabling/disabling the auto scaling feature, following media server CR inputs are required:

  • replicas: Describes the maximum number of replicas that the media server can scale up to.

  • minimumReplicas: Describes the minimum number of replicas of the media server running. This is an optional field. If not specified, the value for minimumReplicas 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 replicas must be more than value of minimumReplicas.

To disable the autoscaling feature of media server, ensure that the value of replicas is equal to the value of minimumReplicas.

Note:

The value of replica must be greater than 0 to enable the elasticity of media server.

NetBackup 11.0 and later, now provides support for scaling down the minimumReplica value of media server custom resource to 0 to diverge from the default behavior. After updating the value of minimumReplica there would be no media server pod running when there are no jobs running. This improves the total cost of ownership (TCO). The count of nodes reduces to 2 when the setup is idle. User must change the value of minimumReplica by editing the environment custom resource object.

  • When minimumReplica = 0, user must change the minimum size of media nodepool to 0 through the portal.

  • If no existing media pod or external media is available, all jobs that require storage interaction will trigger the creation of a new media pod by the NetBackup operator. A job remains in queue/active state waiting for resource with the following reason till the time new media pod is up and ready:

    Cloud scale media server is not available

    Primary server acting as media server will not be used in such cases.

    For more information on the above reason and the resolution for the same, refer to the following section:

    See Job remains in queue for long time.

Note:

For certain jobs, example big data workloads, a specific media server is required. Users must configure these jobs with minimumReplica = 1 in the media server custom resource. Same applies to other cases where media server used as backup host.

Status attributes of elastic media server CR

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.

Note:

If autoscaler is disabled then ExpectedReplicas is equals to minimumReplicas.

ActiveReplicas

Indicates the actual number of replicas that must be running to complete the ongoing operations on the media servers.

Note:

If autoscaler is disabled then ActiveReplicas is equals to minimumReplicas.

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.

Configuration parameters
  • ConfigMap

    A new ConfigMap with name nbu-media-autoscaler-configmap is 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 : "45" stabilitywindow-time-in-seconds : "5" stability-count : "3" graceful-shutdown-interval-in-seconds : "35" cpu-high-watermark-in-percent: "80"

  • bpsetconfig

    A new entry has been added in the primary server bp.conf that 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.

    NetBackup Commands Reference Guide

  • 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 scaling-interval-in-seconds 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 scale-down-unneeded-time 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.

  • For scaled down media servers, the deleted media servers are also displayed on Web UI/API during the credential validation for database servers.

Handling of sudden incoming jobs

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

Elastic media servers and primary server certificate sharing

Starting from NetBackup version 11.0, elastic media servers have been enhanced to share the primary server certificate. This enhancement is a step towards creating a unified, logical media server entity in a Cloud Scale environment with the following changes:

  • Mapping: Elastic media servers will be now mapped to the primary server's host ID.

  • Certificate renewal: The primary server will now manage the certificate renewal for all media servers.

    The renewed certificate will now be shared across the elastic media servers.

  • Host ID management: There will no longer be dedicated Host ID entries for elastic media servers, simplifying host ID management within the environment.

    This design ensures consistency and streamlines the management of certificates and Host IDs, contributing to a more cohesive and scalable architecture for elastic media servers.

  • Post upgrade: Upon upgrading to version 11.0, the existing elastic media server certificates and their corresponding host IDs will be deleted.

    All media servers will then be mapped to the primary server's Host ID.