HANA_Technical_Landscape_Preparation_v4

Report
Preparing Your Technical Landscape
for an SAP HANA Installation
Dr. Bjarne Berg
COMERIT
© Copyright 2014
Wellesley Information Services, Inc.
All rights reserved.
In This Session …
This session examines, in detail:
•
The most critical sizing, integration and performance factors you
must address when adopting SAP HANA.
•
Trends amongst hardware vendors for virtualization, cloud, and
hosted systems, including options, requirements, and costs
associated with network, backup, and application servers
•
How the SAP HANA database —uses persistent storage to
provide a fallback, and how fault tolerance, disaster recovery, and
high-availability can be setup for your SAP HANA implementation
2
What We’ll Cover …
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Landscape Deployment Planning
Backup
High Availability
Wrap-up
3
Hardware Options 2014 Onward
4
Example: IBM 3850 X6
5
Hardware Options 2014 Onward
These systems are based on Intel's E7 IvyBridge processors with
15 cores per processor (the old had only 10).
UPDATE: Hitachi Servers and Dell (R920) are now also available
6
Cloud Options 2014 Onward
7
Support Packages
•
As of 2014, SAP introduced the idea of “production verified revisions” to provide indepth testing of all service packs for SAP HANA
•
Based on the planned releases over the next 24 months, customers should adjust their
plans for service packs accordingly
8
Sizing Overview
Depending on the software components there are several sizing
options:
BW system for HANA
1.




BusinessSuite System for HANA
2.



3.
QuickSizer – New implementation only, not migrations
BW Automated Sizing tool in the Migration Cockpit
Rule of Thumb
T-Shirt Sizing
QuickSizer for BusinessSuite on HANA
Automated Sizing tool
Vendor Tools
Standalone HANA System
9
SAP QuickSizer for HANA
There are three versions of the tool for each version of SAP HANA
The QuickSizer for the
Business Suite allows you to
size for specific modules
The second
QuickSizer version
is for SAP HANA
on SAP NetWeaver
BW
The last is for those who want
to use SAP HANA as a
standalone platform for inmemory data (i.e., using SAP
Data Services to load data to)
SAP’s QuickSizer for SAP HANA is available at
http://service.sap.com/quicksizer.
10
SAP QuickSizer for New BW HANA Implementations
If you’re using planning in
SAP NetWeaver BW, enter
the info here. The fields
marked with * are
mandatory.
For H-PLAN-1, enter the
maximum concurrent users
in the USERS field. The S.T.
and E.T. fields are the start
and end times for the
processing.
Enter the estimated number of information consumers (H-BWINFO), business users (H-BW-BUSI.), and experts (H-BW-EXPER).
SAP suggests a ratio of 71%, 26%, and 3% for each user group,
but you can enter your own mix if you have better estimates.
By entering this type of
information, you’ll get
estimates of loads on the
SAP HANA system by time
periods at the end of the
sizing exercise.
11
SAP QuickSizer for New BW HANA Implementations (cont.)
Enter the InfoCube and DSO
information. The max number
of dimensions (DIM) you can
enter for the InfoCube is 13.
The three fixed dimensions of
BW are already included, so
just enter the free
dimensions.
The field KEYF. refers to the
number of key figures in the
fact table of your InfoCube,
while the field COM. is the
estimated compression.
In the INITIAL LOAD field, you enter the number of records in
the existing InfoCube, and in the PERIOD. UPLD field, you enter
the number of records you estimate will be loaded periodically.
If you don’t have better
estimates, a rate of 5 may
serve for the initial sizing
before you refine the
estimates with your hardware
vendor.
12
SAP QuickSizer for HANA — Output
This SAP HANA
sizing example
calls for 1.6TB of
memory.
In this case, SAP HANA for BW will deploy the master data, ABAP
system tables, and row store data on the master node. The other
connected server node(s) will contain the InfoCubes and DSOs.
13
HANA Sizing Tool for Existing BW Implementations
To increase speed, you can suppress
analysis tables with less than 1 MB size.
SAP has released an updated tool that
generates a report significantly better for
sizing SAP BW than using the QuickSizer. This
tool should be used by all existing BW
implementations for sizing (QuickSizer is only
for new implementations).
This program takes into consideration existing
database, table types, and includes the effects
of non-active data on the HANA system.
The higher precision you run the estimate
at, the longer the program is going to run.
With 12 parallel processors and 10TB database,
it is not unusual to see 30-70 minutes runtime
14
SAP BW on HANA Automated Sizing Tool
Since timeouts are common when
running the sizing program, you can
temporarily change the parameter in
rdisp/max_wprun_time to 0 in BW
transaction RZ11. Finally, you estimate
the growth for the system as a
percentage, or as absolute growth.
The output is stored in the file you
specified and the file can now be
emailed to hardware vendors for sizing
input and hardware selection.
This program is referenced in SAP Notes 1909597 and 1736976 on the Service Marketplace15
Sizing for BusinessSuite on HANA
SAP has created a program for sizing HANA for BusinessSuite:
This should be used for all
HANA migration projects of
ERP/ECC/BusinessSuite
16
Sizing for BusinessSuite on HANA
Some Vendors have also created their own sizing programs, that also include
hardware prices.
17
QuickSizer for BusinessSuite on HANA
For New BusinessSuite implementations you can use QuickSizer
and send the results to SAP for further processing
18
QuickSizer for BusinessSuite on HANA
This is the input screen where you
enter the number of expected
transaction by module. You are also
asked to enter estimated changes
and new records as well as operating
times of your system
Here you get the size in SAPS as well
as memory and disk requirements
19
Sizing a Standalone HANA System - Output
This is the input screen
Here you get the size in
SAPS as well as memory
and disk requirements
20
Rule-of-Thumb Approach to Sizing HANA — Memory
•
Memory can be estimated by taking the current system size and running the
programs in “get_size.zip” in SAP Note 1637145 to get row and column store sizes
for your system
Memory = 50GB +
[ (rowstore tables footprint / 1.5) +
(colstore tables footprint * 2 / 4) ] * Existing DB Compression
•
The 50GB is for HANA services and caches. The 1.5 is the compression expected
for rowstore tables and the 4 is the compression expected for column store tables.
The 2-factor refers to the space needed for runtime objects and temporary result
sets in HANA. Finally, the term “existing DB compression” is to account for any
compression already done in your system (if any).
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
21
Rule-of-Thumb Approach to Sizing HANA — Disk
•
The next item you need is disk space, which can be estimated by the
following:
Disk for persistence layer = 4 Memory
Disk for the log = 1 Memory
•
In this example, you need 4 x 710GB disk for the persistence layer
and about 710GB for the logs. This equals around 3.5TB (don’t worry,
disk space of this size is now almost “cheap”).
•
The persistence layer is the disk that keeps the system secure and
provides for redundancy if there are any memory failures, so it’s
important not to underestimate this.
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
22
Rule-of-Thumb Approach to Sizing HANA — CPU
•
The CPUs are based on the number of cores that you include.
For example, 10 core CPUs now exist (depending on when you
bought your system).
CPU = 0.2 CPU cores per active user
•
If you have a single node with 4 x 10 cores, you will have 40
cores and can handle 200 active users on that hardware node,
and quite a larger number of named users.
Remember, these are quick rules of thumb, so don’t rely
on it for finalized budgeting and hardware purchases
23
A T-Shirt Model for Sizing HANA on BW
A T-shirt model is a quick
way to get some basic ideas
on what a system may look
like
While very inaccurate for
sizing, it provides basic
information for those just
starting to consider SAP
HANA
Data Compress
ion (from)
Working
Memory
Processors
SAS/SSD
(for data)
Replication
Speed (per
hour)
Extra
Large
(XXL)
7000–100,000
GB
3072 GB
12+ Intel
E7 2.4 Ghz
10+ TB
20+ GB
Very
Large
(XL)
3500–7000GB
2048 GB
8+ Intel E7
2.4 Ghz
5 – 10 TB
20+ GB
Large (L)
2000–3500GB
1024GB
4 x Intel
E7 2.4 Ghz
4 - 5 TB
5–20GB
Medium
(M)
1250–
2000GB
512GB
4 x Intel
E7 2.0+
Ghz
2048GB
5–20 GB
Small (S)
500–
1250GB
256GB
2 x Intel
E7 2.0+
Ghz
1024GB
5GB
Extra
Small
(XS)
256–
500GB
128GB
2 x Intel
E7 2.0+
Ghz
1024GB
5GB
to 20+ TB
(multi node)
(multi node)
The number of processors are largely driven by the number of users and usage
patterns. Serious consideration should be made before buying hardware.
24
Summary of HANA Sizing Approaches
Approach
T-Shirt Sizing
Rule of Thumb
SAP QuickSizer
Sizing for programs
•
Quality of Estimate
 Sort of “OK”
 Better
 Much better (new implementations only)
 Excellent (for existing BW systems)
Effort Required
Very Low
Low
High
Moderate/Low
Work with your preferred vendor before ordering your hardware or
finalizing your budgets
SAP Note 1736976 (ABAP report to help with BW on HANA Sizing)
SAP Note 1909597 (SAP NetWeaver BW Migration Cockpit for SAP HANA)
SAP Note 1729988 (SAP BW Checklist for Migration),
SAP Note 11855041 (Sizing the Master node)
25
What We’ll Cover …
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Landscape Deployment Planning
Backup
High Availability
Wrap-up
26
1. Lessons Learned: Buy Hardware Early
1.
The typical lead time for the basic HANA
appliances is as little as 4-8 weeks
2.
However, for large scale environments, or multinode environments, the lead times can sometimes
be as long as 10-14 weeks
3.
This is particularly true for virtualized systems
managed by a third-party who has to set them up,
configure backup, and learn the new technology
Get a small team on site early for planning, budgeting, and
sizing; and hold off staffing all team members from the
business until you get a confirmed hardware delivery date
27
2. Lessons Learned: Get the Right Team Members
1.
While there are many with basic certifications in
HANA, the pool of qualified experienced resources
is limited
2.
Great HANA resources are most likely working on
another project already
3.
So, if you want the best, be prepared to give your
implementation partner several weeks lead time
Do you want “who is available” or “who should be
available” on your project? Be prepared to give your
implementation partner longer lead times than usual.
28
3. Lessons Learned: Include Training for your Staff
1.
There are a lot of “myths” and beliefs about HANA
that you have to address early
2.
Before you start the project, make sure your
implementation partner has a formal written training
plan on how they will provide knowledge transfer
3.
Include your support staff and Basis people in all
project discussions from the first planning session
Many are “fearful” of a new technology and are unsure how this will change their
work. You should provide real demos and workshops early so that everyone
knows what is happening and how HANA will change their day-to-day jobs.
29
4. Lessons Learned: Hardware Sizing Should Include Growth
1.
Some customers forget that sizing would be for 3
years out and not based on current system size
alone
2.
You should have a sizing estimate that includes new
projects, data growth, and data retention policies, as
well as periodic scheduled clean up activities
Funding for hardware is sometimes easier in a project mode,
and many companies plan for 30-50% more capacity as part
of the initial rollout if they can afford it
30
5. Lessons Learned: “Master-Node” Size
1.
Some hardware vendors want to maximize the number
of processes available to the users. They can do this
by using multiple smaller nodes with many processors
in each.
2.
The drawback is that all of your row and master data
stores may not fit on the small node as you grow.
Pay very careful attention to the row-stores sizes and the
master data growth when buying hardware. You don’t
want to have to upgrade shortly after go-live.
31
6. Lessons Learned: Create an Ecosystem of Experts
1.
Having access to the best and brightest within
SAP, consulting firms, and industry experts is
key when issues or questions arise
2.
These people are very busy and are often
engaged on many projects as “supporters”
Formally assign a team of 2-3 experts to come in and meet with your
team a few times during the project planning and execution. Make sure
these project advisors are hands-on and that they can act as technical
go-to resources for your team if questions arise.
32
7. Lessons Learned: Think BIG
1.
A HANA implementation should not be treated as a
replacement project. It is an enabler …
2.
Plan ahead on what you are going to do with the
new technology, e.g., mobile, forecasting,
planning, BI dashboards, customer and vendor
facing analytics, market basket analysis,
stratification, data visualization, etc.
Early in the project create a 2-3 year strategic plan that demonstrates
to the leadership what you are going to do with this new technology.
Present it as new capabilities not just how fast it is …
33
8. Lessons Learned: Plan for Reporting and System Consolidation
1.
2.
After go-live you should have planned for how
you are going to migrate all reporting and
management analytics on to HANA and away from
datamarts and standalone expensive systems that
are not integrated into the long-term vision
You will most likely have to do some “selling” to
your fellow employees and be prepared to give them
“free access” to your HANA system
HANA is not just for BW or Business Suite. It is an enterprise
platform for integrated analytical and data processing. You can give
developers access to your system and they can build their own Agile
marts inside HANA, even if they don’t want to use BW.
34
9. Lessons Learned: Near-Line Storage Can Save Millions
1.
Removing data that is not needed on a daily basis from
your system and placing it on near-line storage instead
of in-memory can save you millions.
2.
In one project a customer took his system from 112TB
to 38TB by simply moving data to near-line storage
(NLS)
3.
An Asian firm took a 3.8TB BW system to “only” 900GB
after cleanup and an NLS implementation
There are many NLS solutions available that can save you big bucks by
reducing the need for multi-node, multi-terabyte HANA systems. Take a serious
look at SAP IQ solution for NLS. It is tightly linked with HANA already.
35
10. Lessons Learned: Save Money with MCOD and MCOS
1.
You may not need separate hardware for sandbox and development
environments
2.
Using Multiple Components One Database (MCOD) and/ or Multiple
components One System (MCOS) you can simplify the number of hardware
environments you need
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
SAP NetWeaver BW on SAP HANA
SAP Finance and Controlling Accelerator for the material ledger
ERP operational reporting with SAP HANA
SAP Finance and Controlling Accelerator: Production Cost Planning
SAP Rapid Marts
SAP COPA Accelerator
SAP Operational Process Intelligence
SAP Cash Forecasting
SAP Application Accelerator / Suite Accelerator
Smart Meter Analytics
In addition to custom developed datamarts, all items above can
run in an MCOD setup (see SAP Note 1666670 for more details)
36
What We’ll Cover
•
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up
37
Landscape Deployment Planning
Virtualization
MCOS
MCOD
Technical
Co-Deployment
HANA DBs
Multiple
Multiple
One
One
DB Schema
Multiple
Multiple
Multiple
One
Availability
Supported for
DEV & QA
systems
Supported for
DEV & QA
systems
Defined by:
White List
1661202 for BW
White List
1826100 for Suite
Business Suite
components
SCM and/or
SCM codeployed with
ERP
Deployment
Scenario
38
Landscape Deployment Planning - Virtualization (on premise)
Share hardware resources for multiple Suite systems and HANA instances with
virtualization techniques. Virtualization technology separates multiple OS images
each containing one HANA DB.
• n x Virtualized Appliances
• n x HANA DB
• n x DB Schema
• n x Applications
Strengths
•
•
•
•
•
Only one HANA system needed
Resource mgmt per virtual instance possible (RAM, CPU, Storage)
Easy scalability
Different Server Level Agreements per virtual machine possible
Independent deployment & maintenance per instance (OS, HANA)
Weaknesses
• Performance impact
• Virtualization overhead
39
Landscape Deployment Planning
•
•
•
•
•
One database schema per database
Separate virtual machine and OS
Separate SAP HANA databases per SAP system
Shared hardware and storage
Currently supports VMware vSphere 5.1
Usage Scenarios
• Non-production systems
• Single-node SAP HANA databases up to 1 TB
See SAP note 1788665.
40
Multiple Components One System (MCOS)
Share hardware for HANA among multiple Suite system to reduce TCO
•
•
•
•
1 x Appliance
n x HANA DB
n x DB Schema
n x Applications
Strengths
• Only one HANA system and one OS required
• HANA software can be individually maintained per DB instance
• Dedicated memory assignment per instance
Weaknesses
• Shared HANA hardware – risk of performance issues since no dedicated CPU
assignment per instance
• No separate Service Level Agreements on database level
SAP currently does not support MCOS configuration on a production system (note 1681092).
41
Multiple Components One Database (MCOD)
Provides the ability to install several components independently on a single database.
•
•
•
•
1 x Appliance
1 x HANA DB
n x DB Schema
n x Applications
Strengths
• Versatility through components and only one HANA instance necessary
• Cross schema reporting supported and separate upgrades possible
• Different operating systems and databases
• Highest scalability possible
Weaknesses
• Maintaining different operating systems and databases
• Shared HANA software version and maintenance processes
• Risk of performance issues - lack of resource management capabilities
• Complex high availability solutions
• Synchronizing backup and restore
42
Multiple Components One Database (MCOD)
•
•
•
•
Multiple database schemas per database
Shared SAP HANA database
Dedicated application servers per application
Shared hardware, OS and storage pool
Usage Scenarios
• Non-production systems
• Production systems for applications on whitelists and custom data marts
• Not multiple BW production systems
See SAP notes:
1661202 – HANA MCOD scenario whitelist
1826100 – SoH MCOD scenario whitelist
1666670 – BW specific considerations
43
Classical Technical Co-Deployment
Appliance approach for optimal performance.
• No additional system required and a reduction of operations effort
• Cross application reporting possible
•
•
•
•
1 x Appliance
1 x HANA DB
1 x DB Schema
1 x Application (e.g. ERP, CRM, or BW)
Strengths
•
•
•
•
•
•
Coordinated start-stop functionality
Reduced operation exertion for DB/OS/Backup/Basis
Multiple application servers can be shared
Simplified application landscape setup, deployment, and maintenance
Option to scale out into separate deployment
Reduced TCO on application level
Weaknesses
• Restrictive enhancement package dependencies
Application specific middleware (CIF, BDOC) still being used. Not yet available for CRM.
44
Landscape Deployment Planning
Classical Technical Co-Deployment
• One SAP HANA database and one database schema
• One AS ABAP application server/SID
• Available for SRM and SCM as ERP add-on
Usage Scenarios
• Production and non-production systems
• Can be combined with Virtualization or MCOS
45
What We’ll Cover
•
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up
46
Backup
• Supports synchronous backup between production system and
backup storage
• Alerts can be setup to monitor whether backups are being done as
expected
• Two primary methods of backing up:
• Traditional File
• BACKINT API for third party vendors
47
•
Backup
There are 4 basepath options for traditional file backups in HANA
•
•
•
•
Basepath data backup – Standard backups to external mount point
Basepath data volumes – Permanent location for data volumes
Basepath log backup – External mount point for logs segment to be copied
Basepath log volumes – Permanent location for log volumes
• IBM offers a backup management solution
called Tivoli Storage Manager
• SAP provides a script in SAP Note 1651055 to
help clean up log files
• Many backup features are now automated
including removal of log segments after backup
These basepath options are available in the Configuration tab in HANA Studio
48
Standby Systems and Backup Monitoring
• It is possible to keep a “warm” standby system that is ready to come
online in the event of a failure
• Hosts can also be on standby in the event of host issues
• HANA includes a service auto-start that restarts any service that may fail
Alerts can be set to monitor
If the backups are being successful
inside the admin console under the
Alerts tab
Standby host can provide
fault-tolerance recovery
49
What We’ll Cover
•
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up
50
High Availability (HA)
• SAP HANA supports HA and recovery measures ranging
from faults and software errors, to disasters that decommission an entire data center
• HA can be achieved by eliminating single points of failure (fault tolerance)
• Providing the ability to rapidly resume operations after a system outage with minimal
business loss (fault resilience).
• The SAP HANA database provides several features in support of high availability, one
of which is service auto-restart
• In the event of a failure or an intentional intervention by an administrator that
disables one of the SAP HANA services, the SAP HANA service auto-restart function
automatically detects the failure and restarts the stopped service process
The number of standby servers defined during installation cannot
subsequently be reduced. Standby servers can be added after installation.
51
High Availability
• Additional SAP HANA appliances used in standby mode for failover
• Capability to assign up to three master servers as the name server (one
is selected as the active server)
• Active server assigned master index server
• If active master name server fails, the systems restores itself to
available standby master
High Availability is a set of techniques, engineering practices and
design principles for Business Continuity
52
Scale out – High Availability
High Availability Configuration
• N active servers in one cluster
• M standby server(s) in one cluster
• Shared file system for all servers
Failover
• Server X fails
• Server N+1 reads indexes from shared storage and
connects to logical connection of server X
Source: SAP AG 2014
SAP HANA cold standby host
•
•
•
Standby host is kept ready for the event that a
failover situation occurs during production operation
Standby host is not used for database processing
All the database processes run on the standby host,
but they are idle and do not allow SQL connections
Source: SAP AG 2014
53
What We’ll Cover
•
•
•
•
•
•
•
Hardware Sizing, Planning, and The Cloud
Top 10 Lessons Learned from SAP HANA Implementations
Hardware Trends
Landscape Deployment Planning
Backup
High Availability
Wrap-up
54
7 Key Points to Take Home
•
There are programs to do pre-readiness checks for an ERP and BW
system for migration to HANA
•
A BW Migration Cockpit is now available to assist in the tasks
•
While one is more common, there are actually four possible approaches
to the HANA migration project
•
There are currently seven different certified HANA vendors and many
options for small, medium, and large systems — Make sure you get a
competitive bid
•
Budgeting should include HANA training and system cleanup, as well as
support staff required or reorganized
•
Most HANA projects can be done in a matter of weeks
•
Only extremely large systems may require 4-7 months
55
Where to Find More Information
•
•
•
•
•
https://www.sap-press.com/sap-hana_3687
Dr. Bjarne Berg and Penny Silvia, SAP HANA: An Introduction (3rd
edition) SAP PRESS, 2014).
www.saphana.com/welcome
 SAP’s main page for all SAP HANA-related information
www.saphana.com/community/try
 SAP HANA demos
http://scn.sap.com/community/netweaver-bw-hana
 SAP NetWeaver BW Powered by SAP HANA Community
56
Your Turn!
How to contact me:
Dr. Berg
[email protected]
57
Disclaimer
SAP, R/3, mySAP, mySAP.com, SAP NetWeaver®, Duet®, PartnerEdge, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and
service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by SAP.
58

similar documents