Hochverfügbarer SAP Betrieb in virtualisierten Umgebungen am Beispiel von VMware vsphere 5 und der SteelEye Protection Suite for Linux

Hochverfügbarer SAP Betrieb in virtualisierten Umgebungen am Beispiel von VMware vsphere 5 und der SteelEye Protection Suite for Linux Version 2.1 Dresden, 13. September 2013

Inhaltsverzeichnis 1 Vorwort... 5 2 Einleitung... 6 3 Grundlagen für den Schutz geschäftskritischer Applikationen... 7 3.1 Zuverlässigkeit der Infrastruktur (Infrastructure Reliability)... 7 3.2 Hardwareverfügbarkeit (Hardware Availability)... 7 3.3 Schutz vor logischen Fehlern (Logical Fault Protection)... 8 3.4 Anwendungsverfügbarkeit (Application Availability)... 8 3.4.1 Überwachung... 8 3.4.2 Datensicherheit... 8 3.4.3 Hochverfügbarkeit... 8 3.4.4 Disaster Recovery... 8 4 Erhöhung der Applikationsverfügbarkeit in klassischen UNIX Umgebungen... 9 4.1 MC/ServiceGuard (HP- UX)... 9 4.1.1 Konfigurationsarten des MC/ServiceGuard Cluster... 10 4.1.2 Quorum- Server des MC/ServiceGuard Cluster... 10 4.2 Oracle Solaris Cluster... 10 4.3 Veritas Cluster Server (VCS)... 11 5 Virtualisierung und Partitionierung auf Nicht- x86- Systemen... 12 6 VMware vsphere Funktionen zur Erhöhung der Verfügbarkeit... 14 6.1 Wichtige VMware Basisfunktionen... 14 6.2 VMware vcenter Server Heartbeat... 15 6.3 VMware High Availability... 15 6.4 VMware vmotion... 17 6.5 VMware Storage vmotion... 18 6.6 VMware Fault Tolerance... 19 6.7 VMware Site Recovery Manager... 21 7 SteelEye Protection Suite for Linux... 22 7.1 SteelEye LifeKeeper for Linux... 22 7.2 SteelEye vappkeeper for Linux... 23 8 SAP NetWeaver... 26 8.1 Struktur des SAP NetWeaver... 26 8.2 Single Points of Failure (SPoF) des SAP NetWeaver... 27 8.3 SAP HA- Interface Zertifizierung... 28 Seite 2

9 Gründe für den Betrieb geschäftskritischer Applikationen in einer virtualisierten Umgebung... 29 9.1 Konsolidierung... 29 9.2 Hochverfügbarkeit... 29 9.3 Disaster Recovery... 29 9.4 Chancen und Risiken... 30 10 Erhöhung der Applikationsverfügbarkeit des SAP NetWeaver durch Einsatz der SteelEye LifeKeeper Protection Suite for Linux in einer VMware vsphere Umgebung... 33 10.1 Application Stack des SAP NetWeaver... 33 10.1.1 Wirkung der VMware vsphere Funktionen auf den Application Stack... 34 10.1.2 Integration von Applikationsschutz in den Application Stack... 35 10.1.3 Bereitstellung hochverfügbarer zentraler Dienste... 35 10.2 Auswahlkriterien für Lösungen zum Applikationsschutz... 36 10.2.1 Zuordnung der Funktionalität zu den Schichten des Application Stacks... 36 10.2.2 Überwachung der Applikation... 37 10.2.3 Konfliktfreiheit der verwendeten Tools... 37 10.2.4 Integration in die Verwaltungsumgebung... 38 11 Design einer hochverfügbaren SAP NetWeaver Plattform auf Basis von VMware vsphere 5... 39 11.1 Gestaltungsaspekte... 39 11.2 Möglichkeiten zur Erhöhung der Verfügbarkeit des SAP NetWeaver... 39 11.2.1 Einsatz von VMware High Availability... 40 11.2.2 Einsatz von VMware Fault Tolerance... 40 11.2.3 Einsatz der SteelEye LifeKeeper Protection Suite for Linux... 40 11.2.4 Einsatz des VMware Site Recovery Managers... 41 11.3 Beispielkonfigurationen... 41 11.3.1 Beispiel 1: VMware High Availability und SteelEye LifeKeeper Protection Suite for Linux mit NFS 41 11.3.2 Beispiel 2: VMware High Availability und SteelEye LifeKeeper Protection Suite for Linux mit Shared Disk... 43 11.3.3 Beispiel 3: Disaster Recovery Szenario... 45 11.3.4 Beispiel 4: Bereitstellung eines hochverfügbaren NFS- Service als zentrale Ressource.. 47 11.4 Betrieb geschäftskritischer Applikationen in Hochverfügbarkeits- Clustern... 48 12 Zusammenfassung und Bewertung... 50 12.1 Konsolidierung der IT- Landschaft... 50 12.2 Erhöhung der Verfügbarkeit... 51 12.3 Möglichkeit zum Disaster Recovery... 51 Seite 3

12.4 Betrieb der virtualisierten Systemlandschaft... 52 13 Anhang... 53 13.1 Trademarks... 53 13.2 Quellenverzeichnis... 53 Seite 4

1 Vorwort Dieses Whitepaper fasst die Erfahrungen aus zahlreichen erfolgreich umgesetzten Projekten zusammen. Ganz wesentlich zum Erfolg der Projekte hat die langjährige gute Zusammenarbeit mit unseren Partnern SAP, SUSE und VMware beigetragen. Auch dieses Whitepaper entstand in enger Abstimmung mit den genannten Partnerunternehmen. Wir bedanken uns für die vielen wichtigen Hinweise, Ergänzungen und die kritische Begleitung beim Entstehen dieser Arbeit. Ein besonderer Dank gilt an dieser Stelle den Herren Markus Gürtler, Alexander Hass, Christoph Reisbeck, Erik Rieger, Matthias Schlarb und Dr. Manfred Stein. Dresden, im August 2013 Seite 5

2 Einleitung Diese Veröffentlichung stellt Technologien und Lösungen zur Erhöhung der Applikationsverfügbarkeit für Linux- Systeme in virtualisierten Umgebungen vor. Betrachtet wird eine x86- Umgebung, die, basierend auf der Virtualisierungsplattform VMware vsphere 5 und dem Betriebssystem SUSE Linux Enterprise Server als Grundlage für den Betrieb des SAP NetWeaver, hochverfügbaren Anforderungen entspricht. Dabei werden verschiedene Möglichkeiten zur Erhöhung der Applikationsverfügbarkeit dargestellt, bewertet und Empfehlungen für den Aufbau einer hochverfügbaren SAP NetWeaver Systemplattform gegeben. Das White Paper richtet sich dabei vorwiegend an Systemarchitekten und IT- Manager. SAP NetWeaver ist seit vielen Jahren die führende Plattform zur Unterstützung nahezu aller wertschöpfenden Prozesse in Unternehmen. Man kann daher mit Fug und Recht behaupten, dass es sich um geschäftskritische Anwendungen handelt. Mit der zunehmenden Verbreitung von SAP R/3 dem Vorgänger von SAP ERP seit Anfang der 1990- iger Jahre hielt das Client/Server- Computing und damit der zunehmende Einsatz von offenen Betriebssystemen Einzug in die Unternehmens- IT. Namentlich UNIX- Systeme unterschiedlicher Hersteller lösten nun die monolithischen Systeme ab, die die Grundlage für SAP R/2 und vergleichbare andere Softwarelösungen waren. Hiermit wurde die erste große Konsolidierungswelle ausgelöst: Die Anwender lösten sich zunehmend aus der Umklammerung proprietärer Systeme die Systeme wurden flexibler und kostengünstiger. Mit der immer größeren Verbreitung von x86- basierten Linux- Systemen als Plattform für SAP NetWeaver und dem gleichzeitigen Durchbruch bei den Virtualisierungstechnologien wird seit einiger Zeit der seinerzeit durch Client/Server- Computing eingeleitete Paradigmenwechsel weiter beschleunigt. Hiervon profitieren ein weiteres Mal die Anwender: Die Wahl des Hardwarelieferanten wird nun nicht mehr durch die spezifische UNIX- Distribution vorgegeben. Mit Linux als Betriebssystemplattform steht die gesamte Palette der verfügbaren x86- Hardware zur Verfügung. Der Einsatz von Virtualisierungslösungen sorgt dabei für eine effizientere Nutzung der vorhandenen Ressourcen und eine Erhöhung der Flexibilität im Hinblick auf Erweiterungen oder auch kurzfristige Reduzierungen. Es ist hierbei ersichtlich, dass neben dem Stromverbrauch auch Raumkapazitäten und Wärmeabführung durch Virtualisierung reduziert werden können. Insgesamt wird die zur Verfügung stehende Kapazität der IT effizienter genutzt und damit Kosten und CO 2 Emissionen reduziert. mit Sitz in Dresden verfügt über langjährige Erfahrungen in Konzeption, Design und Betrieb von hochverfügbaren SAP Umgebungen unter Linux. Das Unternehmen unterhält aktive Partnerschaften zu allen relevanten Hard- und Softwareherstellern und pflegt einen regen Erfahrungsaustausch mit dem SAP LinuxLab in St. Leon- Rot. Seite 6

3 Grundlagen für den Schutz geschäftskritischer Applikationen Der Verzicht auf die Unterstützung der Geschäftsprozesse eines Unternehmens durch die IT ist in der heutigen Zeit undenkbar. Die Integration der elektronischen Datenverarbeitung in allen denkbaren unternehmenskritischen Anwendungsbereichen hat sich zu einem Standard entwickelt, der höchste Anforderungen an den Betrieb der Technik stellt. Dabei stehen Leistungsfähigkeit, Verfügbarkeit, Stabilität und Sicherheit im Vordergrund der Anwender. Geachtet werden muss auf möglichst niedrige Beschaffungs- und Betriebskosten. Unabhängig von der einzusetzenden Plattform, dem Betriebssystem und den betriebenen Applikationen gibt es eine Reihe von Bausteinen, die diese Anforderungen erfüllen. Dabei kann nur die Kombination aller Komponenten zur erfolgreichen Umsetzung führen. Dies soll im Folgenden näher betrachtet werden: 3.1 Zuverlässigkeit der Infrastruktur (Infrastructure Reliability) Die Zuverlässigkeit der einzelnen Infrastrukturkomponenten beginnend bei der Qualität der Verkabelung bis hin zu Brandschutzlösungen für das Rechenzentrum spielt eine wichtige Rolle für die Verfügbarkeit des Gesamtsystems. Sie stellt de facto das Fundament für Business Continuity dar. Hier spielen bauliche Maßnahmen ebenso wie zum Beispiel unterbrechungsfreie Stromversorgungen (USVs) wichtige Rollen für die Bereitstellung einer zuverlässigen Infrastruktur. Teilweise kommen auch spezielle, schlüsselfertige Rechenzentrumseinheiten zum Einsatz. 3.2 Hardwareverfügbarkeit (Hardware Availability) Die aktiven Komponenten vom Netzwerkswitch bis hin zur Server- und Storage- Hardware haben ebenfalls einen maßgeblichen Einfluss auf eine erfolgreiche Business Continuity Strategie. Redundanzen durch RAID- Systeme ebenso wie doppelte Netzteile oder mehrere Netzwerkadapter je Server sind verbreitete Maßnahmen, die Hardwareverfügbarkeit wesentlich zu erhöhen. Seite 7

3.3 Schutz vor logischen Fehlern (Logical Fault Protection) Auch wenn alle anderen hier behandelten Aspekte erfolgreich umgesetzt werden der Schutz vor logischen Fehlern ist ebenso wichtig. Hier helfen Snapshots ebenso wie Continuous Data Protection (CDP), mit dem eine Wiederherstellung (Rewind) eines definierten Altzustandes ermöglicht wird. Auch Schattendatenbanken können hier wertvolle Hilfe leisten. 3.4 Anwendungsverfügbarkeit (Application Availability) 3.4.1 Überwachung Eine umfassende Überwachung (Monitoring) aller wichtigen Systemparameter zeigt frühzeitig mögliche Schwachstellen oder zu erwartende Engpässe auf. Egal ob sich ein Dateisystem durch kontinuierliches Schreiben von Logfiles der Kapazitätsgrenze nähert oder aber Netzwerkadapter Paketverluste produzieren: Bei rechtzeitigem Erkennen können entsprechende Gegenmaßnahmen ergriffen und damit die Verfügbarkeit erhöht werden. 3.4.2 Datensicherheit Grundsätzlich kommt der Sicherheit und Konsistenz der Daten die größte Aufmerksamkeit zu. Neben der Nutzung von RAID- Storages und einem angemessenen Backup- Konzept ist die regelmäßige Anfertigung von Snapshots hilfreich. Zusätzliche Sicherheit kann durch eine Spiegelung auf ein weiteres Storage erreicht werden (s. Disaster Recovery) 3.4.3 Hochverfügbarkeit Die Verfügbarkeit der Anwendung wird durch ein Cluster erhöht. Hierbei erfolgt die Überwachung der Clusterknoten durch einen sogenannten Heartbeat. Der Zustand der Anwendung wird durch ein Monitoring der Anwendungsressourcen über spezifische Skripte überwacht. Im Fehlerfall erfolgt ein Schwenken der Ressourcen (und damit der Anwendung) auf den Clusterknoten n+1. Der häufigste Fall sind Cluster mit zwei Knoten. 3.4.4 Disaster Recovery Beim Ausfall des kompletten Produktionsstandorts wird auf einen Disaster Recovery (DR) Standort umgeschaltet. Die Daten werden synchron oder asynchron auf den DR Standort gespiegelt. Im Fall der synchronen Spiegelung tritt kein Datenverlust auf. Die Spiegelung kann Storage- oder Host- basiert erfolgen. Die Umschaltung erfolgt manuell, bei einer Konfiguration mit Quorum Device kann die Umschaltung auch automatisch erfolgen. Nach der Fehlerbehebung im ursprünglichen Produktionsstandort wird sobald der Datenbestand wieder synchron ist geplant zurückgeschwenkt. Seite 8

4 Erhöhung der Applikationsverfügbarkeit in klassischen UNIX Umgebungen Die Anwendungsplattformen für SAP R/3 waren in der Vergangenheit vor dem Durchbruch der x86- Technologie viele Jahre überwiegend UNIX Systeme. Stabilität, Leistungsfähigkeit und die Gesamtverfügbarkeit der Applikation waren dafür wesentliche Gründe. Clustertechnologien zum Schutz von Applikationen waren hierfür eine wichtige Voraussetzung. Anwendung Anwendung Clustersoftware Betriebssystem Betriebssystem Hardware Hardware In den folgenden Abschnitten soll ein Überblick über verschiedene Lösungsansätze zum Schutz von Applikationen in verschiedenen UNIX Derivaten gegeben werden. Im weiteren Verlauf des vorliegenden White Paper soll auch verdeutlicht werden, dass in virtualisierten Umgebungen, basierend auf der x86- Technologie, entsprechende Tools zur Verfügung stehen und eine adäquate Verfügbarkeit der Applikationen erreicht werden kann. 4.1 MC/ServiceGuard (HP- UX) Typischerweise werden die Anforderungen aus dem Hochverfügbarkeitsumfeld durch den Einsatz einer Clustersoftware erfüllt. Von Hewlett- Packard (HP) wurde der MC/ServiceGuard als Clustersoftware für UNIX- Systeme entwickelt (HP- UX und Linux). Die Buchstaben "MC" bedeuten dabei "multiple computer". "Multiple" steht bei MC/ServiceGuard für eine Zahl zwischen 2 und 16 bei dem Betriebssystem HP- UX und zwischen 2 und 8 bei Linux. Wie heutzutage üblich können die Clusterknoten problemlos in Fibre Channel/Gigabit- Entfernung (10 km) aufgestellt werden. Wem das als Entfernung für einen Desaster- Fall nicht ausreicht, kann eine größere Entfernung durch Verwendung externer Storage- Systeme mittels synchroner oder asynchroner Datenreplikation erreichen. Die gegenseitige Überwachung der Knoten auf Verfügbarkeit erfolgt i. d. R. über ein privates Netzwerk, das redundant ausgelegt werden sollte. In dem Fall, dass nur zwei Knoten miteinander verbunden werden, kann auch eine serielle Verbindung für diesen Heartbeat benutzt werden, die jedoch durch eine zusätzliche LAN- Verbindung abgesichert werden sollte. Grundsätzlich besteht die Möglichkeit, einen Heartbeat über mehrere LAN- Verbindungen, auch gemeinsam mit Benutzerzugängen, zu realisieren. Seite 9

4.1.1 Konfigurationsarten des MC/ServiceGuard Cluster Die Cluster- interne Übernahmefunktionalität kann auf drei verschiedene Weisen konfiguriert werden: active- active active- standby rotating- standby In der ersten Konfigurationsart active- active werden ständig auf allen Clusterknoten unterschiedliche Dienste (im HP- Sprachgebrauch: HA- Packages) zur Verfügung gestellt. Fällt ein Knoten aus, so übernimmt ein definierter Knoten zusätzlich diesen Dienst. Bei active- standby- Konfigurationen wird ein Dienst exklusiv auf einem Rechner zur Verfügung gestellt. Nach einem Ausfall wird der Dienst auf einem anderen Rechner gestartet. Diese beiden Konfigurationen sind innerhalb symmetrischer Clusterkonfigurationen üblich und darüber hinaus geeignet, Desaster- Szenarien zu bewältigen. Bei rotating- standby übernimmt der Knoten mit der geringsten Anzahl gestarteter Dienste den Service eines ausgefallenen Knotens. Der geringere Hardwarebedarf wird in dieser Konfiguration allerdings mit möglichen Performanceeinbußen in einem angenommenen Desaster- Fall (Ausfall der Hälfte der Rechner bei Verteilung auf zwei Lokationen) erkauft. 4.1.2 Quorum- Server des MC/ServiceGuard Cluster Eine Spezialität von MC/ServiceGuard stellt die Nutzung eines Quorum- Servers dar. Um zu vermeiden, dass bei zufälliger, kompletter Kommunikationsunterbrechung zwischen zwei Clustermitgliedern (Split Brain) auf beiden Clusterknoten versucht wird, die Applikation zu starten, werden sogenannte Quorum- Devices definiert. Damit wird vermieden, dass die Applikation mehrfach zur Verfügung steht und Dateninkonsistenzen entstehen können. Eine Übernahme wird nur dann durchgeführt, wenn das Quorum- Device erfolgreich exklusiv gelockt werden kann. Der Quorum- Server stellt zentral solche Devices für bis zu 50 Clusterumgebungen- jedoch maximal 100 Knoten- zur Verfügung. 4.2 Oracle Solaris Cluster Der Oracle Solaris Cluster ist eine Erweiterung des Betriebssystems Oracle Solaris um Eigenschaften zur Erhöhung der Verfügbarkeit des Betriebssystems und von geschäftskritischen Applikationen. Durch die im Oracle Solaris Cluster integrierten Agenten ist es möglich, eine Vielzahl von Anwendungen zu schützen. Diese applikationsspezifischen Agenten sind in der Lage, die entsprechende Anwendung zu starten, zu stoppen oder, bei Ausfall eines Cluster- Knotens, einen Failover der Anwendung auf ein anderes Mitglied durchzuführen. Die zentralen Komponenten des Oracle Solaris Cluster sind der Heartbeat Monitor der Cluster Membership Monitor das HA Framework Seite 10

Durch die Integration der zentralen Komponenten des Oracle Solaris Cluster auf Kernel- Ebene ist es möglich, Fehlersituationen und Ausfälle ohne Verzögerung zu erkennen und Failover- Maßnahmen einzuleiten. Der Status aller Cluster Server wird durch die Heartbeats überwacht. Geht ein Server offline und verliert damit seinen Heartbeat, wird dieser von den verbleibenden Cluster Servern isoliert und der Failover der Applikationen auf einen anderen Server wird gestartet. Durch den Cluster Membership Monitor wird eine konsistente Einbindung der Serverhardware im gesamten Cluster ermöglicht. Koordiniert werden darüber hinaus die Konfiguration der Cluster- Layer und das Ressource Group Management. Das HA Framework garantiert jedem Mitglied des Clusters eine konsistente Sicht auf die Cluster Configuration Database und den Cluster- Status. Der Schutz geschäftskritischer Anwendungen wird im Oracle Solaris Cluster durch die Kombination aus einer Vielzahl notwendiger Ressourcen sichergestellt. Diese Ressourcen sind zum Beispiel globale Storage- Devices, Dateisysteme und Netzwerk- Devices und gewährleisten die Funktionalität aller Applikationsbausteine. Die Ressourcen werden in Ressource Gruppen zusammengefasst. Dadurch werden alle notwendigen Ressourcen in der richtigen Abhängigkeit gestartet und ein Failover auf einen Cluster Server ermöglicht. Auf Grundlage von Failover File Services oder Global File Services ist es mit dem Oracle Solaris Cluster möglich, Failover Cluster oder Parallel Cluster zu betreiben. 4.3 Veritas Cluster Server (VCS) Neben den plattformabhängigen Clusterlösungen MC/ServiceGuard und Oracle Solaris Cluster, ist der Veritas Cluster Server der Firma Symantec u.a. auch in klassischen UNIX Umgebungen eine ebenfalls verbreitete Lösung, um die Verfügbarkeit geschäftskritischer Applikationen zu erhöhen. Die Hauptmerkmale des Veritas Cluster Servers sind unter anderem intelligente Failover Regeln für geschützte Applikationen, Servicegruppen und die Out- oft- the- box Unterstützung vieler geschäftskritischer Anwendungen. Definiert ist ein Veritas Cluster Server als ein Verbund von Systemen, die sich die gemeinsame Cluster- Konfiguration teilen und über ein gemeinsames Interconnect Network verbunden sind. Ein Clusterverbund kann aus bis zu 32 Cluster- Servern bestehen, die auf unterschiedliche Weise auf den Datenbestand der Applikationen auf den Shared Storage Devices zugreifen. Mit Hilfe der Resource Agents werden die für den Betrieb der geschäftskritischen Applikationen notwendigen Ressourcen zu einer oder mehreren Servicegruppen zusammengefasst. Neben Application- Resource- Agents gehören auch Agenten für Storage-, Filesystem- und Netzwerkressourcen zum Inhalt des Veritas Cluster Servers, um die Grundvoraussetzungen für den Betrieb der Anwendungen zu gewährleisten. Seite 11

In den definierten Servicegruppen werden die Ressourcen auf Grundlage ihrer Abhängigkeiten untereinander und miteinander verbunden, wodurch eine korrekte Startreihenfolge der Ressourcen festgelegt werden kann. Die Resource Agents steuern die geschützten Ressourcen und Anwendungen. Nach Bedarf werden die Ressourcen auf den Clustersystemen gestartet, gestoppt, überwacht und im Fehlerfall neu gestartet. Ist ein Neustart einer oder mehrerer Ressourcen einer Servicegruppe auf dem aktiven Clustersystem nicht möglich, wird ein Failover dieser Servicegruppe auf ein anderes Clustersystem in dem Clusterverbund ausgeführt. Je nach Anzahl der Server im Clusterverbund und der konfigurierten Failover Regeln der Servicegruppe sind N+1 und N to N Cluster Topologien möglich. In der N+1 Cluster Konfiguration existiert ein freies Clustersystem, das als Failover Ziel der Servicegruppen fungiert. Eine N to N Cluster Konfiguration zeichnet sich dadurch aus, dass auf allen Clustersystemen standardmäßig eine Applikation aktiv ist. Im Fehlerfall wird anhand der Auslastung und freier Kapazitäten über die Failover Regeln entschieden, auf welches Clustersystem das Failover der fehlerhaften Servicegruppe durchgeführt wird. Die Steuerung des Clusterverbundes ist über die Veritas Cluster Server Management Console möglich, die eine vollständige Sicht auf alle Veritas Cluster Server gibt. Durch den Einsatz des Veritas Cluster Servers ist somit eine Erhöhung der Applikationsverfügbarkeit in klassischen UNIX Umgebungen möglich. 5 Virtualisierung und Partitionierung auf Nicht- x86- Systemen Die Idee der möglichst flexiblen Aufteilung von Hardwareressourcen auf verschiedene Systeme stammt aus dem Mainframe- Bereich: Eine physische Maschine wird dazu in mehrere Einheiten unterteilt (partitioniert). Bei Nicht- x86- Systemen kommt oft sogenannte Hardware- Partitionierung in Form logischer Partitionen (Logical Partitions, LPAR, z.b. auf IBM System p bzw. System z) oder Logical Domains (z.b. auf Sun Fire E10K) zum Einsatz. Physische Maschine Logische Partition Logische Partition Logische Partition Logische Partition Dabei findet eine Zuweisung von Ressourcen an die LPARs/Logical Domains statt, beispielsweise: eine CPU, Seite 12

2 GB Hauptspeicher, Festplattenspeicher usw. In der LPAR/Logical Domain kann nun ein Betriebssystem (z.b. AIX) mit den zugewiesenen Ressourcen arbeiten. Auf einer physischen Maschine können auf diese Weise mehrere Betriebssysteme parallel installiert werden, die direkten Zugriff auf die ihnen zugewiesene Hardware haben. Weitere Features sind die dynamische Anpassung der zugewiesenen Ressourcen im laufenden Betrieb oder das Verschieben einer LPAR/Logical Domain von einer physischen Maschine auf eine andere. Obwohl die zu Grunde liegende Technologie für Hardwarepartitionierung und virtuelle Maschinen (wie etwa unter VMware) völlig unterschiedlich ist, sind einige Funktionen durchaus vergleichbar. Eine Maschine mit höherer Last kann von den Ressourcen einer Maschine mit niedrigerer Last profitieren, auf einer Hardware können mehrere Betriebssysteme parallel betrieben werden und die Verschiebung einer Maschine auf eine andere physikalische Hardware ist möglich. Zusätzlich zur Hardwarepartitionierung können auch virtualisierte Maschinen auf Nicht- x86- Systemen betrieben werden, so zum Beispiel mit Hilfe des Betriebssystems VM auf IBMs System z. Diese Technologie besitzt durchaus vergleichbare Möglichkeiten und Funktionen wie die Virtualisierungslösung von VMware. Im Gegensatz zu VMware sind diese Lösungen an eine proprietäre Hardware gebunden. Seite 13

6 VMware vsphere Funktionen zur Erhöhung der Verfügbarkeit VMware bietet als einer der branchenführenden Hersteller mit langjähriger Erfahrung am Markt eine umfangreiche Palette an Virtualisierungsprodukten an. Dabei setzt VMware den Fokus auf Lösungen, deren Einsatz in den unterschiedlichsten Bereichen im Wesentlichen zwei Ziele verfolgt: Das Erreichen höherer Effizienz bei gestiegener Flexibilität. Die Unabhängigkeit von der verwendeten Hardware führt zu einer höheren Flexibilität und ermöglicht einen dynamischen Betrieb der Anwendungen, wobei Leistung entsprechend dem Bedarf zur Verfügung gestellt werden kann. Die folgenden Abschnitte sollen die entsprechenden Features vorstellen und deren prinzipielle Funktionsweise erläutern. Je nach Lizensierung und hardwaretechnischen Voraussetzungen können diese auch in Kombination miteinander verwendet werden. 6.1 Wichtige VMware Basisfunktionen Der VMware vcenter Server bildet die zentrale Konfigurations- und Verwaltungsinstanz jeder VMware Infrastruktur, von welcher auch das Monitoring der einzelnen virtuellen Maschinen erfolgt. Neben manueller Konfiguration können auf Basis der Messergebnisse auch automatisch gesteuerte Aktionen durchgeführt werden. Bei Ausfall des VMware vcenter Servers ist eine zentrale Kontrolle über die Ressourcen nicht mehr möglich und Automatismen, wie z.b. der Lastenausgleich durch Migration einzelner virtualisierter Systeme, kann nicht mehr erfolgen. Dieser Umstand kann negative Auswirkungen auf die in den virtualisierten Systemen befindlichen Anwendungen haben, weshalb mit VMware vcenter Server Heartbeat (siehe Abschnitt 6.2) eine Möglichkeit besteht, diese Instanz gegen Ausfall abzusichern. Mittels VMware- Ressourcenpools (Bestandteil des VMware vcenter Server) lassen sich logische Pools aus CPU- und Arbeitsspeicherressourcen bilden und diese bestimmten virtualisierten Servern fest zuweisen. Damit kann ein festgelegtes Ressourcenniveau für bestimmte Anwendergruppen sichergestellt werden. Aufgrund der Tatsache, dass Ressourcenpools voneinander isoliert sind, haben Änderungen innerhalb eines Ressourcenpools keinen Einfluss auf andere, unabhängige Pools. Mittels VMware Dynamic Resource Scheduling (VMware DRS) können Ressourcenpools über mehrere VMware Hosts hinweg gebildet werden, diese werden als Dynamic Ressource Scheduling- Cluster bezeichnet und bilden gleichzeitig die Grundlage für VMware High Availability (siehe Abschnitt 6.3). Innerhalb dieser Clustereinheiten ist ein dynamischer Lastenausgleich zwischen mehreren VMware vsphere Hosts möglich, wofür aktuelle Leistungsdaten ausgewertet werden und anhand definierbarer Richtlinien spezielle Aktionen, wie z.b. das Migrieren einzelner virtualisierter Systeme auf andere Hosts per VMware vmotion (siehe Abschnitt 6.4), ausgelöst werden können. Die abgefragten Leistungsdaten beinhalten z.b. Speicher- und Prozessorauslastung sowie Netzwerkantwortzeiten, jedoch lassen sich keine applikationsspezifischen Abfragen wie z.b. die Dauer bestimmter SQL- Datenbank- Zugriffe definieren. Seite 14

VMware vstorage VMFS ist ein Clusterfilesystem, das auf gemeinsame Speichersysteme zurückgreift, um mehreren VMware ESX- Instanzen den gleichzeitigen Lese- /Schreibzugriff auf dasselbe Dateisystem zu ermöglichen. Damit ergibt sich eine wesentlich einfachere Zuordnung von Ressourcen zu den virtualisierten Maschinen und vereinfacht deren Management, da der gesamte Betriebszustand einer virtualisierten Maschine effizient an einem zentralen Speicherort abgelegt wird. 6.2 VMware vcenter Server Heartbeat VMware vcenter Server Heartbeat dient zur redundanten Auslegung des VMware vcenter Servers inklusive der dazugehörigen SQL- Datenbank auf einem zweiten Standby- System. Dabei wird der komplette Server mit den darauf laufenden Anwendungen überwacht und die Daten auf ein zweites System per hostbasierter Replikation übertragen. Zur Überwachung der ordnungsgemäßen Funktion der vcenter Server können beispielsweise Performanceattribute herangezogen werden, die mit Sollwerten abgeglichen werden und bei entsprechenden Abweichungen zum Failover auf das Zweitsystem führen. Durch die Kommunikation mit verschiedenen Kernkomponenten einer Systemumgebung, wie z.b. mit dem Globalen Katalog auf einem Domänencontroller, dem primären DNS- Server oder dem Netzwerk- Gateway soll sichergestellt werden, dass der Ausfall von Netzwerkpfaden nicht zur Isolation eines VMware vcenter Servers führt. 6.3 VMware High Availability VMware High Availability (HA) dient zum Schutz von virtualisierten Maschinen vor Hardwareausfällen und Fehlern im Host- Betriebssystem. VM 1 VM 2 VM 3 VM 4 VMware High Availability Dazu werden Cluster gebildet, die aus mehreren ESX- Hosts bestehen und aus deren Ressourcen ein systemübergreifender Pool entsteht. Zwischen allen beteiligten Systemen werden Statusnachrichten (Heartbeats) versendet, anhand derer die ordnungsgemäße Funktion der Maschinen innerhalb eines Clusters signalisiert werden. Bei Ausfall dieser Statusnachrichten über einen definierten Zeitraum werden die auf dem betreffenden System befindlichen virtualisierten Maschinen auf den verbleibenden Hosts im Cluster neu gestartet. Die Überwachung erfolgt dabei über einen Agenten, der Bestandteil des Betriebssystems ist. Seite 15

VM 1 VM 2 VM 3 VM 4 VMware High Availability Neben der Überwachung auf Hostebene können auch die virtualisierten Maschinen oder einzelne Anwendungen über einen Heartbeat überwacht werden, der durch die Integrationsdienste (VMware Tools) realisiert wird. Kommt es zu einer Störung dieser Kommunikation, kann auf der betreffenden virtualisierten Maschine ein Reset ausgelöst werden. Neben der Statusabfrage der Integrationsdienste kann auch der I/O vom Server zu den virtuellen Laufwerken als Kriterium für die Definition des Systemstatus hinzugezogen werden. Die Kommunikation zu einzelnen Anwendungen (VMware Application Monitoring) muss über ein separat zu erwerbendes SDK realisiert oder von der betreffenden Anwendung explizit unterstützt werden. Da es sich bei allen von VMware High Availability ausgelösten Wiederherstellungsvorgängen aus Sicht der Gastbetriebssysteme um einen Kaltstart handelt, sind aktive Speicherinhalte sowie nicht auf Festplattenlaufwerke oder andere Speichermedien zwischengespeicherte Daten verloren. Für die Verwendung von VMware High Availability sind folgende Voraussetzungen erforderlich: Alle Hosts müssen Zugriff auf ein Shared Storage mit den Konfigurations- und virtuellen Datenlaufwerken für die virtuellen Disks besitzen. Alle Hosts eines Clusters müssen auf dieselben Netzwerksegmente zugreifen können, damit der Zugriff für die virtualisierten Maschinen auf diesen Systemen gewährleistet ist. Alle Hosts eines Clusters müssen über das Verwaltungsnetz miteinander kommunizieren können. Für die Überwachung von einzelnen virtualisierten Maschinen müssen die Integrationsdienste (VMware Tools) auf diesen installiert sein. Bei der Konfiguration eines VMware High Availability- Clusters wird definiert, ob Ressourcen für eine bestimmte Anzahl von Hostausfällen reserviert werden sollen und welche Priorität die einzelnen virtualisierten Maschinen im Fehlerfall besitzen. Seite 16

6.4 VMware vmotion Das Feature VMware vmotion dient zur unterbrechungsfreien Migration einer virtualisierten Maschine zwischen zwei Virtualisierungshosts. Während des Prozesses werden die Voraussetzungen auf beiden beteiligten Hosts überprüft und bei Erfolg benötigte Laufzeitinformationen, wie z.b. aktuelle Speicherinhalte, transferiert. Anschließend übernimmt das Zielsystem den Betrieb der virtualisierten Maschine komplett. VM 1 VM 2 VMware vmotion Dieser Vorgang erfolgt für die auf dem System laufenden Anwendungen transparent und unter Gewährleistung der Transaktionsintegrität. Die Konfiguration und der Status der zur virtualisierten Maschine gehörenden Netzwerkadapter werden ebenfalls transferiert. VM 1 VM 2 VMware vmotion Für die Verwendung dieses Features müssen jedoch einige Voraussetzungen gegeben sein: Da während eines Migrationsvorganges mit VMware vmotion keinerlei Systemdaten verschoben werden, wie z.b. die virtuellen Disks, müssen diese an einem- von allen am Vorgang beteiligten Hosts- erreichbaren Datenablageort liegen (Shared Storage). Die Netzwerk- Kommunikationspfade der betreffenden virtualisierten Maschinen müssen auf den beteiligten Hosts gewährleistet sein und zusätzlich muss ein Pfad für den Abgleich der Laufzeitinformationen definiert sein. Auf allen virtualisierten Systemen sind betriebssystemspezifische Integrationsdienste erforderlich (VMware Tools), die als Kommunikationsschnittstellen zwischen Verwaltung- und Gastbetriebssystem fungieren. Innerhalb der virtualisierten Maschinen dürfen keine weiteren, virtuellen Geräte verbunden sein, auf die vom Zielsystem aus kein Zugriff besteht. Damit sind auch direkt an virtualisierten Systemen verbundene USB- Geräte oder RAW- Disk Devices ausgeschlossen. Die in den Hosts verwendete CPU- Architektur muss übereinstimmen oder es muss Enhanced VMware vmotion Compatibility (EVC) verwendet werden. Die zu migrierende, virtuelle Maschine darf nicht gleichzeitig in einem Storage vmotion- Prozess migriert werden. Seite 17

Wegen der notwendigen Voraussetzung, ein Shared- Storage für die virtuellen Disks zu nutzen, ist es nicht möglich, eine virtualisierte Maschine zwischen mehreren Datenzentren per VMware vmotion zu migrieren. Für den Abgleichvorgang während einer Migration werden Systemressourcen des Host Systems benötigt. Eine Kommunikation zwischen den Integrationsdiensten und den installierten Anwendungen findet während der Migration nicht statt. Wenn das Gastsystem einer virtualisierten Maschine über einen längeren Zeitraum mit vielen I/O- Vorgängen im lokalen RAM oder den virtuellen Festplatten ausgelastet ist, kann ein vmotion- Vorgang verzögert werden oder wird nicht ausgeführt. Das dafür zur Verfügung stehende Zeitlimit ist konfigurierbar. Mehrere gleichzeitige VMware vmotion Prozesse sind nur dann möglich, wenn sich Quell- und Zielhost innerhalb eines Ressourcenpools befinden. 6.5 VMware Storage vmotion VMware Storage vmotion dient zur unterbrechungsfreien Migration während der Laufzeit von virtualisierten Maschinen zwischen mehreren Datastores. Das beinhaltet sämtliche zugehörigen Datenspeicher, wie z.b. virtuelle Disks oder Konfigurationsdateien. Bei einer Migration mit Storage vmotion verbleibt die virtuelle Maschine auf einem definierten Host, d.h. es handelt sich um einen von VMware vmotion getrennt zu betrachtenden Prozess. VM 1 VM 1 VM 1 VM 1 VMware Storage vmotion VMware Storage vmotion DataStore DataStore DataStore DataStore Für die Verwendung von Storage vmotion müssen folgende Voraussetzungen erfüllt sein: Auf allen virtualisierten Systemen sind betriebssystemspezifische Integrationsdienste erforderlich (VMware Tools), die als Kommunikationsschnittstellen zwischen Verwaltung- und Gastbetriebssystem fungieren. Auf der betreffenden virtualisierten Maschine dürfen keine Snapshots vorhanden sein. Das Hostsystem muss direkten Zugriff auf den Quell- und Ziel- Datastore haben, die sich auch auf unterschiedlichen Speichersystemen befinden können. Die Verwendung von virtuellen Laufwerken, die auf physischen Geräten basieren (RAW- Devices), ist nicht unterstützt. Seite 18

Es ist möglich, im Rahmen eines Storage vmotion Prozesses die Datenlaufwerke von den Konfigurationsdateien zu trennen und diese auf unterschiedlichen DataStores zu verteilen, sowie die Art der virtuellen Disks auf Thin- oder Thick- Provisioned zu verändern. Während eines Storage vmotion Prozesses kommt es zu einer Mehrbelastung durch Disk I/O im Speicherbackend und somit zu einer verlängerten Antwortzeit für Disk I/O Vorgänge im Gastbetriebssystem. Es ist nicht möglich, Bandbreiten- oder Leistungsbeschränkungen für Storage vmotion Prozesse zu definieren. 6.6 VMware Fault Tolerance VMware Fault Tolerance (FT) dient zur Erhöhung der Verfügbarkeit durch Minimierung der Auswirkungen im Fehlerfall. Das entscheidende Merkmal dieser Technologie ist, dass Umschaltvorgänge im Fehlerfall unterbrechungsfrei und ohne Auswirkungen für die auf dem System laufenden Anwendungen geschehen können. Für die Realisierung kommt die VMware vlockstep Technik zum Einsatz, die sämtliche Eingaben und Aufrufe innerhalb einer virtualisierten Maschine auf einem zweiten, virtualisierten System nachführt. Diese Einheit wird auch als Fault Tolerance- Cluster bezeichnet. Dieses zweite System fungiert dabei wie ein Klon und wird automatisch erstellt und verwaltet. Dieser Klon kann zu jedem Zeitpunkt die Aufgaben des Primärsystems übernehmen. VM 1 VM 1' VMware Fault Tolerance Nach Aktivierung des Clone- Systems übernimmt dieses sofort die Rolle des Primärsystems und innerhalb einer kurzen Zeitspanne wird automatisch ein neues Clone- System bereitgestellt. Da sich die Clone- Systeme immer auf einem anderen Host befinden, ist auch der Komplettausfall eines VMware- Hosts abgesichert. VM 1 VM 1' VM 1'' VMware Fault Tolerance Sofern die Voraussetzungen für die Verwendung von VMware Fault Tolerance erfüllt sind, lässt sich dieses Feature im laufenden Betrieb zu- und abschalten, etwa um virtuelle Maschinen und die darauf laufenden Applikationen während kritischer Operationsphasen abzusichern. Seite 19

Wie auch bei VMware High Availability kommen Heartbeats für den Austausch von Statusnachrichten und zur Verifikation der Betriebsbereitschaft des Clusterpartners zum Einsatz, allerdings werden diese im Millisekunden- Bereich zwischen den virtualisierten Maschinen ausgetauscht. VMware Fault Tolerance kann in Kombination mit VMware High Availability und Dynamic Resource Scheduling (DRS) eingesetzt werden. Für die Verwendung von DRS für Fault Tolerance Cluster müssen die verwendeten Hosts jedoch EVC unterstützen. Die wichtigsten Voraussetzungen und Limitierungen für den Einsatz von VMware Fault Tolerance sind: Die zu schützenden VMs müssen Mitglied eines VMware High Availability bzw. Dynamic Resource Scheduling Clusters sein Alle Hosts müssen zu FT- kompatible Prozessoren einer ähnlichen Leistungsklasse besitzen. Die verwendete ESX Version muss bei allen beteiligten Hosts übereinstimmen. Die virtualisierten Maschinen müssen auf einem von allen beteiligten Hosts erreichbaren Datastore liegen und Zugriff auf dieselben virtuellen Netzwerke haben. Die virtuellen Disks der zu schützenden virtualisierten Maschinen müssen preallocated (vorbelegt) sein. Alle Mitglieder des FT- Clusters dürfen nur über einen virtuellen Prozessor verfügen. Auf den Mitgliedern des FT- Clusters dürfen keine Snapshots vorhanden sein. Die Verwendung von FT im Zusammenhang mit Snapshots ist nicht möglich. Zwischen den physischen Hosts muss eine zusätzliche dedizierte Gigabit- Netzwerkverbindung für die Verwendung von FT bestehen. Innerhalb des FT- Clusters müssen mindestens zwei virtuelle Netzwerke existieren, eines für den Statusaustausch. Mit FT geschützte virtuelle Maschinen können nicht gleichzeitig per Storage vmotion migriert werden. Hot- Plugging von virtuellen Geräten, wie z.b. Netzwerkgeräten ist innerhalb von FT- Clustern nicht möglich. Für den Einsatz von VMware Fault Tolerance muss ebenfalls berücksichtigt werden, dass die betreffenden VMs die entsprechenden Ressourcen belegen, obwohl stets nur eine Instanz aktiv genutzt werden kann. Bedingt durch die vlockstep Technologie verlängern sich die Antwortzeiten der Gastbetriebssysteme, was sich negativ auf die darauf laufenden Anwendungen auswirken kann. Zurzeit eignet sich VMware FT nur für Anwendungen mit geringen bis mittleren Ansprüchen an Leistung und Speicherbandbreite. Bei dieser Lösung besteht zudem kein Schutz vor Betriebssystem- oder Programmfehlern, da keine Anwendungsüberwachung stattfindet und auch Veränderungen am Betriebssystem selbst (wie z.b. Updates), die eine Betriebsunterbrechung voraussetzen, nicht ohne Ausfallzeit realisiert werden können. Seite 20