IBM System Storage Vergleich IBM Storwize Local HyperSwap vs. IBM SVC Stretched Cluster Michael Frankenberg – IBM Systems, Client Technical Specialist 1 © 2015 IBM Corporation IBM System Storage IBM SVC „Stretched Cluster“ Historie SVC V.4.3 / 5.1 V.7.2 / 7.3 V.6.2 / 6.3 / 6.4 V.7.5 ..... 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 • • • • Topologie == “standard” 3 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 == “stretched” © 2015 IBM Corporation IBM System Storage Was ist IBM SAN Volume Controller (SVC) „Stretched Cluster“? SVC Node 1 Node 2 Volume Mirroring SVC Quorum 3 SVC Quorum 2 SVC Quorum 1 Active Quorum 4 © 2015 IBM Corporation IBM System Storage Was ist IBM SAN Volume Controller (SVC) „Stretched Cluster“? Failure Domain 3 Failure Domain 2 Failure Domain 1 Automatisierter Failover, SVC handhabt den Verlust von: - SVC-Knoten - Quorum Disk - Storage System ISL 1 Kann zusätzlich MM/GM einsetzen, um Disaster Recovery zu realisieren Site 2 SVC Node 2 Node 1 Node 2 - 3-Site-ähnliche Funktionalität Site 1 ISL 2 Speichersystem muss “Extended Quorum” unterstützen Volume Site 1 SVC Quorum 3 Mirroring Site 2 SVC Quorum 2 Site 3 SVC Quorum 1 Active Quorum 5 „Enhanced Stretched Cluster“ ist „Site Aware“(Topologie == „Stretched“) SVC Quorum 1 Aktive Quorum © 2015 IBM Corporation IBM System Storage Einführung: IBM SVC „Stretched Cluster“: Jede vdisk/Volume hat eine: • Primäre Kopie + optional: Sekundäre Kopie • Preferred Node (Pfad Priorität) vdisk 1 Bevorzugter Pfad zur “Preferred Node” SVC Node 1 Alle Pfade aktiv / aktiv Site 1 Node für Site 3 Site 2 Preferred Node Kontrolliert den Destage aufs Backend Storage (Preferred - 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 vdisk 1) SVC Stretched Cluster Volume Mirroring Q Primäre Kopie von vdisk1 6 Q Q Sekundäre Kopie von vdisk 1 © 2015 IBM Corporation SVC aktive Quorum Disk IBM System Storage 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 © 2015 IBM Corporation IBM System Storage 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 © 2015 IBM Corporation IBM System Storage 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 © 2015 IBM Corporation IBM System Storage 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 © 2015 IBM Corporation IBM System Storage 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 Volumes sind über zwei IO-Gruppen als ein Objekt sichtbar (gleiche UID) RZ 1 I/O-Gruppe 0 RZ 2 Metro Mirror I/O-Gruppe 1 Konsistenzgruppen und FlashCopy wird genutzt Site 3 11 Quorum © 2015 IBM Corporation IBM System Storage Einführung: IBM Storwize „Local HyperSwap“ (Stand September 2015) Site 1 Site 2 HyperSwap leitet I/Os falls erforderlich um Metro Mirror wird benutzt, um die beiden Volume-Kopien in sync zu halten SVC / Storwize Cluster I/O-Gruppe 0 Nutzt FlashCopy, um DR auch während der DatenResynchronisierung zu gewährleisten Metro Mirror I/O-Gruppe 1 LUN 1‘ LUN 1 Quorum 12 Unterstützt Konsistenzgruppen, um so das Risiko von Datenverlust bei einem “Rolling Disaster” zu minimieren HyperSwap kann anhand der Zugriffsstatistiken die Metro Mirror Kopierrichtung zwischen den I/OGruppen selbständig wechseln. Site 3 Gleiche LUN ID wird von HyperSwap simuliert Topologie == „HyperSwap“ © 2015 IBM Corporation IBM System Storage 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 © 2015 IBM Corporation IBM System Storage IBM Storwize „Local HyperSwap“: Verhalten bei verschiedenen Fehlersituatuionen • • Failure Domain 1 (IO-Gruppe 0) 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 2 (IO-Gruppe 1) Failure Domain 3 aktives Quorum 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 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 Cluster Status Operativ, Write Cache deaktiviert für die betroffene I/O Gruppe © 2015 IBM Corporation IBM System Storage Gegenüberstellung von IBM SVC „Enhanced Stretched Cluster“ und IBM Storwize „Local HyperSwap“ I/II IBM SVC “Enhanced Stretched Cluster” IBM Storwize “Local HyperSwap” Verfügbar für Nur SVC (sinnvollweise mit mindstens zwei I/O Gruppen) SVC mit zwei oder mehr I/O-Gruppen; Storwize V9000, Storwize V7000 und Storwize V5000 mit mindestens zwei Control Enclosure) Konfigurationsmöglichkeiten CLI oder GUI, einfaches Verfahren durch Mirrored Volume Funktion Zur Zeit nur CLI, mehere Schritte müssen bei der CLI Konfiguration durchgeführt werden Maximale Distanz zwischen den Lokationen Bis zu 300km Bis zu 300km Write Cache enabled falls nur eine Lokation verfügbar ist Nein Ja Synchronisation und Resynchronisation der VolumeKopien Automatisch Automatisch Datenkonsistenz während Resynchronisation gegeben? Nein Ja 15 © 2015 IBM Corporation IBM System Storage Gegenüberstellung von IBM SVC „Enhanced Stretched Cluster“ und IBM Storwize „Local HyperSwap“ II/II IBM SVC “Enhanced Stretched Cluster” Fehlerbehandlung und Resynchronisation bezieht sich auf: Basis eines Volume IBM Storwize “Local HyperSwap” ein oder mehrere Volumes, kann mittels Konsistenzgruppen durch den Benutzer gesteuert werden. Möglichkeiten FlashCopy zu nutzen Ja Limitierungen vorhanden; HyperSwap Volumes können nur als Quelle einer FlashCopy -Beziehung genutzt werden. Möglichkeit zur Nutzung von 3-Site / 4-Site Replikationen (Metro Mirror, Global Mirror) Ja, 3-Site und 4-Site Replikationen sind im Zusammenhang mit “Enhanced Stretched Cluster” möglich Nein Maximum Anzahl der zu verwaltenden gespiegelten Volumes 4096 1024 Lizensierung Volume Mirroring ist in Basislizenz enthalten Benötigt Remote Mirroring Lizenz 16 © 2015 IBM Corporation IBM System Storage 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 © 2015 IBM Corporation IBM System Storage 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 18 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 © 2015 IBM Corporation IBM System Storage Optimale Einsatzgebiete für.... 19 IBM SVC „Enhanced Stretched Cluster“ IBM Storwize „Local HyperSwap“ 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 Storwize V7000 / V5000 sollen genutzt werden, um HALö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 © 2015 IBM Corporation IBM System Storage 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 VolumeKopien 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 © 2015 IBM Corporation IBM System Storage Dokumentation zu Storwize „Local HyperSwap“ IBM Knowledge Center Storwize V7000 Rel. 7.5: – http://www01.ibm.com/support/knowledgecenter/ST3FR7_7.5.0/com.ibm.storwize.v7000.750.doc/svc_hypers wap_configuration.html?cp=ST3FR7%2F0-5-0-9&lang=en White Paper zu IBM Storwize „Local HyperSwap“: – http://w3-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102538 21 © 2015 IBM Corporation IBM System Storage 22 © 2015 IBM Corporation
© Copyright 2024 ExpyDoc
