Layered model for SAP architecture to optimize database licences costs to enable an Unix to Linux migration:
In a Unix-Linux migration and a one-to-one transfer of the Unix-SAP architecture, database license costs can explode as a result of the high number of Intel cores. This can be countered by the use of a layered model.
Anyone who read the recent quarterly sales figures for the Unix server market (from whichever market monitor) may have had a wake-up call. To put it nicely, the decline is continuing. In contrast, the x86 server vendors are on the rise. This image fits with the facts. Above all, against the background that more and more IT users are turning away from Unix in the direction of Linux. Of course this also applies for the SAP community.
However, one aspect is bothering users: It is well known that with a Unix-Linux migration and one-to-one transfer of the Unix SAP architecture, the database license costs can explode due to the high number of Intel cores.
This applies in particular, if the database layer is transferred "unseparated". As a side effect, high-availability aspects in the relevant layers also play a not inconsiderable role.
Clever
solution
So what do we do, in order not to fall into a cost trap - or to trim these costs a little? One approach to optimize the infrastructure costs is to check the current SAP architecture design and derive a separation of the application tiers. This means you have the ability only to license computing power for the database that is actually consumed by the database, and not by the core.
As a brief aside; an explanation of what is understood by a layered model: This splits the SAP landscape into three levels, or elements; the application server layer, the central SAP services layer, and the database layer. The aim is to reduce the number of cores required for the database layer - in order to minimize the licensing costs for the database layer. This type of design is interesting for customers who have signed up for direct database contracts with core-based database licensing. And: As a general rule, the introduction of a layered model is worthwhile from five production lines and 15 instances/SIDs.
Also important is that with the introduction of an SAP layered model, certain parameters require checking. Especially because below the five production lines mentioned above and fewer than 15 SAP instances, such a redesign is not worthwhile. The main reason is that more OS partitions are required per SAP ID instance, which in turn means a higher number of physical servers are needed.
If the check is positive and the result is a redesign, in a second step, the physical side is virtually optimized, using SAP virtualization. Ultimately, the
optimization measures mean that less physical hardware is required, in other words, fewer servers are needed.
SAP Central
Services layer
In a redesign based on a layered model, single points of failure (in the context of HA aspects) can be eliminated by enqueue replication and message server clustering. It is extremely practical to access the certified variant of the SAP cluster reference architecture in this regard. The SAP Netweaver High Availability Cluster 7.30 Certification (reference architecture) describes the interaction of the SAP Control Framework with the SAPstartsrv. The key element of this is that communication to the cluster framework is defined using sapcontrol via the sapstartsrv and via the SAP_SUSE Cluster Connector. The Suse cluster component is called the Suse HA extension; an element of the Suse platform package SLES for SAP applications. The HA extension secures communication to the SAP Instance Resource Agent, which in turn is connected with sapcontrol. Via the SAP Instance Resource Agent, SAP LVM is also coupled to the SAP Control Framework.
As far as the application layer is concerned, scalability and high availability are generated through multiple dialog instances. If an SAP application server fails, it can easily be regenerated and then started up.
SAP HANA not
a cost driver
As an aside, Suite on HANA enables the operation of an increasing number of SAP modules on SAP HANA. Due to the compression factor of 1:5 and due to operating HANA in conjunction with the SUSE/Intel infrastructure, the licensing of the HANA database is not core-based, and thus does not represent a cost driver.
In order to evaluate further criteria for the feasibility of the SAP landscape on the basis of a layered model and to realign high availability in accordance with the SAP Netweaver High Availability Cluster 7.30 Certification, and to enable the associated integration in the SAP LVM, the Realtech study on this topic is recommended reading (www.realtech.com/linux) or attending SAP workshops in Walldorf: SAP Infrastrukturen der Zukunft - Agenda
