Einer Studie des Marktforschungsunternehmens Raad Research zufolge haben knapp 70 Prozent der SAP-Bestandskunden bereits Erfahrungen mit der Virtualisierung von ERP-Servern sammeln können. Firmen erwarten, auf diese Weise ihre Rechner besser auslasten und so Geld sparen zu können (siehe auch "Vor- und Nachteile von Virtualisierung im SAP-Umfeld").

Nach einigem Zögern hat SAP im Dezember 2007 den Betrieb von produktiven SAP-Systemen auf virtuellen Servern prinzipiell freigegeben. Unternehmen, die ihre IT-Umgebungen mit Hilfe einer Server-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 Faktoren beeinflussen das Sizing

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 Red Hat Enterprise Linux (RHEL) 5.2 und Suse Linux Enterprise Server (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.

Keine freie Betriebssystem-Wahl

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 auf einem Host

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.

SAP-Virtualisierung mit 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 Server von 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.

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.

Spezielle Anforderungen berücksichtigen

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.

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.

Virtuelle Server und 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.

Für Systemintegratoren im Hosting-Bereich steht gar nicht so sehr die Konsolidierung im Vordergrund, sondern die hohe Flexibilität, die eine virtualisierte Umgebung bietet. So lassen sich virtuelle Server im laufenden Betrieb migrieren, wodurch Wartungsarbeiten an der Hardware-Plattform ohne Systemunterbrechung möglich sind. Zudem können Testsysteme per Live-Migration sehr einfach zu einem Produktivsystem umgewandelt werden.

In Deutschland gibt es bereits eine ganze Reihe Unternehmen, die produktive Linux- und Windows-SAP-Systeme virtualisiert haben. Beispiele sind Astra Zeneca, Bender, Checkpoint und T-Systems. Nach Einschätzung von Novell eignet sich die SAP-Virtualisierung vor allem für kleinere und mittelständische Unternehmen. Potenzial sieht der Hersteller in diesem Bereich bei Unix-to-Linux-Migrationen. Sobald jedoch die Leistungsanforderungen des SAP-Systems oberhalb von 5000 bis 6000 SAPS liegen, ist seinen Erfahrungen zufolge die physikalische Hardware - zumindest beim heutigen Entwicklungsstand der Virtualisierungssoftware - nach wie vor leistungsfähiger als virtuelle Server.

SAP CRM und SAP ERP auf VMware

Die Firma Bender aus Grünberg, ein Hersteller von Mess-, Schutz- und Überwachungssystemen, betreibt auf einer VMware-ESX-Plattform zwei produktive SAP-Server, die das CRM-System und das Netweaver Portal bereitstellen. Hinzu kommen ein SAP-Test- und ein -Integrationssystem, die ebenfalls virtualisiert wurden. Als Hardware für die ESX-Server dienen Vier-Wege-Quad-Core-Systeme. Ein wichtiges Ziel der Server-Virtualisierung ist laut IT-Manager Harald Rado, die eingesetzte Hardware effizienter zu nutzen. "Deshalb betreiben wir auf jedem ESX-Host zusätzlich zum produktiven SAP-System derzeit weitere fünf virtuelle Server. Die Hardware bietet bezüglich Arbeitsspeicher und CPU-Ausstattung ausreichend Spielraum, so dass sich künftig noch weitere Server auf der VMware-Plattform virtualisieren lassen." Den beiden produktiven virtuellen SAP-Servern wurden sowohl der Arbeitsspeicher als auch die CPUs fest zugewiesen. Dies stellt sicher, dass den SAP-Systemen dieselben Ressourcen zur Verfügung stehen wie beim Betrieb auf einem nach den Sizing-Vorgaben der Hardwarehersteller dimensionierten physikalischen Server. (fn)