Real-time data security

The Hana in-memory database stores data in the working memory and therefore speeds up analyses of business performance and trend calculations enormously compared to traditional relational databases.

It serves as the basis for solutions such as the SAP Business Suite or the new SAP Simple Finance and is suitable for the parallel operation of OLAP (Online Analytical Processing) and OLTP (Online Transaction Processing).

However, Hana places high demands on the IT organization. Gartner warned at the end of 2014 that IT teams will have to acquire completely new skills to manage the platform.

In addition to pure operation, storage, backup, migration and capacity planning raise questions: Which components do I need today and what will my requirements be in two years' time?

Many IT organizations have no experience in this area, as Hana is still a relatively new solution. Initially, SAP only offered the platform introduced in 2010, as the name Hana ("High-Performance Analytic Appliance") suggests, as a complete system.

However, users soon expressed a need to continue using existing storage solutions. SAP therefore added the TDI approach to the appliances in 2013: thanks to TDI, user companies can combine compute blocks with storage equipment as required - provided these blocks are certified for TDI by SAP.

In addition to the continued use of existing storage equipment, TDI offers a number of additional advantages over complete systems, such as flexibility in the choice of components, e.g. as part of a dual-vendor strategy.

As Hana is not a "black box" here, integration into a company-wide standardized monitoring of ITSM metrics is made easier. Joint storage of Hana and non-Hana data on the same storage system is made possible by setting up virtual arrays, while the appliance is limited purely to Hana.

It is also possible to use flash memory ("all-flash storage") throughout - an option that is not provided for in the appliances.

All-Flash for Hana

With traditional hard disk-based storage systems, you have to use a large number of spindles to achieve a high I/O rate. Flash memory is many times faster here - and less susceptible to faults thanks to the absence of mechanical components and rotating media.

In the Hana context, however, data accesses take place in RAM. Mass storage is about I/O performance at the persistence level.

In this context, HP's ASIC-based all-flash architecture offers a number of advantages: The HP-3PAR family scales linearly to up to 15 petabytes of data volume, depending on the SAP Hana volumes.

Such an all-flash system requires 6 times less power, cooling and rack space than a comparable disk-based storage system (see box "Savings potential with flash").

The achievable cost reductions can quickly amount to six-figure sums; the lower energy transition levy alone can save a medium-sized company hundreds of thousands of euros.

Beforehand, however, it is necessary to thoroughly inform yourself about the storage and backup requirements of a Hana TDI system. For companies that use Hana, the platform is generally business-critical, so they cannot afford any downtime.

When it comes to storage, this means paying particular attention to the controller. To guarantee reliability, HP recommends using a four-controller architecture instead of the usual dual-controller solutions. This means that one controller can fail without any loss of data or performance.

In the array architecture that HP uses for 3PAR, which is the only four-controller system on the market in the mid-range segment, all controllers are active and can access all data simultaneously. A clustered file system is implemented natively for this purpose.

This ensures the extremely high redundancy required in the tier 1 storage sector. However, flash technology is now also attractive for the mid-range environment: HP's data compression technologies for flash technology get 20 percent more net capacity out of the SSDs (solid-state disks), so that in terms of cost per GB of net data, the SSDs are on a par with spinning disks in terms of price.

For the required high availability in virtual environments, failover and failback between storage systems must take place automatically and without interruption. Storage hardware expansions and upgrades must be possible during operation, as must firmware updates.

If a storage system has to be shut down for a firmware update, you can no longer really speak of "high availability": breaks then inevitably affect day-to-day business again and again.

It is advantageous for IT operations if the storage equipment has a uniform architecture, operating system and software functions - regardless of whether it is a small, mid-range or high-end system and whether it only uses flash or is a hybrid system that uses flash alongside hard disk storage.

Management should be possible across all of a manufacturer's systems with a standardized interface. Different management interfaces often prove to be a hindrance - and therefore a source of errors that can jeopardize high availability.

Although flash memory offers higher access speeds with significantly lower energy consumption and cooling requirements, SSDs are subject to a faster ageing process than spinning disks.

A monitoring tool should therefore monitor SSD ageing and automatically inform the administrator when an SSD module needs to be replaced. HP also grants a five-year warranty on SSDs, regardless of whether they fail due to a defect or ageing.

Critical backup

Highly available storage requires a solid backup concept. This applies undiminished to Hana, and the in-memory operation of the database does not change this. On the contrary: external storage plays an important role as a backup and archiving medium for a business-critical database.

A look at the levels in SAP's Hana architecture makes this clear: The database runs on the in-memory level, while the so-called persistence level logs all transactions.

However, you should never rely solely on the persistence level for backups: If a logical error occurs at the in-memory level - for example due to incorrect operation, maintenance breakdowns, power failure, etc. - then this is copied to the persistence level.

It therefore does not protect against corrupted data. For this reason, the two levels must always be supplemented by a backup and an archiving level. Only a separate backup level ensures reliable data backup via API access to Hana.

The system administrator can perform snapshots on the array that reflect the state of the array at time x; however, there is no consistency check here due to the conditions of the SAP API.

The administrator should therefore carry out a backup at least once a week using Backint (Backup Integration). This includes consistency checks on the medium and thus rules out data corruption.

Finally, the data is stored on the archiving level for long-term storage in order to meet compliance requirements. The same applies to backups: uniformity across all systems facilitates operation.

A backup solution for Hana should also use the standard SAP APIs in order to minimize the adaptation effort and maintain release capability. QoS (Quality of Service) management should ensure that backups of an application do not impair the performance of Hana processes, e.g. in mixed operation of Hana with third-party applications.

Data deduplication should be possible, but it should also be possible to switch it off. This is because deduplication does not necessarily make sense with Hana, but is definitely an advantage in mixed operation with third-party applications.

Data mobility should be unrestricted - even across different locations. It is also useful if the backup solution can back up the Hana data without separate backup agent software. This avoids license costs.

The overall concept

The complexity of a Hana migration is quickly underestimated. The project is often viewed in isolation, focusing only on the business benefits, without an overall IT concept.

Then important questions fall by the wayside, such as which data sets should not be loaded into Hana in the first place in order to avoid unnecessarily inflating the data volume in the working memory.

An overall view is therefore required, from database operation, backup/recovery and archiving through to information security, data protection and compliance.

Last but not least, the dependencies between Hana and connected solutions need to be specified: A common problem in Hana operation is ensuring the consistency of all databases - including data from solutions connected via API.

Even long-standing SAP customers often have no experience with this. This is where expertise is required, such as that which HP can provide as an SAP Hana partner from the very beginning with decades of experience in the operation of business-critical IT infrastructures.

The switch to Hana promises many business benefits, but first you have to address the operational, storage and backup challenges. After all, today's real-time business requires highly available databases.

Savings potential through Flash

With the new 3.84 TByte SSDs for the HP 3PAR, HP has succeeded in reducing the cost of SSD-based storage to less than two US dollars per GByte of net data.

This puts these SSDs on a par with commercially available 10k SAS hard disks in terms of price - and with a five-year warranty on the flash memory. Not only against technical defects, but also against wear and tear.

HP's all-flash arrays therefore enable significant cost reductions compared to traditional hybrid storage arrays. For example, if a company has 12 PByte of usable capacity, it would need 21 racks with 90 percent HDD and 10 percent SSD-based storage with conventional storage architecture.

In contrast, there is an HP 3PAR StoreServ 208×0 with 100 percent SSDs, which only occupies three racks and is certified for Hana TDI. This requires 87 percent less energy, cooling and floor space. The comparison with conventional dual-controller all-flash arrays from other manufacturers is just as favorable.

Another example can illustrate the total cost calculation when using all-flash storage in SMEs: The storage requirements of a medium-sized example company are 45 TiB and 15,000 IOPS.

An HP StoreServ 7200c hybrid system with 51.7 TiB RAID 5 (136x 600 GB) generates electricity costs of 36,345 euros over five years. The system takes up 16 height units (HE) in the rack and achieves 16,403 IOPS at 10 ms latency.

An all-flash HP StoreServ 7200c with 44.3 TiB (deduplication 2:1) and 10x 3.84TB RAID 5, on the other hand, is content with 6,307 euros in electricity costs, thus consuming 83 percent less energy.

It occupies just 2U in the rack and delivers around 240% more performance with 48,123 IOPS - and with a latency of just 1.5 ms. The all-flash system is therefore significantly more powerful, but does not incur any additional costs over five years compared to a hybrid system.