Administrator Guide

Detach-Regel
Detach-Regeln sind die Richtlinie einer Consistency Group für die automatische Auswahl eines gewinnenden Clusters, wenn es zu einem
Ausfall der Verbindung zwischen Clustern kommt.
Für Metro Node-Metro-Konfigurationen gibt es zwei Detach-Regeln für Consistency Groups:
● no-automatic-winner – Die Consistency Group wählt kein Gewinner-Cluster aus.
● winner cluster-name delay seconds – Das durch „cluster-name“ angegebene Cluster wird zum Gewinner deklariert, wenn
ein Ausfall der Verbindung zwischen Clustern länger als die Anzahl der Sekunden dauert, die durch die Verzögerung festgelegt sind.
Wenn für eine Consistency Group eine Detach-Regel konfiguriert wurde, gilt die Regel für alle Volumes in der Consistency Group und sie
überschreibt alle Regelsätze, die auf individuelle Volumes angewendet wurden.
Diese Eigenschaft gilt nicht für lokale Consistency Groups.
Standardmäßig ist keine bestimmte Detach-Regel für eine Consistency Group konfiguriert. Stattdessen wird die Detach-Regel no-
automatic-winner als Standardeinstellung für eine Consistency Group festgelegt, die für beide Cluster sichtbar ist.
Eine Best Practice besteht darin, Detach-Regeln auf eine Consistency Group anzuwenden, die die Anforderungen Ihrer Anwendung in
puncto I/O-Kontinuität und Datenverlusttoleranz erfüllt.
Verwenden Sie die Befehle consistency-group set-detach-rule zum Konfigurieren der Detach-Regel für eine Consistency
Group:
● Verwenden Sie den Befehl consistency-group set-detach-rule no-automatic-winner, um die Detach-Regel auf
no-automatic-winner festzulegen:
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule no-automatic-winner
● Verwenden Sie den Befehl consistency-group set-detach-rule winner, um anzugeben, welches Cluster der Gewinner
ist, und die Anzahl der Sekunden, die Metro Node nach einem Verbindungsausfall wartet, bevor er das Gewinner-Cluster trennt:
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule winner --cluster
cluster-1 --delay 5s
In der folgenden Tabelle wird das Verhalten der Detach-Regel für eine synchrone Consistency Group beschrieben.
Tabelle 9. Verhalten der Detach-Regel – synchrone Consistency Group
Detach-Regel Verhalten (unabhängig vom Cluster, auf dem I/O-Vorgänge
stattfinden)
Cluster-1 gewinnt I/O ist auf Cluster-1 zulässig.
I/O-Unterbrechungen auf Cluster-2
Kein Datenverlust/kein Daten-Rollback
Cluster-2 gewinnt I/O-Unterbrechungen auf Cluster-1
I/O ist auf Cluster-2 zulässig.
Kein Datenverlust/kein Daten-Rollback
Kein automatischer Gewinner
a
I/O-Unterbrechungen auf Cluster-1
I/O-Unterbrechungen auf Cluster-2
Kein Datenverlust/kein Daten-Rollback
a.
DU auf beiden Clustern, wenn die WAN-COM-Verbindung zwischen Metro Node-Clustern ausfällt
Beachten Sie Folgendes:
● Aktive I/O zeigt aktive Schreibvorgänge an.
● Das in der vorherigen Tabelle beschriebene Verhalten der Detach-Regel basiert auf der Annahme, dass es im Gewinner-Cluster eine
funktionsfähige Komponente während der Cluster-Partition gibt.
● Verwenden Sie den Befehl consistency-group resume-after-rollback, um nach dem Rollback fortzufahren.
● Im Falle der Detach-Regel no-automatic-winner müssen Sie zum Fortsetzen der I/O manuell ein Cluster als Gewinner auswählen.
Verwenden Sie den Befehl consistency-group choose-winner, um einen Gewinner auszuwählen.
68
Consistency Groups