Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Objekt-Operationen

Beitragende
PDFs

Die folgenden Swift-API-Vorgänge werden an Objekten durchgeführt. Diese Vorgänge können im nachverfolgt werden "StorageGRID Prüfprotokoll".

Delete Objekt

Durch diesen Vorgang werden der Inhalt und die Metadaten eines Objekts aus dem StorageGRID System gelöscht.

Die folgenden Anfrageparameter sind erforderlich:

  • Account

  • Container

  • Object

Die folgende Anfrageüberschrift ist erforderlich:

  • X-Auth-Token

Bei einer erfolgreichen Ausführung werden die folgenden Antwortheadern mit einem zurückgegeben HTTP/1.1 204 No Content Antwort:

  • Content-Length

  • Content-Type

  • Date

  • X-Trans-Id

Bei der Verarbeitung einer LÖSCHOBJEKTANFORDERUNG versucht StorageGRID, alle Kopien des Objekts sofort von allen gespeicherten Speicherorten zu entfernen. Wenn erfolgreich, gibt StorageGRID sofort eine Antwort an den Client zurück. Wenn nicht innerhalb von 30 Sekunden alle Kopien entfernt werden können (z. B. weil ein Speicherort vorübergehend nicht verfügbar ist), stellt StorageGRID die Kopien in eine Warteschlange zur Entfernung und zeigt dann den Erfolg des Clients an.

Weitere Informationen finden Sie unter "So werden Objekte gelöscht".

GET Objekt

Dieser Vorgang ruft den Objektinhalt ab und ruft die Objektmetadaten von einem StorageGRID System ab.

Die folgenden Anfrageparameter sind erforderlich:

  • Account

  • Container

  • Object

Die folgende Anfrageüberschrift ist erforderlich:

  • X-Auth-Token

Die folgenden Anfragezeilen sind optional:

  • Accept-Encoding

  • If-Match

  • If-Modified-Since

  • If-None-Match

  • If-Unmodified-Since

  • Range

Bei einer erfolgreichen Ausführung werden die folgenden Kopfzeilen mit einem zurückgegeben HTTP/1.1 200 OK Antwort:

  • Accept-Ranges

  • Content-Disposition, Nur wenn zurückgegeben Content-Disposition Es wurden Metadaten festgelegt

  • Content-Encoding, Nur wenn zurückgegeben Content-Encoding Es wurden Metadaten festgelegt

  • Content-Length

  • Content-Type

  • Date

  • ETag

  • Last-Modified

  • X-Timestamp

  • X-Trans-Id

HEAD-Objekt

Dieser Vorgang ruft Metadaten und Eigenschaften eines aufgenommene Objekts von einem StorageGRID System ab.

Die folgenden Anfrageparameter sind erforderlich:

  • Account

  • Container

  • Object

Die folgende Anfrageüberschrift ist erforderlich:

  • X-Auth-Token

Eine erfolgreiche Ausführung gibt die folgenden Header mit einer HTTP/1.1 200 OK-Antwort zurück:

  • Accept-Ranges

  • Content-Disposition, Nur wenn zurückgegeben Content-Disposition Es wurden Metadaten festgelegt

  • Content-Encoding, Nur wenn zurückgegeben Content-Encoding Es wurden Metadaten festgelegt

  • Content-Length

  • Content-Type

  • Date

  • ETag

  • Last-Modified

  • X-Timestamp

  • X-Trans-Id

PUT Objekt

Durch diesen Vorgang wird ein neues Objekt mit Daten und Metadaten erstellt oder ein vorhandenes Objekt durch Daten und Metadaten in einem StorageGRID System ersetzt.

StorageGRID unterstützt Objekte mit einer Größe von bis zu 5 tib (5,497,558,138,880 Byte).

Hinweis Widersprüchliche Clientanforderungen, wie z. B. zwei Clients, die in denselben Schlüssel schreiben, werden auf der Grundlage der „neuesten Wins“ gelöst. Der Zeitpunkt für die Bewertung „neuester Erfolge“ basiert darauf, wann das StorageGRID System eine bestimmte Anfrage abschließt und nicht darauf, wann Swift-Clients einen Vorgang starten.

Die folgenden Anfrageparameter sind erforderlich:

  • Account

  • Container

  • Object

Die folgende Anfrageüberschrift ist erforderlich:

  • X-Auth-Token

Die folgenden Anfragezeilen sind optional:

  • Content-Disposition

  • Content-Encoding

    Verwenden Sie keine Schrottbecherungen Content-Encoding Wenn die ILM-Regel für ein Objekt Objekte nach der Größe filtert und synchrone Platzierung bei der Aufnahme verwendet wird (die ausgewogenen oder strengen Optionen für das Aufnahmeverhalten).

  • Transfer-Encoding

    Verwenden Sie keine komprimierten oder chunked Transfer-Encoding Wenn die ILM-Regel für ein Objekt Objekte nach der Größe filtert und synchrone Platzierung bei der Aufnahme verwendet wird (die ausgewogenen oder strengen Optionen für das Aufnahmeverhalten).

  • Content-Length

    Wenn eine ILM-Regel Objekte nach Größe filtert und bei der Aufnahme synchrone Platzierung verwendet, müssen Sie angeben Content-Length.

    Hinweis Wenn Sie diese Richtlinien für nicht befolgen Content-Encoding, Transfer-Encoding, und Content-Length, StorageGRID muss das Objekt speichern, bevor es die Objektgröße bestimmen kann und die ILM-Regel anwenden kann. Das heißt, StorageGRID muss standardmäßig vorläufige Kopien eines Objekts bei der Aufnahme erstellen. Das heißt, StorageGRID muss die Dual-Commit-Option für das Ingest-Verhalten verwenden.

    Weitere Informationen zur synchronen Platzierung und zu ILM-Regeln finden Sie unter "Datensicherungsoptionen für die Aufnahme".

  • Content-Type

  • ETag

  • X-Object-Meta-<name\> (Objektbezogene Metadaten)

    Wenn Sie die Option User Defined Creation Time als Referenzzeit für eine ILM-Regel verwenden möchten, müssen Sie den Wert in einem benutzerdefinierten Header namens speichern X-Object-Meta-Creation-Time. Beispiel:

    X-Object-Meta-Creation-Time: 1443399726

    Dieses Feld wird seit dem 1. Januar 1970 als Sekunden ausgewertet.

  • X-Storage-Class: reduced_redundancy

    Diese Kopfzeile wirkt sich darauf aus, wie viele Objektkopien StorageGRID erstellt werden, wenn die ILM-Regel, die mit einem aufgenommenen Objekt übereinstimmt, ein Aufnahmeverhalten der Dual-Commit oder Balance angibt.

    • Dual Commit: Wenn die ILM-Regel die Dual Commit-Option für das Aufnahmeverhalten angibt, erstellt StorageGRID bei Aufnahme des Objekts eine einzelne Interimskopie (Single Commit).

    • Ausgeglichen: Wenn die ILM-Regel die Option ausgeglichen angibt, erstellt StorageGRID nur eine Zwischenkopie, wenn das System nicht sofort alle in der Regel angegebenen Kopien erstellen kann. Wenn StorageGRID eine synchrone Platzierung durchführen kann, hat diese Kopfzeile keine Auswirkung.

      Der reduced_redundancy Kopfzeile eignet sich am besten, wenn die ILM-Regel, die dem Objekt entspricht, eine einzige replizierte Kopie erstellt. In diesem Fall verwenden reduced_redundancy Eine zusätzliche Objektkopie kann bei jedem Aufnahmevorgang nicht mehr erstellt und gelöscht werden.

      Verwenden der reduced_redundancy Header wird unter anderen Umständen nicht empfohlen, da dies das Risiko für den Verlust von Objektdaten während der Aufnahme erhöht. Beispielsweise können Sie Daten verlieren, wenn die einzelne Kopie zunächst auf einem Storage Node gespeichert wird, der ausfällt, bevor eine ILM-Evaluierung erfolgen kann.

      Achtung Da nur eine Kopie zu einem beliebigen Zeitpunkt repliziert werden kann, sind Daten einem ständigen Verlust ausgesetzt. Wenn nur eine replizierte Kopie eines Objekts vorhanden ist, geht dieses Objekt verloren, wenn ein Speicherknoten ausfällt oder einen beträchtlichen Fehler hat. Während Wartungsarbeiten wie Upgrades verlieren Sie auch vorübergehend den Zugriff auf das Objekt.

    Beachten Sie, dass Sie angeben reduced_redundancy Wirkt sich nur darauf aus, wie viele Kopien erstellt werden, wenn ein Objekt zum ersten Mal aufgenommen wird. Es hat keine Auswirkungen darauf, wie viele Kopien des Objekts erstellt werden, wenn das Objekt durch die aktiven ILM-Richtlinien evaluiert wird. Außerdem werden Daten nicht mit niedrigerer Redundanz im StorageGRID System gespeichert.

Eine erfolgreiche Ausführung gibt die folgenden Header mit einer "HTTP/1.1 201 created"-Antwort zurück:

  • Content-Length

  • Content-Type

  • Date

  • ETag

  • Last-Modified

  • X-Trans-Id