Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

FabricPool Volume-Tiering-Richtlinien

Beitragende netapp-aaron-holt netapp-lenida johnlantz netapp-bhouser netapp-ahibbard netapp-thomi netapp-dbagwell netapp-aherbin
Änderungen vorschlagen
PDFs

FabricPool Volumen-Tiering-Richtlinien legen fest, welche Daten in einem Volume für das Tiering infrage kommen, und der Parameter für die minimale Anzahl an Kühl-Tagen beim Tiering bestimmt, wann die Daten als inaktiv gelten und für das Tiering infrage kommen.

Hinweis

Zugriffskontrolllisten (ACLs), Verzeichnisstrukturen und Metadaten werden niemals gestuft, sondern verbleiben immer auf der lokalen Tier.

Ein täglicher Hintergrundscan sucht nach selten genutzten Datenblöcken. Sobald genügend 4-KB-Blöcke desselben Volumes erfasst wurden, werden diese zu einem 4-MB-Objekt zusammengefasst und gemäß der Volume Tiering-Richtlinie in die Cloud-Ebene verschoben.

Das Verständnis der Funktionsweise von Tiering-Richtlinien unterstützt bei der Auswahl der passenden Richtlinie für die Anforderungen an das Speichermanagement.

Optionen für Volume-Tiering-Richtlinien

Standardmäßig verwenden Volumes die Volume-Tiering-Richtlinie „Keine“. Eine Ausnahme bilden neu erstellte FlexVol Volumes auf FabricPool Aggregaten, die die Volume-Tiering-Richtlinie „Nur Snapshots“ verwenden.

Der volume object-store tiering show`Befehl kann verwendet werden, um den Tiering-Status eines FabricPool Volumes anzuzeigen. Weitere Informationen zu `volume object-store tiering show finden sich in der "ONTAP-Befehlsreferenz".

Die FabricPool Tiering-Richtlinie wird auf Volume-Ebene festgelegt. Vier Optionen sind verfügbar:

Nur Snapshot

Die `snapshot-only`Tiering-Richtlinie verschiebt Snapshot-Daten, die nicht mehr mit dem aktiven Dateisystem verbunden sind, in eine andere Ebene. Standardmäßig sind zwei Tage Inaktivität erforderlich, bevor ein Snapshot für das Tiering in Frage kommt. Die meisten Datensicherungspläne sind stündlich oder täglich und lesen die Daten lokal, bevor sie getiert werden.

Die Standardeinstellung für die Mindestkühlzeit nach Stufen kann mit dem -tiering-minimum-cooling-days Parameter auf der erweiterten Berechtigungsebene der volume create und volume modify Befehle geändert werden. Gültige Werte sind 2 bis 183 Tage bei Verwendung von ONTAP 9.8 und höher. Bei Verwendung einer ONTAP-Version vor 9.8 sind gültige Werte 2 bis 63 Tage.

Beim Lesen bleiben kalte Blöcke, die mit Snapshot-Kopien verknüpft sind, kalt und werden nicht zurück in die lokale Tier geschrieben.

Automatisch

Die `auto`Tiering-Richtlinie verschiebt alle kalten Daten im Volume, sowohl die Snapshots als auch das aktive Dateisystem, in die Cloud-Tier. Die standardmäßige Mindestkühlzeit für das Tiering beträgt 31 Tage und gilt für das gesamte Volume, sowohl für das aktive Dateisystem als auch für die Snapshots.

Die Standardeinstellung für die Mindestkühlzeit nach Stufen kann mit dem -tiering-minimum-cooling-days Parameter auf der erweiterten Berechtigungsebene der volume create und volume modify Befehle geändert werden. Gültige Werte sind 2 bis 183 Tage.

Beim zufälligen Lesen werden kalte Blöcke in einem Volume mit auf Auto eingestellter Tiering-Richtlinie als hot markiert und zurück in die lokale Tier geschrieben.

Beim sequenziellen Lesen bleiben kalte Blöcke in einem Volume mit der Tiering-Richtlinie Auto kalt und verbleiben auf der Cloud-Ebene. Sie werden nicht zurück in den lokalen Tier geschrieben.

Alle

Die all Tiering-Richtlinie kennzeichnet sofort alle Daten im Volume als kalt und beginnt, sie so schnell wie möglich in die Cloud-Tier zu verschieben. Ein Warten von 48 Stunden, bis neue Blöcke in einem Volume mit der all Tiering-Richtlinie als kalt gelten, ist nicht erforderlich.

Die Mindestkühlzeit für Tiering findet keine Anwendung, da die Daten in die Cloud-Tier verschoben werden, sobald der Tiering-Scan ausgeführt wird, und diese Einstellung nicht geändert werden kann.

Wenn kalte Blöcke in einem Volume mit der Tiering-Richtlinie „All“ gelesen werden, bleiben sie kalt und verbleiben im Cloud-Tier. Sie werden nicht zurück in den lokalen Tier geschrieben.

Hinweis

Die `all`Volume Tiering-Richtlinie sollte nicht auf lesen/schreiben Volumes angewendet werden, die normalen Client-Datenverkehr aufweisen.

Objektspeicherung ist nicht transaktionsorientiert wie Datei- oder Blockspeicherung. Änderungen an Dateien, die als Objekte in Volumes mit der All Tiering-Richtlinie gespeichert werden, können zur Erstellung neuer Objekte, zur Fragmentierung vorhandener Objekte, zu einer verringerten Leseleistung und zu zusätzlichen Speicherineffizienzen führen.

Keine

Die `none`Tiering-Richtlinie behält die Daten eines Volumes in der Performance-Tier und verschiebt keine Daten in andere Tiers.

Das Festlegen der Tiering-Richtlinie auf none verhindert neues Tiering. Volumendaten, die zuvor in die Cloud-Tier verschoben wurden, verbleiben in der Cloud-Tier, bis sie wieder aktiv werden und automatisch zurück in die lokale Tier verschoben werden.

Die Mindestkühlzeit für das Tiering findet keine Anwendung, da die Daten nie in die Cloud-Tier verschoben werden und die Einstellung nicht geändert werden kann.

Wenn kalte Blöcke in einem Volume mit einer auf none gesetzten Tiering-Richtlinie gelesen werden, werden sie heiß gemacht und in das lokale Tier geschrieben.

Die volume show Befehlsausgabe zeigt die Tiering-Richtlinie eines Volumes an. Ein Volume, das noch nie mit FabricPool verwendet wurde, zeigt die none Tiering-Richtlinie in der Ausgabe an.

Hinweis Bei einer SVM DR-Beziehung müssen Quell- und Ziel-Volumes keine FabricPool Aggregate verwenden, sie müssen jedoch dieselbe Tiering-Richtlinie nutzen.

Was geschieht, wenn eine Volume-Tiering-Richtlinie geändert wird?

Die Tiering-Richtlinie eines Volumes kann durch einen volume modify Vorgang geändert werden. Es ist wichtig zu verstehen, wie sich eine Änderung der Tiering-Richtlinie auf die Dauer auswirken kann, bis Daten als kalt gelten und in die Cloud-Tier verschoben werden.

  • Eine Änderung der Tiering-Richtlinie von snapshot-only oder none zu auto bewirkt, dass ONTAP Benutzerdatenblöcke im aktiven Dateisystem, die bereits kalt sind, an die Cloud-Tier sendet, selbst wenn diese Benutzerdatenblöcke zuvor nicht für die Cloud-Tier geeignet waren.

  • Die Änderung der Tiering-Richtlinie zu all von einer anderen Richtlinie bewirkt, dass ONTAP alle Benutzerblöcke im aktiven Dateisystem und in den Snapshots so schnell wie möglich in die Cloud verschiebt. Vor ONTAP 9.8 mussten Blöcke warten, bis der nächste Tiering-Scan ausgeführt wurde.

    Das Zurückverschieben von Blöcken in die Performance Ebene ist nicht zulässig.

  • Eine Änderung der Tiering-Richtlinie von auto zu snapshot-only oder none führt nicht dazu, dass aktive Dateisystemblöcke, die bereits in die Cloud-Ebene verschoben wurden, wieder in die Performance-Ebene zurückverschoben werden.

    Für die Rückführung der Daten in die Performance-Tier sind Volume-Lesevorgänge erforderlich.

  • Jedes Mal, wenn die Tiering-Richtlinie für ein Volume geändert wird, wird die minimale Abkühlperiode des Tierings auf den Standardwert der Richtlinie zurückgesetzt.

Was geschieht mit der Tiering-Richtlinie, wenn ein Volume verschoben wird?

  • Sofern nicht explizit eine andere Tiering-Richtlinie festgelegt wird, behält ein Volume seine ursprüngliche Tiering-Richtlinie bei, wenn es in ein FabricPool fähiges Aggregat verschoben wird oder dieses verlässt.

    Die Tiering-Richtlinie greift jedoch nur, wenn das Volume sich in einem FabricPool fähigen Aggregat befindet.

  • Der bestehende Wert des -tiering-minimum-cooling-days Parameters für ein Volume wird mit dem Volume übertragen, sofern keine andere Tiering-Richtlinie für das Ziel angegeben wird.

    Wenn Sie eine andere Tiering-Richtlinie festlegen, verwendet das Volume die standardmäßige minimale Abkühlperiode für diese Richtlinie. Dies ist der Fall, unabhängig davon, ob das Ziel FabricPool ist oder nicht.

  • Ein Volume kann zwischen Aggregaten verschoben und gleichzeitig die Tiering-Richtlinie geändert werden.

  • Besondere Aufmerksamkeit ist erforderlich, wenn ein `volume move`Vorgang die `auto`Tiering-Policy betrifft.

    Unter der Annahme, dass sowohl die Quelle als auch das Ziel FabricPool-fähige Aggregate sind, fasst die folgende Tabelle das Ergebnis einer volume move`Operation zusammen, die Richtlinienänderungen im Zusammenhang mit `auto zusammenfasst:

    Wenn ein Volume mit einer Tiering-Richtlinie von …​ verschoben wird

    Und die Tiering-Richtlinie wird mit dem Wechsel zu …​ geändert

    Dann nach der Volume-Verschiebung…​

    all

    auto

    Alle Daten werden in die Performance-Tier verschoben.

    snapshot-only, none, oder auto

    auto

    Die Datenblöcke werden auf dieselbe Ebene des Zielsystems verschoben, auf der sie sich zuvor auf dem Quellsystem befanden.

    auto oder all

    snapshot-only

    Alle Daten werden in die Performance-Tier verschoben.

    auto

    all

    Alle Benutzerdaten werden in die Cloud-Tier verschoben.

    snapshot-only,auto oder all

    none

    Alle Daten verbleiben auf der Leistungsebene.

Was geschieht mit der Tiering-Richtlinie, wenn ein Volume geklont wird

  • Ab ONTAP 9.8 erbt ein geklontes Volume immer sowohl die Tiering-Richtlinie als auch die Cloud-Abrufrichtlinie vom übergeordneten Volume.

    In Versionen vor ONTAP 9.8 übernimmt ein Klon die Tiering-Richtlinie vom übergeordneten Volume, außer wenn das übergeordnete Volume die all Tiering-Richtlinie hat.

  • Wenn das übergeordnete Volume die never Cloud Retrieval Policy hat, muss sein Klon-Volume entweder die never Cloud Retrieval Policy oder die all Tiering Policy sowie eine entsprechende Cloud Retrieval Policy default haben.

  • Die Cloud-Abrufrichtlinie des übergeordneten Volumes kann nicht in never geändert werden, es sei denn, alle seine Klon-Volumes haben eine Cloud-Abrufrichtlinie never.

Beim Klonen von Volumes sind die folgenden bewährten Vorgehensweisen zu beachten:

  • Die -tiering-policy Option und tiering-minimum-cooling-days Option des Klons steuern ausschließlich das Tiering-Verhalten von Blöcken, die nur in diesem Klon vorkommen. Daher wird empfohlen, für das übergeordnete FlexVol Tiering-Einstellungen zu verwenden, die entweder die gleiche Datenmenge verschieben oder weniger Daten verschieben als einer der Klone.

  • Die Cloud-Abrufrichtlinie des übergeordneten FlexVol sollte entweder die gleiche Datenmenge oder mehr Daten übertragen als die Abrufrichtlinie eines der Klone.

Wie Cloud-Abrufrichtlinien mit Tiering-Richtlinien funktionieren

FabricPool Cloud-Datenabruf wird durch Abrufrichtlinien gesteuert, die festlegen, wann Daten in die lokale Ebene zurückgeschrieben werden. Lesemuster können entweder sequenziell oder zufällig sein.

Die folgende Tabelle listet die Volume-Tiering-Richtlinien und das Standardabrufverhalten für jede Richtlinie auf.

Tiering-Richtlinie

Standardmäßiges Abrufverhalten

keine

Sequenzielle und zufällige Lesevorgänge

nur Snapshot

Sequenzielle und zufällige Lesevorgänge

Auto

Zufällige Lesevorgänge

alle

Kein Datenabruf

Ab ONTAP 9.8 überschreibt die Option zur Steuerung der Cloud-Migration cloud-retrieval-policy das standardmäßige Cloud-Migrations- oder Abrufverhalten, das durch die Tiering-Richtlinie gesteuert wird.

Die folgende Tabelle listet die unterstützten Cloud-Abrufrichtlinien und deren Abrufverhalten auf.

Cloud-Abrufrichtlinie

Abrufverhalten

Standard

Beim Lesen von kalten Blöcken in einem Volume wird das Standardverhalten der Volume-Tiering-Richtlinie des Volumes verwendet. Diese Richtlinie ist der Standardwert für jedes Volume, unabhängig vom Typ des gehosteten Aggregats.

on-read

Wenn kalte Blöcke in einem Volume mit einer Cloud-Abrufrichtlinie, die auf “On-Read” gesetzt ist, zufällig oder sequenziell gelesen werden, werden sie zu heißen Blöcken und in die lokale Ebene geschrieben.

Anwendungen, die sequenzielle Lesevorgänge nutzen, lösen Rückschreibvorgänge auf die lokale Ebene aus, indem die Abrufrichtlinie für das Volume aus der Cloud auf „On-Read“ gesetzt wird. Dies kann für Anwendungen von Vorteil sein, die lokale Ebenenleistung für zuvor kalte Daten benötigen, die nun von aktiven Workloads gelesen werden.

niemals

Wenn kalte Blöcke in einem Volume mit einer Cloud-Abrufrichtlinie, die auf „Nie“ gesetzt ist, gelesen werden, bleiben sie kalt und verbleiben auf der Cloud-Ebene. Sie werden nicht zurück auf die lokale Ebene geschrieben.

Die Einstellung der Cloud-Abrufrichtlinie auf „Never“ ist ähnlich wie die All Tiering-Richtlinie, da Daten nicht auf die lokale Ebene zurückkehren dürfen, unterscheidet sich jedoch von der All Tiering-Richtlinie dadurch, dass weiterhin die Einstellung „tiering-minimum-cooling-days“ des Volumes verwendet wird, anstatt die Daten so schnell wie möglich zu verschieben.

Beispielsweise würde ein Volume, das die Standardeinstellung der Auto Tiering-Richtlinie verwendet, Daten erst nach 31 Tagen Inaktivität als kalt markieren. Nach 31 Tagen würden die inaktiven Daten in den Objektspeicher verschoben und kämen beim Lesen nicht zurück, da die Cloud Retrieval Policy des Volumes auf "Never" gesetzt wurde.

promoten

  • Für die Tiering-Richtlinie “none,” werden alle gestuften Daten zurück auf die lokale Tier geschrieben.

  • Für die Tiering-Richtlinie „snapshot-only“ werden gestaffelte, nicht-Snapshot-Daten zurück in die lokale Ebene geschrieben.
Beispiel für die Änderung der Cloud Retrieval-Richtlinie

Das folgende Beispiel ändert die Tiering-Richtlinie des Volumes auf none und die Abrufrichtlinie auf promote:

set -privilege advanced

volume modify -vserver vs1 -volume myvol -tiering-policy none -cloud-retrieval-policy promote