Untersuchen der Best Practices für die Migration sehr großer Datenbanken

  • 11 Minuten

Die folgenden Richtlinien beruhen auf realen Kundenprojekten und den daraus gewonnenen Erkenntnissen. In den Richtlinien werden Szenarien benannt, die sich in der Vergangenheit als nicht erfolgreich erwiesen haben. Ein Beispiel ist die Empfehlung, keine UNIX-Server oder virtualisierte Server als R3load-Exportserver zu verwenden:

  • Häufig ist die Exportleistung ein ausschlaggebender Faktor für die Gesamtausfallzeit. Oft ist die vorhandene Hardware mehr als 4–5 Jahre alt und ein Upgrade unerschwinglich.
  • Daher ist es wichtig, die höchste Exportleistung zu erzielen, die praktisch möglich ist.
  • In vergangenen Projekten wurden Personenwochen oder sogar Personenmonate darauf verwendet, die R3load-Exportleistung für UNIX- oder virtualisierte Plattformen zu optimieren, bis man schließlich aufgab und Intel R3load-Server einsetzte.
  • Handelsübliche Intel-Server mit zwei Sockets sind kostengünstig und bieten erhebliche Leistungssteigerungen, die in einigen Fällen einige Größenordnungen über den geringen Leistungsverbesserungen liegen, die auf UNIX- oder virtualisierten Servern möglich sind.
  • Die Kunden arbeiten häufig mit bestehenden VM-Farmen, die jedoch meistens keine modernen Technologien für Abladung oder SR-IOV unterstützen. Häufig ist die VMware-Version veraltet, nicht gepatcht oder nicht für einen hohen Netzwerkdurchsatz und eine geringe Latenz konfiguriert. R3load-Exportserver benötigen eine hohe Threadleistung und einen extrem hohen Netzdurchsatz. R3load-Exportserver können 10–15 Stunden lang bei nahezu 100 % CPU- und Netzwerkauslastung ausgeführt werden. Dies ist nicht der typische Anwendungsfall der meisten VMware-Farmen, und die Mehrzahl der VMware-Bereitstellungen wurde nie für eine Workload wie R3load konzipiert.

Tipp

Investieren Sie keine Zeit in die Optimierung der R3load-Exportleistung auf UNIX- oder virtualisierten Plattformen. Dies ist nicht nur eine Vergeudung von Zeit, sondern auch sehr viel teurer als der Erwerb kostengünstiger Intel-Server zu Beginn des Projekts. Kunden, die eine VLDB-Migration durchführen möchten, sollten deshalb sicherstellen, dass dem Projektteam zu Beginn des Projekts schnelle und moderne R3load-Exportserver zur Verfügung stehen. Dies verringert die Gesamtkosten und das Risiko des Projekts.

Bewährte Methoden

  • Erfassen und inventarisieren Sie die aktuelle SAP-Landschaft. Identifizieren Sie die SAP Support Pack-Ebenen und ermitteln Sie, ob ein Patching zur Unterstützung des Ziel-DBMS erforderlich ist. Im Allgemeinen wird die Kompatibilität des Betriebssystems durch den SAP-Kernel und die Kompatibilität des DBMS durch die SAP_BASIS-Patchebene bestimmt.
  • Erstellen Sie eine Liste der SAP OSS-Hinweise, die im Quellsystem angewendet werden müssen, wie z. B. Updates für SMIGR_CREATE_DDL. Erwägen Sie ein Upgrade der SAP-Kernel in den Quellsystemen, um umfangreiche Änderungen während der Migration zu Azure zu vermeiden. (Beispiel: Wenn auf einem System ein alter Kernel der Version 7.41 ausgeführt wird, aktualisieren Sie auf dem Quellsystem auf die neueste Version 7.45, um eine umfangreiche Änderung während der Migration zu vermeiden.)
  • Entwickeln und dokumentieren Sie die Lösung für Hochverfügbarkeit und Notfallwiederherstellung. Die Dokumentation sollte eine Unterteilung der Lösung in DB-Ebene, ASCS-Ebene und SAP-Anwendungsserverebene enthalten. Für Einzellösungen wie TREX oder Livecache sind möglicherweise separate Lösungen erforderlich.
  • Entwickeln Sie ein Dokument zur Größenbestimmung und Konfiguration, in dem die Azure-VM-Typen und die Speicherkonfiguration detailliert aufgeführt sind. Geben Sie Folgendes an: Anzahl von Premium-Datenträgern, Anzahl von Datendateien, Art der Verteilung der Datendateien auf die Datenträger, Nutzung des Speicherplatzes, NTFS-Formatgröße = 64 KB. Dokumentieren Sie auch die Sicherung/Wiederherstellung und die DBMS-Konfiguration, z. B. die Speichereinstellungen, den maximalen Parallelitätsgrad und die Ablaufverfolgungsflags.
  • Entwickeln Sie ein Dokument zum Netzwerkentwurf, einschließlich VNet-, Subnetz-, NSG- und UDR-Konfiguration.
  • Dokumentieren und implementieren Sie ein Sicherheits- und Härtungskonzept. Entfernen Sie den Internet Explorer, erstellen Sie einen Active Directory-Container für SAP-Dienstkonten und -Server, und wenden Sie eine Firewallrichtlinie an, mit der alle bis auf eine begrenzte Anzahl von erforderlichen Ports blockiert werden.
  • Erstellen Sie ein Dokument für den Entwurf der Betriebssystem-/DB-Migration, in dem das Konzept für die Paket- und Tabellenaufteilung, die Anzahl von R3load-Prozessen, die SQL Server-Ablaufverfolgungsflags, sortiert/unsortiert, die Oracle RowID-Einstellung, die SMIGR_CREATE_DDL-Einstellungen, die Indikatoren der Leistungsüberwachung (z. B. BCP-Zeilen pro Sekunde und BCP-Durchsatz in KB/Sekunde, CPU, Arbeitsspeicher), die RSS-Einstellungen, die Einstellungen für den beschleunigten Netzwerkbetrieb, die Protokolldateikonfiguration, die BPE-Einstellungen und die TDE-Konfiguration aufgeführt sind.
  • Erstellen Sie ein Diagramm des Ablaufplans, das den Fortschritt des R3load-Exports/-Imports in jedem Testzyklus zeigt. Auf diese Weise kann das Migrationsteam überprüfen, ob Optimierungen und Änderungen die Export- oder Importleistung von R3load verbessern. Die X-Achse gibt die Anzahl der abgearbeiteten Pakete, die Y-Achse die verstrichene Zeit an. Dieser Ablaufplan ist auch während der Produktionsmigration von entscheidender Bedeutung, damit der geplante Fortschritt mit dem tatsächlichen Fortschritt verglichen und etwaige Probleme frühzeitig erkannt werden können.
  • Erstellen Sie einen Plan zum Testen der Leistung. Identifizieren Sie die 20 wichtigsten Onlineberichte, Batchaufträge und Schnittstellen. Dokumentieren Sie die Eingabeparameter (z. B. Datumsbereich, Vertriebsbüro, Werk, Buchungskreis usw.) und Laufzeiten auf dem ursprünglichen Quellsystem. Vergleichen Sie die Werte mit der Laufzeit in Azure. Wenn es Leistungsunterschiede gibt, führen Sie SAT, ST05 und andere SAP-Tools aus, um ineffiziente Anweisungen zu identifizieren.
  • Überprüfen Sie die Bereitstellung und Konfiguration, und stellen Sie sicher, dass Clustertimeouts, Kernel, Netzwerkeinstellungen und NTFS-Formatgröße mit den Planungsdokumenten übereinstimmen. Legen Sie die Indikatoren der Leistungsüberwachung auf wichtigen Servern so fest, dass alle 90 Sekunden grundlegende Integritätsparameter erfasst werden. Stellen Sie sicher, dass sich die SAP-Server in einem separaten AD-Container befinden und dass auf den Container eine Gruppenrichtlinie mit Firewallkonfiguration angewendet wird.
  • Vergewissern Sie sich, dass der leitende Berater für die Betriebssystem-/DB-Migration über eine Lizenz verfügt. Fordern Sie den Namen des Beraters, die S-User-ID und das Zertifizierungsdatum an. Senden Sie eine OSS-Nachricht an BC-INS-MIG, und bitten Sie SAP um eine Bestätigung, dass der Berater aktuell und lizenziert ist.
  • Nach Möglichkeit sollte das gesamte Projektteam, das an dem VLDB-Migrationsprojekt beteiligt ist, an einem einzigen physischen Standort arbeiten und nicht über mehrere Kontinente und Zeitzonen verteilt sein.
  • Vergewissern Sie sich, dass ein geeigneter Fallbackplan vorhanden ist und in den Gesamtplan aufgenommen wurde.
  • Wählen Sie für die R3load-Exportserver Intel-CPU-Modelle mit hoher Threadzahl aus. Verwenden Sie keine energiesparenden CPU-Modelle, da diese eine geringere Leistung aufweisen und nicht für 4-Socket-Server geeignet sind. Intel Xeon E5 Platinum 8158 ist ein gutes Beispiel.

Bewährte Methoden zur Vermeidung von Problemen

  • Beauftragen Sie nicht ein Beratungsunternehmen mit dem Export und ein anderes mit dem Import. Mitunter ist das Quellsystem ausgelagert und wird von einem Beratungsunternehmen oder Partner verwaltet, und ein Kunde möchte zu Azure migrieren und zu einem anderen Partner wechseln. Aufgrund der engen Verknüpfung von Export- und Importoptimierung und -konfiguration ist es unwahrscheinlich, dass die Zuweisung dieser Aufgaben an verschiedene Organisationen zu einem guten Ergebnis führt.
  • Sparen Sie während der Migration und Liveschaltung nicht bei den Azure-Hardwareressourcen. Azure-VMs werden pro Minute in Rechnung gestellt und können problemlos verkleinert werden. Nutzen Sie während einer VLDB-Migration den leistungsstärksten virtuellen Computer, der verfügbar ist. Kunden haben mit 200–250 % überdimensionierten Systemen eine erfolgreiche Liveschaltung durchgeführt und konnten anschließend bei Ausführung überdimensionierter Systeme eine Stabilisierung erreichen. Nach einer Überwachung der Systemauslastung für 4–6 Wochen werden die VMs mit übermäßiger Kapazität verkleinert oder heruntergefahren, um die Kosten zu senken.