View a markdown version of this page

Wie S3 mit Konflikten in Lebenszykluskonfigurationen umgeht - Amazon Simple Storage Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wie S3 mit Konflikten in Lebenszykluskonfigurationen umgeht

Im Allgemeinen gibt Amazon S3 Lifecycle Kostenoptimierung Vorrang. Wenn sich z. B. zwei Ablaufrichtlinien überschneiden, wird die Ablaufrichtlinie mit der kürzeren Frist durchgesetzt, sodass die Daten nicht länger als erwartet gespeichert werden. Wenn sich zwei Übergangsrichtlinien überschneiden, überführt S3 Lifecycle Ihre Objekte in die Speicherklasse mit geringeren Kosten.

In beiden Fällen versucht S3 Lifecycle den für Sie kostengünstigsten Pfad auszuwählen. Eine Ausnahme von dieser allgemeinen Regel bildet die Intelligent-Tiering S3-Speicherklasse. S3 Intelligent-Tiering wird von S3 Lifecycle gegenüber allen Speicherklassen bevorzugt, mit Ausnahme der Speicherklassen S3 Glacier Flexible Retrieval und S3 Glacier Deep Archive.

Wenn in einer S3-Lebenszykluskonfiguration mehrere Regeln vorhanden sind, kann es sein, dass für ein Objekt am gleichen Tag mehrere S3-Lebenszyklusaktionen auszuführen sind. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

  • Das permanente Löschen hat Vorrang vor einem Übergang.

  • Die Übertragung hat Vorrang vor der Erstellung von Löschmarkierungen.

  • Wenn ein Objekt sowohl für einen S3 Glacier Flexible Retrieval- als auch für einen S3-Übergang Standard-IA (oder einen S3 One Zone-IA) in Frage kommt, entscheidet sich Amazon S3 für den S3 Glacier Flexible Retrieval-Übergang.

Beispiele für überlappende Filter und widersprüchliche Lebenszyklusaktionen

Sie könnten eine S3-Lebenszyklus-Konfiguration angeben, in der Sie überlappende Präfixe oder Aktionen spezifizieren. Die folgenden Beispiele zeigen, wie Amazon S3 potenzielle Konflikte löst.

Beispiel 1: Überlappende Präfixe (kein Konflikt)

Die folgende Beispielkonfiguration weist zwei Regeln auf, die überlappenden Präfixe spezifizieren, wie folgt:

  • Die erste Regel spezifiziert einen leeren Filter, d. h. alle Objekte in dem Bucket werden angesprochen.

  • Die zweite Regel spezifiziert ein Schlüsselnamenpräfix (logs/), d. h. nur eine Untermenge von Objekten.

Regel 1 fordert Amazon S3 auf, alle Objekte ein Jahr nach der Erstellung zu löschen. Regel 2 verlangt von Amazon S3, eine Teilmenge von Objekten 30 Tage nach der Erstellung in die Standard-IA S3-Speicherklasse umzuwandeln.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA</StorageClass> <Days>30</Days> </Transition> </Rule> </LifecycleConfiguration>

Da in diesem Fall kein Konflikt besteht, überträgt Amazon S3 die Objekte mit dem logs/ Präfix 30 Tage nach der Erstellung in die Standard-IA S3-Speicherklasse. Wenn ein Objekt ein Jahr nach der Erstellung erreicht, wird es gelöscht.

Beispiel 2: Widersprüchliche Lebenszyklus-Aktionen

In dieser Beispielkonfiguration gibt es zwei Regeln, die Amazon S3 anweisen, zwei unterschiedliche Aktionen für dieselbe Objektmenge zur selben Zeit in der Lebensdauer des Objekts auszuführen:

  • Beide Regeln geben dasselbe Schlüsselnamenpräfix an, deshalb gelten beide Regeln für dieselbe Objektmenge.

  • Beide Regeln spezifizieren dieselben 365 Tage nach der Erstellung des Objekts, wann die Regeln angewendet werden sollen.

  • Eine Regel weist Amazon S3 an, Objekte in die Standard-IA S3-Speicherklasse umzuwandeln, und eine andere Regel möchte, dass Amazon S3 die Objekte gleichzeitig ablaufen lässt.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA</StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

In diesem Fall wollen Sie, dass Objekte ablaufen (zu entfernen), deshalb macht es keinen Sinn, die Speicherklasse zu ändern, und Amazon S3 wählt einfach die Ablaufaktion für diese Objekte aus.

Beispiel 3: Überlappende Präfixe, die zu widersprüchlichen Lebenszyklus-Aktionen führen

In diesem Beispiel besitzt die Konfiguration zwei Regeln, die überlappende Präfixe angeben, wie folgt:

  • Regel 1 legt ein leeres Präfix fest (was für alle Objekte gilt).

  • Regel 2 spezifiziert ein Schlüsselnamenpräfix (logs/), das eine Untermenge aller Objekte angibt.

Für die Untermenge der Objekte mit dem Schlüsselnamenpräfix logs/ werden die S3-Lebenszyklus-Aktionen aus beiden Regeln angewendet. Eine Regel weist Amazon S3 an, Objekte 10 Tage nach der Erstellung zu übertragen, und eine andere Regel weist Amazon S3 an, Objekte 365 Tage nach dem Erstellen zu übertragen.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA</StorageClass> <Days>10</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA</StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

In diesem Fall entscheidet Amazon S3 den Übergang 10 Tage nach der Erstellung auszuführen.

Beispiel 4: Tag-based Filterung und daraus resultierende widersprüchliche Lebenszyklusaktionen

Angenommen, Sie haben die folgende S3-Lebenszykluskonfiguration, die zwei Regeln enthält, die beide einen Tag-Filter spezifizieren:

  • Regel 1 spezifiziert einen Tag-basierten Filter (tag1/value1). Diese Regel weist Amazon S3 an, Objekte 365 Tage nach der Erstellung in die Speicherklasse S3 Glacier Flexible Retrieval zu übertragen.

  • Regel 2 spezifiziert einen Tag-basierten Filter (tag2/value2). Diese Regel weist Amazon S3 an, Objekte 14 Tage nach der Erstellung ablaufen zu lassen.

Die S3-Lebenszyklus-Konfiguration wird im Folgenden angezeigt.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Tag> <Key>tag1</Key> <Value>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>GLACIER</StorageClass> <Days>365</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Tag> <Key>tag2</Key> <Value>value2</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

Wenn ein Objekt beide Tags hat, muss Amazon S3 entscheiden, welche Regel befolgt werden soll. In diesem Fall lässt Amazon S3 das Objekt 14 Tage nach der Erstellung ablaufen. Das Objekt wird entfernt und die Übergangsaktion wird daher nicht angewendet.