EMC GESCHÄFTSKRITISCHE BUSINESS CONTINUITY FÜR SAP

Transkript

1 White Paper EMC GESCHÄFTSKRITISCHE BUSINESS CONTINUITY FÜR SAP Vereinfachtes Management für hohe Verfügbarkeit und Business Continuity Robuste geschäftskritische SAP-Bereitstellungen Aktiv/Aktiv-Rechenzentren EMC Solutions Group Abstract Dieses White Paper beschreibt die Umstellung von einer herkömmlichen SAP-Bereitstellung auf eine geschäftskritische Business-Continuity-Lösung mit Aktiv/Aktiv-Rechenzentren. Die Lösung wird von EMC VPLEX Metro, EMC Symmetrix VMAX, VMware vsphere High Availability, Oracle RAC, Brocade Networking und SUSE Linux Enterprise Server for SAP Applications unterstützt. November 2012

2 Copyright 2012 EMC Deutschland GmbH. Alle Rechte vorbehalten. EMC ist der Ansicht, dass die Informationen in dieser Veröffentlichung zum Zeitpunkt der Veröffentlichung korrekt sind. Diese Informationen können jederzeit ohne vorherige Ankündigung geändert werden. Die in diesem Dokument enthaltenen Informationen werden ohne Gewähr zur Verfügung gestellt. Die EMC Corporation macht keine Zusicherungen und übernimmt keine Haftung jedweder Art im Hinblick auf die in diesem Dokument enthaltenen Informationen und schließt insbesondere jedwede implizite Haftung für die Handelsüblichkeit und die Eignung für einen bestimmten Zweck aus. Für die Nutzung, das Kopieren und die Verteilung der in dieser Veröffentlichung beschriebenen EMC Software ist eine entsprechende Softwarelizenz erforderlich. Eine aktuelle Liste der Produkte von EMC finden Sie unter EMC Corporation Trademarks auf VMware, vsphere, ESXi, vcenter und vmotion sind eingetragene Marken oder Marken von VMware, Inc., in den USA und anderen Ländern. Brocade, DCX, MLX, VCS und VDX sind eingetragene Marken der Brocade Communications Systems, Inc., in den USA und anderen Ländern. Alle anderen in diesem Dokument erwähnten Marken sind das Eigentum ihrer jeweiligen Inhaber. Art.-Nr.: H

3 Inhaltsverzeichnis Zusammenfassung... 5 Geschäftsvorgang... 5 Lösungsüberblick... 5 Die wichtigsten Vorteile... 6 Einführung... 7 Zweck... 7 Umfang... 7 Zielgruppe... 7 Terminologie... 7 Lösungsüberblick... 9 Einführung... 9 Lösungsarchitektur Schutzebenen Datenbank- und Workload-Profil Hardwareres-sourcen Softwareres-sourcen EMC Speicherinfrastruktur Einführung EMC Symmetrix VMAX 10K Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX VMAX-Konfiguration EMC VPLEX Metro-Infrastruktur Einführung VPLEX-Datenmobilität VPLEX Metro-Lösungskon-figuration VPLEX Witness-Konfiguration VPLEX-Performan-cemonitoring Virtualisierte VMware Infrastructure Einführung VMware-Bereitstellungen auf VPLEX Metro Ausgedehnte VMware-Clusterkon-figuration VMware vsphere HA-Konfiguration VMware vsphere DRS-Konfiguration EMC Virtual Storage Integrator und VPLEX

4 SAP-Systemarchitektur Einführung SAP-Systemkon-figuration SUSE Linux Enterprise High Availability Extension-Konfiguration Oracle-Datenbankarchitektur Einführung Oracle RAC und VPLEX Oracle ACFS-Konfiguration Oracle Extended RAC on VPLEX Metro Konfiguration der Oracle ASM-Laufwerkgruppe Brocade-Netzwerkinfrastruktur Einführung IP-Netzwerkkon-figuration SAN-Netzwerkkon-figuration Hohe Verfügbarkeit und Business Continuity: Tests und Validierung Einführung Ausfall des SAP Enqueue-Serviceprozesses Ausfall der virtuellen Maschine der SAP ASCS-Instanz Ausfall des Oracle RAC-Node Systemausfall am Standort Isolierung des VPLEX-Clusters Fazit Zusammenfassung Ergebnisse Referenzen EMC Oracle VMware SUSE SAP Anhang: Beispielkonfigurationen CRM-Beispielkon-figuration Beispiel: ASCS-Instanzprofil Beispiel: ERS-Instanzprofil Beispiel: ERS-START-Profil Beispiel: DI-Instanzprofil

5 Zusammenfassung Geschäftsvorgang Globale Unternehmen benötigen kontinuierliche Verfügbarkeit für ihre Anwendungen und Informationen, um wettbewerbsfähig zu bleiben. Die im vorliegenden White Paper beschriebene EMC Lösung bietet eine Strategie für Business Continuity und hohe Verfügbarkeit geschäftskritischer Anwendungen wie SAP ERP. RPOs (Recovery Point Objectives) und RTOs (Recovery Time Objectives) sind wichtige Kennzahlen bei der Planung einer geschäftskritischen Business- Continuity-Strategie. Sie sind die Antwort auf zwei grundlegende Fragen, die sich Unternehmen bei der Einschätzung der Folgen etwaiger Notfall- oder Ausfallszenarien stellen müssen: In welchem Umfang sind Datenverluste für uns akzeptabel (RPO)? Wie schnell müssen die Systeme oder Anwendungen wiederhergestellt werden (RTO)? Geschäftskritische Business Continuity für SAP erfordert aggressive RPOs und RTOs zur Minimierung von Datenverlust und Recovery-Zeiten. Zu den wichtigsten, für ein Unternehmen beim Entwurf einer solchen Strategie zu bedenkenden Herausforderungen zählen die Folgenden: Minimierung von RPO und RTO Keine SPOFs (Single-Points-of-Failure) Technologie, Mitarbeiter, Prozesse Maximierung der Ressourcenauslastung Reduzierung der Infrastrukturkosten Management der Komplexität von Integration, Wartung und Tests mehrerer punktueller Lösungen Für SAP ERP-Anwendungen mit einer Oracle RAC (Real Applications Clusters) 11g- Datenbankebene bietet die in diesem White Paper vorgestellte EMC Lösung Antworten auf alle diese Herausforderungen. In der Lösung kommt ein innovatives Aktiv/Aktiv-Bereitstellungsmodell für bis zu 100 km voneinander entfernte Rechenzentren zur Anwendung. Dadurch wird das herkömmliche Aktiv/Passiv-DR-Modell (Disaster Recovery) in eine hoch verfügbare Business-Continuity-Lösung mit rund um die Uhr verfügbaren Anwendungen, RTOs und RPOs von nahezu null und ohne Single-Points-of-Failure transformiert. Lösungsüberblick Diese Lösung basiert auf EMC VPLEX Metro. VPLEX Metro ist eine SAN-basierte Verbundlösung für lokalen und verteilten Speicher. Dank der bahnbrechenden Technologie AccessAnywhere TM können dieselben Daten an zwei geografisch getrennten Standorten vorhanden sein und an beiden Standorten gleichzeitig abgerufen und aktualisiert werden. Die Zusatzoption VPLEX Witness ermöglicht selbst bei Störungen in einem der Rechenzentren hohe Verfügbarkeit der Anwendungen und einen unterbrechungsfreien Betrieb ohne Ausfallzeiten. In diesem White Paper werden die Technologien vorgestellt, auf denen diese innovative Business-Continuity-Lösung beruht: EMC VPLEX Metro sorgt für die virtuelle Speicherebene zur Aktivierung eines Metro-Aktiv/Aktiv-Rechenzentrums. 5

6 VPLEX Datenmobilität ermöglicht eine unterbrechungsfreie Datenverschiebung auf Speicherebene. EMC VPLEX Witness unterstützt selbst bei einer Unterbrechung in einem der Rechenzentren kontinuierliche Anwendungsverfügbarkeit. EMC Symmetrix VMAX 10K-Serie mit Enginuity Speicherarrays mit besonders hoher Verfügbarkeit und Unterstützung für FAST (Fully Automated Storage Tiering) sowie für eine Auswahl an Replikationstechnologien stellt Speicherplattformen der Enterprise-Klasse zur Verfügung. Durch die Migration von einer Datenbank mit Einzelinstanz auf Oracle RAC on Extended Distance Clusters entfallen Single-Points-of-Failure auf Datenbankebene. VMware vsphere virtualisiert SAP-Anwendungskomponenten und schließt sie damit als Single-Points-of-Failure aus. VMware HA (High Availability) schützt die virtuellen Maschinen bei einem Ausfall der physischen Server und Betriebssysteme. SUSE Linux Enterprise Server for SAP Applications mit SUSE Linux Enterprise High Availability Extension und SAP ERS (Enqueue Replication Server) schützen die zentralen SAP-Dienste auf den Enqueue- und Message-Servern über zwei Cluster-Nodes und schließen sie als Single-Points-of-Failure aus. Brocade Ethernet-Fabrics und MLXe-Kernrouter sorgen für reibungslosen Netzwerkbetrieb und Layer2-Erweiterung zwischen verschiedenen Standorten. Brocade DCX 8510-Backbones bieten eine redundante SAN-Infrastruktur einschließlich Fabric-Erweiterung. Die wichtigsten Vorteile Die Lösung verbessert die Verfügbarkeit von SAP-Anwendungen durch: Beseitigung von Single-Points-of-Failure auf allen Ebenen der Umgebung zur Erstellung eines verteilten und hoch verfügbaren SAP-Systems Bereitstellung von Aktiv/Aktiv-Rechenzentren, die RTOs und RPOs von nahezu null und geschäftskritische Business Continuity unterstützen Weitere Vorteile: Validierte und bewährte Speicherumgebungen für SAP durch Symmetrix VMAX 10K Vollständig automatische Verfahren bei Ausfällen Bessere Auslastung von Hardware- und Softwareressourcen Aktiv/Aktiv-Nutzung beider Rechenzentren Automatischer Lastenausgleich zwischen Rechenzentren Wartung ohne Ausfallzeiten Vereinfachtes SAP-Management mit hoher Verfügbarkeit Vereinfachte Bereitstellung von Oracle RAC on Extended Distance Clusters Reduzierte Kosten durch mehr Automatisierung und bessere Auslastung der Infrastruktur Schnelle und einfache Datenverschiebung zwischen Speicherarrays 6

7 Einführung Zweck In diesem White Paper wird eine Lösung für verbesserte Verfügbarkeit von SAP- Anwendungen durch die Erstellung von Aktiv/Aktiv-Rechenzentren an geografisch getrennten Standorten und durch die Beseitigung von Single-Points-of-Failure auf allen Ebenen der Umgebung beschrieben. Eine Betriebsunterbrechung in einer SAP-Umgebung kann die Folge eines technischen, logischen oder logistischen Ausfalls sein. Im Mittelpunkt dieser Lösung steht die Business Continuity aus einer technischen Perspektive. Umfang Der Umfang des White Paper schließt Folgendes ein: Einführung der Haupttechnologien Beschreibung der Lösungsarchitektur und des Lösungsdesigns Beschreibung der Konfiguration der Hauptkomponenten Darstellung der Ergebnisse von Tests, die zur Beseitigung von Single-Pointsof-Failure auf allen Ebenen der Umgebung durchgeführt wurden Darstellung der wesentlichen geschäftlichen Vorteile der Lösung Zielgruppe Terminologie Das vorliegende White Paper richtet sich an SAP Basis-Administratoren, Oracle- Datenbankadministratoren, an Speicheradministratoren und IT-Architekten sowie an technische Leiter, die für die Konzeption, Erstellung und das Management von geschäftskritischen, rund um die Uhr verfügbaren SAP-Anwendungen verantwortlich sind. Dieses White Paper verwendet die folgenden Begriffe in Tabelle 1. Tabelle 1. Terminologie Begriff AAS ABAP ACFS ASCS ASM CIFS CNA CRM DI DPS DRS dvswitch DWDM ERP ERS FAST VP FCoE FEC FRA Beschreibung SAP Additional Application Server SAP Advanced Business Application Programming Oracle ASM Cluster File System ABAP SAP Central Services Oracle Automatic Storage Management Common Internet File System Converged Network Adapter Cluster Resource Manager Dialoginstanz Dynamic Path Selection VMware vsphere Distributed Resource Scheduler vsphere Distributed Switch Dense Wavelength Division Multiplexing Enterprise Resource Planning Enqueue-Replikationsserver Fully Automated Storage Tiering for Virtual Pools Fibre Channel over Ethernet Forward Error Correction Flash Recovery Area 7

8 Begriff HA HAIP HBA IDES ISL LACP LAG LLDP LUW MCT MPLS MPP NAS NFS NL-SAS OCR Oracle Extended RAC RAC RFC RPO RTO SAN SBD SFP SLES SLE HAE SMT SPOF STONITH TAF ToR VCS vlag vlan VMDK VMFS VMware HA VPLS VPN VRF VSI Beschreibung High Availability Highly available virtual IP (hoch verfügbare virtuelle IP) Hostbusadapter SAP Internet Demonstration and Evaluation System Inter-Switch Link Link Aggregation Control Protocol Link Aggregation Group Link Layer Discovery Protocol Logical unit of work (logische Arbeitseinheit) Multi-Chassis Trunking Multi-Protocol Label Switching Multipathing-Plug-in Network Attached Storage Network File System (Netzwerkdateisystem) Nearline SAS (Serial Attached SCSI) Oracle Cluster Registry Oracle RAC on Extended Distance Clusters Oracle Real Application Clusters Remote function call (Remotefunktionsaufruf) Recovery Point Objective Recovery Time Objective Storage Area Network STONITH-Blockgerät Small Form-Factor Pluggable SUSE Linux Enterprise Server SUSE Linux Enterprise High Availability Extension Subscription Management Tool Single-Point-of-Failure Shoot The Other Node In The Head Transparent Application Failover Top-of-Rack Virtueller Cluster-Switch Virtual Link Aggregation Group Virtual LAN Virtuelles Laufwerk Virtual Machine File System VMware High Availability Virtual Private LAN Service Virtuelles privates Netzwerk Virtual Routing and Forwarding Virtual Storage Integrator 8

9 Lösungsüberblick Einführung Implementierungen von SAP: Herausforderungen und Antworten Herkömmliche SAP-Implementierungen weisen mehrere Single-Points-of-Failure auf, darunter: Central Services Enqueue-Server* Message-Server* Datenbankserver Bereitstellung am Einzelstandort Lokaler Festplattenspeicher * In dieser Lösung werden Enqueue- und Message-Server als Services innerhalb der Instanz von ASCS (ABAP SAP Central Services) implementiert. In diesem White Paper wird eine Lösung für die erhöhte Verfügbarkeit von SAP- Anwendungen beschrieben. Durch die Architektur und Komponenten der Lösung entsteht ein Aktiv/Aktiv-Cluster für den gesamten SAP-Stapel, der sowohl mehr Zuverlässigkeit und Verfügbarkeit schafft als auch die Bereitstellung und das Management der Umgebung vereinfacht. Die Lösung bietet die folgenden Vorteile: Durch die Beseitigung von Single-Points-of-Failure auf allen Ebenen der Umgebung entsteht ein hoch verfügbares SAP-System. Dank Aktiv/Aktiv-Rechenzentren ist für geschäftskritische Business Continuity gesorgt. Abbildung 1 zeigt die einzelnen Single-Points-of-Failure in einer SAP-Umgebung und welche Lösungskomponenten zu ihrer Beseitigung eingesetzt werden. Abbildung 1. Implementierungen von SAP: Herausforderungen und Antworten 9

10 Lösungsarchitektur In den folgenden Abschnitten werden die auf jeder Ebene der Umgebung implementierten Lösungen beschrieben, die zu hoher Verfügbarkeit und Business Continuity führen (siehe Abbildung 2) Abbildung 2. Der Weg zu hoher Verfügbarkeit (logische Darstellung) Hohe Verfügbarkeit für die Speicherebene Der gesamte, von jedem Server in der Umgebung benötigte Speicherplatz wurde auf VMAX 10K- und VMAX 20K-Speicherarrays der Enterprise-Klasse verschoben. Die bereitgestellten Brocade Backbones bieten eine redundante SAN-Fabric für den Zugriff auf Speicherplatz. So wird die bewährte und besonders hohe Verfügbarkeit der Arrays und der SAN-Backbones, einschließlich ihrer erweiterten Managementfunktionen und Business-Continuity-Merkmale genutzt. Abbildung 3. HA des Speichers Hohe Verfügbarkeit für Datenbanken Der Datenbankserver ist das Daten-Repository der SAP- Anwendung. Für diese Lösung wurde die Back-end-Datenbank von einer Oracle-Datenbank mit Einzelinstanz in ein Oracle RAC- Cluster mit vier Nodes konvertiert. Dadurch zählt der Datenbankserver nicht mehr zu den Single- Points-of-Failure. Abbildung 4. HA der Datenbank 10

11 Hohe Verfügbarkeit für SAP Die SAP-Anwendungsserver wurden mithilfe von VMware ESXi TM 5.0 vollständig virtualisiert. Jede der virtuellen SAP-Maschinen wurde mit SUSE Linux Enterprise Server for SAP Applications 11 SP1 als Gastbetriebssystem bereitgestellt. SUSE Linux Enterprise High Availability Extension und SAP ERS (Enqueue-Replikationsserver) wurden ebenfalls für den Schutz der SAP Enqueue- und Message-Server bereitgestellt. Dadurch zählen die ASCS (ABAP SAP Central Services) nicht mehr zu den Single-Points-of-Failure. Abbildung 5. HA der SAP-Anwendung Hohe Verfügbarkeit für Rechenzentren Die zuvor beschriebene hoch verfügbare Clusterlösung schützt SAP innerhalb des Rechenzentrums. Für hohe Verfügbarkeit zwischen Rechenzentren verwendet die Lösung die Speichervirtualisierungstechnologie von EMC VPLEX Metro, wie in Abbildung 6 gezeigt. Die einzigartige Aktiv/Aktiv-Clustering-Technologie AccessAnywhere von VPLEX Metro sorgt für Lese-/Schreibzugriff auf verteilte Volumes über synchrone Entfernungen. Durch die standortübergreifende Spiegelung von Daten können Anwender dank VPLEX auf dieselben Informationen im selben Augenblick zugreifen. Abbildung 6. HA für das Rechenzentrum Diese Lösung verbindet VPLEX Metro mit SUSE Linux Enterprise High Availability Extension (auf Betriebssystemebene) und Oracle RAC (auf Datenbankebene): Das Rechenzentrum ist kein Single-Point-of-Failure mehr und bietet eine solide Business-Continuity-Strategie für geschäftskritische Anwendungen. 11

12 Oracle RAC auf Extended Distance Clusters über VPLEX bietet folgende Vorteile: VPLEX vereinfacht das Management von Extended Oracle RAC dank der Integration von standortübergreifender Hochverfügbarkeit auf Infrastrukturebene. Für die Oracle-Datenbankadministratoren entspricht die Installation, Konfiguration und Wartung in jeder Hinsicht einer Einzelstandortimplementierung von Oracle RAC. VPLEX beseitigt die Notwendigkeit einer hostbasierten Spiegelung der ASM- Festplatten und Host-CPU-Zyklen, die dafür belegt werden. Mithilfe von VPLEX werden ASM-Festplattengruppen mit externer Redundanz konfiguriert und durch verteilte Spiegelung geschützt. Hosts müssen lediglich auf den lokalen VPLEX-Cluster zugreifen und I/O- Vorgänge werden nur einmal von diesem Node versendet. Hosts haben jedoch weiterhin vollständigen Lese-/Schreibzugriff auf dieselbe Datenbank an beiden Standorten. Bei hostbasierter Spiegelung von ASM-Festplattengruppen muss jeder Lese- /Schreibvorgang jeweils zweimal gesendet werden, und zwar einmal an jede Spiegelung. Für die Bereitstellung einer Oracle Voting Disc an einem dritten Standort, die als Quorumgerät auf der Anwendungsebene fungiert, besteht keine Notwendigkeit. Mithilfe von VPLEX können Sie Consistency Groups erstellen, die mehrere Datenbanken und Anwendungen als eine einzige Einheit schützen. Die Lösung nutzt VPLEX Witness, um die Konnektivität zwischen den zwei VPLEX- Clustern zu überwachen und eine weitere Verfügbarkeit für den Fall zu ermöglichen, dass ein Ausfall der Netzwerkpartition zwischen Clustern oder ein Clusterausfall vorliegt. VPLEX Witness wird auf einer virtuellen Maschine auf einer dritten, separaten Ausfalldomain bereitgestellt (Standort C). Hohe Verfügbarkeit für das Netzwerk In jedem Rechenzentrum wurde mithilfe der VCS-Technologie (Virtual Cluster Switch) von Brocade eine Ethernet-Fabric erstellt, die eine robuste Zugriffsebene mit automatischer Fehlerkorrektur und Linkweiterleitung bietet. vlags (Virtual Link Aggregation Groups, virtuelle Linkzusammenfassungen) verbinden die VCS- Fabrics mit den Brocade MLXe-Kernroutern, die das Layer-2-Netzwerk auf die beiden Rechenzentren erweitert. Abbildung 7 zeigt die physische Architektur aller Ebenen der Lösung einschließlich Netzwerkkomponenten. 12

13 Abbildung 7. Lösungsarchitektur 13

14 Schutzebenen Tabelle 2 fasst die Hochverfügbarkeitsebenen zusammen, die von der Lösung zur Beseitigung von Single-Points-of-Failure verwendet werden. Tabelle 2. Lokale hohe Verfügbarkeit Lokale hohe Verfügbarkeit Schutz Standort Geschützte Komponenten VMware HA und VMware DRS A + B Virtuelle SAP-Maschinen SUSE Linux Enterprise HAE und SAP Enqueue Replication Server A + B SAP Enqueue-Server, SAP Message-Server Mehrere SAP-Dialoginstanzen A + B SAP-Arbeitsprozesse (DIA, UPD, UP2, SPO) VMware A, B + C Servervirtualisierung Oracle RAC A + B Oracle-Datenbank Oracle Clusterware A + B Gemeinsam genutztes SAP-Dateisystem Oracle ACFS A + B SAP Oracle-Home-Verzeichnis, globales SAP- Verzeichnis, SAP-Übertragungsverzeichnis, SAP ASCS-Verzeichnis EMC Symmetrix VMAX 20K A Lokaler Speicher, RAID, Multipath EMC Symmetrix VMAX 10K B Lokaler Speicher, RAID, Multipath Dann erweitert VPLEX Metro die hohe Verfügbarkeit durch eine Clusterarchitektur, die die Abgrenzungen des Rechenzentrums auflöst und Servern in verschiedenen Rechenzentren Lese-/Schreibzugriff auf gemeinsam genutzte Blockspeichergeräte gibt. Diese Transformation des Rechenzentrums setzt neue Maßstäbe geschäftskritischer Business Continuity im Bereich hohe Verfügbarkeit. Abbildung 8 verdeutlicht dieses Hochverfügbarkeitsdesign, bei dem VPLEX Witness und Cross-Cluster Connect für die Erfüllung höchster Anforderungen an Stabilität und Ausfallsicherheit sorgen. Abbildung 8. Lokale HA mit VPLEX für Business Continuity an Remotestandorten Jede der in Abbildung 8 aufgeführten Technologien wird in den entsprechenden Abschnitten des White Paper näher erläutert. 14

15 Datenbank- und Workload-Profil Tabelle 3 enthält Einzelheiten zum Datenbank- und Workload-Profil der Lösung. Tabelle 3. Datenbank- und Workload-Profil Profilmerkmal Anzahl der Datenbanken 1 Details Datenbanktyp Datenbankgröße Datenbankname Oracle RAC Workload-Profil SAP OLTP 500 GB VSE 4 physische Nodes Benutzerdefinierte SAP-Auftragsabwicklungsprozesse Hardwareressourcen Tabelle 4 enthält Einzelheiten zu den Hardwareressourcen der Lösung. Tabelle 4. Hardwareumgebung der Lösung Zweck Menge Konfiguration Speicher (Standort A) 1 Symmetrix VMAX 20K-Serie mit Enginuity: 2 Engines 171 FC-Laufwerke mit 450 GB 52 SATA-Laufwerke mit 2 TB Speicher (Standort B) 1 Symmetrix VMAX 10K-Serie mit Enginuity: 1 Engine 30 NL-SAS-Laufwerke mit 2 TB 79 SAS-Laufwerke mit 600 GB Verteilter Speicherverbund 2 VPLEX Metro-Cluster mit: 2 VS2-Engines Oracle RAC-Datenbankserver 4 4 CPUs mit 8 Kernen und 128 GB RAM VMware ESXi-Server für SAP 4 2 CPUs mit 4 Kernen und 128 GB RAM VMware ESXi-Server für VPLEX Witness Plattform für Netzwerk- Switching und -Routing 2 2 CPUs mit 2 Kernen und 48 GB RAM 2 Brocade DCX 8510-Backbone mit: Fx8-24 FC-Erweiterungskarte 2 FC-Blades mit 48 Ports und Unterstützung für 16-GB-FC-Übertragungsgeschwindigkeit Brocade MLXe Router 4 Brocade VDX 6720 im VCS-Modus 15

16 Softwareressourcen Tabelle 5 enthält Einzelheiten zu den Softwareressourcen der Lösung. Tabelle 5. Softwareumgebung der Lösung Software Version Zweck EMC Enginuity Enginuity 5876 Q SR Betriebsumgebung für Symmetrix VMAX EMC VPLEX GeoSynchrony 5.1 Patch 2 Betriebsumgebung für VPLEX EMC VPLEX Witness 5.1 Patch 2 Überwachung und Arbitrierung von Komponenten bei VPLEX- Clusterausfällen und Kommunikationsausfällen innerhalb des Clusters EMC Unisphere TM 5.1 VPLEX-Managementsoftware EMC Unisphere T VMAX-Managementsoftware EMC VSI (Virtual Storage Integrator) VMware-Speicherintegration EMC PowerPath/VE 5.7 P01 Build 2 Multipath-Software SUSE Linux Enterprise Server for SAP Applications einschließlich SUSE Linux Enterprise High Availability Extension 11 SP1 Betriebssystem für alle Server in der Umgebung VMware vsphere 5.0 Update 1 Hypervisor, der alle virtuellen Maschinen hostet Oracle Database 11g (mit Oracle RAC und Oracle Grid Infrastructure) Enterprise Edition Oracle-Datenbank- und - Clustersoftware SAP ERP 6.04 SAP ERP IDES-System 16

17 EMC Speicherinfrastruktur Einführung Überblick Der folgende Abschnitt erläutert die Speicherinfrastruktur der Lösung: Ein Symmetrix VMAX 20K-Array stellt die Speicherplattform am Standort A dar. Ein Symmetrix VMAX 10K-Array stellt die Speicherplattform am Standort B dar. Beide Speicherarrays werden mit entsprechender LUN-Konfiguration bereitgestellt. EMC Symmetrix VMAX 10K Die Symmetrix VMAX 10K stellt eine neue Klasse von Enterprise- Speicherplattformen dar. Sie wurde speziell dazu entwickelt, einer wachsenden Zahl an IT-Organisationen und Serviceprovidern mit anspruchsvollen Speicheranforderungen und eingeschränkten Ressourcen erstklassige virtuelle High-End-Speicherfunktionen zu bieten. Die VMAX 10K ist einfach zu installieren, einzurichten und zu verwenden. Sie eignet sich insbesondere für Kunden, die besonders hohe und gesicherte Performance benötigen, und ist ein idealer Einstieg in die Symmetrix-basierte Speicherinfrastruktur. Die VMAX 10K nutzt die Virtual Matrix Architecture und bietet Zuverlässigkeit, Verfügbarkeit und Wartungsfreundlichkeit der Enterprise- Klasse. Des Weiteren wurde die VMAX 10K vorkonfiguriert, um das Array noch an demselben Tag einzusetzen, an dem es ausgeliefert wurde. Die Installation nimmt weniger als vier Stunden in Anspruch. Die VMAX 10K ist ein komplett virtuell bereitgestelltes System. Beim Virtual Provisioning verfügt ein Host, eine Anwendung oder ein Dateisystem über mehr Speicher, als physisch vorhanden ist. Physischer Speicher wird nur dann zugewiesen, wenn Daten geschrieben werden und nicht bei der Erstkonfiguration der Anwendung. Dies macht nicht nur manuelle Berechnungen überflüssig, sondern führt auch zu einer Senkung der Energie- und Kühlkosten, da die Größe des inaktiven Speichers im Array reduziert wird. Die Zusatzoption FAST VP für vollständig automatisierten gestuften Speicher erleichtert die Installation und den täglichen Betrieb in IT-Organisationen mit begrenzter Personal- und Ressourcenausstattung. Dank der Integration mit VMware nimmt EMC eine branchenführende Position ein und bietet mit VMAX 10K auf der Grundlage der VMware vsphere 5 Cloudinfrastrukturplattform Enterprise-Speicher mit noch höherer Effizienz. EMC VSI (Virtual Storage Integrator) for VMware vereinfacht die Integration von EMC Speicher in eine virtualisierte Umgebung. Die EMC Enginuity-Betriebsumgebung ermöglicht die intelligente Steuerung aller Komponenten in einem VMAX 10K-Array. 17

18 Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX Die EMC Enginuity-Betriebsumgebung 5876 Q SR ermöglicht die intelligente Steuerung aller Komponenten in einem EMC Symmetrix-Speicherarray. Enginuity ist eine intelligente, präventive Multitasking- Speicherbetriebsumgebung, die den Speicherdatenfluss steuert. Sie ist ausschließlich für Speichervorgänge zuständig und für die in High-End- Umgebungen erforderlichen Servicelevels optimiert. Diese Version von Enginuity setzt den Schwerpunkt auf: Anwenderfreundlichkeit, Management Multitenancy Optimierung VMAX 10K VMAX 20K ist eine perfekte Verbindung aus Anwenderfreundlichkeit, Performance, hoher Verfügbarkeit und angemessenem Preis für kleinere Unternehmen und Kunden im oberen Mid-Tier-Bereich, die ein Speicherdesign mit mehreren Controllern wünschen. VMAX 20K bietet hohe Skalierbarkeit, Kapazität und Performance für Kunden mit höheren Anforderungen. Alle VMAX-Systeme basieren auf der branchenführenden Virtual Matrix Architecture, führen denselben Enginuity-Code aus und verwenden dieselbe Oberfläche für ein zentrales Management: EMC Unisphere for VMAX. Unisphere for VMAX ist eine fortschrittliche grafische Benutzeroberfläche für eine einheitliche EMC Anwendererfahrung auf allen Speicherplattformen. Unisphere for VMAX ermöglicht Kunden einfaches Managen und Überwachen sowie ein leichteres Provisioning von VMAX-Umgebungen (siehe Abbildung 9). Abbildung 9. Unisphere for VMAX 18

19 VMAX- Konfiguration Speicherlayout Das für die Lösung verwendete Layout von VPLEX Metro-, Oracle Extended RACund SAP-Volumes basiert auf Virtual Provisioning. Diese Konfiguration platziert Oracle-Daten- und -Protokolldateien in separate Thin-Pools mit jeweils unterschiedlichem RAID-Schutz. Datendateien befinden sich in einem mit RAID 5 geschützten Pool, während sich die Redo-Protokolle in einem Pool mit RAID 1- Schutz befinden. Keinem Gerät wird vorab Speicher zugewiesen. Eine Ausnahme bilden dabei die Oracle REDO-Protokoll-Geräte. EMC empfiehlt die vollständige und dauerhafte Zuweisung dieser Geräte zum Erstellungszeitpunkt. Dadurch wird ihr Speicher von vorne herein verfügbar. Bei einer Speicherplatzrückgewinnung (Zero Space Reclamation), die zu jedem Zeitpunkt im Pool erfolgen kann, wird vorab zugewiesene Kapazität dem freien Poolspeicherplatz nicht erneut zugeteilt. Abbildung 10 zeigt eine logische Darstellung der Beziehung zwischen Speicherlayout und Oracle ASM-Festplattengruppen. Abbildung 10. Speichergruppen und ASM-Festplattengruppen Gerätetabellen Tabelle 6 zeigt die Größe und Anzahl von für jede ASM-Festplattengruppe konfigurierten Geräte. Tabelle 6. Gerätegrößen Speichergruppe Anzahl von Geräten Gerätegröße (GB) OCR 5 8 FRA 4 16 REDO 8 16 DATA ACFS

20 Tabelle 7 zeigt die Größe und Anzahl der für VPLEX Metro konfigurierten Geräte. Tabelle 7. Größe und Anzahl der für VPLEX Metro konfigurierten Geräte VPLEX-Gerät Anzahl von Geräten Gerätegröße (GB) VPLEX-Metadaten 2 80 VPLEX-Protokoll-Volume 2 20 Backup von VPLEX-Metadaten

21 EMC VPLEX Metro-Infrastruktur Einführung Überblick Dieser Abschnitt beschreibt die VPLEX Metro-Infrastruktur der Lösung, die sich aus folgenden Komponenten zusammensetzt: EMC VPLEX Metro-Cluster in jedem Rechenzentrum (Standort A + B) EMC VPLEX Witness in einer separaten Ausfalldomain (Standort C) EMC VPLEX EMC VPLEX ist eine Speichervirtualisierungslösung sowohl für EMC Arrays als auch Arrays anderer Anbieter. EMC bietet die VPLEX in drei Konfigurationen an, um die Anforderungen von Kunden an hohe Verfügbarkeit und Datenmobilität zu erfüllen (siehe Abbildung 11): VPLEX Local VPLEX Metro VPLEX Geo Abbildung 11. VPLEX-Topologien Weitere Einzelheiten zu diesen VPLEX-Konfigurationen finden Sie in den Referenzen auf Seite 73 aufgeführten Dokumenten. EMC VPLEX Metro VPLEX Metro nutzt eine einzigartige Clusterarchitektur, mit der Kunden die Einschränkungen des Rechenzentrums überwinden und Server in mehreren Rechenzentren bereitstellen können. Dadurch wird ein gleichzeitiger Lese-/ Schreibzugriff auf gemeinsam genutzte Blockspeichergeräte möglich. VPLEX Metro sorgt für Aktiv/Aktiv-Datenzugriff auf Blockebene an zwei Standorten mit synchroner Entfernung und einer Umlaufzeit von bis zu 5 ms. EMC VPLEX Witness VPLEX Witness ist ein optionaler externer Server, der als virtuelle Maschine in einer, von den VPLEX-Clustern getrennten Ausfalldomain installiert wird. VPLEX Witness greift auf beide VPLEX-Cluster mithilfe eines VPN (Virtual Private Network) über das Management-IP-Netzwerk zu. Er erfordert eine Umlaufzeit von maximal einer Sekunde. 21

22 Durch Abgleichung der eigenen Beobachtungen mit den von den Clustern regelmäßig gemeldeten Informationen, befähigt VPLEX Witness die Cluster dazu, zwischen clusterinternen Netzwerkpartitionen und Clusterausfällen zu unterscheiden und I/O-Vorgänge in diesen Situationen automatisch fortzusetzen. VPLEX Witness Semantiken für Verfahren bei Ausfällen gelten ausschließlich für verteilte Volumes innerhalb einer Consistency Group und nur, wenn die Trennregeln für die Consistency Group ein statisches bevorzugtes Cluster ermitteln (weitere Einzelheiten finden Sie VPLEX Consistency Groups auf Seite 23). EMC Unisphere for VPLEX Sie können eine VPLEX-Umgebung mithilfe der webbasierten Benutzeroberfläche von Unisphere for VPLEX managen (siehe Abbildung 12) oder direkt auf einen Managementserver zugreifen und eine VPlexcli-Sitzung starten (VPLEX- Befehlszeilenoberfläche). Abbildung 12. EMC Unisphere for VPLEX EMC VPLEX High Availability VPLEX Metro aktiviert Anwendungs- und Datenmobilität und bietet bei einer Konfiguration mit VPLEX Witness eine hoch verfügbare Infrastruktur für geclusterte Anwendungen wie Oracle RAC. Mithilfe von VPLEX Metro können Sie einen erweiterten Cluster erstellen, als wäre es ein lokaler Cluster. Das Rechenzentrum zählt dadurch nicht mehr zu den Single-Points-of-Failure. Außerdem bietet die Lösung eine einfache Business-Continuity-Strategie, da Daten und Anwendungen an beiden Standorten aktiv sind. Durch die Verwendung einer VPLEX Cross-Cluster-Connect-Konfiguration können Sie sogar eine noch höhere Verfügbarkeit erzielen. In diesem Fall ist jeder Host mit den VPLEX-Clustern an beiden Standorten verbunden. Für den eher unwahrscheinlichen Fall eines Ausfalls des gesamten VPLEX-Clusters verfügt der Host damit über einen alternativen Pfad zum übrigen VPLEX-Cluster. 22

23 Logische VPLEX-Speicherstrukturen VPLEX verkapselt herkömmliche physische Speicherarraygeräte und wendet Ebenen logischer Abstraktion auf diese exportierten LUNs an (siehe Abbildung 13). Virtuelle Volumes Gerät Gerät Extent Speicher- Volume Abbildung 13. Logische VPLEX-Speicherstrukturen Ein Speicher-Volume ist eine aus einem Array exportierte und von einer VPLEX verkapselte LUN. Ein Extent ist ein von VPLEX genutzter Mechanismus zur Teilung von Speicher-Volumes, wobei die gesamte Kapazität oder nur ein Teil des zugrunde liegenden Speicher-Volumes verwendet werden kann. Ein Gerät verkapselt ein Extent oder kombiniert mehrere Extents oder andere Geräte zu einem großen Gerät mit einem speziellen RAID-Typ. Ein verteiltes Gerät ist ein Gerät, das andere Geräte aus zwei separaten VPLEX-Clustern verkapselt. Auf der obersten Schicht der VPLEX-Speicherstrukturen befinden sich virtuelle Volumes. Diese werden aus einem Gerät der obersten Schicht (ein Gerät oder verteiltes Gerät) erstellt und nutzen stets die gesamte Kapazität des Geräts der oberen Schicht. Virtuelle Volumes sind die Elemente, welche die VPLEX den Hosts über ihre Front-end-Ports zur Verfügung stellt. Die VPLEX präsentiert dem Host ein virtuelles Volume über eine Speicheransicht. Sie kann Geräte, einschließlich virtuell bereitgestellter Thin-Geräte und herkömmlicher LUNs, über heterogene Speicherarrays hinweg bereitstellen. VPLEX Consistency Groups Consistency Groups führen virtuelle Volumes zusammen, sodass dieselben Detach-Regeln und weitere Eigenschaften auf alle Volumes in der Gruppe angewendet werden können. Es gibt zwei Arten von Consistency Groups: Synchrone Consistency Groups: Diese werden in VPLEX Local und VPLEX Metro verwendet, um dieselben Detach-Regeln und andere Eigenschaften auf eine Gruppe von Volumes in einer Konfiguration anzuwenden. Dadurch wird die Konfiguration und die Administration auf großen Systemen vereinfacht. Synchrone Consistency Groups nutzen einen Write-Through-Cache (wird als synchroner Cachemodus bezeichnet) und werden mit VPLEX Metro auf Clustern unterstützt, die mit einer Latenz von bis zu 5 ms getrennt sind. VPLEX Metro sendet Writes an die Back-end-Speicher-Volumes und bestätigt den Write an die Anwendung nur, wenn die Back-end-Storage- Volumes den Write in beiden Clustern bestätigt haben. 23

24 Asynchrone Consistency Groups: Diese werden in VPLEX Geo für verteilte Volumes verwendet, in denen Cluster mit einer Latenz von bis zu 50 ms getrennt sein können. Detach-Regeln Detach-Regeln sind vordefinierte Regeln, die Semantiken zur I/O-Verarbeitung für eine Consistency Group festlegen, wenn die Konnektivität zu einem Remotecluster verloren gegangen ist beispielsweise bei einer Netzwerkpartitionierung oder bei einem Ausfall des Remoteclusters. Synchrone Consistency Groups unterstützen die folgenden Detach-Regeln, um das Clusterverhalten bei einem Ausfall zu bestimmen: Statische Präferenzregel identifiziert einen bevorzugten Cluster Eine nicht automatische, übergeordnete Regel setzt den I/O-Vorgang auf beiden Clustern aus Wenn die Konnektivität zwischen Clustern abgebrochen ist, wird die konfigurierte Detach-Regel automatisch ausgeführt. VPLEX Witness kann jedoch eingesetzt werden, um die statische Präferenzregel außer Kraft zu setzen und sicherzustellen, dass der nicht bevorzugte Cluster beim Ausfall des bevorzugten Clusters aktiv bleibt. VPLEX- Datenmobilität Überblick Die Funktion der VPLEX-Datenmobilität ermöglicht die unterbrechungsfreie Migration von Elementen Extent oder Geräte in oder zwischen Clustern. Datenmobilität bietet die folgenden Vorteile: Konsolidierung von Rechenzentren Schnelle Migration von Daten zwischen Rechenzentren Verschiebung und Verlagerung von Anwendungen und Daten über Entfernungen Migration von Daten zwischen unterschiedlichen Arrays für folgende Aktionen: Verlagerung eines Geräts bei laufendem Betrieb von einem langsameren zu einem schnelleren Speicher Verlagerung eines Geräts bei nicht laufendem Betrieb von einem schnelleren zu einem langsameren Speicher Außerbetriebnahme eines Speicher-Volume oder -arrays 24

25 Extent-Migrationen Mit Extent-Migrationen verschieben Sie Daten zwischen Extents im selben Cluster. Speicher-Volumes können sich auf denselben oder auf unterschiedlichen Arrays befinden. Abbildung 14 zeigt eine Extent-Migration. Abbildung 14. Extent-Migration eines VPLEX-Clusters Gerätemigrationen Nicht verteilte Geräte des Typs RAID 0, RAID 1 oder RAID C können mit der Gerätemigration Daten zwischen Geräten im selben Cluster oder in unterschiedlichen Clustern verschieben. Geräte können auf einzelnen oder mehreren Extents oder Geräten erstellt werden. Abbildung 15 zeigt eine Gerätemigration. Abbildung 15. Migration eines Geräts in oder zwischen VPLEX-Clustern In dieser Lösung werden verteilte Geräte genutzt. Für diese Art von Gerät werden Extent-Migrationen verwendet, um den zugrunde liegenden Extent zu jeder Verzweigung des Geräts zu migrieren. Gerätemigrationen zwischen verteilten Geräten werden nicht unterstützt. 25

26 Konfiguration der Datenmobilität Die Voraussetzungen des Zielgeräts oder -Extent lauten: Das Ziel muss dieselbe Größe wie das Quellgerät oder -Extent haben oder größer sein. Wenn das Ziel größer ist als die Quelle, kann der zusätzliche Platz nicht genutzt werden. Auf dem Ziel dürfen keine Volumes vorhanden sein. Extent- und Gerätemobilitätsjobs können über folgende Befehlszeilenoberfläche erstellt, ausgeführt und überwacht werden: VPLEX CLI: Migrationen können als einmalige Jobs oder als Batch-Jobs mit wiederverwendbaren Dateien für die Migrationsplanung ausgeführt werden. Weitere Informationen erhalten Sie im EMC VPLEX CLI-Leitfaden. Unisphere für VPLEX GUI: Die GUI unterstützt keine Batch-Mobilitätsjobs. Jedoch können mehrere Extents/Geräte mit einem Assistenten migriert werden. Auf einem VPLEX-Cluster können bis zu 25 lokale und 25 verteilte Migrationen gleichzeitig ausgeführt werden. Alle Migrationen, die diese Begrenzungen überschreiten, werden in eine Warteschlange gestellt, bis eine vorhandene Migration abgeschlossen wurde. Abbildung 16 zeigt das Erstellen mehrerer Extent-Mobilitätsjobs mit dem Extent Mobility-Assistenten in Unisphere für VPLEX an. Darüber hinaus werden die ausgeführten Jobs und der Jobstatus angezeigt. Abbildung 16. Erstellen und überwachen von Extent-Mobilitätsjobs 26

27 Datenmobilität in dieser Lösung Diese Lösung nutzt eine bestehende VPLEX Metro-Infrastruktur. Im Rahmen einer Technologieaktualisierung wurden die Back-end-Speicherarrays ausgelagert und durch VMAX-Arrays ausgetauscht. VPLEX-Datenmobilitätsjobs wurden für eine unterbrechungsfreie Datenmigration von den ursprünglichen Arrays zu den neuen Arrays verwendet. Die Systeme, in diesem Fall die ESXi-Server und virtuellen Maschinen, wurden eingeschaltet und waren im gesamten Verlauf der Migration, wie in Abbildung 17 abgebildet, verfügbar. Abbildung 17. ESXi-Server, virtuelle Maschinen und Datenspeicher, die während der Migration verfügbar sind VPLEX Metro- Lösungskonfiguration Speicherstrukturen Abbildung 18 zeigt die physische und logische Speicherstruktur, die von VPLEX Metro im Zusammenhang mit dieser Lösung verwendet wurde. Es gibt eine 1:1-Zuordnung zwischen Speicher-Volumes, Extents und Geräte an jedem Standort. Alle Cluster-1-Geräte werden in einer verteilten RAID-1- Konfiguration remote auf Cluster-2 gespiegelt, um verteilte Geräte zu erstellen. Diese verteilten Geräte werden durch virtuelle Volumes verkapselt, die anschließend dem Host über Speicheransichten zur Verfügung gestellt werden. 27

28 Abbildung 18. Physische und logische VPLEX-Speicherstrukturen für die Lösung Consistency Groups Consistency Groups sind vor allem für Datenbanken und deren Anwendungen wichtig. Beispiel: Schreibreihenfolge: Um die Datenintegrität aufrechtzuerhalten, müssen alle Oracle-Datenbanken-LUNs (z. B. Daten-, Kontroll- und Protokolldateien) gemeinsam in einer Consistency Group abgelegt werden. Transaktionsabhängigkeit: Oftmals weisen mehrere Datenbanken Transaktionsabhängigkeiten auf, wie eine Anwendung, die mehrere Transaktionen an mehrere Datenbanken ausgibt und erwartet, dass die Datenbanken übereinstimmen. Alle LUNs, die erfordern, dass die I/O- Abhängigkeit aufrechterhalten wird, müssen sich in einer Consistency Group befinden. Anwendungsabhängigkeit: Oracle RAC behält die OCR (Oracle Cluster Registry) und Abstimmungsdateien innerhalb eines Verbunds von Festplatten bei, die zur Beibehaltung der Datenbankverfügbarkeit zugänglich sein müssen. Die Datenbank sowie die OCR-Festplatten müssen sich in einer Consistency Group befinden. Für die Lösung enthält eine synchrone Consistency Group Extended_Oracle_RAC_CG alle virtuellen Volumes mit Binärdateien der Oracle Database 11g, die Oracle ASM-Festplattengruppe und die OCR sowie die Abstimmungsdateien. In der Detach-Regel für die Consistency Group ist Cluster-1 der bevorzugte Cluster. 28

29 Konfigurationsprozess Für die Lösung werden die logischen VPLEX Metro-Speicherstrukturen wie folgt konfiguriert ( Abbildung 19bis Abbildung 23 zeigen Auszüge aus den Konfigurationsassistenten an, die von der VPLEX Management Console bereitgestellt werden): Speicher-Volume: Ein Speicher-Volume ist eine aus einem Array exportierte und von einer VPLEX verkapselte LUN. Abbildung 19 zeigt unterschiedliche Speicher-Volumes an, die an Standort A erstellt wurden, wie in der VPLEX Management Console angezeigt. Abbildung 19. EMC VPLEX-Speicher-Volumes (Standort A) Extent: In der Lösung gibt es eine 1:1-Zuordnung zwischen Extents und Speicher-Volumes wie in Abbildung 19 und Abbildung 20 dargestellt. Abbildung 20. EMC VPLEX-Assistent zur Extent-Erstellung Gerät: In der Lösung gibt es eine 1:1-Zuordnung zwischen Geräten und Extents. Abbildung 21 zeigt die Option an, die zur Konfiguration dieser 1:1- Zuordnung konfiguriert wurde. Abbildung 21. EMC VPLEX-Assistent zur Geräteerstellung Verteiltes Gerät: In der Lösung wurden die verteilten Geräte durch die Remotespiegelung eines Geräts in einer verteilten RAID-1-Konfiguration erstellt, wie in Abbildung 22 angezeigt. 29

30 Abbildung 22. EMC VPLEX-Assistent zur Geräteerstellung Virtuelles Volume: In der Lösung sind alle Geräte der obersten Ebene verteilte Geräte. Diese verteilten Geräte werden durch virtuelle Volumes verkapselt, welche die VPLEX dem Host anschließend über Speicheransichten zur Verfügung stellt. In den Speicheransichten wird definiert, welche Hosts an welchen VPLEX-Ports auf welche virtuellen Volumes zugreifen. Consistency Group: Abbildung 23 zeigt die Consistency Group an, die für die Lösung Extended_Oracle_RAC_CG erstellt wurde. Abbildung 23. EMC VPLEX-Assistent zur Consistency Group-Erstellung VPLEX Witness- Konfiguration Die Lösung nutzt VPLEX Witness, um die Konnektivität zwischen den zwei VPLEX- Clustern zu überwachen und eine weitere Verfügbarkeit für den Fall zu ermöglichen, dass ein Ausfall der Netzwerkpartition zwischen Clustern oder ein Clusterausfall vorliegt. Dies wird als eine VPLEX Metro-HA-Konfiguration betrachtet, da die Speicherverfügbarkeit am verbleibenden Standort sichergestellt wird. VPLEX Witness wird als eine dritte, separate Ausfall-Domain (Standort C) genutzt und mit den VPLEX-Clustern an Standort A und Standort B verbunden. Standort C ist mit einer Latenz von weniger als 1 Sekunde von den Standorten A und B entfernt. Wenn VPLEX Witness installiert und konfiguriert wurde, zeigt die VPLEX Management Console den Status der Witness-Clusterkomponenten, wie in Abbildung 24 dargestellt, an. 30

31 Abbildung 24. EMC VPLEX Witness-Komponenten und Status VPLEX-Performancemonitoring VPLEX 5.1 bietet ein erweitertes Performancemonitoring über das Performancemonitoring-Dashboard. Dieses Dashboard stellt eine anpassbare Ansicht zur Performance des VPLEX-Systems bereit und ermöglicht Ihnen, unterschiedliche Aspekte der Systemperformance bis zur Director-Ebene anzuzeigen und zu vergleichen. Viele unterschiedliche Kennzahlen sind derzeit verfügbar, einschließlich: Front-end-Latenzdiagramm Front-end-Bandbreitendiagramm Front-end-Durchsatzdiagramm CPU-Auslastungsdiagramm Diagramm zum Wiederherstellungsstatus WAN-Link-Performancediagramm Back-end-Latenzdiagramm Abbildung 25 zeigt die Front-end- und CPU-Performance in Cluster-1 an (der VPLEX an Standort A), wenn Oracle-Statistiken zur SAP VSE-Datenbank erfasst wurden. Abbildung 25. Dashboard für das VPLEX-Performancemonitoring 31

32 Virtualisierte VMware Infrastructure Einführung Überblick Für die Lösung werden die SAP-Anwendungsserver vollständig mit VMware vsphere 5 virtualisiert. In diesem Abschnitt wird die Virtualisierungsinfrastruktur beschrieben, die diese Komponenten und Optionen verwendet: VMware vsphere 5.0 Aktualisierung 1 VMware vcenter TM Server VMware vsphere vmotion VMware vsphere HA (High Availability) VMware vsphere Distributed Resource SchedulerTM (DRS) EMC PowerPath /VE für VMware vsphere Version 5.7 EMC Virtual Storage Integrator für VMware vsphere Version 5.1 VMware vsphere 5 VMware vsphere 5 ist die umfassendste, skalierfähigste und leistungsstärkste Virtualisierungsplattform der Branche. Sie bietet Infrastrukturservices, die die IT- Hardware in eine gemeinsame Computing-Plattform mit hoher Performance verwandeln, sowie Anwendungsservices, mit der IT-Abteilungen ein Höchstmaß an Verfügbarkeit, Sicherheit und Skalierbarkeit bereitstellen können. VMware vcenter Server VMware vcenter ist die zentralisierte Managementplattform für vsphere- Umgebungen, die auf jeder Ebene der virtuellen Infrastruktur Kontrolle und Sichtbarkeit bietet. VMware vsphere vmotion VMware vsphere vmotion ist eine VMware-Technologie, die eine Livemigration virtueller Maschinen über Server hinweg unterstützt, ohne dabei Anwender zu unterbrechen oder Services einzubüßen. Storage vmotion ist eine VMware-Technologie, die die Livemigration von Speicher einer virtuellen Maschine zulässt, ohne die Verfügbarkeit der virtuellen Maschine zu unterbrechen. Dies ermöglicht die Verlagerung von virtuellen Livemaschinen auf neue Datastores. VMware vsphere High Availability VMware vsphere HA (High Availability) ist eine vsphere-komponente, die für jede Anwendung auf einer virtuellen Maschine unabhängig vom Betriebssystem oder der zugrunde liegenden Hardwarekonfiguration eine hohe Verfügbarkeit bietet. VMware vsphere Distributed Resource Scheduler VMware vsphere DRS (Distributed Resource Scheduler) gleicht dynamisch und automatisch die Lastverteilung sowie die Platzierung der virtuellen Maschinen über mehrere ESXi-Server hinweg aus. 32

33 EMC PowerPath/VE EMC PowerPath/VE für VMware vsphere bietet PowerPath-Multipathing- Funktionen zur Optimierung von virtuellen VMware vsphere-umgebungen. PowerPath/VE PowerPath/VE wird als Kernelmodul auf dem ESXi-Host installiert und funktioniert als MPP (Multipathing-Plug-in), das erweiterte Pfadmanagementfunktionen für ESXi-Hosts bereitstellt. EMC Virtual Storage Integrator für VMware vsphere EMC VSI (Virtual Storage Integrator) für VMware vsphere ist ein Plug-in für VMware vsphere Client, das eine Managementoberfläche für das Management von EMC Speicher in der vsphere-umgebung bereitstellt. VSI bietet ein einheitliches und flexibles Anwendererlebnis, das eine individuelle Aktualisierung jeder einzelnen Funktion ermöglicht. Darüber hinaus können neue Funktionen entsprechend den wechselnden Kundenanforderungen schnell eingeführt werden. Bei der Installation von PowerPath/VE auf einem ESXi-Host stellt VSI den Geräten wichtige Multipathing-Details bereit, wie die Lastenverteilungs-Policy und die Anzahl der aktiven und inaktiven Pfade. VMware- Bereitstellungen auf VPLEX Metro EMC VPLEX Metro bietet einen gleichzeitigen Zugriff auf dieselbe Gerätegruppe an zwei physisch separaten Standorten und stellt somit die Aktiv/Aktiv-Infrastruktur bereit, die geografisch verteilte Cluster basierend auf VMware vsphere ermöglicht. Die Verwendung der Brocade-vLAG-Technologie (Virtual Link Aggregation Group) ermöglicht die Erweiterung von VLANs und somit von Subnetzen über unterschiedliche physische Rechenzentren hinweg. Durch die Bereitstellung von VMware vsphere-funktionen und -Komponenten zusammen mit VPLEX Metro kann die folgende Funktionalität erreicht werden: vmotion: Livemigration virtueller Maschinen zwischen Standorten im Vorfeld von geplanten Ereignissen wie der Hardwarewartung. Storage vmotion: Möglichkeit, den Speicher einer virtuellen Maschine zu migrieren, ohne dass dabei die Verfügbarkeit der virtuellen Maschine unterbrochen wird. Dies ermöglicht die Verlagerung von virtuellen Livemaschinen auf neue Datastores. VMware DRS: Automatische Lastverteilung und Platzierung der virtuellen Maschinen über Standorte hinweg unter Verwendung von DRS-Gruppen und Affinitätsregeln. VMware HA: Eine mit VPLEX Witness konfigurierte VPLEX Metro-Umgebung wird als VPLEX Metro HA-Konfiguration betrachtet, da sie die Speicherverfügbarkeit am verbleibenden Standort im Fall eines Ausfalls auf Standortebene sicherstellt. Durch die Kombination von VPLEX Metro HA mit einer Failover-Clustering-Technologie für Hosts wie VMware HA wird ein automatischer Anwendungsneustart für alle Katastrophen auf Standortebene ermöglicht. Abbildung 26 zeigt diese HA-Architektur an. 33

34 Abbildung 26. VMware HA mit VPLEX Witness logische Ansicht VPLEX Metro HA und clusterübergreifende Verbindung: Der Schutz des VMware HA-Clusters kann weiter verbessert werden, indem eine clusterübergreifende Verbindung zwischen den VMware ESXi-Servern und dem VPLEX-Cluster am Remotestandort hinzugefügt wird. Ereignisse, bei denen keine lokalen Daten zur Verfügung stehen, die jedoch nicht von VMware vsphere 5.0 erkannt werden, können bei einem Ausfall auftreten, der sich nicht auf den gesamten Standort bezieht. Clusterübergreifende vsphere-umgebungen zu VPLEX-Clustern schützen vor diesem Problem und stellen sicher, dass fehlgeschlagene virtuelle Maschinen automatisch auf den verbleibenden Standort verschoben werden. Die clusterübergreifende VPLEX-Verbindung ist bis zu einer Latenz von 1 ms verfügbar, die sich aufgrund der Entfernung ergibt. Diese Lösung nutzt VPLEX Metro HA mit clusterübergreifender Verbindung, um die Verfügbarkeit von virtuellen VMware-Maschinen, wie in Abbildung 27 dargestellt, zu maximieren. 1 1 Weitere Informationen erhalten Sie im EMC TechBook: EMC VPLEX Metro Witness Technology and High Availability. 34

35 Abbildung 27. VMware HA mit VPLEX Witness und grenzübergreifender Verbindung logische Ansicht Ausgedehnte VMware- Clusterkonfiguration VMware und EMC unterstützen eine ausgedehnte Clusterkonfiguration, die ESXi- Hosts von mehreren Standorten umfasst 2. Für die Lösung wird ein vsphere-cluster zwischen Standort A und Standort B ausgedehnt, indem ein verteiltes virtuelles VPLEX-Volume mit VMware HA und VMware DRS verwendet wird. Im Cluster gibt es vier Hosts, zwei an jedem Standort. Die clusterübergreifende Verbindung von VPLEX Metro HA bietet eine erhöhte Ausfallsicherheit für die Konfiguration. In vcenter können die Konfiguration dieses Clusters SiteAandSiteB und die hierzu aktivierten Funktionen, wie in Abbildung 28dargestellt, problemlos angezeigt werden. Darüber hinaus werden in dieser Ansicht der Speicher, die CPU und die Speicherressourcen angezeigt, die für den Cluster verfügbar sind. Abbildung 28. vsphere-cluster mit aktiviertem HA und DRS 2 Weitere Anforderungen und Szenarien erhalten Sie im VMware-Wissensdatenbankartikel : Using VPLEX Metro with VMware HA 35

36 Jeder ESXi-Server ist mit zwei physischen 10-GbE-Adaptern konfiguriert, um einen Netzwerk-Failover sowie eine hohe Performance zu ermöglichen. Ein verteilter vsphere-switch (dvswitch) 3 stellt einen allgemeinen Switch über alle Hosts bereit. Die physischen 10-GbE-Adapter (auch Uplink-Adapter bezeichnet) werden dem dvswitch zugeordnet. Dem dvswitch werden zwei verteilte Portgruppen zugeordnet: dvportgroupsiteab: Für den Netzwerkverkehr virtueller Maschinen Managementnetzwerk: Für VMkernel-Verkehr und insbesondere vmotion- Verkehr Abbildung 29 zeigt die dvswitch-konfiguration an. Da beide verteilten vsphere 5.0-Switches und Brocade VCS-Switches das LLDP (Link Layer Discovery Protocol) unterstützen, können die Eigenschaften der zugehörigen physischen Switches problemlos von vcenter identifiziert werden. Abbildung 29. dvswitch-konfiguration und LLDP-Detail Datastore EXT_SAP_VPLEX_DS01 wurde auf einem verteilten 1-TB-VPLEX-Volume erstellt und den ESXi-Hosts im ausgedehnten Cluster zur Verfügung gestellt. Alle virtuellen Maschinen wurden mithilfe von Storage vmotion zu diesem Datastore migriert, da sie virtuelle Laufwerke oder vmotion zwischen Standorten gemeinsam nutzen müssen. Abbildung 30 zeigt die Konfigurationsdetails für den Datastore an. 3 Ein dvswitch bietet eine Netzwerkkonfiguration, die alle Mitgliedshosts umfasst und virtuelle Maschinen zulässt, um eine konsistente Netzwerkkonfiguration bei deren Migration zwischen Hosts aufrechtzuerhalten. Weitere Informationen erhalten Sie im Dokument VMware vsphere Networking ESXi

37 Abbildung 30. Datastore EXT_SAP_VPLEX_DS01 sowie die zugehörigen Hosts und virtuellen Maschinen VMware vsphere HA-Konfiguration Aktivierung von VMware vsphere HA und VMware vsphere DRS vsphere HA nutzt mehrere ESXi-Hosts, die als Cluster konfiguriert sind, um eine schnelle Recovery nach Ausfällen sowie eine kosteneffektive hohe Verfügbarkeit für Anwendungen sicherzustellen, die in virtuellen Maschinen ausgeführt werden. 4 vsphere HA schützt folgendermaßen die Anwendungsverfügbarkeit: Es schützt vor einem Serverausfall, indem die virtuellen Maschinen auf anderen ESXi-Server im Cluster neu gestartet werden. Darüber hinaus schützt es vor Anwendungsausfällen, indem eine virtuelle Maschine konsistent überwacht und diese beim Ausfall eines Gast-BS neu eingerichtet wird. Für die Lösung wurde, wie in Abbildung 31 angezeigt, sowohl vsphere HA als auch DRS aktiviert. Abbildung 31. vsphere HA-Assistent 4 Weitere Informationen zu vsphere HA erhalten Sie im Dokument VMware vsphere Availability ESXi

38 VM-Monitoring VM-Monitoring wurde konfiguriert, um einzelne virtuelle Maschinen neu zu starten, falls ihr Heartbeat nicht innerhalb von 60 Sekunden empfangen wird. Neustartoptionen für virtuelle Maschinen Die VM Restart-Priority-Option für die vier virtuellen SAP-Maschinen wurde auf Hoch gesetzt. Dadurch wird sichergestellt, dass diese virtuellen Maschinen bei einem Ausfall zuerst eingeschaltet werden. Abbildung 32 zeigt diese Einstellung und die Host-Isolation-Response-Einstellung (Standard) an. Abbildung 32. VM Restart-Priority- und Host-Isolation-Response-Einstellungen Datastore Heartbeat Wenn Sie einen vsphere HA-Cluster erstellen wird ein einzelner Host automatisch als Master-Host gewählt. Der Master-Host überwacht den Status aller geschützten virtuellen Maschinen und der Slave-Hosts. Wenn der Master-Host nicht mit einem Slave-Host kommunizieren kann, nutzt er den Datastore Heartbeat, um festzustellen, ob sich der fehlgeschlagene Host in einer Netzwerkpartition oder einem isolierten Netzwerk befindet. Um die vsphere HA-Anforderungen für den Datastore Heartbeat zu erfüllen, wurde ein zweiter Datastore EXT_SAP_VPLEX_HA_HB auf einem verteilten 20-GB- VPLEX-Volume erstellt und allen ESXi-Hosts, wie in Abbildung 33 abgebildet, zur Verfügung gestellt. In einer Produktionsumgebung wählt vcenter automatisch zwei oder mehr Datastores für diesen Zweck basierend auf der Hostsichtbarkeit aus. Abbildung 33. vsphere HA Cluster-Status Heartbeat Datastores 38

39 VMware vsphere DRS-Konfiguration VMware DRS-Hostgruppen und virtuelle Maschinengruppen DRS-Hostgruppen und virtuelle Maschinengruppen vereinfachen das Management der ESXi-Hostressourcen. Diese Funktionen waren für diese Lösung nicht erforderlich. VMware DRS-Affinitätsregeln DRS nutzt Affinitätsregeln, um die Platzierung der virtuellen Maschinen auf Hosts in einem Cluster zu kontrollieren. DRS bietet zwei Arten von Affinitätsregeln: Eine VM-Hostaffinitätsregel gibt die Affinitätsbeziehung zwischen einer virtuellen Maschinengruppe und einer Hostgruppe an. Eine VM-VM-Affinitätsregel gibt an, ob bestimmte virtuelle Maschinen auf demselben Host ausgeführt oder sich auf unterschiedlichen Hosts befinden sollten. Tabelle 8 und Abbildung 34 zeigt die von der Lösung verwendete VM-VM- Affinitätsregel an. Tabelle 8. VMware DRS -Affinitätsregel VM-VM-Affinitätsregel SAPASCS Separat Führen Sie die virtuellen Maschinen SAPASCS2 und SAPASCS3 auf separaten Hosts aus. Abbildung 34. DRS VM-VM-Affinitätsregel für vplex_esxi_metro_ha-cluster. EMC Virtual Storage Integrator und VPLEX EMC VSI (Virtual Storage Integrator) bietet direkt über die vcenter GUI einen besseren Einblick in die VPLEX. Auf die Funktionen Storage Viewer und Pfadmanagement kann über die EMC VSI-Registerkarte, wie in Abbildung 35 dargestellt, zugegriffen werden. In der Lösung hosten verteilte VPLEX-Volumes den EXT_SAP_VPLEX_DS01 VMFS- Datastore (Virtual Machine File System) und Storage Viewer stellt Details zu virtuellen Volumes, Speicher-Volumes und Pfaden des Datastore bereit. 39

40 Wie in Abbildung 35 dargestellt, handelt es sich bei den LUNs, aus denen sich der Datastore zusammensetzt, um vier verteilte VPLEX Metro-Volumes mit RAID 1 und 256 GB, auf die über PowerPath zugegriffen werden kann. Abbildung 35. VSI Storage Viewer Datastores 40

41 SAP-Systemarchitektur Einführung Überblick In diesem Abschnitt wird die SAP-Systemarchitektur beschrieben, die für die Lösung in zwei Rechenzentren bereitgestellt wird. Die SAP-Anwendungsschicht nutzt die folgenden SAP- und SUSE-Komponenten: SAP-Anwendung SAP Enhancement Package 4 für SAP ERP 6.0 IDES SAP NetWeaver Application Server für ABAP 7.01 SAP Enqueue-Replikationsserver Betriebssystem SUSE Linux Enterprise Server for SAP Applications 11 SP1 SUSE Linux Enterprise High Availability Extension Das SAP-System wird in einer Hybridumgebung ausgeführt, in der sich die SAP- Services auf virtuellen Maschinen und die Datenbank auf physischen Servern befinden. Alle SAP-Instanzen werden auf virtuellen VMware vsphere-maschinen mit SUSE Linux Enterprise Server for SAP Applications als Betriebssystem installiert. Bei der zugrunde liegenden Datenbank handelt es sich um eine physische RAC-Datenbank auf ASM. Die VMware- und Oracle-Umgebungen werden in separaten Abschnitten des White Paper beschrieben (siehe Virtualisierte VMware Infrastructure und Oracle-Datenbankarchitektur ). SAP ERP 6.0 SAP ERP 6.0, die durch die SAP NetWeaver-Technologieplattform unterstützt wird, ist eine erstklassige, vollständig integrierte ERP-Anwendung (Enterprise Resource Planning), die die grundlegenden geschäftlichen Anforderungen von mittelständischen sowie Großunternehmen über alle Branchen und Marktsektoren hinweg erfüllt. SAP ERP 6.0 bietet eine Reihe von integrierten und funktionsübergreifenden Geschäftsprozessen und kann als solide Plattform für Geschäftsprozesse eingesetzt werden, die weiteres Wachstum, Innovation und Operational Excellence unterstützt. SAP IDES (Internet Demonstration and Evaluation System) unterstützt Demos, Tests und Funktionsbewertungen basierend auf vorkonfigurierten Daten und Clients. IDES umfasst Anwendungsdaten für unterschiedliche Geschäftsszenarien. Die darin enthaltenen Geschäftsprozesse werden entwickelt, um geschäftliche Anforderungen in Echtzeit widerzuspiegeln und Zugriff auf zahlreiche realistische Merkmale bereitzustellen. Diese Lösung nutzt IDES, um ein Modellunternehmen zu Testzwecken darzustellen. SUSE Linux Enterprise Server for SAP Applications SUSE Linux Enterprise Server ist ein äußerst zuverlässiges, skalierbares und sicheres Serverbetriebssystem, das zur Unterstützung physischer, virtueller und Cloudanwendungen entwickelt wurde. Sie stellt die bevorzugte Linux- Plattform für SAP dar. SUSE Linux Enterprise Server for SAP Applications, der auf der neuesten SUSE Linux Enterprise Server-Technologie basiert, wurde für alle geschäftskritischen SAP NetWeaver-Softwarelösungen und -Appliances optimiert. SAP und SUSE validieren und zertifizieren gemeinsam SUSE Linux Enterprise Server for SAP Applications, um mögliche Softwareinkompatibilitäten zu beseitigen. Diese Partnerschaft integriert den Anwendungs-Workload eng in das Betriebssystem und beseitigt mögliche Inkompatibilitäten bei der Anwendung von Patches auf Anwendungen oder das Betriebssystem. 41

42 SUSE Linux Enterprise High Availability Extension SUSE Linux Enterprise Server for SAP Applications enthält die SUSE Linux Enterprise High Availability Extension, die einen Service mit hoher Verfügbarkeit und Anwendungs-Clustering, Dateisysteme und Clusterdateisysteme, NAS (Network Attached Storage), Netzwerkdateisysteme, Volume-Manager, SAN und Treiber sowie die Mittel bereitstellt, damit all diese Komponenten zusammen funktionieren. SUSE Linux Enterprise High Availability Extension bietet eine integrierte Clustering-Lösung für physische und virtuelle Linux-Bereitstellungen, die die Implementierung von hoch verfügbaren Linux-Clustern ermöglichen und Single-Points-of-Failure beseitigen. SAP-Systemkonfiguration SAP-Systemarchitektur Die Lösung implementiert eine SAP-Systemarchitektur mit hoher Verfügbarkeit, wie in Abbildung 36 dargestellt. Abbildung 36. SAP-Systemarchitektur 42

43 Der Enqueue-Server und der Message-Server sind von der zentralen Instanz getrennt und als Services innerhalb der ASCS-Instanz implementiert 5. SAP ERS wird als Bestandteil der HA-Architektur installiert, um keine Verluste durch die Anwendungssperrung zu erzeugen und den Enqueue-Server weiter zu schützen 6. Zwei Dialoginstanzen sind installiert, um redundante Arbeitsprozesse wie Dialog (DIA), Hintergrund (BGD), Update (UPD), Spool (SPO) und Gateway bereitzustellen. Wichtige Designüberlegungen Das für die Lösung bereitgestellte SAP-System implementiert die folgenden wichtigen Designfunktionen: Die ASCS-Instanz wird mit einem virtuellen Hostnamen (SAPVIPE) installiert, um diesen vom virtuellen Maschinen-Hostnamen unterscheiden zu können. Die ERS-Instanz wird mit einer unterschiedlichen Instanzanzahl (01) installiert, um künftige Verwirrungen zu vermeiden, wenn ASCS und ERS vom Cluster kontrolliert werden. Patches, Parameter, grundlegende Einstellungen und Lastenausgleichs- Einstellungen für SAP werden alle gemäß dem SAP-Installationshandbuch und den SAP-Hinweisen auf Seite 73 installiert und konfiguriert. VMware Best Practices für SAP kommen in dieser Lösung zum Einsatz 7. SAP-Aktualisierungsprozesse (UPD/UP2) werden auf den zusätzlichen Anwendungsserver-Instanzen konfiguriert. SAP ASCS-Instanzprofile, ERS-Instanz- und Startprofile sowie Dialoginstanzprofile werden mit ERS-Konfigurationen aktualisiert. Siehe Anhang: Beispielkonfigurationen für Beispielkonfigurationen. Gemeinsame SAP-Dateisysteme, einschließlich /sapmnt/<sid> (für alle SAP- Instanzen verfügbar) und /usr/sap/<sid>/ascs00 (für SAP-Cluster-Nodes, ASCS-Instanz und ERS-Instanz verfügbar), werden im Oracle ACFS (ASM Cluster File System) gespeichert und als NFS-Shares (Network File System) bereitgestellt. Diese gemeinsamen Dateisysteme werden als hoch verfügbare NFS-Ressource zur Verfügung gestellt, die durch die Oracle Clusterware gemanagt wird. Einige IDES-Funktionen, z. B. die Synchronisation mit dem externen GTS- System, sind deaktiviert, um unnötige externe Schnittstellen zu vermeiden, die nicht im Leistungsumfang der Lösung enthalten sind. Der Speicher für die gesamte SAP-Umgebung ist für diese Lösung verkapselt und virtualisiert. Der Speicher wird über die zwei Standorte hinweg verteilt und den SAP-Servern über VPLEX Metro zur Verfügung gestellt. 5 Der Enqueue-Server managt logische Sperrungen. Dabei besteht seine Zielsetzung darin, die Dauer der Datenbanksperrung zu minimieren. Im Gegensatz zu Datenbanksperrungen kann eine SAP-Sperrung über verschiedene Datenbank-LUWs auftreten. Der Message- Server informiert alle Server (Instanzen) in einem SAP-System über die Existenz der anderen Server. Andere Clients (z. B. SAPlogon- und RFC-Clients mit Lastenausgleich) können ihn ebenfalls kontaktieren, um Informationen zum Lastenausgleich zu erhalten. 6 SAP ERS bietet einen Replikationsmechanismus für den Enqueue-Server, indem eine Kopie der Sperrtabelle in seinem freigegebenen Speichersegment aufbewahrt wird. Die ERS-Installation für Linux ist nicht Bestandteil des standardmäßigen SAPInst-Prozesses. Installationsanweisungen erhalten Sie im Hilfeportal des SAP Enqueue-Replikationsserver unter help.sap.com. 7 Details finden Sie unter: SAP Solutions on VMware: Best Practices Guide. 43

44 SUSE Linux Enterprise High Availability Extension- Konfiguration Die SAP-Struktur der virtuellen Maschinen mit SUSE Linux Enterprise High Availability Extension Die Lösung verwendet die SUSE Linux Enterprise High Availability Extension, um zentrale Services (Message-Server und Enqueue-Server) über zwei Cluster-Nodes hinweg zu schützen, die in virtuellen VMware-Maschinen integriert sind. VMware HA (High Availability) schützt alle virtuellen SAP-Maschinen, einschließlich ASCS und den zusätzlichen Anwendungsserver. Abbildung 37 zeigt diese Architektur. Abbildung 37. SAP ASCS-Clusterarchitektur mit SUSE Linux Enterprise HAE Zu den wichtigsten Komponenten, die in SUSE Linux Enterprise High Availability Extension implementiert sind, zählen: OpenAIS 8 /Corosync 9, ein Cluster-Manager mit hoher Verfügbarkeit, der ein Multi-Node-Failover unterstützt. Ressourcen-Agent (virtuelle IP-Adresse, Master/Slave und SAP-Instanz), um die Verfügbarkeit der Ressourcen zu überwachen und zu kontrollieren. GUI mit hoher Verfügbarkeit und zahlreichen Befehlszeilentools 8 OpenAIS ist eine offene Implementierung der AIS (Application Interface Specification), die vom SA-Forum (Service Availability) bereitgestellt wird. 9 Die Corosync Cluster Engine ist ein Kommunikationssystem für Gruppen mit zusätzlichen Funktionen zur Implementierung einer hohen Verfügbarkeit in Anwendungen. 44

45 Tabelle 9 zeigt die Konfiguration der virtuellen SAP-Maschinen. Tabelle 9. Virtuelle SAP-Maschinen VM-Rolle Menge vcpus Arbeitsspeicher (GB) OS-Startlaufwerk (GB) VM-Name SAP ASCS SAPASCS2 SAP ERS SAPASCS3 SAP AAS SAPDI SAPDI2 Installations- und Konfigurationsprozess Im White Paper Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack für SUSE wird beschrieben, wie die SUSE- Software und SAP NetWeaver installiert und konfiguriert werden. Anhang: Beispielkonfigurationen bietet eine Beispiel-Konfigurationsdatei zur Unterstützung der Funktionen und Funktionalitäten, die von dieser Lösung validiert werden. Sie sollten die Zeitwerte (Timeout, Intervall usw.) in diesem Fall als Anfangs -Werte betrachten, die Sie auf Ihre spezielle Umgebung abstimmen und optimieren können. Für die Lösung wurde SUSE Linux Enterprise High Availability Extension mit der YaST und Pacemaker GUI installiert und konfiguriert. Im Folgenden erhalten Sie eine Zusammenfassung des Installations- und Konfigurationsprozesses: 1. Richten Sie einen internen SMT-Server (aus Sicherheitsgründen) ein, um alle Softwarepakete auf die aktuellen Versionen zu aktualisieren. 2. Wählen Sie im YaST-Softwaremanagementmodul Patterns (Muster) > High Availability (Hohe Verfügbarkeit) aus, um die High Availability Extension, wie in Abbildung 38 dargestellt, zu installieren. 45

46 Abbildung 38. Installieren der SUSE Linux Enterprise High Availability Extension 3. Konfigurieren Sie im YaST-Clustermodul die grundlegenden Clustereinstellungen, wie in Abbildung 39 dargestellt. Abbildung 39. Konfigurieren der grundlegenden Clustereinstellungen 4. Konfigurieren Sie in der Pacemaker GUI die globalen Clustereinstellungen wie in Abbildung 40 dargestellt. 46

47 Abbildung 40. Konfigurieren globaler Clustereinstellungen 5. Ö ffnen Sie in der Pacemaker GUI die Kategorie Resources (Ressourcen) und konfigurieren Sie IPaddr2, Master/Slave und SAP-Instanzressourcen wie in Abbildung 41 dargestellt. Abbildung 41. Konfigurieren von Ressourcen 47

48 6. Konfigurieren Sie in der Pacemaker GUI die Abhängigkeiten der Ressource wie in Abbildung 42 dargestellt. Abbildung 42. Konfigurieren von Ressourcenabhängigkeiten 7. Starten Sie in der Pacemaker GUI den Cluster und prüfen Sie, ob der Cluster und alle Ressourcen-Agents, wie in Abbildung 43 dargestellt, normal funktionieren. Abbildung 43. Überprüfen des Clusterstatus 48

49 Wichtige Designüberlegungen STONITH-Gerätekonfiguration SBD (STONITH-Block-Device) und STONITH (Shoot The Other Node In The Head) ermöglichen die Ausgrenzung (Isolierung der Nodes) in einem Cluster mit gemeinsamem Speicher. Diese Lösung nutzt eine virtuelle Laufwerkspartition als ein SBD-STONITH-Gerät. 10 Aus diesem Grund benötigen beide Cluster-Nodes einen gleichzeitigen Zugriff auf dieses virtuelle Laufwerk. Das virtuelle Laufwerk wird im selben Datastore wie die virtuellen SAP-Maschinen gespeichert. Dieser Vorgang wird durch die VPLEX bereitgestellt und geschützt und ist an beiden Standorten verfügbar. Standardmäßig hindert VMFS mehrere virtuelle Maschinen daran, auf denselben VMDK zuzugreifen und zu schreiben. Sie können jedoch die Freigabe durch die Konfiguration der Multi-Writer-Option, 11 wie in Abbildung 44 dargestellt, konfigurieren. Abbildung 44. Multi-Writer-Option Das SBD-Gerät wird durch die VPLEX geschützt und ist über die EMC PowerPath/VE-Multipath-Software zugänglich. Die Timeout-Parameter für das SBD-Gerät müssen entsprechend konfiguriert werden, um den zugrunde liegenden Oracle RAC-Cluster-Timeout sowie den VLEX-Isolationsprozess zu berücksichtigen. Abbildung 45 zeigt die für diese Lösung verwendete Konfiguration an. 10 SBD ist ausschlaggebend für die Behandlung von Split-Brain-Szenarien im Cluster. Ein SBD- Gerät ist für diese Lösung konfiguriert. Diese SBD-Gerätekonfiguration dient nur zu Testzwecken; Informationen zur Produktionskonfiguration erhalten Sie im Dokument Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack. 11 Ausführliche Informationen erhalten Sie im VMware-Wissensdatenbankartikel : Disabling simultaneous write protection provided by VMFS using the multiwriter flag. 49

50 Abbildung 45. SBD-Gerätekonfiguration Master/Slave-Konfiguration Der SAPInstance-Ressourcen-Agent kontrolliert die ASCS-Instanz sowie die entsprechende ERS-Instanz. Er wird als Master/Slave-Ressource konfiguriert, die die Rolle der Ressource von gestartet und beendet auf Master und Slave erweitert. Eine hochgestufte Master-Instanz startet die SAP ASCS-Instanz. Die heruntergestufte Slave-Instanz startet die ERS-Instanz. Der Master/Slave-Modus stellt sicher, dass eine ASCS-Instanz niemals auf demselben Node wie das ERS gestartet wird. Abbildung 46 zeigt die Konfiguration des SAPInstance-Ressourcen-Agent an. Abbildung 46. Konfiguration des SAPInstance-Ressourcen-Agent Abbildung 47 zeigt die Konfiguration des Master/Slave-Ressourcen-Agent an Abbildung 47. Konfiguration des Master/Slave-Ressourcen-Agent 50

51 Ressourcenbeschränkungen Die ASCS-Instanz und ihre virtuelle IP werden anhand entsprechender Beschränkungen in Bezug auf Reihenfolge und Colocation miteinander verbunden. Abbildung 48 zeigt die Konfiguration der Beschränkungen in Bezug auf Ressourcen-Colocation und Ressourcen-Reihenfolge an. Abbildung 48. Konfiguration der Beschränkungen in Bezug auf Ressourcen-Colocation und Ressourcen-Reihenfolge Abfragekonzept SUSE Linux Enterprise High Availability Extension kann den Status von SAP- Prozessen in jedem Cluster-Node kontinuierlich überwachen und die richtigen Entscheidungen treffen, um die ASCS-Instanz sowie die ERS-Instanz entsprechend hoch- oder herunterzustufen. Es muss kein SAP-Abfragekonzept implementiert werden. Stellen Sie sicher, dass diese Funktion im ERS-Instanzprofil NICHT aktiviert ist. In Beispiel: ERS- Instanzprofil auf Seite 76 erhalten Sie ein Beispiel für ein ERS-Instanzprofil. 51

52 Oracle-Datenbankarchitektur Einführung Überblick In diesem Abschnitt werden das Raster und die Datenbank beschrieben, die den SAP-Anwendungen in der Lösung zugrunde liegen. Die Datenbank ging aus der Instanz einer physischen Oracle Database 11g hervor. Um den Datenbankserver als Single-Point-of-Failure auszuschließen, wurde die Datenbank mit einer Instanz zu einem physischen Oracle RAC 11g-Cluster mit vier Nodes migriert, wobei sich die Oracle-Datenbank auf einem ASM befindet. Die Lösung nutzt die folgenden Oracle-Komponenten und -Optionen: Oracle Database 11g Release 2 Enterprise Edition Oracle ASM (Automatic Storage Management) und Oracle ACFS (ASM Cluster File System) Oracle Clusterware Oracle RAC (Real Applications Clusters) 11g on Extended Distance Clusters Oracle Database 11g R2 Oracle Database 11g Release 2 Enterprise Edition bietet eine branchenführende Performance, Skalierbarkeit, Sicherheit und Zuverlässigkeit mit der Auswahl von Cluster- oder Einzel-Servern, die auf Windows, Linux oder UNIX ausgeführt werden. Sie bietet umfassende Funktionen für Transaktionsverarbeitungs-, Business- Intelligence- und Contentmanagementanwendungen. Oracle ASM und Oracle ACFS Oracle ASM ist ein integriertes, clusterbezogenes Datenbankdateisystem sowie eine Datenträgermanagement. ASM-Dateisystem- und Volume- Managementfunktionen sind im Oracle-Datenbankkernel integriert. In Oracle Database 11g R2 wurde Oracle ASM zudem erweitert, um Support für OCR und Abstimmungsdateien zu bieten, die innerhalb von ASM-Festplattengruppen platziert werden. Oracle ACFS, eine Funktion innerhalb von ASM in der Oracle Database 11g, erweitert die ASM-Funktion, damit diese wie ein Clusterdateisystem für allgemeine Zwecke fungiert. Auf ACFS können sich nicht nur Binärdateien der Oracle-Datenbank befinden, sondern auch unterstützende Dateien, z. B. Traceund Warnmeldungsprotokolle, sowie nicht von Oracle stammende Anwendungsdateien wie SAP ERP. Nicht von Oracle stammende Server können auf ACFS-Volumes anhand von branchenführenden NAS-Protokollen wie NFS und CIFS (Common Internet File System) zugreifen. Oracle Clusterware Oracle Clusterware ist eine portable Clustermanagementlösung, die in der Oracle- Datenbank integriert ist. Sie stellt die Infrastruktur bereit, die zur Ausführung von Oracle RAC, einschließlich Clustermanagementservices und Hochverfügbarkeitsservices erforderlich ist. Eine nicht von Oracle stammende Anwendung kann mit hoher Verfügbarkeit auch über den Cluster hinaus mithilfe der Oracle Clusterware bereitgestellt werden. 52

53 Oracle Grid-Infrastruktur In der Oracle Database 11g R2 kombiniert die Oracle Grid-Infrastruktur Oracle ASM und die Oracle Clusterware getrennt von der Datenbanksoftware in einem Satz mit Binärdateien. Diese Infrastruktur stellt nun alle Cluster- und Speicherservices bereit, die zur Ausführung einer Oracle RAC-Datenbank erforderlich sind. Oracle Real Application Clusters 11g Oracle RAC ist in erster Linie eine Lösung mit hoher Verfügbarkeit für Oracle- Datenbankanwendungen innerhalb des Rechenzentrums. Sie ermöglicht mehreren Oracle-Instanzen auf eine Datenbank zuzugreifen. Der Cluster besteht aus einer Gruppe von unabhängigen Servern, die als ein System zusammenarbeiten und denselben Satz an Speicherfestplatten verwenden. Jede Instanz wird auf einem separaten Server im Cluster ausgeführt. RAC kann hohe Verfügbarkeit, Skalierbarkeit, Fehlertoleranz, Lastverteilung und Performancevorteile bereitstellen und beseitigt alle Single-Point-of-Failure aus der Datenbanklösung. Oracle RAC on Extended Distance Clusters Oracle RAC on Extended Distance Clusters (Oracle Extended RAC) ist eine Architektur, die ermöglicht, dass sich die Server im Cluster an physisch getrennten Standorten befinden können. Dadurch entfällt das Rechenzentrum als Single-Point-of-Failure. Oracle Extended RAC ermöglicht, dass alle Nodes im Cluster, ungeachtet des Standorts, aktiv sein können. Sie bietet wie folgt eine hohe Verfügbarkeit und Business Continuity bei einem Standort- oder Netzwerkausfall: Speicher und Daten sind am verbleibenden Standort weiterhin verfügbar und aktiv. Lastverteilung und Failover von Oracle-Services auf Oracle RAC-Nodes am verbleibenden Standort. Oracle TAF (Transparent Application Failover) ermöglicht, dass Sitzungen automatisch einen Failover auf Oracle RAC-Nodes am verbleibenden Standort ausführen. Drittanbieteranwendungen, die der Kontrolle der Oracle Clusterware unterliegen, können einen Lastenausgleich sowie ein Failover auf die Oracle RAC-Nodes am verbleibenden Standort ausführen z. B. NFS oder Apache httpd. Oracle RAC-Nodes am verbleibenden Standort verarbeiten weiterhin Transaktionen. Oracle empfiehlt, die Oracle Extended RAC-Architektur anzuwenden, wenn zwei Rechenzentren relativ nahe beieinander liegen (nicht mehr als 100 km entfernt) Lesen Sie sich das folgende White Paper von Oracle durch: Oracle Real Application Clusters (RAC) on Extended Distance Clusters. 53

54 Oracle RAC und VPLEX Oracle ACFS- Konfiguration Oracle RAC wird in der Regel in einem lokalen Rechenzentrum ausgeführt. Dies hängt mit den Auswirkungen, die sich aufgrund einer auf die Entfernung zurückzuführenden Latenz ergeben, sowie mit der relativen Komplexität und dem Overhead zusammen, die eine Ausweitung von Oracle RAC über Rechenzentren hinweg mit sich bringt. Diese Ausweitung erfolgt als hostbasierte Spiegelung mit Oracle ASM. Mit EMC VPLEX Metro verändert sich eine Oracle Extended RAC- Bereitstellung aus der Perspektive der Oracle DBA in eine standardmäßige Oracle RAC-Installation und -Konfiguration 13. Diese Lösung nutzt vier ACFS-Volumes, die über den Oracle RAC-Cluster, wie in Tabelle 10 dargestellt, gemountet werden. Drei dieser Volumes, SAPMNT, USRSAPTRANS und ASCS00, wurden anschließend als NFS-Shares an die SAP- Server mit einer virtuellen IP-Adresse und einer NFS-Ressource mit hoher Verfügbarkeit exportiert, die von der Oracle Clusterware kontrolliert wird. Tabelle 10. Oracle ACFS-Volumes und Mount-Punkte ACFS-Volume Größe (GB) Mount-Punkt Beschreibung SAP_O_HOME 16 /oracle/vse/112 ORACLE_HOME für Datenbank-VSE wird auf allen Oracle RAC-Nodes gemeinsam genutzt SAPMNT 16 /sapmnt/vse Globales SAP-Verzeichnis, das Speicherkernel und -profile speichert wird auf allen virtuellen SAP-Maschinen gemeinsam genutzt USRSAPTRANS 16 /usr/sap/trans SAP-Transportverzeichnis, in dem die Transportdateien gespeichert werden wird auf allen virtuellen Maschinen von SAP Dialog Instance gemeinsam genutzt ASCS00 16 /usr/sap/vse/ascs0 0 SAP ASCS-Instanzverzeichnis, in dem die instanzbezogenen Dateien gespeichert werden wird auf SUSE Linux Enterprise High Availability Extension-Cluster-Nodes gemeinsam genutzt 13 Lesen Sie sich das folgende White Paper von EMC durch: Oracle Extended RAC mit EMC VPLEX Metro Best Practices Planning. 54

55 Oracle Extended RAC on VPLEX Metro Abbildung 49 bietet eine logische Darstellung der Oracle Extended RAC on VPLEX Metro-Bereitstellung für die Lösung. Abbildung 49. Oracle Extended RAC over EMC VPLEX Metro Konfiguration der Oracle ASM- Laufwerkgruppe Tabelle 11 zeigt das Layout und die Konfiguration der ASM-Laufwerkgruppe an. Tabelle 11. Größe und Konfiguration der Oracle ASM-Laufwerkgruppe ASM- Laufwerkgruppe* Anzahl der Laufwerke Laufwerkgruppengröße (GB) Redundanz OCR 5 40 Normal EA_SAP_ACFS 4 64 Extern EA_SAP_DATA Extern EA_SAP_REDO 4 64 Extern EA_SAP_REDOM 4 64 Extern EA_SAP_FRA Extern * Das Präfix EA_SAP_ wird verwendet, um die ASM-Laufwerkgruppen in Bezug auf die SAP- Anwendung in Extended Oracle RAC eindeutig zu identifizieren. 55

56 Herstellen einer Verbindung zu Oracle RAC über SAP Damit SAP eine Verbindung zur Oracle RAC-Datenbank herstellen kann, wurde tnsnames.ora auf allen virtuellen SAP-Maschinen (SAPDI1 und SAPDI2), wie in Abbildung 50 dargestellt, abgelegt. VSE.WORLD= (DESCRIPTION = (LOAD_BALANCE = OFF) (FAILOVER = ON) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = sse-ea-erac-scan-c01.sse.ea.emc.com) (PORT = 1521) ) ) (CONNECT_DATA = ) ) (SERVICE_NAME = VSE.sse.ea.emc.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC)) Abbildung 50. Beispieleintrag der tnsnames.ora-datei für die Oracle RAC-Datenbank Bei TAF (Transparent Application Failover) handelt es sich um eine clientseitige Funktion, mit der Clients beim Ausfall einer Datenbankinstanz mit noch funktionierenden Instanzen verbunden werden können. TAF kann entweder über eine clientseitig angegebene Verbindungszeichenfolge oder über serverseitige Serviceattribute konfiguriert werden. Bei der Lösung wurde der Datenbankservice VSE.sse.ea.emc.com auf Oracle RAC für TAF konfiguriert. Er wurde außerdem clientseitig so konfiguriert, dass für SAP ebenfalls TAF aktiviert wurde. TAF wurde so eingerichtet, dass beim Failover Verbindungen hergestellt werden und Anwender nach dem Fehlschlagen bestimmter Vorgänge ihre geöffneten Cursor weiterhin für den Datenabruf verwenden können. 56

57 Brocade-Netzwerkinfrastruktur Einführung Überblick In diesem Abschnitt werden die für die Lösung in den beiden Rechenzentren bereitgestellten IP- und SAN-Netzwerke sowie die Layer-2-Erweiterung zwischen den Rechenzentren beschrieben. Die Netzwerkinfrastruktur wird mit den folgenden Brocade-Komponenten aufgebaut: IP-Netzwerk Brocade VDX 6720-Switches für die Rechenzentren Router der Brocade MLX-Serie Brocade 1020-CNAs SAN Brocade DCX 8510-Backbones Brocade 825-HBAs Brocade VDX 6720 Der Brocade VDX 6720 ist ein leistungsfähiger 10-GbE-Switch für Rechenzentren mit besonders niedriger Latenz, Kabelgeschwindigkeit und fester Portanzahl. Er wurde insbesondere für eine verbesserte Netzwerkauslastung, maximale Anwendungsverfügbarkeit, erhöhte Skalierbarkeit und deutlich vereinfachte Netzwerkarchitektur in virtualisierten Rechenzentren entwickelt. Der Brocade VDX 6720 ist mit zahlreichen Layer-2-Funktionen eine ideale Plattform für herkömmliche Top-of-Rack-(ToR-)Switch-Bereitstellungen. Mit der Fabric-Technologie Brocade VCS ermöglicht der Brocade VDX 6720 Unternehmen den Aufbau von Ethernet-Fabrics im Rechenzentrum. Dieses innovative Design von Layer-2-Netzwerken bildet eine intelligente Grundlage für cloudoptimierte Rechenzentren. Brocade MLX-Serie Die Router der Brocade MLX-Serie sind mit branchenführender 100-GbE-, 10-GbEund 1-GbE-Kabelgeschwindigkeit, IPv4, IPv6, Multi-VRF, MPLS (Multiprotocol Label Switching), Trägerethernetfunktionen und erweitertem Layer-2-Switching auf cloudoptimierte Netzwerke ausgelegt. Mit der Brocade MLX-Serie können geschäftskritische Rechenzentren mehr Datenverkehr verarbeiten, ein höheres Maß an Virtualisierung realisieren und wertvolle cloudbasierte Services in einer schlankeren Infrastruktur bereitstellen. So lassen sich gleichzeitig Prozesse vereinfachen und Kosten einsparen. Darüber hinaus kann die Brocade MLX-Serie die Komplexität großer Unternehmensnetzwerke durch Zusammenfassen von Kern und Aggregationsschicht reduzieren und die Konnektivität zwischen Standorten über MPLS/VPLS ermöglichen. Alle Router der Brocade MLX-Serie tragen mit dem niedrigsten Stromverbrauch und der geringsten Wärmeabgabe ihrer Klasse außerdem zur Einsparung von Energie- und Kühlkosten bei. Die Router der Brocade MLX-Serie sind auf dauerhaftes Networking ausgelegt und bieten mit MCT (Multi-Chassis Trunking) eine Bandbreite von mehr als 30 TB/s, Aktiv/Aktiv-Routing-Links und unterbrechungsfreien Datenverkehrsfluss im Fall eines Node-Failover. Durch vollständig redundante Switch-Fabrics, Managementmodule, Stromversorgungen und Kühlsysteme können Unternehmen eine hohe Ausfallsicherheit erreichen. Das Betriebssystem Brocade IronWare ermöglicht außerdem Management-Failover und Softwareupgrades ohne Anwendereingriff und trägt somit zu einer noch höheren Netzwerk- und Anwendungsverfügbarkeit bei. 57

58 Brocade DCX 8510-Backbone Zusammen mit den Anforderungen von hochgradig virtualisierten Umgebungen und Private Cloud-Architekturen müssen auch die Netzwerke wachsen. FC (Fibre- Channel) ist heute de facto der Standard für Speichernetzwerke im Rechenzentrum. Mit 16-Gb/s-Fibre-Channel ist diese robuste, zuverlässige und leistungsfähige Technologie für die Zukunft gerüstet. So können Unternehmen ihre vorhandenen IT-Investitionen nutzen, um komplexe geschäftliche Herausforderungen zu lösen. Brocade DCX 8510-Backbones bilden als Herzstück der leistungsstärksten 16-Gb/s-Fibre-Channel-Switching-Infrastruktur der Branche die zuverlässigste, skalier- und leistungsfähigste Grundlage für Private Cloud-Speicher und hochgradig virtualisierte Umgebungen. Neben einer höheren geschäftlichen Flexibilität bieten sie jederzeit Zugriff auf Informationen und tragen zur Senkung der Infrastruktur- und Administrationskosten bei. Die 16-Gb-FC-Funktion des Brocade DCX 8510 bietet besondere Vorteile für die SAN-Metro-Konnektivität zwischen Rechenzentren: 16-Gb-FC ermöglicht den höchsten Durchsatz und die niedrigste Latenz für Bereitstellungen mit Fibre-Verbindungen zwischen Rechenzentren. Optionale 10-Gb-FC-Leitungsgeschwindigkeit ermöglicht optimale Leitungsauslastung bei Bereitstellung eines DWDM-Netzwerks zwischen zwei Standorten. Für diese Funktion ist eine Lizenz erforderlich. Optionales ISL-Trunking (Inter-Switch Link) auf Frame-Ebene ermöglicht eine höhere Auslastung als Standard-DPS-Trunking. Für diese Funktion ist eine Lizenz erforderlich. Optionale Komprimierung der ISLs zwischen den Rechenzentren. Diese Funktion bietet zusätzliche Bandbreite bei Bereitstellungen mit begrenzten Verbindungen zwischen Standorten. Optionale In-Flight-Datenverschlüsselung für die ISLs zwischen den Rechenzentren für Bereitstellungen mit sehr hohen Anforderungen an die Datensicherheit. Verlusterkennung und -Recovery bei Freigaben von Puffer zu Puffer. Automatische FEC (Forward Error Correction, Vorwärtsfehlerkorrektur) korrigiert proaktiv bis zu 11 Bitfehler pro 2112-Bit-FC-Frame. Diagnosemodus für die ISL-Ports zwischen Rechenzentren über alle (Offline-) ISL-Ports bietet folgende Funktionen: Elektrische und optische Loopback-Tests Linksättigungstests Messgenauigkeit des Linkabstands innerhalb von 5 m (8 Gb SFP+) bzw. 50 m (10 GbE SFP+) 58

59 IP-Netzwerkkonfiguration Für die Lösung wird das IP-Netzwerk in jedem Rechenzentrum mit zwei Brocade VDX 6720-Switches in einer VCS-Konfiguration aufgebaut. Alle Server werden über redundante 10-GbE-Verbindungen mittels Brocade 1020-CNAs mit dem Netzwerk verbunden. Die Brocade VDX-Switches an den beiden Standorten werden über eine vlag (Virtual Link Aggregation Group, virtuelle Link-Zusammenfassungsgruppe) mit einem Router der Brocade MLX-Serie verbunden. Die Router der Brocade MLX- Serie erweitern das Layer-2-Netzwerk zwischen den beiden Rechenzentren. Hinweis Eine vlag ist ein Fabric-Service, der eine LAG (Link Aggregation Group, Link-Zusammenfassungsgruppe) mit mehreren Brocade VDX-Switches als Quelle ermöglicht. Genau wie eine Standard-LAG steuert eine vlag über das LACP (Link Aggregation Control Protocol) die Zusammenstellung mehrerer physischer Ports zu einem logischen Kanal. Oracle RAC nutzt eine hochverfügbare virtuelle IP (HAIP oder RAC Interconnect) für die private Netzwerkkommunikation. HAIP ermöglicht den Lastenausgleich des Interconnect-Datenverkehrs zwischen den Schnittstellen des privaten Netzwerks. Bei der Lösung wird ein separates VLAN, VLAN 10, für die Interconnect- Verbindung verwendet. VLAN 20 verarbeitet den gesamten öffentlichen Datenverkehr. Der gesamte Datenverkehr zwischen Standort A und Standort B wird über die Brocade MLX-Router weitergeleitet, wobei mehrere, als eine LAG konfigurierte Ports genutzt werden. Abbildung 51 zeigt die IP-Netzwerkinfrastruktur. Abbildung 51. Die IP-Netzwerke der Lösung 59

60 SAN-Netzwerkkonfiguration Das SAN in jedem Rechenzentrum wird mit Brocade DCX 8510-Backbones aufgebaut, wie in Abbildung 52 dargestellt. Alle Server werden über redundante 8-Gb-Verbindungen, die über Brocade 825-HBAs bereitgestellt werden, mit dem SAN verbunden. Für die VPLEX-zu-VPLEX-Verbindung zwischen den Rechenzentren werden mehrere FC-Verbindungen zwischen den Brocade DCX 8510-Backbones genutzt. Dies geschieht im Aktiv/Aktiv-Modus mit Failover. Abbildung 52. Die SAN-Netzwerke der Lösung 60

61 Hohe Verfügbarkeit und Business Continuity: Tests und Validierung Einführung Ausfall des SAP Enqueue- Serviceprozesses Das Validierungsteam von EMC hat die Umgebung zunächst ohne Maßnahmen zum Schutz von hoher Verfügbarkeit oder Business Continuity installiert und validiert. Anschließend wurde die Umgebung in die in diesem White Paper beschriebene geschäftskritische Business-Continuity-Lösung umgewandelt. Anhand der folgenden Tests konnte die Lösung validiert und die Beseitigung aller Single-Points-of-Failure aus der Umgebung dokumentiert werden: Ausfall des SAP Enqueue-Serviceprozesses Ausfall der virtuellen Maschine der SAP ASCS-Instanz Ausfall des Oracle RAC-Node Systemausfall am Standort Isolierung des VPLEX-Clusters Testszenario In diesem Testszenario wird validiert, dass bei einem Ausfall des Enqueue- Serviceprozesses das SUSE Linux Enterprise High Availability Extension-Cluster die SAP ERS-Instanz zu einer voll funktionsfähigen ASCS-Instanz hochstuft und die Sperrtabelle ohne Unterbrechungen für die Anwender übernimmt. Um dieses Fehlerszenario zu testen, wurde der Enqueue-Prozess auf dem aktiven ASCS-Node über den folgenden Kill-Befehl beendet: kill -9 <Prozess-ID> Systemverhalten Das System reagiert wie folgt auf den Ausfall des Enqueue-Serviceprozesses: 1. Der SAPInstance-Ressourcen-Agent erkennt und meldet den Ausfall, wie in Abbildung 53 gezeigt. Abbildung 53. SAPInstance-Ressourcen-Agent erkennt und meldet Ausfall 61

62 2. Der Master/Slave-Ressourcen-Agent stuft den vorherigen Slave-Node (SAPASCS2) zum Master-Node (Host der ASCS-Services) hoch und startet den ERS als Slave auf dem anderen Node (SAPASCS3), sobald dieser wieder dem Cluster beitritt (siehe Abbildung 54). Abbildung 54. Master/Slave-Ressourcen-Agent wechselt Master- und Slave-Node 3. Die replizierte Sperrtabelle wird wiederhergestellt, wie in Abbildung 55 gezeigt. Abbildung 55. Replizierte Sperrtabelle wiederhergestellt Ergebnis Der Anwender nimmt den Ausfall des Enqueue-Prozesses nur wahr, wenn ein Enqueue-Vorgang ausgeführt wird. In diesem Fall beobachtet der Anwender eine längere Antwortdauer der Transaktion während des Wechsels. Neue Anwender können sich sofort nach dem Wechsel des Message-Servers beim System anmelden. Hierzu ist kein administrativer Eingriff erforderlich. 62

63 Ausfall der virtuellen Maschine der SAP ASCS-Instanz Testszenario In diesem Testszenario wird validiert, dass bei einem unerwarteten Ausfall des ESXi-Servers (gleichbedeutend mit einem Ausfall der virtuellen Maschine) das High Availability Extension-Cluster die SAP ERS-Instanz zu einer voll funktionsfähigen ASCS-Instanz hochstuft und die Sperrtabelle ohne Unterbrechungen für die Anwender übernimmt. Um dieses Ausfallszenario zu testen, wurde der ESXi-Server, der die virtuelle Maschine der SAP ASCS-Instanz hostet, über die physische Remotekonsole heruntergefahren. Anschließend wurde der Server neu gestartet, ohne den Wartungsmodus aufzurufen. Systemverhalten Das System reagiert wie folgt auf den Ausfall der virtuellen Maschine: 1. SAPASCS2 ist über vsphere Client nicht mehr verfügbar (siehe Abbildung 56). Abbildung 56. Ausfall der virtuellen Maschine 63

64 2. Der SAPInstance-Ressourcen-Agent erkennt und meldet den Ausfall (siehe Abbildung 57). Abbildung 57. SAPInstance-Ressourcen-Agent erkennt und meldet Ausfall 3. VMware HA startet die ausgefallene virtuelle Maschine von SAPASCS2 auf dem noch funktionierenden ESXi-Host neu, wie in Abbildung 58 gezeigt. Abbildung 58. VMware HA startet ausgefallene virtuelle Maschine neu 4. Der Master/Slave-Ressourcen-Agent stuft den vorherigen Slave-Node (SAPASCS3) zum Master-Node (Host der ASCS-Services) hoch und startet den ERS als Slave auf dem anderen Node (SAPASCS2), sobald dieser wieder dem Cluster beitritt (siehe Abbildung 59). 64

65 Abbildung 59. Master/Slave-Ressourcen-Agent wechselt Master- und Slave-Node 5. Die replizierte Sperrtabelle wird wiederhergestellt (siehe Abbildung 60). Abbildung 60. Replizierte Sperrtabelle wiederhergestellt Ergebnis Der Anwender nimmt den Ausfall des Enqueue-Prozesses nur wahr, wenn ein Enqueue-Vorgang ausgeführt wird. In diesem Fall beobachtet der Anwender eine längere Antwortdauer der Transaktion während des Wechsels. Neue Anwender können sich sofort nach dem Wechsel des Message-Servers beim System anmelden. Hierzu ist kein administrativer Eingriff erforderlich. Ausfall des Oracle RAC-Node Testszenario In diesem Testszenario wird validiert, dass bei einem unerwarteten Ausfall des RAC-Node die SAP-Instanzen automatisch mit anderen RAC-Nodes verbunden werden. Anwender können ihre Transaktionen ohne Unterbrechung fortsetzen, sofern keine Transaktionen auf dem ausgefallenen RAC-Node ausgeführt werden, die noch nicht in die Datenbank geschrieben wurden. Um dieses Fehlerszenario zu testen, wurde der Server neu gestartet, um einen Ausfall des Oracle-Node zu verursachen. 65

66 Systemverhalten Das System reagiert wie folgt auf den Ausfall des RAC-Node: 1. Der RAC-Node wechselt in den Offlinezustand, die Instanz VSE003 ist nicht mehr verfügbar, wie in Abbildung 61 gezeigt. srvctl status database -d VSE Instance VSE001 is running on node sse-ea-erac-n01 Instance VSE002 is running on node sse-ea-erac-n02 Instance VSE004 is running on node sse-ea-erac-n03 Instance VSE003 is not running on node sse-ea-erac-n04 Abbildung 61. RAC-Node wechselt in Offlinezustand 2. Der Arbeitsprozess der SAP-Instanz stellt eine Verbindung mit einer anderen RAC-Instanz her, wie in Abbildung 62 gezeigt.. Abbildung 62. SAP-Instanz stellt Verbindung mit anderem RAC-Node her Ergebnis Der Anwender beobachtet eine längere Antwortdauer der Transaktion, wenn der Arbeitsprozess der Dialoginstanz eine Verbindung mit einem anderen RAC-Node herstellt. Für noch nicht in der Datenbank gespeicherte Transaktionen wird ein Rollback ausgeführt, um die Datenkonsistenz aufrechtzuerhalten. Dem Anwender wird eine Systemfehlermeldung angezeigt (kurzer Speicherauszug) und die Transaktion muss neu gestartet werden. Hierzu ist kein administrativer Eingriff erforderlich. Systemausfall am Standort Testszenario In diesem Testszenario wird validiert, dass bei einem vollständigen Systemausfall am Standort auf den noch funktionierenden RAC-Nodes alle Datenbankvorgänge aufrechterhalten werden. Um dieses Fehlerszenario zu testen, wurde ein vollständiger Systemausfall an Standort A simuliert, von dem die Komponenten VPLEX-Cluster, ESXi-Server, Netzwerk und Oracle RAC-Node betroffen waren. VPLEX Witness war an Standort C weiterhin verfügbar. An Standort B wurde die Kommunikation zwischen VPLEX- Cluster 2 und VPLEX Witness beibehalten. 66