ECS: Zu erwartendes Verhalten bei einem vorübergehenden Systemausfall am Standort

Summary: Erwartetes Verhalten von ADO-Buckets, wenn sich das System in einem vorübergehenden Standortausfall (TSO) befindet

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Virtuelles Rechenzentrum (VDC)
Temporärer Standortausfall (TSO)
Zugriff während eines Ausfalls (ADO)


Was ist TSO?

Anhaltender Herzschlagverlust für 15 Minuten
Mögliche Ursachen: Netzwerkprobleme, Stromausfall am Standort oder können manuell aufgerufen werden, wenn Daten von einem bestimmten VDC-Standort nicht gelesen werden können.


Was ist ADO?

ADO ist eine Funktion, die auf Bucket-Ebene aktiviert werden kann. So kann der Bucket während eines vorübergehenden Standortausfalls verfügbar bleiben. TSO bewirkt, dass ECS in einen letztendlich konsistenten Zustand versetzt wird. Zugriffe während Ausfall-/Erstellungs-/Aktualisierungs-/Löschvorgängen befinden sich in einem letztendlich konsistenten Zustand.
ECS lässt jedoch die Wahl zwischen Konsistenz und Verfügbarkeit. ADO-fähige Buckets sind letztendlich konsistent und ermöglichen gleichzeitig die Datenverfügbarkeit. Um eine starke Konsistenz aufrechtzuerhalten, aber auf Kosten des Zugriffs während eines Ausfalls, haben Sie ADO nicht aktiviert.


Erwartetes Verhalten für Szenario mit zwei Standorten (Achten Sie besonders auf erfolgreiche und fehlgeschlagene Vorgänge an beiden Standorten)

ADO-Flussdiagramm für Szenario mit zwei Standorten

Zur Erleichterung des obigen

Vorgehens:Vor TSO
  • Bucket an Standort 1 erstellt und an Standort 2 repliziert
  • Objekt 1 wird an Standort 1 erstellt und an Standort 2 repliziert
  • Obj 2 wird an Standort 2 erstellt und an Standort 1 repliziert
Auftreten eines Netzwerkausfalls 
  • Nach 15 Minuten tritt ein vorübergehender Standortausfall auf.
  • Siehe Liste der erfolgreichen und fehlgeschlagenen Vorgänge an Standort 1. Standort 1 kann beispielsweise nur Objekte erstellen, lesen, lesen und aktualisieren, die sich im Besitz befinden und repliziert sind, Objekte in Buckets auflisten und Buckets auflisten, die sich lokal im Besitz befinden. 
  • Ähnlich wie an Standort 2 finden Sie hier eine Liste der erfolgreichen und fehlgeschlagenen Vorgänge an Standort 2. Wie an Standort 1 kann Standort 2 Objekte erstellen, Objekte lesen und aktualisieren, die sich im Besitz befinden und repliziert werden, Objekte in Buckets auflisten und Buckets auflisten, die sich lokal im Besitz befinden.
  • Somit kann obj 1 an beiden Standorten aktualisiert werden.
  • Obj 2 kann an beiden Standorten aktualisiert werden.
  • Objekte können an beiden Standorten erstellt werden.
Wenn ADO für einen Bucket aktiviert ist und ein vorübergehender Ausfall erkannt wird, kehrt das System zu einem letztendlichen Konsistenzmodell zurück, d. h., Lese-/Schreibvorgänge von einem sekundären Standort (Nicht-Eigentümer) werden akzeptiert und berücksichtigt. Darüber hinaus führt ein Schreibvorgang auf einen sekundären Standort während eines Netzwerkausfalls dazu, dass der sekundäre Standort die Eigentumsrechte an dem Objekt übernimmt. Auf diese Weise kann jedes VDC weiterhin Lese- und Schreibvorgänge für Objekte aus Buckets in einem gemeinsam genutzten Namespace ausführen.


Erwartetes Verhalten für Szenario mit drei Standorten (Standort 1 ist verloren oder von Standort 2 oder Standort 3 aus nicht zugänglich)

ADO-Flussdiagramm für Szenario mit drei Standorten

In diesem Szenario werden die Verbindungen zu Standort 1 vollständig verloren oder Standort 1 ist von Standort 2 und Standort 3 aus nicht zugänglich. Standort 1 ist Eigentümer von Bucket A.

Nach 15 Minuten tritt der TSO in Kraft und die Eigentumsrechte an Bucket A werden an Standort 2 und Standort 3 übertragen. Zwischen diesen beiden Standorten wird die Entscheidung über den Objektbesitz bestimmt, da auf den ursprünglichen Bucket-Eigentümer, also Standort 1, nicht zugegriffen werden kann. 
 
Hinweis: Der Hauptunterschied zwischen zwei Standorten und einem TSO mit drei Standorten besteht darin, dass im Szenario mit drei Standorten das Erstellen und Aktualisieren von Objekten für einen als inaktiv markierten Standort nicht zulässig ist.


Erwartetes Verhalten für drei Standorte, an denen nur ein Standort ausgefallen ist.

ADO-Flussdiagramm für Szenario mit drei Standorten mit einem ausgefallenen Standort

In diesem Szenario ist nur ein Link ausgefallen und somit kann die Bucket-Eigentümerschaft an Standort 1 und Standort 3 oder Standort 2 und Standort 3 übertragen werden. ECS verwendet das PAXOS-Protokoll, um festzustellen, dass Standort 2 ausgefallen ist und Standort 1 und Standort 3 zwei gültige Standorte sind (in diesem Beispiel). Das PAXOS-Protokoll ist ein Mechanismus zur Lösung und Verwaltung von Konsens. In diesem Beispiel wird also zwischen Standort 1 und Standort 3 über den Objektbesitz entschieden. Wie auf der vorherigen Folie ist der Zugriff je nach Standort eingeschränkt.

Weitere Informationen zum erwarteten Verhalten während eines TSO finden Sie im Administrationshandbuch. Hier ist der Link zum ECS 3.8-Administrationshandbuch.

Affected Products

ECS
Article Properties
Article Number: 000224833
Article Type: How To
Last Modified: 22 Jan 2025
Version:  1
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.