Build robust Hana environments

In addition to the appliance (black box) implementation approach and customer-specific TDI (Tailored Datacenter Integration), there are various forms of availability design for a Hana landscape.

These in turn are directly influenced by the architecture itself. A basic distinction is made between asynchronous or storage-based high availability (HA) and the synchronous HA mechanisms that Hana DB provides as standard.

In addition to the "asynchronous" mode, there are three different interpretations within the synchronous HA: Sync, Sync-MEM and Full Sync. While the standard sync mode can be compared to a fire-and-forget method for the shadow instance, the other two mechanisms wait for the mirror side to write the database commands either in memory, in full mode or even to the storage.

The resulting increased security levels of synchronicity come at the price of an equally increased dependency and higher performance requirements on the mirror site. In the worst case scenario with full sync, a mirror site can slow down or completely paralyze the production site.

Depending on the desired HA level, the mirror site must be set up with the appropriate performance for the production site. There is also the option of failover in scale-out environments to prevent server failure.

In addition, there are currently two cluster variants at operating system level to supplement the sync methods of Hana itself. Manual (manual or script-based) or fully automated with a cluster framework (Red Hat Enterprise Linux High Availability Add-on or Suse extension).

As a result, the question already arises in the architecture and design phase: Who carries out the takeover (planned or unplanned)? Is it the DB admin at Hana level or the Linux admin in the Cluster Resource Manager (Pacemaker)? The SAP Basis admin is also required at the latest for setting the DBSL suspend feature.

Overall, it can be said that most SAP customers today clearly prefer a TDI environment to an appliance, on the one hand to continue using existing investments and on the other hand to adapt the overall architecture robustly and according to their requirements.

In terms of HA architecture, the views are as different as the requirements. In most cases, failover scenarios are supplemented with the standard sync mechanism in order to take precautions at HW and SW level.

Hana lifecycle and consequences

Due to the rapid development of Hana technology, SAP's maintenance cycle for a PLC effectively only provides for nine months of support. Considering that DSPs (Data Center Service Points) should only be used in production environments (they are released approximately every six months), the maintenance windows are very tight.

Especially if you deduct a test phase of one to two months. If you also want to install and operate Hana independently, you need at least two Hana certifications.

What is new, however, is that these certifications are only valid for three PLCs, i.e. approx. 3 x 6 months. It is currently still unclear (queries are being made directly to SAP) as to when the certification is valid, i.e. at the time of certification or at the time of release.

Irrespective of this, employees currently need to be recertified for Hana every 1.5 years at the latest. This has never been the case for all other SAP-approved DBs (AnyDB). The question arises as to whether this is a necessary requirement or just an additional source of income for SAP.

Who is responsible?

As previously mentioned, the Hana customer-specific TDI architectures raise questions of responsibility with regard to operation, monitoring and maintenance. Which department is responsible for what in the Hana TDI? Insourcing, outsourcing/cloud or managed services?

For many customers, this is redefined by the introduction of Hana. In this case, it is advisable to create a RACI matrix via a Hana SLA to determine which tasks are implemented and for which the Linux, HDB or SAP Basis admin is responsible.

This can also be used to determine sourcing and training requirements with little effort. It should also be mentioned that a sensible alerting system integrated into Hana is currently only available via the Solution Manager.

Another important point is Hana Housekeeping. The backup catalog contains all important data and log backups and is backed up with every backup. This should be cleaned up cyclically, as there is no automated function for this in Hana.

Conclusion

From a technological perspective, it can be said that Hana is still on a steep and dynamic development curve. It is advisable to set yourself up for the long term, both architecturally and organizationally, in order to benefit from the innovations and to establish Hana technology as a core competence within your own company.

This also includes the far-sighted checking and scanning of the existing ERP components in the direction of S/4 Hana using the report R_S4_PRE_TRANSITION_CHECKS (note 2182725), which should check existing SAP systems in the direction of S/4 Hana readiness for approximately one year.

Hana & Non-ERP

"It should be comparatively difficult for this"

says Matthias Kneissl.

"Of course, with the Hana stack, SAP also provides a solution that can more than compete with a JBoss.

However, there is certainly also the issue of pricing and licensing. In addition, classic Java Enterprise developers are used to their respective stacks, so it will be difficult to take out the well-known candidates JBoss or WebSphere.

For a customer to swap the stack - which is much more complicated in the J2EE environment than in the SAP world, where OS/DB migration is possible with standard tools - they have to derive clear benefits from it.

The libraries for text search and fuzzy logic are certainly great, but in our opinion SAP is not yet marketing them strongly enough in the community. In addition, SAP is also a new, largely unknown player in the Java community."

Guido Hoepfner adds that Q-Partners customers are innovating in the area of mobile solutions, using Fiori apps and developing their own applications based on SAPUI5.

"In the area of technology, a large number of our customers are actually interested in SAP Hana and we are currently carrying out various conversions of existing solutions to Hana"

he reports from his professional practice.

"Once this foundation has been laid, the conditions for innovation on the application side are possible. This is a development that we see coming. The logical first step is the SAP-based conversion to the new platform."

The challenges lie in particular in integrating the new programming models, technologies and architectures. Historically, both object-oriented and historically non-object-oriented structural programming can be used in Abap.

"This is still common in reports today and sometimes makes sense"

emphasizes Kneissl.

With the new technology in the direction of Hana, SAPUI5 and NetWeaver Gateway, you have to move much more in the direction of object orientation.

"This is particularly important so that users can make sensible use of the new technologies and also benefit from the advantages. Of course, this is a significant change that a user will not realize overnight. The situation is similar in the area of technology"

adds Hoepfner.