Vorherige

Nächste

Erkunden der Pilotphase

Abgeschlossen

Die Pilotphase kann parallel zur Projektplanungs- und -vorbereitungsphase erfolgen. In dieser Phase können auch Optionen getestet werden, die in der Planungs- und Vorbereitungsphase identifiziert wurden. In der Pilotphase empfiehlt es sich, eine vollständige Hochverfügbarkeits-/Notfallwiederherstellungslösung sowie den Sicherheitsentwurf festzulegen und zu überprüfen. In einigen Fällen kann diese Phase auch zum Durchführen von Skalierbarkeitstests oder zum Bereitstellen von SAP-Sandboxsystemen verwendet werden. Zu Beginn der Pilotphase sollten Kunden zunächst ein nicht kritisches System ermitteln, das zu Azure migriert werden soll, und dann die folgenden Aufgaben ausführen:

1. Optimieren der Datenübertragung zu Azure

Vorgehensweise und Ergebnis hängen stark von der Konnektivität vom Kunden zu Azure ab. Abhängig von der Datenmenge können für diesen Zweck möglicherweise ExpressRoute, Site-to-Site-VPN oder Offline-Datenübertragungsdienste wie Azure Data Box oder der Azure-Import/Exportdienst verwendet werden.

2. Migration einer heterogenen SAP-Plattform

Bei der Migration einer heterogenen SAP-Plattform, die den Export und Import von Datenbankdaten beinhaltet, sollten Sie die Export- und Importphasen testen und optimieren. Informationen zu umfangreichen heterogenen Migrationen für SQL Server finden Sie im Artikel zur SAP OS/DB-Migration zu SQL Server – FAQ. Sie können Migration Monitor/SWPM verwenden, wenn Sie die Migration nicht mit einem Versionsupgrade kombinieren müssen. Ansonsten verwenden Sie SAP DMO (Database Migration Option). Details finden Sie in der Einführung zur Datenbankmigrationsoption (DMO) von SUM. Führen Sie in beiden Fällen die folgenden Schritte aus:

• Messen Sie die Zeit für den Export von der Quelle, zum Hochladen der exportierten Inhalte in Azure und für den Import. Maximieren Sie die Überschneidung zwischen Export und Import.
• Vergleichen Sie Quell- und Zieldatenbanken, um die Größe der Zielinfrastruktur ordnungsgemäß zu bestimmen.
• Überprüfen und Optimieren der zeitlichen Steuerung

3. Durchführen der technischen Validierung

Arten von virtuellen Computern

• Informieren Sie sich in SAP-Supporthinweisen, im SAP HANA-Hardwareverzeichnis und in der SAP-Produktverfügbarkeitsmatrix (Product Availability Matrix, PAM), um die Genauigkeit der Informationen zu unterstützten Azure-VM-SKUs, unterstützten Betriebssystemversionen für diese Azure VM-SKUs sowie unterstützte SAP- und DBMS-Versionen sicherzustellen.
• Überprüfen Sie die Größe der Infrastruktur und der Anwendungskomponenten, die Sie in Azure bereitstellen. Beim Migrieren vorhandener Anwendungen sollten Sie den erforderlichen SAPS (SAP Application Performance Standard) anhand vorhandener Telemetriedaten abrufen können. Rufen Sie die SAP-Benchmark ab, und vergleichen Sie sie mit den im SAP-Hinweis 1928533 aufgeführten SAPS-Zahlen. Weitere Informationen finden Sie auch im Artikel zu SAPS-Bewertungen für Azure-VMs – Wo Sie suchen müssen und wo Verwirrung möglich ist.
• Bewerten und Testen der Größe Ihrer Azure-VMs in Bezug auf den maximalen Speicher- und Netzwerkdurchsatz der verschiedenen VM-Typen, die Sie in der Planungsphase ausgewählt haben. Diese Daten finden Sie im Artikel zu Größen für virtuelle Computer in Azure. Wenn Windows als Gastbetriebssystem der Azure-VM verwendet wird, muss der maximale Datenträgerdurchsatz ohne Cache bei der Dimensionierung berücksichtigt werden. Bei Linux muss ebenfalls der maximalen Datenträgerdurchsatz ohne Cache bei der Dimensionierung berücksichtigt werden.

Storage

• Verwenden Sie mindestens standardmäßigen Azure-SSD-Speicher für virtuelle Computer, die SAP-Anwendungsebenen darstellen, sowie für nicht leistungskritische DBMS-Bereitstellungen, und setzen Sie Azure Storage Premium für alle virtuellen leistungskritischen DBMS-Computer ein.
• Vermeiden Sie die Verwendung von standardmäßigen Azure-HDD-Datenträgern.
• Verwenden Sie Azure Managed Disks
• Aktivieren Sie die Azure-Schreibbeschleunigung für DBMS-Protokolllaufwerke mit virtuellen Azure-Computern der M-Serie. Beachten Sie die für die Schreibbeschleunigung dokumentierten Grenzwerte und Nutzungseinschränkungen.
• Weitere Informationen zu DBMS-Speicher finden Sie in den Überlegungen zur DBMS-Bereitstellung für SAP-Workloads mit Azure Virtual Machines sowie in der DBMS-spezifischen Dokumentation, auf die in diesem Dokument verwiesen wird.
• Informationen zu SAP HANA-Bereitstellungen finden Sie im Artikel über SAP HANA-Infrastrukturkonfigurationen und -Vorgänge in Azure.
• Binden Sie Azure-Datenträger niemals mithilfe der Geräte-ID auf einem virtuellen Azure-Linux-Computer ein. Verwenden Sie stattdessen den Universally Unique Identifier (UUID). Gehen Sie mit Bedacht vor, wenn Sie grafische Tools zum Einbinden eines Azure-Datenträgers verwenden. Überprüfen Sie gründlich die Einträge in „/etc/fstab“, um sicherzustellen, dass die Datenträger mit der UUID eingebunden werden. Weitere Informationen finden Sie im Artikel zum Herstellen einer Verbindung zu virtuellen Linux-Computern zum Einbinden eines neuen Datenträgers.

Netzwerk

Testen und evaluieren Sie Ihre virtuelle Netzwerkinfrastruktur und die Verteilung Ihrer SAP-Anwendungen in den virtuellen Azure-Netzwerken oder netzwerkübergreifend.

1. Bewerten Sie den Hub-Spoke-Ansatz für die virtuelle Netzwerkarchitektur oder die Mikrosegmentierung innerhalb eines einzelnen virtuellen Azure-Netzwerks anhand der folgenden Kriterien:

   • Kosten für den Datenaustausch zwischen virtuellen Azure-Netzwerken mit Peering. (Weitere Informationen finden Sie unter Azure Virtual Network – Preise.)
   • Vergleichen der Möglichkeit, das Peering zwischen virtuellen Azure-Netzwerken zu beenden, mit der Verwendung von Netzwerksicherheitsgruppen (NSGs) zum Isolieren von Subnetzen in einem virtuellen Netzwerk, wenn Anwendungen oder virtuelle Computer, die in einem Subnetz des virtuellen Netzwerks gehostet werden, zu einem Sicherheitsrisiko werden.
   • Zentrale Protokollierung und Überwachung des Netzwerkdatenverkehrs zwischen lokalem Standort, Internet und virtuellem Azure-Rechenzentrum.

2. Bewerten und testen Sie den Datenpfad zwischen der SAP-Anwendungsschicht und der SAP DBMS-Schicht. Bedenken Sie bei Ihrer Bewertung Folgendes:

   • Eine Platzierung von virtuellen Azure-Netzwerkgeräten im Kommunikationspfad zwischen der SAP-Anwendung und der DBM-Serverebene eines SAP NetWeaver-, Hybris- oder S/4HANA-basierten SAP-Systems wird nicht unterstützt.
   • Eine Platzierung von SAP-Anwendungsebene und SAP-DBM-Server in verschiedenen virtuellen Azure-Netzwerken, die nicht mittels Peering miteinander verknüpft sind, wird nicht unterstützt.
   • Die Verwendung von Azure-Anwendungssicherheitsgruppen (ASGs) und Netzwerksicherheitsgruppen (NSGs) zum Steuern des Datenverkehrsflusses zwischen der SAP-Anwendungsebene und der SAP-DBMS-Ebene wird unterstützt.

3. Auf den virtuellen Computern, die auf der SAP-Anwendungsebene und der SAP-DBM-Serverebene verwendet werden, muss Azure Accelerated Networking aktiviert sein. Berücksichtigen Sie die Betriebssystemanforderungen zur Unterstützung von Azure Accelerated Networking:

   • Windows Server 2012 R2 oder neuere Releases
   • SUSE Linux 12 SP3 oder neuere Releases
   • RHEL 7.4 oder neuere Releases
   • Oracle Linux 7.5. Der RHCKL-Kernel erfordert die Version 3.10.0-862.13.1.el7. Der Oracle-UEK-Kernel benötigt Version 5.

4. Testen und evaluieren Sie die Netzwerklatenz zwischen virtuellen Computern auf der SAP-Anwendungsebene und virtuellen DBMS-Computern gemäß SAP-Hinweis 500235 und SAP-Hinweis 1100926. Vergleichen Sie die Ergebnisse mit dem Netzwerklatenzleitfaden im SAP-Hinweis 1100926. Die Werte für die Netzwerklatenz sollten im Bereich zwischen mittel und gut liegen.

5. Stellen Sie sicher, dass die Bereitstellungen des internen Azure-Lastenausgleichs für die Verwendung von Direct Server Return eingerichtet wurden. Mit dieser Einstellung wird die Latenz verringert, wenn interne Lastenausgleiche für Hochverfügbarkeitskonfigurationen auf der DBMS-Ebene verwendet werden.

6. Wenn Sie Azure Load Balancer in Verbindung mit Linux-Gastbetriebssystemen verwenden, überprüfen Sie, ob der Linux-Netzwerkparameter net.ipv4.tcp_timestamps auf „0“ festgelegt ist. Beachten Sie, dass dies den allgemeinen Empfehlungen im SAP-Hinweis 2382421 widerspricht. Der SAP-Hinweis wurde aktualisiert, um darauf hinzuweisen, dass dieser Parameter auf 0 festgelegt werden muss, damit er mit Azure Load Balancern funktioniert.

Bereitstellungen für Hochverfügbarkeit und Notfallwiederherstellung

• Wenn Sie die SAP-Anwendungsebene bereitstellen, ohne bestimmte Azure-Verfügbarkeitszonen zum Ziel zu haben, müssen Sie darauf achten, dass alle virtuellen Computer, auf denen die SAP-Dialoginstanz oder Middleware-Instanzen desselben SAP-Systems ausgeführt werden, in derselben Verfügbarkeitsgruppe bereitgestellt werden.

  • Wenn Sie für SAP Central Services und DBM-Server keine Hochverfügbarkeit benötigen, können diese virtuellen Computer in derselben Verfügbarkeitsgruppe wie die SAP-Anwendungsebene bereitgestellt werden.

• Wenn Sie in Hinblick auf Hochverfügbarkeit SAP Central Services und die DBMS-Ebene mit passiven Replikaten schützen müssen, stellen Sie die beiden Knoten für SAP Central Services in einer Verfügbarkeitsgruppe und die beiden DBMS-Knoten in einer anderen Verfügbarkeitsgruppe bereit.

• Wenn die Bereitstellung in Azure-Verfügbarkeitszonen erfolgt, können Sie keine Verfügbarkeitsgruppen nutzen. Stellen Sie stattdessen sicher, dass Sie die aktiven und passiven Central Services-Knoten in zwei verschiedenen Verfügbarkeitszonen bereitstellen, die die niedrigste Latenz zwischen den Zonen bieten.

• Denken Sie daran, dass Sie Azure Load Balancer Standard verwenden müssen, wenn Sie übergreifend über Verfügbarkeitszonen hinweg auf Basis von Windows Server oder Pacemaker Failovercluster für die DBMS- und SAP Central Services-Ebene erstellen. Load Balancer Basic unterstützt keine zonenbezogenen Bereitstellungen.

Timeouteinstellungen

• Überprüfen Sie SAP NetWeaver Developer Traces auf den SAP-Instanzen, und sorgen Sie dafür, dass zwischen dem Warteschlangenserver und den SAP-Arbeitsprozessen keine Verbindungsabbrüche auftreten. Diese Verbindungsabbrüche lassen sich durch Einstellen der beiden folgenden Registrierungsparameter vermeiden:

  • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Weitere Informationen finden Sie unter KeepAliveTime.
  • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Weitere Informationen finden Sie unter KeepAliveInterval.

• Um GUI-Timeouts zwischen lokalen grafischen SAP-Schnittstellen und in Azure bereitgestellten SAP-Anwendungsebenen zu vermeiden, legen Sie in der Datei „default.pfl“ oder im Instanzprofil die folgenden Parameter fest:

  • rdisp/keepalive_timeout = 3600
  • rdisp/keepalive = 20

• Wenn Sie ein Windows-Failoverclustering verwenden, stellen Sie sicher, dass die Parameter, die ein Failover durch nicht reagierende Knoten auslösen, ordnungsgemäß festgelegt sind. Im Microsoft TechCommunity-Artikel zum Optimieren von Netzwerkschwellenwerten für Failovercluster werden Parameter und deren Auswirkungen auf das Failoververhalten aufgelistet. Wenn sich beispielsweise die Clusterknoten im selben Subnetz befinden, müssen Sie die Failoverparameter wie folgt konfigurieren:

  • SameSubNetDelay = 2000

  • SameSubNetThreshold = 15

  • RoutingHistorylength = 30

  • Testen der Verfahren für Hochverfügbarkeit und Notfallwiederherstellung:

    • Simulieren Sie einen Failover durch Herunterfahren von virtuellen Azure-Computern (Windows-Gastbetriebssystem) oder das Versetzen von Betriebssystemen in den Panikmodus (Linux-Gastbetriebssysteme).

    • Messen Sie die Zeit für die Ausführung eines Failovers. Wenn Sie die Zeiten zu lang sind, erwägen Sie Folgendes:

      • Verwenden Sie für SUSE Linux SBD-Geräte anstelle von Azure Fencing-Agent, um das Failover zu beschleunigen.
      • Wenn bei SAP HANA das erneute Laden der Daten zu lange dauert, sollten Sie eine Erhöhung der Speicherleistung erwägen.

    • Testen Sie die Sicherungs-/Wiederherstellungssequenz sowie die zeitliche Steuerung, und optimieren Sie sie bei Bedarf. Stellen Sie nicht nur ausreichende Sicherungszeiten sicher. Testen Sie die Wiederherstellung und ermitteln Sie den zeitlichen Ablauf von Wiederherstellungsaktivitäten. Stellen Sie sicher, dass die Wiederherstellungszeiten innerhalb Ihrer RTO-SLAs liegen, wenn Ihre RTO von einem Wiederherstellungsprozess für eine Datenbank oder einem virtuellen Computer abhängig ist.

    • Testen Sie Funktion und Architektur der Notfallwiederherstellung.

4. Ausführen von Sicherheitsüberprüfungen

• Testen Sie die Gültigkeit des Azure-Ansatzes mit rollenbasiertem Zugriff (RBAC), den Sie implementiert haben. Das Ziel besteht darin, den Zugriff und die an verschiedene Teams delegierten Berechtigungen zu trennen und zu begrenzen. Zum Beispiel sollten SAP-Basisteammitglieder in der Lage sein, in einem vorhandenen virtuellen Azure-Netzwerk virtuelle Azure-Computer bereitzustellen und diesen Datenträger zuzuweisen. Jedoch sollte das SAP-Basisteam keine neuen virtuellen Netzwerke erstellen oder die Einstellungen vorhandener virtueller Netzwerke ändern können. Umgekehrt sollten Mitglieder des Netzwerkteams nicht in der Lage sein, virtuelle Azure-Computer in virtuellen Netzwerken bereitzustellen, in denen SAP-Anwendungen und virtuelle DBM-Servercomputer ausgeführt werden. Außerdem sollten Mitglieder des Netzwerkteams weder Attribute von virtuellen Computern ändern noch virtuelle Computer und zugehörige Datenträger löschen können.
• Vergewissern Sie sich, dass die NSG-Regeln erwartungsgemäß funktionieren und einen Schutz für die Ressourcen bilden.
• Überprüfen Sie die Verschlüsselung im Ruhezustand und bei der Übertragung. Definieren und implementieren Sie Prozesse, um Zertifikate zu sichern, zu speichern und auf diese zuzugreifen, und überprüfen Sie den Wiederherstellungsvorgang für verschlüsselte Entitäten.
• Verwenden Sie Azure Disk Encryption für Betriebssystemdatenträger.
• Bei der Entscheidung, ob ein Verschlüsselungsmechanismus implementiert werden soll, sollten Sie einen pragmatischen Ansatz verfolgen. Bewerten Sie beispielsweise, ob es notwendig ist, sowohl Azure Disk Encryption als auch die transparente DBMS-Datenbankverschlüsselung anzuwenden.

5. Testen der Leistung

Nutzen Sie bei Migrationsszenarien die SAP-Ablaufverfolgung und Messungen, um das Pilotprojekt anhand der folgenden Punkte mit der aktuellen Implementierung zu vergleichen:

• Die 10 wichtigsten Onlineberichte
• Die 10 wichtigsten Batchaufträge
• Datenübertragung über Schnittstellen zum SAP-System mit Schwerpunkt auf standortübergreifendem Datenverkehr

Weiter