Delphix architecture

The Delphix HANA plugin is based on a staging architecture, i.e. the linking process and SnapSync requires a staging environment. The staging environment is a HANA DB server host that leverages storage allocated directly on the Delphix Engine using NFS, and it must contain an instance of SAP HANA that is higher or matches the same version of the Source. To create a dSource on a staging server, a full backup would be required. The Recover command deposits its backup data onto the mounted storage area. The Delphix Engine snapshots the Staging server and the snapshots can be provisioned out to one or more target servers.

To create a dSource on a staging server, a full backup of one particular tenant database is required. With this solution, virtualization will be done at the tenant level only. This topic describes the high-level architecture of the Delphix HANA plugin solution.

This solution invokes HANA recovery of database backup files when a user selects to create a dSource on the staging server. The necessary backups/logs are created outside of Delphix and must exist before dSource creation.

Virtual databases can only be provisioned from a dSource (inheriting the state of the dSource).

The following is the high-level Delphix architecture with SAP HANA.

There are two mechanisms to create dSource on the staging server.

Pull architecture, where the HANA plugin pulls the data into the Delphix provided mount location.
Staging Push architecture, where the user pushes the data into the Delphix engine.

HANA plugin with pull architecture

In Delphix HANA with Pull architecture, dSource is created using External backups which must be a HANA Native backup (ie: no support for third-party Backint tools). With External backups, the first dSource snapshot must include a Full backup, but can optionally include one or more incremental or differential backups. Subsequent dSource snapshots can be based upon additional incremental or differential backups (This will require a full backup along with incremental/differential backups, as recovery in Hana always requires a full backup).
HANA plugin supports an External backup, also known as Native Backups. Native backup implies that the backups are written in native storage format to local storage without a third-party backup tool.

The dSource creation operation invokes the HANA database recovery of the relevant HANA backup files. HANA database recovery can be a lengthy process. The duration of recovery time is subject to the size of the database being recovered. After completion of HANA recovery, the HANA instance will contain the newly recovered dSource tenant.

VDB provision operations from a dSource snapshot do not require HANA database recovery and can occur very quickly.

Failure to follow this recommendation diminishes the key value proposition for HANA, which is agility. Below are the recommended tiers:

dSource: A virtual HANA database constructed by recovery.
Virtual Database (VDB): A copy of a specific dSource snapshot, cloned using Delphix technology. These copies are fast to create with a small initial storage footprint. VDBs are the recommended workbench for developers. Multiple VDBs can exist from a single dSource. Each VDB corresponds to a dSource snapshot.

SAP HANA plugin with staging push architecture

Starting Delphix Engine version 6.0.12.0 and HANA plugin version 6.2.0, a new data ingestion mechanism has been introduced that will help users to push data into the Delphix provided mount point on their own.

The previous versions of the HANA plugin were based only on the Pull approach and it was difficult to support the different ingestion mechanisms as it required a lot of effort to analyze, code, and develop the solution. With the Staging Push mechanism, data ingestion can be achieved with minimum effort.

Few points to be noted about the Staging Push mechanism.

dSource creation creates an empty mount point on the staging host
User managed backup and restore

Operational best practice

Construct a dSource using the backup files. Construct multiple VDBs descended from the dSource.
Create a meaningful object name.
Create Dataset Groups that help delineate to which tier an object belongs.

Segregate user targets (where VDBs reside) from the staging where HANA recovery must take place to create the dSource.
Provision end-user VDBs, so that they can be created, refreshed, and rewound quickly.
Layer VDBs to perform any common post-recovery operations to further streamline provisioning steps.
Closely monitor and manage the quantity and lifespan of dSource and VDB snapshots, since each can consume additional Delphix storage.

Benefits of HANA plugin

Virtualization of individual tenant databases instead of the entire system.
Ability to mix and match virtualized tenants across any HANA system.
Reduced Storage footprint. VDBs can use significantly less storage when initially provisioned from dSource.
Relaxes strict requirement of exact HANA version match between source and target, leveraging HANAs ability to recover an earlier version against a more recent version.
Source backup files can be ingested from a surrogate host without impact to the true production source host.

Limitations of HANA plugin

The tenant's name should contain at least one alphanumeric character or one underscore. Also, it should not start with a digit.
A single quote, double quote, and space characters are not allowed in the password.
Datasets created using the Lua version cannot be upgraded to the vSDK version.
Manual cleanup/unmounting would be required after force delete operation on any dataset.