Making_SAP_HANA_Mainstream_in_Your_Datacenter_part2_FINAL

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 T O 4 . 1 2
Automation4

Executive Summary
IT 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

Introduction
SAP 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 costs
Manage risk
correctly
Simplify change
Drive more business
innovation
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

Fundamental Principles of
Architecture Design
The 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
Minimum
Technical
Requirements
Business scenario
defines technical
requirements
Business benefits
determine
maximum cost
Acceptable
TCO
Minimum
Technical
Requirements
Business scena
defines technic
requirements
Business benefits
determine
maximum cost
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
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
Extensibility/Flexibility
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.
Extensibility/
Flexibility
Performance
Scalability
Resilience
Automation
SAP
HANA
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
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
Extensibility/
Flexibility
5
P R O 2 . 3 5 0
Performance2
A U T O 4 . 1 2
Automation4
Architect’s Design Guide
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

Designing for Scalability
Enterprise 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
››Extensibility/
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

Designing for Performance
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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 example
Path : /hanamove/log/SCQ (xfs)
IO order : sequential
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
Random
HWCCT
Data
Mostly writes
Reads on startup
or occasional
loading of
cold data
Asynchronous
Block sizes of
4K Up to 64MB
Logs
Mostly writes
Reads only due to
backup jobs
Synchronous
Block sizes of
4K, 16K, 1M
GuaranteedLowLatency
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
16
4
16
4
1024
4
1 10 100 1000
GuaranteedHighThroughput
10%
Storage Performance Drivers
SAP’s Defined KPIs are a Starting Point
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 Recovery
Low
Low
High
High
P E R F O R M A N C E
CRITICALITY
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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,0
53:00,0
187x
LessBatch
Tim
e
00:17,0
07:00,0
00:15,5
30:00,0
00:00,0
• 7x improvement in batch ac
with turning of:
– infrastructure
– VMware
– HANA database
– or of the BPC ABAP code
• 187x improvement after EH
• How much is 0,04% bette
worth in your scenario???
BPC on
Oracle 11.2
BPC on
HANA
Virtualized
BPC10 EHP1
on HANA
Virtualized
BPC10 EHP1
on HANA
Bare Metal
SAP HANA on VMware in Perspective
Run a process in ± 0.04% of the time…It’s all about TCO
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

3 Designing for Resilience
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)
Operation
Resumes
System
Operational
R T ORPO
Design & Prepare Detect Recover Performance Ramp
Sync or
Backup
Operation
Resumes
System
Operational
RTORPO
Sync or
Backup
Operation
Resumes
System
Operational
RTORPO
Sync or
Backup
Time
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 Host
Auto-Failover
HANA System
Replication
VMware HA
Host Restart
with Storage
Replication
Unattended Failover Yes
No, need clustering
software
Yes
No, need clustering
software
Failover Time
Medium, load of
column store for
query execution
Short, with table reload
and log replay options;
Medium, without table
reload option
Medium, full restart
Medium, 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
takeover
No, can be managed
by DRS rules
No, 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Technical
Failure
Metro
Local Geo
Availablility Replication Snapshot Backup Archive
Balance
Factors Influencing Your Data Protection Options
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 OPTIONS
HANA
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)
Network
latency
Network
latency
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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
HANA
System
Replication
Secondary System
Storage
Replication
Remote Standby System
HANAHANA
Replication Options
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

4 Designing for Automation
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 Service
A Journey Towards Simplification and Agility
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 Automation
Easy 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
VNX
File-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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

5 Designing for
Extensibility/Flexibility
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.
Approach
GROWING 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

Converged Infrastructure
The 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

InfrastructurePlatform
functions
SAPPlatform
functions
IQ
Compliance - Protection – Availability - Replication
Compute
Services
S/4, BW
Extended
Store
Persistency
NLS/Data AgingData/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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Scalability
››Performance
››Resilience
››Automation
Flexibility

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 Sizing
S 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

Take a holistic approach
to converged infrastructure.
Consider reinvesting the savings from standardization,
automation, and support into innovation
One 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

STEP 1:
Define technical requirements and sizing
Once 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
››Define technical
requirements
and sizing
››Choose your
server
››Choose your
storage
››Choose your
protection

STEP 2:
Choose your server
SAP 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
requirements
and sizing
››Choose your
server
››Choose your
storage
››Choose your
protection

STEP 3:
Choose your storage
The 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
3
requirements
and sizing
››Choose your
server
››Choose your
storage
››Choose your
protection

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 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.
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 Po
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 Poi
VMAX2
VMAX3
VNX
DDBoost
Data Domain
NetWorker
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
requirements
and sizing
››Choose your
server
››Choose your
storage
››Choose your
protection

STEP 4:
Choose your data protection
It 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 Doma
NetWorker
Recover
MAX2
MAX3
VNX
DDBoost
Data Domain
NetWorker
MAX2
MAX3
remlO
NX
alelO
DDBoost
Data Domain
NetWorker
Recover Point
VMAX2
VMAX3
XtremlO
VNX
ScalelO
DDBoost
Data Domain
NetWorker
Recover Point
MAX2
MAX3
remlO
NX
calelO
DDBoost
Data Domain
NetWorker
Recover Point
Table of
Contents
Executive
Summary
Introduction
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources
requirements
and sizing
››Choose your
server
››Choose your
storage
››Choose your
protection

Conclusion
Enterprises 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 Steps
EMC 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.
Resources
More 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.
EMC
VMAX:
Storage configuration on EMC VMAX and VMAX3 storage systems
Business continuity with EMC Symmetrix VMAX
Business continuity with EMC Symmetrix VMAX3
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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

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
VCE
SAP HANA TDI on VCE
SAP
SAP HANA on VMware vSphere
SAP HANA Tailored Datacenter Integration (TDI)
VMware
Best 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
Architectural
Principles
Design Guide
Roadmap
Conclusion
Next Steps
Resources

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

Making_SAP_HANA_Mainstream_in_Your_Datacenter_part2_FINAL

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Making_SAP_HANA_Mainstream_in_Your_Datacenter_part2_FINAL

Similar to Making_SAP_HANA_Mainstream_in_Your_Datacenter_part2_FINAL (20)

Making_SAP_HANA_Mainstream_in_Your_Datacenter_part2_FINAL