Problems with Storage Snapshot based DaaS

Storage Snapshot Cloning Architecture

Customer issues with Storage Snapshot based Cloning

Many customers have mentioned several common problems with their existing storage snapshot based cloning solutions.

To make clones from storage snapshots you must have a full copy of the source database.   It must be a copy because you don’t want to create storage clones on your production storage array and potentially compromise performance.  It must be a full copy because that’s how storage snapshots work.

The major problem here is that you need a mechanism to maintain this full master copy on a different storage array.  Using database vendor specific replication technologies will require you to establish and maintain a variety of solutions if you use more than one database vendor, so most customers use storage replication.  However storage replication does not guard against physical or logical corruption making its way to the replica copy, that might have been avoided using the database vendor replication methods.  In addition we are now locked into the storage vendor for replication, snapshots and clones.

The next issue is that the performance of storage snapshots tends to decline quite rapidly.   Some customers are forced to periodically instantiate new master full copies just to restore performance.   So now we have maintenance, availability and a storage overhead issue.

Finally most storage snapshot solutions do not have automated maintenance workflows to cover the three main requirements for DaaS which are synchronization, governance and provisioning.   For many customers this makes their storage snapshot based cloning solution non-scalable from an operational and performance point of view.

How is Delphix Different

Ø  Delphix is storage agnostic

Ø  Delphix does not require a full copy of the source database(s).

Ø  Delphix automatically synchronizes with source database and retains a compressed de-duplicated copy.

Ø  Delphix can validate the integrity of the Delphix maintained copy.

Ø  Delphix works the same for all supported databases.

Ø  Delphix reduces the workload on the underlying storage by minimizing storage IO.

Ø  Delphix automates the entire DaaS workflow end-to-end.

Ø  Delphix provides self-service interfaces for operational and end-user teams.

Delphix as a smart NFS Server

Delphix AppData over NFS

Delphix is best known for its ability to automatically virtualize entire databases but Delphix can also be used to virtualize filesystem files and folders.  This capability is called AppData which is designed to virtualize application software or any data held in files and folders.

There are two methods of using AppData to synchronise with files and folders.  You can either have Delphix synchronise by periodically scanning a set of folders to capture updates or you can manage the updates yourself by using an AppData mount point.

Delphix can provision virtual storage and present that to a server as an NFS mount point, what we call a virtual mount point, vMount.  You can then copy data into that mount point and because the copied data is managed by Delphix, the data is catalogued, compressed and de-duplicated between copied versions.   Now that Delphix has one or more copies you can provision shared copies of any version of this data to another server over NFS or as a physical copy.

A common use case for this approach is to handle databases that Delphix does not yet natively support.  At the time of writing we support Oracle, SQL Server, SAP ASE (Sybase), Postgres, MySQL and DB2.

For example, Sybase IQ is one of the most commonly used columnar databases used for analytics.   Like many analytics environments it is not usually possible to expand the read capacity because the databases are by nature very large and the cost and time would make provisioning more copies to expand read capacity too expensive.

Using Delphix AppData the process to ingest, govern and provision copies of Sybase IQ are:

1.     Provision storage for IQ backups using a Delphix mount point (vMount)

2.     Restore an existing backup into the vMount, optionally rename.  Initially restore a full backup but subsequently restore either a full, incremental or incremental since full backup.

3.     Bounce the Sybase IQ residing on the vMount to check validity of the restore

4.     Take a Delphix snapshot of the vMount and optionally create a bookmark

5.     Provision a virtual copy of a chosen backup version over NFS to a separate target server

6.     Startup Sybase IQ on the target server running against IQ database files provisioned by Delphix

This method will allow you to save a set of discrete, compressed and de-duplicated versions of your IQ database in Delphix via an NFS mount.

Being a columnar database Sybase IQ gets great compression on its raw data which means the IQ database files are highly compressed.  Delphix will still get some compression on those backup copies, however the main benefits of using Delphix in this way are:

1.     Each subsequent restore is de-duplicated and hence only deltas are held for each backup version.

2.     Full read-write copies of the entire IQ database can be provisioned in minutes, expanding the read/analytics capacity.

3.     All the database maintenance activity on the source IQ database carries on independently of all the virtual copies.

4.     As and when new versions of the source IQ database are copied to Delphix users can refresh their own copies to the latest version or stick with the one they have if preferred.

5.     If desired, Delphix can provision other databases alongside Sybase IQ

Summary

Delphix can act as a very smart NFS server allowing access to private copies of almost any data of any size, near instantly with minimal storage or operational overhead.

Agile Copy Data Management

Delphix Agile Copy Data Management

Copy Data Management

Whilst there has been a gradual evolution in agile infrastructure (IaaS) and software stack provisioning architectures (PaaS), Delphix provides the missing piece in the agile architecture jigsaw by addressing Data as a Service (DaaS) through agile Copy Data Management.

Copy Data Management is generally defined as a solution which takes care of the curation, provisioning and security of all non-production database copies for Development, Analytics, Operations and Data Protection.

Networked Storage

Storage was the first component targeted by outsourcers to consolidate.  Moving from siloed, dedicated, Direct Attached Storage (DAS) to networked storage allowed overall storage consumption to be reduced by consolidating unused capacity and also allowed storage to be managed centrally.  However one of the downsides was that networked storage, typically Storage Area Networks (SANs), required a dedicated fibre channel data network to ensure performance for the high volumes of data traffic moving between database servers and the networked storage arrays.

In today’s world of agile infrastructure where resources are pooled, and allocated using virtualization technologies, having a dedicated network is an anachronism.   A dedicated resource means that unused capacity cannot be used by other workloads and the dedicated resource itself cannot expand or burst out to use capacity from elsewhere.

A move from siloed networks requires high bandwidth networks where capacity can be appropriately partitioned and allocated to accommodate multiple workloads. The throughput and capacity of Ethernet networks are evolving extremely fast allowing a single team of network administrators to manage all network traffic.  High throughput Ethernet allows the network itself to be a pooled resource with all the flexibility, agility and cost advantages that brings.

Storage Snapshots

Storage Snapshots have been around for many years and were originally designed to enable consistent backups of active database systems.  A backup takes a long time and most database systems cannot be suspended for the entire duration of a backup.  Storage snapshots allow a database to be queisced for a brief duration whilst the snapshot is taken.  The database can then be un-queisced allowing transactions to proceed and a consistent backup of the database can then be taken asynchronously via the snapshot.

Clones of snapshots can be taken to provision database copies. However supporting clones has an impact on storage performance and hence clones are usually driven off a full copy of production maintained on a separate storage server.  This mitigates the performance impact of clones on the production storage array at the cost of maintaining a replication method and additional storage.

Unfortunately the performance of cloned storage snapshots also degrades quite rapidly over time with IOPS dropping by up to 50% and latency spikes of 20ms.

Like most technologies storage snapshots are great when used for what they were originally designed for but start to disintegrate for non-primary use cases.

Virtual Data

Virtualising a shared resource is a pre-requisite for IT agility, which is why Delphix virtualizes data.  Delphix virtual data allows many users to share the same copy of data with the appearance of having their very own private, dedicated, full sized, read-write copy.  Delphix compression and de-duplication allow Delphix to store a sequential timeline of multiple database versions spanning long retention periods.  Delphix compression also increases performance by reducing physical IO requests and expands the effective size of the Delphix data cache which further reduces the number of physical IO requests.  These are two of the primary reasons why Delphix virtual data is often faster than purely physical storage based solutions.

Designed for Agility

Delphix itself is deployed as a Virtual Machine to leverage the easier deployment, management, scalability and HA of a hypervisor environment.  Almost every customer has skills in managing Virtual Machine environments.

Delphix is storage agnostic and leverages the flexibility and high performance of Ethernet to provision access to shared database versions over the network using NFS and iSCSI. 

The final key ingredient for agility is automation.  Any manual process involved in common workflows becomes a constraint and renders a solution unpredictable and non-scalable.  Delphix automates the entire data capture, curation, provisioning and versioning processes.

Access to Delphix database version control is available out-of-the box through self-service automation providing GIT like capabilities for databases of any size.

We call this Agile Copy Data Management.

The Business Case for Delphix Data Masking

 

Delphix Masking

Data Masking is necessary to secure non-production copies of production data.  Since data masking is irreversible a masked database copy can be safely used by users who require access to production like database copies without compromising personal or company confidential information.

However data masking is a non-trivial task, you need to modify or generate a full sized copy of a database replacing all sensitive data with plausible replacement values.  This takes a lot of processing effort as every row in every table containing sensitive data needs to be updated or replaced.

Many customers see data masking as an expensive process which reduces agility and consequently increases project costs with little project benefit.  Of course there are an increasing number of data protection regulations due to be enforced with greater vigour.  These regulations do not change the economics but just make it more pressing to implement a data masking solution and somehow absorb the cost, they are definitely a stick and not a carrot.

Many Delphix customers are finding a way to solve the masking problem both technically and commercially.   The commercial value of Delphix data masking is to help reduce costs by enabling customers to use cloud resources for non-production activities.  Whilst it may be acceptable to run with non-masked data on premise, most of us agree that data masking is essential when operating in the cloud.

Delphix Replication makes it easy to mask data on-premise and then replicate only masked data copies to a Delphix Engine sitting, in another Data Centre, on Amazon or, in future, Azure.   Delphix Replication is surprising easy to configure and use, you basically install a second Delphix Engine to replicate to, provide the details of the replica engine to the primary engine, and then specify which masked data copies to replicate.

Of course you still have to mask the data first. Delphix customers create a virtual database (VDB) and prepare that VDB for non-production use, e.g. removing production usernames and passwords, and then obfuscate the sensitive data by running one more masking jobs against the VDB.  Running masking jobs in parallel can reduce the end-to-end masking time substantially.  Use of a VDB eliminates the need for a full database copy as the VDB will only consume storage for the data blocks modified as part of the masking process, this is typically less than 20% of the source database size.

The masked VDB can then be replicated and all non-production VDB copies use this masked master.

Delphix Masking is designed to make the process of data masking easier and faster than most masking tools. Delphix Masking helps identify potentially sensitive columns, does not require a data model to ensure referential integrity and uses the same algorithm to mask a given column, attribute or field across all data sources.

The most commonly used Delphix Masking algorithm is called Secure Lookup which is a method to replace existing values with values from a generated list of realistic but artificial values.  For example if I have a database with UK National Insurance Numbers (NINOs), I can use a script which can generate artificial NINOs according to the algorithm published at NIM39110 - National Insurance Numbers (NINOs): Format and Security.  I would then create a Secure Lookup algorithm and attribute and load this set of generated values to my Secure Lookup algorithm.  My new algorithm will replace the original values with values chosen from this list.   Since NINOs are unique I would generate a list with at least the same number of unique NINOs in the source table.   The Secure Lookup algorithm is deterministic, meaning the same input value will map to the same replacement value chosen from the generated list.  Hence if the NINO appears in more than one table but I use this algorithm against both then referential integrity is preserved.

Finally, for customers who use database encryption on their production databases, if you want to encrypt copies on non-production you would typically need to decrypt and re-encrypt using new keys to segregate from production.  Aside from this complexity, encryption licenses for non-production are expensive and unnecessary when data is masked.

Using the speed and cost savings of Delphix Provisioning, Replication, Masking and optionally cloud hosting, allows Delphix customers to solve the problem of provisioning full sized, secure copies of production efficiently and cost effectively.