High Availability and Amazon AWS

A lightning in Dublin knocked out Amazon and Microsoft data centres offline for few hours and it took sometime to get all the services restored.

Although it did affect Netflix, foursquare and few others, thankfully Druva cloud services were completely unaffected by this. Here is a small note on how we managed to keep our promised SLA.

I think its plain ignorance or mis-planing to assume 100% availability of underlying infrastructure. Just like any hardware, the AWS infrastructure is prone to failures, but the knowledge of these potential failure points can help improve availability.

Since its a backup service, we have have divided our cloud design into 3 parts based on the availability and durability guarantees :

  • Config (most available): Configuration data stored in Amazon RDS
  • Meta-Data : Druva Dedupe file-system spanning across Cassandra nodes
  • Data (most durable): Stored in S3

And some design changes we incorporated to avoid downtimes :

  • Multi-Zone replication: Both RDS and Cassandra nodes are replicated across 3 availability zones. We use Cassandra in full-consistency mode and heavily rely on its self-healing, in case of service failures.
  • Reduced Dependency on EBS: EBS is a software abstraction of an underlying SAN storage. And two independent EC2 instances may share same SAN for EBS. Given this we shifted our focus from EBS to local-storage for meta-data.
  • Extra space copies in S3: We so maintain some extra redundancy on top of S3 for most referenced blocks. This essentially is to avoid the random (but less frequent) S3 time-outs and improve durability of most concurrent data.

We surely paid more for improved availability, but there are simple design changes which can help save as well. For example the 3-way replication increased our compute(EC2) cost by over 200%, but because of extra spare we could increased the data stored per instance, which was earlier restricted to maintain a good cache-vs-on-disk ratio.

For Laptop Backup – Be Your Own Customer

The phrase “eat your own dog food” or the more palatable “drink your own champagne” gets bandied about a lot in Silicon Valley. (I swear I’ve heard it almost as much as “win-win” and “pure play”). I’ve worked at a number of companies where we’ve said this, and done it, with varying degrees of success. No matter the level of success, it’s an important process, since it forces your company to be more customer focused.

At Druva, we walk a mile in our customers shoes, and every employee uses inSync for laptop backup. Prior to any release, we go through the upgrade or installation process ourselves. What this allows us to do is feel any pain first, and make any adjustments as necessary to avoid transferring that pain to the customers. By using the product on a daily basis, we can put it through it’s paces and watch it for performance, scalability, ease of use and so on. It’s been fun and we’ve learned a lot, not only for laptop backup, but also using the iPad and iPhone interface. It also allows anyone within the company to make suggestions about the products as they use them, which is key to our ideas on innovation as we saw in our inaugural Druva Hack Day. We’ve had lots of great ideas from all of our employees, and our product roadmap is pretty exciting.

I actually had to recover a presentation I was working on that I lost recently. I felt the cold panic, the “Oh No!” moment (ok, I didn’t say “No”, I said something else, that rhymed with “truck”, but keeping this blog at a PG-13 rating is important). I recovered the file easily using inSync. It just worked. Very often in Marketing, we will tout certain features and throw out statistics on product performance, but the one thing I realized in using inSync is that, when we say it’s the most simplified laptop backup solution out there, it’s true. And it is lightning fast. It’s a good feeling to be able to stand behind your product like this, and we also hope that customers know that we’re in the trenches, eating dog food or drinking champagne with them.

Why Druva is Like A Newborn Calf

We recently had the chance to present to a group of bloggers and writers at Tech Field Day, an industry event organized by the fine folks over at Gestalt IT (big shout out to Stephen Foskett & crew). It was a great event, and by all accounts everyone seemed receptive to our story, despite the fact that we were last up on a day of presentations. One writer, Tom Hollingsworth, was first to write about what he learned from Tech Field Day, and also wrote a nice article on Druva, comparing us to a calf.

Yes, I said calf, or rather, Tom did.

But this is the great thing about bloggers and writers, and presenting to your peers. They look at things differently, offer different opinions and insights. And to Tom, the rise that Druva has had, amassing over 600 customers globally in 3 short years, was nothing short of miraculous, reminding him of how a calf can stand on it’s own a few short hours after being born. I’d never really thought of it that way, but after reading it, felt it was a fitting comparison. It means we must be addressing an important problem, and the way we’re addressing it, is in the right way.

Of course, to piggy back off of this, the question now is, can Druva grow from a calf to a bull. We’d like to think so, – the recent press coverage we’ve received on our launch was pretty compelling, picked up by InfoStor, StorageNewsletter.com and NetworkWorld among others. In an article on Network Computing Howard Marks said:

“I am constantly amazed at how frequently organizations leave the data on those laptops essentially unprotected. By taking a unique application aware approach to data deduplication, Druva’s Insync may be the best solution to date to this seemingly intractable problem”

Bullish words indeed…

 

Druva inSync now available for iPads and iPhones

I have a confession. I admit I’m a former Windows user turned Mac Geek (no, I don’t have a black turtleneck, you have to draw the line somewhere). Of course, being an avid Mac user I spend a lot of time on my iPad, checking email, reading blogs, reviewing documents, checking designs, surfing the web, downloading apps etc.

Druva inSync Login on iPad

Seems like I continuously have my head in my iPhone these days too, mostly for work (though I have been known to play the odd game or three of Fruit Ninja – highest score so far is 645).

 

Up to now, if I ever needed a file urgently, say a PowerPoint deck or a PDF, I would either pull that from my laptop, or have to dig it out of email.

With the recent release of inSync 4.1 support for iPhone & iPad, now all of the files that are on my laptop I can access via backups on my iPhone or iPad using the inSync remote client.

The inSync client installs just like any other app. Once installed it’s very easy to use, you configure it to point to your inSync server, add your username and password and voila, you now have access to all of your backed up data over time. Simple.

 

The 4.1 release of inSync Enterprise also included some important and exciting additions, such as HyperCache, multi-admin support, and Active Directory integration, making it extremely easy to import and maintain users. And this is just the tip of the iceberg, already we have plans for additional development to add more functionality and extend our protection beyond the laptop to iPads, iPhones and more. Exciting times ahead…

 

Oops, I Lost My Laptop !

According to the recent study by Ponemon Institute, “Airport Insecurity: The Case of Lost Laptops”, sponsored by Dell, business travellers lose more than 12,000 laptops per week in U.S. airports.

Mobile Workforce Airports

According to the same study, which examined losses at 106 of the U.S.’s largest airports, the top 36 “Class B” airports averaged 286 lost laptops per month, which is about one laptop lost every 2.6 hours at these airports. The study also found that only 66% of the lost laptops were never recovered and about a third of those recovered were reclaimed.

Enterprise data is more dispersed and diverse than ever. And with over 30% corporate data sitting on PCs, administrators can no longer hold the end user responsible for protection of this critical corporate data.

The the above statistics clearly states the need for the following two solution on every single corporate PC  -

  • Data Protection Solution – Designed for laptops, keeping in mind the mobile workforce
  • Disk Encryption and Data Leakage Prevention Solution

Shameless Plug: Druvaa inSync is a simple, fast scalable and solution especially designed for mobile workforce. Learn more here – http://www.druvaa.com/insync/laptop-backup

Why so much delay in inSync 3.1 and Phoenix ??

Well, first let me confess that inSync v3.1 took much more time than we planned.Time We had initially planned to release inSync by July 09 and Phoenix public beta by Sep 09.

In Short -
We are working on a new storage engine codename Blackbird (based on the SR-71 legend). The new engine will use application specific deduplication technology to improve performance and bandwidth/storage savings.

Initially planned for inSync v3.1 and Phoenix v1.0 , this now will be available in next major releases.

The longer version -
For the past two years, we have been doing experiments on various different algorithms for global source based data deduplication. While releasing inSync v2.0 we finalized on chunk based or variable-block based data deduplication, because of the simple fact that it was tough to find similar data blocks at natural block boundaries across different users. We also worked on the performance which gradually improved over time.

While the approach was reasonably accurate, there was a scope of significant improvement. We realized that 90% of the backup data on customer PCs comes from the documents and PST files, hence something totally focussed on PST files can dramatically improve the deduplication performance.

Also, while working on Phoenix, we came across a bigger challenge of finding duplicates across different data sources within the enterprise. We soon realized that simple block based approach will not take us too far. We also realized that most of the vendors use fixed and variable block/chunk based hashing techniques. This works well for them, because they have been treating backups as “byte streams”, and the only way to remove duplicates is fixed or variable size data deduplication.

Looking at various data types and possible ways improve, we could clearly see two fundamental changes in our approach which could bring paradigm shift in data deduplication -

  1. For accuracy – Application aware data deduplication
  2. For performance – Hierarchical block based deduplication

Application aware deduplication, can actually pin point duplicates across PST file attachments and  normal office documents.

On the PC side, majority of the data is office documents and Email files. This makes it simpler to introduce the new approach, but still a lot of work needs to be done to productise it. For Phoenix, the problem is much bigger and would take some more time to solve.

The new engine should be ready soon. It would be shipped first in inSync v4.0 early next year and then in Phoenix v2.0 . In the next few posts, I will try and get some benchmark data.

The Dark Side of The Cloud

We all pay our monthly electricity bills. I am sure no one wants to own a power plant :) But, on the contrary most of us own cars and very few rent it for daily use.

The two most important factors which decide how we want to use these two services are -

  1. The cost of ownership
  2. The cost and effort in maintenance

Cloud computing today promises benefits (which are similar to using electricity) for computing, hosted application and storage. Although the offer is very lucrative, but their is a dark side to this as well.

The post just tries to some aspects which you must keep in mind before making the plunge.

The Dark Side of Cloud

The Dark Side of the Cloud

Application Integration

Most of the services like SimpleDB, EBS, SQS still needs a lot of application integration and porting. And that’s something enterprises hate. It’s one of the primary reasons the X86 architecture and IPV4 are so widely used. Even if someone ports the application to these services, he is guaranteed to be locked with it for the rest of his life :)

Services like salesforce.com don’t need any porting, but there have been cases of access to data being refused customers who wish to change the vendor.

Uptime and QoS Guarantees

Most of these services including Amazon and Salesforce do not give uptime and QoS guarantees. The billing and EULA are free from any such clauses.

And when there is a downtime, you can’t do much than start calling the support center to play the blame-game.  And its funny when see the the cloud provider talking the same language to its service provider :)

It’s No Way Even Close to Perfect

Take a recent unfortunate situation for Ylastic, a company that provides a single front-end to manage Amazon Web Services, who was recently an unwillingly participant in one of these cloud bursts. Ylastic noticed something strange occurring with one of the Amazon Elastic Cloud Compute (EC2) Elastic Block Stores (EBS).

But something wasn’t quite right. And over the course of a few hours the story played out via Twitter as Ylastic noticed issues with its EBS instances. When the problem was finally identified, Ylastic discovered that the data could not be recovered. They were forced to recover from an earlier snapshot, that contained only a subset of the data.

Finally, after recovering what data they could, Ylastic had to go to its customers with the unfortunate message:

“AWS has finally terminated the frozen instances. But the EBS volume is still detaching and has been for hours. It doesn’t seem like we will be able to get into it at this point. Some time in the last month or so, our EBS snapshotting of this stuck volume seems to have stopped working correctly…. We have gone back and run through all the snapshots, and the last good snapshot that we have is from October 1.”

Who was at fault? Amazon? Ylastic? Truly, no one. It was simply a combination of issues. A perfect storm in the cloud, as it were. And that perfect storm resulted in data loss for Ylastic and its customer base.

Control

Take for example the case when you take up a cheap hosted website plan on a shared server. You can still negotiate uptime and QoS guarantees. But, what you just can’t control is a SPAM King sharing the same server and IP address with you :)

Most likely you will face two problems -

  1. A slow response on the website- the SPAM King has taken up the computing
  2. Public mail servers will mark the mail traffic from you as spam :)

Plus, there been many stories around salesforce (read this and this) and twitter getting hacked.

ROI

Cost of ownership for a power plant is so damn high, that you just can’t afford one even if you are not happy with your power company. That exactly has to be the case for the cloud.  No one would think of hosting his own solution when the cloud offers the same peanuts.

File-systems Vs Databases

This topic has been on my plate for some time now. It’s interesting to see how databases have come a long way and have clearly out-shadowed file-systems for storing structured or unstructured information.

Technically, both of them support the basic features necessary for data access. For example both of them ensure  -

  • Data is managed to ensure its integrity and quality
  • Allow shared access by a community of users
  • Use of well defined schema for data-access
  • Support a query language

But, file-systems seriously lack some of the critical features necessary for managing data. Lets take a look at some of these feature.

Transaction support
Atomic transactions guarantee complete failure or success of an operation. This is especially needed when there is concurrent access to same data-set. This is one of the basic features provided by all databases.

But, most file-systems don’t have this features. Only the lesser known file-systems – Transactional NTFS(TxF), Sun ZFS, Veritas VxFS support this feature. Most of the popular opensource file-systems (including ext3, xfs, reiserfs) are not even POSIX compliant.

Fast Indexing
Databases allow indexing based on any attribute or data-property (i.e. SQL columns). This helps fast retrieval of data, based on the indexed attribute. This functionality is not offered by most file-systems i.e. you can’t quickly access “all files created after 2PM today”.

The desktop search tools like Google desktop or MAC spotlight offer this functionality. But for this, they have to scan and index the complete file-system and store the information in a internal relational-database.

Snapshots
Snapshot is a point-in-time copy/view of the data. Snapshots are needed for backup applications, which need consistent point-in-time copies of data.

The transactional and journaling capabilities enable most of the databases to offer snapshots without shopping access to the data. Most file-systems however, don’t provide this feature (ZFS and VxFS being only exceptions). The backup softwares have to either depend on running application or underlying storage for snapshots.

Clustering
Advanced databases like Oracle (and now MySQL) also offer clustering capabilities. The “g” in “Oracle 11g” actually stands for “grid” or clustering capability. MySQL offers shared-nothing clusters using synchronous replication. This helps the databases scale up and support larger & more-fault tolerant production environments.

File systems still don’t support this option :(   The only exceptions are Veritas CFS and GFS (Open Source).

Replication
Replication is commodity with databases and form the basis for disaster-recovery plans. File-systems still have to evolve to handle it.

Relational View of Data
File systems store files and other objects only as a stream of bytes, and have little or no information about the data stored in the files. Such file systems also provide only a single way of organizing the files, namely via directories and file names. The associated attributes are also limited in number e.g. – type, size, author, creation time etc. This does not help in managing related data, as disparate items do not have any relationships defined.

Databases on the other hand offer easy means to relate stored data. It also offers a flexible query language (SQL) to retrieve the data. For example, it is possible to query a database for “contacts of all persons who live in Acapulco and sent emails yesterday”, but impossible in case of a file system.

File-systems need to evolve and provide capabilities to relate different data-sets. This will help the application writers to make use of native file-system capabilities to relate data. A good effort in this direction was Microsoft WinFS.

Conclusion

The only disadvantage with using the databases as primary storage option, seems to be the additional cost associated. But, I see no reason why file-systems in future will borrow features from databases.

Disclosure

Druvaa inSync uses a proprietary file-system to store and index the backed up data. The meta-data for the file-system is stored in an embedded PostgreSQL database. The database driven model was chosen to store additional identifiers withe each block – size, hash and time. This helps the filesystem to -

  1. Divide files into variable sized blocks
  2. Data deduplication – Store single copy of duplicate blocks
  3. Temporal File-system – Store time information with each block. This enables faster time-based restores.

Real Businesses Can’t Depend upon Just Tape Backup

The recent Journalspace data loss episode, is a good lesson for all of us. I don’t know what exactly went wrong, but it highlights the fact that real businesses today can’t depend upon only tape/disk based archival of business critical data.

IMO, a good data protection strategy should value following points -

  1. Clear understanding of RPO and RTO for data protection
  2. Local disk-based backup for faster recovery.
  3. Remote-Replication for disaster recovery
  4. Archival and e-discovery

In simple terms RPO (Recovery Point Objective) is – “up to what point in time the data can be recovered” and RTO (Recovery Time Objective) implies – “how much time would it take to recover data”. These goals differ from business to business. But, any real enterprise can’t depend on slow tapes for this, especially when it comes to critical customer data.

The two terms – “Backup” & “Archival” are often confused with each other. And as I see it going forward, more and more enterprises would use local disk based backup-recovery for lowering RPO & RTO. The Tape/VTL/Tape would only be used for archival of older and currently-not-being-used data for compliance or specific business reasons.

With remote IP-based replication almost becoming commodity now, it can easily be used to avoid any local disasters. But, it would be interesting to see it being integrated with local disk-based backup systems. This could reduce load on the production server and make recovery simple.

On the good side, I loved the CouchSurfing 2.0 Rised from the Ashes story covered by Luxman. The company lost the entire MySQL database almost two years back because of a faulty file-system. Founder & CEO Casey Fenton announced company’s death. Later, Fenton’s email was met with vocal opposition to the termination of the project and considerable support for its recreation.

“CouchSurfing 2.0″ was announced early in July 2006, with the intent to be operational within 10 days. The initial implementation of CouchSurfing 2.0 actually launched after only four days.

Understanding Data Deduplication

“Data deduplication is inarguably one of the most new important technologies in storage for the past decade” says Gartner. So let’s take a detailed look at what it actually means.

Definition

Data deduplication or Single Instancing essentially refers to the elimination of redundant data. In the deduplication process, duplicate data is deleted, leaving only one copy (single instance) of the data to be stored. However, indexing of all data is still retained should that data ever be required.

Example
A typical email system might contain 100 instances of the same 1 MB file attachment. If the email platform is backed up or archived, all 100 instances are saved, requiring 100 MB storage space. With data deduplication, only one instance of the attachment is actually stored; each subsequent instance is just referenced back to the one saved copy reducing storage and bandwidth demand to only 1 MB.

Technological Classification

The practical benefits of this technology depend upon various factors like –

  1. Point of Application – Source Vs Target
  2. Time of Application – Inline vs Post-Process
  3. Granularity – File vs Sub-File level
  4. Algorithm – Fixed size blocks Vs Variable length data segments

A simple relation between these factors can be explained using the diagram below -

Deduplication Technological Classification

Target Vs Source based Deduplication

Target based deduplication acts on the target data storage media. In this case the client is unmodified and not aware of any deduplication. The deduplication engine can embedded in the hardware array, which can be used as NAS/SAN device with deduplication capabilities. Alternatively it can also be offered as an independent software or hardware appliance which acts as intermediary between backup server and storage arrays. In both cases it improves only the storage utilization.

Target Vs Source Deduplication

On the contrary Source based deduplication acts on the data at the source before it’s moved. A deduplication aware backup agent is installed on the client which backs up only unique data. The result is improved bandwidth and storage utilization. But, this imposes additional computational load on the backup client.

Inline Vs Post-process Deduplication

In target based deduplication, the deduplication engine can either process data for duplicates in real time (i.e. as and when its send to target) or after its been stored in the target storage.

The former is called inline deduplication. The obvious advantages are -

  1. Increase in overall efficiency as data is only passed and processed once
  2. The processed data is instantaneously available for post storage processes like recovery and replication reducing the RPO and RTO window.

the disadvantages are -

  1. Decrease in write throughput
  2. Extent of deduplication is less – Only fixed-length block deduplication approach can be use

The inline deduplication only processed incoming raw blocks and does not have any knowledge of the files or file-structure. This forces it to use the fixed-length block approach (discussed in details later).

Inline Vs Post Process Deduplication

The post-process deduplication asynchronously acts on the stored data. And has an exact opposite effect on advantages and disadvantages of the inline deduplication listed above.

File vs Sub-file Level Deduplication

The duplicate removal algorithm can be applied on full file or sub-file levels. Full file level duplicates can be easily eliminated by calculating single checksum of the complete file data and comparing it against existing checksums of already backed up files. It’s simple and fast, but the extent of deduplication is very less, as it does not address the problem of duplicate content found inside different files or data-sets (e.g. emails).

The sub-file level deduplication technique breaks the file into smaller fixed or variable size blocks, and then uses standard hash based algorithm to find similar blocks.

Fixed-Length Blocks v/s Variable-Length Data Segments

Fixed-length block approach, as the name suggests, divides the files into fixed size length blocks and uses simple checksum (MD5/SHA etc.) based approach to find duplicates. Although it’s possible to look for repeated blocks, the approach provides very limited effectiveness. The reason is that the primary opportunity for data reduction is in finding duplicate blocks in two transmitted datasets that are made up mostly – but not completely – of the same data segments.

Data Sets and Block Allignment

For example, similar data blocks may be present at different offsets in two different datasets. In other words the block boundary of similar data may be different. This is very common when some bytes are inserted in a file, and when the changed file processes again and divides into fixed-length blocks, all blocks appear to have changed.

Therefore, two datasets with a small amount of difference are likely to have very few identical fixed length blocks.

Variable-Length Data Segment technology divides the data stream into variable length data segments using a methodology that can find the same block boundaries in different locations and contexts. This allows the boundaries to “float” within the data stream so that changes in one part of the dataset have little or no impact on the boundaries in other locations of the dataset.

ROI Benefits

Each organization has a capacity to generate data. The extent of savings depends upon – but not directly proportional to – the number of applications or end users generating data. Overall the deduplication savings depend upon following parameters –

  1. No. of applications or end users generating data
  2. Total data
  3. Daily change in data
  4. Type of data (emails/ documents/ media etc.)
  5. Backup policy (weekly-full – daily-incremental or daily-full)
  6. Retention period (90 days, 1 year etc.)
  7. Deduplication technology in place

The actual benefits of deduplication are realized once the same dataset is processed multiple times over a span of time for weekly/daily backups. This is especially true for variable length data segment technology which has a much better capability for dealing with arbitrary byte insertions.

Numbers

The dedupication ratio increases everytime to pass the same complete data-set through the deduplication engine.

If compared against daily full backups, which I think is not widely used today, the ratios are close to 1:300.  Most if the venders use this as a marketing jargon to attract customers, even though none of their customers could be doing daily full-backup :)

If compared against modern day incremental backups, our customer statistics show that, the results are between 1:4 to 1:50 for source based deduplication.