SAP-IT-Organisationen nutzen die Betriebssystemvirtualisierung, damit auf derselben Hardware mehrere Betriebssys-teme installiert und unabhängig betrieben werden können. Zusätzliche SAP Application Server können auf der bestehenden Hardware flexibel dazugeschaltet werden. Damit können Lastspitzen des Systems flexibel verteilt werden. In ruhigeren Zeiten können «Hardware-Ressourcen» für andere SAP- und Nicht-SAP-Applikations-Anforderungen genutzt werden. Die verteilte Software-Architektur lässt es so zu, von Virtualisierung zu profitieren.
In derselben Art können auf den bereits bestehenden Systemen auch SAP-Prototyp-Sys-teme aufgebaut und zugeschaltet werden. Dieser Ansatz ist sehr beliebt, weil sonst für experimentelle SAP-Systeme zusätzliche Hardware beschafft werden muss. Auch das Risiko, dass Machbarkeitsstudien live an produktiven Systemen gemacht werden, wird damit reduziert. Bei SAP-Kunden findet man deshalb immer eine Anzahl «virtueller» SAP-Prototyp-Systeme im Systemportfolio. Sie werden auf den Systemen nach Bedarf auf- und wieder abgebaut.Weiter werden solche virtuellen Systeme für das SAP-Testing und die SAP-Schulung genutzt. Diese Systeme müssen laufend aufgebaut, initialisiert und wieder abgebaut werden. In Kombination mit einem umfassenden Change- und Transportmanagement, um das System auf dem richtigen Stand entsprechend dem Produktionssystem aufzubauen, zu initialisieren und zurückzusetzen, lässt sich eine ansonsten aufwendige Aufgabe elegant erledigen.
Die Kombination der Datenbanken der verschiedensten SAP-Applikationen in eine für den Nutzer einzige SAP-Datenbank ist eine Form von Datenbankvirtualisierung. Ein SAP Software Layer erlaubt den unterschiedlichen Execution Stacks – von aussen gesehen –, auf eine einzige Datenbank zuzugreifen.
Die Basis hierfür liefert SAP mit seiner über verschiedene Releases konsequent umgesetzten komponentenbasierten Software-Architektur. Im Release 4.0 wurden die ersten Schritte in diese Richtung gemacht. Zunächst waren allerdings die Basiskomponenten des Systems mit den Applikationskomponenten noch stark verknüpft. Jeder Execution Stack brauchte noch seine eigene Datenbank.
Mit dem SAP Netweaver Application Server wurden sämtliche Basis-Komponenten in das «SAP Netweaver Application Server»-Basis-System ausgelagert. Für die Datenbankvir-tualisierung wurde damit die notwendige Aufteilung von Application Server (Basis--Kompo-nenten) und Business-Logik (Business-Komponenten) vollständig erreicht. Die Informationen über die effektiven Abhängigkeiten zwischen Basis- und Business-Komponenten sind dabei in einem Komponentenmodell abgelegt, verwaltet und verfügbar.
Seit es SAP gibt, zeichnet sich die SAP-Lösung dadurch aus, dass ein einziges System in unterschiedlicher Ausprägung und mit sauber getrennten Daten verschiedenen Organisationen zur Verfügung gestellt werden kann. Der Fachbegriff hierfür heisst Mandantenfähigkeit. Dies ist im Prinzip nichts anderes als eine Form von Applikationsvirtualisierung.
Zu diesem Zweck enthalten applikatorische SAP-Datenbanktabellen die Mandanten-Nummer als Primary Key. Systemtabellen hingegen enthalten keine Mandantennummer im Primary Key. Beispiele hierfür sind die Tabellen, in welchen die SAP-Programme gespeichert sind. Auch Runtime-Informationen innerhalb eines SAP-Systems werden logischerweise mandantenunabhängig abgelegt. SAP-Customizing hingegen wird mandantenabhängig gespeichert. So kann ein SAP-System mit denselben Funktionen verschiedenen Organisationen mit sauberer Trennung ihrer spezifischen Daten und ganz anderer Ausprägung des Systems zur Verfügung gestellt werden.
Diese Form von Applikationsvirtualisierung lässt zu, mit einem einzigen System und seiner Datenbank potentiell den Systemmandanten und 998 weitere unterschiedlich ausgeprägte SAP-Kundensysteme zu betreiben.
Die systemtechnische Logik ist mandanten-unabhängig, der einzelne applikatorische Kontext je nach Mandant unterschiedlich. Der SAP--Kunde setzt typische Mandantenkonfigurationen auf unterschiedlichen Systemebenen ein:
?Entwicklungssystem
·Entwicklungsmandant, hier werden alle
Veränderungen am SAP-System vorgenom-
men – Programmierung und Customizing.
·Testmandant, um unterschiedliche Grund-
daten dem Entwickler zur Verfügung zu stellen. Meist findet man mehrere Testmandanten.
·eine Sandbox für experimentelles Customi-
zing-Prototyping.
?Qualitätssicherungssystem
·Testmandant
·Testdaten-Grundmandant
·Schulungsmandant
? Produktionssystem
· Produktionsmandant. Prinzipiell kann es mehrere solche Mandanten geben. Allerdings sieht es SAP nicht so gern, wenn mehrere produktive Mandanten auf demselben SAP-System liegen.
Das Mandantenkonzept bildet einen wichtigen Erfolgsfaktor bei einer SAP-Implementierung, insbesondere beim Change- und Transportmanagements. Dieses muss umgekehrt unbedingt auf das jeweilige Mandantenkonzept abgestimmt sein, denn bei einer Vielzahl von logischen Systemen erhält man nur so eine konsistente System- und Mandantenlandschaft.
Virtualisierung auf verschiedensten Ebenen ist eines der Grundkonzepte von SAP. Umso wichtiger ist es, diese Konzepte zu verstehen und bei der Planung des SAP-Systems frühzeitig zu berücksichtigen. Es gilt, die Anforderungen an die virtuelle SAP-Landschaft umfassend zu definieren, angefangen von der Hardware und Betriebssystemvirtualisierung über die Applikations- bis hin zur Nutzung der Möglichkeiten der Daten-Virtualisierungen für eigene Erweiterungen. Kosten und Nutzen von unterschiedlichen Implementierung in Bezug auf die Virtualisierungsszenarien ergeben sich aus einfachsten Fragestellungen:
? Werden mehrere SAP-Test-Umgebungen benötigt?
? Sollen SAP-Schulungssysteme auf Knopfdruck bereitstehen?
? Braucht es Zusatz-SAP-Systeme, um in Zeiten mit Spitzenauslastung weitere Ressourcen zur Verfügung zu haben?
? Gibt es verschiedene Organisationen, die jeweils ihr eigenes SAP-System benötigen.
Die Unterstützung von individuellen Test- und Schulungsszenarien kann sowohl mit Betriebssystem- wie auch mit Applikationsvirtualisierung mit mehreren Mandanten angegangen werden. Beim Ansatz von mehreren Mandanten ist zu beachten, dass beim Initialisieren ganze Teile der Datenbank systemtechnisch überschrieben werden.
Für das Virtualisierungsverfahren gilt unter allen Umständen, dass es von SAP selbst zertifiziert sein muss. Ansonsten ist es aus SAP-Sicht nicht zulässig und wird nicht unterstützt.
Es liegt an jedem SAP-Kunden selbst, zu entscheiden, inwieweit es Sinn macht, Betriebssystem- und Datenbankvirtualisierung produktiv zu nutzen. Die Möglichkeiten sind vorhanden. Zu schade, wenn dieses Potential des SAP-Systems nicht konsequent genutzt wird.
