Cloud tier sizing and performance

Sizing and performance of data in the cloud is based on customer need and will vary from customer to customer, which makes providing exact sizing and performance information difficult.

To get data to the cloud, customers can use a simple internet connection if the data to be transmitted is less than the amount of available bandwidth.

Cloud providers may provide a direct connection service. Customers can get a dedicated link to their cloud provider with performance similar to LAN bandwidth inside a data center. They can compress data at the data center before being sent across the network to the cloud provider or use MSDP Cloud (MSDP-C) to optimize the data being sent before it is stored in the cloud. They can also throttle bandwidth, if desired, to prevent over-saturation of the network pipe.

Public cloud providers use a regional model in which it has configured various regions across the globe. Each region can have zones that are similar to data centers within the region that communicate with each other over high-bandwidth connections. This setup is similar to a customer having multiple physical data centers in a geographical region that are close enough for low-latency connectivity, yet far enough apart to not be affected by the same natural or artificial disaster.

Data within the region will typically stay within the region, but customers have the option to select a geographically dispersed region that is available for regional DR. Data can be replicated between zones to provide high availability within the cloud for the customer's data. The loss of a single zone does not affect the operations of the others. Customers typically choose to operate within the region that is closest to provide optimized bandwidth for moving data in and out of the Cloud and have the option to select a geographically dispersed region to provide regional DR.

One of the many benefits of the cloud storage model is the ability to quickly add storage to environments. Customers don't pay for the storage until it is provisioned. This model is much different from a traditional data center where racks of disks may sit idle until needed, thus increasing total cost of ownership (TCO). If the disk is spinning and generating heat, additional cooling and power could be needed to keep the disk spinning even if it is not currently in use. Although next-generation SSD arrays require less cooling and power, idle disks still increase TCO.

Once data is in the cloud, cloud providers uses various types of storage including block and object storage. Other options include Network-Attached Storage (NAS) services. Sizing of the environment is based on the needs of the customer and the workloads placed in the cloud. Pricing is based on the type of storage chosen and is typically priced per GB. For example, standard object storage typically runs approximately $0.023/GB per month, whereas archive storage currently runs about $0.004/GB per month and even less for archive storage tiers. Cost also depends on the region where the data is stored. (See the cloud provider's price list for current costs.) Archive tiers are typically used as long-term archive storage targets whereby data is moved there automatically using a variety of methods, and a restore from storage could take hours to access versus seconds for a restore from object storage.

The following sample sizing guidelines are based on the assumptions listed and were created using the standard NetBackup Appliance Calculator to determine the storage required for each type of workload. This guideline applies to back up in the cloud workloads only.

For more information, see About the Media Server Deduplication (MSDP) node cloud tier in the NetBackup Deduplication Guide.

The architecture is based on a single NetBackup domain consisting of a NetBackup primary server and multiple MSDP media servers in the cloud.

Typically, backups are written directly to local MSDP block storage for an immediate copy, then opt-duped to a cloud tier to send deduplicated data to object storage. However, there is no requirement that backups must go to standard MSDP before sending to cloud. If the solution doesn't require MSDP data to be "local" on block storage, then MSDP-C enables backup data to be sent directly to a cloud tier.

With MSDP-C or MSDP in general, data is deduplicated in the plug-in (source side) layer before writing to the storage server. The storage server assembles 64MB containers in memory and writes them to object storage. If the number of streams x 128MB exceeds the memory limits, disk is used as cache to assemble the containers.

The NetBackup primary server should be sized according to the standard Veritas guidelines depending on the load placed on the complete NetBackup domain. Plan accordingly for the initial needs of the environment. Cloud providers offer the added benefit of being able to scale up the systems as workloads grow. The solution can scale out by adding additional media server nodes.

Primary Server Memory and CPU Requirements

For details about the recommended memory and CPU processor requirements for the various environment sizes:

See Table: Sizing guidelines.

These estimates are based on the number of media servers and the number of jobs the primary server must support. You may need to increase the amount of RAM and number of processors based on other site-specific factors.

Primary Server Recommendations

NetBackup MSDP storage can reside on either a NetBackup Appliance, a Virtual Appliance or a build-your-own (BYO) virtual or physical host, including a cloud-based virtual instance. This section outlines MSDP in a public cloud Infrastructure-as-a-Service (IaaS)  deployment.

The host computer's CPU and memory constrain how many jobs can run concurrently. The storage server requires sufficient capability for deduplication and for storage management. Processors for deduplication should have a high clock rate and high floating-point performance. Furthermore, high throughput per core is desirable. Each backup stream uses a separate core.

As the amount of data protected by a server increases, the load requirements on that host will increase. In that scenario, there is a simple solution. You can easily expand any virtual instance or add volumes. Refer to your cloud provider's documentation for information about resizing instances and adding storage to them.

Running traditional MSDP in a cloud environment requires specific resources to be available such as a 10G network and volumes with provisioned IOPS. The recommendations below have been formulated using cloud provider kits that address MSDP pools of different sizes. These are just recommendations and specific customer environments may have different needs. Depending on the footprint, any of the environments below would work based on the sizes.

MSDP Considerations

Storage considerations

Although multiple deduplication storage servers can exist in a NetBackup domain, storage servers do not share their storage. Each storage server manages its own storage. Deduplication within a storage server is supported, including between different block and cloud Disk Pools. Optimized deduplication is supported between different storage servers in the same primary domain. Automated Image Replication (A.I.R.) is supported for replicating data and image metadata between primary domains. For a small 32 TB MSDP storage pool performing a single stream read or write operation, storage media 250 MB/sec is recommended for enterprise-level performance. Scaling the disk capacity to 250 TB recommends a performing 500 MB/sec transfer rate. Multiple volumes may be used to provision storage; however, each volume should be able to sustain 250 MB/sec of IO. Greater individual data stream capability or aggregate capability may be required to satisfy your objectives for simultaneous writing to and reading from disk. The suggested layout to use in a cloud infrastructure is a striped RAID0 or RAID1 configuration. More complex RAID configurations are not cost-efficient.

Table: Recommended media server sizing guidelines shows recommended NetBackup media server sizing guidelines based on the size of the intended deduplication pool.