Von UNIX zu Linux in SAP Rechenzentren: Groß. Kritisch. Über alle Grenzen hinaus.

Größe: px
Ab Seite anzeigen:

Download "Von UNIX zu Linux in SAP Rechenzentren: Groß. Kritisch. Über alle Grenzen hinaus."

Transkript

1 Von UNIX zu Linux in SAP Rechenzentren: Groß. Kritisch. Über alle Grenzen hinaus. Helmut Spöcker Consulting Manager REALTECH Consulting Oktober 2012

2 Inhalt Management Summary... 4 Was seitdem passiert ist... 9 Statistiken neu aufgelegt Allgemeine Betriebssystemtrends Linux-spezifische Betriebssystemtrends Zum Thema Datenbanken Entwicklungen im Preis-Leistungs-Verhältnis Virtualisierung neu bewertet Green IT neu bewertet Groß. Kritisch Große Systeme Große Kunden & große Migrationsprojekte Hochverfügbarkeit & andere Formen hoher Kritikalität Hochverfügbarkeits-Tools für SAP auf Linux SUSE Linux Enterprise Server High Availability Extension Hochverfügbarkeit mit Red Hat Enterprise Linux SteelEye LifeKeeper Veritas Cluster HP MC ServiceGuard IBM PowerHA / HACMP Andere Formen und ein neues Verständnis von HA und Kritikalität Über alle Grenzen hinaus Minima unterschreiten Maxima überwinden Schlussfolgerungen REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 2 -

3 Nachwort Anhang Vollständige Auswertungstabelle (in der EURO/SAPS Reihenfolge) Vergleich der grundlegenden Betriebssystem-Support-Kosten Vergleich von Server-Abwärme bei gleicher CPU Quellenangaben Über REALTECH... 78

4 Management Summary Als im Jahr 2008 das erste UNIX zu Linux -Whitepaper veröffentlicht wurde, konnte niemand auch nur ahnen, welche Entwicklungen es anstoßen würde. Die Schlussfolgerungen waren eindeutig: Linux ist den Anforderungen von SAP-Rechenzentren gewachsen. Die Leistung stimmt. Und ebenso der Funktionsumfang. Die Kosten mit x64 sind erheblich niedriger als mit jeder anderen CPU-Architektur. Die Überführung betrieblicher Abläufe ist von UNIX zu Linux deutlich einfacher als von UNIX zu Windows. Und Kosten sind nicht vom Betriebssystem abhängig, sondern viel mehr eine Frage der CPU-Architektur. Danach veröffentlichte REALTECH ein zweites Whitepaper, das neben der eindeutigen Überlegenheit im Preis-Leistungs-Verhältnis auch Entwicklungs- und Umweltaspekte als zusätzliche Entscheidungsfaktoren für Linux/x64 ins Feld führte. Jetzt, fast vier Jahre später, untersuchen wir mit diesem Unix zu Linux -Whitepaper, inwieweit unsere Annahmen und Prognosen aus den Jahren 2008 und 2009 zutreffend waren. Zudem werfen wir einen Blick auf die Grenzen und Einschränkungen, auf die wir gestoßen sind, und berichten über unsere Erfahrungen. Nimmt man alle Regionen, alle Ausgangssysteme und alle Zielsysteme der REALTECH- Migrationen mit gleichzeitigem Betriebssystemwechsel während der Auswertungsperiode in Betracht, so kommen 92% der Quellsysteme (aber nur sehr wenige der Migrationsziele) von UNIX, was unsere früheren Beobachtungen und Prognosen eindeutig bestätigt. UNIX verliert insgesamt 77% der Marktanteile, wobei HP-UX mit 46% der Hauptverlierer ist. Linux andererseits gewinnt 56% und Windows 23%. Für die x64-cpu-architektur bedeutet dies einen Zuwachs an Marktanteilen von insgesamt 79%, während alle anderen Architekturen eben diese Anteile einbüßen. 95% aller REALTECH-Migrationen auf Linux erfolgen ausgehend von einem der drei großen UNIX-Derivate. Bei der Wahl der Datenbank scheint DB2 LUW in der Welt von Linux und UNIX als die Alternative zu Oracle gehandelt zu werden. Beschränkt man die Betrachtung auf das Preis-Leistungs-Verhältnis, so ist die noch stärkere Dominanz der x64-plattformen auf diesem Gebiet besonders auffällig. Die 13 bestplatzierten CPUs in der Preis-Leistungs-Bewertung sind alle Teil der x64-familie. Der einzige konkurrenzfähige UNIX-Prozessor ist der Power-Prozessor, und hier hat IBM tatsächlich hervorragende Arbeit geleistet und mit der Einführung des Power7 die Wettbewerbsfähigkeit von AIX zu seinen Gunsten verbessert. Doch auch eine Power7-Blade-Plattform erhöht die Kosten pro SAPS immer noch um 74%, selbst wenn man IBM als bevorzugtem Anbieter treu bleibt, und 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 4 -

5 es gibt kostengünstigere Angebote von anderen Anbietern. Betrachtet man die anderen UNIX-Prozessoren, so kann keiner von ihnen auch nur annähernd in diesem Wettbewerb mithalten. Wenn Sie als SAP-Kunde um die Gesamtkosten für Ihre SAP-IT-Infrastruktur besorgt sind und Sie durch bessere SAPS-Leistung bei weniger Ausgaben die Kosten für Ihre Server reduzieren wollen, so kommen weder SPARC noch Itanium für Sie infrage. Wir werden zeigen, dass ein REALTECH-Migrationskunde allein durch die Umstellung auf Linux und x64 die Kosten für seine SAP-Server um mehr als 80% senken und dabei gleichzeitig die verfügbare SAP-Rechenleistung mindestens verdreifachen konnte. Es gibt einen weiteren unverkennbaren und wichtigen Technologietrend: Multi-Sockel-Server- Systeme sind längst nicht mehr zeitgemäß, da sie viel zu teuer sind. Wir werden in diesem Whitepaper anhand von zwei Beispielen zeigen, dass REALTECH-Kunden durch die Ablösung dieses Architekturansatzes schon jetzt mehrere hunderttausend Euro pro Jahr einsparen oder in Zukunft einsparen werden. Die Leistung, die pro Kern erzielt wird, ist besonders für Kunden von Bedeutung, deren SAP-Datenbank-Lizenzen an ihre Prozessorkerne gekoppelt sind: Hier sind die Lizenzkosten unmittelbar von der Anzahl der Kerne abhängig, die für die Erfüllung der Leistungsanforderungen benötigt wird. In größeren Unternehmen gelten derartige Verträge in der Regel sowohl für die SAP- als auch für die Nicht-SAP-Datenbankumgebungen. Hier schneidet Power sehr gut ab. Wenn diese Kennzahl für Sie von Bedeutung ist, Sie aber kein Interesse an einer Power- Architektur haben, zum Beispiel weil Sie sich bereits für eine x64-prozessorarchitektur entschieden haben, so sind Intel-Prozessoren (nicht AMD) die richtige Wahl für Sie. Diese führen so ziemlich allein die verbleibende Rangliste an. Während die Leistung pro Kern für die Datenbanken eine wichtige Rolle spielt, ist die Leistung pro Thread entscheidend dafür, wie sich die Gesamtleistung auf die SAP-Anwendungsebene auswirkt. Die optimale CPU-Architektur für SAP-Anwendungen stellen Multi-Threads mit maximaler Leistung pro Thread dar, und hier dominiert Intel eindeutig seine Konkurrenten Power und AMD. Itanium und SPARC sind wieder einmal hoffnungslos abgeschlagen und können weder bei der Leistung pro Kern noch bei der Leistung pro Thread mithalten. 64-Bit-X86-Xeon-CPUs von Intel sind wohl die beste Lösung sowohl für Ihre SAP-Anwendung als auch für Ihre SAP-Datenbank. Diese bilden die einzige Prozessorarchitektur, die bei allen Aspekten unserer Untersuchung einen Platz unter den Top 10 belegen konnte REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 5 -

6 Es gibt eine Reihe von technisch ausgereiften Virtualisierungslösungen für Linux in SAP- Umgebungen und die Grenzen ihrer Leistungsfähigkeit sind eher theoretischer als praktischer Natur. Als einzige Einschränkung sollte an dieser Stelle angemerkt werden, dass wir davon ausgehen, dass XEN-basierte Technologien langfristig wahrscheinlich ernste Probleme bekommen und möglicherweise nicht überleben werden. Aber abgesehen davon ist Virtualisierung heute eine weit verbreitete Lösung in der x64-welt. Das Thema, das unserem Whitepaper aus dem Jahr 2009 die größte Aufmerksamkeit bescherte, war die Auseinandersetzung mit Fragen der Green IT. Aufgrund einiger Widersprüche haben wir uns dieses Mal für einen neuen Ansatz bei der Untersuchung der Green-IT-Aspekte entschieden. Der Trend hin zu Linux in SAP-Rechenzentren ist in weiten Teilen eine Architekturentscheidung zugunsten der x86_64-prozessorarchitektur. Darum hat sich das Augenmerk unserer Green-IT- Betrachtung weg von den Servern und hin zum Energieverbrauch der CPUs verschoben. Der wichtigste Trend lässt sich dabei eindeutig zusammenfassen: x64-prozessoren von Intel und AMD liefern, ebenso wie der Power-Prozessor, durchaus positive Ergebnisse hinsichtlich ihres Energieverbrauchs. Dabei hat jeder einzelne seine eigenen Vorzüge und Qualitäten, die in verschiedenen Einsatzszenarien zum Tragen kommen. Mit Blick auf SAP-Anwendungen scheint der 64-Bit-X86-Xeon-Prozessor von Intel insgesamt die beste Mischung optimaler Eigenschaften zu bieten. SPARC und Itanium sind wieder einmal der Konkurrenz nicht gewachsen. Wie schon früher vorhergesagt, hat die Leistungsfähigkeit von Linux-Server-Systemen bereits beinahe alles erreicht oder sogar überschritten, was mit UNIX im Bereich des Möglichen liegt. Die Leistungswerte, die hier erzielt werden, liegen längst weit jenseits von allem, was heute an Rechenleistung für ein einzelnes System benötigt wird. Heutige x64-server werden niemals Engpässe verursachen, egal welche Anwendung Sie darauf laufen lassen. Die Quellen möglicher Engpässe liegen anderswo und stehen in keinem Zusammenhang mit Linux (oder jedem anderen Betriebssystem). Was den täglichen Betrieb angeht, gibt es praktisch keine Grenzen für die Größe der auf Linux einsetzbaren Systeme oder Datenbanken. Uns sind sehr große Datenbanken bekannt, die problemlos auf dieser Plattform laufen. Wir selbst haben Produktivsysteme mit bis zu 8 TB eingerichtet oder migriert und an noch größeren Systemen wird bereits gearbeitet. Ein kritischer Faktor, der jedoch unbedingt bedacht werden muss, ist die maximale Downtime, die für den eigentlichen Migrationsprozess zur Verfügung steht, besonders im Hinblick auf das Produktivsystem. Dies steht jedoch in keinerlei Zusammenhang mit der Ziel- CPU-Architektur oder dem Ziel-Betriebssystem REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 6 -

7 Ebenso wie die Größe der einzelnen Systeme kein wirkliches Hindernis (und keinen Nachteil) mehr darstellt, spielt auch die Größe des Unternehmens oder der Systemlandschaft keine Rolle mehr. REALTECH hat umfassende Projekte bei Unternehmen mit Milliardenumsätzen realisiert und Systemlandschaften mit circa 30 Produktivsystemen und hunderten Terabytes an Daten in Angriff genommen. Es ist alles eine Frage der richtigen Planung: Die vollständige Migration einer großen und historisch gewachsenen SAP-Systemlandschaft in einem großen Unternehmen ist sowohl unter technischen als auch unter organisatorischen Gesichtspunkten ein hochkomplexer Prozess, der eine Vielzahl von Entscheidungen und Vorgehensweisen erfordert, von denen Wohl und Wehe des Migrationsprojekts abhängen. Bitte lesen Sie die jeweiligen Kapitel, um detaillierte Informationen zu den Erfolgsfaktoren zu erhalten. Um ein großes Migrationsprojekt zum Erfolg zu führen, bedarf es einer realistischen Planung, eines machbaren Zeitrahmens, erfahrenes Projekt- Management auf beiden Seiten und sachkundiger Migrationsexperten. Wenn man den richtigen Ansatz wählt, stellen die Größe oder Kritikalität eines Kunden, Projekts oder einer Landschaft beim Übergang von UNIX zu Linux keinerlei Hindernis dar. Eines muss jedoch betont werden: Die Fehlerpotenziale in Migrationsprojekten, die wir in dieser Analyse darlegen werden, sind zwar bei allen Migrationen gleich, aber in besonderem Maße typisch für Migrationsprojekte von UNIX zu Linux. Dies hängt wiederum wesentlich damit zusammen, dass sich UNIX und Linux so sehr ähneln, dass allzu oft irrtümlich davon ausgegangen wird, dass beide identisch seien. Das sind sie nicht! Um Fehler zu vermeiden, die aus dieser Ähnlichkeit entstehen, sollten Sie sich unbedingt um eine gute Migrationsberatung bemühen. Hochverfügbarkeit (HA), besonders in SAP-Umgebungen, ist ein Prozess und sollte auch immer als ein solcher verstanden werden. Das heißt auch, dass, egal welche Lösung Sie für die Sicherstellung von Hochverfügbarkeit erwerben, diese Ihre Stabilitätsprobleme nicht lösen wird, wenn Ihre IT-Administration den Herausforderungen beim Betrieb einer kritischen Umgebung nicht gewachsen ist. IT-Manager können das leicht für sich überprüfen. Haben Sie sich schon bei folgenden oder ähnlichen Gedanken ertappt: Ich verstehe nicht, wo unser Problem liegt. Ich habe schließlich für Hochverfügbarkeit bezahlt! Dann haben Sie den falschen Weg eingeschlagen. Es gibt jedoch Hochverfügbarkeits-Tools für Linux, die Ihnen bei der Etablierung des Hochverfügbarkeitsprozesses helfen können. Von allen für Linux verfügbaren Hochverfügbarkeits-Frameworks bietet nach unserem Dafürhalten SUSE Linux Enterprise Server High Availability Extension die engste und beste Integration mit SAP- Anwendungen, einschließlich der benötigten Zertifizierung für das neue generische HA-Interface von SAP. SUSE bietet SUSE Linux Enterprise Server und die HA-Erweiterung gemeinsam in SUSE Linux Enterprise Server for SAP Applications als voll integriertes und komplettes 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 7 -

8 Servicepaket an, das mit Blick auf die speziellen Anforderungen von SAP-auf-Linux-Anwendern zusammengestellt wurde und unserer Meinung nach ein sehr attraktives Angebot darstellt. Die Bedeutung dieses Paketangebots und von SUSE im Allgemeinen wird noch durch die Tatsache verstärkt, dass SAP eine Reihe wichtiger Produkte aus seinem Portfolio (z.b. HANA) exklusiv auf SUSE Linux ausliefert. Linux und die x64-cpu-architektur sind längst erfolgreich im SAP-Rechenzentrum angekommen. Sie eignen sich ideal für die Bereitstellung von Systemlandschaften, die höchsten Ansprüchen an Leistungsfähigkeit und Kritikalität gerecht werden. Demgegenüber sind einige UNIX-Derivate langfristig dem Untergang geweiht. Für Kunden, die mit der Ablösung überholter Architekturen zu lange warten, können sich verschiedene Probleme ergeben. Diese können technischer oder wirtschaftlicher Natur sein oder durch Zeitdruck entstehen, wenn große Infrastrukturen schnell ersetzt werden müssen. Wir raten deshalb zu schnellem Handeln. Bringen Sie den Übergangsprozess jetzt auf den Weg! 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 8 -

9 Was seitdem passiert ist Als im Jahr 2008 das erste UNIX zu Linux -Whitepaper veröffentlicht wurde, konnte niemand auch nur ahnen, welche Entwicklungen es anstoßen würde. In mancherlei Hinsicht war es fast so, als wäre zum ersten Mal ausgesprochen worden, was viele bereits wussten und noch viele mehr vermutet hatten, aber niemand zuvor beim Namen hatte nennen wollen. Die Schlussfolgerungen waren eindeutig: Linux ist den Anforderungen von SAP-Rechenzentren gewachsen. Die Leistung stimmt. Und ebenso der Funktionsumfang. Die Kosten mit x86_64 (im Folgenden nur noch x64 ) sind erheblich niedriger als mit jeder anderen CPU-Architektur. Die Überführung betrieblicher Abläufe ist von UNIX zu Linux deutlich einfacher als von UNIX zu Windows. Und im Hinblick auf die Kosten lässt sich mit Sicherheit sagen, dass sie nicht vom Betriebssystem, sondern vielmehr von der CPU-Architektur abhängig sind. Als Reaktion auf das Whitepaper nahm das Interesse an REALTECH-Dienstleistungen im Bereich Infrastruktur-Analyse und Migration deutlich zu. In der Folge wurden Service-Kontakte mit einigen Weltmarktführern geknüpft oder neu belebt, darunter der weltgrößte Rückversicherer, das weltgrößte Chemieunternehmen, einige der größten europäischen Automobilhersteller, führende Banken und eine Reihe anderer Unternehmen. Sie alle wollten mehr über die Optionen, Vorgehensweisen, Kosten, Folgen und Vorteile erfahren, die sich aus der Einführung von x64 und Linux für SAP und der Ablösung ihrer bisherigen Kombination aus CPU-Architektur und UNIX-Betriebssystem ergeben würden. Intel, der weltweit größte Chip-Hersteller, trat an REALTECH mit der Bitte heran, weitere Untersuchungen durchzuführen und die Architekturaspekte im SAP-Computing noch tiefgreifender zu erforschen. Das taten wir dann auch und veröffentlichten ein zweites Whitepaper, das neben der eindeutigen Überlegenheit im Preis-Leistungs-Verhältnis auch Entwicklungs- und Umweltaspekte als weitere Gründe lieferte, auf einen Zug aufzuspringen, der im Begriff war, stetig und unaufhaltsam immer mehr Fahrt aufzunehmen. Bezogen auf das daraus resultierende Marktinteresse war dieses zweite Whitepaper aus dem Jahr 2009 sogar noch erfolgreicher als sein Vorgänger Novell (damals, heute SUSE) und REALTECH haben irgendwo bei 20,000 Downloads 1 und zahlreichen direkten Kontakten mit dem Zählen aufgehört. Was dem zweiten Whitepaper allerdings fehlte, war eine aussagekräftige statistische Basis, auf der man einige unserer Beobachtungen und Trendprognosen aus dem ersten Whitepaper hätte bestätigen oder widerlegen können. Der Grund dafür lag in der zu kurzen Zeit, die seit dem ersten Whitepaper vergangen war. Dieser wichtige Aspekt wird nun in diesem dritten UNIX zu Linux -Whitepaper beleuchtet: In diesem Whitepaper blicken wir zurück und untersuchen, ob 1 Einige davon sogar noch im 3. Quartal REALTECH Consulting Helmut Spöcker Oktober 2012 Seite - 9 -

10 unsere Annahmen und Vorhersagen von 2008 und 2009 zutreffend waren und bewerten sie anhand von einigen hundert Produktivsystemmigrationen, die in den letzten dreieinhalb Jahren erfolgreich von REALTECH zum Go-Live gebracht wurden. Zudem untersuchen wir, ob die ursprünglich vorhergesagten Reduzierungen im Preis-Leistungs-Verhältnis wirklich erreicht wurden und welche CPU-Architekturen davon in der Folge betroffen waren. Aber dieses Whitepaper hat noch mehr zu bieten. Nach vier weiteren Jahren, in denen wir Erfahrungen mit SAP auf Linux sammeln konnten, betrachten wir nun die Grenzen und Einschränkungen, auf die wir gestoßen sind, berichten über unsere Erfahrungen, legen dar, wie kritisch große Implementierungen mittlerweile geworden sind und zeigen, wie kritische Migrationsprojekte zum Erfolg geführt werden können. Darüber hinaus befassen wir uns mit den Fortschritten von Virtualisierungstechnologien und untersuchen Aspekte der Green IT. Statistiken neu aufgelegt Es gab eine Reihe von Gründen, warum weder das erste noch das zweite Whitepaper einen Überblick über allgemeine Migrationstrends lieferte. Seit der letzten Auswertungsperiode konnten wir jedoch ausreichend Daten zu den verschiedenen Merkmalen (Betriebssystem, Datenbank, Regionen) sammeln, um nicht nur die Quellen von Migrationen in Richtung Linux zu untersuchen (wie schon im Whitepaper von 2008), sondern auch einen umfassenderen Einblick in die Entwicklungen auf dem SAP-Server-Infrastruktur-Markt zu liefern. Wir hoffen sehr, dass dies für unsere Leser ebenso interessant ist, wie es das für uns war, als die Zahlen zum ersten Mal in Tabellen und Diagrammen aufbereitet wurden und einige sehr überraschende, spannende und für einige vermutlich beunruhigende Trends und Ergebnisse offenbar wurden. Die folgenden Regeln gelten für alle Statistiken und Auswertungen in diesem Abschnitt: (1) Alle Statistiken beinhalten und beziehen sich ausschließlich auf Produktivsysteme, die tatsächlich in den Produktivbetrieb auf der Zielplattform überführt wurden. (2) Nur SAP-Datenbankinstanzen finden Berücksichtigung. Anwendungs-Server und Anwendungsinstanzen sind für diese Statistiken unerheblich. (3) Die Auswertungsperiode erstreckt sich vom 1. Januar 2009 bis zum 31. Juli (4) Die Go-Lives wurden von zertifizierten REALTECH-Migrationsexperten durchgeführt REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

11 (5) Da sich dieses Whitepaper auf Entwicklungen im Bereich der Betriebssystem- und CPU- Architekturen konzentriert, wurden Datenbankmigrationen ohne Wechsel des Betriebssystems nicht in die vorliegenden Untersuchungen mit aufgenommen. 2 (6) Diese statistische Basis ist umfassend genug, um alle relevanten Kriterien umfassend zu untersuchen, und liegt meist im dreistelligen Bereich. Um sowohl unsere eigenen als auch die Interessen unserer Kunden zu schützen, stellen wir keine absoluten Zahlen oder genaue Auszählungen zur Verfügung. (7) Aufgrund der erreichten statistischen Bandbreite haben wir auf ganze Prozentzahlen aufgerundet. Sollten also die angegebenen Zahlen zusammen nicht genau 100% ergeben oder zwischen zwei Tabellen nicht genau zusammenpassen, so ist dies den Rundungsungenauigkeiten geschuldet. Wir haben keinen mathematischen Beweis, dass unsere Statistiken einen statistisch repräsentativen Querschnitt weltweiter Trends darstellen. Wir sind jedoch davon überzeugt, dass die strikte Herstellerunabhängigkeit von REALTECH uns einen sehr ausgewogenen Einblick in die wichtigsten Vorgänge auf dem SAP-Markt ermöglicht. Tatsächlich wurden unsere statistischen Beobachtungen aus dem ersten Whitepaper im Nachhinein sowohl auf nationaler Ebene in Deutschland durch RAAD Research und auf internationaler Ebene durch Gartner und IDC weitestgehend bestätigt. Da die absolute Zahl der Migrationen eindeutig zunimmt und die Auswertungsperiode länger ist als zuvor, halten wir unsere Daten und die daraus gezogenen Schlussfolgerungen für überaus genau. Allgemeine Betriebssystemtrends Zunächst sollten wir die allgemeinen Trends und Bewegungen beim Thema Betriebssysteme im SAP-Rechenzentrum betrachten. Nimmt man alle Regionen, alle Ausgangsysteme und alle Zielsysteme der REALTECH-Migrationen mit gleichzeitigem Betriebssystemwechsel während der Auswertungsperiode in Betracht, so kommen 92% der Quellsysteme von UNIX, jeweils 3% von OS/400 und Windows und 2% von... Linux. Ja, man könnte es durchaus als die erste Überraschung bezeichnen, dass es Migrationen von Linux weg gibt; es sind zwar nicht viele, aber es gibt sie tatsächlich. Im späteren Verlauf werden wir auch einen näheren Blick darauf werfen, was hier die möglichen Beweggründe sein könnten. Auf der anderen Seite, und dies ist wenig überraschend, musste UNIX sehr sehr herbe Verluste hinnehmen. Selbst wenn man alle möglichen Ziele und nicht nur Linux allein betrachtet, hat der relative und absolute Anteil jedes 2 Diese Statistiken liegen natürlich vor und Interessenten können sich direkt an REALTECH wenden, um zu erfahren, wie sie Zugang zu diesen Informationen erhalten können REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

12 einzelnen noch am Markt verfügbaren UNIX an den Quellsystemen im Vergleich zur Untersuchung in 2008 zugenommen und das, obwohl sich die damalige Untersuchung ausschließlich auf Linux-Ziele bezog. Aus unseren Statistiken verschwunden sind lediglich die UNIXe, die bereits ihren letzten Atemzug getan haben. Seit 2009 hat REALTECH keine Migrationen weg von Tru64 oder Reliant mehr vorgenommen, obwohl sowohl die relative als auch die absolute Anzahl der Migrationen weg von UNIX signifikant gestiegen ist. Diese Plattformen sind ohne Zweifel vom Markt verschwunden und andere werden ihnen auf diesem Weg folgen. Wer ist also der größte Verlierer? Die Antwort ist eindeutig und wird Kenner der Materie und des Marktes kaum überraschen: HP-UX mit PA-RISC (sehr selten, da nur noch sporadisch vertreten) und Itanium (die überwiegende Mehrzahl) stellen mit Abstand die häufigste Migrationsquelle mit einem Anteil von insgesamt 47%. Unabhängig davon, ob die nächste Itanium-Generation wieder eine beeindruckende Leistungszunahme von 13% erreicht, oder ob HP seinen Rechtsstreit mit Oracle hinsichtlich der Fortführung des Supports für HP-UX/Itanium durch Oracle 12 gewinnen kann, haben die meisten Kunden ihre Entscheidung doch schon getroffen. Die Frage ist längst nicht mehr, ob sie die Plattform ablösen werden, vielmehr geht es nur noch um das Wann, das Wie und das Wohin. Aber auch die anderen UNIX-Anbieter, Oracle und IBM, sollten alarmiert sein. Schließlich machen AIX (29%) und Solaris (15%) zusammen weitere 44% der UNIX-Quellen aus. Und die Gewinner-Verlierer-Statistiken werden zeigen, dass diese Kunden längst nicht mehr nur von einem UNIX auf ein anderes umsteigen, wie es noch während der ersten Jahre des letzten Jahrzehnts häufig zu beobachten war. Die Mehrzahl kehrt der Familie der proprietären UNIXe endgültig den Rücken zu REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

13 Source Operating Systems - All Migrations 4% 3% 2% 15% 29% AIX HP- UX Solaris Windows AS/400 Linux 47% Mainframes sind als Migrationsquelle für REALTECH vollständig verschwunden, höchstwahrscheinlich weil ihr Marktanteil beim SAP-Kundenstamm insgesamt kaum nennenswert ist. Laut unserer (im Allgemeinen immer sehr gut informierten) Quellen, gibt es mittlerweile weniger als 300 Kunden (weltweit), die ihre SAP-Produkte noch auf zseries-mainframes oder OS/390 betreiben eine Zahl, die angesichts der insgesamt 78,000 von SAP berichteten Kunden kaum ins Gewicht fällt. Da wir diese Annahme aber nicht beweisen können und auch nicht mutmaßen wollen, werden wir der Mainframe-Plattform in diesem Whitepaper keine weitere Aufmerksamkeit widmen. Betrachtet man die Zahlen insgesamt, ist ihre Bedeutung einfach zu gering. Das gleiche gilt für die iseries und OS/400 3 wenn es uns einmal begegnet, dann nur als Migrationsquelle, aber durch den geringen Marktanteil ist dies wirklich nur sehr selten der Fall. Wir wissen jetzt, dass UNIX 92% der Ausgangsysteme ausmacht und dass es ein klein wenig Bewegung in so gut wie jeder Betriebssystemfamilie gibt. Aber was sind die Migrationsziele? Auch hier gilt, dass bei Betrachtung aller Migrationen mit Betriebssystemwechsel (und nur dieser) in allen Regionen und über die gesamte Auswertungsperiode hinweg klare Gewinner und Verlierer eines weltweiten Trends offenbar werden: 58% aller REALTECH-Migrationen erfolgten hin zu Linux, 27% in Richtung Windows. Das sind sicherlich gute Nachrichten für SUSE, Red Hat 3 In den Statistiken und Tabellen einfachheitshalber als AS/400 aufgeführt, auch wenn dies nicht zu 100% den IBM- Namenskonventionen entspricht REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

14 und Microsoft, aber Intel und AMD können sich sogar noch mehr freuen: Unsere Statistik ist nämlich gleichbedeutend mit der Aussage, dass 85% unserer Migrationen die x64-cpu- Architektur zum Ziel haben. Weder Linux auf Power, noch Linux oder Windows auf Itanium, welche von Red Hat und Microsoft ohnehin nicht mehr unterstützt werden (und es wird erwartet, dass SUSE mit SUSE Linux Enterprise Server 12 nachfolgen wird), spielen auf dem Markt noch eine Rolle. Target Operating Systems - All Migrations 7% 1% 7% 58% 27% AIX HP- UX Solaris Windows Linux Wo es klare Gewinner gibt, können die Verlierer nicht weit sein. AIX und Solaris verteidigen ihren schwachen Zielanteil von jeweils 7%. Und ja, Sie können Ihren Augen trauen, wir hatten tatsächlich ein Projekt und einen Kunden, der sich für HP-UX auf Itanium entschieden hat. Dieses Projekt macht jedoch gerade einmal 1% der Ziele aus, wurde im allerersten Quartal der Auswertungsperiode durchgeführt und sticht als das weltweit einzige Projekt mit diesem Migrationsziel hervor. Zudem ist es ein hervorragendes Beispiel für das, was wir eine politisch motivierte Migration nennen. Dabei spielen weder technische noch wirtschaftliche Überlegungen eine Rolle: Politisch motivierte Migrationen sind in der Regel das Resultat eines Fusions- oder Übernahmeprozesses, bei dem die kleinere IT die SAP-Plattform der größeren übernehmen muss, egal ob dies nun sinnvoll ist oder nicht. Im Jahr 2005 haben wir sogar ein Projekt durchgeführt, bei dem ein amerikanisches Unternehmen mit einer AS/400-basierten SAP-IT ein deutsches Unternehmen aufgekauft hatte, das über eine relative neue Linux-basierte SAP-IT 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

15 % verfügte und zur Migration gezwungen wurde. Zudem muss auf etwas hingewiesen werden, was aus den reinen Zahlen nicht hervorgeht: Während die 7% AIX-Ziele im hohen Maße darauf zurückzuführen sind, dass Unternehmen ihre SAP-IT bewusst auf der Power-Plattform konsolidiert haben, sind die 7% Solaris-Ziele zum größten Teil die Folge eines sehr großen, politisch motivierten Projekts: Ein großes Finanzinstitut mit einer Solaris-basierten SAP-IT fusionierte mit einem anderen, ähnlich großen Finanzinstitut, bei dem AIX im Einsatz war, und zwang es zur Migration. Dieser Prozess zog sich jedoch über drei Jahre hin und in der Zwischenzeit wurde ein neues Kostensenkungsprogramm beschlossen. Als Ergebnis werden neue SAP-Produkte ausschließlich auf Linux implementiert und bestehende SAP-Systeme sollen so schnell wie möglich nachgezogen werden. Das heißt auch, dass ein guter Teil der 7%, die Solaris in dieser Auswertungsperiode gewinnen konnte, sich in der nächsten in einen Verlust verwandeln werden. Hinzu kommen noch die Systeme in besagter Finanzinstitution, die in den letzten Jahren auf Solaris und der SPARC-CPU betrieben wurden. Das heißt, dass die 7% Zielanteil für Solaris und AIX zwar zunächst als gleichwertig erscheinen, die jeweilige Bedeutung dahinter aber eine vollkommen andere ist. Die spätere Betrachtung der CPU-Eigenschaften und der Entwicklungen im Preis-Leistungs-Verhältnis werden zeigen, warum das so ist. Operating System Win/Loss - All Migrations Unix Linux Windows AS/400 AS/400 Windows Linux Solaris HP- UX AIX Um die Interpretation zu erleichtern, haben wir unsere Ergebnisse in einer Gewinn-Verlust- Statistik zusammengefasst, wie man sie auch von Wahlen her kennt. Tatsächlich ist dies 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

16 gewissermaßen eine Wahl. Und natürlich gelten auch hier die Regeln der Mathematik: UNIX verliert insgesamt 77% der Marktanteile, wobei HP-UX mit 46% der Hauptverlierer ist. Linux andererseits gewinnt 56% und Windows 23%. Für die x64-cpu-architektur bedeutet dies einen Zuwachs an Marktanteilen von insgesamt 79%, während alle anderen Architekturen eben diese Anteile einbüßen. Bisher haben wir die Frage nach den Verlierern und Gewinnern beantwortet, haben aber noch kein Wort darüber verloren, in welchen Teilen der Welt all dies passiert. Für uns ist es ganz besonders interessant, dass, obwohl unsere Niederlassungen in Europa insgesamt größer sind als die in Nord- und Südamerika oder dem asiatisch-pazifischen Raum (APAC), die Anzahl der durchgeführten Migrationen absolut vergleichbar ist, mit nur einem kleinen Vorsprung auf Seiten der Europäer. Dies gibt uns eine ausreichende statistische Basis für alle Regionen. Die regionale Verteilung von Migrationsprojekten ist tatsächlich äußerst interessant und wenn man bei Intel und AMD die Champagnerkorken bisher noch nicht hat knallen lassen, dann ist es spätestens jetzt Zeit dafür: In Nord- und Südamerika, mit Schwerpunkt auf Kanada und den USA, beläuft sich der kombinierte Marktanteil von Windows und Linux an den Migrationszielen auf 100%. Es ist nicht wirklich verwunderlich, dass in diesem Teil der Welt Windows als Migrationsziel Linux gegenüber im Vorteil ist. Das hat zwei Hauptgründe: Der durchschnittliche 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

17 amerikanische oder kanadische SAP-Kunde, der sich heute für eine Migration entscheidet, ist immer noch erheblich kleiner 4 als die Kunden in Europa und in der Regel zu klein, um ein Interesse daran zu haben, im Backend beide Betriebssystemwelten zu betreiben. Außerdem hinkt der amerikanische SAP-Markt dem europäischen gut zwei bis drei Jahre hinterher, was sich sehr gut an der SAP-Produkt- und -Release-Verteilung auf beiden Seiten des Atlantiks ablesen lässt. Mit ähnlicher Verzögerung denken größere UNIX-Betreiber nun über einen Plattformwechsel nach und der Trend zeigt eindeutig, dass mit zunehmender Größe auch die Wahrscheinlichkeit steigt, dass sie sich für eine Migration ihrer SAP-Infrastruktur zu Linux und nicht Windows entscheiden. Dies entspricht dem Trend, den wir auch in Europa nur einige Jahre zuvor beobachten konnten. In Nord- und Südamerika, wo Microsoft traditionell bevorzugt wird, könnte der Trend langfristig auf ein klares Unentschieden zwischen Linux und Windows hinauslaufen. Die aktuelle Verteilung liegt bei 37% für Linux und 63% für Windows. Aber was bedeutet das für UNIX? Wow! Werfen wir also einen Blick auf Europa, dem wohl immer noch wichtigsten Markt für SAP. Auch hier haben wir mit einem kombinierten Anteil von 83% an den Migrationszielen wieder gute Nachrichten für Intel und AMD. Die Kluft zwischen Linux und Windows ist jedoch eklatant: Linux stellt 80% der Migrationsziele, man kann also mit Fug und Recht sagen, dass Europa sich für Linux entschieden hat. Dies hängt eng mit der Kundenstruktur zusammen, bei der die Verschiebung hin zu x64 und Linux in Europa angekommen ist. Hierbei handelt es sich um die größten Unternehmen am Markt. REALTECH allein hat mit 14 DAX 30-Unternehmen über SAP-Linux-Projekte gesprochen. Eine ganze Reihe davon haben sich für eine Implementierung in naher Zukunft entschlossen oder haben den Schritt bereits getan. Und es ist bekannt, dass einige der Unternehmen, mit denen wir nicht gesprochen haben, die Implementierung selbst durchgeführt haben, unter ihnen die Deutsche Telekom, die bereits zum Zeitpunkt des ersten UNIX zu Linux -Whitepapers ein SUSE-Linux-Referenzkunde war. Alle diese Unternehmen hatten die Jahre zuvor sehr große UNIX-Umgebungen betrieben und keines der REALTECH bekannten Unternehmen entschied sich für Windows anstelle von Linux. Gleichzeitig fiel bei praktisch allen die Wahl auf x64 5, hauptsächlich aufgrund von Kostenerwägungen. Anders als in Nord- und Südamerika verteidigen kommerzielle UNIXe in Europa einen Zielanteil von 17%, wobei die Quellen in der Regel andere kommerzielle UNIXe sind. Dieser Trend zeigt aber eindeutig nach unten. Außerhalb Deutschlands haben wir übrigens mit einigen der größten 4 Bezogen auf die SAP-Systemlandschaft. 5 Keiner aus dieser Gruppe der Großen 30 in Deutschland mit denen wir sprechen konnten, hat sich bisher für Solaris auf x64 entschieden, auch nicht langjährige Kunden von Solaris auf SPARC. Das gleiche gilt für den Rest unseres Kundenstammes, unabhängig von der Größe des Unternehmens REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

18 europäischen Banken, Fluggesellschaften und High-Tech-Unternehmen über SAP auf Linux gesprochen. Niemand fehlt und jede Unternehmensgröße ist vertreten. Was Linux für Europa ist, ist Windows für den asiatisch-pazifischen Raum, zumindest jetzt noch. 69% unserer Migrationen in der Region haben das Microsoft-Betriebssystem zum Ziel. UNIXe belegen hier mit 22% den zweiten Platz und Linux muss mit enttäuschenden 9% noch viel Boden gutmachen. Wie schon zuvor bei der Untersuchung der regionalen Verteilung angesprochen, gibt es hierfür zwei hauptsächliche Gründe: den Markt und die Kundenstruktur. Wenn der amerikanische Markt dem europäischen in vielen Belangen um zwei oder drei Jahre hinterherhinkt, so tun dies die SAP-Märkte im asiatisch-pazifischen Raum um weitere zwei oder gegenüber dem amerikanischen. Dies lässt sich für viele Entwicklungen festhalten und der Trend von UNIX zu Linux gehört zweifellos dazu. Als Folge haben viele Kunden vergleichsweise kleine SAP-Landschaften und nur wenige SAP-Produkte in ihrem Rechenzentrum, hauptsächlich ERP und BW, was genau der Kundenstruktur entspricht, die REALTECH noch vor zehn Jahren in Europa angetroffen hat. Und damals führten wir weit mehr Migrationen zu Windows durch als zum gerade erst aufkommenden Linux. Dies betraf in der Regel kleinere Unternehmen, die sich zu dieser Zeit UNIX-Umgebungen schlichtweg nicht leisten konnten. Die größeren Unternehmen im asiatisch-pazifischen Raum tendieren immer noch dazu, von einem kommerziellen UNIX auf ein anderes umzustellen. Ein Trend jedoch ist bereits in der APAC-Region angekommen: Das langsame Verschwinden des Itanium-Prozessors. Es ist nicht nur so, dass weder Windows noch Linux auf Itanium irgendeine Rolle spielen. Wenn wir sagen, dass 22% der Ziele in der APAC-Region kommerzielle UNIXe sind, dann bezieht sich dies ausschließlich auf AIX auf Power und Solaris auf SPARC. Nebenbei bemerkt: Keine Geschäftstätigkeit in Afrika? Das trifft zu. Zumindest für REALTECH ist dieser Teil der Welt wenig erschlossen, jedenfalls bisher REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

19 Linux-spezifische Betriebssystemtrends Im Whitepaper von 2009 machten wir folgende Aussage: Sollte der derzeitige Trend noch für weitere ein oder zwei Jahre anhalten, so werden die unterstützten UNIX-Derivate zukünftig weit mehr als 80% der Ausgangsbetriebssysteme für REALTECHs Linux-Migrationen ausmachen. Der Anteil der (derzeit) abgekündigten Plattformen wird auf Null oder zumindest nahe Null fallen... Source Operating Systems - Migrations to Linux 5% 11% 26% AIX HP-UX Solaris Windows 58% Nachdem wir gerade festgestellt haben, dass 92% aller Migrationsquellen die noch unterstützten UNIX-Derivate sind und Linux 58% aller Ziele ausmacht, ist es keine wirkliche Überraschung mehr, dass sich unsere Prognose bewahrheitet hat. Heute erfolgen 95% aller REALTECH- Migrationen nach Linux ausgehend von einem der drei UNIX-Derivate, die noch in SAPs PAM 6 zu finden sind. Und wieder ist HP-UX mit 58% der Quellen der weitaus größte Verlierer. Die Anteile von AIX und Solaris sind ebenfalls gestiegen, die Erosionsgeschwindigkeit ist jedoch bei weitem nicht so dramatisch. Wie vorhergesagt haben Tru64 und Reliant keinerlei Relevanz mehr. Einigermaßen überraschend war für uns die Tatsache, dass die IBM iseries und zseries als Quellen für eine Migration nach Linux vollkommen verschwunden sind und für iseries-kunden Windows mittlerweile das bevorzugte Ziel ist. 6 Platform Availability Matrix REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

20 Mit Blick auf Microsoft hatten wir vorausgesagt, dass... der Anteil der Windows-Kunden, die sich für Linux entscheiden, auf unter 10% fallen wird. Auch diese Annahmen war zutreffend und selbst für die noch verbleibenden 5% gibt es einleuchtende Erklärungen, von denen allerdings keine einzige technischer Natur ist. Ungefähr 2% aller Windows-Quellen für eine Migration nach Linux sind auf politisch motivierte Projekte zurückzuführen, dabei war von Fusionen und Übernahmen über die Zentralisierung der IT-Ressourcen eines Unternehmens in weniger Rechenzentren bis hin zur Übernahme einer kleineren Organisation durch eine größere alles dabei. Umgekehrt sind dies genauso die Gründe für die weiter oben angesprochenen 2%, die Linux verloren hat. Die verbleibenden 3% der Windows-Quellen für eine Migration nach Linux sind in der Regel eine Nebenerscheinung einer großen UNIX-Migration. In diesen Fällen ist das übliche Szenario, dass für einige kleinere Systemlandschaften, die zu einem späten Zeitpunkt im Lebenszyklus der allgemeinen SAP-Umgebung aufgesetzt wurden, Windows anstelle der teureren UNIXe verwendet wurde, und diese im Rahmen einer Konsolidierung auf Linux jetzt mitgezogen werden. Die typischen SAP-Produkte hierbei sind EBP, Enterprise Portale und Solution Manager. Zum Thema Datenbanken Was wir bisher noch nicht angesprochen haben, sind die Auswirkungen, sollte es überhaupt welche geben, auf den Bereich der Datenbanken. Im 2008er Whitepaper haben wir festgestellt, dass Oracle und MaxDB etwa gleich schnell Marktanteile gewinnen konnten, während DB2 und SQL-Server mit Blick auf Linux-Ziele Einbußen zu verzeichnen hatten. In dieser Hinsicht haben sich viele Dinge grundlegend geändert. Nicht das Microsoft mittlerweile eine SQL-Server-Version für Linux entwickelt hat, aber abgesehen davon... Lassen Sie uns zunächst aber einen Blick auf die allgemeine Entwicklung werfen. Wenn man hier wiederum nur Migrationen mit gleichzeitigem Betriebssystemwechsel betrachtet, so hat SQL-Server laut der von REALTECH beobachteten und mitgetragenen weltweiten Entwicklungen bemerkenswerte 19% an Marktanteilen zugelegt. Angesichts der Tatsache, dass Windows insgesamt einen Zielanteil von 27% hat, lässt sich also festhalten, dass mehr als zwei von drei Kunden, die einen Umstieg auf Windows vollziehen, sich gleichzeitig auch für eine Datenbank vom gleichen Hersteller entscheiden. Ein weiterer Gewinner bei den Marktanteilen ist DB2, oder genauer gesagt, DB2 LUW. Die Datenbank profitiert eindeutig davon, dass iseries und zseries nur noch selten als Quelle vorkommen und so die Verluste für die 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

21 Mainframe-DB2-Version reduziert wurden. Und wie wir noch sehen werden, scheint DB2 LUW in der Welt von Linux und UNIX als die Alternative zu Oracle gehandelt zu werden. Wer gehört also zu den Verlierern? Die Zahl der Verdächtigen wurde ja bereits eingegrenzt. Und ja, in einigen Teilen der Welt fanden sich sogar noch Informix-Kunden, die einen Wechsel vollziehen mussten. Aber diese Projekte fanden zum größten Teil in den ersten Jahren der Auswertungsperiode statt und sind heute nicht mehr von Bedeutung. Viel bemerkenswerter ist, dass die Gewinnserie von MaxDB ein Ende gefunden hat. In den frühen Jahren von SAP auf Linux war die Kombination des Open-Source-Betriebssystems mit einer (fast und eine Zeit lang sogar tatsächlich) Open-Source-Datenbank eine äußerst beliebte Wahl, ganz besonders bei kleineren Linux-Migrations-Kunden mit einem UNIX/Oracle- oder Windows-mit-beliebiger- Datenbank-Hintergrund. Da die durchschnittlichen Linux-Migrations-Kunden heute aber erheblich größer sind, schlagen sie einen von zwei anderen Wegen ein: Entweder sie kommen von einem Oracle-Hintergrund und bleiben auch dabei, oder sie kommen von einem Oracle-Hintergrund und entscheiden sich für DB2 7. Die Marktentwicklung für MaxDB ist mittlerweile weitestgehend zu einem Stillstand gekommen. Kleinere Kunden, die bereits Linux/MaxDB einsetzen, entscheiden sich nicht mehr für einen Wechsel, warum sollten sie auch? Nach allem was wir hören, ist diese Betriebssystem/Datenbank-Plattform unschlagbar stabil und verursacht dabei so gut wie keinen administrativen Aufwand. Andererseits entscheiden sich größere Organisationen gar nicht erst für diese Kombination, warum sollten sie auch? Unseres Wissens nach gibt es beim Einsatz von MaxDB immer noch Einschränkungen hinsichtlich der Leistungsfähigkeit in großen und sehr großen BW-Umgebungen, welche in großen und sehr großen Unternehmen meist eine äußerst wichtige Rolle spielen. Darüber hinaus bietet MaxDB weiterhin nur ein auf UTF-16 basiertes UNICODE-Format und ermöglicht im Gegensatz zu den anderen am Markt verfügbaren Datenbanken keine Hochqualitätskomprimierung. Noch schwerer fällt ins Gewicht, dass SAP bisher so gut wie keine Anstalten gemacht hat, diese hochbegehrte Funktion nachzuliefern, und dass es keine eindeutige Roadmap für die Weiterentwicklung gibt. Es macht durchaus einen Unterschied, ob Ihre SAP-Speicherlandschaft sich auf 300 TB oder nur die Hälfte davon beläuft, sowohl bei Fragen der Infrastrukturkosten, des Energieverbrauchs und des administrativen Aufwands. Und seit zwei oder drei Jahren rückt mit jedem neuen großen Datenskandal irgendwo auf der Welt eine weitere wichtige Funktion in den Fokus, die MaxDB nicht liefern kann: Datenverschlüsselung. Zusammengenommen führte dies dazu, dass Kunden offenkundig das Interesse an MaxDB verloren haben. Die Tatsache, dass SAP Sybase ASE in sein Portfolio 7 Für die weitere Betrachtung gilt, dass DB2 immer für DB2 LUW steht, soweit nicht ausdrücklich etwas anderes angegeben wird REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

22 % aufgenommen hat und HANA zu der Datenbank-Lösung der Zukunft erklärt hat sowie die impliziten Widersprüche dieser Doppelstrategie, waren ebenfalls nicht gerade hilfreich für MaxDB. Database Win/Loss - All Migrations Oracle DB2 Informix MaxDB MS SQL Server Der andere große Verlierer auf dem SAP-Datenbank-Markt ist... Oracle. Ursächlich dafür sind zwei große Trends: Weltweit entscheiden sich fast alle Kunden bei einer Migration zu Windows auch für SQL-Server. Dies geschieht unabhängig vom jeweiligen Ausgangsbetriebssystem, jedoch besonders häufig, wenn der Kunde zuvor Oracle-Datenbanken im Einsatz hatte. Außerdem sehen wir bei Migrationen im Zusammenhang mit UNIX und Linux einen zunehmenden Trend hin zu DB2, auch hier wieder ganz besonders dann, wenn Oracle die Ausgangsdatenbank darstellt. Dies gilt sowohl für Migrationen von UNIX zu Linux als auch für solche von UNIX zu UNIX. Und eigentlich hat Oracle sogar noch Glück gehabt: Einige unserer größten Linux-Migrations-Kunden haben uns offen und klar gesagt, dass ihr Weg geradewegs zu Linux/DB2 und nicht zu Linux/Oracle geführt hätte, wenn sie damals (2008, als die Entscheidungen getroffen wurden) schon gewusst hätten, was sie heute (2012) über Oracles Lizenzmodelle und das nennen wir es Auftreten einiger Oracle-Vertriebler wissen. Einige fügten sogar hinzu, dass der einzige Grund, der gegen eine Wiederholung des Prozesses spricht, nicht die 7-stellige Investitionssumme ist, die für eine solche Umstellung nötig wäre, sondern die Tatsache, dass sie ihren Key-Usern und Fachabteilungen nicht noch ein weiteres großes 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

23 % Migrationsprojekt innerhalb so kurzer Zeit zumuten können. Alles in allem scheint Oracle beim Verprellen seiner Kunden ganze Arbeit zu leisten. Database Win/Loss - Migrations to Linux Oracle DB2 MS SQL Server Der Datenbanktrend, der alle Migrationen betrifft, spiegelt sich deutlich in den Migrationen zu Linux und den damit einhergehenden Einschränkungen wider: Es bleiben einfach nicht viele Optionen. Informix hat das Zeitliche gesegnet, MaxDB hat seine besten Zeiten schon hinter sich, SQL-Server ist für Linux nicht erhältlich und Sybase ASE ist einfach noch nicht so weit: Kunden können sich also im Prinzip nur zwischen Oracle und DB2 entscheiden. Die circa 11% seiner Kunden, die Oracle also bei Migrationen nach Linux verliert, werden zum Gewinn für DB2. Um Missverständnissen vorzubeugen: Die Zahlen zeigen auch deutlich, dass Oracle weiterhin einen Gesamtmarktanteil von mindestens 60% bei Linux und UNIX hält. Bei vielen unserer größten Linux-Migrations-Projekte wurde zwar das Betriebssystem ausgetauscht, an Oracle wurde aber weiter festgehalten und das sogar bei Kunden, die Oracle mit seinen Lizenzmodellen oder seiner Firmenpolitik schon bis aufs Blut gereizt hat. Die Gründe für diese erzwungene Kundentreue sind vielfältig: Zum einen ist ein Datenbankwechsel ein weitaus größerer Schritt als ein Betriebssystemwechsel, zumindest wenn es von UNIX nach Linux geht. Während Kunden bei einer Migration des Betriebssystems von UNIX nach Linux viele betriebliche Abläufe, Skripte, Schnittstellen, 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

24 Automatismen und Layouts beibehalten können, bedeutet ein Datenbankwechsel immer auch erhöhte Aufwände bei Schulung und Implementierung und erfordert eine Neugestaltung grundlegender Mechanismen wie zum Beispiel Backup & Recovery, Performance Tuning, Speicheranordnung und Index-Optimierung. Und die Kunden sind nicht naiv: Sie wissen genau, dass fünfzehn Jahre Erfahrung im Betrieb von Oracle-Datenbanken für SAP-Anwendungen in großen UNIX-Umgebungen nicht so einfach innerhalb weniger Monate ersetzt werden können. Der andere wichtige Grund, der für einen Verbleib bei Oracle spricht, ist, dass SAP zwar einen erheblichen Stellenwert in der Welt des Business-IT besitzt, aber nicht das Maß aller Dinge ist. Viele unserer UNIX zu Linux -Migrationskunden betreiben auch große Nicht-SAP-Landschaften mit Oracle-Datenbanken auf UNIX oder Linux. Die Mehrzahl dieser Kunden hat mit Oracle direkte Lizenzverträge für beide Welten, SAP und Nicht-SAP, und ihnen ist sehr wohl bewusst, dass ihnen ein Absprung auf der einen Seite deftige Preiserhöhungen auf der anderen Seite bescheren würde. Um Oracle also nicht unnötig zu provozieren, bleiben sie Wohl oder Übel dabei, egal ob ihnen das nun gefällt oder nicht. Es gibt aber noch andere Gründe, Oracle treu zu bleiben, so zum Beispiel der Betrieb von FDA-validierten Umgebungen (und die Aussicht, den Validierungsprozess bei einem Datenbankwechsel erneut durchlaufen zu müssen), oder die eigene Vergangenheit, zum Beispiel bei Unternehmen, die von Informix kommen und für einen erneuten Datenbankwechsel noch nicht bereit sind. Auf die einzelnen Regionen bezogen ist der Trend weg von Oracle auf dem amerikanischen Markt am ausgeprägtesten, dicht gefolgt von Europa. Dies entspricht auch den zuvor beschriebenen Trends bei den Betriebssystemen REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

25 Entwicklungen im Preis-Leistungs-Verhältnis Wie schon im 2009er Whitepaper haben wir für die Auswertung des Preis-Leistungs- Verhältnisses eine Reihe strikter Regeln und Kriterien angelegt. [A] Diese Whitepaper-Reihe beschäftigt sich mit der Verbindung zwischen Architekturen und Linux in der SAP-Welt. Folglich haben wir nur Hardware-Anbieter berücksichtigt, die sich derzeit im SAP LinuxLab engagieren. Anbieter, die ein solches Engagement für die Zukunft planen, wurden nicht mit einbezogen. [B] Es werden nur Leistungsmessungen in die Liste aufgenommen, die von einem offiziellen Benchmark (2-Tier SD) für Release ECC 6.0 EHP 4 UNICODE gestützt werden. Anders als letztes Mal haben wir alle auf diesem Benchmark-Release basierten 2-Tier SD-Benchmarks berücksichtigt, die in den letzten zwei Jahren durchgeführt wurden. Falls mehrere Benchmarks für eine identische Server-Konfiguration für diesen Zeitraum vorlagen, haben wir nur das neueste ausgewertet. Die zwei Ausnahmen zu der Regel alle Benchmarks der letzten zwei Jahre betreffen... (1)... den Itanium-Prozessor: Seit 2008 wurde kein 2-Tier SD-Benchmark mehr veröffentlicht 8, also haben wir den letzten 2-Tier SD ECC 6.0 NON-UNICODE für unsere Kosten- und Energieauswertungen zu Grunde gelegt. Bitte beachten Sie dies, wenn Sie sich die Grafiken und Tabellen ansehen, da diese Notlösung den Itanium-Prozessor besser aussehen lässt, als er eigentlich ist. Um einen echten Vergleich anstellen zu können, hätten wir einen gewissen Prozentsatz bei den mit dem weniger anspruchsvollen ECC 6.0-Benchmark gemessenen SAPS abziehen müssen aber wie viel genau? 15% oder 20% oder vielleicht 40%? Wir wissen es nicht und haben es daher auch nicht versucht. (2)... den SPARC-Prozessor: Die verfügbaren Benchmarks liegen mehr als zwei Jahre zurück, aus Mangel an Alternativen haben wir uns für deren Verwendung entschieden. Zumindest wurden diese, anders als beim Itanium, auf dem gleichen Benchmark-Release durchgeführt, wie die verfügbaren x86- und Power-Benchmarks. 8 Sie wurden zwar durchgeführt, aber die betroffenen Hardware-Anbieter haben sich aus guten Gründen gegen eine Veröffentlichung entschieden REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

26 [C] Bitte beachten Sie, dass diese neue Benchmark-Grundlage im Vergleich zur der auf dem Benchmark-Release ECC 6.0 NON-UNICODE basierenden EURO/SAPS-Auswertung aus dem 2009er Whitepaper die Leistungsanforderungen wesentlich erhöht. Darum sind die Preis-Leistungs-Verhältnisse von 2009 und 2012 auch nicht vergleichbar heutige Hardware würde in identischen Benchmarks deutlich besser abschneiden als die von [D] Hardware-Anbieter, bei denen keine offiziellen Preise für gebenchmarkte Server verfügbar waren oder die verfügbaren offiziellen Preise auf einzelne lokale Märkte (z.b. Japan) beschränkt waren, wurden in unserer Auswertung nicht berücksichtigt. Dies ist ein globales Whitepaper, das sich ausschließlich mit globalen Anbietern befasst, die globale Produkte und Dienstleistungen anbieten. [E] Die Kosten für einen (1) Blade-Server wurden wie folgt ermittelt: Wir errechneten die Kosten eines voll ausgestatteten Blade-Centers des jeweiligen Anbieters mit dem entsprechenden Blade- Server in identischer Konfiguration, nahmen die Kosten für das Blade-Center mit auf, teilten die Gesamtkosten der Konfiguration durch die Gesamtzahl der enthaltenen Blade-Server und konnten so die realistischen Gesamtkosten für jeden einzelnen Blade-Server bestimmen. Abgesehen von dieser Besonderheit bei den Blade-Servern wurden die gleichen Methoden und Quellen für die Bestimmung der Server-Preise wie schon in den ersten beiden Whitepapern genutzt, ergänzt und unterstützt durch die Konfigurations- und Preisermittlungs-Programme, die die Mehrzahl der Hardware-Anbieter heute zum Download zur Verfügung stellt. [F] Wir sind uns dessen bewusst, dass aktuellere 2-Tier SD-Benchmarks auf Basis von SAP ECC 6.0 EHP5 UNICODE verfügbar sind. Die Anzahl dieser aktuelleren Benchmarks ist jedoch zu gering, um unsere Untersuchungen ausreichend unterstützen zu können. Tatsächlich hätte uns die Verwendung dieses Benchmarks auf vier Hardware-Anbieter, fünf Benchmarks und ausschließlich x64 beschränkt (Stand 31. August 2012). [G] Unsere Kalkulation der Gesamtkosten basiert auf einem unternehmenskritischen 24/7-Support für das tatsächliche Benchmark-Betriebssystem anders als noch 2008 und 2009, als wir alle 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

27 Berechnungen der Support-Kosten für x64-hardware auf das SUSE-Support-Modell übertragen haben. Wir werden anhand eines Beispiels zeigen, dass die Unterschiede beim grundlegenden Server-Support in der x64-welt zu vernachlässigen sind, zumindest im Hinblick auf SUSE und Red Hat Enterprise Linux sowie Windows Server. Es gibt aber zum Teil erhebliche Kostenunterschiede bei Zusatzmerkmalen wie Hochverfügbarkeit, Virtualisierungsfunktionen und -steuerung oder Lizenz- und Support-Kosten für virtualisierte Umgebungen. Sowohl SUSE als auch Red Hat werden in diesen Kategorien höchstwahrscheinlich deutlich im Vorteil gegenüber Windows sein, diese Merkmale wurden bei unserer Auswertung des Preis-Leistungs- Verhältnisses jedoch stets ausgeklammert, da allein schon die Vielzahl der möglichen Varianten einen fairen Vergleich nahezu unmöglich macht. In Übereinstimmung mit dieser Änderung unserer Auswertungsrichtlinien wurden Oracle-x64- Server mit Solaris als unterstütztes Betriebssystem berechnet, vorausgesetzt, dass sie so gebenchmarkt wurden. Zudem kamen die gleichen Annahmen hinsichtlich des unternehmenskritischen 24/7-Support zur Anwendung. Nachdem wir nun die Regeln dargelegt haben, können wir uns den neuen Zahlen zuwenden. Viele Schlussfolgerungen stimmen voll und ganz mit unseren Aussagen und Prognosen von vor drei oder vier Jahren überein, einige andere bedürfen der Analyse und Erläuterung, hauptsächlich weil sie eine Reihe neuer technischer Entwicklungen beinhalten. Beschränkt man die Betrachtung auf das Preis-Leistungs-Verhältnis in EURO/SAPS, so ist die noch stärkere Dominanz der x64-plattformen auf diesem Gebiet besonders auffällig und offensichtlich. Der einzige konkurrenzfähige UNIX-Prozessor ist der Power-Prozessor und hier hat IBM tatsächlich hervorragende Arbeit geleistet und mit der Einführung des Power7 die Wettbewerbsfähigkeit von AIX zu seinen Gunsten verbessert 9. Doch auch eine Power7-Blade- Plattform erhöht die Kosten pro SAPS immer noch um 20 Cents oder 74%, selbst wenn man IBM als bevorzugtem Anbieter treu bleibt, und es gibt kostengünstigere Angebote von anderen Anbietern. Und die kostengünstigere x64-lösung von IBM kommt in einem 4-Sockel-Server daher und bietet so auch mehr Platz für Speicher, mehr Kerne und mehr Threads, die über eine Reihe von Anwendungen verteilt werden können, sofern nicht eine einzige alle verfügbare Leistung beansprucht. Und verfügbare Leistung ist in beiden Fällen reichlich vorhanden wir reden hier über Server mit (x3755 M3) oder SAPS (Blade Center PS702), was in etwa oder parallel arbeitenden SD-Anwendern entspricht. Betrachtet man die anderen UNIX- 9 Am 3. Oktober 2012 erfolgte die Markteinführung von Power7+, wodurch die Wettbewerbsfähigkeit vermutlich noch einmal gesteigert wird REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

28 Prozessoren, so kann keiner von ihnen auch nur annähernd in diesem Wettbewerb mithalten und daraus lassen sich zwei Aussagen ableiten: Zum einen ist es nicht genug, nur über Entwicklungsfortschritte und Verbesserungen zu reden, man muss diese auch nachweisen können, indem man Vergleiche mit der Konkurrenz möglich macht. Zum anderen haben sowohl Oracle als auch HP beschlossen, sich dem Vergleich zu entziehen, indem sie SAP-Benchmarks erst gar nicht mehr veröffentlichen, wie HP bei Itanium, oder ein von allen anderen abweichendes Benchmark nutzen, der Weg, den Oracle eingeschlagen hat: Ja, es gab im Jahr 2011 ein Benchmark mit SPARC, aber der gewählte Benchmark-Typ war ATO. Hier gab es seit 1998 insgesamt 27 veröffentlichte Benchmarks und das letzte Ergebnis eines Mitbewerbers für diesen Typ wurde im Jahr 2002 veröffentlicht (oder 2003 falls Sie Fujitsu als einen Oracle-Mitbewerber im Bereich SPARC betrachten). Das einzige was sich hier zweifellos festhalten lässt, ist, dass es sogar bei SPARC in den letzten neun (!) Jahren einige wenige Verbesserungen gab... Wenn Sie als SAP-Kunde aber um die Gesamtkosten für Ihre SAP-IT-Infrastruktur besorgt sind und Sie durch bessere SAPS-Leistung bei weniger Ausgaben die Kosten für Ihre Server reduzieren wollen, so kommen weder SPARC noch Itanium für Sie infrage. Ein Blick auf die drei gelisteten SPARC-Werte offenbart eine weitere, äußerst interessante und wichtige Tatsache: Server und Mainboards mit vielen Sockeln gehen mit einem sehr hohen Preis einher, je mehr desto höher. Dies gilt für alle Architekturen. In der x64-familie rangieren alle Server mit 8 Sockeln eindeutig am unteren Ende der Preis-Leistungs-Skala. Und man muss nicht lange raten, warum IBM, schlau wie man dort ist, schon seit 2010 kein 32-Sockel p795-system mehr gebenchmarkt hat. Multi-Sockel-Server-Systeme, wobei Multi für jede Zahl über acht (oder vielleicht auch acht selbst) steht, sind schon längst nicht mehr zeitgemäß, da sie viel zu teuer sind. Wir werden in diesem Whitepaper anhand von zwei Beispielen zeigen, dass REALTECH-Kunden durch die Ablösung von Multi-Prozessor-Servern durch hochsymmetrische 2- und 4-Sockel-Technologien schon jetzt mehrere hunderttausend Euro pro Jahr einsparen oder in Zukunft einsparen werden REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

29 Benchmark ID Vendor Server Model Processor Name Benchmark Throughput [SAPS] Number of Sockets SAPS per Socket Processor Number Benchmark Clock of Cores Year [Mhz] US-$ / SAPS p.a. EURO/ SAPS p.a HP ProLiant DL385 G7 AMD Opteron 6282SE ,29 0, HP ProLiant BL685c G7 AMD Opteron ,30 0, HP ProLiant BL465c G7 AMD Opteron ,30 0, HP ProLiant DL585 G7 AMD Opteron 6282SE ,34 0, IBM System x3755 M3 AMD Opteron 6282SE ,34 0, HP ProLiant DL380p G8 Intel Xeon E ,36 0, Cisco UCS B200 M3 Intel Xeon E ,37 0, Dell PowerEdge R720 Intel Xeon E ,39 0, HP ProLiant BL460c Gen8 Intel Xeon E ,40 0, Cisco UCS C460 M2 Intel Xeon E ,53 0, HP ProLiant BL680c G7 Intel Xeon E ,53 0, Fujitsu PRIMERGY RX300 S7 Intel Xeon E ,55 0, IBM BladeCenter PS702 POWER ,59 0, Cisco UCS B230 M2 Intel Xeon E ,59 0, Dell PowerEdge R910 Intel Xeon E ,61 0, Fujitsu PRIMERGY RX600 S6 Intel Xeon E ,63 0, Oracle Sun Fire X4270 M3 Intel Xeon E ,67 0, IBM System x3690 X5 Intel Xeon E ,73 0, IBM Power System 730 POWER ,76 0, Cisco UCS C260 M2 Intel Xeon E ,81 0, HP ProLiant DL980 G7 Intel Xeon E ,87 0, HP ProLiant DL580 G7 Intel Xeon E ,00 0, IBM System x3850 X5 Intel Xeon E ,04 0, IBM Power System 750 POWER ,23 1, IBM Flex System x240 Intel Xeon E ,81 1, HP Integrity BL860C Intel Itanium 9140M ,48 2, Fujitsu PRIMEQUEST 1800E2 Intel Xeon E ,93 3, _ _ _1 Oracle (Sun) Oracle (Sun) Oracle (Sun) SPARC Enterprise T5440 UltraSPARC T2 Plus ,72 6,33 SPARC Enterprise M9000 SPARC64 VII ,01 25,42 SPARC Enterprise M9000 SPARC64 VII ,71 30,91 Tabelle 1: Ausgewertete Server sortiert nach Preis-Leistungs-Verhältnis (EURO/SAPS), bestes Ergebnis zuerst 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

30 Für uns ist es am interessantesten, dass der allgemeine Trend, auf den wir in den ersten beiden Whitepapern hingewiesen haben, auch weiterhin anhält und man auch nicht ernsthaft davon ausgehen kann, dass sich hier noch einmal etwas ändern wird: In 2008 waren die besten vier beim Preis-Leistungs-Verhältnis x64-plattformen, in 2009 schon die besten acht und jetzt 2012 sind die besten dreizehn Teil der x64-familie. Der Wettbewerb unter den x64-anbietern hat sich durch den Eintritt von Cisco, Hitachi und, wie bereits angekündigt, Huawei in den SAP-Server-Markt noch einmal verschärft und wird wahrscheinlich dazu führen, dass für x64 sogar noch mehr Wettbewerber-Benchmarks als jemals zuvor durchgeführt werden. Gleichzeitig wird die Anzahl der für die verschiedenen UNIX-Plattformen durchgeführten und veröffentlichten Benchmarks mit jedem Jahr weniger werden. Dies führt zudem zu einem bemerkenswerten Wettrüsten zwischen Intel und AMD, wobei sich AMD für die massive Parallelisierung mit möglichst vielen Kernen pro Sockel entschieden hat, während Intel neue Maßstäbe bei der Leistungsfähigkeit pro Kern und pro Thread setzt (und dabei eher Power als Opteron als Wettbewerb im Blick hat). Beide Ansätze haben ihr Vor- und Nachteile. Intel zum Beispiel arbeitet in einem Taktbereich zwischen und MHz während AMD mit bis MHz knapp unter diesem Bereich bleibt. Da die Energieabgabe eine dritte Potenz der Taktung ist, jedoch nur in linearer Abhängigkeit zur Sockelgröße wächst, verschafft dies AMD bei der Energieeffizienz einen leichten Vorteil gegenüber Intel. Die Auswertungen und Diagramme in den Green-IT-Kapiteln werden dies zeigen. Um jedoch optimale Werte bei SAP-Anwendungs- Leistung und Durchsatz zu erzielen, ist die Leistung pro Kern und sogar per Thread in vielen wichtigen Einsatzszenarien ausschlaggebender als massive Parallelisierung, besonders bei Javaund Dual-Stack-Anwendungen sowie virtualisierten Umgebungen. Zudem spricht ein überzeugender wirtschaftlicher Aspekt gegen zu viele Kerne pro Sockel: Wenn Ihre Datenbanklizenzen an die Prozessorkerne gekoppelt sind, egal ob bei Oracle, DB2 oder allen anderen, hat der Ansatz mit vielen Kernen schnell das Nachsehen. REALTECH hat Untersuchungen durchgeführt, bei denen Intel-CPUs gegenüber AMD mit 30% (oder, absolut, mit einer siebenstelligen EURO-Summe) bei den Datenbank-Lizenzkosten über drei Jahre im Vorteil waren und das in ansonsten identischen und bereits unter Lizenzkostenaspekten optimierten Konfigurationen. Dies gleicht die Tatsache mehr als aus, dass Hardware-Anbieter gerne einen höheren Preis für ihre Intel-Angebote verlangen als für ihre AMD-Angebote (vergleichen Sie zum Beispiel den HP ProLiant DL385 G7 mit 0,23 EURO/SAPS mit dem HP ProLiant DL380p G8 mit 0,29 EURO/SAPS, die beide innerhalb von weniger als zwei Monaten gebenchmarkt wurden). Sollte Ihr Datenbank-Lizenzmodell jedoch an den SAP-Vertragswert gekoppelt sein, muss Ihnen all dies keinerlei Kopfschmerzen bereiten. Und das Schöne an dem scharfen Wettbewerb in der x64-welt ist doch, dass es Ihnen vollkommen freisteht, genau die Umgebung aufzubauen, die 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

31 Ihren technischen Anforderungen, finanziellen Möglichkeiten und Ihrer Vertragssituation am besten entspricht. Das nächste Thema, das wir in diesem Whitepaper beleuchten möchten, ist wie viel Leistung Sie für Ihr Geld erhalten, und wir denken, dass sich dies am besten an der Gesamtleistung des Hauptprozessors, oder Sockel (um jeglicher Verwechslung mit einer virtuellen CPU vorzubeugen), ablesen lässt. Wenig überraschend ist dabei, dass die ältesten Benchmarks in diesem Kontext am schlechtesten abschneiden. Bitte beachten Sie, dass wahrscheinlich Itanium und nicht SPARC den letzten Platz in dieser Rangliste einnehmen würde, wenn er auf Grundlage des gleichen Benchmarks wie alle anderen bewertet worden wäre. Eine Betrachtung der Leistung pro Sockel für diese beiden Architekturen ist aber sowieso müßig und führt ins Nichts. Keine der beiden stellt eine wettbewerbsfähige Lösung mehr dar und das nicht nur unter wirtschaftlichen sondern auch unter technischen Gesichtspunkten. Außerdem gibt es wesentlich interessantere Dinge, denen wir uns widmen sollten. Angefangen damit, dass die Rangliste der Leistung pro Sockel von zwei Prozessorherstellern, IBM und Intel, dominiert wird. Diese beiden machen den Wettbewerb unter sich aus, während die anderen unter ferner liefen zu verzeichnen sind. Dies gilt besonders für AMD, wo man offensichtlich Kunden ansprechen möchte, die eine Minimierung der Gesamtkosten dem besten Mittelweg zwischen maximaler Leistung und minimalen Kosten vorziehen. Anders gesagt, gibt es einen eindeutigen Grund, warum alle Server-Anbieter mit AMD-Lösungen im Angebot diese grundsätzlich günstiger anbieten, als ihre Intel-basierten Gegenstücke so wird der Server-Markt für Kunden mit kleineren SAP-Landschaften und IT-Budgets erschlossen. Während große Unternehmen in der Regel eine Lösung suchen, die eine Leistung von vielen hunderttausend SAPS mit einer minimalen Anzahl von Servern (aus Platz- und Administrationsgründen) oder Prozessoren und Kernen (aus lizenztechnischen Gründen) liefert, stehen kleinere Kunden mit nur ein bis drei SAP-Produktivsystemen häufig vor dem Problem, dass sie zwar aus Redundanzgründen zwischen vier und sechs Server benötigen, dies aber ihre Leistungsanforderungen bei weitem übersteigt, selbst mit den nicht ganz so leistungsstarken AMD-Sockeln. Üblicherweise haben genau diese Kunden ein an den Vertragswert gekoppeltes Lizenzmodell für ihre SAP-Datenbanken, womit der AMD-Ansatz mit vielen Kernen pro Sockel niemandem wehtut REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

32 Benchmark ID Vendor Server Model Processor Name Benchmark Throughput [SAPS] Number SAPS per Number of of Socket Cores Sockets Performance per Core [SAPS] Number of Threads per Socket Performance per Thread [SAPS] US-$ / SAPS p.a. EURO/ SAPS p.a IBM Power System 750 POWER ,23 1, Oracle Sun Fire X4270 M3 Intel Xeon E ,67 0, IBM Flex System x240 Intel Xeon E ,81 1, HP ProLiant DL380p G8 Intel Xeon E ,36 0, IBM BladeCenter PS702 POWER ,59 0, Cisco UCS B200 M3 Intel Xeon E ,37 0, Fujitsu PRIMERGY RX300 S7 Intel Xeon E ,55 0, HP ProLiant BL460c Gen8 Intel Xeon E ,40 0, IBM Power System 730 POWER ,76 0, IBM System x3690 X5 Intel Xeon E ,73 0, HP ProLiant BL680c G7 Intel Xeon E ,53 0, Cisco UCS C260 M2 Intel Xeon E ,81 0, Fujitsu PRIMERGY RX600 S6 Intel Xeon E ,63 0, Cisco UCS C460 M2 Intel Xeon E ,53 0, Dell PowerEdge R720 Intel Xeon E ,39 0, IBM System x3850 X5 Intel Xeon E ,04 0, HP ProLiant DL580 G7 Intel Xeon E ,00 0, Fujitsu PRIMEQUEST 1800E2 Intel Xeon E ,93 3, IBM System x3755 M3 AMD Opteron 6282SE ,34 0, HP ProLiant DL585 G7 AMD Opteron 6282SE ,34 0, HP ProLiant DL980 G7 Intel Xeon E ,87 0, HP ProLiant DL385 G7 AMD Opteron 6282SE ,29 0, Dell PowerEdge R910 Intel Xeon E ,61 0, Cisco UCS B230 M2 Intel Xeon E ,59 0, HP ProLiant BL465c G7 AMD Opteron ,30 0, HP ProLiant BL685c G7 AMD Opteron ,30 0, _ _2 Oracle (Sun) Oracle (Sun) SPARC Enterprise T5440 UltraSPARC T2 Plus ,72 6,33 SPARC Enterprise M9000 SPARC64 VII ,01 25, HP Integrity BL860C Intel Itanium 9140M ,48 2, _1 Oracle (Sun) SPARC Enterprise M9000 SPARC64 VII ,71 30,91 Tabelle 2: Ausgewertete Server sortiert nach Leistung pro Hauptprozessor (Sockel), bestes Ergebnis zuerst Ein weitere interessante Beobachtung ist, dass die Top 15 in dieser Rangliste alle 2- oder 4- Sockel-Server sind. Dies legt zumindest nahe, dass das Optimum zwischen Wiederverwendungssynergien bei Multi-Sockel-Architekturen einerseits und erhöhtem 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

33 SMP-Administrationsaufwand andererseits auch in diesem Server-Bereich zu finden ist. Interessanterweise holt IBM mehr Leistung pro Sockel aus seinen 4-Sockel-Servern als aus den 2-Sockel-Versionen heraus. Unter Umständen, und dies ist durchaus eine denkbare Möglichkeit, ist AIX effizienter und besser im Umgang mit Multiprozessoren. Dies deutet auch darauf hin, dass AIX in dieser Hinsicht besser ist als Linux oder Windows. Aber bevor AIX-Befürworter jetzt in Triumphgeschrei ausbrechen, sollte darauf hingewiesen werden, dass diese Unterschiede durch die Leistungsexplosion immer mehr an Bedeutung verlieren, ebenso wie die Verwendung multipler Sockel. Aber wir sind mit der Untersuchung dieser Tabelle noch längst nicht fertig. Wenn Sie genau hinsehen, werden Sie feststellen, dass die besten fünf Intel-Platzierungen von jeweils fünf verschiedenen Server-Anbietern erzielt wurden, alle mit der gleichen CPU (Xeon E5-2690) und alle mit 2-Sockel-Servern. Die Abweichung in den erzielten Leistungen liegen zwar in einem vernünftigen und fast erwartbaren Rahmen von 10%, die Abweichung bei den Preisen in unserer EURO/SAPS-Rangliste jedoch nicht. So können Sie ungefähr 30 Cents pro SAPS bei HP oder Cisco bezahlen, fast 1,50 Euro bei IBM oder einen Betrag dazwischen bei Oracle oder Fujitsu. Oder Sie können sich mit Dell für einen Server mit dem gleichen Prozessortyp, einem 2-Sockel- Setup (wie auch bei den anderen) und durchaus akzeptablen 0,32 EURO/SAPS entscheiden, vorausgesetzt, Sie können mit SAPS weniger Leistung in jedem Server leben. Wir wollen hier nicht spekulieren, warum Dell im Vergleich zu seinen Mitbewerbern offenbar immer wieder ein bisschen weniger Leistung aus den gleichen Prozessortypen herausholt, es ist nur auffällig, dass in dieser Benchmark-Familie das Gleiche auch für den Xeon E zutrifft. Aber warum weicht IBM mit seiner Preisgestaltung für sein Hochleistungs-Intel-Angebot so weit von der Norm ab? Auch hier haben wir keine eindeutigen Belege, aber wir denken, dass in diesem Fall ein wenig Spekulation erlaubt ist. Schon in unserem ersten UNIX zu Linux -Whitepaper aus dem Jahr 2008 (dem ersten der Reihe) haben wir bei IBM zumindest in einigen Fällen und bei einigen Produkten eine strategische Preispolitik vermutet, deren Ziel es ist, die Unterschiede zwischen IBMs x64- und Power-Angeboten nicht zu groß und zu offensichtlich werden zu lassen, um so sicherzustellen, dass Kunden, die IBM treu bleiben, auch bei der Power-Architektur bleiben. Grundsätzlich gehen wir davon aus, dass dies auch heute noch der Fall ist: Statt sich selbst zu kannibalisieren, hat IBM vermutlich interne Preis- und Vertriebsrichtlinien aufgestellt, die Power einen Vorteil verschaffen, es aber weiterhin möglich machen, auch Kunden zu halten, die einen anderen Architekturweg einschlagen, dabei aber IBM treu bleiben wollen. So verliert IBM Power- Kunden nur dann, wenn sie sich für x64 entscheiden und die Mitbewerber am Markt genau untersuchen und gleichzeitig bereit sind, sich mit einem eher langsamen Return on Investment 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

34 Benchmark ID Vendor Server Model Processor Name Benchmark Throughput [SAPS] Number SAPS per Number of of Socket Cores Sockets Performance per Core [SAPS] Number of Threads per Socket Performance per Thread [SAPS] US-$ / SAPS p.a. EURO/ SAPS p.a IBM Power System 750 POWER ,23 1, IBM BladeCenter PS702 POWER ,59 0, IBM Power System 730 POWER ,76 0, Oracle Sun Fire X4270 M3 Intel Xeon E ,67 0, IBM Flex System x240 Intel Xeon E ,81 1, HP ProLiant DL380p G8 Intel Xeon E ,36 0, Cisco UCS B200 M3 Intel Xeon E ,37 0, Fujitsu PRIMERGY RX300 S7 Intel Xeon E ,55 0, HP ProLiant BL460c Gen8 Intel Xeon E ,40 0, Dell PowerEdge R720 Intel Xeon E ,39 0, IBM System x3690 X5 Intel Xeon E ,73 0, HP ProLiant BL680c G7 Intel Xeon E ,53 0, Cisco UCS C260 M2 Intel Xeon E ,81 0, Fujitsu PRIMERGY RX600 S6 Intel Xeon E ,63 0, Cisco UCS C460 M2 Intel Xeon E ,53 0, IBM System x3850 X5 Intel Xeon E ,04 0, HP ProLiant DL580 G7 Intel Xeon E ,00 0, Fujitsu PRIMEQUEST 1800E2 Intel Xeon E ,93 3, HP ProLiant DL980 G7 Intel Xeon E ,87 0, Dell PowerEdge R910 Intel Xeon E ,61 0, HP Integrity BL860C Intel Itanium 9140M ,48 2, Cisco UCS B230 M2 Intel Xeon E ,59 0, IBM System x3755 M3 AMD Opteron 6282SE ,34 0, HP ProLiant DL585 G7 AMD Opteron 6282SE ,34 0, HP ProLiant DL385 G7 AMD Opteron 6282SE ,29 0, HP ProLiant BL465c G7 AMD Opteron ,30 0, HP ProLiant BL685c G7 AMD Opteron ,30 0, _ _ _1 Oracle (Sun) Oracle (Sun) Oracle (Sun) SPARC Enterprise T5440 UltraSPARC T2 Plus ,72 6,33 SPARC Enterprise M9000 SPARC64 VII ,01 25,42 SPARC Enterprise M9000 SPARC64 VII ,71 30,91 Tabelle 3: Ausgewertete Server sortiert nach Leistung pro Kern, bestes Ergebnis zuerst (RoI) abzufinden, da der künstlich klein gehaltene Kostenunterschied zwischen Power und x64 den Einmaleffekt der Übergangskosten genau hier verschärft. Zieht man zusätzlich noch in Betracht, dass Power durch regelmäßige Updates und Weiterentwicklungen technisch auf einem wettbewerbsfähigen Stand gehalten wird, wie durch anerkannte Benchmarks bewiesen, kann 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

35 diese Firmenpolitik auch als ein klares Bekenntnis zur Power-Architektur verstanden werden. Dies spiegelt sich auch in den Erfahrungen von REALTECH wider. Diese besagen, dass Analyseprojekte, die bestehende Power-Infrastrukturen mit neuen Optionen vergleichen, mit einer Chance von 60/40 die geringste Wahrscheinlichkeit eines Wechsels haben, während ähnliche Aktivitäten mit Itanium-SAP-Infrastrukturen immer zu dem gleichen Ergebnis kommen: Orientieren Sie sich um, und tun Sie dies möglichst schnell. Lassen Sie uns nun eine Ebene tiefer gehen und die erzielte Leistung pro Kern betrachten. Diese Kennzahl für Prozessorleistung ist besonders für Kunden von Bedeutung, deren SAP-Datenbank- Lizenzen an ihre Prozessorkerne gekoppelt sind: Hier sind die Lizenzkosten unmittelbar von der Anzahl der Kerne abhängig, die für die Erfüllung der Leistungsanforderungen benötigt wird. In größeren Unternehmen gelten derartige Verträge in der Regel sowohl für die SAP- als auch für die Nicht-SAP-Datenbankumgebungen, womit ihnen wenig oder gar kein Spielraum bleibt, sich einem anderen Datenbankanbieter zuzuwenden. Aus der nach Kernleistung sortierten Tabelle wird ersichtlich, dass Power7 hier sehr gut aussieht und auch tatsächlich ist. Es gibt einen Grund, warum z.b. Oracle für Power-Kerne einen anderen Verrechnungsfaktor ansetzt als für x64 oder SPARC abgesehen von dem Wunsch Kunden bei der Wahl der CPU in eine bestimmte Richtung zu lenken. Wenn sich ein Kunde trotz allem für Power entscheidet, kann mit dieser Vorgehensweise wenigstens in gewissem Maße die hervorragende Leistung pro Kern kompensiert werden. Wenn diese Kennzahl für Sie von Bedeutung ist, Sie aber kein Interesse an einer Power-Architektur haben, zum Beispiel weil Sie sich bereits für eine x64-prozessorarchitektur entschieden haben, so sind Intel-Prozessoren die richtige Wahl für Sie. Diese führen so ziemlich allein die verbleibende Rangliste an. Umgekehrt sollten Sie sich genauso wenig für AMD- Prozessoren entscheiden, wenn Ihre Datenbanklizenzen an die Prozessorkerne gekoppelt sind. Hier würden vermutlich selbst die Itanium-Prozessoren die AMDs schlagen, setzt man die gleiche Benchmark-Grundlage voraus. Gibt es hier noch etwas zum Thema SPARC zu sagen? Wir glauben nicht. Werfen Sie einen Blick auf die Zahlen und machen Sie sich Ihr eigenes Bild REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

36 Benchmark ID Vendor Server Model Processor Name Benchmark Throughput [SAPS] Number SAPS per Number of of Socket Cores Sockets Performance per Core [SAPS] Number of Threads per Socket Performance per Thread [SAPS] US-$ / SAPS p.a. EURO/ SAPS p.a Oracle Sun Fire X4270 M3 Intel Xeon E ,67 0, IBM Flex System x240 Intel Xeon E ,81 1, HP ProLiant DL380p G8 Intel Xeon E ,36 0, Cisco UCS B200 M3 Intel Xeon E ,37 0, Fujitsu PRIMERGY RX300 S7 Intel Xeon E ,55 0, HP ProLiant BL460c Gen8 Intel Xeon E ,40 0, Dell PowerEdge R720 Intel Xeon E ,39 0, IBM System x3755 M3 AMD Opteron 6282SE ,34 0, IBM Power System 750 POWER ,23 1, HP ProLiant DL585 G7 AMD Opteron 6282SE ,34 0, HP ProLiant DL385 G7 AMD Opteron 6282SE ,29 0, IBM System x3690 X5 Intel Xeon E ,73 0, HP ProLiant BL680c G7 Intel Xeon E ,53 0, Cisco UCS C260 M2 Intel Xeon E ,81 0, Fujitsu PRIMERGY RX600 S6 Intel Xeon E ,63 0, Cisco UCS C460 M2 Intel Xeon E ,53 0, IBM System x3850 X5 Intel Xeon E ,04 0, HP ProLiant BL465c G7 AMD Opteron ,30 0, IBM BladeCenter PS702 POWER ,59 0, HP ProLiant BL685c G7 AMD Opteron ,30 0, HP ProLiant DL580 G7 Intel Xeon E ,00 0, Fujitsu PRIMEQUEST 1800E2 Intel Xeon E ,93 3, IBM Power System 730 POWER ,76 0, HP ProLiant DL980 G7 Intel Xeon E ,87 0, Dell PowerEdge R910 Intel Xeon E ,61 0, HP Integrity BL860C Intel Itanium 9140M ,48 2, Cisco UCS B230 M2 Intel Xeon E ,59 0, _ _ _1 Oracle (Sun) Oracle (Sun) Oracle (Sun) SPARC Enterprise M9000 SPARC64 VII ,01 25,42 SPARC Enterprise M9000 SPARC64 VII ,71 30,91 SPARC Enterprise T5440 UltraSPARC T2 Plus ,72 6,33 Tabelle 4: Ausgewertete Server sortiert nach Leistung pro Thread, bestes Ergebnis zuerst Das gleiche gilt für SPARC und die nächste und letzte Ebene Leistung pro Thread. Während die Leistung pro Kern für die Datenbanken eine wichtige Rolle spielt, ist die Leistung pro Thread 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

37 entscheidend dafür, wie sich die Gesamtleistung auf die SAP-Anwendungsebene auswirkt. Da ein Batch-Job oder Dialogprozess oder JAVA-Thread mit derzeit verfügbaren Technologien immer auf genau einem Prozessor-Thread läuft, ist es entscheidend, dass Sie so viele Threads wie möglich pro Sockel haben, damit Ihnen maximale Kapazität für die Parallelisierung zur Verfügung steht, und dass Sie gleichzeitig höchstmöglich leistungsstarke einzelne Threads haben, um maximale Durchsatzraten für Ihre SAP-Prozesse zu erzielen. Die optimale CPU-Architektur für SAP-Anwendungen stellen also Multi-Threads mit maximaler Leistung pro Thread dar. Diese Rangliste wird eindeutig von der Intel Xeon E5-26xx-Serie angeführt, gefolgt von AMDs SE Opterons, der IBM Power7-CPU und anderen Intel-Serien. Da AMD einen Thread einem Kern zuweist, ist das Abschneiden hier viel besser als in der pro Kern -Sortierung. AMD-Prozessoren sind sozusagen besser für den Betrieb von SAP-Anwendungen geeignet als von SAP- Datenbanken. Dies könnte man sich beim Design einer mehrschichtigen und unter Leistungsund Kostenaspekten optimierten SAP-Umgebung zu Nutzen machen, die Power oder Intel für die Datenbankschicht und AMD für die SAP-Anwendungsschicht nutzt. Ein solches Design muss jedoch sehr gut durchdacht sein, damit man nicht auf einer Seite Vorteile gewinnt und sie auf der anderen Seite wieder verliert. Die Unterschiede bei der Leistung pro Thread sind insgesamt sehr groß und ergeben für Intel ca. 30% Vorteil gegenüber den Mitbewerbern. Und die Auswertung bestätigt eine Beobachtung, die REALTECH in den letzten Jahren einige Male 10 machen konnte: AIX-Kunden stiegen von Power6 auf Power7 um und waren danach nicht mehr zufrieden mit der daraus resultierenden SAP-Anwendungs-Performance. Dies war für uns schwer zu erklären und zu glauben, da alle Kennzahlen wie Benchmarks, Server-Durchsatz und Speicherausstattung dies nicht nahelegten. Vielleicht liegt die Erklärung einfach nur in der Leistung pro Thread. Wenn dies zutrifft, dann sind Intel-x64-CPUs die einzige Wahl, wenn Sie ein Prozessor-Design für Datenbank und Anwendung betreiben wollen und Sie dies in einer Umgebung mit sehr hohen Leistungsanforderungen tun müssen. An diesem Punkt haben wir so ziemlich alles beleuchtet, was zur Auswertung dieses Benchmarks gesagt werden kann. Lassen Sie uns nun zum Abschluss und im Anklang an das 2008er Whitepaper einen Blick auf die verfügbare absolute Server-Leistung werfen. Hier, werden nun manche sagen, verschiebt sich endlich einmal die Farbverteilung innerhalb der Tabelle. 10 Dies kam nicht wirklich häufig vor, vielleicht drei oder vier Mal, aber jeweils in sehr großen AIX-Umgebungen REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

38 Benchmark ID Vendor Server Model Processor Name Benchmark Throughput [SAPS] Number SAPS per of Socket Sockets Number of Cores per Socket Performance per Core [SAPS] Number of Threads per Socket Performance per Thread [SAPS] US-$ / SAPS p.a. EURO/ SAPS p.a _1 Oracle (Sun) SPARC Enterprise M9000 SPARC64 VII ,71 30, IBM System x3850 X5 Intel Xeon E ,04 0, Fujitsu PRIMEQUEST 1800E2 Intel Xeon E ,93 3, HP ProLiant DL980 G7 Intel Xeon E ,87 0, _2 Oracle (Sun) SPARC Enterprise M9000 SPARC64 VII ,01 25, IBM Power System 750 POWER ,23 1, HP ProLiant BL680c G7 Intel Xeon E ,53 0, Fujitsu PRIMERGY RX600 S6 Intel Xeon E ,63 0, Cisco UCS C460 M2 Intel Xeon E ,53 0, HP ProLiant DL580 G7 Intel Xeon E ,00 0, IBM System x3755 M3 AMD Opteron 6282SE ,34 0, HP ProLiant DL585 G7 AMD Opteron 6282SE ,34 0, Dell PowerEdge R910 Intel Xeon E ,61 0, HP ProLiant BL685c G7 AMD Opteron ,30 0, Oracle Sun Fire X4270 M3 Intel Xeon E ,67 0, IBM Flex System x240 Intel Xeon E ,81 1, HP ProLiant DL380p G8 Intel Xeon E ,36 0, Cisco UCS B200 M3 Intel Xeon E ,37 0, IBM BladeCenter PS702 POWER ,59 0, Fujitsu PRIMERGY RX300 S7 Intel Xeon E ,55 0, HP ProLiant BL460c G8 Intel Xeon E ,40 0, IBM Power System 730 POWER ,76 0, IBM System x3690 X5 Intel Xeon E ,73 0, Cisco UCS C260 M2 Intel Xeon E ,81 0, Dell PowerEdge R720 Intel Xeon E ,39 0, HP ProLiant DL385 G7 AMD Opteron 6282SE ,29 0, Cisco UCS B230 M2 Intel Xeon E ,59 0, HP ProLiant BL465c G7 AMD Opteron ,30 0, _1 Oracle (Sun) SPARC Enterprise T5440 UltraSPARC T2 Plus ,72 6, HP Integrity BL860C Intel Itanium 9140M ,48 2,03 Tabelle 5: Ausgewertete Server sortiert nach absoluter Server-Leistung, bestes Ergebnis zuerst In der Auswertung 2008 wurde die absolute Server-Leistung ganz klar von Multi-Sockel-UNIX- Servern beherrscht, die die Top 5 der 14 bewerteten Server unter sich ausmachten. Wir kamen zu dem Schluss, dass der Aufstieg von x64-basierten Servern in den Midrange-Bereich der Server-Leistung das wahre Problem für UNIX darstellt. Die Sachlage hat sich für UNIX 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

39 mittlerweile ein wenig geändert, oder besser gesagt, verschlechtert. x64-prozessoren, vor allem von Intel, sind schon seit einiger Zeit auf der Überholspur und mit ihnen hat die verfügbare Leistung die Spitzenplätze erreicht und die UNIX-Architekturen mit Ausnahme von Power hinter sich gelassen. Es stimmt zwar, dass die Rangliste von einem SPARC Enterprise M9000 angeführt wird, aber man benötigt 64 SPARC-Sockel, um 8 Intels zu schlagen, was sich auch deutlich in der Preis-Leistungs-Spalte niederschlägt: Eine größere Anzahl von Sockeln in einem Server geht auch mit einem höheren Preis einher, bei jeder Architektur. Wenn Sie also die Anzahl der Sockel in einem Server verringern und zu Standard- (2- und 4-Wege) oder zumindest standardähnlichen (8-Wege) Konfigurationen zurückkehren, werden Sie Ihre Kosten erheblich senken können. IBM, der UNIX-Fels in der Brandung, der das alles nicht widerstandslos hinnehmen will, macht sich hier keine falschen Vorstellungen. Deren 4-Wege-Server mit Power7 schlägt zwar alle x64-4-wege-server, jedoch bei einem wesentlich schlechteren EURO/SAPS- Verhältnis, und es gibt wahrscheinlich gute Gründe, warum man sich dort entschlossen hat, nicht zu beweisen, dass ein Power7 8-Wege-Server alle 8-Wege-Konfigurationen mit Intel schlagen kann. Die aufschlussreichste Ergebnis dieser Auswertung ist, dass x64 für Linux oder Windows die notwendige Leistung liefert, egal ob Sie sich für multiple, hochsymmetrische (und wahrscheinlich Blade-basierte) 2-Wege-Server-Konfigurationen in Ihrem Rechenzentrum entscheiden oder Sie den Weg der Konsolidierung und Virtualisierung auf hochperformanten 4- oder 8-Wege-Servern gehen. Tatsächlich bietet sich hiermit sogar die Gelegenheit, den Beschaffungs- und Bereitstellungsprozess für Ihr Rechenzentrum auf eine (1) Server-Architektur und zwei (2) Betriebssysteme zu reduzieren. Insgesamt muss angemerkt werden, dass die einzige Prozessorarchitektur, die bei jedem einzelnen Aspekt dieser Auswertung, also Preis-Leistungs-Verhältnis, Leistung pro Sockel, pro Kern und pro Thread sowie verfügbare absolute Server-Leistung, einen Platz unter den besten 10 einnehmen konnte, von Intel stammt REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

40 Virtualisierung neu bewertet Das Kapitel zur Virtualisierung wird sehr kurz ausfallen, für einige vielleicht zu kurz. Aber dafür gibt es einen einfachen Grund: Virtualisierung in Verbindung mit x64-architekturen, einst eine Nischenlösung, die entwickelt wurde, um einigen wenigen und sehr speziellen Landschaftsszenarien wie solchen für Schulungen oder mit niedrigen Leistungsanforderungen zu begegnen, und die als solche auch im Whitepaper von 2008 abgehandelt wurde, hat mittlerweile einen festen Platz sowohl in der Welt von Linux als auch von Windows eingenommen, wird von so gut wie allen eingesetzt und hat die meisten, wenn nicht sogar alle Beschränkungen überwunden. Es gibt eine Reihe technisch ausgereifter Virtualisierungslösungen für Linux in SAP-Umgebungen, hauptsächlich VMware und KVM, und mehrere Benchmarks von verschiedenen Hardware-Anbietern haben gezeigt, dass die Grenzen ihrer Leistungsfähigkeit eher theoretischer als tatsächlich praktischer Natur sind und dass Leistungseinbußen in Folge der Virtualisierung bei sehr akzeptablen 10% oder weniger liegen. Als einzige Einschränkung sollte an dieser Stelle angemerkt werden, dass wir davon ausgehen, dass XEN-basierte Technologien langfristig wahrscheinlich ernste Probleme bekommen und möglicherweise nicht überleben werden. Aber sogar hier müssen wir einräumen, dass wir sehr große Kunden beraten haben, die sehr große Umgebungen auf genau dieser Technologie betreiben, und keiner dieser Kunden eine Wechselabsicht gezeigt hat. REALTECH hat Produktivlandschaften implementiert und automatisiert, die vollständig für SUSE und Red Hat Linux virtualisiert sind, Oracle oder DB2 nutzen, auf VMware, KVM oder XEN auf Hardware von so ziemlich jeden Anbieter am Markt laufen und SAP-Anwendungsservices für mehrere tausend parallel arbeitende Anwender bereitstellen, die Eingaben in Datenbanken von mehreren Terabyte Größe machen. Die wahrscheinlich einzige Herausforderung bei diesem Thema stellt die Ermittlung der besten (d.h. kostenoptimierten, bestperformanten, mit wenig Administrationsaufwand verbundenen und zum Know-how-Profil Ihrer IT-Mitarbeiter passenden) Kombination aus den oben genannten Lösungen dar. Aber abgesehen davon bleibt uns nur noch, auf einen bekannten Slogan eines Sportartikelherstellers zu verweisen: Just do it! 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

41 Green IT neu bewertet Das Thema, das unserem Whitepaper die größte Aufmerksamkeit und zweifellos auch die lebhaftesten und kontroversesten Diskussionen bescherte, war die Auseinandersetzung mit Fragen der Green IT. Bei uns haben sich eine Reihe von Ingenieuren von verschiedenen Hardware-Anbietern gemeldet und darauf hingewiesen, dass elektrische Eingangsleistung und Wärmeabgabe nach dem physikalischen Gesetz der Energieerhaltung die gleiche Rangliste hätten ergeben müssen was nicht der Fall war. Da ich, der Autor dieses Whitepapers, diplomierter Physiker bin, hätte ich diesen berechtigten Einwänden nur schwer widersprechen und mich gleichzeitig weiterhin selbst ernst nehmen können. Bei unseren Versuchen den Gründen dieser Abweichung über den Kontakt per auf den Grund zu gehen, entdeckte einer der Ingenieure, dass es laut der von seinem eigenen Unternehmen (genauer gesagt seiner eigenen Abteilung) veröffentlichten Datenblätter auch einen Unterschied zwischen elektrischer Eingangsleistung und Wärmeabgabe gab und das gut 10% der Energie sich einfach in Luft auflösten. Letztendlich fanden wir eine, wie ich denke, gute Erklärung für die Unterschiede: Die Eingangsenergie wird in Server-Datenblättern in den meisten Fällen, aber nicht in standardisierter Form, als Höchstwert angegeben. Dies soll dabei helfen, die elektrischen Anlagen in Rechenzentren richtig zu dimensionieren. Aber diese Höchstwerte dürfen nicht zur Berechnung des durchschnittlichen Energieverbrauchs oder der durchschnittlichen Energieabgabe verwendet werden. Dafür sind die Wärmeabgabewerte gedacht. Diese werden in der Regel als Durchschnittswert pro Stunde angegeben. Folgerichtig haben wir für dieses Whitepaper auch ausschließlich diese Werte genutzt. Wir haben uns zudem für einen neuen Ansatz bei der Untersuchung der Green-IT-Aspekte entschieden. Wie bereits festgestellt, ist der Trend hin zu Linux in SAP-Rechenzentren in weiten Teilen eine Architekturentscheidung zugunsten der x86_64-prozessorarchitektur. Darum hat sich das Augenmerk unserer Green-IT-Betrachtung weg von den Servern und hin zum Energieverbrauch der CPUs verschoben. Und da Einzelwerte immer auch angreifbar sind, wollen wir Tendenzen für Prozessorfamilien aufzeigen. Mehr werden Sie nicht benötigen, um zu entscheiden, mit welcher Architektur Sie die beste CO2-Bilanz erreichen können. Versprochen! 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

42 Energiediagramm 1: Wärmeabgabe pro Sockel im Verhältnis zur Kapazität pro Sockel. Bitte beachten Sie die wesentlich höhere Kapazität von x64 und Power bei vergleichbaren Verbrauchswerten. Lassen Sie uns mit einem Blick auf die Wärmeabgabe der Prozessoren in den jeweiligen Servern beginnen. Je weiter rechts und weiter unten im Verhältnis zur vertikalen Achse sich eine CPU 11 befindet, desto besser ist ihre Position in dieser Graphik. Uns ist zuallererst aufgefallen, dass die CPU-Familien mit kürzlich erfolgten (in Benchmarks nachgewiesenen) Weiterentwicklungen offensichtlich ihre Kapazität vervielfacht haben, im Vergleich zu älteren Prozessoren aber einen konstanten Energieverbrauch aufweisen. Wie schon zuvor gezeigt, hat die Power-Familie die durchschnittlich höchste Kapazität pro Sockel bei durchaus positiven Umwelteigenschaften. Hinsichtlich der Kapazität können die besten Intels fast mit den besten Power-CPUs mithalten, dies jedoch bei besseren Energiewerten. Wie schon zuvor angedeutet, liegen die besonderen 11 In diesem Kapitel verwenden wir die Begriffe CPU, Sockel und Prozessor in gleicher Weise und mit gleicher Bedeutung REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

43 Stärken von AMD im Gesamtenergieverbrauch pro Sockel, was sich vermutlich auf die geringfügig niedrigeren Frequenzen im Vergleich zu Power und Xeon zurückführen lässt. Bei Green-IT-Aspekten gilt das gleiche wie schon zuvor bei den wirtschaftlichen Aspekten: Wo es keinen Fortschritt gibt, können auch keine Fortschritte erzielt werden. Dies bedeutet, dass, wenn man keine neuen Prozessoren entwickelt und sie nicht durch Benchmarks untermauert, man in Vergleichen schlecht aussehen wird. Stillstand heißt, überholt zu werden, und dies trifft voll und ganz auf SPARC und Itanium zu. Und auch hier gilt wieder, dass der Itanium sogar noch besser dasteht, als er tatsächlich ist, weil seine Benchmark-Grundlage von allen anderen abweicht. Energiediagramm 2: Wärmeabgabeeffizienz in SAP pro Watt pro Sockel im Verhältnis zum Benchmark-Datum. Bitte beachten Sie die zunehmende Effizienz bei neueren Architekturen. Damit kommen wir zum nächsten Diagramm: Wie hier gezeigt, gehen bessere Ergebnisse in der Umweltverträglichkeit in der Regel mit neueren Entwicklungen einher. Dies ist jedoch kein festgeschriebenes Gesetz, hauptsächlich aufgrund der Tatsache, dass die Werte beim 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

44 Energieverbrauch auch mit dem Server-Typ und dem vorgesehenen Verwendungszweck zusammenhängen, zudem gibt es eine große Vielfalt der Server im 2-Tier SD-Benchmark und nicht alle lassen sich untereinander vergleichen. Aber die allgemeine Tendenz ist eindeutig. Zwischen Anfang 2011 und Mitte 2012 konnte Intel zum Beispiel die durchschnittliche Effizienz bei der Wärmeabgabe mindestens verdoppeln. Energiediagramm 3: Kapazität pro Sockel im Verhältnis zur Wärmeabgabe pro Kern. Multi-Kern-Architekturen zeigen eine geringfügig bessere Energieeffizienz. Welche ist also die vielversprechendste Technologie beim Thema Energiesparen? Nun ja, offensichtlich sind neuere CPU-Generationen kleiner dimensioniert, was bessere Energieeigenschaften zur Folge hat. Aber dies ist allgemein bekannt. Eine höhere Anzahl der Kerne pro Sockel hat ebenfalls einen eindeutig positiven Effekt auf den Energieverbrauch. Es scheint, dass die daraus resultierenden Synergieeffekte innerhalb eines Sockels ein wünschenswertes energetisches Verhalten fördern. Die Graphik oben zeigt eindeutig, dass die Wärmeabgabe pro Sockel fast linear mit steigender Anzahl der Kerne abnimmt, während die 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

45 Kapazität pro Kern bei Multi-Kern-CPUs zumindest konstant bleibt oder steigt. Als Ergebnis erhalten Sie mehr SAPS-Leistung bei geringerem Energieverbrauch, genau das erwünschte Ergebnis. Die CPUs, die nichts Neues zu bieten hatten, schneiden im Vergleich wieder einmal schlechter ab. Es gibt weitere Aspekte, die in diesem Kapitel untersucht werden könnten, so zum Beispiel, dass nicht alle Server gleich sind und dass bei der gleichen CPU erhebliche Abweichungen bei den Energieverbrauchseigenschaften auftreten können. Wir werden im Anhang ein konkretes Beispiel vorstellen, möchten an dieser Stelle aber keine weitere Zeit darauf verwenden REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

46 Groß. Kritisch. Die wahrscheinlich häufigsten Fragen, die wir im Zusammenhang mit SAP auf Linux zu hören bekommen, sind: Wie groß dürfen die Systeme sein, bevor sie zu groß für Linux werden? Welche Projektgrößen sind für REALTECH (oder jeden anderen auf dem Migrationsmarkt) machbar? Was ist die Maximalgröße für zu migrierende Systemlandschaften? Wie auch in anderen Bereichen des täglichen Lebens wird die Frage der Größe überbewertet. Wie dem auch sei, mit Blick auf das Thema SAP auf Linux können eine eingehende Erörterung und einige Beispiel helfen, unseren Standpunkt hier zu erläutern. Große Systeme Wie schon in den vorausgegangenen Whitepapern vorhergesagt, hat die Leistungsfähigkeit von Linux-Server-Systemen bereits beinahe alles erreicht oder sogar überschritten, was mit UNIX im Bereich des Möglichen liegt. Noch wichtiger aber ist, dass die Leistungswerte, die hier erzielt werden, längst weit jenseits von allem liegen, was heute an Rechenleistung für ein einzelnes System verlangt wird, zumindest wenn wir die heutige Generation von SAP-Software und -Datenbanken als Betrachtungsgrundlage heranziehen. In der Benchmark-Generation, die in diesem Whitepaper untersucht wurde, erzielen drei Intel-basierte Server mit nur acht Sockeln mehr als SAPS (IBM System x3850 X5, Fujitsu PRIMEQUEST 1800E2, HP ProLiant DL980 G7), was nur noch von einem 64-Sockel-SPARC-Server übertroffen wird ( SAPS). Server mit diesen Leistungswerten werden aber niemals Engpässe verursachen, egal welche Anwendung Sie darauf laufen lassen. Warum? Weil die Quellen möglicher Engpässe anderswo liegen und in keinerlei Zusammenhang mit Linux (oder jedem anderen Betriebssystem) stehen. Hierfür hat REALTECH zwei Hauptverdächtige identifiziert: I/O-Durchsatz und die SAP-Anwendungs-Software selbst. Der erste Verdächtige ist schnell erklärt: Wenn Ihre Datenbank oder Ihre Speichersysteme nicht in der Lage sind, die von den Anwendungs-Servern weitergeleiteten Informationen in beliebiger Bandbreite zu streamen und zu schreiben, werden natürlich irgendwann alle Caches gefüllt sein und weitere Eingaben bis zum Commit der geschriebenen Informationen beschränken. REALTECH ist ein Experiment aus den Laboren eines x64-hardware-anbieters bekannt: Unter Einsatz eines 4-Sockel-Intel-Servers der neuesten Generation, seiner bevorzugten 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

47 High-End-SAP-Datenbank und seiner besten High-End-Speicherlösung, ausgelegt und optimiert für das Akzeptieren von weit mehr als 100,000 IOPS in kontinuierlicher Schreibgeschwindigkeit, schaffte man es dort tatsächlich, das gesamte Speichersystem mit diesem einen 4-Sockel-Server zu 100% auszulasten und das nur durch die Zuweisung einer Reihe von parallelisierten Batch-Jobs mit sehr hoher Schreiblast. Das ursprüngliche Ziel des Experiments, die I/O-Grenzen der spezifischen x64-server-generation zu ermitteln, war gescheitert. Die Ergebnisse waren aber nichtsdestotrotz vielversprechend und ermutigend, haben sie doch bewiesen, das beim Design von High-End-SAP-Systemen Server-I/O nicht unbedingt der Bereich ist, wo man nach Einschränkungen suchen muss (zumindest nicht, wenn das Mainboard über vier Sockel und entsprechende I/O-Busse verfügt). Das bringt uns zum zweiten Verdächtigen: Im Jahr 2011 übernahm REALTECH eine Architekturrolle in einem Proof of Concept in der Finanzwirtschaft und verglich eine Reihe von Systemen, die die folgenden Spezifikationen erfüllen mussten: Ausführung von aneinandergereihten Batch-Jobs im SAP Bank Analyzer mit einem maximalen Anwendungsdurchsatz von 20 Millionen Transaktionen in einem Zeitraum von weniger als acht Stunden hin zur einer TB Datenbank nach Erreichen der vollen Einsatzfähigkeit. Die errechnete erforderliche I/O-Leistung würde bei IOPS kontinuierlicher Bandbreite in einem Lese-Schreib-Verhältnis von 80/20 liegen, die erforderliche Anwendungsleistung bei SAPS in einem Datenbank-Anwendungs-Verhältnis von 60/40 unter hoher Last. Dies waren die Mindestanforderungen, die in einem Proof of Concept nachgewiesen werden sollten. Zwei der vier Hardware-Anbieter, die zu dem Benchmark-PoC eingeladen wurden, boten Lösungen auf Basis von x64/linux an, ein anderer setzte auf x64 und ein anderes Betriebssystem. Jeder der Anbieter entschied sich für seine jeweils bevorzugte High-End- Speicherlösung. Keiner von ihnen war in der Lage, die spezifizierten Leistungsanforderungen zu erfüllen und die festgelegte Jobkette in der vorgegebenen Zeit abzuschließen. Und keiner von ihnen blieb bei der Hardware, dem Betriebssystem oder der Datenbank stecken. Das eigentliche Problem war, dass die SAP-Anwendungs-Software ab einem gewissen Punkt in der Jobkette nicht in der Lage war, gewisse Aufgaben zu parallelisieren, sondern für einige Zeit und einige Schritte zu einem sequentiellen Prozess mit nur einem Thread zurückkehrte. Zu diesen Zeiten waren alle eingesetzten High-End-Server und -Speicherlösungen praktisch im Leerlauf und hatten so gut wie nichts zu tun, während sie in einigen Phasen der Stapelverarbeitung tatsächlich bis an die Grenzen ihrer Leistungsfähigkeit gebracht wurden. Diese Kombination der Verarbeitungsschritte hat jedoch hauptsächlich bewiesen, dass SAP-Anwendungs-Software nicht unbedingt für 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

48 klassische Mainframe-Massentransaktionsprozesse ausgelegt ist und diese Tatsache wahrscheinlich eher für Engpässe verantwortlich ist als jede physische Grenze. Andererseits ist SAP-Software eigens für die Erbringung zufriedenstellender Leistung bei der Arbeit auf vielen Betriebssystemen ausgelegt und Linux ist nur ein weiteres in dieser Reihe und, im positiven Sinne, nichts Besonderes oder längst nichts Besonderes mehr. Um die Neugier unserer Leser zu befriedigen: Es gab zwischen den untersuchten Lösungen Unterschiede bei den Verarbeitungszeiten während der Hochlastphasen sowie eindeutige Unterschiede was den Schwierigkeitsgrad der Konfiguration, der Handhabung, der Wartung und des Betriebs betraf, alles weitere wichtige Aspekte für den Kunden. Eine SUSE-Linux-Umgebung auf Intel-CPUs und Fujitsu-FlexFrame-Hardware hat schließlich das Rennen gemacht. Aus funktioneller Sicht ist die langfristig beste Lösung zur Erfüllung aller High-End-Spezifikationen wahrscheinlich HANA, aber dies wird es erforderlich machen, dass SAP eine Reihen von Abläufen in der Bank-Analyzer-Jobkette vollkommen überarbeitet, dabei eine Reihe von zeitintensiven Aggregationsschritten weglässt und die Daten direkt aus den In-Memory-Tabellen zieht. Was den täglichen Betrieb angeht, so sollen unsere Betrachtungen zeigen, dass es praktisch keine Grenzen 12 für die Größe der auf Linux einsetzbaren Systeme oder Datenbanken gibt. Uns sind Datenbanken mit 10, 15 und 20 TB bekannt, die problemlos auf dieser Plattform laufen. Wir selbst haben Produktivsysteme mit bis zu 8 TB eingerichtet oder migriert und an noch größeren Systemen wird bereits gearbeitet. Es gibt jedoch eine Grenze, die berücksichtigt werden muss. Dabei handelt es sich um die maximale Downtime, die für den eigentlichen Migrationsprozess zur Verfügung steht, besonders im Hinblick auf das Produktivsystem. Zu Informationszwecken hatten wir vor kurzem eine Telefonkonferenz mit einem Kunden, der ein geschäftskritisches 86 TB BW-System betreibt, unglücklicherweise auf HP-UX/Oracle 13. Die Migration dieses Systems wird eine echte Herausforderung darstellen und dabei wird es tatsächlich keinen großen Unterschied machen, für welche Zielplattform sich der Kunde entscheidet. Bisher haben wir in Migrationsprojekten maximale Migrationsdurchsätze von bis zu 300 GB/h für einzelne Systeme erzielt, je nach Ausgangs- und Zielbetriebssystem und Datenbank, verfügbarer Hardware, Speicheraufbau, Migrationsverfahren und der Anzahl der Optimierungsläufe. In der Regel werden die endgültigen Grenzen der Downtime-Minimierung durch die I/O-Möglichkeiten der Speicherlösung bestimmt. 12 Wie in diesem und anderen Kapiteln beschrieben, gibt es jedoch wichtige Regeln, die es zu befolgen gilt. 13 Wodurch sich ein gewisser Handlungsbedarf ergibt REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

49 Durch den Einsatz von fortschrittlicheren (und damit teureren) Speicheroptionen, also SSD, könnte man diesen Wert auf 800 GB/h verbessern. Aber es gibt zwei entscheidende Hindernisse: Das fängt damit an, dass, selbst wenn man hier die derzeit besten Werte für klassische Migrationen mehr als verdoppeln würde, dies auf eine Migrationslaufzeit von über 100 Stunden, d.h. mehr als vier volle Tage, hinauslaufen würde, und dabei sind Funktionstests und Backup noch nicht mit inbegriffen welche zur technischen Downtime hinzukommen und gemeinsam die gesamte Downtime ergeben. Das andere Hindernis muss nicht weiter erklärt werden: Stellen Sie sich nur einmal die Rechnung vor, die Ihnen Ihr Speicherhersteller präsentieren würde, wenn Sie sich für 86 TB Netto-SSD-Speicher, gespiegelt, entscheiden würden und Sie in einer derart geschäftskritischen und großen Umgebung dann noch mal ein identisches Setup für Ihr QA-System benötigen... Es hat schon seinen Grund, warum man Systeme nicht zu groß werden lassen sollte. Archivierung ist weiterhin wichtig vernachlässigen Sie sie nicht, wenn Ihre Systemumgebung es zulässt, denn wenn ein System eine gewisse Größe überschreitet, sind technische Prozesse nicht mehr zu beherrschen. Wir sind uns nicht sicher, welchen Weg dieser spezielle Kunde einschlagen wird. Vielleicht liegt die Antwort in neuen Technologien wie HANA. Hier geht man von einem durchschnittlichen Komprimierungsfaktor von 5:1 aus, was die Größe dieser BW-Datenbank auf gut 17 TB reduzieren würde. Oder der Kunde muss sich für ein spezialisiertes und nur auf ihn zugeschnittenes Projekt entscheiden, so zum Beispiel für eine inkrementelle Migration, bei der ein Großteil der Daten schon vor der eigentlichen Downtime übertragen wird. Es ist alles machbar, aber die Exklusivität einer Technologie schlägt sich auch in ihrem Preis nieder REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

50 Große Kunden & große Migrationsprojekte Nachdem wir festgehalten haben, dass es praktisch keine Größenbeschränkungen für den Betrieb einzelner SAP-Systeme auf Linux und x64 gibt, können wir jetzt einen Blick auf die Größe der Gesamtumgebungen und der Kunden werfen, die sich für diese Plattform entscheiden. Erwarten Sie in diesem Kapitel keine großen Überraschungen. Wir werden Ihnen aber einige beeindruckende Zahlen und Beispiele nennen und Ihnen wichtige Informationen darüber geben, was es bei der Planung von großen Migrationsprojekten unbedingt zu beachten gilt. In einem der vorausgegangenen zwei Whitepaper haben wir darauf hingewiesen, dass sich British Telecom einer reinen Intel-Strategie zuwenden wollte. Zwischen REALTECH und diesem Kunden gibt es keinerlei Verbindung, aber bei unseren Nachforschungen sind wir auch auf andere Marktführer gestoßen, die sich in die gleiche Richtung bewegen. Wie schon im Statistikteil dieses Dokuments angesprochen, sind die größten Kunden, die sich für Linux entscheiden, in Europa angesiedelt, wir wurden aber auch schon von großen amerikanischen Unternehmen mit den gleichen Absichten kontaktiert. In diesem Whitepaper geht es nicht darum, Marketing-orientierte Erfahrungsberichte oder Referenzkunden vorzustellen, wir wollen lediglich Fakten, Zahlen und Beispiele liefern, um glaubwürdig darzulegen, dass SAP auf Linux eine mögliche Lösung unter anderen ist. Darum konzentriert sich dieser Abschnitt auf die Branchen, mit denen wir gearbeitet haben, sowie auf die Struktur und Größe der jeweiligen SAP- Umgebungen, jedoch nicht auf die Namen der Unternehmen. Im Whitepaper von 2008 fiel der Finanzsektor abgesehen von einigen eher kleinen Versicherungsunternehmen als die Branche auf, in der das ansonsten steigende Interesse an Linux weitestgehend nicht geteilt wurde. Das hat sich seitdem grundlegend geändert. Das erste wirklich große Unternehmen, das mit der Absicht an uns herantrat, seine komplette SAP-Systemlandschaft zu x64 (die erste richtungsweisende Entscheidung) und schließlich zu Linux (gefolgt von der zweiten) zu migrieren, war einer der weltgrößten Versicherer/Rückversicherer, ein Unternehmen mit 50 Milliarden Euro Prämieneinnahmen, das Vermögenswerte in Höhe von 200 Milliarden Euro in über 70 Ländern verwaltet. Sein aktuelles Hauptrechenzentrum beherbergt mehr als Anwendungen auf mehr als Windows- und Linux-Servern 14, mit insgesamt, einschließlich SAP aber nicht ausschließlich, 4 PB 15 Datenspeicher. Bis dahin hatten Unternehmen dieser Größenordnung, die uns zum Thema Linux 14 Seit 2011 keine UNIX-Server mehr. 15 Ja, das sind Terabyte Gesamtdatenvolumen REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

51 ansprachen, dies in der Regel mit der Absicht getan, bestimmte Systemlandschaften oder SAP-Produkte zu migrieren oder neu aufzusetzen, aber nicht alles auf einmal anzugehen. Die Systemlandschaft beinhaltet damals wie heute 13 SAP-Produktivsysteme sowie verschiedene Entwicklungs-, QA- und Projektsysteme mit einem Gesamt-SAP-Datenbank-Volumen von netto 100 TB. Die zwei größten zu migrierenden Produktivlinien hatten Projektbeteiligte aus 14 Fachbereichen. Wie organisiert man eine solche Migration? Was ist der Schlüssel zum Erfolg? Die vollständige Migration einer großen und historisch gewachsenen SAP-Systemlandschaft in einem großen Unternehmen ist sowohl unter technischen als auch unter organisatorischen Gesichtspunkten ein hochkomplexer Prozess. Als solcher erfordert er eine Vielzahl von Entscheidungen und Vorgehensweisen, von denen Wohl und Wehe des Migrationsprojekts abhängen. Die erste Ebene der wichtigen Entscheidungen bilden organisatorische Fragen. In den Fällen, in denen wir Migrationsprojekte antrafen (oder hinzugerufen wurden, meist zu einem späten Zeitpunkt), die schon gekippt waren oder kurz davor standen, traf einer oder mehrere der folgenden Punkte zu: Mangelnde Planung oder ein unrealistisch knapp bemessenes Budget oder beides Mangel an ausreichender Zeit, um alle erforderlichen Aufgaben durchzuführen Nicht vorhandenes oder zumindest unzureichendes internes und externes Projekt-Management Unzureichende Kapazitäten an wichtigen internen oder externen Projektmitarbeiten während des Projekts, einschließlich zu weniger zertifizierter Migrationsexperten Fehlende Akzeptanz für das neue Betriebssystem oder die neue Datenbank bei internen Mitarbeitern, einschließlich mangelnder Kenntnisse der neuen Umgebung Die Lösungen entsprechen nicht den Erwartungen des Managements und wurden nicht ausreichend evaluiert, bevor grünes Licht gegeben wurde Für fehlende Technologiekomponenten wurden Workarounds entwickelt, anstatt dass benötigte Lizenzen erworben wurden Lassen Sie uns das näher erläutern. Um eine Migration von SAP-Server-Infrastrukturen in der oben beschriebenen Größenordnung erfolgreich durchzuführen, benötigt man Zeit, Geld und Arbeitskraft. Tatsache ist, dass dies für 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

52 jede SAP-Server-Infrastruktur-Migration gilt, auch dann, wenn sie viel kleiner ist und ganz bestimmt, wenn sie noch größer ausfällt. Und der wahrscheinlich wichtigste von den drei Faktoren ist Zeit, vor allem und ganz besonders die Zeit, die Sie sich selbst für notwendige Planungen und Entscheidungen einräumen, noch bevor die eigentliche Projektarbeit beginnt. Warum? Weil Zeit die einzige Ressource ist, die sie nicht wieder aufstocken können, wenn Sie Ihnen einmal ausgegangen ist. Der Kunde aus dem Beispiel oben führte ein Jahr lang interne Untersuchungen und Studien durch, bevor er sich entschloss, in der Zukunft ausschließlich auf x64-prozessor-architekturen zu setzen. Die Entscheidungsfindung für Linux oder Windows dauerte ein weiteres halbes Jahr. Für die Auswahl des richtigen Migrationspartners 16 und die Definition und Aushandlung eines Vertrags für ein Migrationsprojekt zum Festpreis nahm man sich noch einmal vier Monate Zeit. Nach dem Kick-off des Hauptprojekts begannen wir mit der übergreifenden Planung für die Migration der gesamten Landschaft, einschließlich der Reihenfolge, in der die Migration der Produktivsysteme durchgeführt werden sollte. Für die kritischsten dieser Systeme waren es noch achtzehn (18) Monate bis zur nächsten und einzig möglichen Downtime mit genau einem Puffer-Wochenende eine Woche später. Alle anderen Wochenenden über diesen Zeitraum standen aufgrund von verschiedensten Geschäftsanforderungen nicht zur Verfügung. Es war gut, dass sich der Kunde dieser Situation bewusst war und die Dinge nicht überstürzen wollte, um einen schnelleren RoI zu erzielen. Aber durch derartige Einschränkungen ergeben sich auch immer wieder Chancen. In diesem Fall machte es der Zeitplan möglich, die gesamte Organisation mit der neuen Plattform vertraut zu machen und die Akzeptanz für Linux zu steigern, ganz besonders bei der eher skeptischen und an Superdome gewöhnten UNIX- und Server-Administration. REALTECH erarbeitete eine Migrationsreihenfolge für alle neunzig Systeme, von klein zu groß, von einfach zu kompliziert und von relativ wichtig zu äußerst geschäftskritisch. Und wir führten alle Mechanismen und Instrumente des Migrationsprojekt-Managements schon bei den allerersten Migrationen ein, selbst bei den Systemen, für die dies vielleicht wie zu viel des Guten gewirkt haben mag. Als Ergebnis ergaben sich erwartbare Spannungen, die bei IT-Projekten dieser Größe niemals ausbleiben, schon während des Einschwingprozesses zu Beginn des Projekts, lange bevor die kritischen Produktivmigrationen anstanden. Zudem nutzte unser Kunde die lange Planungszeit, um Fachbereiche und Key User schon frühzeitig für Test- und Genehmigungsprozesse einzuteilen, einschließlich der Wochenendplanung. Im Endeffekt war jeder einzelne Go-Live beim ersten Versuch ein Erfolg und alle Zeitpläne konnten eingehalten werden. 16 REALTECH REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

53 Wie schon erwähnt, hat all dies natürlich auch seinen Preis: Sorgfältige und wiederholte Tests aller technischen Migrationen erforderten bis zu sechs parallel arbeitende Migrationsexperten und einige hundert Tage technischer Beratung. Weitere 30% des Beratungsaufwands gingen in das Projekt-Management auf unserer Seite. Etwa den gleichen Aufwand investierte der Kunde in Infrastruktur-Services, SAP-Basis, Testläufe und internes Projekt-Management. Die Graphik unten illustriert den Prozess, den wir mittlerweile bei jeder einzelnen Systemlandschaft und in jedem Migrationsprojekt, egal ob groß oder klein, zur Anwendung bringen. Das Erfolgsrezept für dieses Projekt waren realistische Planung, ein machbarer Zeitrahmen, erfahrenes Projekt-Management auf beiden Seiten, sachkundige Migrationsexperten und REALTECHs Fähigkeit, dieses Team je nach Bedarf jederzeit aufzustocken. Dies sind die Dinge, auf die Sie bei der Definition Ihres Migrationsprojekts achten sollten. Und um die Eingangsfrage zu beantworten: Ausgehend von dieser Erfahrung und mit Blick auf bereits laufende noch größere Projekte glauben wir, dass mit dem richtigen Ansatz die Größe eines Kunden, Projekts oder einer Landschaft beim Übergang von UNIX zu Linux keinerlei Hindernis darstellt REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

54 Aber unsere Erfahrungen zum Thema Migrationsprojekte kommen längst nicht alle aus diesem Projekt. Es gibt noch andere versteckte Fallen, wie unsere kleine Liste erkennen lässt. Die letzte organisatorische steht meist im Zusammenhang mit zu hohen Erwartungen hinsichtlich möglicher Einsparungen und dem Wunsch, auch noch das Letzte aus diesem Potenzial herauszuholen. In diesen Fällen werden technische Entscheidung vom Management und nicht von den Technologieexperten getroffen und die technisch beste Lösung wird durch den zweit- und manchmal auch drittbesten Workaround ersetzt, der scheinbar die direkten Lizenz- oder Implementierungskosten senkt. Das Worst-Case-Szenario hier ist, dass Eigenschaften und Funktionen nur auf dem Papier begutachtet und abgesegnet und dann hinterher die Anforderungen und Erwartungen in keinster Weise erfüllt werden. Solche Lösungen rächen sich in aller Regel, entweder durch ein Versagen auf technischer Ebene, wo sie Downtimes verursachen oder eine erneute Konfiguration nötig machen, oder indem sie den Administrationsaufwand für die neue Landschaft dauerhaft erschweren und erhöhen. Dagegen haben wir ein einfaches Rezept: Vermeiden Sie Workarounds. Entscheiden Sie sich immer für die technisch beste Lösung für Ihre Umgebung. Planen Sie die optimale Lösung in Ihr Budget ein das ist im Endeffekt günstiger. Es ist wirklich so einfach. Und was Funktionen und neue Konzepte angeht suchen Sie sich gute Referenzen, von denen Sie mehr erfahren können oder besser noch, überprüfen Sie die Tragfähigkeit Ihres Konzepts mit einer PoC-Implementierung in Ihrer eigenen Umgebung, bevor sich für die Produktivsetzung entscheiden. Nur so können Sie wirklich auf Nummer sicher gehen! Auf der zweiten Ebene der anstehenden Entscheidungen folgen die technischen Fragen und auch hier gibt es wichtige Punkte, die es zu bedenken gilt, und auch hier kann man schnell vom richtigen Weg abkommen. Hier eine Liste der typischen Probleme, die uns begegnet sind: Die Komplexität der Zielumgebung wird unterschätzt Der Best of Breed -Ansatz wird nicht berücksichtigt ganz besonders der Fehler der eins zu eins Abbildung Funktionalitäten werden in den falschen Schichten der Architektur implementiert o Infrastrukturfunktionalitäten gehören in die Infrastrukturschicht(en) o Anwendungsfunktionalitäten gehören in die Anwendungsschicht(en) Schlüsselkomponenten werden hinsichtlich ihrer Robustheit und Funktionalität zu hoch bewertet 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

55 Sie haben vielleicht schon bemerkt, dass es in diesem Whitepaper um Linux geht. Die oben aufgelisteten Fehlerpotenziale sind zwar bei allen Migrationen gleich, aber in besonderem Maße typisch für Migrationsprojekte von UNIX zu Linux. Dies hängt wiederum wesentlich damit zusammen, dass sich UNIX und Linux so sehr ähneln, dass allzu oft irrtümlich davon ausgegangen wird, dass beide identisch seien. Das sind sie nicht! Das Versäumnis, die Best of Breed -Lösung einzusetzen, ist auf technischer Ebene das Gegenstück zum organisatorischen Fehler, um jeden Preis Geld einsparen zu wollen. Und in Verbindung mit UNIX und Linux ist uns eine besonders häufige Unterart begegnet, der Fehler der eins zu eins (1:1) Abbildung. Wenn Sie eine Landschaft von UNIX nach Windows umstellen, von iseries zu Linux oder diese Umstellung zwischen zwei anderen, vollkommen unterschiedlichen Betriebssystemen vornehmen, versteht es sich von ganz alleine, dass Sie gewisse Funktionen Ihrer Umgebung vollkommen überarbeiten, so zum Beispiel das Bonding, das Storage-Mapping, das Dateisystem-Layout, die Schnittstellen oder das Cluster-Setup. Dies ist einfach unumgänglich, da sich die Ausgangs- und Zielumgebungen nicht miteinander vergleichen lassen und sie einfach nicht zusammenpassen. Kommerzielle UNIXe und Linux sind sich aber so ähnlich, dass diese Layouts (und vieles mehr) allzu oft von Ausgangssystem zum Zielsystem übertragen werden, als wären die beiden identisch. Dies führt grundsätzlich zu technischen Komplikationen. Sie wissen nicht, wovon wir sprechen? Lassen Sie uns einen gemeinsamen Blick auf ein einfaches Beispiel aus der Praxis werfen, das uns in einem kürzlich durchgeführten Migrationsprojekt von UNIX nach Linux begegnet ist. Die Graphik auf der nächsten Seite zeigt alle Schichten, die Sie beim Layout des Speicherplatzes für ein SAP-System auf Oracle berücksichtigen müssen, vom Dateisystem bis hin zur physischen Festplatte. Es gibt nur einen, auf den ersten Blick unbedeutenden Unterschied zwischen dem Layout des HP-UX-Ausgangssystems und dem Linux-Ziel: Letzeres bringt eine weitere Schicht für die Storage Mirroring Control ins Spiel, MDRAID. Das Ausgangssystem war ausgelegt als Extended Campus Cluster über zwei Rechenzentren mit Software-Spiegelung auf zwei HP EVAs, ein EVA in jedem Rechenzentrum. Für die Spiegelung kamen HP LVM und Mirror Disk UX zum Einsatz, mit HP MC ServiceGuard als der entsprechenden Cluster-Lösung. Auf dem Zielsystem entschied man sich für MDRAID als Nachfolger von Mirror Disk UX, womit theoretisch auch alle Anforderungen des Kunden hätten erfüllt werden können. Tatsächlich aber erwies sich MDRAID als zu kompliziert für die HP-UX-Administratoren dieses speziellen Kunden. Wir haben andere Linux-Migrationskunden, die mit dieser Komponente wunderbar zurechtkommen. Aber sie 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

56 übertragen ihre Designs normalerweise auch nicht eins zu eins und sind sich der Unterschiede zwischen Quelle und Ziel bewusst. Das war bei diesem Kunden nicht der Fall. In der Folge führte ein Administrator-Fehler zur Beschädigung des Dateisystems und Datenverlust. Dabei hatten alle Beteiligten noch Glück, dass dies während einer produktiven Go-Live-Migration passierte. So konnten die Daten ausgehend von einem definierten Zeitpunkt wiederhergestellt werden, und der Schaden begrenzte sich im Wesentlichen auf die Wiederholung der Go-Live-Migration. Es hätte auch weitaus schlimmer kommen können, wenn diese Daten im täglichen Betrieb verloren gegangen wären. Um in diesem Fall den Fehler der eins zu eins Abbildung zu vermeiden, wäre es besser gewesen, die benötigte RAID-Funktionalität eine Schicht weiter unten anzusiedeln und einen transparenten Speicher-Failover über einen Speicher-Hypervisor zu implementieren ein Speicher-Hypervisor ist transparent für Linux und für Administratoren wesentlich einfacher zu handhaben. Source architecture Target architecture Aber niemand ist perfekt und REALTECH bildet hier keine Ausnahme. Wir hätten in besagtem Projekt schon früher nach diesem Fehler suchen, ihn finden und rechtzeitig eingreifen sollen. Das wird uns nicht noch einmal passieren REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

57 Hochverfügbarkeit & andere Formen hoher Kritikalität Um dies gleich von Anfang an klarzustellen: Hochverfügbarkeit ist ein Lebensstil für die IT-Administration und nicht nur eine Sammlung von Tools. Das heißt auch, dass, egal welche Lösung Sie mit dem Versprechen von Hochverfügbarkeit erwerben, diese Ihre Stabilitätsprobleme nicht lösen wird, wenn Ihre IT-Administration den Herausforderungen beim Betrieb einer kritischen Umgebung nicht gewachsen ist. So kann dieses Kapitel des Whitepapers zwar einen Überblick über die derzeit für Linux verfügbaren HA-Tools geben, aber um eine Umgebung wirklich hochverfügbar zu machen, reicht es bei weitem nicht aus, nur die richtigen Tools für Ihre Systemlandschaft auszuwählen und richtig zu konfigurieren. Hochverfügbarkeit sollte vielmehr als ständiger Prozess verstanden werden. IT-Manager, die für kritische Umgebungen zuständig sind, können das leicht für sich überprüfen. Haben Sie sich schon bei folgenden oder ähnlichen Gedanken ertappt: Ich verstehe nicht, wo unser Problem liegt. Ich habe schließlich für Hochverfügbarkeit bezahlt! Dann haben Sie den falschen Weg eingeschlagen. Vor diesem Hintergrund können wir uns nun den erhältlichen Hochverfügbarkeits-Tools für Linux zuwenden und untersuchen, wie gut diese dafür geeignet sind, Sie bei der Etablierung des Hochverfügbarkeitsprozesses zu unterstützen. Hochverfügbarkeits-Tools für SAP auf Linux Beim Thema Hochverfügbarkeit, eine ureigene UNIX-Domäne und das wichtigste Verkaufsargument für diese Plattformen, hat Linux in den letzten Jahren erhebliche Fortschritte gemacht. In diesem Kapitel möchten wir Ihnen einen Überblick über erhältliche Hochverfügbarkeitslösungen geben. Der Fokus liegt dabei auf Failover-Cluster-Software- Produkten für Linux. Wir werden uns kurz mit ihrer Geschichte befassen und Ihnen anhand unserer Erfahrungen aus kürzlich durchgeführten Projekten die Vor- und Nachteile jedes Produkts vorstellen. SUSE Linux Enterprise Server High Availability Extension SUSE Linux Enterprise Server High Availability Extension ist ein Add-on für SUSE Linux Enterprise Server. Angesichts der Länge des Produktnamens werden wir ihn auf SLES HA Extension abkürzen, auch wenn wir wissen, dass diese Abkürzung kein offizieller Produktname ist. Was die Lizenz betrifft, so müssen Sie SUSE Linux Enterprise High Availability Extension oder SUSE Linux Enterprise Server for SAP Applications erwerben. In Letzterer ist die High 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

58 Availability Extension neben anderen speziell für die Anforderungen von SAP-Anwendern entwickelten Software-Produkten und Services bereits enthalten. SLES HA Extension setzt sich aus drei Hauptkomponenten zusammen: Pacemaker Corosync OpenAIS Diese drei Hauptkomponenten setzen andere Teile des Open Cluster Framework (OCF), so zum Beispiel STONISH-Support, OCFS2, clvm2, DRBD und andere Funktionalitäten voraus oder nutzen diese. Alles in allem handelt es sich hierbei um eine recht leistungsstarke HA-Umgebung, die aber auch sehr komplex ist und einiges an Arbeit für Ihre IT oder Ihren Implementierungspartner bedeuten könnte und zudem fachkundige und erfahrene Mitarbeiter erfordert. Pacemaker ist aus dem Heartbeat-Projekt hervorgegangen und dient der Ressourcenverwaltung in Clustern. Die wichtigsten Messaging- und Membership-Funktionen werden unter dem Corosync-Projekt entwickelt. OpenAIS hält die Schicht mit der Implementierung des Application Interface Specification -Standards (AIS). AIS ist eine Sammlung von offenen Spezifikationen, die die Application Programming Interfaces (API) der für den Aufbau von Hochverfügbarkeitsanwendungen am häufigsten benötigten Funktionen definieren 17. Pacemaker wurde mit SLES 11 GA in der SAP-Welt eingeführt. Laut der Release Notes gibt einen Update-Pfad von Heartbeat und SLES 10 auf Pacemaker und SLES 11 SP1 (über das hb2openais.sh-tool). Aufgrund vieler erfolgter Änderungen halten wir es jedoch für das beste Verfahren, Cluster beim Upgrade von bestehenden SLES-10-Clustern auf SLES 11 SP1 neu aufzubauen. Die Ressourcen-Agenten sind Teil des OCF (Open Cluster Framework). Ein OCF-konformer Ressourcen-Agent kann in jeder Programmiersprache implementiert werden, da die API nicht sprachspezifisch ist. Die Mehrzahl der OCF-RAs werden jedoch als Shell-Scripts implementiert. Zu den verfügbaren Ressourcen-Agenten für SLES HA Extension gehören unter anderem solche für SAP-Instanzen und SAP-Datenbanken, diese sind bereits Teil des Pakets (ohne zusätzliche 17 Übersetzt aus dem Englischen. Quelle: REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

59 Kosten). Der Vorteil des OSS-Modells ist, dass Ihr Beratungspartner oder Ihre IT-Administration eigene RAs hinzufügen kann, vorausgesetzt, dass das notwendige Fachwissen vorhanden ist. Am Support für die Ressourcen-Agenten sind viele Akteure beteiligt die Autoren, einige REALTECH-Berater, die Linux-Anbieter SUSE und Red Hat und/oder die Community. Binärdateien werden vom Open-Source-Projekt und/oder SUSE unterstützt. Aufgrund des uneingeschränkten Supports für so ziemlich jede mögliche Hardware-Kombination kommt es nur selten vor, dass wir nicht mit Fehlern konfrontiert werden, und diese sind oftmals schwer zu reproduzieren und nur aufwändig zu beheben. Support für neue Hardware- oder Software- Versionen könnte einige Zeit in Anspruch nehmen. Wir wollen bei dieser Betrachtung aber nicht das negative in den Vordergrund stellen, und Pacemaker hat im Bezug auf SAP-Umgebungen durchaus einige wichtige und einzigartige technische Vorteile: Pacemaker unterstützt Master-Slave-Ressourcen und macht es so einfacher SAP Enqueue Replication zu implementieren. Pacemaker-Ressourcen oder Ressourcengruppen können mit einer einfachen Syntax konfiguriert werden (wohingegen die Kombination aus rgmanager & cman & SAP nur über eine XML-Datei konfiguriert werden kann, was sehr aufwendig ist). Pacemaker unterstützt komplexe Cluster-Regeln (Location, Co-Location, Reihenfolge). Pacemaker & Corosync unterstützen die Verschlüsselung der gesamten Cluster- Kommunikation Root-Passwörter werden nicht mit offenen Protokollen übertragen oder in lesbaren Dateien gespeichert. Und bitte verstehen Sie uns richtig: Ohne den Beweis des Gegenteils kann davon ausgegangen werden, dass die Entscheidung, nahezu jede verfügbare Hardware zu unterstützen, von SUSE zugunsten seiner Kunden und mit dem Ziel, die große Mehrheit der Systemlandschaften unterstützen zu können, getroffen wurde. Aber aufgrund dieser Unternehmenspolitik sollten Pacemaker-Konfigurationen mehr als jede andere Linux-HA-Lösung einer genauen Prüfung durch einen PoC in Ihrer spezifischen Umgebung unterzogen werden. Es ist sowohl für die Linux- Anbieter als auch für SAP unmöglich, jede mögliche HW/SW-Kombination zu testen, darum ist es unbedingt notwendig, die gewünschten Kernkomponenten zu validieren, bevor sich für die Produktivsetzung entscheiden. Und falls Sie sich Sorgen um die mit einem PoC verbundenen Kosten machen, muss man offen und ehrlich sagen, dass Ihre Umgebung vielleicht keine Hochverfügbarkeitslösung benötigt oder verdient REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

60 Es ist sicherlich als positiv zu bewerten, dass kein zusätzlicher Anbieter für die Architektur benötigt wird, wenn Sie sich für eine der oben genannten Lösungen entscheiden. Zudem erwarten wir erhebliche Fortschritte in der Reife der Lösung, da sich auch Red Hat für einen Umstieg auf Pacemaker entschieden hat und somit die beiden führenden Linux-Anbieter ihre Herangehensweise an SAP-Hochverfügbarkeit auf einen Nenner bringen. Darüber hinaus ist SLES HA mit Pacemaker eine der wenigen 18 Linux-HA-Lösungen, die bereits von SAP für dessen generisches HA-Interface zertifiziert wurden. SUSE Linux Enterprise High Availability Extension 11 Service Pack 2 (SP2) wurde zudem vor kurzem für SAP NetWeaver zertifiziert. Wir halten dies für einen wirklich bedeutenden Vorteil der Lösung. Hinsichtlich der Virtualisierung mit integrierten HA-Funktionen möchten wir auf die enge Zusammenarbeit zwischen SUSE und VMware beim Aufbau von hochverfügbaren virtualisierten SAP-Umgebungen hinweisen. Hochverfügbarkeit mit Red Hat Enterprise Linux Noch bis vor kurzem setzte Red Hat auf das rgmanager-basierte Red Hat High Availability Add-on, um die durchgängige Verfügbarkeit von Services in seinen Cluster sicherzustellen. Da rgmanager technologisch überholt ist (vergleichen Sie dazu die vorausgegangene Liste der Pacemaker-Vorteile, die so ziemlich alles enthält, was rgmanager fehlt), hat Red Hat angekündigt, mit dem nächsten großen RHEL-Release auf eine Pacemaker-basierte Lösung umzusteigen. Und bei Cross Campus Clustern und anderen großen Lösungen arbeitet Red Hat mit Symantec zusammen und empfiehlt Veritas Cluster. SteelEye LifeKeeper SteelEye LifeKeeper blickt auf eine lange Geschichte zurück und ist schon seit einiger Zeit auf einer Reihe von Betriebssystemen verfügbar, was für uns ein wichtiger Aspekt bei der Untersuchung der Eigenschaften und Qualitäten von HA-Tools war. Eine erste Version wurde Mitte der 1990er als eine Hochverfügbarkeitslösung von AT&T entwickelt. Seit über einem Jahrzehnt wird LifeKeeper jetzt von SIOS Technology Corp. weiterentwickelt und vertrieben. LifeKeeper unterstützt Linux und Windows und verfügt über einen klaren Upgrade-Pfad. Application Recovery Kits (ARKs) sind für eine Reihe von Unternehmensanwendungen, einschließlich SAP, und für professionelle Datenbankprodukte wie DB2 und Oracle verfügbar. 18 Das es in diesem Bereich viel Bewegung gibt, haben wir uns hier auf zurückhaltende Aussagen hinsichtlich der zertifizierten Lösungen beschränkt REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

61 Im Jahr 2007 wurde SteelEye LifeKeeper auf der LinuxWorld mit dem Best Clustering Solution Award ausgezeichnet. LifeKeeper verfügt über eine klar definierte Support-Matrix. LifeKeeper ist eine weitere HA-Lösung, die bereits von SAP für dessen generisches HA-Interface zertifiziert wurde, was in der Zukunft entscheidend für die schnelle Integration der Lösung in SAP-HA-Umgebungen sein wird. Der Einsatz von LifeKeeper verursacht zusätzliche Lizenzkosten und erhöht die Anzahl der Anbieter, die in der Architektur vertreten sind. Andererseits werden die LifeKeeper Application Recovery Kits von nur einem Anbieter unterhalten, Support für neue Hardware oder Software- Versionen wird unserer Erfahrung nach recht schnell zur Verfügung gestellt und Hochverfügbarkeit ist eine Kernkompetenz von SIOS. LifeKeeper unterstützt ohne Einschränkungen drei der vier großen x64-virtualisierungslösungen, Citrix XEN, Microsoft Hyper-V und VMware, und bietet Plug-ins für VMware HA Application Monitoring an. Da KVM einfach ein Kernel-Modul des Linux-Kernels ist, gehen wir davon aus, dass KVM ebenfalls voll unterstützt wird. Alles in allem ist LifeKeeper in der Regel eines der Tools, das wir darauf überprüfen, ob es zu einer bestimmten Kundenumgebung passt. Veritas Cluster Genau wie der zuvor angesprochene LifeKeeper ist Veritas Cluster ein Veteran in HA- und SAP-HA-Umgebungen und bereits seit Mitte der 1990er erhältlich. Das Produkt unterstützt verschiedene UNIX-Systeme sowie Linux und Windows und verfügt über einen klaren Upgrade-Pfad. Veritas Cluster bietet Anwendungs-Agenten für viele gängige Unternehmenslösungen, einschließlich SAP, und Datenbanken. Die Support-Matrix ist klar definiert. Veritas Cluster verursacht zusätzliche Lizenzkosten (und kann in dieser Hinsicht getrost als der Rolls-Royce unter den Cluster-Tools für Linux bezeichnet werden) und erhöht mit Symantec die Anzahl der Anbieter, die in der Architektur vertreten sind. Veritas Cluster bietet uneingeschränkte Unterstützung für VMware und stellt zusätzliche Integrationen für Speichersubsysteme zur Verfügung. Es ist anzunehmen, dass neue Hardware und Software-Versionen schneller integriert werden können, da Cluster-Technologie eine Kernkompetenz von Veritas/Symantec ist. Es ist ein ausgereiftes und unglaublich umfangreiches Tool und ist geeignet, bei richtiger Konfiguration und Implementierung eine technische Lösung für 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

62 Ihr technisches Anwendungsszenario zu bieten aber wie bereits gesagt, sollten Sie nicht davon ausgehen, dass HA eine Frage der Tools ist. Die Erfahrungen einiger unserer Kunden mit dem Symantec-Support für Veritas Cluster waren jedoch insbesondere bei Linux sehr unterschiedlich und nicht unbedingt immer nur gut, sowohl mit Blick auf die Antwortzeiten als auch auf die Qualität der Support-Antworten. Einige unserer großen Linux-Migrationskunden habe sich aufgrund dieser gemischten Erfahrungen mittlerweile von Veritas Cluster abgewendet oder stehen kurz davor. HP MC ServiceGuard HP MC ServiceGuard ist ebenfalls ein alter Bekannter auf dem HA-Tool-Markt, die ersten Versionen waren schon 1995 mit HP-UX erhältlich. Das Produkt unterstützt HP-UX und Linux und bietet einen klaren technischen Upgrade-Pfad. Es wurde intensiv auf HP-Hardware getestet und es ist anzunehmen, dass Support für neue Hardware (vor allem HP) und Software-Versionen vergleichsweise schnell zur Verfügung gestellt wird. Integrationen für HP-Speichersubsysteme sind ebenfalls erhältlich (i.e. EVA Cluster Extension für HP EVA Continuous Access). Auf Linux unterstützt HP MC ServiceGuard virtualisierte Gäste mit VMware ESX sowie Red Hat- und SUSE Xen-Hosts (DOM0). ServiceGuard und Anwendungsintegrationen werden von nur einem Anbieter unterhalten und es gibt schlüsselfertige Integrationen mit wichtigen Unternehmensprodukten einschließlich SAP und Oracle. Die Support-Matrix ist klar definiert, aber HP MC ServiceGuard verursacht zusätzliche Lizenzkosten und erhöht die Anzahl der Anbieter, die in der Architektur vertreten sind. In der Vergangenheit haben Kunden schlechte Erfahrungen mit HPs Engagement für dieses Produkt gemacht, da der Linux-Support 2010 zunächst abgekündigt und dann in 2011 wieder aufgenommen wurde. Da Kontinuität in kritischen Installationen von sehr großer Bedeutung ist, sollten Sie HPs Unbeständigkeit als erheblichen Nachteil für dieses Produkt ansehen. Niemand außerhalb der HP-Führungsetage kann oder wird Ihnen garantieren, dass es keine erneute Kehrtwende geben wird. Darum zögert REALTECH, dieses Produkt auch nur als eine weitere Option zu empfehlen. IBM PowerHA / HACMP IBM PowerHA (oder HACMP) ist auch schon lange mit dabei. Derzeit wird Linux jedoch nur auf System i und System p jedoch nicht auf System x unterstützt. Da mit dieser Unternehmenspolitik 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

63 x64, die wichtigste Prozessorplattform für SAP auf Linux, vollkommen ignoriert wird, empfehlen wir, HACMP für SAP-Umgebungen auf Linux nicht in Betracht zu ziehen. Denn selbst wenn Sie heute noch SAP auf Linux mit Power-CPUs betreiben, könnten Sie sich eines Tages vielleicht für einen Umstieg entscheiden. Nach heutigem Stand wären Sie dann aber vermutlich gezwungen, ein neues HA-Tool zu finden und zu implementieren und so gewonnenes Wissen opfern zu müssen. Andere Formen und ein neues Verständnis von HA und Kritikalität Ebenso wie Hochverfügbarkeit auf der organisatorischen Ebene mehr ist, als nur eine Frage der richtigen Tools, so ist sie auf der technischen Ebene mehr als klassische 1:1 Clustering- Technologien. SAP hat einige Änderungen an der grundlegende Architektur seines Software- Stacks vorgenommen, die eine Trennung der Schichten und eine Unterscheidung zwischen kritischen und nicht-kritischen Services möglich macht. Das heißt, dass Sie jetzt unterschiedliche Technologien auf unterschiedlichen Schichten einsetzen können, um Hochverfügbarkeit zu gewährleisten oder zu etablieren, was N+1 (anstelle von 1:1) Clustering und Round-Robin- Wartungsverfahren erleichtert und es Ihnen damit wiederum ermöglicht, nicht nur unvorhergesehene Downtime sondern auch geplante Downtime zu reduzieren. Im nächsten Kapitel finden Sie ein Beispiel, wie wir uns diese Architekturmöglichkeiten zu Nutze gemacht haben REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

64 Über alle Grenzen hinaus. Minima unterschreiten Ein großer Kunde aus dem Gesundheitssektor bat uns, seine SAP-Plattform-Strategie für die nächsten fünf Jahre und darüber hinaus zu überprüfen und ihn so bei der Suche nach einer zukunftssicheren Plattform mit den gleichen natürlich gerne auch besseren Leistungs- und Verfügbarkeitswerten wie seine aktuelle Plattform (IBM-Power-Server mit AIX- und Oracle- Datenbanken) zu unterstützen. Mit ungefähr 100 SAP-Systemen, mehreren SAPS und ca. 90 TB an Datenbanken ist die Umgebung ein wichtiger und kritischer Teil der Gesamtinfrastruktur des Kunden. Die neue Umgebung musste Anforderungen hinsichtlich Validierung/Qualifizierung und FDA- und GMP-Compliance erfüllen sowie Hochverfügbarkeit und Disaster Recovery gewährleisten. Zudem sollte es zukünftige SAP-Versionen und -Trends wie In-Memory-Computing unterstützen und den Weg in die Cloud ermöglichen. Wie in allen REALTECH-Architekturuntersuchungen wurden mögliche Plattformalternativen zunächst mit dem Status Quo beim Kunden verglichen. Für die zukünftige Plattform war der erste Schritt ein Resizing der Umgebung für die neuesten IBM-Power-Server mit AIX- und Oracle- Datenbanken. Danach entwickelten wir verschiedene Alternativen, einschließlich Optionen mit IMB Power Blades und x64-blade-servern basiert auf AMD- oder Intel-Prozessoren. Der Umstieg von seiner Oracle-Datenbank auf ein anderes Produkt war für unseren Kunden keine Option, da dieser eine große Nicht-SAP-Umgebung auf Oracle betreibt und eine Änderung des Standards mit immens hohen Kosten verbunden gewesen wäre, wenn es in einer qualifizierten und validierten Umgebung überhaupt möglich gewesen wäre. Um uns einen vollständigen Überblick über die finanziellen Auswirkungen zu machen, analysierten wir die Hardware-Kosten, Software-Lizenzen sowie Übergangs- und Schulungskosten und veranschlagten die zukünftigen Kosten und möglichen Einsparungen im Betrieb. Da die Lizenzierung beim Kunden auf Grundlage eines pro-kern-modells erfolgt, musste die Anzahl der Kerne für die Datenbanken möglichst gering gehalten werden, um die 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

65 Datenbankkosten nicht in die Höhe zu treiben. Das SAP-Schichtenmodell, das seit der Einführung von NetWeaver verfügbar ist, bietet die notwendige Flexibilität, um den Gesamt-Stack in mehrere Schichten aufzuteilen und so die Datenbank auf einer kleinen Anzahl von Servern zu isolieren. Die nächste Graphik zeigt unsere allgemeine Herangehensweise. Alle Alternativen einschließlich der aktuellen Plattform mit den neuesten Server-Modellen wurden mit Blick auf Kriterien wie technische Details, Risiken und vielem mehr untereinander verglichen. Abschließend wurden alle Optionen unter finanziellen Gesichtspunkten verglichen. Das aktuelle Setup, eine klassische CI/DB-Konfiguration, die wo benötigt um Anwendungs-Server ergänzt wurde, wurde zuerst berechnet, um eine Baseline zu erhalten, die unten als 100% dargestellt wird. Es entstehen natürlich keine Übergangskosten, wenn man einfach das bestehende Setup beibehält und es von Power6 auf Power7 übertragt. Selbst wenn man die technischen Vorteile außer Acht lässt, macht sich unser Ansatz mit einer mehrschichtigen Architektur unter wirtschaftlichen Aspekten sofort bezahlt, auch wenn es keine Änderungen in der Prozessorarchitektur gibt. Der Verzicht auf den Wechsel des Betriebssystems hat den eindeutigen Vorteil, dass keine erwähnenswerten Übergangskosten entstehen, da keine Notwendigkeit für eine heterogene Migration besteht. Beachten Sie aber bitte, dass Oracle unverhältnismäßig davon profitiert hätte. Aufgrund der Kern-basierten Lizenzierung und der unterschiedlichen Verrechnungsfaktoren pro Power-Kern und x64-kern hätte diese Option zwar Gesamteinsparungen von knapp über 20% möglich gemacht, die Umsätze aber von IBM zu Oracle verlagert REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

66 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

67 REALTECH war überzeugt, dass es hierzu eine bessere Alternative geben musste und dass es möglich sein sollte, eine mehrschichtige Architektur zu entwerfen, die die Grenzen der Verfügbarkeit nach oben verschieben und die Betriebskosten gleichzeitig um mehr als 20% senken würde. Unsere Kostenvergleiche aller Alternativen zeigten dann, dass ein Umstieg auf x64 mit Linux und Oracle RAC in einem mehrschichtigen Setup erhebliche jährliche Einsparungen ermöglichen würde, dies aber selbstverständlich mit einer großen Anfangsinvestition für das Übergansprojekt verbunden war. Die jährlichen Kosten machen ungefähr 54% des Baseline aus, und die Übergangskosten liegen bei circa 127% der jährlichen Kosten der aktuellen Architektur. Durch maximale Automatisierung der Bereitstellung und des täglichen Betriebs und durch die strikte Verwendung von Standards für Komponenten und Konfigurationen können die Betriebskosten trotz einer leicht höheren Anzahl von Komponenten in der neuen Architektur begrenzt werden. Die neue Architektur basiert ausschließlich auf einem mehrschichtigen Modell unter Einsatz von virtuellen Maschinen für die Anwendungsschicht. Jedes SAP-System nutzt mindestens zwei Anwendungs-Server, einen in jedem Rechenzentrum. In diesem Setup teilen sich die SAP 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

68 Central Services einen 2-Knoten-Cluster auf Basis von zwei virtuellen Maschinen mit SLES HA Extension. In der Datenbankschicht profitiert der Kunde von seiner langjährigen Erfahrung mit Oracle RAC in seiner Nicht-SAP-Umgebung. Im Vergleich zu vielen 2-Knoten-Clustern für die Datenbanken wird durch den Einsatz von Oracle RAC die Anzahl der Server für die Datenbankschicht erheblich verringert, was gleichzeitig die Anzahl der Datenbanklizenzen minimiert, auch wenn RAC-Lizenzen teurer als Standard-Lizenzen sind. Neben den rein finanziellen Aspekten hat sich der Kunde für einen Umstieg auf x64 mit SLES for SAP Applications entschieden, weil diese Kombination sämtliche Anforderungen an Leistung und Verfügbarkeit erfüllt und ihm gleichzeitig eine Roadmap für kostengünstiges In-Memory- Computing und den Umzug in ein privates Cloud-Computing-Modell ermöglicht. Zudem können so die Beschaffungs- und Provisioning-Prozesse optimiert werden. Nach Abschluss des Projekts wird der Kunde ausschließlich x64-server sowie Linux und Windows als die einzigen Betriebssysteme betreiben, zumindest in seinen SAP-Rechenzentren. Die neue Architektur wird derzeit in einem stufenweisen Ansatz implementiert und die Pilotumgebung für die Entwicklungssysteme wird in etwa zur gleichen Zeit wie dieses Whitepaper fertiggestellt werden REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

69 Maxima überwinden Die nächste und letzte Betrachtung zeigt nicht mehr und nicht weniger, als dass es mit einem Umstieg auf x64 möglich ist, die verfügbare Leistung in Ihrem SAP-Rechenzentrum bei gleichzeitig erheblich niedrigeren Kosten zu vervielfachen. Dies hängt natürlich von Ihrem Ausgangssystem ab, aber der Kunde in diesem Beispiel hatte zuvor eine Itanium-basierte High-End-HP-UX-Infrastruktur in Betrieb, die maximales Einsparpotenzial lieferte. Ob Sie es glauben oder nicht, diese Zahlen wurden uns vom Kunden zur Verfügung gestellt, alle Prozentangaben wurden mit Budgets aus der Praxis errechnet. Unser erstes Diagramm zeigt den Anstieg in SAPS-Leistung über den Zeitraum, in dem der Kunde seine Itanium-basierte Infrastruktur durch eine Intel-basierte mit Linux anstelle von UNIX ersetzte. Es dürfte niemanden überraschen, dass dies zu einer erheblichen Zunahme in verfügbarer Rechenleistung führte REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

70 Die Überraschung kommt viel mehr in der darauf folgenden Abbildung, welche die Kosten für die Server-Infrastruktur über weitestgehend den gleichen Zeitraum zeigen. Allein durch die Umstellung auf Linux und x64 konnte dieser Kunde die Kosten für seine SAP-Server um mehr als 80% senken und dabei gleichzeitig die verfügbare SAP-Rechenleistung mindestens verdreifachen. Und um den Skeptikern gleich zuvorzukommen, weder haben sich die Stabilität oder die tatsächliche Leistung in der Folge verschlechtert, noch wurden höhere Administrationsaufwände nötig. Einfach ausgedrückt: Wenn Sie die Leistungsfähigkeit in Ihrem SAP-Rechenzentrum steigern wollen, sind Linux und x64 die richtige Lösung für Sie. Der Kunde in unserem ersten Beispiel entschied sich für SUSE, dieser für Red Hat. Wie schon vorher festgehalten, werden die wirksamsten Kosteneffekte über die CPU-Architektur erzielt. Wenn Ihr Ausgangssystem UNIX heißt, lassen sich mit jeder dieser beiden Linux-Distributionen erhebliche Einsparungen erzielen. Nur um dies noch einmal deutlich zu machen: Diese beiden Diagramme wurden uns von unserem Migrationskunden zur Verfügung gestellt und sie zeigen die Leistung im SAP-Rechenzentrum und die Kostenentwicklung anhand von echten Budgets, so wie vom Kunden selbst berichtet. REALTECH hat sogar die tatsächlichen Zahlen gesehen, nicht nur die Prozentangaben. Dies ist keine Simulation und kein Marketing-Versprechen. Dies ist das echte Leben! 2012 REALTECH Consulting Helmut Spöcker Oktober 2012 Seite

SAP-Lösungen auf Linux migrieren? In drei Schritten zum Erfolg

SAP-Lösungen auf Linux migrieren? In drei Schritten zum Erfolg SAP-Lösungen auf Linux migrieren? In drei Schritten zum Erfolg Inhaltsverzeichnis 1. Informieren Sie sich über Ihre Linux-Optionen........................ 2 2. Erarbeiten Sie einen Business Case für die

Mehr

IT-Technologieberatung

IT-Technologieberatung IT-Technologieberatung Moderne IT-Architekturen, -Plattformen und -Technologien: Bessere Performance. Mehr Flexibilität. Niedrigere Kosten. Innovative Lösungen. Absolut zukunftssicher. Cloud-fähig! MehrWert

Mehr

Virtual System Cluster: Freie Wahl mit Open Source

Virtual System Cluster: Freie Wahl mit Open Source Virtual System Cluster: Freie Wahl mit Open Source LPI Partnertagung 2012 Sprecher: Uwe Grawert http://www.b1-systems.de 24. April 2012 c B1 Systems GmbH 2004 2012 Chapter -1, Slide 1 Freie Wahl beim Virtual

Mehr

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Fragebogen. SAP - Outsourcing

Fragebogen. SAP - Outsourcing Fragebogen SAP - Outsourcing ifilios GmbH Business Technology Consulting Maximilianstraße 13 D-80539 München Sitz der Gesellschaft: München Registergericht München HRB 202785, USt.-IdNr. DE286548485 Geschäftsführer:

Mehr

Von UNIX zu Linux in SAP Rechenzentren: Eine Trendbetrachtung Update und Betrachtung der Architektureffekte

Von UNIX zu Linux in SAP Rechenzentren: Eine Trendbetrachtung Update und Betrachtung der Architektureffekte Von UNIX zu Linux in SAP Rechenzentren: Eine Trendbetrachtung Update und Betrachtung der Architektureffekte Helmut Spöcker Consulting Manager REALTECH Consulting August 2009 Inhaltsverzeichnis Management-Zusammenfassung

Mehr

Zielsetzung. Fachlicher Schwerpunkt. Besondere Qualifikation. Fortbildung

Zielsetzung. Fachlicher Schwerpunkt. Besondere Qualifikation. Fortbildung Zielsetzung Freiberufliche Mitarbeit in Projekten (Teilzeitprojekte) Verfügbar ab: sofort Fachlicher Schwerpunkt Oracle Datenbanken Oracle Real Application Cluster (RAC) Veritas Cluster Server (VCS) SAP

Mehr

GIA Informatik AG Peyermattstrasse 3 CH-4665 Oftringen Telefon +41 62 789 71 71 Telefax +41 62 789 71 99 info@gia.ch www.gia.ch

GIA Informatik AG Peyermattstrasse 3 CH-4665 Oftringen Telefon +41 62 789 71 71 Telefax +41 62 789 71 99 info@gia.ch www.gia.ch GIA Informatik AG Peyermattstrasse 3 CH-4665 Oftringen Telefon +41 62 789 71 71 Telefax +41 62 789 71 99 info@gia.ch www.gia.ch Agenda 1 GIA Informatik AG 2 SAP MaxDB im Kundeneinsatz 3 Management von

Mehr

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Peter Stalder DOAG November 2009 Basel Baden Bern Lausanne Zurich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg Munich Stuttgart Vienna

Mehr

Das virtuelle Rechenzentrum

Das virtuelle Rechenzentrum Das virtuelle Rechenzentrum Erfahrungen, Meinungen, Visionen CON.ect Informunity Infrastrukturmanagement, Virtualisierung & Green IT Wien, 26.3.2009 Georg Chytil, Ing. Andreas Schoder georg.chytil@nextlayer.at,

Mehr

Profil & Projektübersicht. Markus Fugger. SAP Basis & Technologieberater. Breitscheidstaße 88 70176 Stuttgart. mail@markusfugger.

Profil & Projektübersicht. Markus Fugger. SAP Basis & Technologieberater. Breitscheidstaße 88 70176 Stuttgart. mail@markusfugger. Profil & Projektübersicht Markus Fugger SAP Basis & Technologieberater Breitscheidstaße 88 70176 Stuttgart mail@markusfugger.com 0175 2330086 http://www.markusfugger.com Ausbildung Zertifizierter SAP Basis

Mehr

IBM DB2 für Ihre SAP-Landschaft

IBM DB2 für Ihre SAP-Landschaft IBM DB2 für Ihre SAP-Landschaft Die Lösungen der PROFI AG Senken auch Sie Ihre SAP-Betriebskosten um bis zu 30 Prozent Kosten senken Ihre Herausforderungen Durch wachsende Datenmengen in den SAP-Systemen

Mehr

ORACLE & HP Auf dem Weg nach vorne

ORACLE & HP Auf dem Weg nach vorne ORACLE & HP Auf dem Weg nach vorne Michael Peuker ORACLE Deutschland HP Alliance Manager Germany Jörg Demmler Hewlett-Packard GmbH Technolgie Consultant & DECUS DBI Repr. Agenda Rückblick ORACLE / Premerger

Mehr

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network.

56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen. Client Client Client Client Client. Public Network. aktiv. Private Network. 56 Maßnahmen zur Sicherung der Verfügbarkeit in Oracle-Umgebungen aktiv inaktiv Node 1 ( Aktiv ) Node 2 ( Passiv ) Private Network aktiv inaktiv (exklusiver Zugriff) Abbildung 3.1: Schematische Darstellung

Mehr

Wir freuen uns auf Ihr Kommen. AddOn (Schweiz) AG

Wir freuen uns auf Ihr Kommen. AddOn (Schweiz) AG E x e c u t i v e I n f o r m a t i o n «E i n W e g d e r s i c h l o h n t S A P R e - P l a t f o r m i n g m i t M i c ro s o f t» E i n W e g d e r s i c h l o h n t S A P R e - P l a t f o r m i

Mehr

best Systeme GmbH Michael Beeck Geschäftsführer, CTO Michael.Beeck@best.de best Systeme GmbH

best Systeme GmbH Michael Beeck Geschäftsführer, CTO Michael.Beeck@best.de best Systeme GmbH best Systeme GmbH Michael Beeck Geschäftsführer, CTO Michael.Beeck@best.de best Systeme GmbH Münchner Str. 123a 85774 Unterföhring Tel: 089/950 60 80 Fax: 089/950 60 70 Web: www.best.de best Systeme GmbH

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Klein Computer System AG. Portrait

Klein Computer System AG. Portrait Klein Computer System AG Portrait Die Klein Computer System AG wurde 1986 durch Wolfgang Klein mit Sitz in Dübendorf gegründet. Die Geschäftstätigkeiten haben sich über die Jahre stark verändert und wurden

Mehr

Virtuelle Infrastrukturen mit Linux...

Virtuelle Infrastrukturen mit Linux... Virtuelle Infrastrukturen mit Linux...... und deren Integration in OSL SC Christian Schmidt Systemingenieur Virtualisierung "Aufteilung oder Zusammenfassung von Ressourcen" Unterschiedliche Bereiche für

Mehr

ERP 2020: Zurück in die Zukunft?! - Treiber, Handlungsfelder und Lösungen für zukunftsfähige ERP-Lösungen

ERP 2020: Zurück in die Zukunft?! - Treiber, Handlungsfelder und Lösungen für zukunftsfähige ERP-Lösungen ERP 2020: Zurück in die Zukunft?! - Treiber, Handlungsfelder und Lösungen für zukunftsfähige ERP-Lösungen Name: Markus Beck Funktion/Bereich: Geschäftsführer Organisation: Deliance GmbH Liebe Leserinnen

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

4 Jahre Progymnasium, 4147 Aesch (1991-1995) 4-jährige Berufslehre zum Informatiker (1995-1999) bei ITRIS Maintenance AG, 4153 Reinach

4 Jahre Progymnasium, 4147 Aesch (1991-1995) 4-jährige Berufslehre zum Informatiker (1995-1999) bei ITRIS Maintenance AG, 4153 Reinach Michael Arlati Neubüntenweg 11 4147 Aesch mobile: +41 (0)79 272 75 92 email: mik@arlati.ch web: www.arlati.ch Jahrgang Nationalität Beruf/ Titel Ausbildung 08.05.1979 CH Informatiker 4 Jahre Progymnasium,

Mehr

Erfolgreiche Einführung von dnfs bei SALK Salzburger Landeskliniken

Erfolgreiche Einführung von dnfs bei SALK Salzburger Landeskliniken Erfolgreiche Einführung von dnfs bei SALK Salzburger Landeskliniken Ernst Berger und Christian Pfundtner Ing. Ernst Berger Ing. Ernst Berger, RHCE, ITIL Foundation Certified Verheiratet, einen Sohn, wohnhaft

Mehr

InfoSphere Change Data Capture/Change Data Delivery

InfoSphere Change Data Capture/Change Data Delivery InfoSphere Change Data Capture/Change Data Delivery Aktuellste Daten für Ihr Datawarehouse 1 Information Management ist eine Wertschöpfungskette für die RICHTIGE Information zu jeder Zeit, am richtigen

Mehr

Profil & Projektübersicht. Markus Fugger. SAP Basis & Technologieberater. Breitscheidstaße 88 70176 Stuttgart. mail@markusfugger.

Profil & Projektübersicht. Markus Fugger. SAP Basis & Technologieberater. Breitscheidstaße 88 70176 Stuttgart. mail@markusfugger. Profil & Projektübersicht Markus Fugger SAP Basis & Technologieberater Breitscheidstaße 88 70176 Stuttgart mail@markusfugger.com 0175 2330086 http://www.markusfugger.com Ausbildung Zertifizierter SAP Basis

Mehr

ALLGEMEINE FRAGEN ZU DR. TAX OFFICE 3.0... 3

ALLGEMEINE FRAGEN ZU DR. TAX OFFICE 3.0... 3 INHALT ALLGEMEINE FRAGEN ZU DR. TAX OFFICE 3.0... 3 1. Wofür steht Dr. Tax 2.0 bzw. Dr. Tax?... 3 2. Warum wird Dr. Tax 3.0 eingeführt?... 3 3. Was sind die Unterschiede zwischen Dr. Tax 2.0 und 3.0?...

Mehr

API Überlegungen bei der Auswahl des CRM-Anbieters

API Überlegungen bei der Auswahl des CRM-Anbieters WHITE PAPER API Überlegungen bei der Auswahl des CRM-Anbieters Eine vergleichende Analyse über die Integration von CRM Lösungen EINFÜHRUNG Eine CRM-Lösung vereint in einer Organisation die Bereiche Vertrieb,

Mehr

IT-Symposium 2008 04.06.2008. HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime 6/9/2008 1

IT-Symposium 2008 04.06.2008. HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime 6/9/2008 1 HOB RD VPN HOB Remote Desktop VPN Your Desktop-Anywhere-Anytime Joachim Gietl Vertriebsleiter Central Europe 6/9/2008 1 HOB RD VPN Eine branchenunabhängige Lösung für alle Unternehmen die Ihren Außendienst

Mehr

Virtualisierung von Microsoft verringert IT-Kosten und ermöglicht die schnelle Reaktion auf Unternehmensanforderungen

Virtualisierung von Microsoft verringert IT-Kosten und ermöglicht die schnelle Reaktion auf Unternehmensanforderungen Case Study: Erfolgreiche Virtualisierung durch Microsoft am Universitätsklinikum Aachen Virtualisierung von Microsoft verringert IT-Kosten und ermöglicht die schnelle Reaktion auf Unternehmensanforderungen

Mehr

Zuerst zu Open Source wechseln

Zuerst zu Open Source wechseln Zuerst zu Open Source wechseln Zuerst zu Open Source wechseln Inhaltsverzeichnis Zuerst zu Open Source wechseln... 3 In die Mitte.... 4 Veränderungen in der Wirtschaftlichkeit der IT.... 6 2 Zuerst zu

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

PROJEKTÜBERSICHT MITARBEITER DIRK BOLINSKI. 08 / 06 jetzt ZEITRAUM. Energieversorger KUNDE

PROJEKTÜBERSICHT MITARBEITER DIRK BOLINSKI. 08 / 06 jetzt ZEITRAUM. Energieversorger KUNDE ÜBERSICHT MITARBEITER DIRK BOLINSKI ZEITRAUM 08 / 06 jetzt Energieversorger Upgrade Solution Manager 3.2 --> 4.0 Upgrade Oracle 10g --> Oracle 11g Upgrade Oracle 9i --> 10g Konzepterstellung zur Anbindung

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

Standardsoftware. SAP Basisarchitektur. Prof. Dr. Bernhard Schiefer 2-1

Standardsoftware. SAP Basisarchitektur. Prof. Dr. Bernhard Schiefer 2-1 Standardsoftware SAP Basisarchitektur Prof. Dr. Bernhard Schiefer 2-1 SAP Client/Server Dreistufige Rechnerhierarchie Lesen in der DB und Aktualisierung der Puffer Datenbankänderung Zentrale DB (speichert

Mehr

Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA

Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA Das Zusammenspiel von mysap ERP, SAP NetWeaver und der ESOA Erschienen in der E3 04/2007 Von Dr. Carl Winter, REALTECH AG Wer im Umfeld von SAP Systemlandschaften über mysap ERP 2005 spricht, landet schnell

Mehr

1. Umfrage zum Einsatz von Open Source Software in österreichischen Unternehmen

1. Umfrage zum Einsatz von Open Source Software in österreichischen Unternehmen 1. Umfrage m Einsatz von Open Source Software in österreichischen Unternehmen Dieser Fragebogen dient der Erhebung über den Einsatz von Open Source Software (OSS) in österreichischen Unternehmen und wird

Mehr

IT-Monitoring braucht Sicherheit Sicherheit braucht Monitoring. Günther Klix op5 GmbH - Area Manager D/A/CH

IT-Monitoring braucht Sicherheit Sicherheit braucht Monitoring. Günther Klix op5 GmbH - Area Manager D/A/CH IT-Monitoring braucht Sicherheit Sicherheit braucht Monitoring Günther Klix op5 GmbH - Area Manager D/A/CH Technische Anforderungen an IT Immer komplexere & verteiltere Umgebungen zunehmend heterogene

Mehr

SAP HANA -Umgebungen. Prof. Dr. Detlev Steinbinder, PBS Software GmbH, 2013

SAP HANA -Umgebungen. Prof. Dr. Detlev Steinbinder, PBS Software GmbH, 2013 Information Lifecycle Management in SAP HANA -Umgebungen Prof. Dr. Detlev Steinbinder, PBS Software GmbH, 2013 Agenda Einführung Business Case Information Lifecycle Management (ILM) ILM und Migration nach

Mehr

SAS Analytics bringt SAP HANA in den Fachbereich

SAS Analytics bringt SAP HANA in den Fachbereich Pressemitteilung Hamburg, 08. November 2013 SAS Analytics bringt SAP HANA in den Fachbereich Ergonomie kombiniert mit Leistungsfähigkeit: die BI-Experten der accantec group geben der neuen Partnerschaft

Mehr

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de

Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Virtualisierung am Beispiel des LRZ Stefan Berner berner@lrz.de Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften Agenda Einleitung Vor- und Nachteile der Virtualisierung Virtualisierungssoftware

Mehr

Berufliches Profil. Alexander Oswald. Senior Consultant. SAP Basis and SAP System Optimization. Stärken

Berufliches Profil. Alexander Oswald. Senior Consultant. SAP Basis and SAP System Optimization. Stärken Berufliches Profil Senior Consultant SAP Basis and SAP System Optimization Stärken Große Erfahrung in Internationalen Projekten Hervorragende Kommunikation zu Kunden und Projektteam Gute Analytische und

Mehr

DB2 Express: IBM Data Management Angebot für kleine und mittelständische Unternehmen

DB2 Express: IBM Data Management Angebot für kleine und mittelständische Unternehmen IBM Software Group DB2 Express: IBM Data Management Angebot für kleine und mittelständische Unternehmen IBM Data Management CEBIT 2003 IBM ist der führende Datenbankanbieter Kundenakzeptanz fördert Wachstum

Mehr

Mitarbeiterprofil Stand: 27.06.2014 Frank Hellweg Jahrgang: 1967 Abschluss:

Mitarbeiterprofil Stand: 27.06.2014 Frank Hellweg Jahrgang: 1967 Abschluss: Mitarbeiterprofil Stand: 27.06.2014 Name: Frank Hellweg Jahrgang: 1967 Abschluss: Versicherungskaufmann (IHK) SAP Certified Technical Consultant SAP Certified OS/DB Migration (S0002825171) Einsatzgebiete:

Mehr

Bertelsmann Club. SAP Hosting

Bertelsmann Club. SAP Hosting Bertelsmann Club SAP Hosting Der Kunde Der Club Bertelsmann wurde 1950 von Reinhard Mohn gegründet. Der Club bietet einen einzigartigen Zugang zur faszinierenden Welt der Bücher und Medien für die ganze

Mehr

The German Market for Linux & Open Source 2005 2007

The German Market for Linux & Open Source 2005 2007 Informationen zur Marktstudie Linux/ Open Source 2005 Linux/Open Source Research von TechConsult Als neutrales Marktforschungsunternehmen beobachtet TechConsult seit nun mehr als fünf Jahren die Entwicklung

Mehr

Oracle EngineeredSystems

Oracle EngineeredSystems Oracle EngineeredSystems Überblick was es alles gibt Themenübersicht Überblick über die Engineered Systems von Oracle Was gibt es und was ist der Einsatzzweck? Wann machen diese Systeme Sinn? Limitationen

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

Android, ios und Windows Phone dominieren zurzeit den Markt für mobile Firmware, wesentlich kleiner ist der Marktanteil von Blackberry OS10.

Android, ios und Windows Phone dominieren zurzeit den Markt für mobile Firmware, wesentlich kleiner ist der Marktanteil von Blackberry OS10. Zahlen und Fakten. Firmware Mit Firmware wird bei mobilen Endgeräten der Anteil des Betriebssystems bezeichnet, der auf die Hardware in dem Gerät angepasst ist und mit dem Gerät durch Laden in einen Flash-Speicher

Mehr

Besondere Stärken: ganzheitliches Management des mobilen Arbeitsplatzes und Services für gehobenen Mittelstand

Besondere Stärken: ganzheitliches Management des mobilen Arbeitsplatzes und Services für gehobenen Mittelstand Experton Mobile Enterprise Vendor Benchmark 2015: Computacenter weiterhin führend im Mobile-Enterprise-Markt Besondere Stärken: ganzheitliches Management des mobilen Arbeitsplatzes und Services für gehobenen

Mehr

SAP R/3 und Linux. Zwei Welten treffen aufeinander. Jochen Hein

SAP R/3 und Linux. Zwei Welten treffen aufeinander. Jochen Hein Zwei Welten treffen aufeinander Jochen Hein Jochen arbeitet mit SAP R/2 seit 1987, mit Linux seit 1992 und mit SAP R/3 seit 1995. Sein Hobby an der Arbeit als SAP Basisbetreuer ist

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Experton Mobile Enterprise Vendor Benchmark 2013: Computacenter ist führender Dienstleister im Bereich Mobile

Experton Mobile Enterprise Vendor Benchmark 2013: Computacenter ist führender Dienstleister im Bereich Mobile Experton Mobile Enterprise Vendor Benchmark 2013: Computacenter ist führender Dienstleister im Bereich Mobile Bestnoten bei Mobile Consulting, Mobile Device Management Services und Managed Workplace Services

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

Mehr

Migration nach MAXDB bei GESIS

Migration nach MAXDB bei GESIS GESIS Ehrfahrungsbericht MAXDB; Seite 1 Migration nach MAXDB bei GESIS Salzgitter, den 13.06.2006 Vorstellung der GESIS Über die Gesis 100% Tochter der Salzgitter AG Hauptsitz in Salzgitter, Büros in Mülheim

Mehr

Steunenberg. Compiere Fragen & Antworten. Testen Sie jetzt die Flashdemo "Die Compiere UI kennenlernen" Ich freue mich über Rückmeldungen

Steunenberg. Compiere Fragen & Antworten. Testen Sie jetzt die Flashdemo Die Compiere UI kennenlernen Ich freue mich über Rückmeldungen Steunenberg Ich freue mich über Rückmeldungen Testen Sie jetzt die Flashdemo "Die Compiere UI kennenlernen" Compiere Fragen & Antworten Diese Seite enthält nur einige viel gestellte Fragen zum Thema Compiere

Mehr

Executive Briefing. Big Data und Business Analytics für Kunden und Unternehmen. In Zusammenarbeit mit. Executive Briefing. In Zusammenarbeit mit

Executive Briefing. Big Data und Business Analytics für Kunden und Unternehmen. In Zusammenarbeit mit. Executive Briefing. In Zusammenarbeit mit Big Data und Business Analytics für Kunden und Unternehmen Umfangreiche und ständig anwachsende Datenvolumen verändern die Art und Weise, wie in zahlreichen Branchen Geschäfte abgewickelt werden. Da immer

Mehr

PROFI Managed Services

PROFI Managed Services PROFI Managed Services Die Lösungen der PROFI AG You do not need to manage IT to use IT Die PROFI Managed Services sind exakt auf die Bedürfnisse von komplexen IT-Umgebungen abgestimmt und unterstützen

Mehr

Xen Enterprise Virtualisierung

Xen Enterprise Virtualisierung , Möglichkeiten, Ausblicke Silpion IT Solutions GmbH/ LSP 2008-04-09 / LISOG Virtualisierungs-Pitch Über den Redner Vorschau Über den Redner - Mit-Autor von Xen - Virtualisierung unter Linux Berater, Free

Mehr

Systemvoraussetzungen Varial GUIDE/BROWSER

Systemvoraussetzungen Varial GUIDE/BROWSER Systemvoraussetzungen Varial GUIDE/BROWSER Finanzbuchführung Anlagenbuchhaltung Kostenrechnung Personalwirtschaft 1 IMPRESSUM Varial Systemvoraussetzungen Varial GUIDE/BROWSER November 2007 by Varial Software

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum)

Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum) Hochverfügbare Server-Hardware: Eine Fallstudie (Logistik-Zentrum) Anforderungen aus heutiger Sicht Wesentliche Merkmale der Anwendung Leistungsbestimmende Komponenten Zuverlässigkeitsbestimmende Komponenten

Mehr

Freiberuflicher IT-Berater Schwerpunkte: Unix, Oracle, Netzwerk. www.jj-it.de. www.jj-it.de. Dipl.-Inform. Joachim Jäckel

Freiberuflicher IT-Berater Schwerpunkte: Unix, Oracle, Netzwerk. www.jj-it.de. www.jj-it.de. Dipl.-Inform. Joachim Jäckel Freiberuflicher Schwerpunkte: Unix, Oracle, Netzwerk 2005 1 Testaufbauten von Oracle 10g RAC auf preiswerter Hardware 2 3 Typisches Cluster System Clients Public Network Node A Node B Cluster Interconnect

Mehr

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

CNT Management Consulting. Unsere Beratungskompetenz für Ihren Erfolg

CNT Management Consulting. Unsere Beratungskompetenz für Ihren Erfolg CNT Management Consulting Unsere Beratungskompetenz für Ihren Erfolg Technology and Integration Consulting Exposé 14. Mai 2014 CNT Management Consulting GmbH Our Competences For Your Success 2 Unser Beitrag

Mehr

HP User Society. Wir bewirken mehr. DECUS München e.v.

HP User Society. Wir bewirken mehr. DECUS München e.v. DECUS München e.v. Reden Sie mit. 2004 Hewlett-Packard Development Company, L.P. + 2005 DECUS München e.v. The information contained herein is subject to change without notice Wir bewirken mehr. Größte

Mehr

Berater-Profil 2579. DB- und Systemadministrator (AIX, Linux, Oracle, Tivoli, Win NT)

Berater-Profil 2579. DB- und Systemadministrator (AIX, Linux, Oracle, Tivoli, Win NT) Berater-Profil 2579 DB- und Systemadministrator (AIX, Linux, Oracle, Tivoli, Win NT) Backup & Recovery, Storage Management, High Availibility, Systems Management Ausbildung Vordiplom Maschinenbau (FH)

Mehr

Dies ist die entscheidende Erkenntnis, um die es in diesem Buch geht. Nach Abschluss der Lektüre werden Sie verstehen, was genau ich damit meine.

Dies ist die entscheidende Erkenntnis, um die es in diesem Buch geht. Nach Abschluss der Lektüre werden Sie verstehen, was genau ich damit meine. Das Geheimnis der Spitzenspieler Das Spiel der Quoten No-Limit Hold em ist ein Spiel der Quoten. Liegen Sie mit Ihren Quoten grundlegend falsch, können Sie trotz noch so großem Engagement kein Gewinner

Mehr

HANA Operation. Patrick Meier, Director Business Development / Partner 22 May 2014

HANA Operation. Patrick Meier, Director Business Development / Partner 22 May 2014 HANA Operation Patrick Meier, Director Business Development / Partner 22 May 2014 E R F O L G R E I C H E S H O S T I N G V O N S A P U N D D R I T TA N W E N D U N G E N A U F S A P H A N A Regensdorf,

Mehr

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden Jens Kaminski ERP Strategy Executive IBM Deutschland Ungebremstes Datenwachstum > 4,6 Millarden

Mehr

Copyright 2014, Oracle and/or its affiliates. All rights reserved.

Copyright 2014, Oracle and/or its affiliates. All rights reserved. 1 Integrierte Systeme für ISVs Matthias Weiss Direktor Mittelstand Technologie ORACLE Deutschland B.V. & Co. KG 2 Agenda Engineered Systems Lösungsansatz aus der Praxis Engineered Systems Oracle s Strategie

Mehr

Infrastruktur modernisieren

Infrastruktur modernisieren Verkaufschance: Infrastruktur modernisieren Support-Ende (EOS) für Windows Server 2003 Partnerüberblick Heike Krannich Product Marketing Manager ModernBiz ModernBiz Bereitstellung von KMU-Lösungen mit

Mehr

Berater-Profil 3447. SAP Basis Berater - BC, Netweaver -

Berater-Profil 3447. SAP Basis Berater - BC, Netweaver - Berater-Profil 3447 SAP Basis Berater - BC, Netweaver - Fachlicher Schwerpunkt: - SAP Security (Rollen+Profile, Basis, BW Security) - Transportwesen Design und Handling - Systemarchitekturplanung, SAP

Mehr

HOB Remote Desktop VPN

HOB Remote Desktop VPN HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB Remote Desktop VPN Sicherer Zugang mobiler Anwender und Geschäftspartner

Mehr

ROI in VDI-Projekten. Dr. Frank Lampe, IGEL Technology CIO & IT Manager Summit 14.04.2011 Wien. IGEL Technology ROI in VDI Projekten Dr.

ROI in VDI-Projekten. Dr. Frank Lampe, IGEL Technology CIO & IT Manager Summit 14.04.2011 Wien. IGEL Technology ROI in VDI Projekten Dr. ROI in VDI-Projekten Dr. Frank Lampe, IGEL Technology CIO & IT Manager Summit 14.04.2011 Wien 1 Agenda Einführung aktuelle Umfragen zu VDI Nutzen von VDI Projekten Einsparpotenziale auf der Desktopseite

Mehr

Martin Knoblauch Tel.: 08161 85801 Wettersteinring 12 Mobile: 0171/8033948 D-85354 Freising knobi@knobisoft.de. Lebenslauf

Martin Knoblauch Tel.: 08161 85801 Wettersteinring 12 Mobile: 0171/8033948 D-85354 Freising knobi@knobisoft.de. Lebenslauf Lebenslauf Persönliche Daten Adresse Geburtstag Martin Knoblauch Wettersteinring 12 D-85354 Freising 27. Oktober 1958 in Düsseldorf Derzeitiger Arbeitgeber (seit Juli 2002) MSC.Software GmbH, D-81829 München

Mehr

Ergonomisch, flexibel, schnell und automatisch merlin.zwo realisiert neues Berichts-Portal RAAS

Ergonomisch, flexibel, schnell und automatisch merlin.zwo realisiert neues Berichts-Portal RAAS Neue Reporting-Software für die Union Investment Gruppe Ergonomisch, flexibel, schnell und automatisch merlin.zwo realisiert neues Berichts-Portal RAAS Foto: Union Investment Gruppe Mit dem von merlin.zwo

Mehr

GPX Business CLOUD. Einführung in GPX. www.inposia.com

GPX Business CLOUD. Einführung in GPX. www.inposia.com GPX Business CLOUD Einführung in GPX www.inposia.com Die GPX Business CLOUD Konnektieren Sie elektronisch mit Ihren Geschäftspartnern via EDI Ihre EDI Lösung 3 Sparen Sie erhebliche Prozesskosten ein Die

Mehr

Secure Network Communications (BC-SEC-SNC)

Secure Network Communications (BC-SEC-SNC) Secure Network Communications (BC-SEC-SNC) HELP.BCSECSNC Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen

Mehr

Release Notes scvenus 2.2.0

Release Notes scvenus 2.2.0 Release Notes Juli 2005 IT Services Release Notes scvenus 2.2.0 Operational Concepts Security Solutions Was ist neu? Unterstützte Betriebssysteme Vertrieb E-Mail-Support / Mailinglisten Webportal / Schulung

Mehr

Ihr Microsoft Spezialist für Migrationen, Upgrades und Infrastruktur-Konzeption für Microsoft SQL Server und Microsoft SharePoint.

Ihr Microsoft Spezialist für Migrationen, Upgrades und Infrastruktur-Konzeption für Microsoft SQL Server und Microsoft SharePoint. Ihr Microsoft Spezialist für Migrationen, und Infrastruktur-Konzeption für Microsoft und Microsoft SharePoint. Unsere Infrastructure Services unterstützen Kunden mit folgenden Angeboten: Migrationen von

Mehr

... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 2... Konzeption virtualisierter SAP-Systeme... 87

... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 2... Konzeption virtualisierter SAP-Systeme... 87 ... Einleitung... 15 1... Grundlagen der Virtualisierung... 23 1.1... Einführung in die Virtualisierung... 23 1.2... Ursprünge der Virtualisierung... 25 1.2.1... Anfänge der Virtualisierung... 25 1.2.2...

Mehr

SQL Server 2012 Datenblatt zur Lizenzierung

SQL Server 2012 Datenblatt zur Lizenzierung SQL Server 2012 Datenblatt zur Lizenzierung Veröffentlicht am 3. November 2011 Produktüberblick SQL Server 2012 ist ein bedeutendes Produkt- Release mit vielen Neuerungen: Zuverlässigkeit für geschäftskritische

Mehr

Qualifikationsprofil

Qualifikationsprofil Qualifikationsprofil PERSÖNLICHE DATEN Kandidat: 16103 (männlich) Jahrgang: 1974 Staatsangehörigkeit: Deutsch Sprachkenntnisse: Deutsch Muttersprache Englisch fließend in Wort und Schrift SAP-Erfahrung

Mehr

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack

Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack Migration einer bestehenden Umgebung in eine private Cloud mit OpenStack CeBIT 2014 14. März 2014 André Nähring Cloud Computing Solution Architect naehring@b1-systems.de - Linux/Open Source Consulting,

Mehr

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD

PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD PROLAG WORLD 2.0 PRODUKTBESCHREIBUNG SERVERSYSTEM, CLUSTERSYSTEME FÜR PROLAG WORLD Inhaltsverzeichnis 1. ZUSAMMENSTELLUNG VON SERVERN...3 1.1. ANFORDERUNGSPROFIL...3 1.2. 1.3. SERVER MODELLE...3 TECHNISCHE

Mehr

E-Interview mit Herrn Dr. Winokur, CTO von Axxana

E-Interview mit Herrn Dr. Winokur, CTO von Axxana E-Interview mit Herrn Dr. Winokur, CTO von Axxana Titel des E-Interviews: Kostengünstige Datenrettung ohne Verlust und über alle Distanzen hinweg wie mit Enterprise Data Recording (EDR) von Axxana eine

Mehr

SEP AG. SEP sesam Die Backup und Recovery Lösung für (fast) alle heterogene Umgebungen. Johann Krahfuss Director Partner Sales jkr@sep.de. www.sep.

SEP AG. SEP sesam Die Backup und Recovery Lösung für (fast) alle heterogene Umgebungen. Johann Krahfuss Director Partner Sales jkr@sep.de. www.sep. SEP AG SEP sesam Die Backup und Recovery Lösung für (fast) alle heterogene Umgebungen. Johann Krahfuss Director Partner Sales jkr@sep.de Über die SEP AG Die SEP AG ist deutscher/europäischer Hersteller

Mehr

17 Datenbank aufteilen

17 Datenbank aufteilen 17 Datenbank aufteilen Warum teilt man eine Datenbank auf und was bedeutet dies? Eine Access-Datenbankdatei ist ein Monolith. Sie enthält alle notwendigen Objekte wie Tabellen, Abfragen, Formulare, Berichte,

Mehr

PROFIL. Michael Honekamp

PROFIL. Michael Honekamp Seite: 1 Michael Honekamp PROFIL Beruf : Diplom-Physiker (1993) zertifizierter DV-Spezialist (1994) SAP Certified Technical Consultant UNIX / Oracle (1998) SAP Certified Technical Consultant UNIX / DB2

Mehr

BESCHAFFUNG UND LIZENZIERUNG

BESCHAFFUNG UND LIZENZIERUNG BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG: ORACLE LIZENZIERUNG Fragen Sie uns! Oracle Database 12c Standard

Mehr

Success Story Von Novell zu Microsoft

Success Story Von Novell zu Microsoft Success Story Von Novell zu Microsoft www.netlogix.de 1 Der Kunde Die Diakonie Neuendettelsau ist mit 180 Einrichtungen der größte diakonische Träger in Bayern. Sie bietet für Menschen mit einer geistigen

Mehr

Virtualisierung des Bibliothekssystems Aleph 500. ITEK Präsentation 10.02.2010 Uwe Sujata

Virtualisierung des Bibliothekssystems Aleph 500. ITEK Präsentation 10.02.2010 Uwe Sujata Virtualisierung des Bibliothekssystems Aleph 500 ITEK Präsentation 10.02.2010 Uwe Sujata Agenda 1. Ausgangslage 2. Ziele 3. Meilensteine 4. Projektverlauf 5. Systemdesign 6. Abgleich DLV / OLA 7. Risiken

Mehr

Virtualisierung. Es geht auch anders. Ein Erfahrungsbericht zur Enterprise Virtualisierung mit Open-Source-Technologien. Stefan Grote GONICUS GmbH

Virtualisierung. Es geht auch anders. Ein Erfahrungsbericht zur Enterprise Virtualisierung mit Open-Source-Technologien. Stefan Grote GONICUS GmbH Virtualisierung Es geht auch anders Ein Erfahrungsbericht zur Enterprise Virtualisierung mit Open-Source-Technologien Stefan Grote GONICUS GmbH GONICUS* Gegründet 2001 Rund 25 Mitarbeiter Spezialisiert

Mehr

REALTECH Consulting. Was wirklich zählt ist was Sie bewegt!

REALTECH Consulting. Was wirklich zählt ist was Sie bewegt! REALTECH Consulting Was wirklich zählt ist was Sie bewegt! Die Menschen hinter REALTECH sind es, die das Unternehmen und die Projekte so erfolgreich machen. Chris Kohlsdorf, Geschäftsführer, REALTECH Consulting

Mehr

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Softwareentwicklung

Mehr

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Konsolidierung und Neuimplementierung von VIT Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Inhaltsverzeichnis 1 Was ist der Kontext?... 1 2 VIT: Ein sehr erfolgreiches

Mehr

ITSM Executive Studie 2007

ITSM Executive Studie 2007 ITSM Executive Studie 2007 Ergebnisse der Befragung in Österreich und Deutschland Patrick Schnebel Geschäftsführer Niederlassung Wien Telefon: +43 6410820-0 E-Mail: Patrick.Schnebel@materna.de Ines Gebel

Mehr

HANA. TOBA-Team Dresden 19.05.2012

HANA. TOBA-Team Dresden 19.05.2012 HANA TOBA-Team Dresden 19.05.2012 Kunde droht mit Auftrag! Ein großer Discounter schickt Anfrage: Bis wann und zu welchem Preis können Sie 30.000 Stück liefern? Die Hektik beginnt! Bis wann Welche und

Mehr