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