Vergleich IBM Storwize Local HyperSwap vs. IBM SVC Stretched Cluster

Transkript

1 Vergleich IBM Storwize Local HyperSwap vs. IBM SVC Stretched Cluster Michael Frankenberg IBM Systems, Client Technical Specialist 1

2 IBM SVC Stretched Cluster Historie SVC V.4.3 / 5.1 V.6.2 / 6.3 / 6.4 V.7.2 / 7.3 V IBM SVC Stretched Cluster Einführung: SVC Stretched Cluster bis 10 km mit / ohne RPQ SVC Stretched Cluster > 10 km über ISL (Private / Public SAN) Aktive Multiplexer FCoE Unterstützung für Node to Node Kommunikation Einführung: SVC Enhanced Stretched Cluster Site Awareness für Nodes und Storage Manual Recovery Procedure mittels overridequorum Read-I/O Optimierung, reduziert Traffic zwischen den Sites CLI / GUI support SVC Enhanced Stretched Cluster Konfiguration der preferred Node erfolgt automatisch, abhängig vom Standort des Servers (ALUA notwendig) Topologie == standard Topologie == stretched 3

3 Was ist IBM SAN Volume Controller (SVC) Stretched Cluster? SVC Node 1 Node 2 Volume Mirroring SVC Quorum 3 SVC Quorum 2 Active Quorum SVC Quorum 1 4

4 Was ist IBM SAN Volume Controller (SVC) Stretched Cluster? Failure Domain 1 Failure Domain 2 Failure Domain 3 Site 1 ISL 1 SVC Node 1 Node 2 Node 2 ISL 2 Site 2 Automatisierter Failover, SVC handhabt den Verlust von: - SVC-Knoten - Quorum Disk - Storage System Kann zusätzlich MM/GM einsetzen, um Disaster Recovery zu realisieren - 3-Site-ähnliche Funktionalität Speichersystem muss Extended Quorum unterstützen Volume Mirroring SVC Quorum 3 Site 1 Site 2 SVC Quorum 2 Active Quorum SVC Quorum 1 SVC Quorum 1 Aktive Quorum Site 3 5 Enhanced Stretched Cluster ist Site Aware (Topologie == Stretched )

5 Einführung: IBM SVC Stretched Cluster : Jede vdisk/volume hat eine: Primäre Kopie + optional: Sekundäre Kopie Preferred Node (Pfad Priorität) SVC Node 1 (Preferred Node für vdisk 1) Bevorzugter Pfad zur Preferred Node Preferred Node Kontrolliert den Destage aufs Backend Storage vdisk 1 Alle Pfade aktiv / aktiv Site 1 Site 2 SVC Stretched Cluster - IO empfangender Node (Caching I/O-Gruppe): - führt Operation aus - spiegelt Scheib-Cache zum Partner Node - Cachetreffer, wenn Daten im lokalen Cache SVC Node 2 Site 3 Volume Mirroring Q Primäre Kopie von vdisk1 Sekundäre Kopie von vdisk 1 Q Q SVC aktive Quorum Disk 6

6 Einführung: IBM SVC Enhanced Stretched Cluster IBM SVC Enhanced Stretched Cluster Topologie == stretched SVC Nodes müssen gleich (50:50) über die Sites (Failure domain) 1 und 2 verteilt werden Sinnvoll sind mindestens zwei I/O-Gruppen SVC Nodes kommunizieren nur mit dem Storage (mdisks) in der gleichen Site und mit Site 3 (Quorum) Aktiv Quorum Disk Lokation ist in Site 3 SVC Site-Awarness, d.h. Standorte der Nodes und der Storage Systeme sind dem SVC bekannt Manuelle Recovery Prozedur verfügbar Konfiguration über GUI / CLI ist seit Version 7.3 möglich Schreib- und Lese-IOs sind optimiert um die Traffic zwischen den Standorten zu reduzieren. Mit Version 7.5 wird die preferred Node abhängig vom Server-Standort automatisch optimiert (ALUA notwendig) 7 Copyright IBM Corporation 2014

7 IBM SVC Enhanced Stretched Cluster : Verhalten bei verschiedenen Fehlersituationen Failure Domain 1 (SVC Node 1) Failure Domain 2 (SVC Node 2) Failure Domain 3 aktives Quorum Cluster Status Operativ Operativ Operativ Operativ, optimal Ausgefallen Operativ Operativ Operativ, Write Cache deaktiviert Operativ Ausgefallen Operativ Operativ, Write Cache deaktiviert Operativ Operativ Ausgefallen Operativ, Aktive Quorum Disk verschoben Operativ, Verbindungen zur Failure Domain 2 ausgefallen, Split Brain Operativ, Verbindungen zur Failure Domain 1 ausgefallen, Split Brain Operativ Operativ, Node. die aktives Quorum im Zugriff hat, bleibt aktiv. Alle anderen Nodes gehen offline. Sollte es sich um ein Rolling Disaster handeln und der Node,der das Quorum Race gewonnen hatte, geht auch offline, kann die überlebende Seite mittels overridequorum wieder aktiviert werden. Operativ Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 3 Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 2 Gestoppt, überlebende Seite kann mitels overridequorum wieder aktiviert werden Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 3 Operativ Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 1 Gestoppt, überlebende Seite kann mitels overridequorum wieder aktiviert werden 8

8 IBM SVC Enhanced Stretched Cluster : Vorteile gegenüber IBM SVC Stretched Cluster IBM SVC Enhanced Stretched Cluster Topologie == stretched SVC Site-Awarness, d.h. Standorte der Nodes und der Storage Systeme sind dem SVC bekannt Manuelle Recovery Prozedur verfügbar Schreib- und Lese-IOs sind optimiert, um die Traffic zwischen den Standorten zu reduzieren. Mit Version 7.5. wird die preferred Node abhängig vom Server-Standort automatisch optimiert (ALUA notwendig) 9 Copyright IBM Corporation 2014

9 IBM HyperSwap Historie IBM HyperSwap, basierend auf DS8000 Metro Mirror, ist in zwei Ausprägungen seit Jahren bei Kunden im Einsatz. Im System z Umfeld wird DS8000 HyperSwap mittels GDPS oder TPC-R gemanaget und überwacht HyperSwap wird vom Betriebssystem gesteuert funktioniert auch mit anderen Storage-Herstellern. Bei Ausfall des primären Storage Systems wird ohne Anwendungsunterbrechung auf das sekundäre Storage System umgeschaltet. Im AIX Umfeld mittels Power HA SystemMirror und DS8000 Metro Mirror HyperSwap wird durch das AIX Betriebssystem gesteuert. NEU in 2015: IBM Storwize Local HyperSwap Unabhängig vom Betriebssystem Bei Ausfall einer Lokation wird ohne Anwendungsunterbrechung auf die andere Lokation umgeschaltet. 10

10 Was ist IBM Storwize Local HyperSwap? Local HyperSwap : Der nächste Schritt in Richtung Integration von Hochverfügbarkeit und Disaster Recovery IBM Storwize Local HyperSwap : Basiert auf Metro Mirror, Global Mirror with Change Volumes und NDVM Technologien RZ 1 RZ 2 Volumes sind über zwei IO-Gruppen als ein Objekt sichtbar (gleiche UID) Konsistenzgruppen und FlashCopy wird genutzt I/O-Gruppe 0 Metro Mirror I/O-Gruppe 1 Site 3 11 Quorum

11 Einführung: IBM Storwize Local HyperSwap (Stand September 2015) Metro Mirror wird benutzt, um die beiden Volume-Kopien in sync zu halten I/O-Gruppe 0 Site 1 Site 2 HyperSwap leitet I/Os falls erforderlich um SVC / Storwize Cluster Metro Mirror Unterstützt Konsistenzgruppen, um so das Risiko von Datenverlust bei einem Rolling Disaster zu minimieren I/O-Gruppe 1 HyperSwap kann anhand der Zugriffsstatistiken die Metro Mirror Kopierrichtung zwischen den I/O- Gruppen selbständig wechseln. Nutzt FlashCopy, um DR auch während der Daten- Resynchronisierung zu gewährleisten LUN 1 LUN 1 12 Quorum Site 3 Gleiche LUN ID wird von HyperSwap simuliert Topologie == HyperSwap

12 Einführung: IBM Storwize Local HyperSwap IBM Storwize Local HyperSwap Topologie == HyperSwap Mindestens zwei SVC I/O Gruppen oder zwei Storwize V5000/V7000/V9000 Controller werden benötigt und über die Sites 1 und 2 verteilt Remote Mirroring Lizenz ist erforderlich Storwize Controller / SVC Nodes kommunizieren nur mit dem Storage (mdisks) in der gleichen Site und mit Site 3 (Quorum) Aktiv Quorum Disk Lokation ist in Site 3 Connectivity Anforderungen identisch mit denen vom SVC Enhanced Stretched Cluster (mit und ohne ISLs) Site-Awarness, für Server, Nodes/Controller und der Storage System muss vergeben werden Konfiguration über CLI möglich Die preferred Node werden abhängig vom Server-Standort automatisch optimiert (ALUA notwendig) Anwendungs-Awarness kann mittels Konsistenzgruppen erzeugt werden. Im Fehlerfall kann die Datenkonsistenz mittels Konsitenzgruppen gewahrt werden. Vor einer evtl. notwendigen Re-Synchronisation wird mittels FlashCopy ein konsistenter Datenbestand abgespeichert Manuelle Recovery Prozedur verfügbar 13

13 IBM Storwize Local HyperSwap : Verhalten bei verschiedenen Fehlersituatuionen Im Fehlerfall kann die Datenkonsistenz mittels Konsitenzgruppen gewahrt werden. D.h. Anwendungs-Awarness ist gegeben. Vor einer evtl. notwendigen Re-Synchronisation, wird mittels FlashCopy ein konsistenter Datenbestand abgespeichert Failure Domain 1 (IO-Gruppe 0) Failure Domain 2 (IO-Gruppe 1) Failure Domain 3 aktives Quorum Cluster Status Operativ Operativ Operativ Operativ, optimal Hälfte der I/O Gruppe ist ausgefallen Operativ Operativ Operativ, Write Cache deaktiviert für die betroffene I/O Gruppe Operativ Hälfte der I/O Gruppe ist ausgefallen Operativ, Write Cache deaktiviert für die betroffene I/O Gruppe Ausgefallen Operativ Operativ Operativ, wenn für die Server HA Funktion implementiert ist Operational Ausgefallen Operativ Operativ, wenn für die Server HA Funktion implementiert ist Operativ Operativ Ausgefallen Operativ, Aktive Quorum Disk verschoben Operativ, Verbindungen zur Failure Domain 2 ausgefallen, Split Brain Operativ, Verbindungen zur Failure Domain 1 ausgefallen, Split Brain Operativ Operativ, I/O Gruppe, die die aktive Quorum im Zugriff hat, bleibt aktiv. Die andere I/O-Gruppe geht offline. Sollte es sich um ein Rolling Disaster handeln und die I/O-Gruppe, die das Quorum Race gewonnen hatte, geht auch offline, kann die überlebende Seite mittels overridequorum wieder aktiviert werden. Operativ Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 3 Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 2 Gestoppt, überlebende Seite kann mitels overridequorum wieder aktiviert werden Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 3 Operativ Ausgefallen zum gleichen Zeitpunkt wie Failure Domain 1 Gestoppt, überlebende Seite kann mitels overridequorum wieder aktiviert werden 14

14 Gegenüberstellung von IBM SVC Enhanced Stretched Cluster und IBM Storwize Local HyperSwap I/II Verfügbar für Konfigurationsmöglichkeiten Maximale Distanz zwischen den Lokationen IBM SVC Enhanced Stretched Cluster Nur SVC (sinnvollweise mit mindstens zwei I/O Gruppen) CLI oder GUI, einfaches Verfahren durch Mirrored Volume Funktion Bis zu 300km IBM Storwize Local HyperSwap SVC mit zwei oder mehr I/O-Gruppen; Storwize V9000, Storwize V7000 und Storwize V5000 mit mindestens zwei Control Enclosure) Zur Zeit nur CLI, mehere Schritte müssen bei der CLI Konfiguration durchgeführt werden Bis zu 300km Write Cache enabled falls nur eine Lokation verfügbar ist Synchronisation und Resynchronisation der Volume- Kopien Datenkonsistenz während Resynchronisation gegeben? Nein Automatisch Nein Ja Automatisch Ja 15

15 Gegenüberstellung von IBM SVC Enhanced Stretched Cluster und IBM Storwize Local HyperSwap II/II Fehlerbehandlung und Resynchronisation bezieht sich auf: Möglichkeiten FlashCopy zu nutzen Möglichkeit zur Nutzung von 3-Site / 4-Site Replikationen (Metro Mirror, Global Mirror) IBM SVC Enhanced Stretched Cluster Basis eines Volume Ja Ja, 3-Site und 4-Site Replikationen sind im Zusammenhang mit Enhanced Stretched Cluster möglich IBM Storwize Local HyperSwap ein oder mehrere Volumes, kann mittels Konsistenzgruppen durch den Benutzer gesteuert werden. Limitierungen vorhanden; HyperSwap Volumes können nur als Quelle einer FlashCopy -Beziehung genutzt werden. Nein Maximum Anzahl der zu verwaltenden gespiegelten Volumes Lizensierung Volume Mirroring ist in Basislizenz enthalten Benötigt Remote Mirroring Lizenz 16

16 IBM Storwize Local HyperSwap : Vorteile gegenüber IBM SVC Enhanced Stretched Cluster IBM Storwize Local HyperSwap Topologie == HyperSwap Bessere Performance, da Write Cache auch bei Ausfall eines Standortes verfügbar bleibt Disaster Recovery Fähigkeiten erhöht Anwendungs-Awarness kann mittels Konsistenzgruppen erzeugt werden. Im Fehlerfall kann die Daten-Konsistenz mittels Konsistenzgruppen gewahrt werden. Vor einer evtl. notwendigen Re-Synchronisation wird automatisch mittels FlashCopy ( Change Volume Technologie) ein konsistenter Datenbestand abgespeichert 17

17 Implementierungsunterschiede IBM SVC Enhanced Stretched Cluster Topologie == Stretched Für die Volume-Kopie wird Volume Mirroring genutzt Nodes einer I/O-Gruppe werden über zwei Standorte verteilt Site Attribute müssen für Nodes und Storage vergeben werden Aktive Quorum im dritten Standort Dedizierte Verbindungen für Node to Node Kommunikation müssen bereitgestellt werden IBM Storwize Local HyperSwap Topologie == HyperSwap Für die Volume-Kopie wird Remote Mirroring genutzt I/O Gruppen oder Controller Enclosure werden zwei Standorte verteilt Site Attribute müssen für Nodes, Storage und Server vergeben werden FlashCopy-Beziehungen müssen etabliert werden, um DR auch während der Daten-Resynchronisierung zu gewährleisten Konsistenzgruppen-Nutzung möglich und sinnvoll Aktive Quorum im dritten Standort Dedizierte Verbindungen für Node to Node Kommunikation müssen bereitgestellt werden 18

18 Optimale Einsatzgebiete für... IBM SVC Enhanced Stretched Cluster Maximale Anzahl von Volumes wird benötigt 3-Site-Lösung ist erforderlich oder zukünftig geplant FlashCopy soll ohne Einschränkungen genutzt werden können HA steht im Vordergrund Optimierter IO zur Reduzierung der Traffic zwischen den Standorten ist wichtig Anwendungen, bei denen auf beiden Standorten annähernd gleich viel IOs durchgeführt werden, z. B. Oracle RAC IBM Storwize Local HyperSwap Storwize V7000 / V5000 sollen genutzt werden, um HA- Lösung zu erstellen Anforderung an verbesserte DR-Fähigkeiten sind vorhanden Falls regelmäßig Volumes von Thick auf Thin oder von noncompressed auf compressed umgestellt werden Optimiert für Cluster Systeme die aktiv / passiv arbeiten, z. B. AIX PowerHA Bei VMware Umgebungen sollte der Datastore immer lokal bei der VM liegen Umgebungen, bei denen nur ein Teil der Volumes hochverfügbar seinen müssen und die restlichen Volumes optimale Performance benötigen 19

19 Migration von SVC Enhanced Stretched Cluster zu SVC Local HyperSwap Diese Schritte gelten nur für SVC: Bei Enhanced Stretched Cluster Implementierungen muss die Topologie auf Standard gesetzt und die Site Attribute entfernt werden Die bestehenden SVC Nodes müssen neu über die beiden Standorte verteilt werden, sodass in einem Standort immer eine komplette I/O-Gruppe installiert ist. Löschen der Volume-Kopien eines Standortes Sollte die Möglichkeit bestehen, die Host I/O zu stoppen, könnten mittels splitvdiskcopy zwei unabhängige Volume- Kopien erstellt werden Umsetzen der Topologie von Standard bzw. auf HyperSwap Die Site-Attribute für die Server müssen gesetzt werden Die Volume-Kopien müssen neu erstellt werden. Oder - falls splitvdiskcopy genutzt wurde - können die Volumes beim Erstellen der HyperSwap-Beziehungen mittels sync Parameter ohne Full Sync wieder zusammengefahren werden. Zukünftige Erleichterungen sind in Planung: splitvdiskcopy activeactive <stretchedvolume> konvertiert Volumes in eine HyperSwap-Beziehung Die HyperSwap-Beziehungen und alle weiteren Konfigurationsschritte, die für eine HyperSwap Implementierung notwendig sind, müssen durchgeführt werden (z. B. die FlashCopy Volumes und Beziehungen müssen angelegt werden). 20

20 Dokumentation zu Storwize Local HyperSwap IBM Knowledge Center Storwize V7000 Rel. 7.5: 01.ibm.com/support/knowledgecenter/ST3FR7_7.5.0/com.ibm.storwize.v doc/svc_hypers wap_configuration.html?cp=st3fr7%2f &lang=en White Paper zu IBM Storwize Local HyperSwap : 21

21 22