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.

Fügen Sie mit der S3 PutObject-Anfrage ein Objekt zu einem Bucket in StorageGRID hinzu

Änderungen vorschlagen
PDFs

Sie können die S3 PutObject Anfrage verwenden, um ein Objekt zu einem Bucket hinzuzufügen.

Konflikte beheben

Konfliktierende Clientanfragen, beispielsweise wenn zwei Clients auf denselben Schlüssel schreiben, werden nach dem Prinzip „latest-wins“ aufgelöst. Der Zeitpunkt der „latest-wins“-Auswertung richtet sich danach, wann das StorageGRID System die jeweilige Anfrage abgeschlossen hat, und nicht danach, wann S3 Clients eine Operation starten.

Objektgröße

Die maximal empfohlene Größe für einen einzelnen PutObject-Vorgang beträgt 5 GiB (5.368.709.120 Byte). Bei Objekten, die größer als 5 GiB sind, sollte stattdessen "mehrteiliger Upload" verwendet werden.

Die maximal unterstützte Größe für eine einzelne PutObject-Operation beträgt 5 TiB (5.497.558.138.880 Bytes).

Hinweis Wenn Sie von StorageGRID 11.6 oder einer älteren Version aktualisiert haben, wird die Warnung „S3 PUT Object size too large“ ausgelöst, wenn Sie versuchen, ein Objekt mit mehr als 5 GiB hochzuladen. Bei einer Neuinstallation von StorageGRID 11.7 oder 11.8 wird die Warnung in diesem Fall nicht ausgelöst. Um jedoch dem AWS S3-Standard zu entsprechen, werden zukünftige Versionen von StorageGRID keine Uploads von Objekten mit mehr als 5 GiB unterstützen.

Größe der Benutzermetadaten

Amazon S3 beschränkt die Größe benutzerdefinierter Metadaten in jedem PUT-Anfrageheader auf 2 KB. StorageGRID beschränkt benutzerdefinierte Metadaten auf 24 KiB. Die Größe benutzerdefinierter Metadaten wird durch die Summe der Anzahl der Bytes in der UTF-8-Kodierung jedes Schlüssels und Werts gemessen.

UTF-8-Zeichen in Benutzermetadaten

Wenn eine Anfrage (nicht maskierte) UTF-8-Werte im Schlüsselnamen oder Wert von benutzerdefinierten Metadaten enthält, ist das Verhalten von StorageGRID undefiniert.

StorageGRID analysiert oder interpretiert keine maskierten UTF-8-Zeichen, die im Schlüsselname oder -wert benutzerdefinierter Metadaten enthalten sind. Maskierte UTF-8-Zeichen werden als ASCII-Zeichen behandelt.

  • PutObject, CopyObject, GetObject und HeadObject-Anfragen sind erfolgreich, wenn die benutzerdefinierten Metadaten maskierte UTF-8-Zeichen enthalten.

  • StorageGRID gibt den x-amz-missing-meta Header nicht zurück, wenn der interpretierte Wert des Schlüsselnamens oder -werts nicht druckbare Zeichen enthält.

Objekt-Tag-Grenzwerte

Sie können neuen Objekten beim Hochladen Tags hinzufügen oder sie bestehenden Objekten hinzufügen. Sowohl StorageGRID als auch Amazon S3 unterstützen bis zu 10 Tags pro Objekt. Tags, die einem Objekt zugeordnet sind, müssen eindeutige Tag-Schlüssel haben. Ein Tag-Schlüssel kann bis zu 128 Unicode-Zeichen lang sein und Tag-Werte können bis zu 256 Unicode-Zeichen lang sein. Schlüssel und Werte sind Groß-/Kleinschreibung.

Objektbesitz

In StorageGRID gehören alle Objekte dem Bucket-Besitzerkonto, einschließlich Objekten, die von einem Nicht-Besitzerkonto oder einem anonymen Benutzer erstellt wurden.

Unterstützte Anfrageheader

Die folgenden Anfrage-Header werden unterstützt:

  • Cache-Control

  • Content-Disposition

  • Content-Encoding

    Wenn Sie `aws-chunked`für Content-EncodingStorageGRID angeben, werden die folgenden Punkte nicht überprüft:

    • StorageGRID überprüft die chunk-signature nicht anhand der Chunk-Daten.

    • StorageGRID überprüft den von Ihnen angegebenen Wert `x-amz-decoded-content-length`nicht anhand des Objekts.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    Chunked Transfer-Codierung wird unterstützt, wenn aws-chunked Nutzlast-Signierung ebenfalls verwendet wird.

  • x-amz-checksum-sha256

  • x-amz-meta-, gefolgt von einem Name-Wert-Paar mit benutzerdefinierten Metadaten.

    Beim Festlegen des Namen-Wert-Paares für benutzerdefinierte Metadaten wird dieses allgemeine Format verwendet:

    x-amz-meta-name: value

    Wenn die Option Benutzerdefinierte Erstellungszeit als Referenzzeit für eine ILM-Regel verwendet werden soll, muss creation-time als Name der Metadaten verwendet werden, die den Erstellungszeitpunkt des Objekts aufzeichnen. Beispielsweise:

    x-amz-meta-creation-time: 1443399726

    Der Wert für creation-time wird als Sekunden seit dem 1. Januar 1970 ausgewertet.

    Hinweis Eine ILM-Regel kann nicht sowohl eine benutzerdefinierte Erstellungszeit für die Referenzzeit als auch die Aufnahmeoption Balanced oder Strict verwenden. Beim Erstellen der ILM-Regel tritt ein Fehler auf.

  • x-amz-tagging

  • S3 Object Lock Anforderungsheader

    • x-amz-object-lock-mode

    • x-amz-object-lock-retain-until-date

    • x-amz-object-lock-legal-hold

      Wird eine Anfrage ohne diese Header gestellt, werden die Standard-Aufbewahrungseinstellungen des Buckets verwendet, um den Objektversionsmodus und das Aufbewahrungsdatum zu berechnen. Siehe "S3 REST API zur Konfiguration von S3 Object Lock verwenden".

  • SSE-Anforderungsheader:

Nicht unterstützte Anfrageheader

Die folgenden Anfrageheader werden nicht unterstützt:

  • If-Match

    Das If-Match header wird akzeptiert, ist aber nicht funktionsfähig.

  • If-None-Match

    Das If-None-Match header wird akzeptiert, ist aber nicht funktionsfähig.

  • x-amz-acl

  • x-amz-sdk-checksum-algorithm

  • x-amz-trailer

  • x-amz-website-redirect-location

    Der x-amz-website-redirect-location`Header gibt `XNotImplemented zurück.

Speicherklassenoptionen

Der x-amz-storage-class Anforderungsheader wird unterstützt. Der übermittelte Wert für x-amz-storage-class beeinflusst, wie StorageGRID Objektdaten während der Aufnahme schützt und nicht, wie viele persistente Kopien des Objekts im StorageGRID System gespeichert werden (dies wird durch ILM bestimmt).

Wenn die ILM-Regel, die auf ein aufgenommenes Objekt zutrifft, die Strict-Aufnahmeoption verwendet, hat der x-amz-storage-class Header keine Auswirkung.

Folgende Werte können für x-amz-storage-class verwendet werden:

  • STANDARD (Standard)

    • Doppelter Commit: Wenn die ILM-Regel die Option „Doppelter Commit“ für das Aufnahmeverhalten festlegt, wird nach der Aufnahme eines Objekts eine zweite Kopie dieses Objekts erstellt und auf einem anderen Storage Node verteilt (doppelter Commit). Bei der Auswertung der ILM wird von StorageGRID geprüft, ob diese anfänglichen Zwischenkopien den Platzierungsanweisungen in der Regel entsprechen. Falls dies nicht der Fall ist, müssen möglicherweise neue Objektkopien an anderen Speicherorten erstellt und die anfänglichen Zwischenkopien gelöscht werden.

    • Ausgeglichen: Wenn die ILM-Regel die Option „Ausgeglichen“ vorsieht und StorageGRID nicht sofort alle in der Regel angegebenen Kopien erstellen kann, erstellt StorageGRID zwei Zwischenkopien auf verschiedenen Storage Nodes.

      Wenn StorageGRID alle in der ILM-Regel angegebenen Objektkopien sofort erstellen kann (synchrones Placement), hat der `x-amz-storage-class`Header keine Auswirkung.

  • REDUCED_REDUNDANCY

    • Dual commit: Wenn die ILM-Regel die Option Dual commit für das Aufnahmeverhalten angibt, erstellt StorageGRID beim Aufnehmen des Objekts eine einzelne Zwischenkopie (single commit).

    • Ausgeglichen: Wenn die ILM-Regel die Option „Ausgeglichen“ angibt, erstellt StorageGRID nur dann eine einzelne Zwischenkopie, wenn das System nicht sofort alle in der Regel angegebenen Kopien erstellen kann. Wenn StorageGRID eine synchrone Platzierung durchführen kann, hat dieser Header keine Auswirkung. Die REDUCED_REDUNDANCY Option ist am besten geeignet, wenn die ILM-Regel, die auf das Objekt zutrifft, eine einzelne replizierte Kopie erstellt. In diesem Fall wird durch die Verwendung von REDUCED_REDUNDANCY diese Option das unnötige Erstellen und Löschen einer zusätzlichen Objektkopie bei jedem Ingest-Vorgang vermieden.

    Die Verwendung der REDUCED_REDUNDANCY Option wird unter anderen Umständen nicht empfohlen. REDUCED_REDUNDANCY Das Risiko von Objekt-Datenverlust während der Aufnahme wird dadurch erhöht. Beispielsweise kann es zu Datenverlust kommen, wenn die einzige Kopie zunächst auf einem Storage Node gespeichert wird, der ausfällt, bevor die ILM-Auswertung erfolgen kann.

Achtung Wenn für einen bestimmten Zeitraum nur eine replizierte Kopie vorhanden ist, besteht das Risiko eines dauerhaften Datenverlusts. Wenn nur eine replizierte Kopie eines Objekts existiert, geht dieses Objekt verloren, wenn ein Storage Node ausfällt oder einen schwerwiegenden Fehler aufweist. Auch während Wartungsarbeiten wie Upgrades ist der Zugriff auf das Objekt vorübergehend nicht möglich.

Die Angabe von REDUCED_REDUNDANCY wirkt sich lediglich darauf aus, wie viele Kopien beim erstmaligen Einlesen eines Objekts erstellt werden. Sie hat keinen Einfluss darauf, wie viele Kopien des Objekts bei der Auswertung durch die aktiven ILM-Richtlinien erstellt werden und führt nicht dazu, dass Daten im StorageGRID System mit geringerer Redundanz gespeichert werden.

Hinweis Wenn Sie ein Objekt in einen Bucket mit aktiviertem S3 Object Lock importieren, wird die REDUCED_REDUNDANCY Option ignoriert. Wenn Sie ein Objekt in einen älteren Compliant-Bucket importieren, gibt die REDUCED_REDUNDANCY Option einen Fehler zurück. StorageGRID führt immer einen Dual-Commit-Import durch, um die Einhaltung der Compliance-Anforderungen zu gewährleisten.

Anfrage-Header für serverseitige Verschlüsselung

Sie können die folgenden Anfrageheader verwenden, um ein Objekt mit serverseitiger Verschlüsselung zu verschlüsseln. Die Optionen SSE und SSE-C schließen sich gegenseitig aus.

  • SSE: Der folgende Header ist zu verwenden, wenn das Objekt mit einem von StorageGRID verwalteten eindeutigen Schlüssel verschlüsselt werden soll.

  • SSE-C: Alle drei dieser Header werden verwendet, wenn das Objekt mit einem eindeutigen Schlüssel verschlüsselt werden soll, den Sie bereitstellen und verwalten.

    • x-amz-server-side-encryption-customer-algorithm: Angeben AES256.

    • x-amz-server-side-encryption-customer-key: Geben Sie Ihren Verschlüsselungsschlüssel für das neue Objekt an.

    • x-amz-server-side-encryption-customer-key-MD5: Der MD5-Digest des Verschlüsselungsschlüssels des neuen Objekts ist anzugeben.

Achtung Die von Ihnen bereitgestellten Verschlüsselungsschlüssel werden niemals gespeichert. Wenn Sie einen Verschlüsselungsschlüssel verlieren, verlieren Sie das zugehörige Objekt. Vor der Verwendung von kundenseitig bereitgestellten Schlüsseln zur Sicherung von Objektdaten sollten die Hinweise zu "Verwendung serverseitiger Verschlüsselung" beachtet werden.
Hinweis Wenn ein Objekt mit SSE oder SSE-C verschlüsselt ist, werden alle Verschlüsselungseinstellungen auf Bucket- oder Grid-Ebene ignoriert.

Versionierung

Wenn die Versionierung für einen Bucket aktiviert ist, wird automatisch eine eindeutige versionId für die Version des gespeicherten Objekts generiert. Diese versionId wird auch in der Antwort mit dem x-amz-version-id Response-Header zurückgegeben.

Wenn die Versionsverwaltung ausgesetzt ist, wird die Objektversion mit einem Nullwert versionId gespeichert, und falls bereits eine Nullversion existiert, wird diese überschrieben.

Signaturberechnungen für den Authorization-Header

Bei der Verwendung des Authorization Headers zur Authentifizierung von Anfragen unterscheidet sich StorageGRID von AWS in folgenden Punkten:

  • StorageGRID erfordert nicht, dass host-Header innerhalb von CanonicalHeaders enthalten sind.

  • StorageGRID erfordert nicht, dass Content-Type innerhalb von CanonicalHeaders enthalten ist.

  • StorageGRID erfordert nicht, dass x-amz-*-Header innerhalb von CanonicalHeaders enthalten sind.

Hinweis Als allgemeine Best Practice sollten diese Header immer innerhalb von CanonicalHeaders enthalten sein, damit sie überprüft werden; wenn diese Header jedoch ausgeschlossen werden, gibt StorageGRID keinen Fehler zurück.

Weitere Informationen finden Sie unter "Signaturberechnungen für den Authorization Header: Übertragung der Nutzlast in einem einzigen Chunk (AWS Signature Version 4)".

Verwandte Informationen