Erfahrungen mit dem Wechsel von SAP-Hosting: So migrieren Sie Systeme schmerzfrei

Oder kann man? Natürlich ist die Migration von SAP-Systemen ein komplexer und gewissenhafter Prozess, bei dem die koordinierte Zusammenarbeit aller Beteiligten entscheidend für den Erfolg ist. Wenn die Migration in kurzer Zeit erfolgen muss, wird die Aufgabe erheblich komplizierter. Nicht jeder traut sich das zu. Die Gründe können vielfältig sein. Zum Beispiel ist der Prozess an sich zeitaufwendig und organisatorisch anspruchsvoll. Außerdem besteht die Gefahr von unvorhergesehenen Ausfallzeiten der Systeme. Oder die Kunden sind sich nicht sicher, ob sie nach einem solchen Eingriff die Vorteile erhalten, die den Aufwand rechtfertigen. Es gibt jedoch Ausnahmen.

Im Folgenden werden wir die Herausforderungen besprechen, mit denen Auftraggeber während der Migration und dem Betrieb von SAP-Systemen konfrontiert sind, diskutieren, warum Klischees nicht immer der Realität entsprechen, und einen Fall präsentieren, in dem wir es geschafft haben, die Systeme eines Auftraggebers innerhalb von etwas mehr als drei Monaten in eine neue Infrastruktur zu migrieren.

Hosting von SAP-Systemen

Vor etwa fünf Jahren war es kaum vorstellbar, dass Kunden zunehmend Hosting-Ressourcen für SAP-Anwendungen nutzen würden. In den meisten Fällen wurden sie vor Ort implementiert. Doch mit der Entwicklung von Outsourcing-Modellen und dem Markt für Cloud-Dienste hat sich die Perspektive der Kunden gewandelt. Welche Argumente sprechen für die Wahl der Cloud für SAP?

• Für Einsteiger, die gerade die Implementierung von SAP planen, ist eine Cloud-Infrastruktur praktisch die Standardwahl – Skalierbarkeit der Ressourcen entsprechend den aktuellen Bedürfnissen des Systems und der Wunsch, keine Ressourcen für die Entwicklung von Fachkompetenzen abzuzweigen.
• In Unternehmen mit komplexen Systemlandschaften erreichen CIOs durch das Hosting von SAP-Systemen eine qualitativ höhere Risikoverwaltung, da der Partner für die SLA verantwortlich ist.
• Das dritte häufigste Argument ist die hohe Kosten für den Aufbau einer Infrastruktur zur Umsetzung von Hochverfügbarkeits- und DR-Szenarien.
• Faktor 2027 – die vom Anbieter angekündigte Einstellung der Unterstützung für veraltete Systeme im Jahr 2027. Dies bedeutet eine Migration der Datenbanken auf HANA, was mit erheblichen Kosten für Modernisierungen und den Erwerb neuer Rechenkapazitäten verbunden ist.

Der Markt für SAP-Hosting in Russland kann jetzt als ausreichend reif betrachtet werden. Dies schafft umfangreiche Möglichkeiten für Kunden, die ihre Hosting-Plattformen wechseln möchten. Allerdings können solche Projekte zu Recht Bedenken bei Unternehmen hervorrufen, aufgrund der Komplexität des Migrationsprozesses. Dies zwingt die Auftraggeber dazu, erhöhte Anforderungen an die Dienstleister zu stellen, die nicht nur über hervorragende Kompetenzen im Hosting und Support von SAP-Systemen verfügen, sondern auch über erfolgreiche Erfahrung im Bereich Migration.

Was sind die Herausforderungen beim Wechsel des SAP-Hostings?

Hosting-Angebote gibt es viele. Ein Mangel an Übereinstimmung mit dem angegebenen Serviceniveau, zahlreiche „aber“ und Sternchen mit kleinen Druckbedingungen, sowie eine Begrenzung der Ressourcen und Möglichkeiten. Hosting-Anbieter, mangelnde Flexibilität in der Kommunikation mit dem Kunden, Bürokratie, technische Einschränkungen, geringe Kompetenz des technischen Supports und viele weitere Nuancen sind nur einige der Fallstricke, mit denen Kunden konfrontiert werden können, wenn sie ihre Geschäftssysteme in Outsourcing-Infrastrukturen betreiben. Oft bleibt dies für den Kunden im Verborgenen, verborgen in den Tiefen eines mehrseitigen Vertrags, und wird erst im Zuge der Nutzung der Dienstleistungen offensichtlich.

Irgendwann wird dem Kunden klar, dass das Serviceniveau, das er erhält, weit von seinen Erwartungen entfernt ist. Dies fungiert als Katalysator für die Suche nach Lösungen zur Behebung der Situation, und im Falle eines Misserfolgs, wenn sich die Probleme bis zur Schmerzgrenze auftürmen, kommen sie zu aktiven Maßnahmen zur Erarbeitung alternativer Optionen für einen Anbieterwechsel.

Warum werden die Dinge bis zur letzten Minute hinausgezögert? Der Grund ist einfach – der Prozess der Systemmigration für Kunden ist nicht immer transparent und verständlich. Es fällt dem Kunden schwer, die tatsächlichen Risiken, die mit dem Migrationsprozess verbunden sind, zu beurteilen. Man könnte sagen, dass die Migration für die Kunden eine Art schwarze Box ist: Unklar sind die Kosten, die Ausfallzeiten der Systeme, die Risiken und wie man sie minimieren kann, und insgesamt herrscht eine gewisse Angst. Schließlich, wenn es nicht funktioniert, haben sowohl die Führungskräfte als auch die Mitarbeiter Konsequenzen zu befürchten.

SAP sind Systeme auf Unternehmensebene, komplex und gelinde gesagt nicht günstig. Für ihre Implementierung, Anpassung und Wartung werden erhebliche Budgets aufgewendet, und die Verfügbarkeit und reibungslose Funktion sind entscheidend für den Betrieb des Unternehmens. Stellen Sie sich nun die Folgen eines Stillstands in einer großen Produktionsstätte vor. Das sind finanzielle Verluste, die sich in Zahlen mit vielen Nullen summieren können, sowie Reputationsschäden und andere nicht minder bedeutende Risiken.

Lassen Sie uns die Schwierigkeiten untersuchen, die in jeder Phase beim Migration eines SAP-Systems eines unserer Kunden auftreten können.

Vorbereitung und Projektierung

Migration ist eine komplexe Angelegenheit mit vielen verschiedenen Faktoren. Einer der wichtigsten Aspekte ist die Phase der Planung und Vorbereitung der Zielinfrastruktur.

Wir mussten uns intensiv mit der bestehenden Systemimplementierung und deren Architektur auseinandersetzen. In der Zielinfrastruktur haben wir in einigen Bereichen bestehende Lösungen wiederholt, während wir in anderen Aspekten Verbesserungen und Ergänzungen vorgenommen haben. Zudem haben wir Lösungen zur Gewährleistung von Ausfallsicherheit und Verfügbarkeit entwickelt und alle Ressourcen so weit wie möglich konsolidiert.

Im Verlauf der Planung wurden viele verschiedene Übungen durchgeführt, die uns schließlich dazu verhalfen, uns optimal auf die Migration vorzubereiten und alle möglichen Nuancen sowie Fallstricke zu berücksichtigen.

Das Ergebnis ist eine individuell gestaltete Infrastruktur eines privaten Clouds, basierend auf unserem Rechenzentrum:

• dedizierte physische Server für SAP HANA;
• VMware-Virtualisierungsplattform für Anwendungsserver und Infrastruktur-Services;
• redundante Kommunikationskanäle zwischen den Rechenzentren für L2; VPN;
• zwei Hauptspeicherlösungen zur Trennung von Produktions und 'übrigen' Daten;
• SRK auf Basis von Veritas Netbackup mit einem separaten Server, einer Festplattenspeicherlösung und einer Bandbibliothek.

So haben wir das technisch umgesetzt.

SAP

• Für die effiziente Nutzung von Speichern für produktive HANA haben wir gemeinsame Laufwerke ohne systematische DB-Replikation mittels SAP verwendet. Das Ganze haben wir in einem Active-Standby-Cluster von SUSE HAE basierend auf Pacemaker umgesetzt. Ja, die Wiederherstellungszeit ist etwas länger als bei der Replikation, aber wir erhalten eine halbierte Speicherkapazität des Speicher-Systems und dadurch Einsparungen im Budget des Kunden.
• In den präproduktivem Umgebungen haben wir auf Cluster-HANA verzichtet, aber technisch die Konfiguration der produktiven Systeme nachgebildet.
• Testumgebungen und Entwicklungssysteme wurden auf mehrere Server ohne Cluster in der MCOS-Konfiguration verteilt.
• Alle Anwendungsserver wurden virtualisiert und in VMware platziert.

Netzwerke

• Physisch haben wir die Netzwerke für Verwaltung und Produktivität durch Switch-Stapel getrennt und die produktiven in Richtung des Rechenzentrums des Kunden geleitet.
• Es wurden ausreichend Netzwerkschnittstellen vorgesehen, um große Datenverkehrsströme nicht zu vermischen.
• Für die Datenübertragung mit den Speicher-Systemen haben wir klassische FC SAN-Fabriken eingerichtet.

Speicher-System

• Die produktive und präproduktive SAP-Last wurde auf einem All-Flash-Array abgelegt.
• Entwickler-Testumgebungen und Infrastrukturservices wurden auf einem separaten hybriden Array platziert.

SRK

• Wurde auf Basis von Veritas NetBackup erstellt.
• Wir haben einige eingebaute Skripte ergänzt, um MCOS-Konfigurationen zu sichern.
• Die sofortigen Backups wurden auf ein Speichergestell gelegt, um eine schnelle Wiederherstellung zu gewährleisten; für die langfristige Speicherung nutzen wir Bänder.

Überwachung

• Alle Hardware, Betriebssysteme und SAP werden unter Zabbix überwacht.
• Wir haben zahlreiche nützliche Dashboards in Grafana erstellt.
• Im Falle eines Zabbix-Alerts kann ein Ticket im Incident-Management-System erstellt werden, das bei uns über Jira realisiert ist. Zudem wird die Information in einen Telegram-Kanal dupliziert.

Telegram

Allgemeiner Zustand von HANA

Zustand des SAP-Anwendungsservers:

Infrastrukturservices

• Um interne Namensräume zu bedienen, haben wir einen Cluster von DNS-Servern eingerichtet, der mit den Servern des Kunden synchronisiert wird.
• Wir haben einen separaten Dateiserver für den Datenaustausch eingerichtet.
• Um verschiedene Konfigurationen zu speichern, haben wir GitLab hinzugefügt.
• Für verschiedene sensible Informationen nutzen wir HashiCorp Vault.

Migrationsprozess

Im Allgemeinen besteht der Migrationsprozess aus folgenden Phasen:

• Vorbereitung aller erforderlichen Projektdokumente;
• Verhandlungen mit dem aktuellen Anbieter — Lösung organisatorischer Fragen;
• Einkauf, Lieferung und Installation neuer Hardware für das Projekt;
• Testmigration und Anpassung des Prozesses;
• Übertragung der Systeme, produktive Migration.

Ende Oktober 2019 haben wir den Vertrag unterzeichnet, danach die Architektur entworfen und nach Zustimmung des Kunden die erforderliche Hardware bestellt.

Worauf man in erster Linie achten sollte — die Lieferzeiten der Hardware. Im Durchschnitt dauert die Lieferung von zertifizierter Hardware für SAP NAHA, die den Anforderungen des Softwareherstellers an die Hardwareplattformen entspricht, 10–12 Wochen. Und aufgrund der Saisonalität (die Umsetzung des Projekts fiel genau auf Neujahr) konnte sich dieser Zeitraum um einen weiteren Monat verlängern. Daher musste der Prozess so schnell wie möglich beschleunigt werden: Wir arbeiteten mit dem Distributor-Lieferanten zusammen und vereinbarten eine schnellere Lieferung per Flugzeug (anstatt auf Land- und Seewegen).

November und Dezember wurden für die Vorbereitung der Migration und den Erhalt eines Teils der Hardware genutzt. Die Vorbereitungen fanden auf einer Testumgebung in unserer Public Cloud statt, wo wir alle grundlegenden Schritte durchliefen und mögliche Komplikationen und Probleme identifizierten:

• wir haben einen detaillierten Plan für die Interaktion der Projektteams mit minutengenauen Zeitplänen erstellt;
• wir haben eine Testumgebung für die Datenbanken und Anwendungsserver eingerichtet, die der Zielinfrastruktur ähnlich war;
• wir haben die notwendigen Kommunikationskanäle und Infrastrukturservices konfiguriert, um die Funktionsfähigkeit der Integrationen zu überprüfen;
• wir haben die Cutover-Szenarien geübt;
• die Cloud hat uns zudem geholfen, vorkonfigurierte Vorlagen für virtuelle Maschinen zu erstellen, die wir später einfach importierten und in der Zielarchitektur bereitstellten.

Kurz vor den Weihnachtsferien traf die erste Lieferung von Hardware bei uns ein. Dadurch konnten wir einige Systeme auf echter Hardware bereitstellen. Da nicht alles ankam, haben wir Ersatzhardware angeschlossen, über deren Lieferung wir mit dem Anbieter und den Distributoren verhandeln konnten. Den Rest der Zielinfrastruktur erhielten wir bereits in der finalen Phase.
Um die Frist einzuhalten, mussten unsere Ingenieure die Weihnachtsferien opfern und am 2. Januar mit den Vorbereitungen der Zielinfrastruktur beginnen – mitten in den Feiertagen. Ja, das kommt vor, wenn es brennt und es keine anderen Optionen gibt. Auf dem Spiel standen die Funktionsfähigkeit der Systeme, von denen das Unternehmen abhängt.

Der allgemeine Ablauf der Migration sah so aus: zuerst die am wenigsten kritischen Systeme (Entwicklungsumgebung, Testumgebung), dann die produktiven Systeme. Die finale Phase der Migration fand Ende Januar bis Anfang Februar statt.

Der Migrationsprozess war bis ins kleinste Detail geplant. Es handelt sich um einen Cutover-Plan mit einer Liste aller Aufgaben, der Ausführungszeiten und der verantwortlichen Personen. Alle Schritte wurden bereits in einer Testmigration erprobt, daher musste während der eigentlichen Migration nur noch dem Plan gefolgt und der Prozess koordiniert werden.

Die Migration wurde systematisch in mehreren Phasen durchgeführt. In jeder Phase wurden zwei Systeme migriert.

Das Ergebnis des drei Monate dauernden Sprints war ein vollständig funktionierendes System im Rechenzentrum KROK. Insgesamt wurde dieses positive Resultat durch die enge Zusammenarbeit erzielt, wobei der Beitrag und das Engagement aller Beteiligten auf höchstem Niveau waren.

Die Rolle des Auftraggebers im Projekt

Die Kommunikation mit dem Provider, den unser Kunde verlassen hat, war nicht einfach. Das ist verständlich, denn sie gehörten zu den letzten, die am erfolgreichen Abschluss des Projekts interessiert waren. Der Auftraggeber übernahm die Aufgaben der Eskalation und der Koordination aller Kommunikationsfragen und hat dies zu 100,5 % gemeistert. Dafür gebührt ihm ein besonderer Dank. Ohne dieses aktive Engagement im Prozess hätte das Projektergebnis ganz anders ausfallen können.

Durch die Formalisierung der Prozesse beim "ehemaligen" Anbieter wurde die Infrastruktur von Fachleuten überwacht, die in der Tat weit entfernt von den Problemen des damaligen Auftraggebers waren. Beispielsweise konnte der Export derselben Datenbank zwischen einer und fünf Stunden in Anspruch nehmen. Damals schien das wie Magie, ein Geheimnis, das uns nie offenbart wurde. Wahrscheinlich widmeten sich die Support-Techniker nebenbei der Meditation und vergaßen, dass irgendwo in weit entferntem Russland Deadlines waren, Ingenieure ohne Weihnachtsleckereien litten und der Auftraggeber weinte…

Projektübersicht

Der letzte Schritt der Migration war die Übergabe der Systeme zur Betreuung.

Jetzt bieten wir einen zentralen Service für Kundenanfragen und erledigen alle Aufgaben rund um die Betreuung der Infrastrukturkomponenten und SAP-Basis gemeinsam mit unserem Partner — itelligence. Der Kunde lebt seit einem halben Jahr in der Private Cloud. Hier sind die Statistiken zu den Servicefällen in dieser Zeit:

• 90 Vorfälle (20% wurden ohne Einbindung des Auftraggebers gelöst)
• Im Rahmen des SLA gelöst – 100%
• Ungeplante Systemausfälle – 0

Wenn Sie ähnliche Aufgaben haben wie unser Kunde und mehr darüber erfahren möchten, wie Sie diese lösen können, schreiben Sie an: ahaidukov@croc.ru

Quelle: habr.com