ENHANCING SECURITY FOR SAP HANA IN THE...

White Paper SAP Co-Innovation Lab

ENHANCING SECURITY FOR SAP HANA® IN THE CLOUD A COLLABORATIVE SAP® CO-INNOVATION LAB PROJECT WITH INTEL, VORMETRIC, AND VIRTUSTREAM Editors: Ashvin Kamaraju Sergio Pacheco-Sanchez September 2014 Version 1

Enhancing Security for SAP HANA in the Cloud 2

Acknowledgements This document is the work of a virtual project team at SAP Co-‐innovation Lab, whose members include: David Cruickshank (SAP SE), Tariq Ellahi (SAP), Roger Guedes (SAP), Mark Hourani (SAP), Heather Li (SAP), Kevin Liu* (SAP), Sergio Pacheco-‐Sanchez (SAP), Carmelo Ragusa (SAP), Jay Thoden van Velzen (SAP), Kathy Barboza (Intel Corporation), Todd Christ (Intel), Martin Guttmann (Intel), Bing Wang* (Intel), Ashvin Kamaraju* (Vormetric, Inc.), Sridharan Sudarsan (Vormetric), Carlos Wong (Vormetric), Michael Powell (Virtustream Inc.), Gregsie Leighton (Virtustream), Vince Lubsey* (Virtustream), Pete Nicoletti (Virtustream), and many colleagues from the participating companies who helped with this project. * project lead from each participating company


1 Executive Summary With corporate and government data breaches in daily headlines, it is no longer sufficient to secure just the perimeter of data centers. Data, which is the most important asset of every enterprise, must be secured using a combination of access controls, mature key management, and encryption. This is even more pertinent when such data is stored in the cloud, where others are managing the customers’ systems and may have access to client data. However, the overhead of encrypting data often leads to tradeoffs between performance and security. Thanks to recent innovations in hardware to accelerate encryption at the processor level, such tradeoffs are no longer necessary. Intel introduced a set of six instructions, called AES-‐NI (Advanced Encryption Standard New Instructions) in its Xeon E7 processor family. These instructions accelerate encryption using the AES algorithms, thereby reducing the performance overhead associated with encryption. Since the introduction of AES-‐NI, Intel has been improving the AES-‐NI performance with better pipelining and other optimizations in its Xeon E7 V2 and Xeon E5 V3 processor family. Vormetric, a leader in encryption software, has been working closely with Intel to exploit the AES-‐NI hardware acceleration with a new multi-‐threaded encryption engine. This has led to significant performance breakthroughs for a variety of enterprise workloads required for mission-‐critical applications. The SAP HANA® platform, which is used by enterprises both for transactional data operations as well as for real-‐time analytics, delivers high-‐performance throughput as well as low latency. SAP HANA stores and processes sensitive enterprise data that must be secured in order to meet industry-‐specific regulatory requirements, as well as offering real security in an age of porous perimeters. With SAP HANA deployed in the cloud and offered as a service, cloud security, especially data security, becomes even more important. With the recent AES-‐NI innovations in the Intel Xeon processor family and the Vormetric encryption software enhancements optimally exploiting AES NI, large data sets on SAP HANA can be encrypted or decrypted with virtually no performance overhead. SAP® Co-‐innovation Lab has shown through a series of tests that we can:

• Secure customers’ data using a combination of access controls and encryption • Lock cloud administrators out of access to the data without impeding their ability to perform administrative

tasks (and even applying to “root” accounts) • Leave the owner of the data in full control of the encryption keys


Table of Contents 1 Executive Summary ...................................................................................................................................... 3

2 Introduction .................................................................................................................................................... 5 2.1 Project scope ................................................................................................................................................... 6

3 SAP HANA ...................................................................................................................................................... 7

4 Vormetric Technology ................................................................................................................................... 8

5 Performance Evaluation ............................................................................................................................. 10

6 System Landscape ...................................................................................................................................... 11 6.1 System configurations ................................................................................................................................... 11 6.2 Software configurations ................................................................................................................................. 11

7 Experimentation Plan .................................................................................................................................. 12

8 Performance Evaluation Results and Analysis ........................................................................................ 14 8.1 OLTP-Bench workload .................................................................................................................................. 14 8.2 SAP-OLTP workload ..................................................................................................................................... 15 8.3 SAP-OLAP workload ..................................................................................................................................... 17

9 Summary ...................................................................................................................................................... 19

10 References ................................................................................................................................................... 19


2 Introduction With several powerful trends playing out in the industry – real-‐time data analytics, cloud computing, increasing regulatory requirements for data protection, and a daily stream of news of security breaches – security becomes the catalyst for migrating enterprise workloads to the cloud. Many companies are using, or planning to perform, sophisticated predictive and prescriptive analytics on all their data using SAP HANA (Intel Real-‐Time Business Intelligence, 2014). Achieving full value from SAP HANA requires integrating and analyzing core business data, which typically includes both sensitive customer information as well as an enterprise’s intellectual property. Data must be secured using encryption and access control in order to comply with regulatory requirements and to protect against data breaches. Security is even more important when hosting sensitive data in the cloud, in a service provider’s data center. There is an inherent loss of control when using a cloud hosting provider as suddenly, others are administering the customers’ technology landscapes. While a partner relationship implies trust, this does not necessarily protect a customer against rogue employees at the cloud hosting provider. Nor does a trusted partner relationship protect against state actors who might compel such providers to hand over data, potentially even preventing them from informing the customer. We can dramatically increase the trust levels between cloud hosting providers and their customers if we can demonstrate that:

• Any cloud administrator managing customers’ applications and cloud infrastructure does not have access to customers’ sensitive data

• Such data is encrypted on disk with the customer as the owner of the data holding the encryption keys To address potential performance impact associated with data protection of large data sets and enterprise workloads on SAP HANA, SAP, Vormetric, Intel, and Virtustream collaborated at SAP Co-‐innovation Lab to address the following:

1. Secure SAP HANA data and log volumes using Vormetric Transparent Encryption and Data Security Manager technologies

2. Quantify the performance overhead required for the data encryption solution for SAP HANA

The results derived of this project have demonstrated: • Robust security enabling customers to become the custodians of their encryption keys • Effective enablement of data-‐access control policies • Minimal performance overhead required to encrypt large data sets for solutions running on SAP HANA

Vormetric solutions not only complement cloud security best practices, but also provide security for the enterprise customers’ data, and help customers comply with regulatory requirements. Figure 1 illustrates a deployment model where the Vormetric Data Security Manager (DSM) resides on the customer’s premises while the SAP HANA database and the related server and storage infrastructure resides in the data center of a service provider such as Virtustream. The DSM is used by the customer to define the policies that govern access to the SAP HANA database and encryption of data sets in SAP HANA. Because the DSM resides on the customer’s premise, the customer becomes the custodian of the policies and encryption keys, and only the customer’s security administrators are authorized to define the polices and the encryption keys used in these policies. The service provider’s operational personnel can provision the necessary infrastructure and update all relevant software, but will


not have access to the data. This separation of duties, which allows the customer to be the custodian of encryption keys, enhances the security of SAP HANA when it is deployed in the cloud.

Figure 1. Vormetric Security Solution for SAP HANA in the cloud

2.1 Project scope

The scope of this project executed by teams across SAP, Vormetric, Intel, and Virtustream at SAP Co-‐innovation Lab and SAP facilities has focused on:

1. Installation and configuration of Vormetric Data Security Transparent Encryption on SAP HANA database servers

2. Management of the Vormetric Data Security Manager by creating encryption keys and necessary security policies that define encryption settings and access to user’s data

3. Measuring the performance overhead of the system while the Vormetric Data Security Transparent Encryption solution is enabled for a defined set of workloads

The aforementioned performance overhead investigation accounts for two generations of the Intel® Xeon® Processor E7-‐4800 product family.


3 SAP HANA High-‐speed data analytics is changing the way companies compete, enabling them to generate real-‐time insights to support their most important business processes. The SAP HANA platform is a clear leader in this arena, providing not just a uniquely fast and adaptable platform for real-‐time business, but as well to ultimately coexist and integrate with other cloud technologies. Cloud computing provides game-‐changing capabilities for business computing. Yet many companies have been reluctant to deploy mission-‐critical applications such as SAP HANA in cloud environments. Customers today recognize the potential benefits and want nothing more than to run all applications from the cloud; yet they all have unique requirements regarding security and compliance. Virtustream answers those security and compliance concerns with a global cloud infrastructure designed specifically for hosting mission-‐critical workloads. Now Virtustream is taking cloud security to even higher levels by integrating Vormetric Data Security into its cloud infrastructure and utilizing a variety of security technologies that are built into the latest Intel Xeon processor E7 V2 family. Intel, Vormetric, Virtustream, and SAP have been working together in SAP Co-‐Innovation Lab to integrate and test this solution. With this enhanced security architecture, customers can implement even stronger data encryption and more granular access controls for SAP HANA. Most important, customers retain complete control over their data in this enhanced cloud environment. And with SAP HANA running on the latest Intel Xeon processor E7 V2 family, customers can experience real-‐time performance across very large data sets – up to three times larger than could be supported using previous-‐generation platforms such as the ones configured with Xeon E7 family.


4 Vormetric Technology Overview: The Vormetric Data Security solution consists of two distinct components that work in tandem:

• Vormetric Data Security Manager (DSM), which is used by the security administrator(s) to define policies rules and encryption keys for each of the data servers where access to the data must be controlled and the data must be encrypted

• Transparent encryption, which resides on the data server and provides access control and encryption/decryption of data based on the policies defined by the security administrator

The Vormetric DSM and the Transparent Encryption agent communicate with each other using secure communication protocols such as the Transport Layer Security (TLS). Both are certified for data security standards such as FIPS 140-‐2. Vormetric Data Security transparent encryption exploits Intel® Xeon® Processor product family security features such as AES-‐NI to minimize the performance overhead associated with encryption.

Figure 2 illustrates the location of the transparent encryption component within the operating system stack at the data server. The transparent encryption software is an operating system–level product that layers above the native file system, for example, EXT3 on SuSe Linux SLES 11, and intercepts all system calls related to file I/O and the file system. The policies defined by the security administrator are applied to each of the I/O access system calls to determine whether the data must be encrypted (write), decrypted (read), and whether access to the data must be allowed or denied. The transparent encryption software is a secure file system, with the exception that it does not

Figure 2. Vormetric security solution functionality

Approved processes and users

Privileged users

*$^!@#)(

-‐|”_}?$%-‐:>>

Encrypted and controlled

John Smith 401 Main Street

Clear Text

Cloud provider Infrastructure and storage admins

*$^!@#)( -‐|”_}?$%-‐

:>>

Encrypted and controlled

Figure 2. Vormetric security solution functionality


have a disk layout of its own. It creates an overlay mount on the underlying file system. This overlay mount is called a “guard point.” A guard point can also be created on raw or logical volumes (similar to file systems). However, guard points on raw volumes are not used in the case of SAP HANA. Another important feature of the transparent encryption is its ability to prevent data access by privileged users. As illustrated in Figure 2, privileged users such as “root user” or other system administrators with privileged access can be denied access to the data. Denying privileged users access to the data is defined in a policy by the security administrator, using the DSM. The policy, which is made available to the transparent encryption software, is evaluated and enforced by the transparent encryption software running on a data server. Only authorized applications and authorized users can access the data. Vormetric Transparent Encryption secures SAP HANA data located in both the data and log volumes. Access to data sets in SAP HANA is enforced according to the security policies defined by the security administrator using the DSM. The DSM, with centralized key management and other important security administration features, provides separation of duties and enforces the security of the SAP HANA database regardless of whether SAP HANA is deployed in the cloud or in the enterprise.


5 Performance Evaluation For performance evaluation purposes, we have chosen a set of representative application workloads running on SAP HANA. The following workloads have been selected:

• OLTP-‐Bench: This is a database management system (DBMS) test-‐bed framework for online transaction processing (OLTP) and Web-‐based workloads (OLTP-‐Bench, 2014). From the variety of tests available, we have chosen the “TPC-‐C alike” workload. This workload simulates an order-‐entry system environment where a population of users executes transactions against a database. There is a mix of five different types of transactions executing concurrently. Clearly, the throughput is measured in transactions per minute. In summary, this workload represents the activity of any industry that must manage, sell, or distribute a product or a service.

• SAP-‐OLTP: This is an SAP internal transactional workload representative of a sales and distribution scenario in

the SAP ERP application. SAP-‐OLTP includes standard business transactions, as it essentially depicts the execution of a general sales cycle in an SAP system that refers to the creation of a sales order document followed by delivery and billing. The workload encompasses six transaction types: • One transaction displays all sales orders relating to a particular customer or material.

• Another transaction creates a sales order.

• Another transaction displays a sales order given an order number.

• Another transaction creates a billing document, that is, sales invoice.

• Another transaction creates an outbound delivery with order reference number.

• Finally, another transaction changes the outbound delivery and posts goods issue. In general, workloads on SAP ERP include a large set of transaction types arranged in workflow sequences. SAP-‐OLTP throughput is typically measured in dialog steps per second, frequently normalized to hours. Dialog steps, that is, requests, are the basic units of work in SAP ERP that are served within work processes (enterprise resource planning, or ERP, software threads) non-‐preemptively.

• SAP-‐OLAP: This is a SAP internal online analytical processing (OLAP) workload customized for SAP systems. It

is known that the OLAP data set is entirely loaded into memory before the execution of the system workload; thereafter, all operations are executed in-‐memory where no encryption/decryption is conducted. This fact clearly obviates the need to account for this workload into this work. However, aiming for performance evaluation completeness that encompasses both OLTP and OLAP worlds, we are showing experimental results that demonstrate no encryption overhead.


6 System Landscape

6.1 System configurations

Table 1 reflects the system configurations that are relevant for setting our joint activities:

Memory Storage Processor Cores

1TB 800GB (Intel SSD 910 Series PCIe 2.0 x8 Flash card)

Intel Xeon E7-‐4870 4 socket, 40 cores @ 2.4GHz

1TB 800GB (Intel SSD 910 Series PCIe 2.0 x8 Flash card)

Intel Xeon E7-‐4890 V2 4 socket, 60 cores @ 2.8GHz

Table 1. System configurations

NOTE: An additional server was used to act as the client system that executes the testing against the server running SAP HANA. The same client system has been consistently used for all the experiments. 6.2 Software configurations

Table 2 shows the details of the software components used on the SAP HANA database servers:

Software Component Description Version Operating system SuSe Linux Enterprise Server SLES 11 SP3

File system Ext3. File system storing SAP HANA data and log volumes Not applicable

SAP HANA SAP HANA support package stack (SPS)

SPS 06 revision 631 Stand-‐alone deployment

Table 2. Software configurations

The Vormetric Transparent Encryption software encrypted the SAP HANA data and log volumes using the American Encryption Standard (AES) algorithm. The symmetric key used for encryption had a key size of 256 bits. This key size (also known as key strength) provides the strongest level of security.

1 The SAP HANA revision used for conducting SAP-OLTP experimentation is 1.00.71.00. The reason behind this decision is that the SAP-OLTP application used is shipped for SAP HANA 1.00.71.00. The rest of the experimental plan has been executed while using the aforementioned SAP HANA revision 63.


7 Experimentation Plan Table 3 accounts for the detailed system configurations and workloads while enabling/disabling the Vormetric encryption solution for the Intel® Xeon® Processor E7-‐4800 and E7-‐4800 v2 product family.

Batch ID

Experiment ID CPU platform Encryption Workload

Data set size (GB)

Hyper-‐Threading

CPU utilization

Performance Evaluation Without Encryption

1

1 Intel Xeon E7-‐4870

NO

OLTP-‐Bench 365 OFF Entry midrange

2 Intel Xeon E7-‐4870 OLTP-‐Bench 182 OFF Entry midrange

3 Intel Xeon E7-‐4870 SAP-‐OLTP 4 OFF Midrange

4 Intel Xeon E7-‐4870 SAP-‐OLTP 4 OFF High

5 Intel Xeon E7-‐4870 SAP-‐OLTP 4 ON Midrange

6 Intel Xeon E7-‐4870 SAP-‐OLTP 4 ON High

7 Intel Xeon E7-‐4870 SAP-‐OLAP 21 ON High

2

8 Intel Xeon E7-‐4890 V2

NO


9 Intel Xeon E7-‐4890 V2 OLTP-‐Bench 182 OFF Entry midrange

10 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 OFF Midrange

11 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 OFF High

12 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 ON Midrange

13 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 ON High

Performance Evaluation with Vormetric Solution

3

14 Intel Xeon E7-‐4870

YES


15 Intel Xeon E7-‐4870 OLTP-‐Bench 182 OFF Entry midrange

16 Intel Xeon E7-‐4870 SAP-‐OLTP 4 OFF Midrange

17 Intel Xeon E7-‐4870 SAP-‐OLTP 4 OFF High

18 Intel Xeon E7-‐4870 SAP-‐OLTP 4 ON Midrange

19 Intel Xeon E7-‐4870 SAP-‐OLTP 4 ON High

20 Intel Xeon E7-‐4870 SAP-‐OLAP 21 ON High

4

21 Intel Xeon E7-‐4890 V2

YES


22 Intel Xeon E7-‐4890 V2 OLTP-‐Bench 182 OFF Entry midrange

23 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 OFF Midrange

24 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 OFF High

25 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 ON Midrange

26 Intel Xeon E7-‐4890 V2 SAP-‐OLTP 4 ON High

Table 3. Experimental Plan


The experimentation plan shown in the table above encompasses 4 batches of experiments, which in total account for 26 experiments, replicated at least 3 times. Clearly, experiment batches with ID 1 and 2 represent the experimental baseline whose results will be compared against the cases when system encryption is enabled. Note that SAP-‐OLAP is accounted for to accomplish a complete performance evaluation of both OLTP and OLAP schemes as discussed above in section 5; the experiments conducted for this purpose are experiments with ID 7 and 20. In total, OLTP-‐Bench is used in 8 system configurations, whereas SAP-‐OLTP is accounted for in 16 system configurations. The former considers 2 large data sets that are in the order of hundreds of gigabytes that drive CPU utilization of up 40% of usage, which can be classified as entry midrange system usage. The latter accounts for smaller data sets; however, it drives CPU utilization to midrange levels, 60% to 89%, and high usage levels, above 90%. Given the fact that only midrange system usage has been achieved by completing OLTP-‐Bench, it has been thought to enable the CPU Hyper-‐Threading (HT) feature only for higher-‐CPU utilization scenarios. This means that the HT feature has been enabled for SAP-‐OLTP workloads only as it drives CPU usage higher than OLTP-‐Bench, thus yielding system usage scenarios where the impact of HT is likely to be more visible. In summary, the workload variety used in this work exemplifies a real-‐world representative approach for stressing the system as a whole under different system load levels and data-‐set sizes.


8 Performance Evaluation Results and Analysis

8.1 OLTP-Bench workload

The evaluation methodology for this workload indicates to include the ramp-‐up and ramp-‐down phases. The former represents the system warm-‐up that eliminates the initialization overheads from system measurements. After the ramp-‐up, the system enters the steady-‐state phase, the one that is accounted for performance analysis; as the name suggests, during this phase the transactional throughput stabilizes. Thereafter, in the ramp-‐down phase, users progressively stop to send requests to the database server. Both the ramp-‐up and ramp-‐down phases each last for 20 minutes, and the workload steady-‐state phase is configured to last for two hours. Figure 3 depicts the performance overhead of encryption for the eight system configurations determined according to section 7. The plot shows the performance degradation, with respect to the baseline, in terms of throughput loss, quantified in transactions per minute, when encryption is enabled on the two different Intel hardware platforms while using two different data-‐set sizes. The throughput measurements are normalized by the throughput given by the E7-‐4870 system baseline and data-‐set size of 182GB.

Figure 3. OLTP-Bench throughput

We learn from Figure 3 above that for the same data-‐set sizes, the E7-‐4890 V2 processor outperforms the E7-‐4870 by approximately 75%. Moreover, when the data-‐set size is doubled, the E7-‐4870 encrypted system is taxed only an additional 0.4%. In contrast, the E7-‐4890 V2 system shows no encryption overhead while using the 182GB data set, and the encryption overhead is only 1% with the 365GB data set.

0

0.5

1

1.5

2

Xeon E7-‐4870 Xeon E7-‐4890 V2

Normalized

Throu

ghpu

t

Intel Xeon Processors

Baseline-‐182GB

Encrypwon-‐182GB

Baseline -‐365GB

Encrypwon-‐365GB

-‐7% -‐7.4%

0%

-‐1%


8.2 SAP-OLTP workload

As previously described, SAP-‐OLTP is an internal transactional workload that encompasses standard business transactions. In our experiments, the workload placed on the system is equivalent to that generated by 40,000 users accessing the SAP HANA database for various ERP functions. Similar to the evaluation methodology of previous workload, testing this application also encompasses the ramp-‐up and ramp-‐down phases. In the ramp-‐up phase, all users log on one after another, and the number of concurrently working users is increased until reaching the 40,000th user. The experimental run continues with the high load phase, that is, steady phase, which is the actual interval considered for performance analysis. This is very important because before entering the high load phase, it is necessary that the system has the buffers and cache already filled; this allows using representative measurements. In the ramp-‐down phase, all users log off one after another. Both the ramp-‐up and ramp-‐down phases last each for 10 minutes, and the workload high load phase is configured to last for 30 minutes. We have confirmed through a sensitivity analysis that a 30-‐minute period is representative of a phase with stable transactional throughput. That is, similar measurements would be obtained when running experiments for longer periods of time. Figure 4 depicts the performance overhead of encryption for 4 out of the 16 different system configurations defined according to section 7. The plot shows the performance degradation, with respect to the baseline, in terms of throughput loss when encryption is enabled on the two Intel hardware platforms evaluated. The throughput measurements are normalized by the throughput given by the E7-‐4870 system baseline. We have chosen the system configurations of high CPU utilization when no HT is enabled. That is, in order to summarize the presentation of the experimental results, we show only the results of the four system configurations that stress the system the most. For instance the CPU utilization of the Intel Xeon E7-‐4870 systems has been approximately 97%, whereas the same measurements for the Intel Xeon E7-‐4890 V2 systems have been slightly lower, about 92%.

We learn from Figure 4 above that when comparing the baselines, the E7-‐4890 V2 system delivers an additional 126% of throughput compared to the E7-‐4870 system. Regarding the performance overhead, when encryption is enabled

0

0.5

1

1.5

2

2.5

Xeon E7-‐4870 Xeon E7-‐4890 V2

Normalized

Throu

ghpu

t

Intel Xeon Processors

Baseline

Encrypwon -‐1.2%

+5%

Figure 4. SAP-OLTP throughput


compared to the baseline, the E7-‐4870 system suffers a slight (negligible) throughput degradation of about 1.2%. In contrast, the E7-‐4890 V2 system delivers consistently along all experiment replications a throughput that is slightly higher by approximately 5%. We surmise that this “counterintuitive” behavior of slightly higher throughput stems from the fact that Intel has made significant enhancements (pipelining) to the AES-‐NI instructions in the Intel Xeon E7-‐4890 V2 processor family. Vormetric encryption software takes advantage of these enhancements in order to deliver faster encryption processing times. In addition, Vormetric encryption software parallelizes I/O requests into multiple encryption/decryption threads, which in effect leverages the multiple processor cores in the system more optimally. Together, these hardware and software enhancements result in very low overhead and consequently greater system performance. It is important to highlight that this “counterintuitive” behavior is observed only on the newer Intel Xeon E7-‐4890 V2–based systems. Actually, during OLTP-‐Bench experimentation, a similar behavior has been observed while using the 182GB data set. Only until the data set of 365GB is used has this “anomalous” system behavior stopped, and we actually observed a transactional throughput loss of approximately 1% with encryption on. Clearly, this substantial increase in data-‐set size entails a system load increase. Based on these results, we could hypothesize that as the data-‐set size increases, the more likely that we continue observing a progressive performance degradation trend. In summary, the hypothesis formulated behind this “counterintuitive behavior” is that, given the fact that more resources are available on the Xeon E7-‐4890 V2 platform, the Vormetric software is able to increase the parallelization of the encryption/decryption operations. This parallelization effort, which is witnessed by a significant increase in the system-‐context switching activity, seems to induce higher throughput related to a combination of factors. These factors include, as a possibility, better data locality and not a fine-‐tuned multi-‐threading level, which exceeds to a point for not only hiding the latencies, but also for delivering slightly higher transactional processing capability. In addition, Figure 5 illustrates the encryption performance improvements of the Intel Xeon E7-‐4890 V2 processor versus the E7-‐4870 CPU by showing memory-‐speed test results, quantified in megabytes per second, for different memory buffer sizes.

Figure 5. Comparison of encryption performance: Xeon E7 vs. Xeon E7 V2 processor family


The memory-‐speed tests were conducted by using Vormetric Transparent Encryption software that encrypts data in memory buffers of varying size. That is, there was no I/O related to storage accesses. These tests were conducted to measure the AES-‐NI related enhancements in the Xeon E7 V2 family of processors together with the code optimization in Vormetric encryption to increase the pipelining of the AES rounds. The results have demonstrated that the pure cost of encryption was significantly lower on the Xeon E7 V2 family of processors. Clearly, these enhancements could further explain the fact that the parallelization achieved with the Vormetric encryption engine could lead to better performance than the baseline for the same workload. 8.3 SAP-OLAP workload

SAP has defined “T-‐shirt sizes” for SAP HANA appliances. These T-‐shirt sizes are based on the compressed data-‐set sizes that can be loaded into memory for processing. Sizing recommendations state that 50% of the system memory should be used for storing data, whereas the other 50% should be used for intermediate results, temporary data objects, and so on. Keeping these sizing guidelines in mind, the 1TB server should be able to hold 512GB of compressed data. In other words, in order to process 512GB of compressed data, 1TB of memory is required. The evaluation methodology for this workload indicates to warm up the system before the actual experimentation stage; the warm-‐up phase preloads the data set into memory. This implies that the data read from persistent storage is decrypted prior to caching it into memory. Therefore, there is no encryption or decryption of data associated to query answering during the execution of the experiments that take place after the warm-‐up phase. While this important point is well understood, and obviated the need for taking into account this workload, we decided to prove our hypothesis by setting a simple set of experiments. This has entailed using a data set smaller than 512GB; thus we have set the data-‐set size to 21GB, as shown above in section 7. Similar to the experimentation using the other two workloads, we have configured the system to hold both data and log volumes on the Intel SSD PCIe Flash card. However, even if both volumes had been placed on a slower device such as mechanical media, it would not affect the performance shown in Figure 6 below, except during the data-‐loading phase (loading from persistence to memory), which is not accounted for in this experiment. In our test bed, we have 100 users running on the client hardware sending queries to the server. In total, during each experimental run, 18,000 queries are sent to the server, which on average take about 49 minutes to execute. The SAP-‐OLAP experimentation showed that there is no overhead on the system when encryption is enabled. The system is actually saturated at approximately 97% of CPU usage, on average. It is also important to highlight that I/O activity is nonexistent at about 36 I/O operations per second (IOPS), on average. In contrast, during the execution of SAP-‐OLTP and OLTP-‐Bench, the system delivered approximately 10,000 IOPS on average, showing spikes of up to 19,000 IOPS. Figure 6 depicts system throughput, in terms of queries per hour, of both the baseline and the encryption experimental runs. The throughput measurements are normalized by the values of the baseline.


Figure 6. SAP-OLAP throughput

We can observe that, for the 16 replications of the experiment (that encompass baseline and encryption), the difference in throughput between the baseline and encrypted systems is minimal at 0.96%. This difference is a minor variance, possibly introduced by factors other than encryption. In the long run, on average, the system throughput of both the baseline and the encryption will converge.

0.0

0.5

1.0

1.5

2.0

1 2 3 4 5 6 7 8

Normalized

Throu

ghpu

t

Experiment ReplicaQons

Baseline

Encrypwon


9 Summary Installing and configuring the SAP HANA application, the Vormetric Data Security appliance, and the physical SAP HANA database servers has been procedural and straightforward. Most of the project effort has been focused on measuring the performance overhead of encryption on the two Intel hardware platforms evaluated, namely the Intel Xeon E7-‐4870 processor and the Intel Xeon E7-‐4890 V2 processor. We have measured an encryption overhead of a single digit, overall. In particular, the experimentation on the Intel Xeon E7-‐4870 platform shows an overhead of less than 8% while processing transactional workloads. In contrast, experimentation under transactional workloads on the Intel Xeon E7-‐4890 V2 platform reveals a negligible performance overhead. However, we surmise that the counterintuitive behavior found in some system configurations might be attributed to the parallelization effort of Vormetric software running on the Intel Xeon E7-‐4890 V2 platform. Evidence of this degree of parallelization is the increased context switching activity on encrypted systems, as it surges up to a 25% with respect to the baseline reference system. We also have provided results of testing that no performance overhead is placed on the system processing analytical workloads when encryption is enabled. We plan to evaluate the high-‐availability features of the Vormetric security software in combination with the scale-‐out deployment of SAP HANA. We also aim to evaluate the operational impact of the data transformation methods of Vormetric software as the size of data sets in data centers significantly increases.

10 References • SAP Web site, (2014) Retrieved from: http://www.sap.com • Vormetric Web site, (2014) Retrieved from: http://www.vormetric.com/ • Intel Web site, (2014) Retrieved from: http://www.intel.com • Intel Real-Time Business Intelligence. (2014). Intel white paper on Security in the Cloud for SAP HANA [White

paper]. Retrieved from http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-security-xeon-e7-v2-sap-virtustream-paper.pdf

• Virtustream Web site, (2014) Retrieved from: http://www.virtustream.com/

• OLTP-Bench Web site, (2014) Retrieved from: www.oltpbenchmark.com

Copyright/Trademark

Copyright© 2014 SAP SE or an SAP SE affiliate company. All rights reserved.No part of this publication may be reproduced or transmitted in anyform or for any purpose without the express permission of SAP SE.The information contained herein may be changed without prior notice.Some software products marketed by SAP SE and its distributors contain proprietary software componentsof other software vendors. National product specifications may vary.These materials are provided by SAP SE and its affiliated companies (“SAP SE Group”) for informationalpurposes only, without representation or warranty of any kind, and SAP SE Group shall not be liable forerrors or omissions with respect to the materials. The only warranties for SAP SE Group products andservices are those that are set forth in the express warranty statements accompanying such products andservices, if any. Nothing herein should be construed as constituting an additional warranty.SAP SE and other SAP SE products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP SE in Germany and other countries.Please seehttp://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

for additional trademark information and notices.

ENHANCING SECURITY FOR SAP HANA IN THE...

Documents

Transcript of ENHANCING SECURITY FOR SAP HANA IN THE...