NetBackup™ Deployment Guide for Kubernetes Clusters

Last Published:
Product(s): NetBackup (10.5.0.1)
  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
    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)
  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.  
          Configuring NetBackup IT Analytics for NetBackup deployment by configuring data collector on a separate host machine
        2.  
          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
    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 fluentbit
      1.  
        Managing fluentbit for logging
    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 containers
    3. Upgrading
      1. Upgrading Cloud Scale Technology
        1.  
          Prerequisites for Cloud Scale Technology upgrade
        2.  
          Upgrade the add-ons
        3.  
          Upgrade the operators
        4.  
          Upgrade fluentbit
        5.  
          Upgrade PostgreSQL database
        6.  
          Create db-cert bundle
        7.  
          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 Snapshot Manager from Kubernetes cluster
      4. 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 token issues
        12.  
          Resolving an issue related to insufficient storage
        13.  
          Resolving an issue related to invalid nodepool
        14.  
          Resolving a token expiry issue
        15.  
          Resolve an issue related to KMS database
        16.  
          Resolve an issue related to pulling an image from the container registry
        17.  
          Resolving an issue related to recovery of data
        18.  
          Check primary server status
        19.  
          Pod status field shows as pending
        20.  
          Ensure that the container is running the patched image
        21.  
          Getting EEB information from an image, a running container, or persistent data
        22.  
          Resolving the certificate error issue in NetBackup operator pod logs
        23.  
          Pod restart failure due to liveness probe time-out
        24.  
          NetBackup messaging queue broker take more time to start
        25.  
          Host mapping conflict in NetBackup
        26.  
          Issue with capacity licensing reporting which takes longer time
        27.  
          Local connection is getting treated as insecure connection
        28.  
          Primary pod is in pending state for a long duration
        29.  
          Backing up data from Primary server's /mnt/nbdata/ directory fails with primary server as a client
        30.  
          Storage server not supporting Instant Access capability on Web UI after upgrading NetBackup
        31.  
          Taint, Toleration, and Node affinity related issues in cpServer
        32.  
          Operations performed on cpServer in environment.yaml file are not reflected
        33.  
          Elastic media server related issues
        34.  
          Failed to register Snapshot Manager with NetBackup
        35.  
          Post Kubernetes cluster restart, flexsnap-listener pod went into CrashLoopBackoff state or pods were unable to connect to flexsnap-rabbitmq
        36.  
          Post Kubernetes cluster restart, issues observed in case of containerized Postgres deployment
        37.  
          Request router logs
        38.  
          Issues with NBPEM/NBJM
        39.  
          Issues with logging feature for Cloud Scale
        40.  
          The flexsnap-listener pod is unable to communicate with RabbitMQ
      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

Config-Checker utility

How does the Config-Checker utility work

The Config-Checker utility performs checks on the deployment environment to verify that the environment meets the requirements, before starting the primary server and media server deployments.

How does the Config-Checker works:

  • RetainReclaimPolicy check:

    This check verifies that the storage classes used for PVC creation in the CR have reclaim policy as Retain. The check fails if any of the storage classes do not have the Retain reclaim policy.

    For more information, see the 'Persistent Volumes Reclaiming' section of the Kubernetes Documentation.

  • MinimumVolumeSize check:

    This check verifies that the PVC storage capacity meets the minimum required volume size for each volume in the CR. The check fails if any of the volume capacity sizes does not meet the requirements.

    Following are the minimum volume size requirements:

    • Primary server:

      • Data volume size: 30Gi

      • Catalog volume size: 100Gi

      • Log volume size: 30Gi

    • Media server:

      • Data volume size: 50Gi

      • Log volume size: 30Gi

  • Provisioner check:

    EKS-specific only

    • Primary server: This will verify that the storage type provided is Amazon Elastic Block Store (Amazon EBS) for data and log volume. If any other driver type is used, the Config-Checker fails.

    • Media server: This will verify that the storage type provided is Amazon Elastic Block Store (Amazon EBS) for data and log volume. Config-Checker fails if this requirement is not met for media server.

    AKS-specific only

    • This check verifies that the provisioner type used in defining the storage class is Azure disk, for the volumes in Media servers. If not the Config-Checker will fail. This check verifies that the provisioner type used in defining the storage class is not Azure files for the volumes in Media servers. That is data and log volumes in case of Media server.

  • (EKS-specific only) AWS Load Balancer Controller add-on check:

    This check verifies if the AWS Load Balancer Controller add-on is installed in the cluster. This load balancer controller is required for load balancer in the cluster. If this check fails, user must deploy the AWS Load Balancer Controller add-on

  • Cluster Autoscaler

    This autoscaler is required for autoscaling in the cluster. If autoscaler is not configured, then Config-Checker displays a warning message and continues with the deployment of NetBackup servers.

    (EKS-specific only) This check verifies if the AWS Autoscaler add-on is installed in the cluster. For more information, refer to 'Autoscaling' section of the Amazon EKS User Guide.

  • Volume expansion check:

    This check verifies the storage class name given for Primary server data and log volume and for Media server data and log volumes has AllowVolumeExpansion = true. If Config-Checker fails with this check then it gives a warning message and continues with deployment of NetBackup media servers.

Config-Checker execution and status details

Note the following points.

  • Config-Checker is executed as a separate job in Kubernetes cluster for both the primary server and media server CRs respectively. Each job creates a pod in the cluster. Config-checker creates the pod in the operator namespace.

    Note:

    Config-checker pod gets deleted after 4 hours.

  • Execution summary of the Config-Checker can be retrieved from the Config-Checker pod logs using the kubectl logs <configchecker-pod-name> -n <operator-namespace> command.

    This summary can also be retrieved from the operator pod logs using the kubectl logs <operator-pod-name> -n <operator-namespace> command.

  • Following are the Config-Checker modes that can be specified in the Primary and Media CR:

    • Default: This mode executes the Config-Checker. If the execution is successful, the Primary and Media CRs deployment is started.

      Note:

      This is default mode of Config-Checker if not changed explicitly through CR specs.

    • Dryrun: This mode only executes the Config-Checker to verify the configuration requirements but does not start the CR deployment.

    • Skip: This mode skips the Config-Checker execution of Config-Checker and directly start the deployment of the respective CR.

  • Status of the Config-Checker can be retrieved from the primary server and media server CRs by using the kubectl describe <PrimaryServer/MediaServer> <CR name> -n <namespace> command.

    For example, kubectl describe primaryservers environment-sample -n test

  • Following are the Config-Checker statuses:

    • Success: Indicates that all the mandatory config checks have successfully passed.

    • Failed: Indicates that some of the config checks have failed.

    • Running: Indicates that the Config-Checker execution is in progress.

    • Skip: Indicates that the Config-Checker is not executed because the configcheckmode specified in the CR is skipped.

  • If the Config-Checker execution status is Failed, you can check the Config-Checker job logs using kubectl logs <configchecker-pod-name> -n <operator-namespace>. Review the error codes and error messages pertaining to the failure and update the respective CR with the correct configuration details to resolve the errors.

    For more information about the error codes, refer to NetBackup™ Status Codes Reference Guide.

  • If Config-Checker ran in dryrun mode and if user wants to run Config-Checker again with same values in Primary or Media server YAML as provided earlier, then user needs to delete respective CR of Primary or Media server. And then apply it again.

    • If it is primary server CR, delete primary server CR using the kubectl delete -f <environment.yaml> command.

      Or

      If it is media server CR, edit the Environment CR by removing the media server section in the environment.yaml file. Before removing the mediaServer section, you must save the content and note the location of the content. After removing section apply environment CR using kubectl apply -f <environment.yaml> command.

    • Apply the CR again. Add the required data which was deleted earlier at correct location, save it and apply the yaml using kubectl apply -f <environment.yaml> command.