SAP in der Cloud

Mit SAP S/4 Hana in die "SAP Cloud" umsteigen

Uhr
von Damian Tometzki, Functional Lead SAP on Hyperscaler; Philipp Blum, Head of Technology & Managed Services, NTT Data Business Solutions Schweiz

Das dynamische Business von heute erfordert ein Höchstmass an Flexibilität, Agilität und Innovation. Hohe Investitionen in kapazitätsbeschränkte Systeme sind nicht mehr zielführend. Es braucht skalierbare Lösungen mit weltweitem Zugriff. Eine eigene Cloud-Strategie ist deshalb unumgänglich.

SAP bietet verschiedene Möglichkeiten, in die Cloud einzusteigen. Das Lizenzmodell erklärt die Varianten: SAP S/4 Hana Public und Private Cloud sind Software-as-a-Service (SaaS) und werden von SAP betrieben. SAP S/4 Hana On-Premise kann im eigenen oder Partner-Datacenter, der SAP Hana Enterprise Cloud oder einem Hyperscaler betrieben werden.

Die Wahl des Public-Cloud-Providers (z.B. Azure, AWS, Google Cloud) ist essenziell: Datenhaltung, Datenschutz und regionale Abhängigkeiten, wie Kosten, Serviceverfügbarkeit und Latenzen, bilden wichtige Entscheidungsfaktoren. Die geografische Standortwahl ist ausschlaggebend für die Skalierbarkeit, Verfügbarkeit von Zonen und In­stanz-Typen sowie um die Verbindungskosten und Latenzen tief zu halten.

Für die Dimensionierung des virtuellen Datacenters sind ein genügend grosses Netzwerk sowie die zugehörigen Subnetze und die künftige Grösse der SAP-Systemlandschaft wesentlich. Best Practice ist, das Netzwerk ausreichend gross anzulegen und Reserven für zukünftige Expansionen einzuplanen. Hierzu sollte die Cloud-Strategie detailliert Auskunft geben.

Fragen zur Verfügbarkeit klären

Weiter ist es wichtig, sich Gedanken zur Systemverfügbarkeit zu machen. Ist ein 24/7-Betrieb der gesamten SAP-Systemlandschaft notwendig oder ist eine Verfügbarkeit der (oder einiger) non-produktiven Systeme zu Bürozeiten ausreichend? Der Break-even für einen Applikationsserver liegt bei zirka 280 h/Monat, bei einem Hana-Datenbankserver bei zirka 210 h/Monat (im Vergleich zu Pay-as-you-Go und einer 3-Jahre-Reserved-Instance). Mit diesen Betrachtungen können Kosten reduziert werden.

Bei der Auswahl der Instanz-Typen der VM (Virtual Machine) und dem Sizing ist zu prüfen, ob die getroffene Wahl für den produktiven Betrieb des Cloud-Anbieters freigegeben und von SAP für den Einsatzzweck zertifiziert ist. Beim Sizing der Hana-Datenbank geben vorhandene SAP-Reports (z.B. /SDF/HDB_SIZING für ERP) einen Anhaltspunkt. Bei der Wahl des Storage sind die Herstellerfreigaben ebenfalls zu beachten. Zudem sind Local vs. Geo-redundant Storage sowie der jeweilige Storage Type (Standard, Premium oder Ultra SSD) wichtige – und kos­tentreibende – Kriterien.

Für eine hohe Verfügbarkeit und Desaster-Toleranz ist die Anzahl VM-Instanzen ein wichtiger Faktor. Bei der Konzipierung von Hana System Replication (HSR) gilt es, wichtige Punkte zu beachten: ASYNC ist die einzige Option bei regionsübergreifendem HSR. SYNC und SYNCMEM sind für den primären Cluster reserviert. HSR sollte in der primären Region zwischen zwei oder mehreren Verfügbarkeitszonen eingerichtet werden.

Für Applikationsserver (AS) sind folgende Szenarien im Desaster Recovery (DR) Set-up zu empfehlen: Einsatz von Replikations- und Recovery-Optionen sowie Aufbau mehrerer Applikationsserver in unterschiedlichen Verfügbarkeitszonen (AZ) in der primären Region.

Bei der individuellen Cloud-Strategie ist und bleibt jedoch der wichtigste Punkt, die Sicherheitsrichtlinien der Anbieter zu verstehen – vor allem, wenn es um sensible Informationen Ihres Unternehmens geht. Denn nicht in jedem Land gelten dieselben gesetzlichen Datenschutzanforderungen.

Webcode
DPF8_272317