We’ve Expanded Our Copy Data Support to SAP HANA

Our new Catalogic ECX release 2.6 expanded the application support matrix considerably by adding SQL physical hosts, Epic EHR with InterSystems Cache environments, physical server basic file systems (Windows, Linux, AIX) and VMware pRDMs. On top of all these enhancements, we were also tremendously excited to add support for SAP HANA environments.

SAP HANA is an in-memory, column-oriented, relational database management system developed and marketed by SAP. Many of the legacy SAP systems were supported by Oracle and DB2, both of which are also supported by Catalogic for orchestrating DB aware IBM and Pure Storage snapshots. Customers are slowly and steadily migrating to the HANA platform because of the performance improvements afforded by running the database from memory. Storage, however, is the core component of this infrastructure in delivering persistency to data and to support queries that may not have all the necessary data in memory. Combining SAP HANA with Flash storage has allowed customers to achieve several benefits:

  • Substantial increase in performance (of course!)
  • Even higher storage efficiency compared to just HANA’s deduplication
  • Offload at-rest encryption to the storage arrays to avoid HANA’s native encryption.
  • Offload replication to storage instead of log shipping at the HANA level
  • Reduced footprint with lower OpEx cost of Flash compared to spinning disk environments

With the introduction of SAP HANA TDI (Tailored Data Center Integration), customers now have the choice of storage and servers and OS instead of the prepackaged one-size fits all appliance approach. Both our partners, IBM Storage and Pure Storage, have certified storage platforms delivering world-class capabilities to SAP HANA environments. With Catalogic 2.6 and its corresponding OEM versions, we can now deliver application-aware snapshots and recoveries on top of performance and reliability. In a nutshell, our compatibility can be summarized as:

  • Storage: Pure FlashArray (FA, \\M and \\X series), IBM Spectrum Virtualize (SVC and Storwize) and IBM Spectrum Accelerate (XIV) family
  • Servers: Physical and virtual – Intel and Power platforms
  • Operating System: RHEL, SLES and PowerLinux

Here are some key benefits for SAP HANA users:

  • Storage array snapshots complete in seconds what it takes the legacy “Backint” interface to create a backup copy
  • Negligible impact on HANA servers during backup. Queries can run faster even during backups.
  • Completely Agentless. No agents for physical or virtual servers running Power or Intel.
  • Orchestrate app-consistent replication of snapshots for DR by leveraging the underlying storage replication engine.
  • Instant Recovery in case of data loss by utilizing zero-footprint clones from either the primary or replica copy.
  • Flexibility to use Fiber Channel or iSCSI to mount disks during recovery.
  • One-touch recovery back to the original destination by automating the mountpoint handling.
  • Centralized single pane of glass management for Oracle, SQL Server, DB2 and HANA under one umbrella.
  • Monitor RPO compliance through snapshot registration in SAP HANA Backup Catalog as well as Catalogic reports.

As always, let’s wrap up with some screenshots and a link to our demo video. Stay tuned for more storage platform support and additional enhancements covering multi-tenant databases and new features in SAP HANA 2.0 SPS 1.

 

The first step is to register your SAP HANA servers. The process is simple and agentless. You select the application type, in this case SAP HANA, and provide credentials. That’s it!

 

Snapshot policies get defined based on SLAs, such as how many snapshots do you want to maintain. One or more policies can then be applied to any workload.

 

The above screen shows a selected SAP HANA instance, on the left, and the applied policies on the right. It’s as easy and point-and-click to apply protection polices to SAP HANA workloads.

 

When it comes to recovery, restore jobs are created up front. Assorted options are chosen, pre- and post-script actions can be applied. Once the recovery job is created, it’s as easy as point-and-click to restore data. The same functionality can be used to deploy data sets for dev-test, reporting, etc.  And since everything in ECX is RESTful API enabled, you can also drive recovery and data delivery via code. Self-service options are available as well. We’re all about delivering data when and where it’s needed.

Read More
05/17/2017 0 Comments

Our New Epic Support is Epic!

Healthcare datasets are growing at a rapid pace, especially with the adoption of electronic medical/health records (aka EMR/EHRs). Epic has been the fastest growing market leader in the EMR market and it is estimated that more than half the U.S. population has an Epic record. And that Epic record is kept on a database called Caché developed by InterSystems, supplemented by other reporting databases based on SQL or Oracle, plus presentation servers.

Catalogic ECX, with its latest version 2.6, has added support for Caché database instances with native integration on top of the support it already offered for SQL Server and Oracle. Unlike several established vendors such as EMC, NetApp and Commvault, we have integrated specifically with the Caché APIs, subsequently avoiding the need for pre-scripts/post-scripts for snapshotting as well as for recovery mounts. Coupling this with the “in-place” copy data management benefits of Catalogic across multiple storage platforms, this is now truly an industry leading feature set for protecting and recovering Epic and Caché environments.

We think our new Epic support is epic! The key benefits of the Catalogic approach are:

  • Automatic Discovery of Caché Instances
    Picking up new databases and dropping ones that are no longer available.
  • Automatic Discovery of Caché DB paths, journal files, etc.
    The user isn’t burdened with knowing where these reside, or updating the backup jobs for every change.
  • Automated Freeze and Thaw through API integration
    Without the need for pre- and post-snapshot scripts.
  • Support for AIX/Linux and pRDMs
    AIX/Power Systems has a large market share in Epic environments today and Linux and pRDMs are quickly emerging as a standard. Catalogic supports all these configurations.
  • Low Impact Storage Snapshots
    Epic imposes exacting standards on maintaining minimum I/O performance. Because ECX uses storage array snapshots, the impact on Caché is near zero and the servers don’t need to participate in any data movement for protection or recovery.
  • Instant Database Recoveries
    Instant recoveries back to original or alternate servers without the need to configure and write pre- and post-mount scripts.
  • Automate Test/Dev Environments
    Create a test/dev Caché Instance from a bare Linux image within minutes.
  • Automate GUID Handling
    Bring up Caché instances and update GUID automatically so that these databases don’t take on a production profile.
  • Integrate with DevOps Tools
    Catalogic offers native plug-ins with popular tools such as Puppet, Jenkins, etc.
  • Full Stack Support
    Includes full stack automation outside of Caché DBs as well, including SQL, Oracle, File Systems, VMware VMs, etc.

Catalogic is thrilled to partner with @IBMStorage and @PureStorage, whose snapshot and replication technology we integrate with today for these Epic & Caché environments. We are also thankful to the @InterSystems engineering team who were instrumental in offering us a great deal of guidance and feedback as well as their assistance in evaluating whether we were using the right API calls in the right order during the development cycle.

Stay tuned for more enhancements planned for this space as well as support for more storage platforms. Also, please find below some screenshots of the product – a picture is worth a thousand words; it’s worth a whole lot more when English isn’t my first or second language! You can also check out this wonderful demo video created by my Catalogic counterpart @p_jagannathan. Or get more specifics in our Epic solution sheet.

 

In the above screen, the first step is to select the application server type you wish to register.

 

On the registration screen, you provide necessary information and credentials. Credentials can be new or you can use existing credentials. Authentication can be by password or key.

 

This shows the Jobs tab where inventory, backup and recovery tasks can be started and monitored.

 

This screen shows how simple it is to add a policy to an instance. On the left side, discovered Caché instances are displayed. Check the instances you wish to protect, and then on the right-side click the policy you wish to apply. A policy contains details such as how frequently to protect the database (once an hour, once a day, etc.) as well as how long to retain the snapshot. A policy may also contain replication information (array to array copy).

 

This screen shows a portion of the job log created when a policy is run. You can see on the right side that ECX is “freezing the instance” of the database in order to create an application consistent copy.

 

Creating a recovery job is as simple as creating a backup job. You simply pick the database you wish to recover, you pick the copy you wish to use (“most recent” is the default) and you determine where you want the snapshot to be mounted.

Read More
05/11/2017 0 Comments

Are All Storage Snapshots Equal? Seven Things To Consider

Every primary storage vendor offers the ability to snapshot, replicate and/or vault datasets. But when it comes to end users, snapshots are like gym memberships: everyone’s got them, but very few use them. At Catalogic, our software is uniquely designed and developed to take advantage of these native capabilities of your storage arrays, but we are aware that (like body types and skill levels) not all snapshots are the same. The technology needs good genes, just as much as good form and the ability to perform and persevere.

When choosing primary storage with snapshots in mind, we recommend to our customers that you build your own scorecard of what’s important to you and how the various storage arrays compete on each of these variables. Once you make that decision and procure a platform, we hope it’s one of many that Catalogic enables to maximize your storage investments by leveraging these snapshots.

To help you with your decision process, here are some key parameters to consider for your storage snapshot scorecard. The importance of these variables may vary for your specific data types. However, it would be good to remember that the alternative to using storage snapshots and native array replication is the need for:

  1. A dedicated hardware appliance.
  2. A new hardware stack with different management needs, differing performance characteristics and most likely a system never tuned to run your production at scale.
  3. An infrastructure model where the secondary doesn’t scale with your primary – exacerbated when you use a software-only appliance model.
  4. Higher impact on your servers and applications for your backups, because the host systems will be involved in data movement.
  5. A process that will have to rehydrate, decrypt, re-encrypt and re-compress datasets as part of data movement. That’s a whole lot of effort spent for a net zero effect.
  6. Almost always higher cost compared to maximizing investments already made.
  7. More importantly, a new vendor lock-in introduced and designed to milk the customer forever.

Choose this approach at your own peril. Let’s get back to Storage Snapshot Scorecard. Here’s what our experience shows us is important:

1. Performance Impact

There are essentially two major types of snapshots: copy-on-write and redirect-on-write snapshots. Differences between them and a few other variations are well documented in this article. The key to selecting the right type of snaps includes:

  • Low read performance impact
  • Low write performance impact
  • Mitigation options for performance impact, if any
  • Minimal snapshot consolidation overhead
  • Consistent performance of the array when close to full capacity
2. Scale Factors and Max Limits

Every snapshot technology has its boundaries. If a vendor says there is no technical limit, always ask what the trade-off is. Typical limits to factor into your selection would include:

  • Maximum number of volumes
  • Maximum number of clones
  • Maximum number of snapshots
  • Maximum number of consistency groups
  • Maximum number of concurrent mounts
  • Minimum space reserve
3. Space Efficiency Impact

The impact of snapshots on deduplication is not well documented by vendors. Some have truly global deduplication and compression. Some limit it to volumes, and some limit it to snapshots within volumes. This certainly impacts deduplication and compression efficiency. If your changes are pretty much the exact same every day, the snapshot should dedupe itself to just one copy with the right technology. The keys to measure are:

  • Space savings on Day 0
  • Space savings after N snapshots with representative amount of changed data. A suggested value for N is 30.
  • Space savings when multiple versions are in use from the same underlying snapshot.
4. Chaining and Concatenation
In test-dev processes as well as in continuous integration, continuous deployment (CICD) DevOps processes, there is a tremendous emphasis on path dependencies. How you got to a certain point may have an impact on how the application behaves at that point to the same input data. This is often tested by branching, versioning, and rewinding your test data sets. The snapshot technology needs to allow chaining and concatenating these snapshots to allow this to happen. Factors to check are:
  • Can I snapshot a snapshot clone? Some vendors call this a 2nd gen snapshot.
  • How many generations of snapshots can be created?
  • What is the performance impact with each generation?
  • What is the Impact of deleting parent snapshots on the child versions?
5. Replication Carryovers

Replication of snapshots is key to having an off-box copy of your critical data.  The key factors to consider are:

  • One-to-Many and Many-to-One capabilities
  • Does the replication target volume support snapshots?
  • RPOs possible within the framework.
  • Ability to replicate to low performance, lower cost storage.
  • Ability to retain compression/dedupe/encryption etc. during replication.
  • Does replication support different retention compared to primary storage?
  • Does the replication target behave the same way as the primary array for restores?
6. Software Costs

Nothing is free, but everything is acceptable as long as it is not hidden and the pricing is transparent. Sometimes the point of sale discounting to add-on discounting can significantly vary, so it’s best to understand the costs involved from all fronts. Things to consider the costs of:

  • Snapshot licenses
  • Mirror licenses
  • Unlimited clone licenses
  • Management software licenses
7. Miscellaneous

There are always items that don’t fall into a category, but for some organizations, these may need to be separate categories as well. A few to think about are:

  • At-rest encryption on snapshots and whether replication retains encryption during data transfer.
  • Can you restore from snapshots, revert a snapshot and mount snapshots as read/write copies?
  • Availability of a robust set of [REST] APIs for automation.
  • Ability to manage snapshots across multiple arrays/storage vendors on-premises and in-cloud (wink, wink… there is always a plug somewhere).

Read More
05/05/2017 0 Comments

Let us show you around


Data ProtectionData ManagementOpen VM BackupNetApp Ransomware ShieldNetApp File Catalog