Cost/Benefit Case for SAP HANA Deployment

Transcription

1 February 2013 MANAGEMENT BRIEF Cost/Benefit Case for SAP HANA Deployment Comparing Costs and Effectiveness of IBM and Competitive Solutions International Technology Group 609 Pacific Avenue, Suite 102 Santa Cruz, California Telephone: Website: ITGforInfo.com

2 TABLE OF CONTENTS EXECUTIVE SUMMARY 1 SOLUTIONS 5 SAP HANA 5 Overview 5 Applications 5 Evolution 6 Appliances 7 Overview 7 Single-node Configurations 7 Scale-out Configurations 9 Performance Issues 10 High Availability and Disaster Recovery 11 DETAILED DATA 13 Basis of Calculations 13 Cost Breakdowns 13 List of Figures 1. Three-year Appliance Costs for SAP HANA Deployment Averages for All Scale-out Configurations 2 2. Largest SAP HANA Test Systems 3 3. SAP HANA Applications 5 4. Planned SAP HANA Enhancements 6 5. SAP HANA Single-Node Appliance Configurations 8 6. SAP HANA Scale-Out Appliance Configurations 9 7. SAN-based and IBM GPFS Configurations HP Disaster Recovery Solution for HP AppSystems for SAP HANA Cost Breakdowns (1) Cost Breakdowns (2) 14 Copyright 2013 by the International Technology Group. All rights reserved. Material, in whole or part, contained in this document may not be reproduced or distributed by any means or in any form, including original, without the prior written permission of the International Technology Group (ITG). Information has been obtained from sources assumed to be reliable and reflects conclusions at the time. This document was developed with International Business Machines Corporation (IBM) funding. Although the document may utilize publicly available material from various sources, including IBM, it does not necessarily reflect the positions of such sources on the issues addressed in this document. Material contained and conclusions presented in this document are subject to change without notice. All warranties as to the accuracy, completeness or adequacy of such material are disclaimed. There shall be no liability for errors, omissions or inadequacies in the material contained in this document or for interpretations thereof. Trademarks included in this document are the property of their respective owners.

3 EXECUTIVE SUMMARY In barely two years, SAP HANA has gone from an ambitious design to a major force in the IT world. SAP investments in architecture and technology, and in creating an ecosystem of applications, skills and third-party support, have encouraged rapid adoption worldwide. HANA deployment is at an early stage in most organizations. In January 2013, SAP reported that it had 1000 customers, with at least 200 in production and approximately 500 projects underway. Customer experiences have been overwhelmingly positive. Among 23 HANA users surveyed for this report, for example, improvements in query response and/or report generation throughput that ranged from 20 to more than 800 times were reported. Data loading was accelerated by 3 to more than 10 times. Users expected that performance would increase as tuning and workload management improved. A further result should be highlighted. In 17 cases (74 percent), users planned or expected to add additional HANA applications. In five cases, worldwide deployments were planned following successful experiences in individual business units or local subsidiaries. HANA analytical usage will clearly expand, and will increasingly extend to new applications incorporating big data content. The SAP portfolio of transactional systems will also progressively move to this platform. Availability of SAP Business Suite 7 for HANA was announced in January Realizing the potential of HANA will mean addressing many business and technical challenges. One of these challenges which is the subject of this report will be to put in place appliance infrastructures that are capable of handling massive, sustained growth in workloads and data volumes over multi-year periods. There are currently seven SAP-certified appliance vendors Cisco Systems, Dell, Fujitsu, Hewlett- Packard (HP), Hitachi Data Systems (HDS), IBM and NEC. All offer single-node configurations, while only Cisco, Dell, Fujitsu, HP and IBM offer scale-out solutions. There is a striking disparity between scale-out architectures. With the exception of IBM, all scale-out vendors offer variants of Network File System (NFS) and storage area networks (SANs), including external disk arrays. IBM employs General Parallel File System (GPFS), which offers higher performance and does not require SANs or disk arrays. There are implications in three main areas: 1. Costs of ownership. Three-year costs of ownership are lower for use of the GPFS-based IBM Systems solution for SAP HANA. For 4-, 8-, 12- and 16-node configurations, costs for the IBM solution average 27 percent less than those for HP AppSystems for SAP HANA, and 21 and 23 percent less than those for Cisco Systems equivalents using EMC VNX and NetApp FAS disk arrays respectively. Figure 1 illustrates these results. Costs include hardware, maintenance, licenses and support for vendor-supplied software tools, and facilities including data center occupancy and power consumption. Costs of SAP software and implementation are not included. International Technology Group 1

4 IBM Systems solucon 1, Cisco & EMC 1, Cisco & NetApp 1, HP AppSystems 1, $ Thousands Servers Storage Infrastructure FaciliCes Figure 1: Three-year Appliance Costs for SAP HANA Deployment Averages for All Scale-out Configurations In this presentation, infrastructure costs are for switches, racks and related components. Calculations are based on configurations as described by vendors, and on discounted prices for individual components. Actual vendor prices may differ in practice. Costs for Cisco and HP systems, which are blade-based, include chassis and fabrics. Costs for IBM systems are for System x3950-based rack mount servers equipped with internal storage, and include GPFS licenses and support. Additional information on configurations and costs may be found in the Detailed Data section of this report. 2. Performance and scalability. Because of the early state of HANA deployment, potential differences between appliances in performance and scalability may not yet be visible. However, they will become a great deal clearer as systems expand. The main challenge vendors have faced is that HANA scale-out architecture requires technologies that are closer to the supercomputing world than to conventional commercial IT environments. IBM GPFS was designed as a parallel file system, and has been widely employed in supercomputing for more than a decade. It has shown near-linear scalability in extremely large configurations systems with 1,000+ nodes are common, and the largest exceed 5,000 nodes. Data volumes often run to hundreds of terabytes, and petabyte-scale systems have been deployed. NFS variants have shown more limited results. For example, academic users have reported that GPFS outperforms conventional NFS by 5 to 10 times, while disparities between Multi Path File System (MPFS) employed in Cisco scale-out configurations using EMC disk arrays and parallel NFS (pnfs) appear to be in the two to four times range. It can be expected that, in large SAN configurations, disk array and switching latencies will cause further performance degradation relative to GPFS. In terms of scalability, all vendors offer SAP-certified 16-node scale-out configurations although there is little production experience with these and Cisco claims that 48-node configurations may be certified on request. However, IBM servers and GPFS formed the basis of the three highest-performing HANA systems demonstrated to date. International Technology Group 2

5 During 2012, SAP and IBM demonstrated a 16-node HANA system processing 100 terabytes (TB) of raw data. It was followed by a 100-node system described by SAP as the world's largest inmemory database system ever assembled handling 1,000 TB (one petabyte) of raw data. In this test, a 25 times increase in query volume resulted in negligible performance degradation. An expanded version of this cluster with 150 nodes was demonstrated at SAPPHIRE Madrid in November Figure 2 summarizes workloads and results for these tests. Test Date April 2012 October 2012 November 2012 Raw data size 100TB 1,000TB 1,000TB Compressed database 3.78TB 49.2TB 49.2TB Number of records 120 billion 1,200 billion 1,200 billion Configuration 16 x IBM ex5 100 x IBM ex5 150 x IBM ex5 4/40 x E /40 x E /40 x E GB RAM/node 1TB RAM/node 1TB RAM/node 3.3TB disk/node 3.3TB disk/node 3.3TB disk/node Figure 2: Largest SAP HANA Test Systems Query workloads, according to SAP, were modeled on those of HANA users. The 1.2 trillion records employed in the one-petabyte demonstration corresponded to ten years of data for a large corporation generating an average of 330 million transactions per day. In most cases, complex queries were processed in under a second. The largest was processed in under 3.2 seconds. IBM employs GPFS for single-node as well as scale-out configurations. For single-node applications, GPFS offers performance advantages over the standard Linux-based file systems, ext3 and hfs, employed by other vendors. The I/O strengths of IBM X-Architecture in System x servers further boost high-volume throughput relative to conventional x86 servers. 3. High availability and disaster recovery. Real-time analytics are inevitably sensitive to downtime. Even brief interruptions of service may impair decision-making processes throughout organizations. Recovering extremely large data volumes in the event of a serious outage will be a challenging process. As organizations deploy SAP transactional as well as analytical applications, vulnerability will increase. A serious outage, or a protracted delay in recovering from one, may grind the entire business to a halt. Maintaining continuous availability will be even more critical and more difficult than with today s enterprise resource planning (ERP) systems and data warehouses. The SAP HANA design incorporates extensive high availability and disaster recovery features, although the manner in which they are implemented varies between appliance vendors. There is, again, a striking disparity between SAN-based approaches and IBM GPFS. SAN-based approaches require synchronization of server- and array-based failover and recovery mechanisms. Configuration complexity is materially increased, and there are more potential points of failure. It will, moreover, clearly take time for the mainstream commercial solutions employed by most vendors to become stable in a HANA environment. In comparison, GPFS requires only failover of disk-equipped servers, and volumes of data that must be recovered are significantly less. International Technology Group 3

6 A four-node GPFS cluster, for example, contains 4.8 TB of disk capacity, compared to 25.5 TB for Cisco clusters with EMC arrays, and 28.8 TB for HP AppSystems and Cisco clusters with NetApp arrays. In 16-node configurations, capacities are 19.2 TB, 102 TB and TB respectively. GPFS also employs a stable and widely used failover and recovery architecture built around Failure Groups. Data may be replicated to multiple standby nodes in real-time. For example, in the one-petabyte HANA test discussed above, 95 active and 5 standby nodes were employed. In practice, ratios of active to standby nodes vary according to user requirements. For SAP users undertaking POCs and pilots, the choice of hardware platform may appear to be a secondary issue. But usage will evolve rapidly, and later changes not only in hardware platforms, but also in distributed file systems which will be closely entwined with SAP software will be disruptive. It may be necessary to interrupt service at a time when organizations are beginning to realize the full business value of HANA applications. Among appliance vendors, IBM appears to be the early market share leader. It would be surprising if this were not the case. The architecture and technology underlying the company s appliance offerings are by a wide margin better equipped to deal with the long-term challenges of HANA deployment than any competitive platform. International Technology Group 4

7 SOLUTIONS SAP HANA Overview SAP HANA first appeared in 2010 as a new SAP-optimized architecture combining in-memory computing, columnar database, massively parallel processing (MPP) and advanced data compression technologies. The HANA package also includes data modeling and development, analytics, replication, loading and other tools. Early functionality and customer adoption have focused on high-performance analytical applications. HANA has typically been employed to accelerate SAP Business Warehouse (BW) output. This was, for example, the case for all but two of the HANA users surveyed for this report. New data compression algorithms employed by SAP have proved highly effective, with users reporting levels of four to eight times in early deployments. HANA is in principle capable of up to 20 times compression, and some users expect to achieve this Adoption has been facilitated by aggressive SAP efforts to develop the portfolio of applications for this platform, and to accelerate the emergence of an ecosystem of third-party tools, skills and support. Applications To date, SAP has adapted most of its major application offerings to run on HANA. Figure 3 lists these. SAP 360 Customer SAP Accelerated Trade Promotion SAP BusinessObjects Business Intelligence SAP BusinessObjects Business Intelligence OnDemand SAP Business One SAP Business Planning & Consolidation SAP Business Suite 7 SAP Cash Forecasting SAP Collection Insights SAP CO- PA Accelerator SAP Customer Segmentation Accelerator SAP Customer Usage Analytics for Financial Services SAP Customer Usage Analytics for High- Tech SAP Customer Usage Analytics for Telecommunications SAP Demand Signal Management SAP Finance & Controlling Accelerator SAP Grid Infrastructure Analytics SAP Liquidity Risk Management SAP NetWeaver Business Warehouse SAP Operational Process Intelligence SAP POS Data Management for Real- Time Retailing SAP Precision Retailing SAP Sales Analysis for Retail SAP Sales & Operational Planning SAP Sales Pipeline Analysis SAP Situational Analysis SAP Smart Meter Analytics SAP Supplier InfoNet Consumer apps (Recalls Plus, MyRunway) Figure 3: SAP HANA Applications SAP has aggressively sought to expand the base of third-party and user-developed applications through its global Co-Innovation structures. Partnerships with key independent software vendors (ISVs), systems integrators and appliance vendors have contributed to the company s recruitment efforts. A program for certification of third-party extract, transform and load (ETL) tools was recently launched. SAP has launched a Real-Time Fund to encourage early stage companies to develop HANA applications. As of November 2012, investments had been made through the Fund in 153 small and midsize companies. In addition, SAP has made a limited version, SAP HANA One, available through Amazon Web Services, and offers the full version through its own SAP NetWeaver Cloud service. International Technology Group 5

8 Evolution The next stage of HANA evolution will, according to SAP, move this platform in multiple directions. Analytical enhancements will continue. In-memory functions will expand (ETL services will, for example, be implemented in RAM). Optimized support for ERP systems will introduced, and big data capabilities will be enhanced. This evolution has begun with SAP HANA support pack stack 5 (SPS5), announced in November SPS5 creates a foundation for converged data and application serving, and for integration of online analytical processing (OLAP) and online transaction processing (OLTP). Plans were also announced for the enhancements summarized in figure 4. Single OLTP & OLAP environment will combine read- optimized & write- optimized data stores supporting transactional & OLAP applications respectively. Natural language- based text analytics will be supported across 31 languages. Expanded predictive analytics will enable customer segmentation and clustering. Predictive Model Markup Language (PMML) will also be supported. Extended application services enhancements will include: (1) Native application server support for two- & 2 1/2 tier applications using HTLM5, JavaScript, JavaScript Object Notation (JSON), SQLScript, XML/A & Open Data Protocol (OData). (2) Business rules management will become a core component. (3) Application functional library framework will provide developer access to embedded algorithms & business functions through SQLScript or JavaScript. Real- time stream processing support through Sybase Event Stream Processor (ESP). Sybase ESP will also exploit HANA real- time analytic features for evaluation of complex decisions. Common modeling environment across data stores through Sybase PowerDesigner. High- performance bulk loading of data from new sources, including Apache Hadoop. Enhanced data profiling will enable business users to manage metadata directly in business terms, monitor data quality scorecards & identify data quality issues using SAP Information Steward software. SAP HANA Platform for Large- Scale Data Center Deployment will include: (1) Support for hot & warm standby servers; integration with third- party backup & failover/recovery solutions; & security enhancements including encryption & expanded authentication, access authorization & audit logging. (2) Support for multiple development, test & sandbox instances on single SAP HANA appliances. Figure 4: Planned SAP HANA Enhancements SAP has moved aggressively to position HANA in the ERP space. HANA support for SAP Business Suite 7 was announced in January It can be expected that HANA will become a major player in emerging big data applications. Many HANA users surveyed for this report saw opportunities to expand applications to address unstructured as well as structured data, and some were actively planning to do so. In these and other SAP user organizations, investments in ERP, BW, BusinessObjects and other SAP systems mean that large segments of data infrastructures are already SAP-based. In such organizations, HANA is a prime candidate for applications that integrate conventional and new data types. International Technology Group 6

9 Appliances Overview In enabling hardware support, SAP defines specifications for and certifies hardware platforms, while selected vendors implement, install and support these. In HANA deployments, resources are dedicated; i.e., they may not be shared with other applications. Currently, SAP recommends use of separate appliances for production, development and quality assurance (QA), although this picture will change in The company has indicated that it will support multiple non-production instances on a single physical HANA platform. HANA runs only on certified hardware configurations with SUSE Linux Enterprise Server (SLES) for SAP Applications. Key hardware requirements currently include use of platforms based on Intel Xeon processor E7 family with up to 128 GB RAM per socket, and 10 Gbps Ethernet connections. According to SAP, these specifications will evolve over time. SAP expanded third-party support in November 2012 with the announcement that VMware vsphere will be supported as the company s preferred way to virtualize HANA databases for non-production instances. Several appliance vendors have indicated plans to support VMware for HANA in early 2013, and the remainder are expected to follow suit. The most likely VMware role, at least initially, will be to support multiple non-production instances in comparatively small single-node installations. It is unlikely that VMware will be employed in a production role, or for scale-out systems for some time. Single-node Configurations Single-node configurations are defined by SAP in T-shirt sizes (e.g., Extra Small, Small, Medium, Large) with two, four or eight processors and up to 1 TB of main memory. All processors are 10-core Intel E7 2.4 GHz models with Intel Hyper-Threading Technology; i.e., two threads per core are supported. For the principal players Cisco, Fujitsu, HP and IBM there are some variations in configurations that are illustrated in figure 5. In terms of technology, the largest differences in single-node configurations are in two areas: 1. File systems. For single node HANA configurations, all vendors other than IBM have adopted third extended filesystem (ext3) and/or XFS. These are journaled file systems forming part of the Linux kernel. IBM employs GPFS, which typically delivers higher levels of performance general industry experience is 20 to 50 percent higher than standard Linux-based equivalents. 2. X-Architecture. This is an Intel processor-based design employed in IBM System x3690 X5 and x3950 X5 servers. Currently in its fifth generation (ex5), X-Architecture offers higher I/O memory and performance than conventional x86 servers. It has proved highly synergistic with HANA workloads. X-Architecture is implemented through extensions to Intel Xeon processor E7 family that conform to the company s QuickPath Interconnect (QPI) specification. International Technology Group 7

10 XS 128GB S 256GB S+ 256GB M 512GB M+ 512GB L 1TB Cisco SAP HANA Appliances UCS C260 M2 UCS C260 M2 UCS C460 M2 2/20 x /20 x /40 x GB RAM 6 x 100 GB SSD log 10 x 600GB SAS data 256 GB RAM 6 x 100 GB SSD log 10 x 600GB SAS data 512 GB RAM 2 x Fusion- io 365GB log 12 x 300GB SAS data Fujitsu SAP HANA Appliances RX600 S6 RX600 S6 RX600 S6 RX900 S2 2/20 x E /20 x E /40 x E /80 x E GB RAM 2 x FusionIO 320GB log 256GB RAM 2 x FusionIO 320GB log 512GB RAM 2 x FusionIO 320GB log 1TB RAM 2 x FusionIO 1.2TB log 8 x 600GB SAS data 8 x 600GB SAS data 8 x 600GB SAS data 8 x 900GB SAS data HP AppSystems for SAP HANA DL580 G7 2 x E GB RAM 1 x 320GB Fusion- io log 2 x 300GB SAS + 24 x 146GB SAS data DL 580 G7 2 x E GHz 256GB RAM 1 x 320GB Fusion- io log 2 x 300GB SAS + 24 x 146GB SAS data DL580 G7 4 x E GB RAM 2 x 320GB Fusion- io log 2 x 300GB SAS + 24 x 146GB SAS data DL980 G7 4/40 x GB RAM 2 x 320GB Fusion- io log 2 x 300GB SAS + 24 x 300GB SAS data DL980 G7 8/80 x TB RAM 4 x 320GB Fusion- io log 2 x 300GB SAS + 24 x 300GB SAS data IBM System solution for SAP HANA x3690 X5 2/20 x 2870 x3690 X5 2/20 x 2870 x3950 X5 2/20 x 8870 x3950 X5 4/40 x 8870 x3950 X5 8/80 x GB RAM 10 x 200GB SSD (log & data) 256GB RAM 10 x 200GB SSD (log & data) 256GB RAM 1.2TB Fusion- io log 8 x 900GB SAS 512GB RAM 1.2TB Fusion- io log 8 x 900GB SAS data 1TB RAM 2 x 1.2TB Fusion- io log 16 x 900GB SAS data Figure 5: SAP HANA Single-Node Appliance Configurations Upgrade paths vary. Cisco and HP require two platform changes in moving from entry-level to scale-out configurations and, in HP s case, users must transition from DL series rack-mount to BL series blade servers. Fujitsu and IBM allow users to upgrade from four-way rack-mount servers with 512 GB to scaleout configurations built around the same platform. In addition, all vendors offer SAP Business Warehouse Accelerator (BWA) appliances, which employ a HANA-like server architecture to offload compute-intensive processing from BW systems. Although SAP HANA will replace BWA, it is expected that the latter will remain in use among organizations that do not require full HANA functionality, or who do not yet wish to undergo the software changes required by this solution. Cisco also offers the SAP-certified Cisco Bridge to SAP HANA, which is designed to act as a BWA appliance while enabling future migration to a full Cisco HANA platform. The Bridge appliance is built around dual-socket UCS B200 M3 blades with Intel E processors. It would be necessary to replace blades to meet HANA specifications. International Technology Group 8

11 Scale-out Configurations Scale-out configurations show greater hardware variations than single-node equivalents. Current offerings for the same vendors are summarized in figure 6. IBM System solution for SAP HANA Cisco SAP HANA Appliances HP AppSystems for SAP HANA Fujitsu SAP HANA Appliances 4-16 nodes certified 100 nodes tested 4-16 nodes certified Up to 48 nodes certified on request 4-16 nodes certified 4-16 nodes certified Servers & Storage x3950 X5 4/40 x E GB or 1 TB RAM 1.2TB Fusion- io 8 x 900GB SAS or x3690 X5 2/20 x E GB RAM 10 x 200GB SSD Switches 2 x RackSwitch G8264 Servers UCS B440 M2 4/40 x E GB RAM UCS 6248 Fabric Interconnect Nexus 2224 Fabric Extender UCS C220 Management Server Storage up to 4x EMC VNX storage processors 16GB RAM 75 x 300GB SAS or NetApp FAS 3240 HA 2 controllers 16 GB RAM 1TB flash cache 48 x 600GB SAS Data ONTAP Switches 2 x Nexus 5596UP (EMC) 2 x Nexus 5548UP (NetApp) 2911 Router Servers c7000 BladeSystem 5108 chassis (up to 4x) BL680 G7 (up to 16x) 4/40 x E GB RAM Virtual Connect Fabric X3400 Storage Management Server Storage up to 4x EVA P controllers 16GB RAM 48 x 600GB SAS XCS, CommandView 2 x X9300 IBRIX gateway nodes NFS Switches 2 x ProCurve 6600 LAN 2 x StorageWorks SAN 2910 ProCurve switch Servers RX600 S6 4/40 x E GB RAM Primergy RX100 Management Server Storage up to 4x Eternus NR1000 (NetApp FAS3240) 2 controllers 16GB RAM 1TB flash cache 48 x 600GB SAS Switches 2 x Brocade VDX Figure 6: SAP HANA Scale-Out Appliance Configurations Scale-out configurations are built around 512 GB or (for the IBM System x3950 X5) 1 TB RAM. In a 16- node configuration, IBM System solution for SAP HANA supports 16 TB RAM compared to 8 TB for competitive platforms. Most vendors have adopted variants of NFS. Since its introduction by Sun Microsystems in 1983, NFS has become the industry s most widely used distributed file system for commercial applications, and is the de facto standard for network-attached storage (NAS). Since 2000, NFS has been an open source product whose development is managed by the Internet Engineering Task Force (IETF). NFS is, however, generally recognized to generate comparatively high levels of server overhead, and commonly experiences performance bottlenecks in high-volume, I/O-intensive environments. Its popularity among HPC users has declined in favor of parallel file systems. A number of attempts have been made to adapt NFS for higher performance. MPFS, for example, was originally developed by EMC and introduced in 2002 for its Celerra NAS platform. It was initially marketed by the company as a means of addressing conventional NAS scalability limitations, but was later adopted by some supercomputer users. International Technology Group 9

12 MPFS was adopted by Cisco for scale-out configurations incorporating EMC VNX systems. EMC has claimed that MPFS is three to four times faster than conventional NFS, and Cisco has claimed three times faster in a HANA environment. Actual disparities depend upon workloads. A second initiative has involved Parallel NFS (pnfs), which forms part of NFS Version 4.1 released by the IETF in January Although pnfs has experienced some initial stability problems, it is expected that it will eventually become a feature of HANA scale-out deployments. Early experiences suggest that performance disparities relative to conventional NFS are approximately the same as for MPFS. NFS is coupled with external disk arrays and SANs. These add to configuration complexity and, because of the higher latencies involved, retard performance. In Cisco as well as HP configurations, blade fabrics compound these effects. This is particularly the case for HP s scale-out solution, which combines blade fabrics, disk arrays (EVA P6500), NAS gateways (X9300 IBRIX) and dual LAN and SAN switches. There are a number of differences between GPFS and NFS variants employed to support SAP HANA. The most important is that GPFS stripes data across all disks on all nodes, and reads and writes to these in parallel. External disk arrays and SANs are not required. Figure 7 illustrates this distinction. SAN- based IBM GPFS Server Nodes Server Nodes LAN LAN SAN Disk Arrays Duplexed switch Figure 7: SAN-based and IBM GPFS Configurations GPFS also incorporates a distributed metadata structure, policy-driven automated storage tiering, managed high-speed replication, information lifecycle management (ILM) tooling and other features. Performance Issues There are currently no generally recognized HANA-specific benchmarks. The SAP BW Enhanced Mixed Load (BW-EML) Benchmark, which has been publicized by HP, is not an exception. The only benchmark result to date, certified by SAP in May 2012, was for an HP configuration. Although a HANA database was employed, the benchmark is BW- rather than HANA-specific. The configuration for which the tests were run a three-tier structure including dedicated DL580 G7- based database and BL680c G7-based application servers is not standard for HANA appliances, although it might be appropriate for generic BW environments. The configuration does not include disk arrays, NFS gateways or switches. Apart from HP, no other appliance vendors have to date published BW-EML results. International Technology Group 10

13 High Availability and Disaster Recovery High Availability (HA) and Disaster Recovery (DR) features form part of the SAP HANA design, although these had not been fully implemented when this report was written. DR was formerly named Disaster Tolerance (DT). The overall HANA design allows for use of failover to cold, warm and hot standby servers ( cold, in this context, means that a standby server receives periodic scheduled backups, but is not activated until the primary server fails; warm means that data is copied periodically between active servers; and hot means that data is replicated continuously, in real time). Synchronous replication for disaster recovery is supported for local or regional replication, typically up to 50 kilometers (c. 30 miles). Asynchronous capability, supporting distances of over 500 kilometers (or 300 miles) is planned for SAP expects that, in practice, appliance vendors will play the central role in implementing HA and DR solutions. All vendors duplex key components and offer extensive reliability, availability and serviceability (RAS) features. Server- and, where these are employed, array-based disks are configured as RAID systems. There are, however, significant differences between SAN-based approaches and IBM GPFS. The former will tend to result in more complex configurations requiring synchronization of server- as well as arraylevel failover and recovery processes. HP, for example, recently announced that SAP had certified its disaster recovery solution for HP AppSystems for SAP HANA (Scale-Out), which employs the company s EVA-based Continuous Access remote replication and recovery software. Server-level clustering, which will use HANA native mechanisms, has not yet been implemented. This solution, which is currently supported only for synchronous replication, is illustrated in figure 8. Servers Servers NFS X9300 IBRIX Cluster NFS X9300 IBRIX Cluster SAN EVA 6500 SAN EVA 6500 Continuous Access Figure 8: HP Disaster Recovery Solution for HP AppSystems for SAP HANA It can be expected that other vendors SAN-based disaster recovery solutions will be generally similar. All vendors plan support for asynchronous replication for International Technology Group 11

14 In comparison, GPFS employs technologies that are integrated into the core file system structure rather than implemented through hardware add-ons and software overlays. GPFS automatically replicates data to one or multiple standby servers in real time, implements locking and enables clusters to continue operation using replicated data. No interruptions of service occur. The core configuration structure for this approach is a GPFS Failure Group, which consists of a set administrator-defined servers sharing a potential point of failure. Data is replicated to and may be reactivated on one or two servers outside this group. The actual number of servers may vary in practice. A four-node configuration, for example, will normally employ a single standby server. In the 100-node configuration used by SAP for its one-petabyte test in October 2012, five standby servers were employed. Failover may occur between multiple, geographically separate clusters using synchronous or (when this is supported by SAP) asynchronous replication. A further differentiator should be noted. Unlike SAN-based approaches, GPFS high availability and disaster recovery mechanisms are designed to operate in high-volume parallel environments, and have been successfully employed in these since Stability problems are unlikely. IBM s GPFS-based Disaster Recovery solution for HANA was certified by SAP as of December There are no restrictions on configuration size. International Technology Group 12

15 DETAILED DATA Basis of Calculations The cost comparisons presented in this report are for the scale-out configurations shown in figure 6. Calculations were based on hardware and, where appropriate, systems software stacks as described in SAP and/or vendor documentation, and are based on discounted list prices as reported by users. In some cases, vendors charged a single price for hardware, maintenance and software licenses and/or support. Where this was the case, costs were counted as hardware. Calculations do not include costs for Linux operating systems, which would normally be the same for all platforms. Facilities costs for data center occupancy are for space occupied by racks, including allowance for service clearances and inactive areas, and are based on a conservative assumption of average cost per square foot for existing Tier I facilities (i.e., costs do not include new construction). Costs also include energy consumption by IT equipment and by cooling, power distribution and other data center systems supporting these. Costs were calculated based on 24-hour, 365 days per year utilization over a three-year period. All cost values were for the United States. Cost Breakdowns Detailed breakdowns of costs are presented in figures 9 and nodes 8 nodes 12 nodes 16 nodes IBM Systems solution for SAP HANA Servers 363, ,292 1,013,464 1,338,635 Infrastructure 50,628 50,898 53,257 53,257 Facilities 41,012 82, , ,168 TOTAL ($) 454, ,214 1,189,757 1,556,060 Cisco Appliances + EMC Arrays Servers 218, , , ,629 Storage 187, , , ,877 Infrastructure 76,374 77,267 77,267 78,161 Facilities 74, , , ,748 TOTAL ($) 556,570 1,035,815 1,514,168 1,993,415 Cisco SAP HANA Appliances + NetApp Arrays Servers 218, , , ,629 Storage 214, , , ,160 Infrastructure 61,746 61,746 62,639 62,639 Facilities 66, , , ,944 TOTAL ($) 560,812 1,058,034 1,556,149 2,053,372 HP AppSystems for SAP HANA Servers 254, , ,590 1,019,453 Storage 218, , , ,460 Infrastructure 82,487 86,399 90, ,223 Facilities 88, , , ,204 TOTAL ($) 644,088 1,136,777 1,629,569 2,134,340 Figure 9: Cost Breakdowns (1) International Technology Group 13

16 4 nodes 8 nodes 12 nodes 16 nodes IBM Systems solution for SAP HANA Hardware & maintenance 250, , , ,342 Software licenses & support 163, , , ,550 Facilities 41,012 82, , ,168 TOTAL ($) 454, ,214 1,189,757 1,556,060 Cisco Appliances + EMC Arrays Hardware & maintenance 471, ,032 1,259,493 1,653,847 Software licenses & support 10,205 20,410 30,614 40,819 Facilities 74, , , ,748 TOTAL ($) 556,570 1,035,816 1,514,168 1,993,414 Cisco SAP HANA Appliances + NetApp Arrays Hardware & maintenance 489, ,042 1,341,662 1,767,388 Software licenses & support 5,010 10,020 15,030 20,040 Facilities 66, , , ,944 TOTAL ($) 560,812 1,058,034 1,556,150 2,053,372 HP AppSystems for SAP HANA Hardware & maintenance 509, ,936 1,224,715 1,594,537 Software licenses & support 46,620 93, , ,600 Facilities 88, , , ,204 TOTAL ($) 644,088 1,136,778 1,629,568 2,134,341 Figure 10: Cost Breakdowns (2) International Technology Group 14

17 ABOUT THE INTERNATIONAL TECHNOLOGY GROUP ITG sharpens your awareness of what s happening and your competitive edge... this could affect your future growth and profit prospects International Technology Group (ITG), established in 1983, is an independent research and management consulting firm specializing in information technology (IT) investment strategy, cost/benefit metrics, infrastructure studies, deployment tactics, business alignment and financial analysis. ITG was an early innovator and pioneer in developing total cost of ownership (TCO) and return on investment (ROI) processes and methodologies. In 2004, the firm received a Decade of Education Award from the Information Technology Financial Management Association (ITFMA), the leading professional association dedicated to education and advancement of financial management practices in end-user IT organizations. The firm has undertaken more than 120 major consulting projects, released more than 250 management reports and white papers and more than 1,800 briefings and presentations to individual clients, user groups, industry conferences and seminars throughout the world. Client services are designed to provide factual data and reliable documentation to assist in the decisionmaking process. Information provided establishes the basis for developing tactical and strategic plans. Important developments are analyzed and practical guidance is offered on the most effective ways to respond to changes that may impact complex IT deployment agendas. A broad range of services is offered, furnishing clients with the information necessary to complement their internal capabilities and resources. Customized client programs involve various combinations of the following deliverables: Status Reports Management Briefs Management Briefings Executive Presentations Communications Telephone Consultation In-depth studies of important issues Detailed analysis of significant developments Periodic interactive meetings with management Scheduled strategic presentations for decision-makers Timely replies to informational requests Immediate response to informational needs Clients include a cross section of IT end users in the private and public sectors representing multinational corporations, industrial companies, financial institutions, service organizations, educational institutions, federal and state government agencies as well as IT system suppliers, software vendors and service firms. Federal government clients have included agencies within the Department of Defense (e.g., DISA), Department of Transportation (e.g., FAA) and Department of Treasury (e.g., US Mint). International Technology Group 609 Pacific Avenue, Suite 102 Santa Cruz, California Telephone: Contact@ITGforInfo.com Website: ITGforInfo.com XSW03127USEN- 00