SAP HANA® is becoming a reality for many SAP customers. As a Basis Administrator, DBA, or System Architect, you may be asking yourself what that will mean for you. What are the key decision points during the planning phases that will require your input? What skills will you need to attain and leverage during implementation, migration, and during steady state operations?
We start by looking at SAP HANA use cases. SAP HANA is a database, but it’s also much more. Its projected role in a given environment is the fulcrum for many of the architectural choices that will be made, and also determines scope of administrative effort and responsibility.
As a relational database system, SAP HANA can be used as a backend for both SAP BW and SAP Business Suite. For SAP BW, many of the established technical responsibilities associated with this platform are transferable, but the flexibility and features of SAP HANA coupled with SAP BW 7.4 may require an expanded skill set. Examples include increased data modeling capabilities, and information model consumption. The nearline storage (NLS) interface which provides an alternative to traditional data archiving, and Smart Data Access (SDA); an integration technology that facilitates data transfer between the SAP HANA backend and the NLS system are new technologies available with SAP BW 7.4 on SAP HANA.
Use of SAP HANA as an RDBMS backed for SAP Business Suite not only requires expertise on the SAP NetWeaver platform, but also knowledge of SAP HANA repository objects such as stored procedures and data models that are integrated in to SAP HANA specific optimization and processing elements.
SAP HANA Data Mart or “sidecar” deployments present a whole new set of considerations. Knowledge of user management and access control is a must in situations where Developers need direct database access, and an understanding of the change control and transport mechanisms available will also play an integral role. Data provisioning technologies are especially relevant for Data Mart systems as a means to get data from external systems into the SAP HANA database. To that end, SAP Landscape Transformation Replication Server (SLT), and SAP Data Services are used in different real time replication, and batch ETL contexts.
Administration of SAP HANA in any context requires a deep understanding of its underpinnings and architectural elements such as the Index Server, XS Server, and Name Server among others. Each play a vital and important role in the operation of this complex database. Managing the relationship between memory and data-persistent processes, and proper administration of the persistence layer itself (log and data volumes) is key to the health of the system. Additionally, SAP HANA only runs on supported versions of SUSE Linux Enterprise Server (SLES) and Red Hat Enterprise Linux (RHEL); something to consider when scoping potential administrative effort.
With an understanding of what’s possible with SAP HANA and how it will be used in a given environment, decisions about hardware and deployment can be made. Many are familiar with the concept of SAP HANA as an “appliance”; an approved version of SLES or RHEL pre-installed with the SAP HANA database on certified hardware. A comprehensive listing of certified appliances based on the Intel Haswell, Intel Ivy Bridge, and predecessor Intel CPUs can be found in the SAP HANA Hardware Directory. SAP HANA on IBM POWER8 is supported, but only within TDI (a program we’ll touch on shortly).
The concept of “T-shirt sizing” (sizing of systems based on pre-configured ratios of installed RAM, CPUs/cores, and disk) is a common way of classifying appliance systems. When sizing any SAP HANA solution, it’s important to remember that CPU and RAM ratios are specific to use cases (SAP BW on HANA, SAP Business Suite on HANA, etc.) due to differing requirements for OLAP vs OLTP workloads.
An alternative to certified appliances, SAP introduced Tailored Datacenter Integration (TDI) as a means for customers to utilize existing infrastructure in SAP HANA solutions. No formal certification of TDI infrastructure is offered by SAP, however, server hardware and storage products must be selected from SAP HANA Hardware Partners in published offerings. While the TDI approach can be attractive from an operational cost savings and flexibility perspective, it does require that the underlying Operating System and the SAP HANA database software itself be installed by an individual holding the “SAP Certified Technology Specialist- SAP HANA Installation” certification. SAP provides the SAP HANA Hardware Configuration Check Tool (HWCCT) as a means to determine whether a given TDI solution meets SAP’s performance KPIs related to throughput and latency. The version of HWCCT used must correlate to that which was used for certification of the servers and storage solutions by the vendor. KPI scenarios are different for OLAP and OLTP systems, and while they are geared toward production environments, it is ultimately up to the customer to determine whether test results meets their operational requirements.
How to Scale SAP HANA
Scaling SAP HANA is frequently discussed in terms of “scale up” (hardware with capacity for additional CPU. RAM, and disk) and “scale out” (typically smaller pieces of hardware operating in a cluster that shares a dedicated internal network and common filesystem(s)). Both are ways to address growing data volume and/or increased workload. Scale out systems are much more common with SAP BW on HANA since they conform well to the technical underpinnings of that specific database architecture, while scale up systems are more frequently deployed for SAP Business Suite on HANA (though there are strictly defined processes and hardware prerequisites that can be met in order to achieve SAP support requirements for SAP Business Suite scale out systems).
When discussing scaling, virtualization is frequently part of the conversation, and SAP HANA on VMware offers advantages in this area in addition to high availability, and agile provisioning. For non-production environments, SAP supports VMware vSphere 5.1 with SAP HANA SPS 05 (or later), while VMware vSphere 5.5 with SAP HANA SPS 07 (or later) is supported in production. In should be noted however, that running multiple production SAP HANA VMs is supported only under controlled availability for selected customers. Using VMware in high availability scenarios for SAP HANA can be achieved by way of vMotion (which allows the live migration of an SAP HANA virtual host from one piece of physical hardware to another with no downtime). This is accomplished by completely preserving the state of the database in memory while allowing transaction and query processing to continue with only a minor impact to performance. While running virtualized SAP HANA offers several advantages, there are numerous recommendations and technical best practices that must be followed such as NUMA pinning, workload optimization, and optimizations related to virtual NICs and SCSI adapters.
Want to learn more…
While we’ve only scratched the surface of SAP HANA use cases, architecture, scaling, and virtualization from a technical perspective, it’s easy to see that administration of this platform requires a unique and diversified skill set. By leveraging our years of industry leading SAP Basis Managed services, and our enterprise class SAP HANA Cloud, Symmetry is positioned to get you in the SAP HANA game and start your project today.
For more information to get started with Symmetry’s SAP HANA cloud solution, request a free quote here.
Photo Credit: © kasto/Bigstock