Der Netapp Architektur Sind
Änderungen vorschlagen
PDFs
SAP HANA-Hosts sind über eine redundante FCP-Infrastruktur und Multipathing-Software mit den Storage Controllern verbunden. Eine redundante FCP Switch-Infrastruktur ist erforderlich, um eine fehlertolerante SAP HANA Host-zu-Storage-Konnektivität bei Ausfall von Switch oder Host Bus Adapter (HBA) bereitzustellen. Ein entsprechendes Zoning muss am Switch konfiguriert werden, damit alle HANA Hosts die erforderlichen LUNs auf den Storage Controllern erreichen können.
Auf der Storage-Ebene können verschiedene Modelle der FAS Produktfamilie verwendet werden. Die maximale Anzahl an an mit dem Storage verbundenen SAP HANA-Hosts wird durch die Performance-Anforderungen von SAP HANA definiert. Die Anzahl der benötigten Platten-Shelves richtet sich nach den Kapazitäts- und Performance-Anforderungen der SAP HANA-Systeme.
Die folgende Abbildung zeigt eine Beispielkonfiguration mit acht SAP HANA-Hosts, die an ein Storage HA-Paar angeschlossen sind.
Diese Architektur lässt sich in zwei Dimensionen skalieren:
-
Durch das Anschließen zusätzlicher SAP HANA-Hosts und Festplattenkapazität an den Storage, sofern die Storage-Controller bei der neuen Last genügend Performance bieten können, um wichtige Performance-Kennzahlen (KPIs) zu erfüllen.
-
Durch Hinzufügen weiterer Storage-Systeme und Festplattenkapazität für die zusätzlichen SAP HANA-Hosts
Die folgende Abbildung zeigt ein Konfigurationsbeispiel, in dem mehr SAP HANA-Hosts mit den Storage-Controllern verbunden sind. In diesem Beispiel sind mehr Platten-Shelves erforderlich, um die Kapazitäts- und Performance-Anforderungen der 16 SAP HANA-Hosts zu erfüllen. Abhängig von den Anforderungen an den Gesamtdurchsatz müssen die Storage Controller um zusätzliche FC-Verbindungen erweitert werden.
Unabhängig vom implementierten FAS Storage-Modell lässt sich die SAP HANA Landschaft auch durch Hinzufügen weiterer Storage-Controller skalieren, wie in der folgenden Abbildung dargestellt.
SAP HANA Backup
Die NetApp ONTAP Software bietet einen integrierten Mechanismus für das Backup von SAP HANA Datenbanken. Storage-basiertes Snapshot Backup ist eine vollständig unterstützte und integrierte Backup-Lösung, die für SAP HANA Single-Container-Systeme und SAP HANA MDC-Einzelmandanten-Systeme verfügbar ist.
Storage-basierte Snapshot Backups werden mithilfe des NetApp SnapCenter Plug-ins für SAP HANA implementiert, das über die von der SAP HANA Datenbank bereitgestellten Schnittstellen konsistente Storage-basierte Snapshot Backups ermöglicht. SnapCenter registriert die Snapshot-Backups im SAP HANA Backup-Katalog, damit die Backups im SAP HANA Studio sichtbar sind und für Restore- und Recovery-Vorgänge ausgewählt werden können.
Mit der NetApp SnapVault Software können die auf dem Primärspeicher erstellten Snapshot Kopien auf dem sekundären Backup-Storage repliziert werden, der von SnapCenter gesteuert wird. Für Backups auf dem primären Storage und für Backups auf dem sekundären Storage können unterschiedliche Richtlinien zur Backup-Aufbewahrung definiert werden. Das SnapCenter Plug-in für SAP HANA Database managt die Aufbewahrung von auf Snapshot Kopien basierenden Daten-Backups und Log-Backups, einschließlich der allgemeinen Ordnung des Backup-Katalogs. Das SnapCenter Plug-in für SAP HANA Database ermöglicht darüber hinaus die Überprüfung der Blockintegrität der SAP HANA Datenbank durch ein dateibasiertes Backup.
Die Datenbankprotokolle können mithilfe eines NFS-Mount-Speichers direkt auf dem sekundären Storage gesichert werden, wie in der folgenden Abbildung dargestellt.
Storage-basierte Snapshot Backups bieten im Vergleich zu dateibasierten Backups entscheidende Vorteile. Zu diesen Vorteilen zählen unter anderem:
-
Schnelleres Backup (wenige Minuten)
-
Schnellere Restores auf Storage-Ebene (wenige Minuten)
-
Keine Auswirkungen auf die Performance des SAP HANA Datenbank-Hosts, Netzwerks oder Storage während des Backups
-
Platzsparende und bandbreiteneffiziente Replizierung auf Basis von Blockänderungen auf sekundärem Storage
Weitere Informationen zur Backup- und Recovery-Lösung SAP HANA mit SnapCenter finden Sie unter "TR-4614: SAP HANA Backup and Recovery with SnapCenter".
Disaster Recovery für SAP HANA
SAP HANA Disaster Recovery kann mithilfe von SAP-Systemreplizierung oder auf der Storage-Ebene mithilfe von Storage-Replizierungstechnologien auf der Datenbankebene durchgeführt werden. Der folgende Abschnitt bietet einen Überblick über Disaster-Recovery-Lösungen basierend auf der Storage-Replizierung.
Weitere Informationen zur Disaster-Recovery-Lösung SAP HANA mit SnapCenter finden Sie unter "TR-4646: SAP HANA Disaster Recovery with Storage Replication".
Storage-Replizierung basierend auf SnapMirror
Die folgende Abbildung zeigt eine Disaster-Recovery-Lösung für drei Standorte, die synchrone SnapMirror Replizierung zum lokalen DR-Datacenter und asynchrone SnapMirror zur Replizierung von Daten an das Remote-DR-Datacenter verwendet.
Die Datenreplizierung mit synchronem SnapMirror sorgt für einen RPO von null. Die Entfernung zwischen dem primären und dem lokalen DR-Datacenter ist auf etwa 100 km beschränkt.
Der Schutz vor Ausfällen des primären und lokalen DR-Standorts wird durch Replizieren der Daten zu einem dritten Remote-DR-Datacenter mithilfe von asynchronem SnapMirror durchgeführt. Der RPO hängt von der Häufigkeit der Replizierungs-Updates und der Übertragungsgeschwindigkeit ab. Theoretisch ist die Entfernung unbegrenzt, aber die Obergrenze hängt von der zu übertragenden Datenmenge und der zwischen den Rechenzentren verfügbaren Verbindung ab. Typische RPO-Werte liegen im Bereich von 30 Minuten bis mehreren Stunden.
Das RTO für beide Replizierungsmethoden hängt in erster Linie von der Zeit ab, die zum Starten der HANA-Datenbank am DR-Standort und zum Laden der Daten in den Speicher erforderlich ist. Mit der Annahme, dass die Daten mit einem Durchsatz von 1000 MBit/s gelesen werden, dass das Laden von 1 TB Daten ungefähr 18 Minuten dauert.
Die Server an den DR-Standorten können im normalen Betrieb als Entwicklungs- und Testsysteme genutzt werden. Bei einem Ausfall müssten die Entwicklungs- und Testsysteme heruntergefahren und als DR-Produktionsserver gestartet werden.
Beide Replizierungsmethoden ermöglichen die Durchführung von DR-Workflow-Tests ohne Auswirkungen auf RPO und RTO. FlexClone Volumes werden auf dem Storage erstellt und an die DR-Testserver angeschlossen.
Die synchrone Replizierung bietet den StrictSync-Modus. Wenn der Schreibvorgang auf den sekundären Storage aus irgendeinem Grund nicht abgeschlossen wird, fällt der Applikations-I/O aus. Dadurch wird sichergestellt, dass die primären und sekundären Storage-Systeme identisch sind. Der Applikations-I/O zum primären Volume wird erst wieder fortgesetzt, nachdem die SnapMirror-Beziehung zum InSync-Status zurückkehrt. Falls der Primär-Storage ausfällt, kann der Applikations-I/O nach dem Failover ohne Datenverlust auf dem sekundären Storage fortgesetzt werden. Im StrictSync-Modus ist der RPO immer Null.
Storage-Replizierung basierend auf NetApp MetroCluster
Die folgende Abbildung bietet einen allgemeinen Überblick über die Lösung. Der Storage Cluster an jedem Standort sorgt für lokale Hochverfügbarkeit und wird für Produktions-Workloads verwendet. Die Daten an jedem Standort werden synchron zum anderen Standort repliziert und sind im Fall eines Disaster Failovers verfügbar.
