dpaas—factors to determine the - dell technologies

Balaji PanchanathanPrincipal Software Quality EngineerEMC [email protected]

Pravin Kumar ASenior Software Quality EngineerEMC [email protected]

Satchidananda PatraSoftware QA Group Team LeadEMC [email protected]

DPAAS—FACTORS TO DETERMINE THE RIGHT ARCHITECTURE

mailto:[email protected]



2015 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Introduction ................................................................................................................................ 3

Data protection........................................................................................................................... 3

Market Size ............................................................................................................................ 3

Backup/Recovery Services ..................................................................................................... 3

Archiving/Compliance ............................................................................................................. 4

Disaster Recovery .................................................................................................................. 4

Requirement Gathering .............................................................................................................. 4

Secondary Research .............................................................................................................. 4

Primary Research ................................................................................................................... 5

Capabilities of the service provider............................................................................................. 6

Choosing the right segment product ........................................................................................... 7

Level of protection .................................................................................................................. 7

Level of Cloud Integration ....................................................................................................... 8

Avamar/NetWorker 8

Primary or application level storage protection ....................................................................... 9

How to zero in on the right product ........................................................................................10

Security ..............................................................................................................................10

Network Requirements .......................................................................................................10

Scalability...........................................................................................................................10

Manageability .....................................................................................................................10

Pricing .......................................................................................................................................12

Architecture ...............................................................................................................................12

Conclusion ................................................................................................................................14

References ...............................................................................................................................15

Glossary....................................................................................................................................16

Appendix ...................................................................................................................................16

Disclaimer: The views, processes or methodologies published in this article are those of the

authors. They do not necessarily reflect EMC Corporation’s views, processes or methodologies.


Introduction

Proliferation of cloud services has caused an increased need for providing data protection as a

service in the cloud. This Knowledge Sharing article begins by covering data protection as a

service (DPaaS) in general terms, then examines how a service provider can gather the

requirements based on their target customer and price point, and concludes with a discussion

on design of the appropriate architecture.

Data protection

Market Size: From 1.2B in 2012 and expected to reach CAGR of 28% in 2015

Typically, service providers have an existing relationship in hosting a customer’s site, exchange,

database, etc., and see data protection for those services as an upsell opportunity.

A value-add of data protection services is that recovery to a point in time can be taken using the

data protection services should user error or data corruption occur.

Data protection covers:

Backup/Recovery Services

Archiving/Compliance

Disaster Recovery

Backup/Recovery Services

A backup of file system/database at a point in time is taken and stored for future reference. The

backup stored has data and metadata. Metadata information includes when the backup was

taken as well as all the files that have been taken. This information will be used in restore. Usual

use cases include:

File system/Exchange: If a user accidentally deletes a file/email, restore can be done

for that particular file/email

Database: If a database is corrupted, regular backups can restore last useful state

Virtual images: - When a virtual machine/image is crashed, the same can be

restored


Archiving/Compliance

The market size for cloud premise archiving is around $1 Billion and is expected to reach $2

Billion in 2016. Cloud can be used for long term archiving and compliance. Email archiving

makes up the majority of archiving deployment. Key features of archiving are:

Security

Tamper-Proof – Customer choose private-public key encryption where the data will

be encrypted using public key and can be decrypted only using private key

Indexing, search requirements

Disaster Recovery

Disaster recovery as a service is a fast growing segment, expected to grow by 50% up to 2018

and reach a market size of $5.7 Billion. Disaster recovery provides business continuity as a

service. Here, the required architecture will be decided based on two important factors:

1. RTO – Recovery Time Objective

2. RPO – Recovery Point Objective

Requirement Gathering

Secondary Research

Secondary research about the customer’s requirement can be performed by going through

industry analyst reports (Gartner, etc.) and general surveys conducted by analyst firms such as

IDC.

EMC commissioned a study to determine the data protection readiness of different customers.

The findings, provided in the URLs found in the References section at the end of this article,

rank the countries based on the data protection readiness. The report can also be used to target

customers with the right products. For example, if the customers are more concerned about

protecting their cloud applications, a Service Provider can deploy products which protect their

cloud applications (i.e. Spanning products from EMC). Customers with a hybrid cloud

environment can use Maginatics to protect while those having Azure can use Avamar® on

Hyper-V to protect their environments.

Clearly, performing secondary research will help enhance primary research which involves

talking directly to potential customers.


The outcome of secondary research could uncover that:

More customers are struggling to protect their cloud, mobile, etc.

Customers have more of hybrid cloud and are struggling to protect their public cloud

storage

Customers are willing to protect their data on cloud but are not doing it because of:

o No trusted vendor ( Service Provider )

o Security considerations

With the above set of inferences/inputs, Service Providers can plan primary research better.

Primary Research

A survey can be conducted among potential customers and, based on that, specific needs can

be identified and informed decisions made on the architecture and the products used. The

survey can include a set of broad questions which will provide insight to the customer’s

expectation and requirements.

The survey/questionnaire can be broadly structured in the format below.

1. Do they have any data protection solutions in-house? If so, ask

a. What type of solution they have

b. Whether the existing solutions meet all their requirements and if they do not

i. What requirements are not met by the current solution

c. What are the typical problems faced in the existing solution

d. Whether they would like to protect their mobile data/cloud, etc.

2. If they do not, probe why

a. They felt there is no need

b. Cost

c. Not aware of the benefits, etc.

3. After this, present the option of data protection in the cloud followed by asking

a. Whether they are interested in using data protection as a service and, if so, for

what purpose.

i. For disaster recovery, operational recovery, etc.

ii. Based on the purpose, further questions should be asked, i.e. what are

their RTO, RPO expectations

iii. Whether they want to back up any applications, databases, etc


iv. Protect only cloud applications, etc.

b. If they are not willing to use DPaaS, what are their reasons

i. Security? Control? Other?

ii. What would drive them to use DPaaS?

From the customer responses and survey analysis may infer

1. Level of data protection solution in-house

2. Type of services they expect from DPaaS

3. How to frame the architecture will mitigate the reasons for not using the service

4. Level of cloud integration

5. Whether they have challenges in protecting cloud/mobile/big data, etc.

Capabilities of the service provider

From the requirements gathering and their willingness to pay the service provider one can fairly

conclude what type of data protection services will be profitable. The next step would be to look

internally at the capabilities and strengths of the service provider and accordingly decide on the

offering. The chart below can be used to decide on the data protection offering.

Profitability High 3 4

Profitability Low 1 2

Low High

Ability to offer the service

The service provider should put the different data protection service offerings in the graph above

and preferably choose the data protection offering which falls under the 4th quadrant of the

graph.

Once the customer decides on the data protection service offering, service provider should

determine the right products for that offering. How to choose is discussed in the next section.


Choosing the right segment product

The architecture and products the service provider recommends will depend on the needs of the

target market.

We categorize the customers under a broad set of categories:

Level of protection

Level of Cloud integration

Protecting their mobile

Application or Primary storage level protection

The type of architecture and the products will vary based on each category, discussed below.

Level of protection

Level of protection refers to recovery point objective (RPO). It can range from a few seconds to

a few days. In the cloud, RPO is typically in the range of hours. Thus, a customer that requires a

RPO of seconds cannot be accommodated it is not possible to provide the same using cloud

service.

For RPO of a few seconds, the ideal product is RecoverPoint. For hours to days, there are

backup products such as Avamar®/NetWorker®/Symantec/Commvault. A couple of service

providers operating in this area are bluerock and vision solutions.

The available products in various levels of protection is given below.

RecoverPoint RecoverPoint/Netappsnapshot NetWorker NetWorker

Tape

In Seconds Minutes Hours Days

Weeks

The RPO shown above can be achieved with the products mentioned if it is on-premise. If it is

provided by a service provider, the WAN conditions need to be taken into account. Hence, an

RPO of seconds can be achieved only by an on-premise solution. Meanwhile, cloud hours/days

can be achieved by using Avamar, NetWorker, etc. Note that Avamar is more focused on the

service provider market.

http://www.visionsolutions.com/


While DPaaS providers should not target customers who have RPO of seconds, if they do, both

the primary and secondary data should be on their cloud/data center.

Level of Cloud Integration

Based on the type of cloud, solutions will vary and there are four levels of cloud:

1. On-premise

2. Private Cloud

3. Hybrid Cloud

4. Public Cloud

RPO in seconds

spanning

RPO in Hours

AVE Spanning/AVE

On-premise Private Cloud Hybrid Cloud Public Cloud

Avamar/NetWorker Avamar Maginatics Tape RPO in Days Tape RPO in weeks

X-axis – level of cloud integration

y-axis – level of protection

Products – Bold


Primary or application level storage protection

A business that is based on application criticality and cost will decide on the RTO/RPO for each

of the business applications and then decide on the vendor for those business applications. The

service provider can categorize the market based on:

Protection of applications like ( Database, MS Apps etc)

Primary storage protection

Level of Protection (RTO and RPO). Based on the RTO/RPO the cost and price will vary

In the graph below, x-axis is the level of application knowledge and y-axis can be the level of

protection; RTO/RPO.

Customer A RPO in seconds

Customer B RTO in Hours

Raw Storage OS level(Linux/Windows) Database Application

RTO in days

RTO in weeks

Using the graph, service providers can visually plot the different customers, fit them into the

graph, and then decide on the best option and work on the architecture accordingly.

For example, in the graph above, Customer A wants to protect their raw storage (Symmetrix®,

etc.) and the RPO should in seconds. In this case, the appropriate product would RecoverPoint

etc

Similarly, Customer B would like to protect their OS and want RTO in hours. For them, the

appropriate products would be Avamar, NetWorker, Symantec, NBU, etc.


How to zero in on the right product

After deciding on the level of protection/cloud/mobility, etc., shortlisting different products should

be done using the criteria below.

Security

Security requirements will differ based on the customer profile. Major factors to consider are:

Compliance with different standards. For example:

o Health Insurance Portability and Accountability Act (HIPPA)

o Federal Information Processing Standard (FIPS)

Multi-tenancy

Network Requirements

Performance

When performing their secondary research, the service provider should zero in on the customer

requirements. What is the performance required for each category? Below are some of the

ways in which the performance can be measured.

Backup of OS should be 100GB/hr with network bandwidth of 10Mbps

Replication should be completed within 1 hour for 300TB of data

Scalability

Service providers should project the amount of data protected over a period of time and the

supported data by the vendor should be matched.

Manageability

How easy is it to manage multiple customers and multiple accounts?

o Does the vendor provide APIs which can be used by the service provider to

easily manage multiple customers easily and with lower cost?

Service providers should calculate the cost of managing each customer to arrive at total

cost of ownership (TCO). This will include:

o Hardware

o Software

o Cost of administrative person/per customer

Deployment (automated way of deploying in the cloud, i.e. CHEF and PUPPET). Service

providers can check how easy it is to deploy the products and the architecture and the

time taken to deploy the architecture and get it production-ready.


The service provider should evaluate each of the products shortlisted based on the above

criteria and then select the final product, using the table below.

Security Performance Manageability Scalability Total

Product A 6 5 4 4

Product B 8 6 5 5

Product B 7 8 9 10

Different weights should be given to the different attributes to arrive at a final value. Based on

the values of all the products, the final product can be selected.

The weight given to different attributes will depend on the relative importance given to each

attribute by the customer. Thus, after deciding on the customer segment, the service provider

should do further analysis and find the relative importance given to each attribute by that

customer segment.

For instance, the service provider can determine that the weight for security is 0.3, performance

0.2, manageability 0.3, and scalability 0.2. Applying the values above, the total for product A will

be = 6*0.3 + 5*0.2 + 4*0.3 + 4*0.2 = 1.8+1+0.2+0.8=3.8.


Pricing

This section provides broad guidelines on pricing strategy.

First, we will look at the pricing schemes currently offered by some of the players.

Pricing per Raw storage of backup data – 0.3$ per GB per month

Pricing per Application complexity + Storage – 1$ per GB per month for MSSQL, etc.

Pricing per Recovery – very low base price for backup and a separate price per recovery

Again, the pricing depends on the target customer and their requirements. If your target

customer wants high application level protection, pricing should also be based on application

level .

Currently there are more service providers in the disaster recovery as a service area. Some of

the prominent providers are CenturyLink, netmagic, and zerto.

Architecture

After the set of products are selected based on the requirements, the next step would be how

the products will be deployed. Decisions below have to be made to determine the network and

deployment architecture.

Will the products be virtual or physical appliances?

Depending on the customer’s RPO objectives, a service provider might deploy an

availability solution such as VPLEX® to failover to another site in case of disaster in one

of the service provider’s data centers.

What will be the storage device for these backup products?

o Data Domain®

o Avamar

o Symantec

Are there any requirements for edge appliances? (deploying a device in customer

premises)

Is there a requirement of role-based access control?

API support (webservices). What type of API’s need to be developed by the service

provider? This will largely depend on the level of control required by the customer. If the

customer wants more control, it is better to give more API control to enable them to get

stats through the API itself.


The decisions above will be made based on the factors below.

In the requirement gathering phase, the service provider will come to a conclusion on the

level of RTO/RPO and then decide on the service level agreement (SLA). The SLA will

play a major role in deciding the architecture. For example, if the customer’s RPO

requirement is in hours and the bandwidth is limited, it is better to deploy a caching/edge

appliance in the customer premise and then periodically replicate it to the service

provider’s environment.

The architecture needs to be designed depending on the level of control required by the

customer. If the customer is not comfortable with multi-tenancy, a new virtual edition is a

better option for each customer.

Growth rate of customer acquisitions and their data growth rate must be considered. If

the customer wants to scale very fast, a physical appliance with high end device is

necessary. Conversely, a virtual appliance should be fine if the growth of the customer

and their amount of data is slow.

Backup window of the acquired customers.

Network conditions

o Loss/Delay/Bandwidth between the client and the backup server.

Security concerns

o The product should provide secure multi-tenancy and cryptographic key

management capabilities. For example, Data Domain has key management

capabilities and integration options with external management vendors, such as

RSA and others.

Ease of deployment and whether there is support for automated provisioning of the

products and services, etc.

If the backup window is small and growth rate of new customer acquisition is large, the safer

decision is to opt for a physical appliance. Otherwise, a new virtual appliance can be

provisioned as and when new customers are acquired.

Similarly, the service provider must study the performance of the different backup vendors

under different network conditions and evaluate it.


Conclusion

Service providers can zero in on the right product if they conduct proper research in identifying

the requirements of his target customers. Thus, if the first step of identifying the requirements is

clear and accurate, selecting the right architecture and right products will follow seamlessly. The

approach described in this Knowledge Sharing article is summarized below.


References

http://www.asigra.com/sites/default/files/resource_center/WP-7155.pdf

http://en.wikipedia.org/wiki/Email_archiving

http://www.computerweekly.com/feature/Cloud-archive-What-it-is-and-what-types-of-cloud-

archive-services-exist

http://www.marketsandmarkets.com/PressReleases/recovery-as-a-service.asp

http://webserver2.deloitte.com.co/ERS/Disaster%20Recovery%20as%20a%20Service.pdf

http://www.drdobbs.com/web-development/replication-as-a-service-widens-on-

deman/227900007

http://india.emc.com/collateral/hardware/white-papers/h9542-emc-vplex-business-continuity-

sap-wp.pdf

http://www.emc.com/about/news/press/2014/20141202-01.htm

http://www.emc.com/microsites/emc-global-data-protection-index/index.htm?cmp=SOC-14Q4-

GDPI-OT

http://www.emc.com/microsites/emc-global-data-protection-index/index.htm?cmp=SOC-14Q4-

GDPI-OT

http://www.bluelock.com/cloud-services/raas/pricing/

http://redmondmag.com/articles/2013/11/08/microsoft-cloud-backup-service.aspx

http://msdn.microsoft.com/en-us/library/azure/dn251004.aspx

http://www.vazata.com/Blog/disaster-recovery-as-a-service-market-to-grow-by-over-50-in-the-

next-four-years

http://www.emc.com/collateral/analyst-reports/information-archiving-market-quadarant-2013.pdf

http://www.computerweekly.com/report/Email-archiving-market-matures

http://www.asigra.com/sites/default/files/resource_center/WP-7155.pdf

http://en.wikipedia.org/wiki/Email_archiving

http://www.computerweekly.com/feature/Cloud-archive-What-it-is-and-what-types-of-cloud-archive-services-exist

http://www.computerweekly.com/feature/Cloud-archive-What-it-is-and-what-types-of-cloud-archive-services-exist

http://www.marketsandmarkets.com/PressReleases/recovery-as-a-service.asp

http://webserver2.deloitte.com.co/ERS/Disaster%20Recovery%20as%20a%20Service.pdf

http://www.drdobbs.com/web-development/replication-as-a-service-widens-on-deman/227900007

http://www.drdobbs.com/web-development/replication-as-a-service-widens-on-deman/227900007

http://india.emc.com/collateral/hardware/white-papers/h9542-emc-vplex-business-continuity-sap-wp.pdf

http://india.emc.com/collateral/hardware/white-papers/h9542-emc-vplex-business-continuity-sap-wp.pdf

http://www.emc.com/about/news/press/2014/20141202-01.htm

http://www.emc.com/microsites/emc-global-data-protection-index/index.htm?cmp=SOC-14Q4-GDPI-OT




http://www.bluelock.com/cloud-services/raas/pricing/

http://redmondmag.com/articles/2013/11/08/microsoft-cloud-backup-service.aspx

http://msdn.microsoft.com/en-us/library/azure/dn251004.aspx

http://www.vazata.com/Blog/disaster-recovery-as-a-service-market-to-grow-by-over-50-in-the-next-four-years

http://www.vazata.com/Blog/disaster-recovery-as-a-service-market-to-grow-by-over-50-in-the-next-four-years

http://www.emc.com/collateral/analyst-reports/information-archiving-market-quadarant-2013.pdf

http://www.computerweekly.com/report/Email-archiving-market-matures


Glossary

AVE – Avamar Virtual Edition

DPaaS – Data Protection as a Service

NDMP – Network data management protocol

RTO – Recovery time objective

RPO – Recovery point objective

Appendix

RecoverPoint If your RPO is in seconds, RecoverPoint – a Continuous data protection

appliance – is the solution.

Avamar This backup/recovery product has deduplication technology and support for a variety of

applications, shown below:

1. MS Apps

2. Databases (Oracle, DB2)

3. Mail – MS Outlook, Lotus

4. SAP Hana

It has support for NDMP and primary storage such as Isilon®.

Backup frequency depends on the RPO objectives.

It supports backing up Laptop/desktop environments and is tightly integrated into virtual

machines (VMs).

NetWorker Similar to Avamar, NetWorker is deployed as software and supports a variety of

applications. It is tightly integrated with Data Domain.


VPLEX availability Customers might not ask for this explicitly but based on the SLA in regard

to uptime (99.99%), requirements will vary. There are different VPLEX offerings

VPLEX GEO: Move data between sites spread geographically so in case of failure of at

one site, the other site will become active and the data will be spread across sites.

VPLEX Local: In this deployment, data is spread across a heterogeneous array and not

across sites.

Spanning

Protecting Public cloud applications, Spanning currently supports backup of these cloud

applications:

1. Salesforce

2. Google apps

3. Office365

Backup is done to Amazon S3 and a UI is provided where customers can view their backups,

etc.

Maginatics

Maginatics is a product best suited for hybrid cloud where the data can be protected in both

public and private cloud and metadata is stored in Maginatics filer.

Mozy

Mozy provides secure cloud backup of desktops/laptops, etc. However, it cannot be used by

any service provider since Mozy itself is a cloud service provider.

Data Domain

Data Domain® is a target deduplication storage device used along with Backup Software. It

supports:

EMC – Avamar,NetWorker

Symantec – Netbackup

Commvault - Simpana


EMC believes the information in this publication is accurate as of its publication date. The

information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION

MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO

THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an

applicable software license.

dpaas—factors to determine the - dell technologies

Documents