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

UPDATE 10.03.2014:  Zoning im enhanced Mode
UPDATE 14.07.2014:  Ä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 bei Site 2. Allerdings erfolgen Zugriffe auf Quorum Devices (also auf alle drei Quorum Candidate MDisks) direkt von allen Nodes, unabhängig von dessen Site Attributes.
  • Daher (und auch aus Gründen der Einfachheit) bitte die WWPNs der Speichersysteme immer an alle SVC Nodes zonen. 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. 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. 

    Asynchron dazu wird der Destage auf die primary Copy und bei VDISK-Mirror auch auf die secondary Copy vom preferred Node der VDisk wie folgt durchgeführt:

    • Liegt die Copy in der gleichen Site (oder in Site 3) wie der empfangende Node, führt der empfangende Node den Destage auf Disk direkt 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.
  • 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 remote 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

Advertisements

6 Gedanken zu “Enhanced S. C. Version 7.2 – Teil 1 (IO Handling)

  1. Sehr gute und hilfreiche Zusammenfassung Franz, besten Dank!
    Frage: Warum werden für den enhanced mode mindestens vier Knoten empfohlen?

    • Bei einem Firmware-Upgrade steht ein Node ein paar Minuten nicht zur Verfügung. Bei einem 2-Node Cluster bedeutet das, dass zeitweise in einer Site kein Node mehr online ist. Während dieser Zeit:
      – würden alle rz-übergreifenden VDisk-Mirrors asynchron
      laufen (werden dann automatisch nachsynchronisiert)
      – können keine IOs zu/von Speichersystemen der Site erfolgen, deren
      Node offline ist ! Somit Access-Loss für Daten die nur in diesem RZ liegen.

      Ist in dieser Site noch ein weiterer Node vorhanden (andere IO-Group), treten diese Erscheinungen nicht auf.

  2. Beim nochmaligen Lesen stellen sich mir neue Fragen…
    1. „Im enhanced Mode werden Speichersysteme in Site 1 nur noch von Nodes in Site 1 angesprochen“ – ist das ein KANN oder ein MUSS? Sprich sollte ich mein Zoning so aufsetzen oder könnte ich auch im enhanced mode weiterhin alle Subsysteme von allen Knoten sehen lassen?
    2. Das Handling der Write-IOs klingt nach „broken by design“. Es wäre ja von Vorteil, wenn – vorausgesetzt sie laufen – immer nur die lokalen Knoten destagen. Die Write-Daten haben ja beide, Dank Cache-Mirror. Aber wenn ich lese „Liegt die Copy in der anderen Site schickt der empfangende Node die Daten zum Partner-Node […] im anderen RZ […], der die Daten dort dann auf das Plattensystem schreibt“, frag ich mich ernsthaft, „warum? Der hat die Daten doch schon vom Cache-Spiegeln.“. Und im write-thru Modus müsste der eine Knoten einfach wie bisher, beide destage writes durchführen. Vermutlich ist aber diese „Fallunterscheidung“ bei jedem IO genau das Problem. Zu aufwändig/unperformant. Dann lieber 2x über die Leitung gejagt, Bandbreite ist ja heutzutage nicht mehr das Problem… 🙂

    • zu 1.) Sobald der enhanced Mode aktiviert ist greifen Nodes in Site 1 nur noch auf Speichersysteme in Site 1 und Site 3 zu. Site 2 analog. Das ist auch so, wenn Zoning einen Zugiff der Nodes auf die entfernten Speichersysteme erlauben würde. Meiner Einschätzung nach, kann somit das Zoning auf entfernte Speichersysteme entfallen.
      zu 2, Teil 1.) Korrekt, die Write-Daten liegen wegen des Cache-Mirrors bereits auf der anderen Seite. Trotzdem werden sie bei Version 7.2 nochmals für den Destage auf entfernte Speichersysteme übertragen. Somit wird die Bandbreite (bei ISL Setup im private SAN) doppelt benötigt: für Cache-Mirror und beim Destage auf entfernte Site. Die Frage nach dem „warum?“ kann ich hier nicht beantworten; vielleicht werden wir in der Zukunft überrascht…
      zu 2, Teil 2.) Zitat „… müsste der eine Knoten einfach wie bisher beide destage writes durchführen….“. Anmerkung: Das kann er für entfernte Speichersysteme nicht mehr, da er im enhanced Mode nur noch auf Speichersysteme der gleichen Site (oder Site 3) zugreifen kann. Daher muss der Knoten den Schreibauftrag (in 7.2 zusammen mit den Daten) an einen Node im anderen RZ übergeben.
      zu 2, Teil 3.) Zität „… Bandbreite ist ja heutzutage nicht mehr das Problem…“. Anmerkung: Mehr Bandbreite bedeutet oft höhere Kosten. Daher wäre hier ein anderes Verhalten wünschenswert – siehe letzter Satz unter „zu 2, Teil 1.)“.

      • Update 10.3.2014:
        Bitte im enhanced Mode das Zoning identisch zum non-enhanced Mode aufsetzen. Somit alle Speichersysteme an alle Nodes (auch Site-übergreifend) zonen.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s