Los geht's
StorageGRID Swift REST-API-Operationen
Änderungen vorschlagen
PDFs
Speziell für das StorageGRID System wurden Vorgänge zur Swift REST API hinzugefügt.
ABRUFEN der Container-Konsistenzanforderung
"Konsistenzwerte" Sorgen Sie für ein Gleichgewicht zwischen der Verfügbarkeit der Objekte und der Konsistenz dieser Objekte über verschiedene Storage-Nodes und Standorte hinweg. Mit der GET-Container-Konsistenzanforderung können Sie die Konsistenz bestimmen, die auf einen bestimmten Container angewendet wird.
Anfrage
| HTTP-Header anfordern | Beschreibung |
|---|---|
X-Auth-Token |
Gibt das Swift-Authentifizierungs-Token für das Konto an, das für die Anforderung verwendet werden soll. |
X-ntap-sg-Konsistenz |
Gibt den Anforderungstyp an, wobei |
Host |
Der Hostname, auf den die Anforderung gerichtet ist. |
Anforderungsbeispiel
GET /v1/28544923908243208806/Swift container X-Auth-Token: SGRD_3a877009a2d24cb1801587bfa9050f29 x-ntap-sg-consistency: true Host: test.com
Antwort
| HTTP-Kopfzeile für Antwort | Beschreibung |
|---|---|
Datum |
Datum und Uhrzeit der Antwort. |
Verbindung |
Ob die Verbindung zum Server offen oder geschlossen ist. |
X-Trans-ID |
Die eindeutige Transaktions-ID für die Anforderung. |
Inhaltslänge |
Die Länge des Reaktionskörpers. |
X-ntap-sg-Konsistenz |
Die Konsistenz, die auf den Container angewendet wird. Folgende Werte werden unterstützt: All: Alle Knoten erhalten die Daten sofort, oder die Anfrage schlägt fehl. Strong-global: Garantiert Lese-nach-Schreiben-Konsistenz für alle Client-Anfragen über alle Standorte hinweg. Strong-site: Garantiert Lese-nach-Schreiben Konsistenz für alle Client-Anfragen innerhalb einer Site. Read-after-New-write: (Standard) bietet Read-after-write-Konsistenz für neue Objekte und eventuelle Konsistenz für Objektaktualisierungen. Hochverfügbarkeit und garantierte Datensicherung Empfohlen für die meisten Fälle. Verfügbar: Bietet eventuelle Konsistenz für neue Objekte und Objekt-Updates. Verwenden Sie für S3-Buckets nur nach Bedarf (z. B. für einen Bucket mit Protokollwerten, die nur selten gelesen werden, oder für HEAD- oder GET-Vorgänge für nicht vorhandene Schlüssel). Nicht unterstützt für S3 FabricPool-Buckets. |
Antwortbeispiel
HTTP/1.1 204 No Content Date: Sat, 29 Nov 2015 01:02:18 GMT Connection: CLOSE X-Trans-Id: 1936575373 Content-Length: 0 x-ntap-sg-consistency: strong-site
PUT Container-Konsistenzanforderung
Mit der Konsistenzanforderung für PUT-Container können Sie die Konsistenz angeben, die auf Vorgänge angewendet werden soll, die auf einen Container ausgeführt werden. Standardmäßig werden neue Container mit der Konsistenz „Read-after-New-write“ erstellt.
Anfrage
| HTTP-Header anfordern | Beschreibung |
|---|---|
X-Auth-Token |
Swift Authentifizierungs-Token für das Konto zur Verwendung für die Anforderung. |
X-ntap-sg-Konsistenz |
Die Konsistenz, die auf Vorgänge auf dem Container angewendet werden soll. Folgende Werte werden unterstützt: All: Alle Knoten erhalten die Daten sofort, oder die Anfrage schlägt fehl. Strong-global: Garantiert Lese-nach-Schreiben-Konsistenz für alle Client-Anfragen über alle Standorte hinweg. Strong-site: Garantiert Lese-nach-Schreiben Konsistenz für alle Client-Anfragen innerhalb einer Site. Read-after-New-write: (Standard) bietet Read-after-write-Konsistenz für neue Objekte und eventuelle Konsistenz für Objektaktualisierungen. Hochverfügbarkeit und garantierte Datensicherung Empfohlen für die meisten Fälle. Verfügbar: Bietet eventuelle Konsistenz für neue Objekte und Objekt-Updates. Verwenden Sie für S3-Buckets nur nach Bedarf (z. B. für einen Bucket mit Protokollwerten, die nur selten gelesen werden, oder für HEAD- oder GET-Vorgänge für nicht vorhandene Schlüssel). Nicht unterstützt für S3 FabricPool-Buckets. |
|
Der Hostname, auf den die Anforderung gerichtet ist. |
Zusammenspiel von Konsistenz- und ILM-Regeln zur Beeinträchtigung der Datensicherung
Beide Ihre Wahl "Konsistenzwert" Ihre ILM-Regel wirkt sich darüber hinaus auf den Schutz von Objekten aus. Diese Einstellungen können interagieren.
Die beim Speichern eines Objekts verwendete Konsistenz wirkt sich beispielsweise auf die anfängliche Platzierung von Objekt-Metadaten aus, während der "Aufnahmeverhalten" Die für die ILM-Regel ausgewählt wurde, wirkt sich auf die anfängliche Platzierung von Objektkopien aus. StorageGRID benötigt zur Erfüllung von Clientanfragen Zugriff auf die Metadaten und die Daten eines Objekts. Durch die Auswahl einer passenden Sicherungsstufe für die Konsistenz und das Aufnahmeverhalten können die Daten am Anfang besser gesichert und Systemantworten besser vorhersehbar sein.
Beispiel für die Interaktion von Konsistenz- und ILM-Regeln
Angenommen, Sie haben ein Grid mit zwei Standorten mit der folgenden ILM-Regel und folgender Konsistenz:
-
ILM-Regel: Erstellen Sie zwei Objektkopien, eine am lokalen Standort und eine an einem entfernten Standort. Das strikte Aufnahmeverhalten wird ausgewählt.
-
**: "Strong-global" (Objektmetadaten werden sofort an alle Standorte verteilt.)
Wenn ein Client ein Objekt im Grid speichert, erstellt StorageGRID sowohl Objektkopien als auch verteilt Metadaten an beiden Standorten, bevor der Kunde zum Erfolg zurückkehrt.
Das Objekt ist zum Zeitpunkt der Aufnahme der Nachricht vollständig gegen Verlust geschützt. Wenn beispielsweise der lokale Standort kurz nach der Aufnahme verloren geht, befinden sich Kopien der Objektdaten und der Objektmetadaten am Remote-Standort weiterhin. Das Objekt kann vollständig abgerufen werden.
Wenn Sie stattdessen dieselbe ILM-Regel und die Konsistenz von „starken Standorten“ verwenden, erhält der Client möglicherweise eine Erfolgsmeldung, nachdem die Objektdaten am Remote-Standort repliziert wurden, aber bevor die Objektmetadaten dort verteilt werden. In diesem Fall entspricht die Sicherung von Objektmetadaten nicht dem Schutzniveau für Objektdaten. Falls der lokale Standort kurz nach der Aufnahme verloren geht, gehen Objektmetadaten verloren. Das Objekt kann nicht abgerufen werden.
Die Beziehung zwischen Konsistenz- und ILM-Regeln kann komplex sein. Wenden Sie sich an NetApp, wenn Sie Hilfe benötigen.
Anforderungsbeispiel
PUT /v1/28544923908243208806/_Swift container_ X-Auth-Token: SGRD_3a877009a2d24cb1801587bfa9050f29 x-ntap-sg-consistency: strong-site Host: test.com
Antwort
| HTTP-Kopfzeile für Antwort | Beschreibung |
|---|---|
|
Datum und Uhrzeit der Antwort. |
|
Ob die Verbindung zum Server offen oder geschlossen ist. |
|
Die eindeutige Transaktions-ID für die Anforderung. |
|
Die Länge des Reaktionskörpers. |
Antwortbeispiel
HTTP/1.1 204 No Content Date: Sat, 29 Nov 2015 01:02:18 GMT Connection: CLOSE X-Trans-Id: 1936575373 Content-Length: 0