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

Quorum Disks im non-enhanced Mode

Dieser Beitrag beschreibt Grundlagen zu SVC Quorum Disks, sowie die Besonderheiten und Empfehlungen im non-enhanced Stretched Cluster Mode.

Zum Thema „Quorum“ sind folgende weitere Beiträge geplant:

  • Quorum Disks im enhanced Mode
  • Anbindung der aktiven Quorum Disk in Site 3

Grundlagen:

  • Wofür: In der aktiven Quorum Disk werden wichtige SVC Metadaten (die in den Nodes vorgehalten sind) nochmals extern abgelegt. Dies ist z.B. das Mapping von VDISK-Extents zu den Extents der MDISKs und ein Journaling der VDISK-Mirrors. Außerdem spielt die aktive Quorum Disk die entscheidende Rolle beim automatischen Site-Failover.
  • Jeder SVC Cluster (lokal und stretched) benötigt 3 Quorum Candidates. Nur einer davon ist zu einem Zeitpunkt aktiv; dies ist die aktive Quorum. Die anderen beiden Candidates stehen als Reserve zur Verfügung, falls die aktive Quorum Disk ausfallen sollte.
  • Der SVC Cluster definiert die Quorum Candidates automatisch. Dazu werden bei drei MDISKs, die sich in einem Pool (Managed Disk Group) befinden, jeweils ein paar hundert MB (z.B. Extent Size 128 MB: 3 Extents;  Extent Size 256 MB: 2 Extents;  ab Extent Size von 512 MB: 1 Extent) dafür reserviert. Die verbleibenden Extents dieser MDISKs kann für Benutzerdaten verwendet werden.
  • Die automatische Definition der Quourm Disks ist für lokal aufgebaute Cluster  (alle Nodes in gleichen RZ) in der Regel in Ordnung. Beim Stretched Cluster müssen jedoch die Quorum Disks besonders verteilt werden – dies muss bei der Installation beachtet und speziell eingerichtet werden.

Anforderungen im Stretched Cluster:

Aktive Quorum Disk:

  • Die aktive Quorum Disk muss sich in Site 3 befinden. Sie wird auch als „Extended Quorum Disk“ bezeichnet.
  • Dazu ist in Site 3 ein Speichersystem notwendig, das von IBM für diesen Zweck freigegeben ist. In der SVC Interoperability Matrix muss dazu beim Speichersystem „supports extended quorum“ (in der Spalte „Supports Quorum Disk“) vermerkt sein.

Meine Empfehlungen für das Speichersystem in Site 3:

  • Eigenes kleines Speichersystem (z.B. IBM Storwize V3700) mit 4 „kleinen“ Platten (SAS, 10k).
  • Setup mit RAID5 2+P und einer Hotspare Disk. Definition eines Volumes mit 1 GiB (binäres Gigabyte), das die aktive SVC Quorum Disk aufnehmen soll.
  • Das Speichersystem sollte dediziert als aktives Quorum Device verwendet werden. Sollte die Dedizierung nicht gewünscht sein, empfehle ich zumindest das RAID-Array mit dem Quorum-Volume zu dedizieren. Andere RAID-Arrays können ggf. für non-SVC Traffic, z.B. als Disk Pool für Backup, eingesetzt werden.

Nicht aktive Quorum Disks:

  • In Site 1 und in Site 2 muss je ein Quorum Candidate eingerichtet werden.
  • Dies ist nur auf Speichersystemen möglich, die in der SVC Interoperability Liste in der Spalte „Supports Quorum Disk“ freigegeben sind.
  • Ich empfehle in Site 1 und Site 2 je ein dediziertes Volume mit 1 GiB zur Verwendung als Quorum Candidate anzulegen.

Quorum Disks implementieren:

Quorum Disks integrieren:

  • Ich empfehle Quorum-Disks als solche zu dedizieren, d.h. diese MDISKs nicht zusätzlich für Extent Allocations (VDISKs) zu verwenden. Damit wird eine Trennung zwischen SVC Metadaten und Benutzerdaten erreicht.
  • Quorum Disks können nur auf MDISKs definiert werden, die sich in einem Pool (managed disk group) befinden. Ich empfehle, dafür einen eigenen Pool zu definieren (Quorum-Pool), der nur die 3 Quorum MDISKs (mit je 1 GiB) beinhaltet. Sollte eine Quorum MDISK ausfallen, ist der Zugriff auf die anderen Quorum MDISKs möglich, auch wenn sich alle Quorum MDISKs im gleichen Pool befinden !

Verwendung einrichten:

  1. Quorum Disks definieren:
    CLI:> svctask chquorum –mdisk [id oder name der 1. Quorum Disk] 0
    CLI:> svctask chquorum –mdisk [id oder name der 2. Quorum Disk] 1
    CLI:> svctask chquorum –mdisk [id oder name der 3. Quorum Disk] 2
    Die letzte Ziffer ist die Quorum-ID (0, 1 und 2).
  2. Aktive Quorum Disk festlegen; dabei muss die Quorum-ID angegeben werden, deren MDISK in der Site 3 liegt:
    CLI:> svctask chquorum –active [Quorum-ID]
  3. Ab Version 6.2 muss noch folgende Einstellung vorgenommen werden:
    CLI:> svctask chquorum –mdisk [id oder name der 1. Quorum Disk] –override yes 0
    CLI:> svctask chquorum –mdisk [id oder name der 2. Quorum Disk] –override yes 1
    CLI:> svctask chquorum –mdisk [id oder name der 3. Quorum Disk] –override yes 2
    Mit „override yes“ wird die Funktion zur automatischen Quorum-Auswahl überschrieben, d.h. abgeschaltet.
  4. Am Ende bitte alles mit „svcinfo lsquorum“ überprüfen.

Weitere Hinweise:

Mit o.g. Einstellungen wird der SVC Cluster nach einem Ausfall die festgelegte Konfiguration automatisch wiederherstellen, z.B.:

Ausgangssituation:

  • Quorum-ID 0 = MDISK 5 = Quorum candidate
  • Quorum-ID 1 = MDISK 1 = Quorum candidate
  • Quorum-ID 2 = MDISK 9 = Aktive Quorum Disk

Nach Ausfall von MDISK 9:

  • Quorum-ID 0 = MDISK 5 wird zur aktiven Quorum Disk
  • Da nur noch 2 Quorums im System sind, sucht sich der Cluster eine weitere MDISK mit freier Kapazität und definiert dort einen weiteren Quorum Candidate, z.B:
    Quorum-ID 2 = MDISK 179 (temporärer Quorum Candidate)

Nach Wiederverfügbarkeit von MDISK 9:

  • Quorum-ID2 wird wieder auf die MDISK 9 gesetzt und aktiv verwendet.
  • Temporärer Quorum Candidate auf MDISK 179 wird verworfen.

 

Viele Grüße aus München (bei strahlendem Sonnenschein), Franz.

Enhanced S. C. Version 7.2 – Teil 1 (IO Handling)

UPDATE 10.03.2014:  Zoning im enhanced Mode (Änderungen in blau)

Dieser Eintrag beschreibt das IO Handling bei non-enhanced und enhanced Stretched Cluster.

Definition: „Empfangender Node“ ist der SVC Node, der vom Server über einen Pfad angesprochen wird, der also den IO empfängt.

Zunächst allgemeine Informationen:

  • Im klassischen non-enhanced Mode (ab Version 5.1) macht der SVC keinerlei Unterschiede, ob er lokal oder stretched implementiert ist. Der Cluster weis nicht, ob er lokal oder stretched implementiert ist. Die Funktionsweise ist daher in beiden Fällen absolut identisch.
  • Im enhanced Mode (optional ab Version 7.2) wird jedem SVC Node und jedem Speichersystem die Site 1 oder Site 2 zugeordnet. Das Speichersystem mit der aktiven Quorum Disk wird der Site 3 zugeordnet. Der SVC Cluster weis nun, in welcher Site (=RZ) sich welche SVC Nodes und Speichersysteme befinden (= Site awareness).
  • Die Verkabelung ist im enhanced Mode identisch zum non-ISL oder ISL Setup.
  • Der enhanced Mode kann online im laufenden Betrieb aktiviert werden.
  • Für den enhanced Mode sind mindestens 4 SVC Nodes im Cluster empfohlen.

Zugriff auf die Speichersysteme:

Non-enhanced Mode:

  • Alle Speichersysteme müssen von allen SVC Nodes eines Clusters in Zugriff genommen werden. Genauer: Eine WWPN an einem Speichersystem darf entweder von keinem SVC Node gesehen werden oder muss von allen Nodes des Clusters gesehen werden.

Enhanced Mode:

  • Im enhanced Mode werden Speichersysteme in Site 1 nur noch von Nodes in Site 1 angesprochen; analog dazu auf Site 2. Speichersysteme in Site 3 (aktive Quorum Disk) werden von allen SVC Nodes (Site 1 und Site 2) angesprochen.
  • Trotzdem müssen die WWPNs der Speichersysteme in Site 1, 2 und 3 an alle SVC Nodes gezont werden. Somit kein unterschiedliches Zoning für non-enhanced und enhanced Modes.

IOs zwischen Server und Nodes:

  • Hier ändert sich nichts. Eine VDISK wird durch die beiden Nodes einer IO-Group (Caching IO-Group), ggf. zusätzlich durch die beiden Nodes einer weiteren IO-Group (Access IO-Group), mit Pfaden zu den Servern dargestellt. Die Pfade zum preferred Node (= ein bestimmter Node der Caching IO-Group) einer VDISK werden vom SVC gekennzeichnet;  die Multipathing Software am Server kann dieses Kennzeichen abfragen und die Path Selection davon abhängig machen.
  • Nach wie vor ist dynamisches Multipathing zu allen Nodes, die eine bestimmte VDISK mit Pfaden zu den Servern geben, möglich.

Wichtig: Der enhanced Mode erfordert keine Änderungen auf Server-Ebene.

Verarbeitung von Read IOs:

Non-enhanced Mode:

  • Der empfangende Node (der Caching IO-Group) bearbeitet einen Lese-IO selbständig. Sind die Daten nicht im lokalen Read-Cache vorhanden, holt der Node die Daten direkt vom Speichersystem. Bei aktiviertem (und synchronisiertem) VDISK-Mirror werden die Daten immer von der primary Copy gelesen. Ist die primary Copy im anderen Rechenzentrum, wird über die Entfernung gelesen. Dadurch erhöht sich in diesem Fall die Latenz um 0,1 ms je 10 km Kabellänge. Dieser entfernungsabhängige Latenz-Anteil wird komplett dem Server-IO aufgeschlagen.

Enhanced Mode:

  • Im enhanced Mode liest der empfangende Node (der Caching IO-Group) die Daten immer vom lokalen Speichersystem, wenn eine lokale gültige Kopie existiert. Dies kann bei Nutzung von VDISK-Mirror auch die secondary Copy der VDISK sein.
  • Ist keine lokale gültige Kopie der Daten vorhanden, beauftragt der empfangende Node seinen Partner-Node (gleiche IO-Group) im anderen RZ die Daten von dort zu lesen und an ihn zu senden. Im ISL Setup erfolgt dieser Vorgang über das private SAN.
  • Falls der Partner-Node offline sein sollte, wird ein anderer Node im entfernten RZ dazu eingesetzt. Daher die Empfehlung einen enhanced Stretched Cluster mit mindestens 4 Nodes auszustatten.

somit:

  • Bei Nutzung von VDISK Mirror entstehen keine entfernungsabhängigen Latenz-Aufschläge, wenn die lokale Kopie gültig (synchron) ist.
  • Ist keine gültige lokale Kopie vorhanden (ggf. wenn kein VDISK-Mirror eingesetzt wird oder Mirror nicht synchron sein sollte):
    • entfernungsabhängige Latenzen
    • höhere CPU-Auslastung der entfernten Nodes
    • höhere Last im private SAN beim ISL Setup (ggf. berücksichtigen)

Verarbeitung von Write IOs:

Non-enhanced Mode:

  • Der empfangende Node (der Caching IO-Group) gibt den Write-IO an seinen Partner-Node (gleiche IO-Group) im anderen RZ weiter (= Cache-Mirror) und sendet dann ein IO-Complete zum Server. Asynchron dazu wird der Destage auf das Speichersystem vom preferred Node des Volumes vorgenommen. Bei VDISK-Mirror schreibt der preferred Node beide Kopien, in der Regel eine ins lokale RZ und die zweite ins entfernte RZ.
  • Durch den Cache-Mirror (falls Cache nicht abgeschaltet, sprich Write-Through Mode) entsteht eine zusätzliche Latenz in Höhe von 0,1 ms je 10 km Kabellänge. Dieser entfernungsabhängige Latenz-Anteil wird komplett dem Server-IO aufgeschlagen.
  • Beim ISL Setup wird der Cache-Mirror im private SAN und die IOs zu den Servern und Speichersystemen im public SAN durchgeführt.

Enhanced Mode:

  • Der empfangende Node (der Caching IO-Group) gibt den Write-IO an seinen Partner-Node (gleiche IO-Group) im anderen RZ weiter (= Cache-Mirror) und sendet dann ein IO-Complete zum Server. Asynchron dazu wird der Destage auf die primary Copy und bei VDISK-Mirror auch auf die secondary Copy vom empfangenden Node (nicht mehr vom preferred Node) wie folgt durchgeführt:
    • Liegt die Copy in der gleichen Site wie der empfangende Node, führt der empfangende Node das Destage auf Disk selbst durch.
    • Liegt die Copy in der anderen Site schickt der empfangende Node die Daten zum Partner-Node (gleiche IO-Group) im anderen RZ (bei ISL Setup über private SAN), der die Daten dort dann auf das Plattensystem schreibt (bei ISL Setup über public SAN).
      Falls der Partner-Node offline sein sollte, wird ein anderer Node im entfernten RZ mit dem Destage der Daten eingesetzt. Daher die Empfehlung einen enhanced Stretched Cluster mit mindestens 4 Nodes auszustatten.
  • Durch den Cache-Mirror (falls Cache nicht abgeschaltet, sprich Write-Through Mode) entsteht eine zusätzliche Latenz in Höhe von 0,1 ms je 10 km Kabellänge. Dieser entfernungsabhängige Latenz-Anteil wird komplett dem Server-IO aufgeschlagen.
  • Beim ISL Setup findet der Cache-Mirror und das weiterleiten der Destage-Daten zur anderen Site im private SAN, die IOs mit den Servern und zu den Speichersystemen im public SAN statt.

somit:

  • Durch Write-Cache Mirror entstehen entfernungsabhängige Latenz-Aufschläge, außer der Cache wird nicht verwendet (Write-Through Mode).
  • Ist der empfangende Node und eine Kopie der Daten auf Sites 1 und 2 verteilt, werden die Daten zwischen den Sites zweimal über das private SAN übertragen: für Cache-Mirror und für Destage. Bitte bei der Bandbreitendimensionierung beachten.
  • Die CPU-Auslastung der Nodes erhöht sich, da für das Destage einer entfernten Kopie zwei Nodes beteiligt sind.

Viele Grüße, Franz

Stretched Cluster Varianten Überblick

Zur Einstimmung fasse ich die derzeit möglichen Varianten des Stretched Clusters kurz zusammen:

  1. non-ISL Stretched Cluster (ab SVC Version 5.1):
    • “Kreuzverkabelung: Die Hälfte der SVC Node FC-Ports sind direkt an die SAN-Switche im entfernten RZ angeschlossen”
    • Kabellänge zwischen den RZs: 0-10 km (bei 8gbps Verbindungen)
      ab SVC Version 6.2 zusätzlich: 0-20 km (bei 4gbps Verbindungen), 0-40 km (bei 2 gbps Verbindungen)
    • Besonderheit: lw SFPs in den SVC-Nodes und SAN Switches für die “Kreuzverbindungen” notwendig; ggf. colored lw SFPs bei CWDM Infrastrukturen
  2. ISL Stretched Cluster (ab SVC Version 6.3):

    • Alle SVC Node Ports sind an lokale SAN Switches angebunden. Die Nodes werden jedoch in public SAN (2 Fabrics) und private SAN (2 Fabrics) aufgeteilt:
      • Public SAN: Verbindung zu Server und Speichersystemen
      • Private SAN: Node zu Node Verbindungen für SVC Metadaten und Cache-Mirroring
      • Die Trennung erfolgt physisch (eigene Switche für private SAN), per Brocade Virtual Fabrics  bzw.  CISCO vSANs.
    • Entfernung zwischen den RZ von 0 km bis zu (theoretisch) 300 km möglich
    • Bandbreitenanforderung für private SAN (beide private Fabrics zusammen): 4 gbps oder 2 * Peak Write MB/s der Server (whichever is higher)

Ab SVC Version 7.1: optional 8 FC Ports je SVC Node:

  • Nodes können optional mit einem zweiten 4-Port FC-HBA ausgestattet werden.
  • Über Bitmaps kann eingestellt werden, welche Rolle welche Ports übernehmen:
    • Für Server IO (Ports 1-8 möglich) und IO zu Speichersystemen (Ports 1-6 möglich)
    • Für intercluster Kommunikation (remote mirroring zwischen eigenständigen SVC Clusters, Ports 1-8 möglich)
  • Option ist für non-ISL und ISL Varianten möglich

Ab SVC Version 7.2: optional “Enhanced Stretched Cluster”:

  • Der Mode “Enhanced Stretched Cluster” bringt eine “Site-awareness” von SVC Nodes und Speichersystemen:
    Für jeden Node und Speichersystem kann die Site (Rechenzentrum) definiert werden:

    • Site 1 und Site 2 stellen die beiden Haupt-Rechenzentren dar.
    • Site 3 definiert den Standort der aktiven Quorum Disk.
  • Auf den Site-Informationen basierend stehen neue Funktionen und Optimierungen zur Verfügung.
  • Enhanced Stretched Cluster ist für non-ISL und ISL Varianten möglich.

Zusammengefasst stehen 8 Setups zur Verfügung:

  • non-ISL / 4 Ports je Node
  • non-ISL / 8 Ports je Node
  • non-ISL / 4 Ports je Node / enhanced
  • non-ISL / 8 Ports je Node / enhanced
  • ISL / 4 Ports je Node
  • ISL / 8 Ports je Node
  • ISL / 4 Ports je Node / enhanced
  • ISL / 8 Ports je Node / enhanced

Eine schönen Tag wünscht Euch Franz.

Willkommen !

Ich bin Berater für Speicherlösungen bei IBM. Dieser Blog beschäftigt sich mit IBM SVC Stretched Cluster. Alle Informationen stellen meine persönliche Sicht dar und sind keine offiziellen und verbindlichen Informationen von IBM.

Die Informationen in diesem Blog sind sorgfältig erstellt, werden aber nur auf “as-is” Basis bereit gestellt. Es besteht kein Anspruch auf Richtigkeit, Vollständigkeit und Aktualität.

November 2013, Franz Schiegl

FB_FS