What are the General Specifications of SAP HANA Hardware

SAP HANA  is  sold  as  a  pre-configured,  pre-installed  appliance  that  is delivered directly from the hardware partner. SUSE Linux SLES 11 and Red Hat Enterprise Linux for SAP HANA are the only supported operating systems, and Intel E7 processors are the primary supported chips. Samsung RAM is currently the primary memory used by most of the hardware partners.

Most partner systems use on-board 15k RPM hard disks (4x ratio for main memory) for data-volume backup and Fusion I/O SSD cards (1:1 ratio for  main memory) for log-volume backup.

SAP ensures the quality, availability, and performance of the certified systems through a rigorous process of end-to-end quality  testing, performance testing, and continuous early access to next-generation technologies from all of its partners.

SAP HANA Product Availability Matrix (PAM)

SAP has recently made the SAP HANA supported hardware matrix available on an open website.
SAP Certified Appliance Hardware for SAP HANA

Additional Infrastructure

SAP recommends that customers deploy 10GB network data connections.
SAP has no preference on external storage/SAN; rather, it is determined by the server vendor.

Multi-Node and Scale-Out Options

SAP  HANA  is a linearly scalable database, meaning, you can string  together multiple physical servers into a single logical database instance and achieve linear performance results for every additional server added to the landscape.

Scale-out- This means combining multiple independent nodes/computers into one system.

Currently, SAP HANA has certified several vendors for multi-node scale out. Literally, you just add another node/server to the landscape, and you immediately enjoy an exponential increase in performance, in addition to the additional memory.

In 2012, SAP recently completed the first 100TB benchmark for the 16 node scale out solution. The data set consisted of five years of Sales and Distribution Records (100 Billion records) and was run on a single logical server consisting of 16 nodes. Each node was a certified IBM X5 machine with eight Intel E7-8870 processors with 10 cores, running at 2.40 GHz. The total cost of the 16 node system was roughly USD$640K.

SAP HANA was able to scan 100 Billion rows/Sec on the 100 TB dataset and was able to load 16 million records/min. SAP HANA’s compression algorithms were able to achieve 20x compression on the raw data when loading into memory, going from 100TB on disk to 3.8TB in memory.

Typical query results were:

• BW Workload: 300ms — 500ms
• Ad-Hoc Analytics: 800ms — 2s

No database tuning, indexing or caching were needed to achieve these results. To put that in context, the closest competitive database is roughly 1000x slower in the same benchmark and several times more expensive.

High Availability

SAP HANA is fully designed for high availability. It supports recovery measures ranging from faults and software errors, to disasters that decommission an entire data center. High availability is the name given to a set of techniques, engineering practices and design principles that support the goal of business continuity.

High availability is achieved by eliminating single points of failure (fault tolerance), and providing the ability to rapidly resume operations after a system outage with minimal business loss (fault resilience).

SAP HANA supports cold standby hosts, meaning a standby host is kept ready in the event that a failover situation occurs during production operation. In a distributed system, some of the servers are designated as worker hosts, and others as standby hosts. Significantly, you can assign multiple standby hosts  to each group. Alternatively, you can group together multiple servers to create a dedicated standby host for each group.

A standby host is not used for database processing. All of the database processes run on the standby host, but they are idle and do not enable SQL connections.

Disaster Recovery

The  SAP  HANA  database  holds  the  bulk of its  data  in memory to   ensure optimal performance, but it still uses persistent storage to provide a fallback in case of failure.

During normal database operations, data is automatically saved from memory to disk at regular save-points. Additionally, all data changes are recorded in the log. The log is saved from memory to SSD after each committed database transaction. After a power failure, the database can be restarted in the same way as a disk-based database, and it returns to its last consistent state by replaying the log since the last save-point.

Checkout SAP HANA Interview Questions

Although save-points and log writing protect your data against power failures, they do not help if the persistent storage itself is damaged. Protecting against data loss due to disk failures requires backups. Backups save the contents of the data and log areas to difierent locations. These backups are performed while the database is running, so users can continue to work normally. The impact of the backups on system performance is negligible.

If the SAP HANA system detects a failover situation, the work of the services on the failed server is reassigned to the services running on the standby host. The failed volume and all the included tables are reassigned and loaded into memory in accordance with the failover strategy defined for the system. This reassignment can be performed without moving any data, because all the persistency of the servers is stored on a shared disk. Data and logs are stored on shared storage, where every server has access to the same disks.

Before a failover is performed, the system waits for a few seconds to determine whether the service can be restarted. During this time, the status is displayed as ”Waiting.” This procedure can take up to a minute. The entire process of failover detection and loading may take several minutes to complete.

Tailored Data Center Concept for SAP HANA deployments

In addition to SAP HANA as standardized and highly optimized appliance, SAP now offers the opportunity to run the SAP HANA server with a customer’s preferred storage solution. This option enables a reduction in hardware and operational costs at installed base customers through the reuse of existing hardware components and operational processes. This approach  not only helps to mitigate risk and optimize time-to-value by enabling existing IT Management processes for SAP HANA implementations, it also afords additional fiexibility in hardware vendor selection by leveraging the existing ecosystem. IT departments will benefit from staying within IT budgets, shorter implementation cycles, and better consumption of hardware innovations to drive the SAP HANA adoption.

Many SAP HANA customers have existing investments in shared storage architecture, and since the in-memory architecture of SAP HANA does not require Tier 1 storage, SAP would like to allow customers to take advantage of their existing investments in skills and technology to make the transition to in-memory computing with SAP HANA easier and more cost-effective.

To help customers that want to manage their own storage, as of SP7, SAP HANA tailored data center integration is now provided as a flexible configuration option for enterprise customers. SAP HANA customers can plan and validate customized storage configurations for SAP HANA with SAP partners for enterprise storage and the SAP HANA appliance. Essentially, this gives large customers the freedom (and responsibility)  of deploying HANA with their own storage rather than deploying it as an appliance.

SAP Hardware Partner Details

Each Certified SAP HANA hardware partner was given the opportunity to briefly describe their SAP HANA offering and discuss their value-added services for SAP HANA implementation, support, and operations.