Enhanced S. C. – Teil 2 (Warum und Voraussetzungen)

Der enhanced Mode Stretched Cluster ist seit der Version 7.2 optional verfügbar, d.h. er kann zusätzlich bei einem bestehenden Standard Stretched Cluster (non-enhanced Mode) implementiert werden.

Dieser Beitrag beschreibt die Motivation für den enhanced Mode (WARUM) und die Rahmenbedingungen (VORAUSSETZUNGEN) bei den SVC Versionen 7.2 und 7.3.

Einführung:

  • Non-enhanced Mode Stretched Cluster:
    Der klassische Mode wird in der SVC Terminologie als „standard“ Topologie bezeichnet, obwohl das Setup bereits ge-„stretched“ ist:
    CLI:> chsystem –topology standardDer klassische (non-enhanced) Mode (-topology standard) ist voreingestellt.
  • Enhanced Mode Stretched Cluster:
    Der enhanced Mode wird in der SVC Terminologie als „stretched“ Topologie geführt; „stretched“ Mode bedeutet also enhanced Mode;
    CLI:> chsystem –topology stretched
  • Wechsel zwischen den beiden Modi:
    Zwischen den beiden Modi kann online gewechselt werden. Das Verhalten des Clusters ändert sich dann entsprechend.

Warum:

Der enhanced Mode bringt folgende Funktionalitäten:

  • Erweiterte Disaster Recovery Fähigkeit:
    Durch sehr seltene Ereignisse (z.B. Doppelfehler, rolling Disasters oder Fehler, die sich langsam ausbreiten) können Situationen entstehen, die eine gleichzeitige Nichtverfügbarkeit der aktiven Quorum Disk UND eines RZs mit sich bringen:Beispiel:
    – aktive Quorum Disk in Site 3 fällt aus.
    – Der Cluster ernennt den Quorum Candidate z.B. in Site 2 zur neuen aktiven Quorum Disk.
    – Der Ausfall in Site 3 wird nicht sofort korrigiert.
    – Ein paar Tage später fällt die Stromversorgung in Site 2 aus.
    – Somit geht die dann aktive Quorum Disk und Site 2 gleichzeitig außer Betrieb.

    Was passiert in diesem Fall:
    Obwohl in Site 1 alle Daten konsistent vorhanden sind, gehen alle VDisks offline, da die SVC Nodes in Site 1 in diesem Fall annehmen müssen, dass Site 2 noch läuft und nur die Kommunikation zur Site 2 gestört ist.

    Im non-enhanced Mode hat der SVC Administrator keine Möglichkeit, die VDisks online zu schalten. Die ausgefallene aktive Quorum Disk in Site 2 muss wieder aktiviert werden (falls noch möglich); erst dann werden die VDisks wieder verfügbar. Sollte die aktive Quorum Disk nicht aktivierbar sein, muss der SVC Support aktiviert werden.

    Im enhanced Mode gibt es für diesen Fall einen CLI-Befehl, mit dem der SVC Administrator die VDisks mit den SVC Nodes der Site 1 aktivieren kann. Dieser Vorgang nennt sich „Quorum Override“.

  • Site Awareness mit Bandbreitenoptimierung:
    SVC Knoten und Speichersysteme können ab Version 7.2 mit Site-Attributen versehen werden:
    – SVC Knoten: Site 1 oder Site 2 (CLI:> chnode –site x)
    – Speichersysteme: Sites 1, 2 oder 3 (CLI:> chcontroller –site x)Bereits das Setzen von Site-Attributen bewirkt erste Änderung des IO-Routings innerhalb des SVCs.

    Erst wenn für alle SVC Nodes und Speichersysteme das Site-Attribut gesetzt wurde, läßt sich der Cluster in den enhanced Mode schalten (CLI:> chsystem –topology stretched).

    Folgende Bandbreitenoptimierungen sind im enhanced Mode aktiv:
    Read-Misses erfolgen von Speichersystemen der lokalen Site, falls die Daten dort vorhanden und gültig sind. Dies spart Bandbreite zwischen den Sites und reduziert die Read-Latency.

    Bei Version 7.2 werden Write-IOs zwei Mal zwischen den Sites übertragen (für Cache-Mirror und für Remote-Destage-to-Disk). Ab Version 7.3 werden Write-IOs nur noch 1 mal zwischen den Sites übertragen, da für den Remote-Destage-to-Disk die vorher bereits übertragene Cache-Mirror-Kopie verwendet wird). Dies spart ebenfalls Bandbreite zwischen den Sites 1 und 2.

Voraussetzungen:

  • Fertig implementierter und betriebsbereiter SVC Stretched Cluster im non-enhanced Mode
  • non-ISL Setup oder ISL Setup
  • SVC Version mindestens 7.2, empfohlen 7.3
  • Empfohlen sind mindestens 4 SVC Nodes im Cluster (siehe Beitrag „enhanced mode – Teil 1“)
  • Alle IO-Groups müssen mit einem Node in Site 1 und einem Node in Site 2 betrieben werden. Sonderfälle (z.B. eine IO-Group in Site 3) sind nicht möglich.

Sind diese Voraussetzungen erfüllt, empfehle ich die Verwendung des enhanced Modes in Betracht zu ziehen.

Grüße aus München, Franz.

Anbindung der aktiven Quorum Disk in Site 3

Ergänzung 25.11.2013: Kapitel 2.3a

Dieser Beitrag beschäftigt sich mit der Anbindung der aktiven Quorum Disk in Site 3. Die Ausführungen gelten für:

  • non-ISL Setups (wie in den Bildern dargestellt) und ISL Setups (in diesem Fall liegt die Anbindung der Site 3 komplett im public SAN).
  • non-enhanced und enhanced Mode

1. Sites und Power Domains

  • In den beiden Hauptrechenzentren Site 1 und Site 2 werden Server, SVC Nodes und Speichersysteme betrieben. In der Site 3 steht in der Regel nur das Speichersystem mit der aktiven Quourm Disk.
  • Jede Site muss als unabhängige Power Domain betrieben werden: Bei komplettem Stromausfall in Site 1 oder Site 2 müssen die jeweils anderen beiden Sites noch mit Strom versorgt werden, um ein automatisches SVC Site Failover sicher stellen zu können. Nach erfolgtem Site Failover darf dann auch Site 3 ausfallen.

2. Mögliche Anbindungen

2.1 Optimale Anbindung:

Bild 1 zeigt die für alle unterstützten Speichersysteme optimale Anbindung. Dieses Setup ist somit für active/active (z.B. IBM Storwize V7000) und active/passive (z.B. IBM DS4700) Speichersysteme optimal geeignet:

bild1

Allgemeine Hinweise zum Bild:

  • In grün dargestellt: 2 unabhängige SAN Fabrics (A und B), die jeweils über Site 1 und Site 2 gespannt sind.
  • Bedeutung der Switchnamen: [Fabric][Site]-[id];  id=C für Core-Switch bzw. Ex für Edge-Switch(e).
    Die Core-Switche sind die Switche, die direkt mit der jeweils anderen Site verbunden sind.
  • In blau ist eine SVC IO-Group mit 2 Nodes im non-ISL Setup dargestellt: Bezeichnung der Nodes:
    Node[IO-Group-Nr]-[Node-Nr].
  • SVC Nodes und Speichersysteme sollten immer an die Core-Switche angebunden werden.

Details zur optimalen Anbindung:

  • In rot dargestellt: Jeder Core Switche ist mit der aktiven Quorum Disk verbunden:
    – Site 1: Fabric A an Controller-B der Quorum; Fabric B an Controller-A der Quorum
    – Site 2: Fabric A an Controller-A der Quorum; Fabric B an Controller-B der Quorum
  • Es ist wichtig (wie in der Zeichnung dargestellt), dass die Verbindungen von Site 1 nach Site 3 nicht durch die Site 2 verlaufen; analog die Verbindungen von Site 2 nach Site 3 nicht durch die Site 1 verlaufen.

2.2 Variante für active/active Speichersysteme:

Wird für die aktive Quorum Disk in Site 3 ein active/active Speichersystem eingesetzt, können mit folgendem Setup zwei Leitungen eingespart werden:

bild2

  • In rot dargestellt: Site 1 und Site 2 ist nur je 1-mal mit der aktiven Quorum Disk verbunden:
    Dabei müssen aber beide Fabrics und beide Plattensystem-Controller eingebunden werden, z.B:
    – Site 1: Fabric B an Controller-B der Quorum
    – Site 2: Fabric A an Controller-A der Quorum
  • Auch hier ist wichtig, dass die Verbindung von Site 1 nach Site 3 nicht durch die Site 2 verlaufen; analog die Verbindung von Site 2 nach Site 3 nicht durch Site 1 verlaufen.

2.3 Notlösung bei active/passive Quorum Disk System:

Falls ein active/passive Quorum Disk System mit nur 2 Verbindungen (eine aus Site 1 und eine aus Site 2) angebunden werden kann, ist folgende Notlösung denkbar:

bild3

  • In diesem Fall müssen die beiden Verbindungen am gleichen Speichersystem-Controller (A oder B) angebunden werden.
  • Der Ausfall dieses Speichersystem-Controllers wird vom SVC dann wie ein Ausfall der aktiven Quorum-Disk behandelt, d.h. ein anderer Quorum Candidate wird automatisch zur aktiven Quorum Disk ernannt. In diesem Zustand (bis der Zugriff auf die Quorum Disk in Site 3 wieder möglich ist) können Einschränkungen beim automatischen Site Failover auftreten, falls zusätzlich die Site ausfallen sollte, die nun übergangsweise die aktive Quorum Disk beherbergt.

2.3a Zusätzliche SAN Switche in Site 3

Die Site 3 kann mit zusätzlichen SAN Switches ergänzt werden, um z.B.

  • longwave / shortwave Konvertierungen vorzunehmen (falls das Speichersysteme keine lw SFPs unterstützen sollte);
  • eine Verbindung an beide Speichersystem-Controller anbinden zu können;
  • für die Übertragung in Site 1 bzw. Site 2 mehr Buffer Credits zur Verfügung stellen zu können (falls das Speichersystem zu wenig Buffer Credits bereitstellen kann).

Dabei kann entweder nur für eine Fabric ein Switch eingesetzt werden (andere Fabric direkt angebunden), oder für beide Fabrics je ein Switch verwendet werden.

Das folgende Bild zeigt eine Lösung für die in Punkt 2.3 beschriebene Einschränkung:

bild3a

2.4 Integration von Site 3 in Site 1 oder in Site 2

Leider gibt es oft die Einschränkung, dass eine separate Site 3 nicht möglich ist. In diesem Fall kann ggf. die Site 3 in eines der beiden Hauptrechenzentren integriert werden:

bild4

  • Die Anbindung ist dabei identisch zu den oben beschriebenen Varianten (2.1, 2.2 oder 2.3).
  • Wichtig ist, dass alle Geräte der „integrierten Site 3“ strommäßig vom „Gast-RZ“ entkoppelt sind:
    Geht die Stromversorgung im „Gast-RZ“ komplett verloren (z.B. USV 1 defekt, USV 2 übernimmt gesamte Last, USV 2 ist aber damit überlastet und schaltet ab . . . .) müssen die Geräte der „integrierten Site 3“ noch einige Minuten weiterlaufen (10-15 Minuten reichen sicherlich) und von der anderen Site erreichbar sein.
  • Die Geräte der „integrierten Site 3“ sind also: Das Speichersystem für die aktive Quorum Disk und alle aktiven Komponenten (SAN Switches, Multiplexer, etc.) die für die Verbindung zu den Core-Switches im anderen RZ benötigt werden.
  • Dies kann z.B. mit einer zusätzlichen Rack-USV erfolgen, welche die Geräte der „integrierten Site 3“ nach einem Stromausfall im „Gast-RZ“ noch einige Minuten in Betrieb halten kann.
  • Zusätzlich ist empfohlen, die Geräte der „integrierten Site 3“ im „Gast-RZ“ möglichst separat aufzustellen, z.B. eigenes Rack, anderer Raum oder Brandabschnitt usw.

3. Realisierung der Verbindungen

Jede Verbindung zwischen den Core-Switches und dem aktiven Quorum System (in den Skizzen rot dargestellt; bei der Variante 2.3a ist die Verbindung zwischen den Core-Switches und den Switches in Site 3 gemeint) kann mit einer der folgenden Varianten realisiert werden. Dabei ist für jede Verbindung eine andere Variante möglich:

3.1 Direktverbindung mit multimode FC Verkabelung

  • Die einfachste und kostengünstigste Verbindung wird mit shortwave SFPs in Switch und Speichersystem aufgebaut.
  • Die maximalen Kabellängen sind allerdings stark eingeschränkt:
    – OM2-Kabel: 2 gbps: 300 m, 4 gbps: 150 m, 8 gbps:    50 m, 16 gbps:   35 m
    – OM3-Kabel: 2 gbps: 500 m, 4 gbps: 380 m, 8 gbps: 300 m, 16 gbps: 100 m
  • Bitte die möglichen Kabellängen mit dem SAN-Switch-Hersteller abstimmen.

3.2 Direktverbindung mit monomode FC Verkabelung

  • Dieses Setup unterstützt Kabellängen von bis zu 10 km (ggf. mit speziellen „extended length“ SFPs > 10 km)
  • Dazu sind longwave SFPs in Switch und Speichersystem erforderlich
  • Am SAN Switch müssen die Buffer Credits (BCs) des FC-Ports abhängig von Entfernung und Geschwindigkeit eingestellt werden:
    –   4 gbps: mindestens 2 BCs je km
    –   8 gpbs: mindestens 4 BCs je km
    – 16 gbps: mindestens 8 BCs je km

3.3 Nutzung eines Kanals einer CWDM Multiplexer Verbindung

  • Für diese Lösung werden spezielle „colored longwave“ SFPs im Switch und im Speichersystem benötigt.
  • Kompatiblität und Support dieser SFPs muss für Switch und Speichersystem überprüft und ggf. beim Hersteller beantragt werden.
  • BCs wie bei 3.2

3.4 Nutzung eines Kanals einer DWDM Multiplexer Verbindung

  • Dazu werden standard shortwave SFPs in Switch und Speichersystem eingesetzt.
  • BCs wie bei 3.2

3.5 Nutzung einer IP-Verbindung

  • Die aktive Quorum Disk in Site 3 kann auch über eine IP-Verbindung angebunden werden.
  • Dies ist nur mit FCIP möglich. Dabei werden die FC-Frames in IP-Frames eingepackt und transparent übertragen.
  • Die Implementierung erfolgt mit multiprotokoll-Routern (entweder separate Geräte oder Funktionalität in die SAN Switche integriert)
  • Multiprotokoll-Router können ohne SAN-Routing oder mit SAN-Routing (evtl. Lizenz notwendig) verwendet werden:
    – ohne SAN-Routing: gemeinsames Fabric „rechts und links“ der IP-Strecke
    – mit SAN-Routing: getrennte Fabrics „rechts und links“ der IP-Strecke
  • Dieses Setup ist relativ komplex