Nach einigem Zögern hat SAP Ende 2007 den Betrieb von produktiven SAP-Systemen auf virtuellen Servern prinzipiell freigegeben. Unternehmen, die ihre IT-Umgebungen per Virtualisierung konsolidieren möchten, können nun auch ihre ERP-Systeme auf eine Virtualisierungsplattform migrieren.

Allerdings beansprucht die Virtualisierung mehr Hardwareleistung. Die Dimensionierung (Sizing) von SAP-Systemen erfolgt in der Regel durch die Hardwarehersteller. Diese ermitteln anhand von SAP-User-Kennzahlen, Mengengerüsten und Benchmarks wie SAPS (SAP Application Performance Standard), mit wie viel Arbeitsspeicher, CPU-, Disk-I/O- und Netz-I/O-Ressourcen ein Server ausgerüstet werden muss, damit er die anstehenden Aufgaben zügig bewältigen kann.

Viele Einflüsse

In virtuellen Umgebungen ist das Sizing komplexer, da deutlich mehr Faktoren die Gesamtleistung beeinflussen als bei Einzelsystemen. Beispielsweise muss der Anwender berücksichtigen, dass weitere virtuelle Server auf derselben Hardware laufen und um die vorhandenen Ressourcen konkurrieren. Zudem kommunizieren mehrere virtuelle Server über dieselbe physische Netzwerk- und SAN-Karte des Wirtsrechners (V-Hosts) mit dem LAN und dem Speichernetz.

Dimensionierungstabellen

Um diesen neuen Anforderungen gerecht werden zu können, hat SAP den Hardwarepartnern Werkzeuge an die Hand gegeben, mit denen sie ihre Server-Sizing-Tabellen für virtualisierte Systeme anpassen können. Für die Dimensionierung der CPU- und RAM-Leistung hat sich laut Manfred Stein vom SAP Linux-Lab das Vorgehen etabliert, den Overhead-Faktor der jeweiligen Virtualisierungslösung zu den bisherigen Sizing-Vorgaben hinzuzurechnen.

Tests belegen gute Performance

Vom Idealzustand, dass die Virtualisierung überhaupt keinen System-Overhead verursacht, sind die Virtualisierungsanbieter noch ein Stück entfernt. Im vergangenen Jahr hat SAP einen Overhead von 20 Prozent als Obergrenze für den Betrieb von virtuellen Systemen angesetzt. Diese Angabe bezog sich auf Linux-Plattformen mit Suse Linux Enterprise Server (SLES) 10 SP1 und Red Hat Enterprise Linux (RHEL) 5 sowie VMware ESX 3.0 und war vor allem für kleinere Umgebungen gedacht. Virtuelle Server unter Xen skalierten zu dieser Zeit nur mit bis zu zwei virtuellen CPUs, mit VMware ließen sich auch mit vier V-CPUs akzeptable Leistungssteigerungen erzielen.

Ende des vergangenen Jahres wurde eine neue Testrunde mit virtualisierten SAP-Systemen gestartet, bei der unter anderem Vergleichswerte zu nativen Umgebungen ermittelt wurden. Erste Ergebnisse deuten nach Angaben von Helge Deller, SAP Linux-Lab, darauf hin, dass die neuen Linux-Versionen RHEL-5.2 und SLES 10 SP2 besser skalieren und sich der Virtualisierungs-Overhead auf etwa zehn Prozent reduziert. Getestet wurden auch größere virtuelle Server mit bis zu acht V-CPUs, die mittlerweile eine gute Performance erreichen.

Dirk Hessing, bei Novell als Product Manager für den Betrieb von SAP unter Linux zuständig, weist zudem darauf hin, dass die virtuellen Maschinen in der genannten Testrunde auch bei den Disk-I/O- und Memory-Durchsatz-Werten gut skaliert haben.

Betriebssystem-Vorgaben

Bei der Wahl des Betriebssystems zieht SAP bislang relativ enge Grenzen. So muss bei Xen-basierenden Virtualisierungsplattformen das virtuelle Betriebssystem für den SAP-Server mit dem Betriebssystem der Virtualisierungsplattform übereinstimmen. Auf einem Novell-SLES-10-Server mit Xen-Virtualisierung muss das SAP-System ebenfalls auf einem virtuellen SLES-10-Server laufen. Für produktive SAP-Systeme, die auf einem virtualisierten Windows-Server laufen, ist bisher nur VMware ESX Server als V-Host zugelassen. Unter VMware ESX sind zudem Novell SLES10 SP1 und Red Hat RHEL 5.1 als virtuelle Server für produktive SAP-Systeme möglich.

SAP wird aller Voraussicht nach auch die native Kombination Windows auf Windows unterstützen, sobald der von Microsoft für Juli 2008 angekündigte neue Hypervisor des Windows Server 2008 verfügbar ist. Unter Xen und VMware wird derzeit das SAP Kernel Release 7.00 unterstützt. Für eine Virtualisierung älterer SAP-Kernel-Versionen sind individuelle Freigaben erforderlich.

Arbeitsspeicher fest zuweisen

Auch für die Konfiguration des Arbeitsspeichers von virtualisierten SAP-Systemen gibt es aus Walldorf klare Vorgaben. Dem virtuellen ERP-Server muss genauso viel RAM exklusiv zur Verfügung gestellt werden, wie ein physischer Server erhalten würde. Als Grund für diese Forderung führt Linux-Spezialist Stein Ergebnisse von Benchmark-Tests an. Demnach bricht die Performance insbesondere mit VMware stark ein, sobald die Server mehr Speicher beanspruchen, als physikalisch vorhanden ist. Für diesen Test liefen mehrere virtuelle SAP-Benchmark-Systeme parallel auf einem ESX-Host.

Zusätzlich muss ausreichend Arbeitsspeicher für das Host-System vorhanden sein, damit keine Engpässe auftreten. Für ein mit 16 GB RAM ausgestattetes virtuelles SAP-System sollte für den V-Host etwa 1 GB Arbeitsspeicher reserviert werden.

SAP- und Nicht-SAP-Server

Um auch bei einer Virtualisierung von SAP-Servern von den Vorteilen eines effizienteren Einsatzes der Hardwareressourcen und eines niedrigeren Strom- und Platzbedarfs profitieren zu können, sollten Unternehmen auf dem jeweiligen V-Host-System zusätzlich zum SAP-Server weitere Server virtualisieren. Dadurch lässt sich die Prozessorleistung von allen virtuellen Servern effizienter nutzen, und für die Nicht-SAP-Server kann auch der Arbeitsspeicher überallokiert werden.

Für Wolfram Weber, Manager Field System Engineers bei VMware, liegt genau hierin einer der größten Vorteile der Server-Virtualisierung. Ziel sei es ja gerade, die bisherigen Silos aufzubrechen und auf einer größer dimensionierten Hardware zahlreiche physikalische Einzelsysteme zu konsolidieren. Zudem könnten Unternehmen die Vorteile einer effizienteren RAM-Auslastung durch eine Virtualisierung von SAP-Test- und Integrationssystemen nutzen. Denn bei diesen Systemen könne auch der Arbeitsspeicher überallokiert werden, da es sich um nicht produktive Server handele und das Antwortzeitverhalten deshalb nicht so kritisch sei. Für Integrations- und Testsysteme bietet VMware mit dem Lab Manager eine auf diese Anforderungen spezialisierte Lösung an. Nach Angaben des Virtualisierungsspezialisten lassen sich Systeme damit schnell klonen, um Veränderungen zunächst zu testen und bei Erfolg den geclonten Server zum produktiven System zu machen.

IBM AIX und Sun Solaris

Eine vergleichbare Funktion bietet das Betriebssystem "Solaris" von Sun Microsystems mit den "Zones" an. Damit lassen sich ebenfalls produktive Systeme klonen und der Test-Server nach erfolgreicher Testphase als Produktivsystem einsetzen. Auch IBM offeriert mit den Servern der p-Series-Reihe und dem Betriebssystem AIX Virtualisierungsfunktionen, mit denen sich mehrere SAP-Systeme auf einem größeren Server effizienter betreiben lassen als auf dedizierten Einzel-Servern.

Für virtualisierte Umgebungen gibt es keine speziellen Vorgaben, welche SAP-Systeme wo laufen sollen. Laut den SAP-Experten Stein und Deller spricht nichts dagegen, auf einem großzügig ausgestatteten V-Host-Server zusätzlich zu einem produktiven SAP-System weitere virtuelle Server zu betreiben, wobei es sich durchaus auch um zusätzliche SAP-Server handeln kann. Dabei sollte allerdings sichergestellt werden, dass ausreichend RAM- und CPU-Ressourcen zur Verfügung stehen, um alle virtuellen Systeme mit der von physikalischen Servern gewohnten Performance betreiben zu können.

Bei älteren Xen-Versionen lässt sich die Performance virtualisierter SAP-Systeme steigern, indem man den Parameter "Mprotect" deaktiviert. Dadurch nutzt die Umgebung den Arbeitsspeicher besser aus. Für künftige 64-Bit-Anwendungen wird laut Deller die Nutzung von Mprotect wieder die Standard-Konfigurationsvorgabe sein.

Prozessoren überallokieren

CPUs lassen sich mittels Virtualisierung deutlich besser auslasten. Der Systemverwalter kann den virtuellen Servern in der Summe mehr CPU-Leistung zuweisen, als tatsächlich vorhanden ist. Durch diese Überbuchung kann man den einzelnen virtuellen Servern eine höhere Prozessorleistung zur Verfügung stellen, weil in der Regel nicht alle virtuellen Server gleichzeitig mit Volllast laufen. Der V-Host stellt die CPU-Leistung jeweils dort in vollem Umfang zur Verfügung, wo sie gerade gebraucht wird.

VMware empfiehlt beim SAP-Betrieb, eine physikalische CPU für die VMware-Instanz freizuhalten. Novell-Spezialist Hessing hält es bei produktiven SAP-Systemen auch unter Linux für vorteilhaft, der Dom 0 eine dedizierte CPU zuzuweisen, wenn auch die SAP-Datenbank innerhalb eines virtuellen SAP-Servers läuft. Dies stellt sicher, dass kein Flaschenhals entstehen kann.

Die Tests zeigten, dass sich die CPU-Ressourcen bis zu 50 Prozent überallokieren lassen, ohne die Stabilität des Gesamtsystems zu gefährden. Bei einem Server mit 16 CPU-Cores bedeutet dies, dass den virtuellen Servern insgesamt 24 V-CPUs zugewiesen werden können. Der Leistungsabfall verläuft linear, so dass sich das Verhalten bei steigender CPU-Last gut vorhersehen lässt. In den Benchmarks wurde ein V-Host-Server mit 16 CPU-Cores und 64 GB RAM mit acht virtuellen SAP-Systemen CPU-seitig voll ausgelastet und lief immer noch stabil.

Nicht für APO geeignet

VMware empfiehlt aufgrund von Benchmark-Ergebnissen, virtuelle SAP-Systeme zunächst mit zwei V-CPUs zu konfigurieren. Erst wenn mehr CPU-Leistung erforderlich ist, sollten die Anwender weitere V-CPUs hinzufügen.

Für eine Virtualisierung weniger geeignet sind Livecache-Systeme von SAP, wozu beispielsweise die Komponente "Advanced Planning and Optimization" (APO) zählt. Diese Server halten große Teile der Datenbank im Arbeitsspeicher vor, um die Performance zu erhöhen. Mittlerweile gibt es dem ERP-Anbieter zufolge auch schon Anwender, die im Zuge ihrer Konsolidierungsstrategie sogar diese Cache-Server virtualisieren.

Datenbankanforderungen

Generell gilt, dass bei virtualisierten SAP-Systemen dieselben Anforderungen zu berücksichtigen sind wie bei physikalischen Servern. So müssen zum Beispiel große SAP-Datenbanktabellen, die mehrere GB umfassen, im Storage-System auf eigene LUNs (Logical Unit Numbers) gelegt werden, um einen ausreichend hohen Datendurchsatz zu gewährleisten. Auch ist darauf zu achten, dass die Disk-I/O- und die Netzwerkzugriffe nicht zum Flaschenhals werden. SAP weist seine Anwender zudem darauf hin, dass der Betrieb von geschäftskritischen Hochleistungsdatenbanken auf Virtualisierungsplattformen von den Datenbankherstellern im Allgemeinen nicht empfohlen wird.

Follow-the-Sun-Prinzip

Ein interessantes Beispiel für eine Nutzung virtualisierter SAP-Systeme liefert ein international agierendes Unternehmen. Die Firma verfügt über zwei Hauptstandorte in Asien sowie in Europa und nutzt die virtualisierte SAP-Umgebung nach dem Follow-the-Sun-Prinzip. Sie setzt hierfür einen V-Host-Server ein, auf dem zwei virtuelle SAP-Systeme laufen. Jedem dieser beiden Server sind fast die gesamten CPU- und RAM-Ressourcen zugewiesen. Wenn in Asien tagsüber gearbeitet wird, hat der für die europäische Niederlassung eingerichtete virtuelle Server so gut wie keine Last und umgekehrt.

Sobald jedoch die Leistungsanforderungen des SAP-Systems oberhalb von 5000 bis 6000 SAPS liegen, ist Erfahrungen zufolge die physikalische Hardware - zumindest beim heutigen Entwicklungsstand der Virtualisierungssoftware - nach wie vor leistungsfähiger als virtuelle Server.

(fn)