21
© 2015 IBM Corporation IBM System Storage Vergleich IBM Storwize Local HyperSwap vs. IBM SVC Stretched Cluster Michael Frankenberg – IBM Systems, Client Technical Specialist 1

Vergleich IBM Storwize Local HyperSwap vs. IBM SVC ... · PDF fileIBM SVC “Enhanced Stretched Cluster” IBM Storwize “Local HyperSwap” 16 Fehlerbehandlung und Resynchronisation

  • Upload
    vanbao

  • View
    487

  • Download
    11

Embed Size (px)

Citation preview

© 2015 IBM Corporation

IBM System Storage

Vergleich

IBM Storwize Local HyperSwapvs.

IBM SVC Stretched Cluster

Michael Frankenberg – IBM Systems, Client Technical Specialist

1

© 2015 IBM Corporation

IBM System Storage

IBM SVC „Stretched Cluster“ Historie

3

SVC V.4.3 / 5.1 V.6.2 / 6.3 / 6.4 V.7.2 / 7.3 V.7.5 .....

IBM SVC Stretched Cluster

Einführung: SVC StretchedCluster • bis 10 km mit / ohne

RPQ

SVC StretchedCluster • > 10 km• über ISL (Private /

Public SAN) • Aktive Multiplexer• FCoE Unterstützung für

Node to Node Kommunikation

Topologie == “standard”

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

Topologie == “stretched”

SVC Enhanced Stretched Cluster • Konfiguration der

“preferred Node” erfolgt automatisch, abhängig vomStandort des Servers (ALUA notwendig)

© 2015 IBM Corporation

IBM System Storage

4

SVC Quorum 3

Node 1

SVC Quorum 1SVC Quorum 2

Active Quorum

Was ist IBM SAN Volume Controller (SVC) „Stretched Cluster“?

Node 2

Volume Mirroring

SVC

© 2015 IBM Corporation

IBM System Storage

5

SVC Quorum 3

Failure Domain 1 Failure Domain 2

Node 1 Node 2

SVC Quorum 1SVC Quorum 2

Active Quorum

Volume Mirroring

ISL 1

ISL 2

Was ist IBM SAN Volume Controller (SVC) „Stretched Cluster“?

Automatisierter Failover, SVC handhabt den Verlust von:

- SVC-Knoten

- Quorum Disk

- Storage System

Failure Domain 3

SVC Quorum 1

Aktive Quorum

Speichersystem muss “Extended Quorum” unterstützen

Node 2

Site 3

Site 2

Site 2

Site 1

Site 1

Kann zusätzlich MM/GM einsetzen, um Disaster Recovery zu realisieren

- 3-Site-ähnliche Funktionalität

„Enhanced Stretched Cluster“ ist „Site Aware“(Topologie == „Stretched“)

SVC

© 2015 IBM Corporation

IBM System Storage

Einführung: IBM SVC „Stretched Cluster“:

6

Site 1 Site 2SVC Node 2

Q

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

Jede vdisk/Volume hat eine:• Primäre Kopie +

optional: Sekundäre Kopie• Preferred Node (Pfad Priorität)

Alle Pfadeaktiv / aktivBevorzugter Pfad

zur “PreferredNode”

Primäre Kopie von vdisk1 Sekundäre Kopie von vdisk 1

vdisk 1

Preferred NodeKontrolliert den Destageaufs Backend Storage

SVC Node 1

(Preferred

Node für

vdisk 1)

Q

Site 3

SVC aktive Quorum Disk

Q

Volume Mirroring

© 2015 IBM Corporation

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

8

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, bleibtaktiv. 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

© 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”?

11

RZ 1 RZ 2

Quorum

Site 3

I/O-Gruppe 1Metro MirrorI/O-Gruppe 0

� IBM Storwize „Local HyperSwap“: Basiert aufMetro Mirror, Global Mirror with Change Volumes und NDVM Technologien

� Volumes sind über zwei IO-Gruppen als einObjekt sichtbar (gleiche UID)

� Konsistenzgruppen und FlashCopy wird genutzt

“Local HyperSwap”: Der nächste Schritt in Richtung Integration von Hochverfügbarkeit und Disaster Recovery

© 2015 IBM Corporation

IBM System Storage

Einführung: IBM Storwize „Local HyperSwap“ (Stand September 2015)

12

SVC / Storwize Cluster

Site 1 Site 2

Quorum

Site 3

I/O-Gruppe 1I/O-Gruppe 0 Metro Mirror

LUN 1 LUN 1‘

HyperSwap kann anhand der Zugriffs-

statistiken die Metro Mirror Kopierrichtung

zwischen den I/O-Gruppen selbständig

wechseln.

Unterstützt Konsistenz-gruppen, um so das

Risiko von Datenverlustbei einem “Rolling

Disaster” zu minimieren

Nutzt FlashCopy, um DR auch während der Daten-

Resynchronisierung zugewährleisten

Topologie == „HyperSwap“Gleiche LUN ID wird von HyperSwap simuliert

HyperSwap leitet I/Osfalls erforderlich um

Metro Mirror wird benutzt, um die beiden

Volume-Kopien in sync zu halten

© 2015 IBM Corporation

IBM System Storage

Einführung: IBM Storwize „Local HyperSwap“

13

� 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

© 2015 IBM Corporation

IBM System Storage

14

IBM Storwize „Local HyperSwap“: Verhalten bei verschiedenen Fehlersituatuionen

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 aktiviertwerden.

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

• 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

© 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”

15

Verfügbar fürNur 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öglichkeitenCLI oder GUI, einfaches Verfahren durch Mirrored

Volume FunktionZur Zeit nur CLI, mehere Schritte müssen beider CLI Konfiguration durchgeführt werden

Maximale Distanz zwischen den Lokationen

Bis zu 300km Bis zu 300km

Write Cache enabled falls nur eineLokation verfügbar ist

Nein Ja

Synchronisationund Resynchronisation der Volume-

KopienAutomatisch Automatisch

Datenkonsistenz währendResynchronisation gegeben?

Nein Ja

© 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” IBM Storwize “Local HyperSwap”

16

Fehlerbehandlung und Resynchronisation bezieht sich auf:

Basis eines Volume ein oder mehrere Volumes, kann mittelsKonsistenzgruppen durch den Benutzer

gesteuert werden.

Möglichkeiten FlashCopy zu nutzen JaLimitierungen vorhanden; HyperSwapVolumes 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 imZusammenhang mit “Enhanced Stretched Cluster”

möglich

Nein

Maximum Anzahl der zuverwaltenden gespiegelten Volumes

4096 1024

Lizensierung Volume Mirroring ist in Basislizenz enthalten Benötigt Remote Mirroring Lizenz

© 2015 IBM Corporation

IBM System Storage

IBM Storwize „Local HyperSwap“: Vorteile gegenüber IBM SVC „Enhanced Stretched Cluster“

17

� 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

© 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

� 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-Resynchronisierungzu 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

© 2015 IBM Corporation

IBM System Storage

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 non-compressed 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

© 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 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

© 2015 IBM Corporation

IBM System Storage

Dokumentation zu Storwize „Local HyperSwap“

� IBM Knowledge Center Storwize V7000 Rel. 7.5:

– http://www-

01.ibm.com/support/knowledgecenter/ST3FR7_7.5.0/com.ibm.storwize.v7000.750.doc/svc_hyperswap_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