🥇Erfahrungen beim Wechsel des SAP-Hostings: Wie man Systeme migriert, ohne unnötige Schwierigkeiten zu haben

Oder ist das möglich? Natürlich ist die Migration von SAP-Systemen ein komplexer und mühsamer Prozess, dessen Erfolg die koordinierte Zusammenarbeit aller Beteiligten erfordert. Wenn die Migration in einem engen Zeitrahmen erfolgt, wird die Aufgabe mehrfach erschwert. Nicht jeder traut sich das zu. Es kann mehrere Gründe dafür geben. Zum Beispiel ist der Prozess an sich langwierig und organisatorisch komplex. Außerdem besteht das Risiko ungeplanter Ausfallzeiten der Systeme. Oder Kunden sind sich nicht sicher, dass sie nach einer solchen Operation Vorteile erhalten, die den investierten Aufwand rechtfertigen. Es gibt jedoch auch Ausnahmen.

Im folgenden Artikel werden wir über die Schwierigkeiten sprechen, mit denen Kunden bei der Migration und Wartung von SAP-Systemen konfrontiert sind, erörtern, warum Klischees nicht immer der Realität entsprechen, und einen Fall vorstellen, in dem es uns gelungen ist, die Systeme eines Kunden in weniger als drei Monaten in eine neue Infrastruktur zu migrieren.

Hosting von SAP-Systemen

Vor noch fünf Jahren wäre es schwer vorstellbar gewesen, dass Kunden massenhaft Hosting-Ressourcen für SAP-Anwendungen nutzen würden. In den meisten Fällen wurden sie on-premise implementiert. Mit der Entwicklung von Outsourcing-Modellen und dem Markt für Cloud-Dienste begann sich jedoch die Sichtweise der Kunden zu ändern. Was sind die Argumente, die für die Wahl der Cloud für SAP sprechen?

Für Anfänger, die gerade die Einführung von SAP planen, ist eine Cloud-Infrastruktur praktisch die Standardwahl – die Skalierbarkeit von Ressourcen basierend auf dem aktuellen Bedarf des Systems und das Verlangen, Ressourcen nicht auf die Entwicklung nicht verwandter Kompetenzen abzulenken.
In Unternehmen mit umfangreicher Systemlandschaft gelangen CIOs durch das Hosting von SAP-Systemen auf eine qualitativ neue Ebene des Risikomanagements, weil der Partner für den SLA verantwortlich ist.
Das dritte der häufigsten Argumente ist die hohe Kosten für den Aufbau einer Infrastruktur zur Realisierung von Szenarien mit hoher Verfügbarkeit und DR.
Faktor 2027 – die vom Anbieter angekündigte Einstellung der Unterstützung für veraltete Systeme im Jahr 2027. Das bedeutet die Migration der Datenbank auf HANA, was mit Kosten für Modernisierung und den Erwerb neuer Rechenressourcen verbunden ist.

Der SAP-Hosting-Markt in Russland kann derzeit als relativ ausgereift betrachtet werden. Dies bietet breite Möglichkeiten für Kunden, die ihre Hosting-Plattformen wechseln möchten. Solche Projekte können jedoch verständlicherweise Bedenken bei Unternehmen hervorrufen, da der Migrationsprozess komplex ist. Dies zwingt die Auftraggeber dazu, erhöhte Anforderungen an die Dienstleister zu stellen, die nicht nur über außergewöhnliche Kompetenzen im Hosting und in der Unterstützung von SAP-Systemen verfügen müssen, sondern auch über erfolgreiche Erfahrungen im Bereich Migration.

Was sind die Schwierigkeiten beim Wechsel des SAP-Hostings?

Es gibt verschiedene Hosting-Anbieter. Abweichungen vom angekündigten Serviceniveau, viele "aber" und Sterne mit kleinen Textausschlüssen, begrenzte Ressourcen und Möglichkeiten Hosting-Anbieter, fehlende Flexibilität in der Kommunikation mit dem Kunden, Bürokratie, technische Einschränkungen, geringe Kompetenz der Techniksupportmitarbeiter sowie viele andere Nuancen – dies ist nur ein kleiner Teil der Stolpersteine, mit denen Kunden während der Nutzung ihrer Geschäftssysteme in Outsourcing-Infrastrukturen konfrontiert sein können. Oft bleibt all dies für den Kunden im Dunkeln, verborgen im Dickicht eines mehrseitigen Vertrags, und taucht erst im Laufe der Nutzung der Dienste auf.

Irgendwann wird dem Auftraggeber klar, dass das Serviceniveau, das er erhält, weit von seinen Erwartungen entfernt ist. Dies dient als Katalysator für die Suche nach Lösungen zur Behebung der Situation und im Falle eines Misserfolgs, wenn sich Probleme bis zur Schmerzgrenze häufen, treten sie aktiv an die Planung alternativer Optionen für den Wechsel des Dienstleisters heran.

Warum wird bis zur letzten Minute gewartet? Der Grund ist einfach – der Prozess der Übertragung von Systemen ist für die Kunden nicht immer transparent und verständlich. Es fällt dem Kunden schwer, die tatsächlichen Risiken im Zusammenhang mit dem Migrationsprozess zu bewerten. Man kann sagen, dass Migration für Kunden eine Art schwarzer Kasten ist: Unklar sind Preis, Ausfallzeit der Systeme, Risiken und wie man diese mindert, und überhaupt ist alles dunkel und beängstigend. Es ist so, wenn es nicht klappt, verlieren sowohl die Führungskräfte als auch die Ausführenden ihren Kopf.

SAP ist ein komplexes, unternehmensweites System, das man freundlich gesagt nicht günstig nennen kann. Die Implementierung, Anpassung und Wartung erfordern erhebliche Budgets, und die Verfügbarkeit sowie die korrekte Funktionsweise hängen maßgeblich von der Lebensfähigkeit des Unternehmens ab. Stellen Sie sich nun die Folgen der Stilllegung einer großen Produktion vor. Dies sind finanzielle Verluste, die sich in Zahlen mit einer großen Anzahl von Nullen messen lassen, sowie reputationsbedingte und andere, nicht weniger bedeutende Risiken.

Lassen Sie uns die Herausforderungen analysieren, die in jeder Phase im Zusammenhang mit der Migration von SAP-Systemen eines unserer Kunden auftreten können.

Vorbereitung und Projektierung

Die Migration ist eine Formel mit vielen verschiedenen Komponenten. Eine der wichtigsten Phasen ist die Planung und Vorbereitung der Zielinfrastruktur (neuen Infrastruktur).

Wir mussten uns mit der bestehenden Implementierung der Systeme und ihrer Architektur auseinandersetzen. In der Zielinfrastruktur haben wir bestehende Lösungen teilweise wiederholt, in einigen Aspekten ergänzt und verbessert sowie in anderen Punkten umgestaltet, durchdacht und Lösungen zur Gewährleistung von Ausfallsicherheit und Verfügbarkeit gewählt, während wir alle Ressourcen maximal konsolidiert haben.

Im Rahmen der Planung wurden viele verschiedene Übungen durchgeführt, die letztendlich eine optimale Vorbereitung auf die Migration ermöglichten und alle möglichen Nuancen und Fallstricke (darauf später mehr) berücksichtigten.

Was wir letztendlich erreicht haben, ist eine individuell gestaltete Infrastruktur eines privaten Cloud-Systems auf der Basis unseres Rechenzentrums:

dedizierte physische Server für SAP HANA;
VMware-Virtualisierungsplattform für Anwendungsserver und Infrastrukturservices;
redundante Kommunikationskanäle zwischen Rechenzentren für L2; VPN;
zwei Hauptspeichersysteme zum Trennen von Produktiv- und 'aller anderen' Daten;
Backup-Lösungen basierend auf Veritas Netbackup mit einem separaten Server, einer Festplattenschublade und einer Bandbibliothek.

So haben wir all dies aus technischer Sicht umgesetzt.

SAP

Für die effiziente Nutzung von Speichern für produktive HANA setzen wir gemeinsame Festplatten ohne systematische Datenbankreplikation mit den Mitteln von SAP ein. All dies wurde in einen Active-Standby-Cluster von SUSE HAE auf Basis von Pacemaker integriert. Ja, die Wiederherstellungszeit ist etwas länger als mit Replikation, aber wir erhalten eine Reduzierung des Speicherplatzes im Speicher um das Zweifache und folglich eine Budgeteinsparung für den Kunden.
In den Präproduktionsumgebungen wurde auf Cluster HANA verzichtet, jedoch wurde die Produktivkonfiguration technisch nachgebildet.
Die Test- und Entwicklungsumgebungen wurden auf mehrere Server ohne Cluster in der MCOS-Konfiguration verteilt.
Alle Anwendungsserver wurden virtualisiert und in VMware untergebracht.

Netzwerke

Die Konturen der Verwaltungs- und Produktionsnetzwerke wurden physisch getrennt, wobei Produktionsnetzwerke in Richtung des Rechenzentrums des Kunden verlegt wurden.
Es wurden genügend Netzwerkinterfaces eingeplant, um große Datenströme nicht zu vermischen.
Für die Datenübertragung mit dem SAN haben wir klassische FC SAN-Fabriken eingerichtet.

Speichersystem

Die produktive und präproduktive SAP-Last wurde auf einem All-Flash-Array belassen.
Die Testumgebungen der Entwickler und Infrastrukturservices wurden auf einem separaten hybriden Array untergebracht.

SRK

Basierend auf Veritas Netbackup eingerichtet.
Einige eingebaute Skripte wurden erweitert, um die MCOS-Konfigurationen zu sichern.
Die Betriebs-Backups wurden auf einer Disk-Storage platziert, um eine schnelle Wiederherstellung zu ermöglichen, und für die langfristige Speicherung verwenden wir Bänder.

Überwachung

Alle Hardware, Betriebssysteme und SAP wurden in Zabbix erfasst.
Eine Vielzahl nützlicher Dashboards in Grafana wurde gesammelt.
Bei Auftreten eines Alarms kann Zabbix eine Anfrage im Incident-Management-System generieren, das bei uns auf Jira implementiert ist. Die Informationen werden auch im Telegram-Kanal dupliziert.

Allgemeiner Zustand HANA

Zustand des SAP-Anwendungsservers:

Infrastrukturservices

Für die Verwaltung der internen Namensräume wurde ein DNS-Server-Cluster eingerichtet, der mit den Servern des Kunden synchronisiert wird.
Ein separater Dateiserver für den Datenaustausch wurde eingerichtet.
Um verschiedene Konfigurationen zu speichern, wurde Gitlab hinzugefügt.
Für verschiedene vertrauliche Informationen haben wir HashiCorp Vault ausgewählt.

Migrationsprozess

Im Allgemeinen besteht der Migrationsprozess aus folgenden Phasen:

Vorbereitung aller erforderlichen Projektdokumentationen;
Verhandlungen mit dem aktuellen Anbieter – Lösung organisatorischer Fragen;
Einkauf, Lieferung und Installation neuer Hardware für das Projekt;
Testmigration und Prozessoptimierung;
Übertragung der Systeme, produktive Migration.

Ende Oktober 2019 haben wir einen Vertrag unterschrieben, anschließend die Architektur entworfen und nach deren Genehmigung durch den Kunden die erforderliche Hardware bestellt.

Was zuerst berücksichtigt werden muss, sind die Lieferzeiten der Ausrüstung. Im Durchschnitt dauert die Lieferung von zertifizierten Komponenten für SAP NAHA, die den Anforderungen des Softwareherstellers an Hardwareplattformen entsprechen, 10-12 Wochen. Und unter Berücksichtigung der Saisonalität (der Projektstart fiel genau auf den Jahreswechsel) könnte sich dieser Zeitraum um einen weiteren Monat verlängern. Folglich war es notwendig, den Prozess maximal zu beschleunigen: Wir arbeiteten mit dem Distributor-Lieferanten zusammen und vereinbarten eine beschleunigte Lieferung mit Flugzeugen (anstatt über Land- und Seewege).

November und Dezember wurden benötigt, um die Vorbereitung für die Migration abzuschließen und einen Teil der Ausrüstung zu erhalten. Die Vorbereitung fand an unserem Teststand im öffentlichen Cloud statt, wo wir alle wesentlichen Schritte durchführten und mögliche Schwierigkeiten und Probleme identifizierten:

Wir haben einen detaillierten Interaktionsplan der Projektteamteilnehmer mit minutengenauen Timings erstellt;
Wir haben einen Teststand für die Datenbank und die Anwendungsserver in etwa der gleichen Weise aufgebaut wie in der Zielinfrastruktur;
Wir haben die notwendigen Kommunikationskanäle und Infrastrukturservices eingerichtet, um die Funktionsweise der Integrationen zu überprüfen;
Wir haben Cutover-Szenarien erarbeitet;
Die Cloud half uns auch, vorinstallierte Vorlagen für virtuelle Maschinen zu erstellen, die wir später einfach importierten und in der Zielumgebung bereitstellten.

Kurz vor den Feiertagen kam die erste Lieferung von Ausrüstung zu uns. Dies ermöglichte es uns, Teile der Systeme auf echter Hardware zu implementieren. Da nicht alles angekommen war, schlossen wir Ersatzgeräte an, deren Lieferung wir mit dem Anbieter und den Distributoren vereinbaren konnten. Die restliche Zielinfrastruktur erhielten wir bereits in der finalen Phase.
Um rechtzeitig fertig zu werden, mussten unsere Ingenieure auf die Weihnachtsferien verzichten und die Arbeiten zur Vorbereitung der Zielinfrastruktur am 2. Januar, mitten im Festtagsgeschehen, aufnehmen. Ja, das passiert manchmal, wenn es brennt und keine anderen Optionen vorhanden sind. Es ging um die Funktionsfähigkeit der Systeme, von denen das Bestehen des Unternehmens abhängt.

Der allgemeine Ablauf der Migration sah folgendermaßen aus: Zuerst die am wenigsten kritischen Systeme (Entwicklungslandschaft, Testlandschaft), dann die produktiven Systeme. Die finale Phase der Migration fand Ende Januar bis Anfang Februar statt.

Der Migrationsprozess wurde bis ins kleinste Detail geplant. Dies ist ein Cutover-Plan mit einer Liste aller Aufgaben, Zeitrahmen und Verantwortlichkeiten. Alle Schritte wurden bereits bei der Testmigration erprobt, sodass während der Produktionsmigration nur der Plan befolgt und der Prozess koordiniert werden musste.

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

Das Ergebnis des dreimonatigen Sprints war ein vollständig funktionierendes System im Rechenzentrum von KROK. Insgesamt wurde ein positives Ergebnis durch die Zusammenarbeit erzielt, wobei der Beitrag und das Engagement aller Beteiligten maximal waren.

Die Rolle des Auftraggebers im Projekt

Es war nicht einfach, mit dem Provider zu kommunizieren, den unser Kunde verließ. Verständlicherweise waren sie die Letzten auf der Liste der Interessierten am erfolgreichen Abschluss des Projekts. Der Auftraggeber übernahm die Aufgaben der Eskalation und der Klärung aller Kommunikationsfragen und meisterte dies zu 100500%. Dafür einen besonderen Dank. Ohne dieses tatkräftige Engagement im Prozess hätte das Ergebnis des Projekts ganz anders ausfallen können.

Aufgrund der Formalisierung der Prozesse beim "früheren" Provider wurden die Infrastrukturfragen von Fachkräften betreut, die im wahrsten Sinne des Wortes weit von den Problemen des zu diesem Zeitpunkt noch bestehenden Auftraggebers entfernt waren. Zum Beispiel konnte der Export derselben Datenbank zwischen einer und fünf Stunden in Anspruch nehmen. Damals schien es uns wie Magie, ein Geheimnis, das uns nie offenbart wurde. Wahrscheinlich widmeten sich die Support-Techniker zwischen den Arbeiten der Meditation und vergaßen dabei, dass irgendwo in der fernen Russland Fristen, Ingenieure ohne Neujahrsalat, weinende und leidende Auftraggeber existierten...

Die Ergebnisse des Projekts

Der finale Akt der Migration war die Übergabe der Systeme zur Betreuung.

Jetzt bieten wir einen Service für einheitliche Anfragen des Auftraggebers an und decken das gesamte Volumen an Aufgaben zur Betreuung der Infrastrukturkomponenten und SAP Basis gemeinsam mit dem Partner — itelligence. Der Kunde lebt seit einem halben Jahr in einer privaten Cloud. Hier sind die Statistiken zu den Servicefällen in dieser Zeit:

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

Wenn Sie Aufgaben haben, die denjenigen unseres Kunden ähnlich sind, und Sie mehr darüber erfahren möchten, wie Sie diese lösen können, schreiben Sie: ahaidukov@croc.ru

Quelle: habr.com