Cloud and Clear: Cohesity Cloud Archival

Yep, we all agree to that! 

Cohesity provides a way to archive your secondary storage to the cloud or you can add cloud as a tier in addition to SSD and HDD.

Cloud Tier and Archival augments on-premise Cohesity storage, provides invisible additional storage. 

Cohesity supports Google, Amazon and Microsoft Azure as cloud providers for cloud tiering and archival.

Cohesity supports archival of VMs, Views(Datastore) and SQL Services.

This blog will cover

- setting up a Cloud Archival for a WindowsVM

- troubleshooting tips 

- reviewing the stats.

Setting up a Amazon S3 cloud archival on Cohesity:

1.  Configure a External Target
2.  Add the external target to an existing or a new backup policy

Cloud Archival Workflow

After the local backup is done, the snapshot will be transferred to the cloud based on the configured policy.

Here is the screenshot of a successful cloud tier archive. ( #greencloud)

And .......the archival data is in

Extra Credit:
Cloud Troubleshooting Tips ( for MAC):
a)  Installing the AWS CLI
sudo easy_install pip; sudo pip install awscli

b) Configuring the AWS CLI - region, id and keys 

aws configure

c) list S3 buckets

aws s3 ls

d) Find the job id from the URL of Cohesity UI - https://172.16.2.22/protection/job/10747/run/10748/1469037004135602/protection

e) List the encrypted S3 archival data directory

aws s3 ls s3://s3<bucketname> --recursive --human-readable --summarize|grep 10748

2016-07-20 11:10:29   14.7 GiB cohesity/icebox/7608250724803412/10747_10748_117673240_1469038227497648

2016-07-20 13:31:12   32.0 MiB cohesity/icebox/7608250724803412/10747_10748_117673240_1469046671061785

Internal Troubleshooting Tips: ( for the inquisitive mind)

Bridge Container Manages ICEBOX (cloud tiering and archival )

    a) check the logs  (increase the verbosity of bridge logs from 0 to 2 )

GFLAG                         : v, 2

[cohesity@gs1-alpha-node-2 ~]$ allssh.sh "grep curl data/logs/bridge_exec*INFO*|grep Time|tail -1"

=========== 172.16.2.11 ===========

=========== 172.16.2.13 ===========  
(Note: this is the magneto slave that is replicating the data to the cloud for this job 10748)

bridge_exec.INFO: E0720 13:28:24.495574 15328 curl_http_rpc_executor.cc:521] Executing the curl RPC: 1612 failed with error: 28, status msg: Timeout was reached, time taken: 30001 ms

=========== 172.16.2.14 ===========

=========== 172.16.2.12 ===========

 The above output informs us that there are timeouts due to cloud archival taking more than 5 minutes for this operation operation.
Bro Tip: There is a gflag to increase the timeout, if the connectivity to s3 is slow. (ping bucketname.s3.amazonaws.com)

GFLAG NAME: bridge_s3_adapter_http_request_timeout_msecs, 180000

Note: Cloud tiering uses 8 MB block size for each operation. Cloud archival uses 32 MB block size for each operation.

   b) Live Traces can be reviewed (http://cohesity_node_ip:11111 -> icebox master) and review the job instance id 10748

 

   

c) Trace (tracez - provides information on the latency of each op)

Cohesity Cloud Archival Setup- Screenshots

1. Register the external Target ie., SRECloud (with Encryption and Compression Enabled)

2. Set up a flexible VM Backup Policy SREVMCloud 
Local backup done once every hour and it is retained for a day
Cloud archive done once a day and it is retained for a month

3. Creating a Protection job (SREWindows) that adds the VM to the above protection policy (SREVMCloud)

4. That's it, now the VM is protected locally and archived to the cloud

a)VM is backed up locally every hour and archived to the cloud once a day

b) Review the stats ( logical/transferred)

c)Screenshot of a Successful Cloud Archival (#greencloud)

Cohesity Oasis 2.8 Features

Cohesity Oasis 2.8 features that will be released in a week. We have a lot of customers doing RC/EA testing. We are waiting on their feedback before the general availability.

Backup Software:

• Ingest multiple VMDKs of a VM in parallel : faster ingest
• Adapter for SQL Server running in a VM : with the ability to truncate the logs and to do granular restore
• Cloud Archival-related enhancements: Simple Cloud Restore workflow

Backup Target:

• Compression : Support for post process as well as inline
• SMB AD Integration improvements
• Support for SMB archive bit : makes Windows robocopy efficient

Platform:

• Cluster Create enhancements - less dependency on ipv6 multicast
• Support Replication over 1GbE interfaces and support for VPN fragmentation (custom MTU size)

• Support for Bond Mode 4 (LACP) in addition to Mode6
• Apollo Smart Scheduler : background tasks scheduled automatically during non-production
• Qualified Tree Walker Algorithm
• Graceful handling of disk full conditions
• FIPS compliance
• Support CSV Downloads for additional reports

Others:

REST API documentation

Each of the features deserve a blog on their own. As time permits, I will write a blog on each of these features. For more details on 2.8 and future releases : http://www.cohesity.com/press/cohesity-expands-data-protection-physical-servers-doubles-performance/

Why do we need a secondary storage?

With compute, memory and a network that can provide a sub millisecond latency to applications, the storage latency of 5-15ms becomes a bottleneck when a very low latency is required.

This situation sparked a new revolution in the primary storage business with the advent of the expensive low latency All Flash Arrays (AFAs) and hybrid storage (SSD+HDD with Intelligent Lifecycle Manager -ILM).

Primary Storage

Purpose of Primary Storage: Performance

a) All Flash Arrays

All Flash Array (AFA) storage systems are expensive, so using it for any purpose other than to read and write the application data is not cost-effective. If the storage architects want to replicate the primary data to a remote site for Disaster Recovery(DR) purpose, they need a similar expensive High Availability(HA) pair on the remote site as well.

b) Hybrid Storage Arrays

The storage architects can use the hybrid storage array, but then they have to right size the SSD tier. the active workset can become unpredictable due to the change in application workload, multiple reads by the backup subsystem, and when running the analytics on the primary storage.

So, in addition to managing the application performance expectations, the following features must be provided

• Disaster recovery solution ( at minimum, double the cost of expensive storage arrays)
• Backup to tape/VTL/cloud using expensive backup software that requires media agents, virtual server agents, etc.
• Reports on data growth, type of data, etc ( Internal or External Analytical Engine)

Many of the features can be offloaded to the secondary storage system.

Secondary storage

The ability of secondary storage to take on many of the functions of the primary has created a huge market. 

Shortcomings of the existing backup products:

• UI is not elegant and is unintuitive
• Purpose Built Backup Appliance (PBBA) is expensive and not scalable. It is a hodgepodge of multiple incompatible solutions stuck together (backup software, storage, replication software, and cloud connector from multiple vendors).
• The backup software and media/VSA agents are complex to setup.

In short, the existing backup solution is built for backup and it cannot do anything else.

In addition to backup, the following features make the secondary storage platform interesting. 

1. Workflow: Easy to deploy, easy to scale, easy to operate with an intuitive self-guided UI
2. Test and Dev Workloads: Optimized for backup and test/dev workloads at the right price/performance point
3. Data Reduction Technologies: Higher Compression and dedup ratio for a longer retention period.
4. Snapshot and Change Block Tracking(CBT): Hydrated snapshots for a low RPO/RTO, forever incremental backup and instant recovery
5. Data Throttling: By controlling the ingest, storage architects can backup during work hours without affecting the application performance
6. Intuitive and customizable backup scheduler
7. DR capabilities: Ability to replicate from one secondary storage to another remote secondary storage without affecting the application performance
8. Analytics workBench: Analyze the data for trends without affecting application performance and ability to build custom search capabilities. It utilizes big data analytics to analyze dark data
9. Cloud Archival: Easy workflow and support for multiple cloud providers
10. Automation and customization: Programmable interface (REST API) , so customers can automate their backup and replication workflows (data pane) in addition to managing the dashboards (control pane)
11. Backup and Restore anything: Ability to backup virtual machines and physical machine
12. Application Aware Backup and Restore: Adapters for various applications to provide app consistent backups with log file truncation and the ability to do granular restores ( SMBR- single mailbox restore, FLR - file level restore)
13. Reuse the existing backup solution: It should act as a backup target for Commvault, Netbackup, Veeam and other backup solutions
14. Encryption: Ability to encrypt the data when written locally or to the cloud

I will blog about these feature in the future. I am still learning the ropes of secondary storage and would love your feedback.

Please visit Cohesity at http://www.cohesity.com for more details.

Purpose of secondary storage: Backup, File services, Analytics and whatever you can imagine

Ack: Thanks to my editor and patient wife Lori. twitter @lori_cpa