At the last count SAP have certified over 600 systems in their two tier benchmark. When considering new hardware for an SAP landscape this sounds like a lot, but this figure is not an accurate portrayal of how many of these systems are still available to buy. Digging deeper into the data it becomes apparent that only around 150 of these systems were tested between 2008 and 2010. Unless a customer has a good reason for buying hardware originally release over 3 years ago, then the majority of the certified systems can be ignored.

Looking closer again it is apparent that the tested systems can be divided into two groups based on their hardware. These groupings are proprietary UNIX systems and x86 based systems. Proprietary UNIX systems are produced by manufacturers and are a combination of specific UNIX operating system software and hardware. Only three companies currently submit proprietary UNIX systems to benchmarking by SAP, these are indicated in the following table.

Manufacturer	Processor Type	UNIX Operating System
IBM	Power	AIX
HP	Itanium	HPUX
SUN	SPARC	Solaris

Proprietary UNIX

UNIX can normally be found running the larger implementations of SAP. Proprietary UNIX uses an operating system and hardware by the same vendor. These systems generally have more advanced architectures, can often scale up better and have better handling of hardware failures. Modern UNIX systems scale from a single socket all the way up to 128 sockets. Nowadays most UNIX systems for SAP are somewhere between 2 and 32 sockets. Because of proprietary UNIX architecture and ability to scale up it is more costly then x86 systems and is rarely used for small installations. Although you could use a proprietary UNIX platform for a 50 user SAP solution, the price tag would be somewhat worrying compared to an x86 equivalent.

x86

The term x86 refers to a family of instruction set architectures based on the Intel 8086 processor that was originally released in 1978. The original 8086 processor was 16 bit, but the instruction set has expanded over the years to support 32 and 64 bit implementations. The x86 market is dominated by Microsoft Windows operating systems. Linux, although ported to many architectures, is also common on x86. Solaris can also be found on x86, but normally only on SUN hardware. x86 systems scale from single socket solutions up to 16 sockets, however 16 socket solutions are rare. Most x86 SAP implementations use somewhere between 2 and 8 sockets. Unlike proprietary UNIX systems, x86 is not locked down to specific hardware vendors but lacks the ability to scale up as far as UNIX. To its advantage, x86 is cheaper, making it ideal for small to medium sized SAP installations. The x86 architecture is also gaining ground on UNIX due to the popularity of Windows and Linux, as well as the leaps in technology surrounding the x86 platform.

Unix or x86?

Is it a common misconception that proprietary UNIX systems offer better performance? It is certainly a concept the industry leads customers to believe, but is it true? Another thing to consider is if UNIX does offer better performance at what point should you consider a UNIX system? Should you consider UNIX at all? Many SAP products (ECC for example) allow you to scale out with Application Servers, so should you scale out or up?

As mentioned in the first article in this series, it is vital that you have a good sizing which should result in a sizing requirement measured in SAPS. Once this figure or figures have been obtained, you can begin to consider what platform to choose.

The following charts show data from the official SAP benchmarks for systems tested through 2008, 2009 and 2010.

Over the past three years the average SAPS of all tested proprietary UNIX systems was over 100,000 per system, x86 average SAPS rating over the same period was less than 20,000 per system. So, on average, UNIX systems tested by SAP have 5 times the performance of x86 systems. This figure itself is of little importance unless we understand the makeup of these systems.

The average socket count of these systems provides further information.

The tested UNIX systems have an average of around 24 sockets per system where the x86 systems have an average of around 4. As discussed earlier, UNIX systems tend to be bigger and can scale up to a higher number of sockets.

Both UNIX and x86 systems have CPUs that have 2, 4, 6 and 8 cores, but as the socket count is higher on UNIX so is the average core count. On average the UNIX core count is over 90 per solution whereas the x86 only just tops 20. Another interesting point is that there is not much fluctuation in CPU speed between UNIX and x86 systems. In recent years, CPU frequency in the UNIX and x86 markets have been pretty similar.

UNIX also has a much higher average system memory, on average just under 600GB. x86 systems, on the other hand, come out with an average of just over 80GB per system. The higher memory amount is largely due to more CPU and cores, the average memory per core ratio for UNIX is only slightly higher than the x86 average.

The figures show that UNIX systems generally have more CPUs and therefore more cores, they also have more memory. The more cores you have the more performance (SAPS) you get. What is very interesting is the data relating to SAPS per core. This data is derived by dividing the SAPS result by the number of cores in the system. The chart below shows the average results.

Both x86 and UNIX supply a similar amount of SAPS (performance) per core with x86 showing slightly more performance than UNIX. The clear advantage of UNIX over x86 is that it can provide far more cores, and therefore more performance in a single system.

Digging deeper

This data seems to lead to the automatic conclusion that UNIX is for big systems and x86 is for small systems. Unfortunately, things are never that simple. There are two technological obstacles that prevent the former statement from being the complete picture. The first is virtualisation, splitting a single large system in to multiple, smaller virtual systems. This enables many individual workloads to operate within a single physical system. The second is scaling out, balancing a large workload across several applications servers

Virtualisation is the topic of the next article, so the remainder of this article will look at scaling out using application servers.

Scaling out

In this example, we have a requirement for a system that has a SAPS benchmark of at least 85,000 SAPS. IBM have UNIX solutions and x86 solutions that can deliver this performance in a single system. A scaled out solution using x86 has also been included.

Server	SAPS	CPUs	Cores	CPU Freq	Main Memory	List Price Including 3years HW/SW maintenance
IBM Power System 750	85,220	4	32	3.5Ghz	512GB	£315,055.83
IBM System x3850 X5	108,270	8	64	2.26Ghz	512GB	£69,246.00
3 x IBM System x3690 X5	29,300 per server	2 per server	16 per server	2.26Ghz	128GB	£97,569.00 (total cost)

All prices are IBM list prices and include 3 years 24 x 7 hardware and software maintenance. No storage adapters or database/application storage is included. The first thing to note is that the Power System 750 (UNIX) solution is, by far, more expensive than either the monolithic or scaled out x86 solutions. However, UNIX is generally regarded to be extremely stable and is not tied to the limitations of x86 hardware. Although all prices are list, UNIX systems are normally discounted more generously than x86 systems, so the street price would be quite a bit lower, but would always be more expensive than x86.

The x86 based IBM System x3850 X5 provides more SAPS than the UNIX solution at a much lower cost. x86 systems do not include some of the advanced hardware features available in IBM Power (UNIX) such as processor instruction retry and alternate processor recovery. However, as the hardware is less than half of the cost as the UNIX system, a customer could purchase two of the x86 solution and cluster them for redundancy for less than the cost of the UNIX solution.

The final option is to scale out using 3 x IBM System x3690 X5 servers. This solution offers a combined SAPS total of 87,900 and costs around £28,000 more than the monolithic x86 option. In addition to this increased cost you also have the disadvantage that there are 3 physical servers to maintain rather than 1. On the other hand, scaled out solutions can often handle the failure of a single server without taking the whole system down. In addition, extra scaled out nodes can be added to grow the system at a later stage.

So what conclusions can be drawn from this data? It seems that the performance gap between proprietary UNIX systems and x86 is becoming narrower. UNIX can still support a higher CPU and therefore core count, which gives them greater performance, but scaled out x86 solutions can meet this performance. Scaled out solutions have the disadvantage that they are more complex and systems administrators need to manage a higher number of systems. UNIX systems tend to have more advanced system architecture making them more reliable, but for less cost it is possible to double up and cluster x86 hardware that provides the same performance.

Any decision a customer will make on a hardware platform for SAP must also include the skills of their staff. If a customer has always used Solaris on SPARC, has many years of collective knowledge of running SAP on these systems, what is the likeliness of ditching the current hardware and replacing it with Windows on x86? What will the retraining costs be? It can often be overlooked but what hostility might a customer face from their technical staff if they switch from a known and trusted hardware platform to something completely new?

Customers who have traditionally used proprietary UNIX systems, drawn to x86 because of the cost savings, may consider Linux on x86 as an acceptable solution. Certain Linux distributions (SLES and Red Hat) are fully supported by SAP and by Oracle and IBM for database products. Being a UNIX-like OS, UNIX administrators may feel much more at home than moving to Windows Server products.

All in all, choosing a hardware platform for an SAP landscape is not clear cut. Many customers will end up choosing the platform they have always used. Switching to a new platform may mean costly training for technical staff and could cause animosity if not executed well. But switching hardware platforms is possible and when managed well, can save customers money without sacrificing system performance or availability.