Überblick über die Automatisierung der Bereitstellung von SAP Workload HA auf IBM Cloud® Virtual Private Cloud (VPC) (Terraform und Ansible )
Sie können Terraform verwenden, um die Bereitstellung von IBM Cloud VPC zu automatisieren. Die bereitgestellte VPC umfasst virtuelle Serverinstanzen mit hoher Netzleistung. Die VPC-Infrastruktur enthält eine Reihe von IaaS-Angeboten (Infrastructure as a Service), einschließlich Virtual Servers. Nachdem die VPC bereitgestellt wurde, verwenden die Skripte das Ansible Playbook, um das SAP System zu installieren.
IBM Cloud® VPC-Einführung
Eine VPC ist ein Public Cloud-Angebot, das ein Unternehmen verwendet, um eine eigene Private Cloud-ähnliche IT-Umgebung in einer gemeinsam genutzten Public Cloud-Infrastruktur einzurichten. VPCs geben einem Unternehmen die Möglichkeit, ein virtuelles Netz zu definieren und zu steuern, das logisch von allen anderen öffentlichen Cloud-Tenants isoliert ist und einen privaten, sicheren Platz in der Public Cloud erstellt.
Stellen Sie sich vor, dass die Infrastruktur eines Cloud-Providers ein Wohngebäude ist und mehrere Familien darin leben. Als Public Cloud-Tenant fühlt man sich wie in einer Wohnung mit ein paar Mitbewohnern. Im Gegensatz dazu ist ein VPC wie eine eigene Eigentumswohnung: Niemand sonst hat den Schlüssel, und niemand kann den Raum ohne Ihre Berechtigung betreten.
Die logische Isolation einer VPC wird mithilfe virtueller Netzfunktionen und Sicherheitsfunktionen implementiert, die einem Unternehmenskunden eine differenzierte Steuerung darüber geben, welche IP-Adressen oder Anwendungen auf bestimmte Ressourcen zugreifen können. Es ist vergleichbar mit den Steuerelementen "nur für Freunde" oder "öffentlich/privat" auf Konten in sozialen Medien, die verwendet werden, um zu steuern, wer Ihre ansonsten öffentlichen Beiträge sehen kann oder nicht.
Mit IBM Cloud VPC können Sie die Benutzeroberfläche, die Befehlszeilenschnittstelle und die API verwenden, um virtuelle Serverinstanzen für VPC mit hoher Netzwerkleistung manuell bereitzustellen. Die VPC-Infrastruktur enthält eine Reihe von Infrastructure-as-a-Service-Angeboten ( IaaS ), darunter Virtual Servers for VPC. Verwenden Sie die folgenden Informationen, um einen einfachen Anwendungsfall für die Planung, Erstellung und Konfiguration von Ressourcen für Ihre VPC zu verstehen und um mehr über weitere VPC-Übersichten und VPC-Lernprogramme zu erfahren. Weitere Informationen zu VPC finden Sie unter Einführung in Virtual Private Cloud (VPC).
SAP produktarchitektur auf IBM Cloud VPC
Eine Virtual Private Cloud(VPC ) enthält eine der sichersten und zuverlässigsten Cloud-Umgebungen für SAP Anwendungen innerhalb Ihrer eigenen VPC mit den darin enthaltenen virtuellen Serverinstanzen. Dies stellt eine Infrastructure as a Service ( IaaS ){: external} innerhalb von IBM Cloud dar, die alle Vorteile einer isolierten, sicheren und flexiblen virtuellen Cloud-Infrastruktur von IBM bietet. Im Vergleich dazu verwendet das Angebot von IBM Cloud classic infrastructure virtual servers virtuelle Instanzen mit nativen und VLAN-Netzwerken, um innerhalb eines Rechenzentrums miteinander zu kommunizieren; allerdings sind die Instanzen durch die Verwendung von Subnetz- und VLAN-Netzwerken auf einen gut funktionierenden Pod beschränkt, da ein Gap-Scale-up der virtuellen Ressourcen zwischen den Pods erforderlich ist. Das Neue an IBM Cloud VPC ist ein Konzept der Netzwerk-Orchestrator-Schicht, das die Pod-Grenzen und -Einschränkungen aufhebt. Dieses neue Konzept verwaltet das gesamte Netzwerk für jede virtuelle Instanz, die innerhalb der VPC über Regionen und Zonen hinweg läuft.
Hochverfügbares System für SAP NetWeaver auf IBM Cloud VPC
In einem hochverfügbaren (HA) System kann jede Instanz auf einer separaten virtuellen Serverinstanz IBM Cloud laufen. Die Cluster-HA-Konfiguration für den SAP Anwendungsserver besteht aus zwei virtuellen Serverinstanzen, die sich jeweils in derselben Zone für eine Zone oder in verschiedenen Zonen für mehrere Zonen innerhalb derselben Region befinden, indem Platzierungsgruppen verwendet werden. Platzierungsgruppen stellen sicher, dass sowohl Cluster-Ressourcen als auch Cloud-Ressourcen in verschiedenen Rechenknoten untergebracht sind, wie im folgenden Abschnitt über Platzierungsgruppen beschrieben.
Platzierungsgruppen auf IBM Cloud VPC für SAP HA-Architektur
Platzierungsgruppen (PG) für VPC haben zwei verschiedene Anti-Affinitätsstrategien für hohe Verfügbarkeit. Durch die Verwendung von Platzierungsstrategien minimieren Sie das Risiko von Serviceunterbrechungen bei virtuellen Serverinstanzen, die auf verschiedenen Hosts oder in einer Infrastruktur mit separater Strom- und Netzwerkversorgung untergebracht sind.
Das Design von Platzierungsgruppen für virtuelle Server in IBM Cloud ermöglicht die Lösung dieses Problems. Platzierungsgruppen bieten eine Möglichkeit zur Steuerung des Hosts, auf dem ein neuer öffentlicher virtueller Server platziert wird. Mit dieser Version wird eine "Spread"-Regel implementiert, d.h. die virtuellen Server innerhalb einer Platzierungsgruppe werden alle auf verschiedene Hosts verteilt. Sie können eine hochverfügbare Anwendung innerhalb eines Rechenzentrums erstellen und wissen, dass Ihre virtuellen Server voneinander isoliert sind.
Platzierungsgruppen mit der Verteilungsregel stehen zur Verfügung, um die Erstellung in den ausgewählten IBM Cloud-Rechenzentren durchzuführen. Nachdem eine "Spread"-Regel erstellt wurde, können Sie einen virtuellen Server in dieser Gruppe bereitstellen und sicherstellen, dass er sich nicht auf demselben Host wie andere virtuelle Server befindet. Besonders vorteilhaft an dieser Funktion ist, dass ihre Verwendung völlig kostenfrei ist.
Sie können Ihre Platzierungsgruppe erstellen und dann bis zu vier neue virtuelle Serverinstanzen zuweisen. Mit der Verteilungsregel werden alle virtuellen Server auf unterschiedlichen physischen Hosts bereitgestellt. In den folgenden Beispielkonfigurationen wird die Option "Power Spread" verwendet.
Dies sind die folgenden SAP Instanzen, die für ein HA-Szenario benötigt werden:
- ABAP Central Services Instanz (ASCS-Instanz)- enthält den ABAP Message Server und den ABAP Enqueue Server
- Enqueue-Replikationsserver-Instanz (ERS-Instanz) für die ASCS-Instanz
- Datenbankinstanz
- Primäre Anwendungsinstanz (PAS) auf Knoten 1
- Zusätzliche Anwendungsinstanz (AAS) auf Knoten 2
Es wird empfohlen, sowohl die ASCS-Instanz als auch die ERS-Instanz in einer Switchover-Cluster-Infrastruktur zu betreiben.
IBM Cloud File Storage for VPC für SAP HA-Architektur
IBM Cloud File Storage for VPC technologie wird verwendet, um die Verzeichnisse von SAP für das System SAP verfügbar zu machen. Die Technologien der Wahl sind NFS, gemeinsam genutzte Festplatten und das Cluster-Dateisystem. Wenn Sie sich für eine hochverfügbare (HA) Lösung für Ihr SAP System entschieden haben, stellen Sie sicher, dass Sie die HA-Anforderungen der SAP Dateisysteme in Ihrer SAP Umgebung richtig berücksichtigen.
- Dateifreigaben, die als NFS permanente Dateisysteme auf beiden Clusterknoten für SAP apps HA eingehängt werden:
/usr/sap/<SAPSID>/SYS/sapmnt<SAPSID>/usr/sap/trans
- Cluster-verwaltete Dateisysteme für SAP Apps HA: ASCS si ERS
/usr/sap/<SAPSID>/ASCS00/usr/sap/<SAPSID>/ERS01
- Permanenter NFS mount auf SAP Apps HA node 1 PAS instance:
/usr/sap/<SAPSID>/Dxx
- Permanenter NFS mount auf SAP Apps HA node 2 dialog instance:
/usr/sap/<SAPSID>/Dyy
Voraussetzungen
Sie müssen die Hardware (Hosts, Festplatten und Netzwerk) installieren und entscheiden, wie die Datenbank, die SAP Instanzen und, falls erforderlich, der Network File System ( NFS ) Server auf die Clusterknoten verteilt werden sollen.
Kontext
Aus der Sicht einer SAP Anwendung sind dies die Arten von SAP Verzeichnissen:
- Physisch gemeinsam genutzte Verzeichnisse:
/<sapmnt>/<SAPSID>und/usr/sap/trans - Logisch gemeinsam genutzte Verzeichnisse, die an einen Knoten gebunden sind, wie z. B.
/usr/sap, mit den folgenden lokalen Verzeichnissen:/usr/sap/<SAPSID>/usr/sap/<SAPSID>/SYS/usr/sap/hostctrl
- Lokale Verzeichnisse, die die SAP Instanzen enthalten, wie z.B
/usr/sap/<SAPSID>/ASCS<Instance_Number> - Das globale Transportverzeichnis kann sich auf einem separaten SAP Transportrechner befinden, wie es bei einer Standardkonfiguration der Transportschicht mit drei Systemen der Fall ist.
Sie benötigen mindestens zwei Knoten und ein gemeinsames Dateisystem für verteilte ASCS- und ERS-Instanzen, und es wird davon ausgegangen, dass die übrigen Komponenten auf andere Knoten verteilt sind.
Installation von ASCS und ERS
Damit die ASCS- und ERS-Instanzen von einem Knoten zum anderen verschoben werden können, müssen sie auf einem gemeinsamen Dateisystem installiert werden und virtuelle Hostnamen auf der Grundlage der virtuellen IP verwenden.
In dieser VPC-basierten SAP HA-Lösung wird das vom Cluster benötigte gemeinsame Dateisystem durch den NFS-gemounteten Dateispeicher und die virtuelle IP durch die Application Load Balancer for VPC (ALB) ersetzt.
In diesem Szenario werden drei ALBs verwendet, eine für jede Single Point of Failure-Komponente (SPOF), um den Bedarf an virtuellen IPs zu ersetzen: ALB für ASCS, ALB für ERS und ALB für HANA. Jeder ALB ist als Backend für die entsprechenden Cluster-Server konfiguriert und leitet die gesamte Kommunikation, die an den Front-End-Ports eingeht, an den aktiven Server im Backend-Pool weiter.
Private Lastausgleichsfunktion für Anwendungen
Ein privater Anwendungs-Load-Balancer ist über Ihre privaten Subnetze zugänglich, die Sie zum Erstellen des Load-Balancers konfiguriert haben.
Ähnlich wie bei einem öffentlichen Anwendungs-Load-Balancer wird Ihrer privaten Anwendungs-Load-Balancer-Service-Instanz ein FQDN zugewiesen; dieser Domänenname wird jedoch mit einer oder mehreren privaten IP-Adressen registriert.
Durch IBM Cloud-Operationen können Anzahl und Wert der zugeordneten privaten IP-Adressen im Laufe der Zeit aufgrund von Wartungs- oder Skalierungsvorgängen geändert werden. Die virtuellen Backend-Serverinstanzen, die Ihre Anwendung hosten, müssen in derselben Region und unter derselben VPC ausgeführt werden.
Verwenden Sie den zugewiesenen ALB-FQDN, um den Datenverkehr an den privaten Anwendungs-Load-Balancer zu senden, um Konnektivitätsprobleme mit Ihren Anwendungen während der Systemwartung oder bei Skalierungsaktivitäten zu vermeiden.
Jeder ALB sendet Daten an den Clusterknoten, auf dem die Anwendung (ASCS, ERS, HANA DB) läuft. Beim Failover des Clusters leitet der ALB den gesamten Datenverkehr an den neuen Knoten um, an dem die Ressourcen betriebsbereit sind.
DNSaaS (DNS as a Service) ist die Verwaltung IBM Cloud VPC DNS-Dienst von HA und FQDN (IPs) Mechanismus.
Der ALB hat einen Standardwert von 50 Sekunden für Client- und Server-Timeout, d. h. nach 50 Sekunden Inaktivität werden die Verbindungen geschlossen. Um SAP Verbindungen über ALB zu unterstützen und die Verbindung nicht nach 50 Sekunden zu verlieren, müssen Sie eine Änderung dieses Wertes auf mindestens 300 Sekunden beantragen (clientseitige Leerlaufverbindung = mindestens 300s und serverseitige Leerlaufverbindung = mindestens 300s ). Um diese Änderung zu beantragen, öffnen Sie ein Support-Ticket. Dies ist eine kontoweite Änderung, die alle ALBs in Ihrem Konto betrifft. Weitere Informationen finden Sie unter Zeitüberschreitungen bei Verbindungen.
DNS Services mit VPC
IBM Cloud DNS Services bietet den VPC-Benutzern ein privates DNS. Private DNS-Zonen sind nur in IBM Cloud auflösbar und nur aus explizit zugelassenen Netzen in einem Konto. Um zu beginnen, erstellen Sie eine DNS Services Instanz mit Hilfe der IBM Cloud Konsole.
DNS Services ermöglichen Folgendes:
- Private DNS-Zonen erstellen, bei denen es sich um Sammlungen von Domänennamen handelt.
- DNS-Ressourcendatensätze unter diesen DNS-Zonen erstellen.
- Zugriffssteuerungen für die DNS-Auflösung von Ressourcendatensätzen auf Zonenebene angeben.
DNS Services unterhält auch eine eigene weltweite Gruppe von DNS-Auflösern. Instanzen, die unter IBM Cloud in einem IBM Cloud-Netz bereitgestellt werden, können Ressourcendatensätze verwenden, die durch IBM Cloud DNS Services konfiguriert wurden, indem sie DNS Services-Auflöser abfragen.
Für Ressourcendatensätze und Zonen, die über DNS Services konfiguriert werden, gilt Folgendes:
- Sie sind getrennt vom größeren, öffentlichen DNS und den öffentlich zugänglichen Datensätzen.
- Versteckt vor Systemen außerhalb und nicht Teil des privaten Netzes IBM Cloud.
- Der Zugriff ist nur von Systemen möglich, die Sie im privaten Netzwerk IBM Cloud autorisiert haben.
- Kann nur über die vom Dienst bereitgestellten Resolver aufgelöst werden.
Der DNS-Dienst ordnet den FQDN jedes ALB den virtuellen Hostnamen des ASCS, ERS und HANA zu, die von SAP Anwendungen verwendet werden.
Netzwerklatenz zwischen VPC-Zonen und -Regionen
Für die Netzwerklatenz zwischen VPC-Zonen und -Regionen lesen Sie bitte das Thema VPC-Netzwerklatenz-Dashboards und führen Sie Ihre eigene Messung gemäß SAP Hinweis "500235 - Netzwerkdiagnose mit NIPING" durch, um eine Latenzprüfung mit dem SAP Tool niping durchzuführen.
Es werden die gemessenen Ergebnisse berichtet. Diese Messungen beinhalten keine Leistungsgarantie. Diese Statistiken geben Aufschluss über die Latenz zwischen allen Regionen und Zonen und helfen Ihnen bei der Planung der optimalen Auswahl für Ihre Cloud-Bereitstellung und bei der Planung von Szenarien wie Datenverfügbarkeit und Leistung.
Hochverfügbares System für die Datenbank SAP HANA
Ein standardmäßiger HA HANA-Cluster in einer Aktiv-Passiv-Konfiguration besteht aus zwei Knoten: einem Primärknoten und einem Standby-Knoten. Das bedeutet einfach, dass der primäre Knoten die aktiven SAP Instanzen (PAS und AAS) aktiv bedient, während der Standby-Knoten darauf wartet, bei einem Ausfall einzuspringen.
Hochverfügbares System für SAP Anwendungsinstanz
Der Cluster wird mit einem virtuellen IP-Hostnamen eingerichtet (der Hostname wird über DNS auf den FQDN des HANA ALB gemappt, was dasselbe ist, wie zuvor für SAP ASCS- und ERS-Instanzen erklärt wurde). Anwendungsinstanzen (PAS und AAS), das sind die Angaben, die in den Profilen von SAP verwendet werden, um diese bestimmte Komponente aufzurufen. Der Cluster weist diese virtuelle IP dem aktiven Knoten zu und verwendet einen Heartbeat-Monitor, um die Verfügbarkeit der Komponenten zu bestätigen. Wenn der primäre Knoten nicht mehr reagiert, löst er den automatischen Failover-Mechanismus aus, der den Standby-Knoten aufruft, um die Rolle des primären Knotens zu übernehmen. Der ALB erkennt die Änderung, leitet den Verkehr an den neuen aktiven Knoten um und weist ihm die virtuelle IP zu, wodurch die Verfügbarkeit der Komponente wiederhergestellt wird. Nachdem der ausgefallene Knoten repariert wurde, geht er als Standby-Knoten online.
Synchroner On-Disk (sync) HANA-Datenbankreplikationsmechanismus unterstützt von SAP
Das primäre System wartet mit dem Commit der Transaktion, bis es eine Antwort erhält, daß das Protokoll im sekundären System persistiert ist. Diese Option garantiert die sofortige Konsistenz zwischen den beiden Systemen, allerdings um den Preis, dass sich die Transaktion um die Zeit für die Datenübertragung und die Persistenz im Sekundärsystem verzögert.
Wenn die Verbindung zum sekundären System unterbrochen wird, setzt das primäre System die Transaktionsverarbeitung fort und schreibt die Änderungen nur auf die lokale Festplatte. In diesem Szenario kommt es zu keinem Datenverlust, wenn das sekundäre System angeschlossen ist. Datenverluste können auftreten, wenn eine Übernahme durchgeführt wird, während das sekundäre System nicht angeschlossen ist.
Außerdem kann dieser Replikationsmodus mit einer vollständigen Synchronisierungsoption ausgeführt werden. Dies bedeutet, daß das Schreiben des Protokolls erfolgreich war, wenn der Protokollpuffer in die Protokolldatei des primären und des
sekundären Systems geschrieben wurde. Wenn die Verbindung zum sekundären System unterbrochen wird (z. B. wegen eines Netzausfalls), unterbricht das primäre System die Transaktionsverarbeitung, bis die Verbindung zum sekundären System wiederhergestellt
ist. Bei diesem Szenario kommt es zu keinem Datenverlust. Mit dem Parameter [system_replication]/enable_full_sync können Sie die Option Full Sync für die Systemreplikation einstellen.
Wenn die SAP HANA Systemreplikation im Sync-Replikationsmodus mit aktivierter Option "Full Sync" läuft und die Verbindung zur sekundären Site unterbrochen wird, sind keine Schreibvorgänge auf der primären Site möglich. Beim Anlegen einer Mieterdatenbank wird beispielsweise gewartet, bis die Verbindung zur sekundären Datenbank wiederhergestellt ist oder die SQL-Anweisung eine Zeitüberschreitung aufweist.
Diese Automatisierung wird kostenlos angeboten; die bereitgestellte Infrastruktur ist jedoch kostenpflichtig.