Making SAP HANA Mainstream in your Datacenter - Dell · PDF fileMaking SAP HANA Mainstream in Your Datacenter ... Online transaction processing ... SAP HANA can either scale up,

Part 2: An architect’s guide to deploying SAP on-premise with Tailored Datacenter Integration

Making SAP HANA Mainstream in

your Datacenter

LET’S GO

Abstract: This whitepaper shares the experience and learning EMC gathered from customers who were early adopters of SAP HANA. It covers architecture, operations, and change, to guide you through currently available deployment options along with their benefits and challenges. It also includes future directions we foresee with SAP HANA and SAP HANA-based applications.

Target Audience: This whitepaper is aimed at Enterprise Architects, SAP Technical Architects, Directors of Operations, Directors of IT Engineering, Directors of Architecture, and in general all senior technologists involved in defining and deciding the deployment model for SAP Software based on SAP HANA in their organizations.

Table of Contents

Executive Summary

Introduction

Architectural Principles

Design Guide

Roadmap

Conclusion

Next Steps

Resources

2 | Copyright © 2016 EMC Corporation. All rights reserved. Published in the USA.

Starting the Journey

Executive Summary

Introduction

Fundamental Principles of Architecture Design

Architect’s Design Guide:

– Designing for Scalability

– Designing for Performance

– Designing for Resilience

– Designing for Automation

– Designing for Extensibility/Flexibility

Roadmap to Build Your SAP HANA TDI Infrastructure

Conclusion

Next Steps

Resources

1

2

3

E M C 1 . 5 9 9 0

D E S I G N I N G F O R

Scalability1

X C L 3 . 0 2 5


Resilience3

G O 5 . 1 7


Extensibility/Flexibility

5

P R O 2 . 3 5 0


Performance2

A U TO 4 . 1 2


Automation4


Executive SummaryIT architects have the primary responsibility of ensuring not only that the IT systems put in place by an organization deliver against the business requirements of that organization, but that the systems also represent a rational utilization of company assets.

The key business goals for IT architects of SAP HANA, as well as other technologies in the datacenter, are to accomplish the following:

When SAP first introduced SAP HANA on dedicated appliances only, many of the traditional practices and principles used by IT architects could not be applied. With the introduction of SAP HANA TDI (Tailored Datacenter Integration), that is no longer the case. Although SAP still specifies restrictions on SAP HANA infrastructure architectures, today most of the key principles of IT systems architecture can also be applied to SAP HANA systems.

A holistic approach to IT architecture across the datacenter is now possible, offering a more cost-effective way to deliver the benefits of SAP HANA to business organizations. This is achieved by utilizing existing data center resources. This allows organizations to build a strong return on investment (ROI) business case for SAP HANA adoption, as described in EMC’s business whitepaper, Making SAP HANA Mainstream in Your Datacenter – Part 1.

Reduce costs Manage risk correctly Simplify change Drive more business innovation

Today, you can achieve your business goals by matching SAP HANA system designs with your datacenter strategy:

• Leverage a standard datacenter architecture to host SAP HANA• Use existing skills, processes, and tools in the datacenter• Allocate resources tailored to the business requirements of individual systems • Balance processing performance and costs through data tiering• Virtualize to achieve greater flexibility and automation • Simplify architectures and operations by using converged infrastructures• Leverage EMC’s robust availability, data-resilience, lifecycle management, and

data-protection solution extensions already available in your datacenter

The following chapters explore each of these aspects in detail.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

http://emc.com/collateral/emc-perspective/h14459-making-sap-hana-mainstream-datacenter-part1.pdf

IntroductionSAP HANA is an essential part of the SAP product portfolio and roadmap. SAP customers are incorporating HANA into their overall SAP strategy in order to standardize all their SAP workloads onto one HANA platform. They must also take into account that all non-HANA platforms/databases will be out of SAP support by 2025. Customers therefore demand that all SAP related investments are protected when moving to HANA platform.

As organizations transition from the proof-of-concept (PoC) phase to the mainstream adoption phase, Tailored Datacenter Integration (TDI) has become the only infrastructure option that is viable for the long term. The companion white paper, Making SAP HANA Mainstream in Your Datacenter, Part 1 explains why this is so.

In Part 2, we focus on the design process and considerations for choosing the right infrastructure architecture for your on-premise deployment of SAP HANA.

Datacenter Readiness

As with investments in any other information technology, an investment in SAP HANA--including the resources to deploy and operate it—must help an organization achieve its business goals.

Cost-effective operations, compared to the business benefit it provides

Predictable performance, as businesses need to rely on certain performance and service levels without disruption through downtime or degraded services/performance

Innovation through effective and efficient implementation and adoption of technology

Flexibility to allow organizations to experiment at low cost and high speed, be agile in supporting fast launches of new business initiatives, and be flexible in responding “just in time” to unexpected requirement changes

Datacenter readiness is the result of a “risk contingency evaluation” of whether an application infrastructure architecture is ready “by design” to support and facilitate availability-, performance-, data resilience-, and change-related activities in an acceptable time window, and at a reasonable cost. Risks can also be lowered by making change a “smooth constant” in IT operations.

Reduce costsManage risk

correctly

Simplify change

Drive more business innovation


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources



Fundamental Principles of Architecture DesignThe fundamental role of the architect is to find the “balanced architecture” for a given business scenario utilizing company resources to the maximum potential.

The first step in determining the appropriate architecture is to evaluate the business requirements of the business scenario in question. Avoid starting or building justification through technical discussions about SAP HANA infrastructure architecture, since ignoring the business relevance will lead to misalignment with key stakeholders and decision makers.

Acceptable TCO

MinimumTechnical

Requirements

Business scenariodefines technicalrequirements

Business benefitsdetermine

maximum cost

Acceptable TCO

MinimumTechnical

Requirements

Business scenariodefines technicalrequirements

Business benefitsdetermine

maximum cost


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

Important assumptions that underlie modern design principles include the following:

Not all applications are alike: Different applications (such as an ERP system compared to an HR system) and their roles (such as production, test or development) reflect different business scenarios that influence the technical requirements, and as a result, the design of the architecture.

Standardization: For both financial and operational reasons, standardization of IT is of major importance to most organizations.

Standardization• reduces software and hardware costs• lowers risk• increases productivity• minimizes staff training time and expense• manages change effectively

Your SAP HANA architecture can be standardized vertically by business areas to limit duplication of similar business functions and reduce the number of modifications or deployments of too many application systems. It can also be standardized horizontally by technology layer to reduce the number of technology choices of servers, network, and storage components across multiple applications. By standardizing your architecture both vertically and horizontally, you will significantly reduce the complexity of your system landscape.

Automation: Eliminate unnecessary and repetitive manual intervention or IT tasks, such as deployment of new SAP HANA instances, through automation, which takes advantage of standardization to reduce risk and improve productivity with consistent results.

Dealing with exceptions: There will often be exceptions. Variances in compliance requirements, localization of specific implementations, and different system up-time demands for different applications can sometimes make it hard to fit everything into one standardized model. This requires a process for evaluating requests for exceptional solutions, documenting the exceptions, and continuously re-evaluating the scenario to turn exceptions back into standardized solutions.

Design Considerations for a Flexible and Future-proof SAP HANA Infrastructure Architecture

An IT architect defines the balance between technical and business requirements.

The technical variables to be considered include the following:

Scalability

Performance

Resilience

• Application-level Availability• Data Resilience and Disaster Recovery (DR)

Automation


Your design considerations must also include detailed evaluation of these variables in terms of their financial consequences: the cost to deploy/implement, the cost to operate, and the cost to evolve/change.


Performance

Scalability

Resilience

Automation

SAPHANA


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

E M C 1 . 5 9 9 0


Scalability1

X C L 3 . 0 2 5


Resilience3

G O 5 . 1 7



5

P R O 2 . 3 5 0


Performance2

A U TO 4 . 1 2


Automation4

Architect’s Design Guide

Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

Designing for ScalabilityEnterprise Relevance

Organizations must adapt their SAP HANA architecture to its intended workloads. However, workloads can fluctuate and depend on internal and external influences and business aspects, including changes in business priority. Thus, your SAP HANA architecture has to be flexible and agile to rapidly scale up or down according to business needs without disruption.

Challenges

Different infrastructure architectures will place different constraints on an organization. You must take cost, complexity, and even physical limits to scalability into account. The wrong architecture could have a long-lasting negative impact on enterprise operations and productivity. It is therefore important to identify the business scenarios you plan to migrate to or implement on your HANA system in the foreseeable future. These scenarios will affect the amount of associated data that is generated and consequently impact the SAP HANA RAM requirement. Larger, single HANA systems (scale-up) are more expensive, but easier to manage than scale-out systems with distributed data and multiple nodes. Online transaction processing (OLTP) applications like ERP and CRM are only supported on scale-out HANA systems in specific scenarios and in close cooperation with SAP.

Approach

SAP HANA has been designed with a “shared-nothing” architecture. In other words, in addition to conventional database scalability options and more memory as a result (scale-up), SAP HANA can also grow by adding more server nodes to create a cluster (scale-out). Data is then split into partitions across the nodes.

The SAP HANA Scalability whitepaper (Login credentials may be required) provides further information on the possibilities of scaling SAP HANA. In essence, scaling concepts apply to SAP HANA in the same way they apply to other databases; SAP HANA can scale to handle greater volumes of data and to increase performance.

SAP HANA can either scale up, by increasing the capacity of a single server’s main memory (RAM), or scale out, by adding servers into a cluster and spreading data across all active nodes within that cluster.

Scale Up Scale Out HANA HANA


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation

› Extensibility/Flexibility

http://scn.sap.com/docs/DOC-60340

CHARACTERISTICS OF SAP HANA SCALE-UP:

Application specific. Suite on HANA (SoH) and S/4 HANA are currently only supported with scale-up architectures. Scale-out scenarios with multiple worker nodes are not yet generally released for Suite on HANA and S/4HANA. SAP Note 1825774 provides the detailed information. (SAP Marketplace credentials are required.)

Consolidation. Multiple AnyDB systems can be consolidated on a single SAP HANA system.

Less complexity. The scale-up approach may still be the simpler solution for higher performance and capacity. A scale-up solution may be easier to manage because it does not raise the same issues of cross-node communication and data distribution as a scale-out solution.

Cost. Organizations that expect their systems to be stable—with limited change in their environments—may see operational expenditure (OpEx) savings in a scale-up system that compensates for initially higher capital expenditure (CapEx) investment.

Flexibility. An SAP HANA TDI deployment assumes the use of external storage components rather than built-in storage. External storage allows for more flexible scale-up processor changes and upgrades.

Skills impact. A scale-up solution does not require specialized skills to manage table and load distribution, and hash algorithms. No cross-node network tuning or troubleshooting is required.

Hard growth limits. Customers that have significant growth rates on their SAP HANA systems will hit a limit sooner when scaling up when compared to scaling out, which keeps options open. Changing the RAM capacity on an existing system often involves a processor change, as well as changes to the firmware and OS version.

High availability (HA). Shared storage allows 1 worker +1 standby configuration, as described in SAP Note 1825774. (SAP Marketplace credentials are required.)

CHARACTERISTICS OF SAP HANA SCALE-OUT:

Application specific. Only SAP Business Warehouse on HANA (BWoH) and other OLAP type of workloads such as HANA native applications are supported for scale-out architectures.

Flexibility. The use of smaller standard building blocks in the datacenter enables organizations to reallocate these smaller boxes more easily to better meet dynamic business needs.

Efficiency. Multiple smaller servers tend to lower the cost of vacancy, especially for service providers and large customers with more than 50 production SAP systems.

Much higher growth limits. Scale-out solutions allow organizations to keep their options open for SAP HANA systems that have massive growth rates, unlike scale-up solutions which hit growth limits.

Communication complexity. The cross-tenant communication and requirements for network communications between scale-out nodes can be complex, accentuating the advantage of the simplicity of a single scale-up node.

Cost. From a CapEx perspective, a 2 x 4-socket server is considerably less expensive than a 1 x 8 socket server. However, if you need to manage a significant number of smaller systems in a scale-out cluster, the OpEx can be higher than that of a single scale-up system.

High availability. Scale-out has built-in HA capability through the use of one or several standby node(s).

Single SAP HANA System Scale-up Versus Scale-out

The decision to scale up or to scale out will depend on each organization’s specific requirements.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


http://service.sap.com/sap/support/notes/1825774


The choice between a scale-up or scale-out solution will depend on your specific situation and priorities. A few additional factors may also make one solution significantly more attractive than the other:

Switching between architectures. Applications that run in a scale-out environment will typically also run in a scale-up environment, if required, and the associated RAM can be purchased for a single-certified system. The reverse is not true for all applications.

Reduced data footprints. The increased use of “data aging” or “data tiering” solutions and the simplified data models of S/4 can reduce the RAM requirement of your SAP HANA system in general, regardless of which deployment model you use. With a reduced in-memory data requirement comes the opportunity to reduce the number of scale-out nodes or stay within the capacity of a scale-up system.

Application-level tiering functions include Near line storage (NLS) for SAP Business Warehouse (BW), the information lifecycle management (ILM) framework inclusive of the Archive Development Kit (ADK) for SAP ERP, as well as Data Aging for S/4 HANA-based applications.

Platform-level tiering functions include dynamic tiering (DT), available on HANA since SP09, and Data Lifecycle Manager (DLM), which is part of the SAP HANA Data Warehouse Foundation (DWF) and available since HANA rev. 96. DLM is currently limited to SAP BW and native HANA applications and does not yet support any other standard SAP applications.

IT automation. The OpEx for scale-out systems may increase due to the larger number of OS images to manage and patch. On the other hand, the right automation tools can considerably reduce the effort required. If your operation is already tuned to handle large numbers of individual images, this may be a moot point.

Scalability and the Full SAP Applications Landscape

Limiting the discussion of scalability requirements to a single system would be shortsighted if it ignored the bigger picture of the full applications landscape.

Many customers will continue to have at least three-tier landscapes with production, test, and development systems, in which large systems will most likely be the exception.

The scale-up and scale-out considerations described previously are exponentially compounded when applied to your entire SAP system landscape. The SAP HANA Scalability whitepaper on the SAP community network offers further information (login credentials may be required).

Keeping the Size of Your HANA System in Check

As described earlier, any of these data-tiering solutions can help decrease the in-memory data requirement of your HANA deployment, reducing licensing cost and keeping your HANA system size more manageable. Additionally, S/4 HANA, with its dramatically reduced data requirement and simplified data models, means reduced HANA in-memory requirements for your main application data. Due to enterprise-wide virtualization requirements, some organizations try to keep their HANA in-memory requirement within the supported limits of HANA on VMware-based virtualization. This point will be covered later in this paper.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation



Storage Platform Choice

When selecting a storage platform, organizations need to balance single-system requirements with full landscape requirements. Generally, the number of SAP HANA systems in the landscape and the uniqueness of their performance and replication requirements will determine which back-end storage platform to choose. Additionally, you may be operating not only SAP HANA-based SAP applications, but also traditional relational database management system (RDBMS)-based applications and critical non-SAP bolt-on systems with their own requirements with similar service-level-agreement (SLA) expectations.

Active Data Locality

The right solution for each organization will depend on its landscape profile. Any of the EMC storage systems that are certified for HANA TDI can also be leveraged as a platform for the data tiering location to simplify your design and offer unified protection abilities.

Virtualization

One of the best known advantages of virtualizing a datacenter environment is simple scalability. In addition to improving asset utilization, virtualization also delivers flexibility: simply increase the memory configuration of a VM on the fly and restart HANA after adjusting the HANA RAM parameter in the global.ini.

When using VMware, for instance, if an ESXi server no longer has sufficient capacity, the systems can be live-migrated using vMotion to another ESXi server with more capacity where the VMs can then be resized.

Because of these and other advantages, such as VMware HA and DRS, we recommend that you factor virtualization—within the current limits of VMware support for SAP HANA scenarios—into your architecture design wherever possible.

For further information on the scenarios currently supported by VMware for SAP HANA, consult SAP HANA on VMware vSphere on the SAP Community Network (Login credentials may be required).

HANA

Traditional DatabaseHANA Database

Disk

RAM

DATA DATA

DATA

Disk

RAM

DATA

AnyDB


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation



Basic Blueprint for Scalability

Work closely with SAP to determine the size of your system, including any anticipated growth.

Scale up first, and then scale out where necessary and where applications support that option.

SAP BW, data marts, and native custom HANA apps can utilize a scale-out SAP HANA design.

Most OLTP applications, like ERP and CRM, are better suited to a single node scale-up model due to the complexity of dividing tables among nodes, maintaining growth, and adding new data for new business scenarios.

Utilize infrastructure components that support both scale-up and scale-out models, instead of only one or the other. You may not know all your requirements at this time and may want to err on the side of caution and flexibility.

Consider the requirements of each system, together with the requirements of the full landscape.

Higher capacity requirements and mixed workloads will be key drivers for the back-end disk count.

Choose your storage platform as a balance between single-system requirements and landscape-wide scalability.

Know how many HANA nodes you require today in your entire landscape and how many you will need in your datacenter for growth. Not all storage platforms can be connected to the same number of HANA nodes.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Designing for PerformanceEnterprise Relevance

The pace of business continues to accelerate. Enterprises have increasingly large amounts of data to process and analyze, and shorter time. SAP HANA enables business functions to act with significantly shorter response times compared to traditional RDBMS-based solutions.

Challenges

Performance optimization can be complicated, especially with a platform that still needs to be better understood by the majority of SAP Basis teams, as well as organizations in general. A system that does not respond to the pace of your business leads to lower productivity and disappointing expectations. Over-delivering on this variable may result in unnecessary cost.

About the only unchanged reality is the fact that applications still result in SQL statements against your HANA database. New tools, such as Calculation views and Attribute views within HANA that help ensure optimal performance, require new skills.

The infrastructure for your SAP HANA system still consists of servers, network, and storage. However, the use and role of these familiar components have shifted due to the in-memory nature of SAP HANA.

Approach

Since the same IT components (servers, network, and storage) used in your SAP HANA TDI system are shared with other applications in your datacenter, certain Key Performance Indicators (KPIs) need to be met by each component.

SAP-defined HANA TDI KPIs

SAP has defined a number of KPIs that production and critical HANA TDI systems have to meet.

These KPIs are documented in SAP Note 1943937 (SAP Marketplace credentials are required) and can be tested with the SAP-supplied Hardware Configuration Check Tool (HWCCT), available at SAP’s Software Download Center. The SAP Note also contains instructions on where to obtain the tool and how to run it in your system. The KPIs and HWCCT continue to be revised; please refer to the SAP Note for the latest information.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


https://service.sap.com/sap/support/notes/1943937

Critical Infrastructure Aspects for In-Memory Performance Needs

SAP HANA is an in-memory database; the typical read/write ratio is 10%/90%, with heavy sequential writes and large block sizes. Business process performance is no longer tightly tied to tuning the IO stack for latency. This is very different from the traditional SAP applications that take advantage of buffer/caching at different layers and prefetching techniques on the storage array to improve response time.

This in-memory architecture still benefits from high performing storage for

• Faster system startup, failover and data load time

• Improved query performance when access data of the Extended Store (ES) under DT

• Reduced large objects (LOB) load times in cases where LOBs are stored on disk rather than in memory

EMC’s internal tests have shown that bandwidth and connectivity make a key difference for the scenarios mentioned here. Simultaneously increasing the number of Host Bus Adapters (HBAs) on your HANA node(s) and the number of storage front-end-ports can significantly reduce your HANA data load times. EMC has documented configuration best practices and implementation guides for all certified and validated platforms. References for all these documents can be found later in this paper.

SAP’S HANA TDI KPIs SAP Note 1943937

Output examplePath : /hanamove/log/SCQ (xfs)IO order : sequentialLog 4k : Max. Throughput initial write 13.9947GB/#Log 4k : Max. Throughput initial write 13.9947GB/#Log 4k : Max. Throughput initial write 13.9947GB/#Log Latency 46: Latency sync. overwrite : 301.622#

HANA

Storage

Measurements

Data 4K,16K, 64K,1M,16M, 64M

4K,16K, 1MSequentialLog

Volume IO Order Block Sizes

RandomHWCCT

DataMostly writes

Reads on startupor occasionalloading of cold data

Asynchronous

Block sizes of4K Up to 64MB

LogsMostly writes

Reads only due to backup jobs

Synchronous

Block sizes of4K, 16K, 1M

Gua

rant

eed

Low

Lat

ency

OLTP

OLAP

HANA

OLTP

OLAP

(OLTP&OLAP)

HANA

90%

60% 40%

0% 20% 40% 60% 80% 100%

10%

90%

Read % Write % Max Block Size KB Min Block Size KB

164

164

10244

1 10 100 1000Gua

rant

eed

Hig

h Th

roug

hput

10%

Storage Performance Drivers

SAP’s Defined KPIs are a Starting Point


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Avoiding Typical Performance Pitfalls

Typical mistakes that we see in IO performance when running large SAP HANA systems are related to one or more of the following:

• Not enough HBAs on the HANA node(s): As previously mentioned, long startup times, slow data loads, and long node failovers can all be caused by inadequate bandwidth between your HANA node(s) and your storage system. All storage area network (SAN) components require 8 GB/s link speed and the SAN topology must follow best practices with all redundant components and links. Use a minimum of two HBAs for throughput and availability. You can increase the number of HBAs on your HANA nodes in multiples of two.

• Saturation of front-end (FE) ports on storage systems: In most real-world scenarios, applications will not consume 100% of the allocated physical capacity. As a result, organizations can cut costs by pooling and sharing resources between multiple systems. In many cases, they can also consolidate at the storage level, with a single array supporting a large number of servers. All these servers will share a number of FE ports, whose function is to send/receive IOs to/from the servers. In the case of HANA, this may lead to unacceptably low performance, as FE ports are serial devices. Dedicating specific FE ports to critical SAP HANA systems can overcome this problem.

• Inefficient multi-pathing: The SAP HANA database requires SLES11 or RHEL 6.5 OS on the SAP HANA nodes. To access the block devices from the SAP HANA nodes, ensure that zoning is properly configured based on SAN best practices. Follow the steps described in the EMC Host Connectivity Guide for Linux to enable Linux DM-MPIO on SLES11 or RHEL 6.5.

Allocating Performance Capacity Based on Real Requirements

In the SAP HANA TDI FAQ, available on SAP Community Network (SAP Marketplace credentials are required), SAP discusses the flexibility to define the right performance for each system based on its workload profile.

SAP has removed the requirement for non-production systems to run on certified components. (SAP does not provide performance support for these systems.) Customers can now make a trade-off between cost and performance for non-production systems as they did previously for SAP NetWeaver-based business systems. How can we then determine the right ratio of performance to apply to each system type?

SAP may revise its Quick Sizer tool to include this information in the future; however, this capability is not currently available. As most migrations of SAP Business Suite today are from AnyDB to SAP HANA as the main platform, this ratio must be determined from the careful evaluation of the current utilization and role of existing systems, as well as any new systems. You can use the following evaluation map example to determine your system requirements as they relate to HANA TDI KPIs.

Not All Systems are Equal

Meet TDI KPIs

Sandbox

Training

QA

Pre-Production

Production

Clone

Development

Disaster RecoveryLow

Low

High

High

P E R F O R M A N C E

CR

ITIC

AL

ITY


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


http://www.emc.com/collateral/TechnicalDocument/docu5128.pdf


Virtualization

Performance in a virtualized environment has not always been discussed in the proper perspective. The following real-life customer case may help to clarify this matter.

The customer had been running SAP BPC 10 (Business Planning and Consolidation) on Oracle and decided to migrate to SAP HANA. After the OS/DB migration from Oracle to HANA, a key planning process that previously took an average of 53 minutes to run now took about seven minutes. After applying the Enhancement Package 1, the same process ran in 17 seconds (a 99.5% improvement!!!). This performance was achieved with virtualized SAP HANA. The customer then measured the performance on bare metal in an appliance where the process ran in 15.5 seconds. This corresponds to a performance hit of roughly 10% when running in VMs compared to bare metal.

Taking into account the OpEx and CapEx impact of running SAP HANA on a physical, dedicated appliance compared with running SAP HANA on an existing infrastructure virtualized with VMware, how much was the difference of 1.5 seconds worth to the customer’s business? The response was obvious in this case. The customer chose a TDI and virtualization strategy for SAP HANA deployment, enabling a far more cost-effective deployment and leveraging the built-in characteristics of availability inherited from the virtualization.

VMware also conducted recent benchmarks to determine the performance overhead of a virtualized architecture compared with a physical architecture. For the same workload in both cases, the additional overhead was less than 4. However, traditionally and to be extremely conservative, sizing is done with a 10% overhead already calculated in.

Essentially, the SAP HANA virtualization discussion is therefore one of TCO, simplicity, and agility, not performance. The majority of customers running performance comparisons like the one above will most likely come to the same conclusion.

You can find out more about the current options for running SAP HANA virtualized with VMware on SAP HANA on VMware vSphere (login credentials may be required).

60:00,053:00,0 187x Less Batch Time

00:17,0

07:00,0

00:15,5

30:00,0

00:00,0

• 7x improvement in batch achievedwith turning of:– infrastructure– VMware– HANA database– or of the BPC ABAP code

• 187x improvement after EHP1

• How much is 0,04% better,worth in your scenario????

BPC onOracle 11.2

BPC onHANA

Virtualized

BPC10 EHP1on HANA Virtualized

BPC10 EHP1on HANA Bare Metal

SAP HANA on VMware in PerspectiveRun a process in ± 0.04% of the time…It’s all about TCO


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation



Avoiding Typical Performance Pitfalls under Virtualization

Typical mistakes that we see in IO performance when running large SAP HANA systems virtualized with VMware are related to one or more of the following:

• Not following best practices: The best practice guide will provide all necessary details about setting up and configuring an SAP HANA workload on vSphere considering configuration for the VM, OS, I/O etc.

• Not enough HBAs and NICs on the ESXi hosts: When customers consolidate multiple database servers on the same ESXi host virtualized with VMware, they often only evaluate CPUs and RAM. They do not take into account that data will need to flow in and out of servers. Consider for instance the consolidation of four SAP HANA systems onto a single ESXi host, where each SAP HANA server has two host bus adapters (HBAs) to connect to the storage (a total of eight HBAs). What if the new ESXi host is only equipped with two HBAs that must now be shared between four SAP HANA systems? Insufficient HBAs will increase latency. The same limitation also occurs with network interface cards (NICs) for network connectivity.

• Inefficient multi-pathing: Multi-pathing enables a VM to process IO through multiple HBAs. Because an HBA is a serial device, enabling parallel communication across multiple HBAs while optimizing their utilization can have a dramatic improvement on VM IO latency and throughput. However, a standard round-robin multi-pathing configuration on an ESXi host with different workloads may lead to undesired results: some very large IO may cause higher latency to smaller, but more critical, IO. Multi-pathing software with smart algorithms (such as EMC PowerPath/VE) can overcome this issue and is critical in the context of SAP HANA VMs.

• Inadequate configurations of HBA drivers or ESXi kernels: VMware has published a set of whitepapers that covers this area in detail. Issues include too-low values for default IO queues of the HBAs on ESXi that cause bottlenecks, and configurations at the ESXi kernel level that influence SCSI adapter behavior (such as aggregating multiple IOs before sending them to the physical adapters to optimize bandwidth) and create higher than desired latency on small block writes. Such issues can be avoided by ordering a health check with VMware specifically for SAP HANA, or by deploying your virtualized systems in optimized infrastructures, such as the VCE Vblock systems that are set up with these best practices and configurations.

Set up correctly, virtualizing SAP HANA using VMware provides excellent performance and reduces costs throughout the lifetime of your SAP HANA systems.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation



Basic Blueprint for Performance

Study SAP Note 1943937 (SAP Marketplace credentials are required)

Set performance objectives that correspond to business requirements and that can be measured and verified for each of your SAP systems; select an architecture that best suits all these objectives.

Make use of implementation best practices.

Leverage HANA functionality as it is designed. Understand the purpose and capabilities of Attribute Views, Analytic Views, Calc views, and how they depend on each other.

Measure progress with initial testing and throughout the HANA lifecycle to ensure that you can continue to meet performance objectives.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


https://service.sap.com/sap/support/notes/1943937

3 Designing for ResilienceEnterprise Relevance

Unavailability of business functions can cause disruption and financial loss to your enterprise. Loss or damage to your data can also negatively impact your business and is therefore unacceptable. Any of your IT solutions including your SAP HANA system must mitigate such risks to all business functions.

Challenges

Your SAP HANA systems require the right architecture to keep business disruptions to a minimum or to eliminate them entirely. It is essential to balance cost with the risk to your business, particularly when selecting system components or evaluating the potential for datacenter-wide failures. Additionally, you may want to take advantage of existing technologies that are already in place for other mission critical systems.

Approach

Resilience is about managing risk and documenting the probability and business impact of system outages, data loss concerns, and component failures. Resilience concerns can be categorized into local and remote application-level availability and data loss prevention. The standard measures for these concerns are expressed in RPO (Recovery Point Objective) and RTO (Recovery Time Objective). RPO defines a company’s maximum loss tolerance with respect to its data; RTO defines how long it takes to make an application (or function) available again. RTO and RPO are often defined as part of an SLA for a business, and provide a common language for different parts of an organization. Multi-level SLAs help clarify capabilities and expectations in different scenarios. Organizations should not put the same contingencies in place and accept the same cost for different levels of risk. Instead, different service levels should be defined based on RTO, RPO, and other metrics for a single component failure within a datacenter (for a HA solution) and for a full datacenter loss (for a DR solution.)

You may have the option of using the same technology for both HA and DR requirements, which can simplify the overall design. Remember, though, that your business should be the driving factor. Too often, solutions are implemented that are not in alignment with the needs of key stakeholders in the organization. The most important, and the most difficult part of designing your resilience solution is to meet the requirements of your business; everything else is secondary.

Many business users do not understand that lower RTO and RPO come with a price. It is often wise to have an open discussion and find the true RTO and RPO to set the right expectations and to provide the right solution at the right cost and complexity.

Factors Influencing Your Data Protection Options

RPO - Recovery Point Objective (how much data loss can be tolerated)RTO - Recovery Time Objective (how long it takes to make a systems available again)

OperationResumes

SystemOperational

R T ORPO

Design & Prepare Detect Recover Performance Ramp

Sync orBackup

OperationResumes

SystemOperational

RTORPO


Sync orBackup

OperationResumes

SystemOperational

RTORPO


Sync orBackup

Time


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


RPO and RTO are often defined as part of your SLA. It is important that your business stakeholders agree on these parameters as the foundation of your system architecture. Once a system has been implemented, it is a painful and expensive process to correct the differences between expectations and capabilities.

Application-level Availability

In order to focus on the HANA-specific availability content in this paper, we assume that redundancy in power, cooling and network is a common design practice. For server, switch, and storage systems, all components are designed and configured with redundant parts and connectivity. Currently, there are multiple solutions available from SAP, VMware, and EMC, which address availability with different RTOs; each solution has different implications for CapEx and OpEx.

HANA HIGH AVAILABILITY OPTIONS

HANA HostAuto-Failover

HANA SystemReplication VMware HA

Host Restart with Storage Replication

Unattended Failover Yes No, need clustering software Yes No, need clustering

software

Failover TimeMedium, load of column store for query execution

Short, with table reload and log replay options;Medium, without table

reload option

Medium, full restartMedium, stop time

of existing workload, plus full restart

Support for Virtualization

Yes, with EMCvHConnector Yes Yes Yes, can be combined

with VMware SRM

Need Standby (idle) Hardware Yes, at least 1 host Yes, for fastest

takeoverNo, can be managed

by DRS rulesNo, can be used for

non-production

Support Scale-up and Scale-out Yes Yes Yes Yes

Support Metro Distance Yes, with EMC VPLEX Yes Yes, with EMC VPLEX Yes


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


SAP HANA Host Auto-Failover is a native SAP HANA HA solution that does not require any additional clustering software or licensing. For scale-out implementations, Host Auto-Failover offers economical protection against single component failure. This option requires a standby host. You can find HANA HA options detailed in this SAP paper (login credentials may be required).

EMCvHConnector for EMC storage integrates with both SAP HANA Host Auto-Failover and VMware HA to deliver complete HA automation and a lower RTO. It is ideal for balancing cost and availability for customers who have many systems.

SAP HANA System Replication duplicates the entire SAP HANA system and can pre-load objects into memory. As a result, this solution provides the shortest RTO (usually less than five minutes). Cluster software or scripts are needed to automate the failover.

For scale-out scenarios, you may want to protect /hana/shared against a single point of failure with clustering solutions based on VMware tools and/or SUSE or Red Hat. See SLES HA options for SAP HANA or SAP notes on Red Hat for more information about these solutions. (Login credentials may be required for one or both of these resources.)

Data Resilience and Disaster Recovery

Your system could have many active users across the globe, as well as multiple interfaces to other systems, such as supply chain management, warehouse management, or manufacturing. Consistency across systems and zero data loss are increasingly required and have become standard for all organizations.

Geographic Resilence Data Loss Causes

Human Error Disaster

TechnicalFailure

Metro

Local Geo

Availablility Replication Snapshot Backup Archive

BalanceFactors Influencing Your Data Protection Options


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


https://scn.sap.com/docs/DOC-65585




Data loss can be caused by many different events, including human error, technical failures, and local/regional disasters. DR solutions require a balance between risk management, cost, and the limitations of physics (such as network latency, rate of change, and bandwidth).

Both SAP and EMC provide synchronous replication that ensures all data written to disk is replicated before an acknowledgment is sent to the application that replication is complete. Because this type of replication requires minimum network latency, it is usually limited to local or metro distances to minimize the impact on performance. While SAP native replication can pre-load objects to memory to deliver faster takeover, storage-based replication can achieve consistency across systems by using technologies such as consistency groups.

Both SAP and EMC also provide asynchronous replication to ensure that the main site is safe and to relax network performance and distance requirements. SAP asynchronous replication can be used in conjunction with non-production systems running on remote sites for increased utilization; however, the operational complexity of managing the solution is also increased. Storage-based asynchronous replication provides consistency across systems in this scenario.

SAP HANA REPLICATION OPTIONSHANA

Synchronous in memory

(SYNCMEM)

HANA Synchronous

(SYNC)

HANA Asynchronous (ASYNC) + QA

& Dev 2nd

Symmetrix Remote Data Facility

(SRDF) or MirrorView SYNC /

ASYNC”

RecoverPoint SYNC / ASYNC VPLEX Data Domain

Replication

Replicates the Entire System?

Database (DB) only DB only DB only Yes Yes Yes Yes

Federated Consistency No No No Yes Yes Yes No

RTO*Domain Name System (DNS)

takeover

DNS takeover + data load

QA & Dev Stop + data load

Boot + data load

Boot + data load

Boot + data load

Boot + restore & recovery + data load

RPO* 0 0 >0 0 on SYNC, >0 /ASYNC

0 on SYNC, >0 /ASYNC 0 Last replicated

log backup

Performance Impact on production

(PRD)

Networklatency

Networklatency No

Network latency

with SYNC

Network latency

with SYNC

Network latency No

Support Scale-up & Scale-out

Yes Yes Yes Yes Yes Yes Yes

*(depends on data volume, network latency, change rate)


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Note that HANA system replication includes all data and logs from the HANA system. External data types—such as shared files, configuration files, trace files and dumps—are not included. This data must be replicated in one of the following ways: including the volumes in storage-based replication, maintaining additional synchronization solutions, or including the data in the replicated backup.

Storage-based replication usually meets DR SLAs during DR readiness tests; the DR system is brought online and tested from a functional level before it resumes a role of TST or QA. HANA-based replication must be halted during such a test. If HANA replication is required to achieve a higher SLA when functioning with a role of TST or QA, there may be exposure to risk at certain levels or DR tests.

The requirements of availability and data resilience may be combined for maximum protection. In such cases, a cluster with SAP HANA system replication across two servers could be implemented within a single datacenter to ensure synchronous replication between the systems. Storage-level replication would then be performed to another site in asynchronous mode.

Backup and Recovery

HANA backups and backup replication remain important options for data resilience. Most customers have implemented a comprehensive backup solution that consists of backup software (such as Networker) and backup target media (such as Data Domain). Backup agents developed for SAP HANA accept SAP HANA as just another application and leverage existing processes and skills. Deduplication and WAN-optimized replication minimize network consumption and reduce storage footprint to reduce cost. Because backups are fully recoverable, backup administrators can restore the system to any point in time. However, the application will take longer to become available compared with other replication technologies. For customers who have compliance requirements, backup solutions remain the most cost effective option for long-term retention when used in conjunction with encryption to keep data safe. Depending on your recovery SLAs, if you replicate to your service provider’s Data Domain system, backup replication may also support HANA recovery as a service.

In conclusion, your SLA requirements will drive your selection for the appropriate technical components, as well as their configuration and operation. EMC offers the widest range of options for your SAP HANA environment.

HANA

Primary System

HANASystem

Replication

Secondary System

StorageReplication

Remote Standby System

HANAHANA

Replication Options


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Virtualization

Virtualization brings benefits in resilience, in both simplification and automation, for day-to-day operations:

VMware’s vSphere vMotion allows IT to live migrate SAP HANA databases across hosts in just minutes, with zero downtime and zero data loss. During the live-migration process, vMotion maintains the entire memory state, data, temporary tables, and statistics.

VMware HA automatically restarts VMs in the event of physical server and OS failures. It supports SAP native solutions and together with EMC vHANA Connector, SAP HANA Host Auto-Failover, and VMware HA can deliver complete HA automation and a lower RTO. It is ideal for balancing cost and availability for customers who have many systems.

VMware Site Recovery Manager (SRM) can help reduce the complexity of a DR solution by automating the complex disaster recovery steps at any level. SRM manages, updates, and executes disaster recovery plans. Through integration with EMC’s array-based replication (which supports replication at the block level), SRM also replicates SAP HANA data and log files to the DR site. SRM is fully integrated with EMC’s storage arrays.

VMware Fault Tolerance (FT) provides continuous availability for a virtual machine by creating and maintaining another virtual machine that is identical and continuously available to replaced the original in the event of a failover situation. It supports one vCPU on vSphere 5.5, and four vCPUs on vSphere 6. SAP Central Services (ASCS) is a good candidate for vSphere FT since ASCS is a single-point-of-failure (SPOF) that does not require much CPU resource like DBMS or SAP Application Servers.

Basic Blueprint for Resilience

Define multi-level SLAs with your business stakeholders

Read about SAP HANA HA options (Login credentials may be required)

Based on your OS choice, learn about OS-level HA options for SLES and Red Hat

If you are considering HANA on vSphere, read here (Login credentials may be required)

Read EMC best practice guides for your TDI platform

Whiteboard your options with your local EMC SAP specialist

Design your resilience to meet your SLAs

Consider external non-HANA systems in your HA and DR design (Which systems do you need to keep your business processes running?)

Test your design


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation





4 Designing for AutomationEnterprise Relevance

In today’s fast changing business environments, customers need to minimize the resources needed to maintain their SAP landscapes and focus more on innovation and business results. Automation is essential in achieving this goal. Automation can also eliminate human error of manual operations.

Challenges

If the automation system is complex, or if the task to be automated has many variables or is infrequently executed, the effort cost of automation may exceed the benefits that are achieved. Fast-changing systems also put stress on automated solutions, as they must be constantly revisited and updated. In addition, a heterogeneous infrastructure environment slows down or even prevents automation from being adopted.

Approach

Automation in the following three areas of IT operations will have a major impact on cost and risk management for IT organizations today:

Failover both in the case of single component failure (HA) and full datacenter loss (DR).

Repetitive SAP-specific operational tasks related to application lifecycle management activities.

Periodical tasks in infrastructure management.

01 Standardize 02 Virtualize 03 Automate

HANA HANA

vSphere vSpherevSphere

Infrastructure as a ServiceA Journey Towards Simplification and Agility


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


To optimize the investment in automation in terms of decreased operating cost, increased change agility, and reduced operational risk, you should take the following steps:

• Standardize on a physical architecture (compute, network, storage) across the datacenter, both vertically and horizontally. Datacenter standardization is strongly correlated with the possibilities of automation. The more standard the components that are used, the easier it will be to automate, and the more time and effort you will save. SAP HANA TDI opens up opportunities for such standardization. Converged systems from the VCE portfolio take standardization to even higher levels, where you no longer have to worry about interoperability issues of designing and maintaining you datacenter components.

• Software-defined architectures provide a higher degree of automation and go hand in hand with hardware standardization. Virtualization technologies for SAP HANA can help to accelerate the adoption of automation due to simplification (e.g. copy, clone SAP HANA VMs, Snapshots for rapid deployment of new SAP environments) and tools (e.g. vRealize Orchestrator) that can automatically execute even very complex, intertwined tasks through workflow automation.

These two steps simplify automation, extend its use, and multiply its advantages.

One example of automation through dramatic simplification is the traditional datacenter failover. In the event of disaster, IT relies on written operational cookbooks and manual work. In many cases, the scripts and commands are not up to date and not tested as frequently as they should be due to complexity and time. This leads to the inability to bring up the production systems on the DR site according to SLAs. As more and more customers consolidate business operations and analytics onto the same HANA platform, it is critical that the existing infrastructure can support reliable, repeatable, orchestrated failover in the event of disaster.

The matrix below shows the additional benefits of integrating VMware SRM with disk-based replication to automate the failover of the infrastructure, including applications such as SAP HANA.

DISASTER RECOVERY WITH AUTOMATION OPTIONS

HANA System Replication

Disk-Based Replication

Data Domain Replication

Tape Backup/ Restore

Replication Automation Simple Simple Simple Needs shipment service

Failover AutomationEasy with 3rd party cluster or custom

scripts

Easy on VMware with SRM Complex Not possible

Failback Manual set of reverse replication

Easy on VMware with SRM

Manual backup / restore

Manual backup / shipment / restore

Best “Potential” RTO* Under 1 minute 3 to 5 minutes Few hours Hours to days

Out of the Box RPO Near zero Near zero Last log backup Last arrived tape

DR Testing Without Protection Loss No Yes Yes Yes

Hardware (HW) Cost High to medium Medium Low Lowest

Network Cost High High Low None

Cost Avoidance No Vacant capacity Servers, storage, network Just store tapes

*(depends on data volume, network latency, change rate)


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


To better manage the SAP application lifecycle, SAP’s Landscape Virtualization Management provides automation workflows specifically for SAP HANA (from SAP LVM 2.1 onwards.) Integrations developed by storage vendors allow application administrators to take further advantage of storage array capabilities by pushing the copy/clone workload down the array without manual interruptions during the process.

Storage Integration with SAP LVM

EMC HLC Administration Console

EMC SMI - S

VMware ESXi

VNXFile-Block

VPLEX -Block

VMAX-Block

XtremlO -Block

vCenter Server

EMC Storage Systems

SAP LVM

ESI for SAP LVM Adapter


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Basic Blueprint for Automation

Standardize datacenter components vertically and horizontally.

Use virtualization as an abstraction layer to decouple applications from the physical hardware components.

Identify SAP HANA tasks and routines that can be easily automated or where reliability and predictable response time are important.

Utilize workflows for sequences of operational actions (backup routines, for example) or for business continuity actions to prevent or minimize interruption of service.

Evaluate the cost/time/effort of automation against the benefits.

Prioritize by order of importance and feasibility. Automate by order of priority.

Adjust automation when routines or objectives change.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


5 Designing forExtensibility/Flexibility

Enterprise Relevance As markets change, so do business objectives and the IT functionality required to achieve those objectives. New applications will need to be developed or acquired. The success of a business depends heavily on its ability to easily and seamlessly extend existing IT functionalities and integrate new capabilities at reasonable cost.

Challenges Existing IT systems—including SAP HANA—are architected, configured, and tuned to meet current business goals. It is not always possible to know what functionalities will be required in the future. The challenge lies in building architecture that not only satisfies existing application requirements, but is also able to accommodate other technology components/products in the future.

ApproachGROWING COMPLEXITY

As SAP HANA evolves, customers are consolidating multiple systems and functionalities onto their HANA platform. Customers are also now considering the use of HANA’s superior analytics capability for predictive analysis against massive machine-generated datasets. As a result, it is more and more challenging for the main memory to cope with the exponential data growth. However, not all data requires real-time analytics, particularly historical data. It is unnecessary, and unrealistic, to load ALL data into the main memory, resulting in:

Extremely long restart times

Excessive licensing costs

Wasted capacity in memory

Increased costs from resiliency requirements (HA and DR)

SAP has developed innovative techniques to improve data management and avoid these problems. These techniques including the following:

Dynamic tiering: offload data from the HANA database

Data aging: offload data for applications (such as G/L Accounting from Smart Financials) in an S/4 system

Near-line storage: offload data from BW systems using Sybase IQ as cool data storage

In addition, SAP recently introduced HANA Vora, a new in-memory query engine that further extends analytical capabilities with integration between HANA and Hadoop/Spark systems.

These innovations must be put into operation and be datacenter ready. Before entering production, however, they must be evaluated on the basis of performance, protection, and cost. It is also critically important to assess whether the existing infrastructure and processes can be seamlessly extended to support various types of systems and data without creating new silos.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Converged InfrastructureThe IT industry is undergoing a transformation; providers of components to IT systems are now supplying converged infrastructure systems. These systems are fully functional IT infrastructures. They are:

• factory built with best-in-class and SAP certified components

• fully tested and integrated, including servers, storage, networking, and software

• pre-installed and configured, based on best-practice guides and numerous tests

• delivered and supported as a single product

Converged infrastructure systems are also available for specific needs and environments, such as infrastructures specific for SAP HANA systems. The infrastructure complexity is abstracted to ensure that design principles, as well as the aforementioned design variables, are taken into consideration.

The customer no longer needs to design and engineer its IT infrastructure architectures. Instead, it can focus its IT resources on driving business alignment and maximizing the business value of IT.

VCE, with its unmatched product family, including VBlock , VxBlock, VxRack and VxRail, is the leader in the converged infrastructure market. VCE drives standardization across the datacenter (including SAP HANA) and leverages the possibilities of visualization and automation provided by VMware , Openstack, or Virtustream xStream Cloud Management software. VCE offers uniquely manufactured “data centers in a box”, extensible vertically and horizontally at any point in their lifecycle, for any workload. For customers that cannot utilize the offerings by VMware, Openstack or Virtustream in part of entirely, VCE even includes bare metal nodes in the architecture in a way that minimizes any impact on overall standardization. VCE technology extensions offer additional compute and storage capabilities that utilize the same interconnect and single vendor support model to allow even more applications, such as Big Data use cases, to reside on this platform.

CRM ERP

HANA

Converged Infrastructure


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Infr

ast

ruct

ure

Pla

tfo

rm

fun

ctio

ns

SA

P P

latf

orm

fu

nct

ion

s

IQ

Compliance - Protection – Availability - Replication

Compute Services

S/4, BW

Extended Store

Persistency

NLS/Data Aging Data/Document Archiving/Backup

SAP HANA Vora HANA

Data Services

Data Stores HDFS Tier 1/2 Block

Converged Infrastructure

/ NAS

Put It into Action: EMC Petabyte Platform for SAP• An organization starts with an infrastructure foundation design that leverages x86 servers with

virtualization, network, and SAP HANA-certified storage (such as VMAX, VNX and XtremIO), and either best-of-breed infrastructure to protect the existing investment or converged infrastructure (such as VCE Vblock) for higher standardization.

• New functionalities—such as NLS, data tiering, and data aging—are adopted to manage the HANA RAM footprint. Additional components that are required to support these functionalities (such as SAP IQ) can reside on the same platform that supports the existing applications.

• Availability and resiliency of all these applications are standardized and automated with EMC Data Protection Suite, which includes VPLEX and Data Domain.

• As the organization’s business and data continue to grow, Big Data analytical capabilities become more and more important. Spark and HANA Vora provide the necessary technologies in this area. EMC’s Isilon platform provides out-of-box Hadoop support and is available as a VBlock technology extension.

EMC Petabyte Platform for SAP

Basic Blueprint for Extensibility/Flexibility

Design an infrastructure to meet the current requirements, but also keep its extensibility and flexibility in mind.

Stay up to date with SAP products and technologies that may offer useful extensions of functionality. Evaluate how they may impact infrastructure architectural requirements.

Consider different options to find the right choice that balances technical requirements and business benefits.

Take a holistic approach to converged infrastructure. Consider reinvesting the savings from standardization, automation, and support into innovation.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Scalability

› Performance

› Resilience

› Automation


Roadmap to Build Your SAP HANA TDI Infrastructure

Leveraging hardware and software components by EMC and its partners, the following four-step process incorporates fundamental principles and design aspects to help you achieve a reliable operational infrastructure for your SAP HANA systems.

S T E P 1 : Define

Technical Requirements

and SizingS T E P 2 :

Choose Your Server S T E P 3 :

Choose Your Storage

S T E P 4 : Choose Your Protection

1

2

4

3

Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

Take a holistic approach to converged infrastructure.Consider reinvesting the savings from standardization, automation, and support into innovationOne of the easiest way to integrate your HANA system into your datacenter is to work with your VCE SAP specialist to get a “datacenter in a box” that is configured and ready for deployment. The flexibility of SAP HANA TDI, combined with a converged infrastructure from VCE, delivers the best of both worlds. By incorporating all the TDI aspects described in this paper, you get the single-point-of-contact experience of an appliance, without the limitations of an appliance. The VCE team can help you consolidate your HANA and non-HANA application requirements into a single-point-of-contact converged infrastructure that includes compute, network, and storage, backup and replication options. Because VCE systems support both bare metal and virtualized environments, nearly any SAP application requirement can be covered on this single platform.

If you decide to build your own HANA system, you can follow the simple steps below to achieve a reliable operational infrastructure for your SAP HANA system. These steps incorporate the fundamental principles and design aspects that were discussed previously and leverage hardware and software components provided by EMC and its partners.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

STEP 1: Define technical requirements and sizingOnce you have defined which business applications and scenarios to migrate to or be deployed on SAP HANA, it is time to take the design aspects into consideration, define the technical requirements that support the business scenarios at the right cost and minimal complexity, and use the information to design your HANA systems.

SAP provides sizing guidelines and reports, including the following, which can help you define your technical requirements’ (Login credentials may be required):

• Sizing Approaches for SAP HANA • 1793345 - Sizing for SAP Suite on HANA• 1637145 - SAP BW on HANA: Sizing SAP In-Memory Database

At a minimum, you should have answers to these questions:

• What is the RAM requirement of your protection HANA system?

• Which systems in your landscape must meet TDI KPIs

• What non-production systems require the same performance and support from SAP?

• What non-production systems require no SAP performance support and what is the required performance percentage compared to production (50%, 25%, etc.)?

• What is your RTO/RPO for local and remote scenarios?

• What level of data protection do you require?

• What is your system refresh frequency?

• What other systems have to be in sync for your system refresh?

1


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

› Define technical requirements and sizing

› Choose your server

› Choose your storage

› Choose your protection

https://websmp102.sap-ag.de/~sapidb/011000358700000050632013E



STEP 2: Choose your serverSAP offers certification programs for SAP HANA to qualify server vendors and products, including VCE converged infrastructure systems with specific server hardware configurations to guarantee consistent performance. If you choose a converged infrastructure approach, a VCE SAP architect can help you to select the servers that are best suited for your organization from the following lists of SAP-certified and validated servers:

• Complete list of VCE based configuration choices

• Certified servers based on Intel E7 CPU for production workload

• Validated entry-level servers based on Intel E5 CPU for non-production workload

You can find a full list of certified server vendors, models and additional information.

(SAP Marketplace credentials are required for these resources)

2


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources





https://community.emc.com/docs/DOC-52465

http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html

http://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/entry-level-systems.html

https://global.sap.com/community/ebook/2014-09-02-hana-hardware/enEN/appliances.html

STEP 3: Choose your storageThe official vendor-agnostic SAP HANA storage requirements are documented and updated in the white paper SAP HANA TDI Storage Requirements (Login credentials may be required).

EMC offers specific recommendations that incorporate real-world operational experiences of EMC and its customers. The configuration defined for you by your VCE architect may vary based on your growth projections.

• /hana/data/: Consider 1.2X RAM to build in headroom for growth

• /hana/log: Follow SAP’s most current recommendations

• /hana/export/: In most cases, this directory will be on the shared filesystem, which already allows for temporary exports. If full table exports are likely to be a regular task, consider a dedicated filesystem according to SAP’s most current recommendations

• Root filesystem and /usr/sap: 100GB per HANA node

• /hana/shared: Follow SAP’s most current recommendations

• /hana/backup/: If you are using EMC’s Data Domain, there is no need to consider this space in the storage array as it should be included in the Data Domain sizing. If you are not using Data Domain, allow sufficient space for “Data and Log backup” multiplied by the “number of backups to keep”

• Non-production systems are not expected to grow as much as production systems, so they will not require as much space. Consider staying closer to the minimum requirements described in the SAP HANA TDI Storage Requirements white paper

• If you are considering a full landscape with many large systems, the headroom for growth (2 x RAM for each production system) may be reduced in accordance with the organization’s overall expectations for growth and the frequency of its capacity planning process.


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

3






EMC offers a wide range of certified and validated SAP HANA TDI storage platform choices to meet each customer’s specific requirements. Any of these can be part of a VCE converged infrastructure or used independently with any certified server to suit your needs.

• VMAX: VMAX family (VMAX All Flash, VMAX 3 and VMAX) is the most scalable enterprise storage platform and is suited for organizations that want to consolidate their workloads. It also provides the highest enterprise grade availability and resiliency features such as SRDF and SnapVX.

• XtremIO: XtremIO provides significant scalability. The XtremIO Virtual Copies (XVC) functionality can be leveraged to merge production and non-production systems on the same storage platform to dramatically reduce the landscape footprint through compression and deduplication. Additional X-Bricks can be added for linear scale and performance scalability.

• VNX: VNX is the platform of choice for medium-to-small landscape sizes and is also featured in EMC’s SAP HANA appliance. MirrorView and SnapView provide for increase availability and resiliency.

• ScaleIO: ScaleIO provides massive scalability (up to thousands of systems) and is specially tailored for service provider scenarios. For details, please refer to SAP Note 800326: Certified SAP and EMC solutions for Linux environments (SAP Marketplace credentials are required).

• VPLEX: VPLEX is certified to work together with other EMC certified storage for SAP HANA.

• Unity: Unity is a midrange storage designed for all-flash and is available in purpose-built (all flash or hybrid flash), converged deployment (through VCE), and as a software-defined virtual edition. It’s a powerful combination of simplicity, modern design, affordable price point, and deployment flexibility.

Each of the options described above corresponds to a different organizational profile. The EMC SAP Specialist in your region can help you determine the right platform and configuration for your company. EMC also offers are regularly updated recommendations on SAP HANA TDI solutions.

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources






http://www.emc.com/collateral/brochure/emc-sap-hana-tdi-solutions-made-simple-br.pdf

STEP 4: Choose your data protectionIt is also essential to define a data protection strategy that aligns with the profile of your organization not only in terms of data resilience, RTO, and RPO, but also with respect to the strategy’s unique lifecycle management and automation requirements.

EMC offers a number of data protection options:

• VPLEX: VPLEX provides disaster recovery, as well as a fully automated 1+1 transparent failover solution, and can be utilized in many use cases specific to SAP HANA.

• RecoverPoint: RecoverPoint’s continuous local and remote data replication provides consistent point-in-time imaged across systems and simple recovery to any point-in-time or user-generated bookmarks.

• Data Domain: Data Domain‘s purpose-built backup appliances provide a robust platform to store and protect your backups and archives. They include integrated capabilities of compression and deduplication to reduce the overall footprint of your back-up data. They also offer remote replication capabilities that ensure the availability of your backup data at a remote location, enabling you to build a “cold DR” strategy and add an additional level of resilience to your data.

• NetWorker: NetWorker is the right solution for organizations that have a centralized team to manage all data protection activities (such as backup and restore) across the datacenter. It is fully integrated with the SAP HANA Backint API and leverages the full capabilities of EMC’s Data Domain backup appliances to ensure centralized backup scheduling and monitoring across your datacenter.

• DD Boost: Data Domain Boost for Databases and Applications—DD Boost—is the right tool for organizations that assign the responsibility for backup and recovery to the database administrators. This solution integrates fully with SAP HANA Studio, making the benefits of the Data Domain backup appliances available directly from SAP HANA Studio.

4

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point

VMAX2

VMAX3

XtremlO

VNX

ScalelO

DDBoost

Data Domain

NetWorker

Recover Point


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources





ConclusionEnterprises can now take advantage of the breakthrough technology of SAP HANA to achieve better business performance, while keeping cost and complexity to a minimum. The guidelines above demonstrate how you can leverage standard datacenter architectures, processes, and tools to move towards scalable, high-performance, robust, extensible, cost-effective implementations of SAP HANA. By using the TDI approach and selecting the right choice of infrastructure architecture for your on-premise SAP HANA deployment, your organization can look ahead to faster, better IT innovation and responsiveness to meet evolving business requirements.

Next StepsEMC is prepared to help you navigate through your IT transformation and assure your organization is “SAP HANA ready.”

Contact your EMC sales representative today, to book a meeting or request your participation on one of EMC’s next SAP events.

Attend a one-day customized executive briefing at EMC SAP Week to hear SAP subject matter experts from EMC, SAP, VMware, Virtustream and VCE. During the sessions, meet with our experts in person, and we will provide you a unique opportunity to learn about our latest solutions, have access to our teams’ learnings from engaging with multiple other customers that have already gone through SAP HANA implementation projects, and get advice in regards to your SAP HANA adoption strategy and architecture.

ResourcesMore information on EMC Solutions for SAP can be found here.Learn from the experience of EMC as an SAP customer by following the EMC IT blog.

EMCVMAX:Storage configuration on EMC VMAX All Flash, VMAX3, and VMAX storage systems

Business continuity with EMC Symmetrix VMAX

Business continuity with EMC Symmetrix VMAX3

Unity:Storage configuration on EMC Unity series unified storage systems

VNX:Storage configuration on EMC VNX series unified storage systems

Business continuity on EMC VNX with MirrorView

Business continuity and disaster recovery on EMC VNX with RecoverPoint

XTREMIO:Storage configuration on EMC XtremIO Storage

Business continuity with EMC XtremIO

VPLEX:Configuration and business continuity on EMC VPLEX


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

https://community.emc.com/docs/DOC-32257

http://www.emc.com/sapsolutions

http://itblog.emc.com/?s=sap

http://www.emc.com/collateral/white-paper/h12342-storage-config-best-practices-sap-hana-tdi-vmax-vmax3-wp.pdf

http://www.emc.com/collateral/white-paper/h13149-business-continuity-best-practices-sap-hana.pdf

http://www.emc.com/collateral/technical-documentation/h14466-continuity-vmax3-hana-sg.pdf

http://www.emc.com/collateral/technical-documentation/h15220-storage-config-best-practices-sap-hana-tdi-unity-sg.pdf

http://www.emc.com/collateral/white-paper/h13047-storage-config-best-practices-sap-hana-tdi-vnx-wp.pdf

http://www.emc.com/collateral/white-papers/h13955-vnx-storage-mirrorview-snapview.pdf

https://www.emc.com/collateral/white-papers/h14715-recoverpoint-hana-vnx-wp.pdf

http://www.emc.com/collateral/technical-documentation/h13984-storage-config-best-practices-sap-hana-tdi-xtremio-cg.pdf

http://www.emc.com/collateral/technical-documentation/h14761-business-continuity-recovery-xtremio-sap-hana-tdi-sg.pdf

http://www.emc.com/collateral/white-papers/h14283-vplex-sap-hana-sg.pdf

Resources (cont.)SCALEIO:Storage configuration for SAP HANA TDI and EMC® SCALEIO® converged infrastructure

NETWORKER:Protecting SAP HANA with EMC networker

Protecting SAP HANA with Data Domain Boost for databases and applications

VIRTUALIZATION:VMware virtualized SAP HANA with EMC storage

EMC INTEGRATION WITH SAP LVM

VCESAP HANA TDI on VCE

SAPSAP HANA on VMware vSphere

SAP HANA Tailored Datacenter Integration (TDI)

VMwareBest Practice and Recommendations for Scale-up deployments of SAP HANA on VMware vSphere

Best Practice and Recommendations for Scale-out deployments of SAP HANA on VMware vSphere


Table of Contents

Executive Summary

Introduction


Design Guide

Roadmap

Conclusion

Next Steps

Resources

http://www.emc.com/collateral/white-papers/h13731-storage-configuration-best-practices-sap-hana.pdf

http://www.emc.com/collateral/white-papers/h13937-saphana-networker-wp.pdf

http://www.emc.com/collateral/technical-documentation/h13902-saphana-ddbda-wp.pdf

http://www.emc.com/collateral/technical-documentation/h14721-vmware-virtualized-sap-hana-emc-storage-sg.pdf

https://www.emc.com/collateral/technical-documentation/h13279-emc-storage-sap-lvm-ig.pdf

http://www.vce.com/asset/documents/sap-hana-tdi-whitepaper.pdf



https://www.vmware.com/files/pdf/SAP_HANA_on_vmware_vSphere_best_practices_guide.pdf

http://www.vmware.com/files/pdf/sap-hana-scale-out-deployments-on-vsphere.pdf

EMC2, EMC, RSA and their respective logos are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. © Copyright 2016 EMC Corporation. All rights reserved. EMC Corporation, Hopkinton, MA 01748-9103

Documents

Making SAP HANA Mainstream in your Datacenter - Dell · PDF fileMaking SAP HANA Mainstream in Your Datacenter ... Online transaction processing ... SAP HANA can either scale up,