Datacore SANsymphony bietet Software defined Storage mit transparentem Spiegel im active-active Modus.
Seit Version SANsymphony 10 PSP7 unterstützt Datacore eine Witness Funktion.
Das Problem
Wenn beide Datacore Hosts sowohl Spiegelpfade, als auch LAN Verbindung verlieren, entsteht eine sogenannte Split-Brain Situation.
Beide Hosts DC1 und DC2 sind funktionsfähig und haben intakte Daten auf ihrem Datastore. Beide Hosts können Storage I/O von Servern (H1-H4) in ihrem Bereich bearbeiten. dadurch erfahren beide Hälften des Datenspeichers unterschiedliche Veränderungen, die nicht mehr in Einklang gebracht werden können.
Zur Wiederherstellung des Spiegels muss einer der beiden Köpfe zum Master erklärt werden. Alle Änderungen auf der anderen Seite müssen verworfen werden. Datenverlust !
Witness
Hier kommt der Witness ins Spiel. Sobald ein Datacore Host seinen Spiegelpartner weder über den Mirror-Pfad, noch über LAN erreichen kann, versucht er Kontakt mit dem Witness aufzunehmen. Gelingt dies nicht, verweigert er alle I/O auf seinen Datastore.
Szenario 1 – ohne Witness
Im Folgenden ist ein Szenario dargestellt mit zwei Sites im active/active Betrieb. Hosts verwenden als bevorzugte Storage den lokalen DataCore Server, können aber im Fehlerfall auch gegen den remote Datastore arbeiten.
Durch eine Unterbrechung der Glasfaserverbindung werden der Inter-Switch-Link (ISL) im SAN, der Datacore Spiegel-Link (MIR) und die LAN-Verbindung gekappt. Beide Rechenzentren arbeiten autonom weiter und ändern Daten auf den Datastores.
Beide Hälften des Spiegels laufen auseinander und können nicht wieder durch ein Log-Recovery synchronisiert werden. Die einzige Möglichkeit besteht darin, sich für eine Seite zu entscheiden und ein Full-Recovery auf die andere Seite zu starten. Dies bedeutet Datenverlust für eine Seite.
Szenario 2 – mit Witness
Gleiches Szenario wie unter 1, jedoch in diesem Fall mit Witness (W) auf Seite von SDS1.
Nach Unterbrechung der Verbindung (Zeitpunkt x) erreicht SDS1 den Witness und präsentiert weiterhin LUNs an die Server. Prinzipiell an alle Server, jedoch kann er nur von Servern der Site 1 erreicht werden. SDS2 hat keinen Kontakt zum Spiegelpartner und keinen Kontakt zum Witness. Er stellt alle Zugriffe auf seine Datenspeicher ein.
Die Server auf Site 2 erleiden einen APD, aber die Daten auf der Storage bleiben im Zustand von Zeitpunkt x eingefroren. Nach Wiederherstellung des Spiegels kann Site 2 von Site 1 durch ein Log-recovery wieder synchronisiert werden.
Installation
Voraussetzung ist die Version SANsymphony 10 PSP7. Nach Installation des PSP7 muss eine Blindaktivierung ausgelöst werden. D.h. man aktiviert den Cluster, ohne einen Lizenzschlüssel einzutragen. Nach erfolgreicher Aktivierung ist das Witness-Feature auf der Lizenzseite zu sehen.
Die Installation des Witness erfolgt nur über Powershell CMDlets. Eine GUI gibt es (noch) nicht. Dazu öffnet man von einem der beiden Datacore Hosts eine PowerShell und verbindet sich mit dem Datacore Server. In meinem Beispiel heissen die beiden Datacore Server SDS1 und SDS2. Als Witness fungiert ein physischer Veeam-Backup-Proxy am Standort 1.
Dieser erste Schritt ist wichtig und war zu Anfang nicht dokumentiert.
Connect-DCSserver sds1
Nachdem die Connection steht, kann man den Witness definieren. Der Name ist frei wählbar. Der gewählte Witness muss auf Ping Anfragen antworten.
Add-DcsWitness -Name "witness 1" -Address "172.22.7.110"
Wir können nun prüfen, ob beide Hosts mit dem Witness Kontakt aufnehmen können.
Invoke-DcsWitnessContact
Das Cmdlet forder zur Eingabe des Witness-Namens auf (witness 1).
cmdlet Invoke-DcsWitnessContact at command pipeline position 1 Supply values for the following parameters: Witness: witness 1 ServerId WitnessId ResponseStatus -------- --------- -------------- 7233CB41-D6A1-4730-B9DB... 79506f86bfa748779b71eb1... Success 1503818E-E8E2-4370-9130... 79506f86bfa748779b71eb1... Success
Beide Server können den Witness erreichen.
Wir können einen bestehenden Witness mit folgendem Befehl abfragen.
PS C:\Program Files\DataCore\SANsymphony> Get-DcsWitness Alias : witness 1 IPAddress : 172.22.7.110 SequenceNumber : 97879 Id : 79506f86bfa748779b71eb12c1ad45b6 Caption : witness 1 ExtendedCaption : Internal : False
Witness als Default für alle vDisks setzen
Der Witness ist zwar eingerichtet, aber man müsste nun selektiv den Witness für einzenlne vDisks definieren. In der Regel genügt es, den den Witness als Default für alle vDisks zu definieren.
Set-DcsServerGroupDefaultWitnessProperties -Address "172.22.7.110"
OurGroup : True
Alias : Server Group
Description :
State : Present
SmtpSettings : DataCore.Executive.SmtpServerSettings
LicenseSettings : DataCore.Executive.LicenseSettings
LicenseType : Regular
ContactData : DataCore.Executive.ContactData
StorageUsed : 49.82 TB
BulkStorageUsed : 0 B
MaxStorage : 100 TB
RecoverySpeed : 32
ExistingProductKeys : {, , , ...}
DataCoreStorageUsed : 0 B
SupportBundleRelayAddress :
MirrorTrunkMappingEnabled : False
SelfHealingDelay : 480
DefaultWitness : f33551cf965e4dc887abe750130db21a
DefaultWitnessOption : Automatic
WitnessAllowed : True
SequenceNumber : 103302
Id : 1f929299-c9f9-419c-a7e9-8c7c694102b5
Caption : Server Group
ExtendedCaption : Server Group
Internal : False
Fazit
Mit der Einführung der Witness-Rolle erfüllt DataCore letztendlich eine lange geforderte Möglichkeit, um Split-Brain Situationen zu vermeiden. Wir kennen die Verwendung eines Witness bereits aus anderen Hochverfügbarkeits-Szenarien, wie z.B. vSAN oder vCenter-HA.