Preparing Your Technical Landscape for an SAP HANA Installation

Preparing Your Technical Landscape for an SAP HANA InstallationDr. Bjarne BergCOMERIT Copyright 2014Wellesley 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 serversHow 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#What is covered in this session? Advanced tips and trick in Query designer and BEx AnalyzerThe advanced tips and tricks are explained using business scenariosOverlooked and obscure features are brought to limelightLots of demos to explain BExGetData and other topicsWhat Well Cover Hardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsLandscape Deployment PlanningBackup High AvailabilityWrap-up#Lets begin with features of Query DesignerHardware Options 2014 Onward

#Example: IBM 3850 X6

#Hardware Options 2014 OnwardThese 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

#Cloud Options 2014 Onward

#Support PackagesAs of 2014, SAP introduced the idea of production verified revisions to provide in-depth testing of all service packs for SAP HANABased on the planned releases over the next 24 months, customers should adjust their plans for service packs accordingly

#Sizing OverviewDepending on the software components there are several sizing options:

BW system for HANAQuickSizer New implementation only, not migrationsBW Automated Sizing tool in the Migration CockpitRule of ThumbT-Shirt Sizing

BusinessSuite System for HANAQuickSizer for BusinessSuite on HANAAutomated Sizing tool Vendor Tools

Standalone HANA System

#

SAP QuickSizer for HANAThere are three versions of the tool for each version of SAP HANASAPs QuickSizer for SAP HANA is available at http://service.sap.com/quicksizer. The last is for those who want to use SAP HANA as a standalone platform for in-memory data (i.e., using SAP Data Services to load data to)The second QuickSizer version is for SAP HANA on SAP NetWeaver BWThe QuickSizer for the Business Suite allows you to size for specific modules

#

If youre 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. By entering this type of information, youll get estimates of loads on the SAP HANA system by time periods at the end of the sizing exercise.Enter the estimated number of information consumers (H-BW-INFO), 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. SAP QuickSizer for New BW HANA Implementations#

SAP QuickSizer for New BW HANA Implementations (cont.)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. 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. If you dont have better estimates, a rate of 5 may serve for the initial sizing before you refine the estimates with your hardware vendor.#

This SAP HANA sizing example calls for 1.6TB of memory. SAP QuickSizer for HANA OutputIn 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.

#

HANA Sizing Tool for Existing BW ImplementationsSAP 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. To increase speed, you can suppress analysis tables with less than 1 MB size. With 12 parallel processors and 10TB database, it is not unusual to see 30-70 minutes runtime#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.This program is referenced in SAP Notes 1909597 and 1736976 on the Service MarketplaceThe output is stored in the file you specified and the file can now be emailed to hardware vendors for sizing input and hardware selection.

#Sizing for BusinessSuite on HANASAP has created a program for sizing HANA for BusinessSuite:This should be used for all HANA migration projects of ERP/ECC/BusinessSuite

#Sizing for BusinessSuite on HANASome Vendors have also created their own sizing programs, that also include hardware prices.

#QuickSizer for BusinessSuite on HANA

For New BusinessSuite implementations you can use QuickSizer and send the results to SAP for further processing

#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 systemHere you get the size in SAPS as well as memory and disk requirements#

Sizing a Standalone HANA System - Output

This is the input screenHere you get the size in SAPS as well as memory and disk requirements#Rule-of-Thumb Approach to Sizing HANA MemoryMemory 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

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). Memory = 50GB + [ (rowstore tables footprint / 1.5) + (colstore tables footprint * 2 / 4) ] * Existing DB CompressionRemember, these are quick rules of thumb, so dont rely on it for finalized budgeting and hardware purchases

#Rule-of-Thumb Approach to Sizing HANA DiskThe next item you need is disk space, which can be estimated by the following:

In this example, you need 4 x 710GB disk for the persistence layer and about 710GB for the logs. This equals around 3.5TB (dont 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 its important not to underestimate this.

Disk for persistence layer = 4 MemoryDisk for the log = 1 MemoryRemember, these are quick rules of thumb, so dont rely on it for finalized budgeting and hardware purchases

#Rule-of-Thumb Approach to Sizing HANA CPUThe 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).

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.

CPU = 0.2 CPU cores per active user

Remember, these are quick rules of thumb, so dont rely on it for finalized budgeting and hardware purchases

#A T-Shirt Model for Sizing HANA on BWA 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

The number of processors are largely driven by the number of users and usage patterns. Serious consideration should be made before buying hardware.

#Summary of HANA Sizing ApproachesApproach Quality of EstimateEffort RequiredT-Shirt Sizing Sort of OKVery LowRule of Thumb Better LowSAP QuickSizer Much better (new implementations only)HighSizing for programs Excellent (for existing BW systems)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)

#What Well Cover Hardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsLandscape Deployment PlanningBackup High AvailabilityWrap-up#Lets begin with features of Query Designer1. Lessons Learned: Buy Hardware EarlyThe typical lead time for the basic HANA appliances is as little as 4-8 weeks However, for large scale environments, or multi-node environments, the lead times can sometimes be as long as 10-14 weeksThis 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

#2. Lessons Learned: Get the Right Team MembersWhile there are many with basic certifications in HANA, the pool of qualified experienced resources is limitedGreat HANA resources are most likely working on another project alreadySo, 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.

#3. Lessons Learned: Include Training for your StaffThere are a lot of myths and beliefs about HANA that you have to address earlyBefore you start the project, make sure your implementation partner has a formal written training plan on how they will provide knowledge transferInclude your support staff and Basis people in all project discussions from the first planning sessionMany 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.

#4. Lessons Learned: Hardware Sizing Should Include GrowthSome customers forget that sizing would be for 3 years out and not based on current system size aloneYou should have a sizing estimate that includes new projects, data growth, and data retention policies, as well as periodic scheduled clean up activitiesFunding 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

#5. Lessons Learned: Master-Node SizeSome 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.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 dont want to have to upgrade shortly after go-live.

#6. Lessons Learned: Create an Ecosystem of ExpertsHaving access to the best and brightest within SAP, consulting firms, and industry experts is key when issues or questions ariseThese people are very busy and are often engaged on many projects as supportersFormally 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.

#7. Lessons Learned: Think BIGA HANA implementation should not be treated as a replacement project. It is an enabler 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

#8. Lessons Learned: Plan for Reporting and System ConsolidationAfter 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 visionYou will most likely have to do some selling to your fellow employees and be prepared to give them free access to your HANA systemHANA 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 dont want to use BW.

#9. Lessons Learned: Near-Line Storage Can Save MillionsRemoving 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.In one project a customer took his system from 112TB to 38TB by simply moving data to near-line storage (NLS)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.

#10. Lessons Learned: Save Money with MCOD and MCOSYou may not need separate hardware for sandbox and development environmentsUsing Multiple Components One Database (MCOD) and/ or Multiple components One System (MCOS) you can simplify the number of hardware environments you needSAP NetWeaver BW on SAP HANASAP Finance and Controlling Accelerator for the material ledgerERP operational reporting with SAP HANASAP Finance and Controlling Accelerator: Production Cost PlanningSAP Rapid MartsSAP COPA AcceleratorSAP Operational Process IntelligenceSAP Cash ForecastingSAP Application Accelerator / Suite AcceleratorSmart Meter Analytics

In addition to custom developed datamarts, all items above can run in an MCOD setup (see SAP Note 1666670 for more details)

#What Well CoverHardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsHardware TrendsLandscape Deployment PlanningBackup High AvailabilityWrap-up#Landscape Deployment PlanningVirtualization MCOS MCOD Technical Co-Deployment

DeploymentScenarioHANA DBsMultipleMultipleOneOneDB SchemaMultipleMultipleMultipleOneAvailabilitySupported for DEV & QA systemsSupported for DEV & QA systemsDefined by:White List 1661202 for BWWhite List 1826100 for SuiteBusiness Suite components SCM and/or SCM co-deployed with ERP#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 Appliancesn x HANA DBn x DB Scheman x Applications

StrengthsOnly one HANA system neededResource mgmt per virtual instance possible (RAM, CPU, Storage)Easy scalabilityDifferent Server Level Agreements per virtual machine possibleIndependent deployment & maintenance per instance (OS, HANA)

WeaknessesPerformance impactVirtualization overhead#Landscape Deployment PlanningOne database schema per databaseSeparate virtual machine and OSSeparate SAP HANA databases per SAP systemShared hardware and storageCurrently supports VMware vSphere 5.1

Usage ScenariosNon-production systemsSingle-node SAP HANA databases up to 1 TBSee SAP note 1788665.

#Multiple Components One System (MCOS)Share hardware for HANA among multiple Suite system to reduce TCO1 x Appliancen x HANA DBn x DB Scheman x Applications

StrengthsOnly one HANA system and one OS requiredHANA software can be individually maintained per DB instanceDedicated memory assignment per instance

WeaknessesShared HANA hardware risk of performance issues since no dedicated CPU assignment per instanceNo separate Service Level Agreements on database level

SAP currently does not support MCOS configuration on a production system (note 1681092).

#Multiple Components One Database (MCOD)Provides the ability to install several components independently on a single database.

1 x Appliance1 x HANA DBn x DB Scheman x ApplicationsStrengthsVersatility through components and only one HANA instance necessaryCross schema reporting supported and separate upgrades possibleDifferent operating systems and databasesHighest scalability possible

WeaknessesMaintaining different operating systems and databasesShared HANA software version and maintenance processesRisk of performance issues - lack of resource management capabilitiesComplex high availability solutionsSynchronizing backup and restore

#Multiple Components One Database (MCOD)Multiple database schemas per databaseShared SAP HANA databaseDedicated application servers per applicationShared hardware, OS and storage pool

Usage Scenarios

Non-production systemsProduction systems for applications on whitelists and custom data martsNot multiple BW production systemsSee SAP notes: 1661202 HANA MCOD scenario whitelist1826100 SoH MCOD scenario whitelist1666670 BW specific considerations

#Classical Technical Co-DeploymentAppliance approach for optimal performance.No additional system required and a reduction of operations effortCross application reporting possible

1 x Appliance1 x HANA DB1 x DB Schema1 x Application (e.g. ERP, CRM, or BW)

StrengthsCoordinated start-stop functionalityReduced operation exertion for DB/OS/Backup/BasisMultiple application servers can be sharedSimplified application landscape setup, deployment, and maintenanceOption to scale out into separate deploymentReduced TCO on application level

WeaknessesRestrictive enhancement package dependenciesApplication specific middleware (CIF, BDOC) still being used. Not yet available for CRM.#Landscape Deployment PlanningClassical Technical Co-Deployment

One SAP HANA database and one database schemaOne AS ABAP application server/SIDAvailable for SRM and SCM as ERP add-on

Usage Scenarios

Production and non-production systemsCan be combined with Virtualization or MCOS

#What Well CoverHardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsHardware TrendsLandscape Deployment PlanningBackup High AvailabilityWrap-up#BackupSupports 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 FileBACKINT API for third party vendors

#BackupThere are 4 basepath options for traditional file backups in HANABasepath data backup Standard backups to external mount pointBasepath data volumes Permanent location for data volumesBasepath log backup External mount point for logs segment to be copied Basepath log volumes Permanent location for log volumes

These basepath options are available in the Configuration tab in HANA Studio

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#Standby Systems and Backup MonitoringIt is possible to keep a warm standby system that is ready to come online in the event of a failureHosts can also be on standby in the event of host issuesHANA 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

#What Well CoverHardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsHardware TrendsLandscape Deployment PlanningBackup High AvailabilityWrap-up#High Availability (HA)SAP HANA supports HA and recovery measures ranging from faults and software errors, to disasters that decommission an entire data centerHA 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-restartIn 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.

#High AvailabilityAdditional 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 masterHigh Availability is a set of techniques, engineering practices and design principles for Business Continuity

#Scale out High Availability

High Availability ConfigurationN active servers in one clusterM standby server(s) in one clusterShared file system for all servers

FailoverServer X failsServer N+1 reads indexes from shared storage and connects to logical connection of server X

SAP HANA cold standby hostStandby host is kept ready for the event that a failover situation occurs during production operationStandby host is not used for database processingAll the database processes run on the standby host, but they are idle and do not allow SQL connections

Source: SAP AG 2014Source: SAP AG 2014#What Well CoverHardware Sizing, Planning, and The CloudTop 10 Lessons Learned from SAP HANA ImplementationsHardware TrendsLandscape Deployment PlanningBackup High AvailabilityWrap-up#7 Key Points to Take HomeThere are programs to do pre-readiness checks for an ERP and BW system for migration to HANAA BW Migration Cockpit is now available to assist in the tasksWhile one is more common, there are actually four possible approaches to the HANA migration projectThere are currently seven different certified HANA vendors and many options for small, medium, and large systems Make sure you get a competitive bidBudgeting should include HANA training and system cleanup, as well as support staff required or reorganizedMost HANA projects can be done in a matter of weeksOnly extremely large systems may require 4-7 months#Where to Find More Informationhttps://www.sap-press.com/sap-hana_3687Dr. Bjarne Berg and Penny Silvia, SAP HANA: An Introduction (3rd edition) SAP PRESS, 2014).www.saphana.com/welcome SAPs main page for all SAP HANA-related informationwww.saphana.com/community/try SAP HANA demoshttp://scn.sap.com/community/netweaver-bw-hana SAP NetWeaver BW Powered by SAP HANA Community #Your Turn!How to contact me:Dr. Bergbberg@comerit.com

#57DisclaimerSAP, 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.#