February  2013  


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 95060-4406 Telephone: 831-427-9260 Email: Contact@ITGforInfo.com Website: ITGforInfo.com

SAP HANA Overview Applications Evolution Appliances Overview Single-node Configurations Scale-out Configurations Performance Issues High Availability and Disaster Recovery 1 5 5 5 5 6 7 7 7 9 10 11 13 13 13

Basis of Calculations Cost Breakdowns

List of Figures
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Three-year Appliance Costs for SAP HANA Deployment – Averages for All Scale-out Configurations Largest SAP HANA Test Systems SAP HANA Applications Planned SAP HANA Enhancements SAP HANA Single-Node Appliance Configurations SAP HANA Scale-Out Appliance Configurations SAN-based and IBM GPFS Configurations HP Disaster Recovery Solution for HP AppSystems for SAP HANA Cost Breakdowns (1) Cost Breakdowns (2) 2 3 5 6 8 9 10 11 13 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.

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 2013. 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, HewlettPackard (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


IBM  Systems  soluCon   Cisco  &  EMC     Cisco  &  NetApp   HP  AppSystems   $  Thousands   Servers   Storage  


1,274.99   1,307.09   1,386.19   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


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 2012. Figure 2 summarizes workloads and results for these tests.
Test  Date   Raw  data  size   Compressed  database   Number  of  records   Configuration   April  2012   100TB   3.78TB   120  billion   16  x  IBM  eX5   4/40  x  E7-­‐8870   512GB  RAM/node   3.3TB  disk/node    October  2012   1,000TB   49.2TB   1,200  billion   100  x  IBM  eX5   4/40  x  E7-­‐8870   1TB  RAM/node   3.3TB  disk/node    November  2012   1,000TB   49.2TB   1,200  billion   150  x  IBM  eX5   4/40  x  E7-­‐8870   1TB  RAM/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


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 115.2 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


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

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 2012. 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 2013. 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


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 2013. 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


XS   128GB   UCS  C260  M2     2/20  x  2870   2.4  GHz   128  GB  RAM   6  x  100  GB  SSD  log     10  x  600GB  SAS   data  

S   256GB   UCS  C260  M2         2/20  x  2870   2.4  GHz   256  GB  RAM   6  x  100  GB  SSD  log     10  x  600GB  SAS   data  

S+   256GB  

M   512GB   UCS  C460  M2       4/40  x  4870   2.4  GHz   512  GB  RAM   2  x  Fusion-­‐io  365GB   log   12  x  300GB  SAS   data   RX600  S6     4/40  x  E7  4870   2.4  GHz   512GB  RAM   2  x  FusionIO     320GB  log     8  x  600GB  SAS  data   DL580  G7   4  x  E7-­‐4870     2.4  GHz   512GB  RAM   2  x  320GB     Fusion-­‐io  log   2  x  300GB  SAS  +  24   x  146GB  SAS  data  

M+   512GB    

L   1TB  

Cisco  SAP  HANA  Appliances  

Fujitsu  SAP  HANA  Appliances   RX600  S6   2/20  x  E7  4870   2.4  GHz   128GB  RAM   2  x  FusionIO     320GB  log     8  x  600GB  SAS  data     DL580  G7   2  x  E7-­‐4870   2.4  GHz   128GB  RAM   1  x  320GB   Fusion-­‐io  log   2  x  300GB  SAS  +  24   x  146GB  SAS  data   x3690  X5   2/20  x  2870     2.4  GHz   128GB  RAM   10  x  200GB  SSD     (log  &  data)   RX600  S6     2/20  x  E7  4870   2.4  GHz   256GB  RAM   2  x  FusionIO     320GB  log     8  x  600GB  SAS  data     DL  580  G7     2  x  E7-­‐4870     2.4GHz   256GB  RAM   1  x  320GB   Fusion-­‐io  log   2  x  300GB  SAS  +  24   x  146GB  SAS  data   x3690  X5   2/20  x  2870   2.4  GHz   256GB  RAM   10  x  200GB  SSD     (log  &  data)   x3950  X5   2/20  x  8870   2.4  GHz   256GB  RAM   1.2TB  Fusion-­‐io  log   8  x  900GB  SAS     RX900  S2   8/80  x  E7  8870   2.4  GHz   1TB  RAM   2  x  FusionIO     1.2TB  log   8  x  900GB  SAS  data     DL980  G7   8/80  x  4870   2.4  GHz   1TB  RAM   4  x  320GB     Fusion-­‐io  log   2  x  300GB  SAS  +  24   x  300GB  SAS  data   x3950  X5   8/80  x  8870     2.4  GHz   1TB  RAM   2  x  1.2TB  Fusion-­‐io   log   16  x  900GB  SAS  data    

HP  AppSystems  for  SAP  HANA   DL980  G7   4/40  x  4870   2.4  GHz   512GB  RAM   2  x  320GB   Fusion-­‐io  log   2  x  300GB  SAS  +  24   x  300GB  SAS  data  

IBM  System  solution  for  SAP  HANA   x3950  X5     4/40  x  8870     2.4  GHz   512GB  RAM   1.2TB  Fusion-­‐io  log   8  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 E5-2670 processors. It would be necessary to replace blades to meet HANA specifications.
International Technology Group 8

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   4-­‐16  nodes  certified   100  nodes  tested   Servers  &  Storage   x3950  X5     4/40  x  E7  8870  2.4  GHz     512GB  or  1  TB  RAM   1.2TB  Fusion-­‐io   8  x  900GB  SAS     or   x3690  X5   2/20  x  E7  2870  2.4  GHz     256GB  RAM   10  x  200GB  SSD     Switches   2  x  RackSwitch  G8264   Cisco  SAP  HANA     Appliances   4-­‐16  nodes  certified     Up  to  48  nodes  “certified  on   request”     Servers     UCS  B440  M2   4/40  x  E7  4870  2.4  GHz     512GB  RAM   UCS  6248  Fabric   Interconnect     Nexus  2224  Fabric  Extender   UCS  C220   Management  Server   Storage     up  to  4x   EMC  VNX  5300   2  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   HP  AppSystems  for     SAP  HANA   4-­‐16  nodes  certified   Fujitsu  SAP  HANA   Appliances   4-­‐16  nodes  certified  

Servers   c7000  BladeSystem   5108  chassis  (up  to  4x)   BL680  G7  (up  to  16x)     4/40  x  E7  4870  2.4  GHz   512GB  RAM   Virtual  Connect  Fabric   X3400  Storage  Management   Server   Storage   up  to  4x       EVA  P6500   2  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  E7  4870  2.4  GHz   512GB  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 16node 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

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 2010. 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.
Server  Nodes  

Server  Nodes  


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 G7based 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

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 2013. 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 2013.

International Technology Group


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 2005. Stability problems are unlikely. IBM’s GPFS-based Disaster Recovery solution for HANA was certified by SAP as of December 2012. There are no restrictions on configuration size.

International Technology Group


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 10.
  Servers   Infrastructure   Facilities   TOTAL  ($)   Servers   Storage   Infrastructure   Facilities   TOTAL  ($)   Servers   Storage   Infrastructure   Facilities   TOTAL  ($)   Servers   Storage   Infrastructure   Facilities   TOTAL  ($)   4  nodes   363,121   50,628   41,012   454,761    218,290      187,219      76,374      74,687      556,570    218,290      214,290      61,746     66,486    560,812    254,833      218,467      82,487     88,301   644,088   8  nodes   688,292   50,898   82,024   821,214    434,736      374,438      77,267      149,374     1,035,815    434,736      428,580      61,746     132,972   1,058,034    509,666      364,110      86,399     176,602   1,136,777   12  nodes   1,013,464   53,257   123,036   1,189,757    651,182      561,658      77,267      224,061     1,514,168    651,182      642,870      62,639     199,458   1,556,149    764,590      509,764      90,312     264,903   1,629,569   16  nodes   1,338,635   53,257   164,168   1,556,060    867,629      748,877      78,161      298,748     1,993,415    867,629      857,160      62,639     265,944   2,053,372    1,019,453      655,460      106,223     353,204   2,134,340  

IBM  Systems  solution  for  SAP  HANA  

Cisco  Appliances  +  EMC  Arrays  

Cisco  SAP  HANA  Appliances  +  NetApp  Arrays  

HP  AppSystems  for  SAP  HANA  

Figure 9: Cost Breakdowns (1)

International Technology Group


  Hardware  &  maintenance   Software  licenses  &  support   Facilities   TOTAL  ($)   Cisco  Appliances  +  EMC  Arrays   Hardware  &  maintenance   Software  licenses  &  support   Facilities   TOTAL  ($)   Hardware  &  maintenance   Software  licenses  &  support   Facilities   TOTAL  ($)   HP  AppSystems  for  SAP  HANA   Hardware  &  maintenance   Software  licenses  &  support   Facilities   TOTAL  ($)  

4  nodes   250,399   163,350   41,012   454,761   471,678   10,205   74,687   556,570   489,316   5,010   66,486   560,812   509,167   46,620   88,301   644,088  

8  nodes   450,440   288,750   82,024   821,214   866,032   20,410   149,374   1,035,816   915,042   10,020   132,972   1,058,034   866,936   93,240   176,602   1,136,778  

12  nodes   652,571   414,150   123,036   1,189,757   1,259,493   30,614   224,061   1,514,168   1,341,662   15,030   199,458   1,556,150   1,224,715   139,950   264,903   1,629,568  

16  nodes   852,342   539,550   164,168   1,556,060   1,653,847   40,819   298,748   1,993,414   1,767,388   20,040   265,944   2,053,372   1,594,537   186,600   353,204   2,134,341  

IBM  Systems  solution  for  SAP  HANA  

Cisco  SAP  HANA  Appliances  +  NetApp  Arrays  

Figure 10: Cost Breakdowns (2)

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 Email 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 95060-4406 Telephone: 831-427-9260 Email: Contact@ITGforInfo.com Website: ITGforInfo.com


Sign up to vote on this title
UsefulNot useful