SAP HANA Tiering: The Pressures of Data Growth
Fri, 01 May 2020 14:24:20 -0000|
Read Time: 0 minutes
“Data growth is accelerating!” Quotes like this appear frequently in studies, papers, and blogs. You will not find more data growth quotes in this blog article, however, because I think it is more interesting to look at this from a data management investment policy perspective. A data management investment policy has similar benefits to a corporate travel investment policy—the goal is to efficiently maximize the bottom line. In most customer accounts, the SAP HANA licensing investment happens early and the business must maximize the benefits in the long term. First cost is not the sole driver because volume, variety, veracity, and velocity are all considerations when a company is looking for a strategy. Evaluating a data management investment policy for the long term can be complex. SAP provides Native Storage Extensions (NSE) to address both cost pressures and the intelligent placement of data over time.
SAP HANA with NSE offers the functionality of tiering data using different storage solutions based on the age of the data. The NSE data management policy categorizes data into three classes: hot, warm, or cold. This blog post focuses on the hot and warm data tiers. Hot data can use both volatile and nonvolatile memory, as follows:
- DRAM: DRAM is the fastest storage media. DRAM is volatile, however, meaning the data must be loaded into memory on restart of the database or server.
- PMEM: Persistent Memory (or PMEM) is faster than SSD storage but not as fast as DRAM. PMEM is also nonvolatile memory, meaning the data does not have to be loaded into memory on restart of the database or server. PMEM is used for the SAP HANA Fast Restart option.
SAP HANA on-premises Native Storage Extension
If you are interested in learning more about maximizing your data management investment strategy, the SAP HANA TDI on Dell EMC PowerEdge Servers Validation Guide provides detailed configurations. The hot data tier both drives the fastest performance and is the most expensive tier (hardware + SAP HANA licensing + annual support). Maximizing the performance-to-cost trade-off of hot data placement requires consideration of two factors:
- Keep actively used data that is critical to the business in the hot data tier
- Migrate less frequently used data out of the hot data tier to sustain costs
The first consideration is a performance guideline for when the responsiveness of the database and applications is at a premium for the business. Data that is less frequently used can be placed in the warm tier to minimize the impact on queries on the hot data tier. Another benefit is related to SAP HANA restarts. For example, planned maintenance events involving Linux operating system or SAP HANA database updates can require a restart. An SAP HANA system with NSE could have less data in the hot tier compared to the same SAP HANA system without NSE, thus improving restart times.
NOTE: SAP HANA also has a Fast Restart Option that uses file storage to speed up restarts. Fast Restart leverages PMEM to accelerate file storage access, significantly reducing the start time of the database. SAP HANA Fast Restart applies to scenarios in which only SAP HANA is restarted and not the operating system.
The second consideration is an avoidance guideline that sustains existing investments while mitigating additional ones. Success could be defined as a strategy in which performance increases with each new server generation while SAP HANA costs remain constant if the size of the hot data tier remains the same. The business impact is a continual increase in performance combined with efficiently maximizing the bottom line.
The warm data tier is for less frequently accessed data that occasionally resides in SAP HANA memory. If kept in memory, warm data accelerates costs, mainly through the additional licensing that is needed to increase the memory size. To mitigate the impact of rapid data growth, maximize the usage of the warm data tier. Keep in mind that the warm data tier is limited to four times the size of the hot data tier. For example, a hot data tier of 1 TB means the warm data tier can be up to 4 TB. The warm data tier also cannot exceed 10 TB in size. The 10 TB maximum is a first-release restriction.
Data in the warm tier is transactionally consistent with the hot data tier. This means that the warm data tier must be protected in conjunction with the hot data tier so that the entire database backup is consistent. While the hot and warm data tiers are transactionally consistent, they differ in how data is loaded into memory. The hot data tier is ”column loadable,” meaning the columnar tables are loaded into memory. In contrast, the warm data tier is “page loadable,” meaning granular portions of data are loaded into memory or partially in memory. The page-loadable design has two key benefits for the warm data tier:
- It does not significantly impact the memory footprint.
- It does not significantly impact the start time of the database.
Use of the warm data tier depends on the SAP HANA NSE buffer cache. This buffer cache is enabled by default and is initially sized as 10 percent of SAP HANA memory (for the sizing reference, see the SAP HANA Administration Guide for SAP HANA Platform 2.0 SPS 04). For example, the NSE buffer size is recommended to be at least 12.5 percent of the total size of the warm data tier. You can modify the NSE buffer cache size by using the ALTER SYSTEM ALTER CONFIGURATION command.
Warm Data Tier
Overall, use of the warm data tier enables customers to balance fast performance with increased data volumes while minimizing cost, thus achieving greater value. Customers have the flexibility to design an amazingly fast warm data tier with storage I/O latencies measured in microseconds, narrowing the difference between the hot and warm data tiers in terms of performance.
Dell Technologies has a team of experienced SAP HANA experts that can assist with accurate sizing and design of an infrastructure solution for your databases. Our goal is to work closely with you to maximize the value of NSE and create an extremely fast warm data tier that narrows the performance gap with the hot data tier. Your Dell Technologies representative can put you in contact with one of our SAP HANA experts.
Related Blog Posts
New all-NVMe VxRail platforms deliver highest levels of performance
Mon, 30 Mar 2020 15:24:55 -0000|
Read Time: 0 minutes
Two new all-NVMe VxRail platforms deliver highest levels of performance
December 11, 2019
If you have not been tuned into the VxRail announcements at VMworld Barcelona last month, this is news to you. VxRail is adding more performance punch to the family with two new all-NVMe platforms. The VxRail E Series 560N and P Series 580N, with the 2nd Generation Intel® Xeon® Scalable Processors, offer increased performance while enabling customers to take advantage of decreasing NVMe costs.
Balancing workload and budget requirements, the dual-socket E560N provide a cost-effective, space-efficient 1U platform for read-intensive workloads and other complex workloads. Configured with up to 32TB of NVMe capacity, the E560N is the first all-NVMe 1U VxRail platform. Based on the PowerEdge R640, the E560N can run a mix of workloads including data warehouses, ecommerce, databases, and high-performance computing. With support for Nvidia T4 GPUs, the E560N is also equipped to run a wide range of modern cloud-based applications, including machine learning, deep learning, and virtual desktop workloads.
Built for memory-intensive high-compute workloads, the new P580N is the first quad-socket and also the first all-NVMe 2U VxRail platform. Based on the PowerEdge R840, the P580N can be configured with up to 80TB of NVMe capacity. This platform is ideal for in-memory databases and has been certified by SAP for SAP HANA. The P580N provides 2x the CPU compared to the P570/F and offers 25% more processing potential over virtual storage appliance (VSA) based 4-socket HCI platforms that require a dedicated socket to run (VSA).
The completion of the SAP HANA certification for the P580N which coincides with the P580N’s general availability demonstrates the ongoing commitment to position VxRail as the HCI platform of choice for SAP HANA solutions. The P580N provides even more memory and processing power than the SAP HANA certified P570F platform. An updated Validation Guide for SAP HANA on VxRail will be available in early January on the Dell EMC SAP solutions landing page for VxRail.
For more information about VxRail E560N and P580N, please check out the resources below:
Bare Metal Compared with Kubernetes
Thu, 04 Jun 2020 16:19:26 -0000|
Read Time: 0 minutes
It has been fascinating to watch the tide of application containerization build from stateless cloud native web applications to every type of data-centric workload. These workloads include high performance computing (HPC), machine learning and deep learning (ML/DL), and now most major SQL and NoSQL databases. As an example, I recently read the following Dell Technologies knowledge base article: Bare Metal vs Kubernetes: Distributed Training with TensorFlow.
Bare metal and bare metal server refer to implementations of applications that are directly on the physical hardware without virtualization, containerization, and cloud hosting. Many times, bare metal is compared to virtualization and containerization is used to contrast performance and manageability features. For example, contrasting an application on bare metal to an application running in a container can provide insights into the potential performance differences between the two implementations.
Figure 1: Comparison of bare metal to containers implementations
Containers encapsulate an application with supporting binaries and libraries to run on one shared operating system. The container’s runtime engine or management applications, such as Kubernetes, manage the container. Because of the shared operating system, a container’s infrastructure is lightweight, providing more reason to understand the differences in terms of performance.
In the case of comparing bare metal with Kubernetes, distributed training with TensorFlow performance was measured in terms of throughput. That is, we measured the number of images per second when training CheXNet. Five tests were run in which each test consecutively added more GPUs across the bare metal and Kubernetes systems. The solid data points in Figure 2 show that the tests were run using 1, 2, 3, 4, and 8 GPUs.
Figure 2: Running CheXNet training on Kubernetes compared to bare metal
Figure 2 shows that the Kubernetes container configuration was similar in terms of performance to the bare metal configuration through 4 GPUs. The test through 8 GPUs shows an eight percent increase for bare metal compared with Kubernetes. However, the article that I referenced offers factors that might contribute to the delta:
- The bare metal system takes advantage of the full bandwidth and latency of raw InfiniBand while the Kubernetes configuration uses software defined networking using flannel.
- The Kubernetes configuration uses IP over InfiniBand, which can reduce available bandwidth.
Studies like this are useful because they provide performance insight that customers can use. I hope we see more studies that encompass other workloads. For example, a study about Oracle and SQL Server databases in containers compared with running on bare metal would be interesting. The goal would be to understand how a Kubernetes ecosystem can support a broad ecosystem of different workloads.
Hope you like the blog!