XenServer @ SAP

Wer in den letzten 12 Monaten auf einer Veranstaltung von Citrix war, der hat sicher schon einmal davon gehört. Es ist quasi das Referenzprojekt für Citrix.

Die SAP AG wird ihre Presentation Server Umgebung mittels Citrix XenServer 5.0 virtualisieren.

Ich kann mich an keine Veranstaltung, an kein Gespräch mit einem Citrix Mitarbeiter in den vergangenen Monaten erinnern bei dem nicht mindestens einmal das Konsolidierungprojekt bei der SAP AG angesprochen wurde. Erst einmal ist natürlich ein ziemlich großes Projekt. Es wurde immer wieder eine Zahl zwischen 700 und 800 Server genannt. Also jede Menge Blech. Zum Zweiten kann man sich vorstellen dass die SAP nicht eben mal schnell ihre Server virtualisiert ohne dies ausgiebig zu testen.

Vorausgegangen ist wohl ein ziemlich umfangreiches Pilotprojekt in dem die unterschiedlichen Hypervisor (VMware ESX, Citrix XenServer und wohl sogar Microsoft Hyper-V) gegeneinander miteinander verglichen wurden. Am Ende hat sich SAP für den Citrix XenServer 5.0 entschieden. Dies hat wohl vor allem mit der Optimierung des XenServer für XenApp zu tun die man in den „Optimization Properties“ einstellen kann.

XenApp Optimierung

Citrix hat sich hier das „Insiderwissen“ zum XenApp zu nutzen gemacht und den XenServer in diese Richtung optimiert. Aktuell arbeitet man dort auch an Optimierungen für Microsoft SQL Server und Microsoft Exchange Server. Die Wirkung auf den Virtualisierungsmarkt ist aus meiner Sicht nicht zu unterschätzen. Immerhin ist die SAP nebenbei auch ein ziemlich gewaltiger VMware Kunde und ich kann mir vorstellen dass VMware in der Pilotphase alles daran gesetzt hat „gut“ auszusehen. Am Ende hat es dann doch nicht gereicht. Natürlich haben neben den technischen Aspekten auch politische und finanzielle Punkte zu diesem Endergebnis geführt. Das versteht sich bei Projekten dieser Größenordnung von selbst. Aber was man so hört, auch von der SAP Seite, war der XenServer auch technisch die beste Lösung. Mit keiner anderen Virtualisierunglösung konnten so viele Benutzer pro physikalischem Server bedient werden. Im letzten Citrix SRT (Solution Round Table) war von 25 – 30 Benutzer pro XenApp Server und von 4 XenApp Server pro XenServer die Rede. Dies würde eine Summe von 100 – 120 Benutzer pro Server (Blech) ergeben.

Leider wird in der Citrix Success Story relativ wenig über die technischen Daten der Umgebung geschrieben. Zudem gehen die Informationen im Dokument und die Informationen von div. Citrix Mitarbeitern auseinander. In der Success Story steht dass es sich um Blade Server mit jeweils 2 QuadCore Prozessoren und 32 GB Speicher handelt. Auf Veranstaltungen war immer von nur 20 GB Speicher die Rede.

Da es sich um „normale“ 32-bit Windows 2003 Server handeln soll machen aus meiner Sicht 32 GB relativ wenig Sinn. Wenn man den Speicher für den XenServer selbst abzieht, ist immer noch „Platz“ für 7 Windows Server mit jeweils 4 GB Speicher. Da sind die 20 GB Speicher aus meiner Sicht schon realistischer. 4 Virtuelle Maschinen mit jeweils 4 GB Speicher. Der Rest (4 GB) bleibt für den XenServer selbst. Auf der anderen Seite hört man immer das SAP vom Hardwarelieferant (HP) ein Standard Blade bezieht, das heißt egal welcher Anwendungszweck, es wird immer das gleiche Blade mit identischer Ausstattung benutzt. Dies macht bei der sicher nicht geringen Anzahl an Serversystemen natürlich auch wieder Sinn. Somit können es auch 32 GB Speicher sein. Letztendlich ist es egal.

Wichtiger als die reinen technischen Daten finde ich das es sich hier um eines der ersten, großen XenServer Projekte handelt. Bisher wird, vor allem aus der VMware Gemeinde, das „Enterprise ready“ ein wenig belächelt. Nun – wenn das nicht Enterprise ready ist – was dann. Vielen Kunden wurde in der Vergangenheit abgeraten Citrix Presentation Server zu virtualisieren (auf VMware ESX). Mir Citrix XenServer kann man sich dieser Lösung annehmen und die Serveranzahl in Presentation Server Umgebungen deutlich reduzieren. Denn mittlerweile sind die CPUs in modernen Serversystemen derart Leistungsfähig das hier kein Flaschenhals mehr entstehen kann. Das Problem ist und bleibt das Speicherproblem. Bei 2 GB Userspace und 2 GB Systemspace ist in einem 32-bit System einfach Schluss und 64-bit Windows können auf Grund von Anwendungen (16-bit) nicht überall eingesetzt werden. Wenn sich eine Konsolidierungsrate von 3:1 oder gar 4:1 erreichen lässt, dann gibt es wieder Platz im Rechenzentrum und die Klimaanlage kann auch wieder mit weniger Leistung arbeiten.

Advertisements