Alta Data Protection Sizing Tool v 1.0

Introduction

This tool is designed to provide an estimate of the infrastructure and costs associated with deploying Cohesity Alta Data Protection in a public cloud environment. By following the steps below, you can generate a detailed sizing report tailored to your specific data protection needs.

Step 1: Input Your Parameters (Page 1)

The first page is crucial for gathering all the necessary information about your environment. It is divided into several sections:

• Workload Parameters: Enter the total size (in Terabytes or Gigabytes) and count of the data sources you intend to protect, including File Systems, VMs, and Databases.
• Common Parameters: Provide your estimated daily data change rate, expected annual data growth, and the backup window (in hours) you require to complete backup operations.
• Snapshot & Tiering Policy: Define how many native cloud snapshots you wish to retain and for how long data should be kept in the short-term retention (STR) tier before being moved to long-term archive storage.
• Backup Retention Policy: Specify the number of daily, weekly, monthly, and yearly backup copies you need to retain for compliance and operational recovery.

Step 2: Calculate Initial Sizing

Once you have filled in all the parameters, click the "Calculate" button. The panel on the right will update with a high-level summary, including the total front-end terabytes (FET) to be protected and the projected storage requirements for snapshots, STR, and LTR over five years.

Step 3: Select a Deployment Model (Page 2)

After reviewing the initial summary, click "Next". You will be prompted to choose a deployment architecture:

• NetBackup Classic: A traditional architecture suitable for smaller, more straightforward cloud deployments.
• Cloudscale: A modern, containerized, scale-out architecture designed for large, enterprise-grade cloud environments that require high scalability and resilience.

Step 4: Review Detailed Sizing and Costs

Based on your model selection, the subsequent pages will provide a detailed breakdown of the required infrastructure (e.g., server specifications, node counts) and a comprehensive cost estimate for your chosen cloud provider (AWS, Azure, GCP, or OCI). You can adjust the time period (e.g., 1 Year, 3 Years) to see how costs change over time.

Step 5: Compare 5-Year TCO (Final Page)

The final page presents a 5-Year Total Cost of Ownership (TCO) comparison between the Classic and Cloudscale models. This includes a data table and a bar chart (drawn on a canvas) to help you visually compare the long-term costs and make an informed decision.

Additional Features

• Cloud Costs: View a detailed rate card of various cloud provider services.
• View Report: Generate a summary of your sizing and cost estimation.

NetBackup Catalog Storage Optimization with External PostgreSQL Database

1. Overview

In NetBackup 10.x and later, the internal PostgreSQL database (NBDB) stores metadata for the Enterprise Media Manager (EMM) and backup images. By default, this database resides on the Primary Server’s local storage as part of the NetBackup catalog. Using an external PostgreSQL database moves this portion of the catalog off the Primary Server, reducing local catalog storage requirements. However, this does not remove the need for local catalog storage entirely.

2. What Moves to the External Database

When NBDB is relocated to an external PostgreSQL host:

Moved:

• Enterprise Media Manager (EMM) metadata
• Image metadata (structured catalog data)
• NetBackup database indexes

Remains Local:

• Backup image header files (/usr/openv/netbackup/db/images/)
• Detailed file-level metadata for restores
• Disaster Recovery (DR) files and configuration data
• Catalog-related logs
• Host-specific configuration files

3. Storage Impact

Typical savings: 10–30% of catalog size (depends on environment size and backup metadata volume).

4. Sizing Recommendations

• Still Size for Local Catalog Storage: Even with an external DB, the majority of the catalog (images/ directory) remains local.
• Plan Headroom: Maintain 20–30% free space on the primary server catalog volume for growth and operational processes.
• External DB Planning Ensure:
  • Dedicated high-performance storage
  • Low-latency connectivity to the Primary Server
  • Regular backups of the PostgreSQL DB
  • HA/replication if required
• Monitor Growth: Regularly check NBDB and images/ directory sizes to adjust capacity forecasts.

5. Key Benefits of External PostgreSQL

• Offloads a large, frequently accessed database from the Primary Server
• Can be placed on dedicated, high-performance infrastructure
• Reduces local catalog storage footprint by up to ~30%
• Allows independent scaling of DB resources

6. Limitations & Considerations

• Local catalog storage is still required for image files and restore metadata.
• External DB introduces a dependency on network availability and DB host stability.
• Additional complexity for backup/restore and DR planning.

Conclusion

Using an external PostgreSQL database in NetBackup optimizes catalog storage by removing the NBDB portion from the Primary Server. While this can save a significant amount of storage (typically 10–30%), most catalog storage requirements remain due to the images/ directory and related files. Proper sizing, planning for growth, and robust DB backup/HA strategies are critical.

Cohesity CloudScale Deployment Guide for Azure

This document provides a comprehensive guide for deploying Cohesity CloudScale Technology on Microsoft Azure using Terraform. It covers the architecture, prerequisites, a three-step deployment process, details of cloud resources, Kubernetes cluster specifics, and cost drivers.

1. CloudScale Architecture and Elasticity

a. Key Components and Functionality:

• NetBackup: Deployed on Azure Kubernetes Service (AKS) clusters for scaling the capacity of the NetBackup host to serve a large number of concurrent requests.
• MSDP Scaleout: The deduplication engine, supporting 1 to 16 replicas, can be deployed alongside primary and media servers. It provides high resilience and scalability, acting as a single storage pool for NetBackup.
• NetBackup Snapshot Manager: Deployed with autoscaling capabilities to manage data movement and snapshot operations.

b. Elasticity:

CloudScale Technology is designed with elastic services that autonomously grow and shrink as needed to optimize cloud resource usage and costs. This is achieved through:

• Autoscaling Node Pools: Kubernetes node pools (Primary, Media, Storage, Data Plane) can be configured with autoscaling, allowing them to dynamically provision and de-provision nodes based on workload demands.
• Elastic Media Server: This feature provides auto-scaling of media server replicas based on CPU and memory usage, as well as jobs queued due to maximum jobs per media server settings, significantly reducing operational costs by scaling down to zero replicas when idle.
• Snapshot Manager Autoscaling: The Snapshot Manager's data node pool can be configured with autoscaling to dynamically scale based on workload demands.

2. Pre-requisites: Networking, Azure Permissions, DNS

a. Networking Requirements

• VNet and Subnets: A Virtual Network (VNet) and subnets must be created in your Azure account prior to executing Terraform scripts.
• Required Address Spaces: Cluster Subnet ( /22 or /24), Load Balancer Subnet (/26, must be empty).
• DNS Entries in Private Hosted Zone: For Primary (1), MSDP (1), and Snapshot Manager (1).
• Outbound Internet Access: Required for the Terraform Management Server.
• Naming Conventions: Avoid using prefixes like netbackup, primary, or media.
• AKS API Server Communication: The Terraform server must be able to communicate with the cluster API server.

3. Step Deployment Process using Terraform

a. Stage 1: Base Stage

This stage provisions the foundational CloudScale infrastructure (AKS cluster, container registry, roles).

b. Stage 2: Addons Stage

This stage deploys Kubernetes resources like Cert Manager and Trust Manager.

c. Stage 3: Deployment Stage

This final stage deploys CloudScale Technology onto the provisioned infrastructure using Helm charts.

4. Cloud Resources Details and Configuration

The Terraform deployment configures various Azure cloud resources with parameters for the base and deployment stages, including instance IDs, locations, VNet/subnet names, scaling configurations, and application credentials.

5. CloudScale Kubernetes Cluster Details

• AKS Cluster: Serves as the foundation for the deployment.
• Node Pools: Dedicated node pools for different components ensure performance and isolation.
• Application Namespaces and Pods: Components are deployed within namespaces (e.g., netbackup), with decoupled services and Fluentbit for logging.
• Persistent Storage: Uses Azure Disk for data/log volumes and Azure Files (NFS) for shared storage.
• Load Balancers: Azure Load Balancers manage traffic to NetBackup services.

6. Cost Drivers for Total Cost of Ownership (TCO) in Azure

a. Variable Costs (Usage-Based)

• Azure Disks (IOPS/throughput, Transactions)
• Azure Files (Throughput, transactions)
• Load Balancers (Rules, data processed)
• Data Transfer (Endpoints, Egress)
• Azure Key Vault (Keys, API requests)
• Backup Target (Object Storage Cost, API)
• Snapshot Storage (Storage and API Cost)
• AKS nodepools (cpdatapool)

b. Fixed Costs (Less Variable)

• Azure DNS
• Terraform Management Server VM
• Software Licenses
• Personnel Costs
• Azure Container Registry (SKU, storage)
• Azure Disks (Provisioned for PVs)
• Azure Files (Provisioned)
• AKS, Load Balancer, Endpoints (Fixed Cost)
• AKS nodepools (Control Plane Nodes)

AWS NetBackup Cloudscale Deployment

1. Prerequisites for AWS (EKS)

A successful deployment hinges on correctly preparing the AWS EKS environment.

Cluster and Node Configuration:

• Kubernetes Version: The EKS cluster must be running Kubernetes version 1.27 or later.
• Node Groups: Dedicated node groups are required for the Primary server (recommended: m5.2xlarge), Snapshot Manager (minimum: t3.large with auto-scaling), and Media servers (recommended with autoscaler add-on). All nodes must run Linux.
• Node Storage: Each node should have an EBS volume of at least 100 GB.

IAM and Security:

• IAM Role Policies: The cluster's IAM role needs policies like AmazonEKSClusterPolicy, AmazonEKSWorkerNodePolicy, etc.
• OIDC Provider: An IAM OIDC provider must be created for the EKS cluster.

Storage Configuration:

• Amazon EFS: Required for the primary server's catalog. The EFS CSI driver must be installed, and the ReclaimPolicy set to Retain.
• Amazon EBS: A StorageClass using the EBS CSI driver is needed for data and log volumes, with allowVolumeExpansion set to true and a ReclaimPolicy of Retain.

Networking and Required Add-ons:

• Load Balancer: The AWS Load Balancer Controller add-on must be deployed.
• Certificate Management: cert-manager and trust-manager are mandatory.
• Security Groups: Inbound rules must be configured for necessary NetBackup ports if access is needed from outside the VPC.

2. Deployment Process

Step 1: Image Preparation:

Download the NetBackup package, load the Docker images locally, log in to Amazon ECR, re-tag each image for your ECR repository, and push them.

Step 2: Deploy Operators and Core Services:

Use Helm to install the msdp-operator, nb-operator, and flexsnap-operator, as well as Fluentbit for logging and PostgreSQL for the database.

Step 3: Deploy the Cloud Scale Environment:

Customize the environment-values.yaml file with your EKS-specific parameters (FQDN, load balancer annotations, storage class names). Use Helm to generate the final Kubernetes manifest and apply it to your cluster.

Step 4: Verification and Finalization:

Monitor the deployment until all pods are running and the environment custom resource shows a "Success" status. Finally, restart the Cloud Scale services to ensure proper initialization.