FabricPool Volume-Tiering-Richtlinien
Ä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.
|
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.
Sie können den volume object-store tiering show Tiering-Status eines FabricPool Volumes mit dem Befehl anzeigen. Erfahren Sie mehr über volume object-store tiering show in der "ONTAP-Befehlsreferenz".
Die FabricPool Tiering-Richtlinie wird auf Volume-Ebene festgelegt. Vier Optionen stehen zur Verfügung:
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 beim Tiering 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.
Sie können die Standardeinstellung für den minimalen Kühlzeitraum des Tiering mit dem -tiering-minimum-cooling-days Parameter auf der erweiterten Berechtigungsebene der volume create volume modify Befehle und ändern. 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 auf die lokale Ebene 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 minimale Abkühlzeit für das Tiering gilt nicht, da die Daten sofort nach der Tiering-Überprüfung in die Cloud-Tier verschoben werden und Sie die Einstellung nicht ändern können.
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.
|
|
Die 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.
Durch Festlegen der Tiering-Richtlinie none wird ein neues Tiering verhindert. Volume-Daten, die zuvor in die Cloud-Tier verschoben wurden, bleiben in der Cloud-Tier, bis sie häufig verwendet werden und automatisch zurück auf die lokale Tier verschoben werden.
Der minimale Kühlzeitraum für das Tiering entfällt, da die Daten niemals in das Cloud-Tier verschoben werden und Sie die Einstellung nicht ändern können.
Wenn selten genutzte Blöcke auf einem Volume mit einer Tiering-Richtlinie zum none Lesen „heiß“ werden, werden sie „heiß“ und auf die lokale Tier geschrieben.
Die volume show Ausgabe des Befehls 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.
|
|
In einer SVM-DR-Beziehung müssen Quell- und Ziel-Volumes keine FabricPool-Aggregate verwenden, sondern sie müssen dieselbe Tiering-Richtlinie verwenden. |
Was geschieht, wenn eine Volume-Tiering-Richtlinie geändert wird?
Sie können die Tiering-Richtlinie eines Volumes durch einen volume modify Vorgang ändern. Sie müssen wissen, wie sich die Änderung der Tiering-Richtlinie auf den Zeitraum auswirkt, den Daten für „kalte“ Daten und zur Cloud-Tier verschoben werden müssen.
-
Wenn die Tiering-Richtlinie von
snapshot-onlybzw.noneauf geändertautowird, sendet ONTAP Benutzerdaten in einem aktiven Filesystem, die bereits selten in die Cloud-Tier kommen, selbst wenn diese Benutzerdatenblöcke zuvor für die Cloud-Tier nicht zur Verfügung standen. -
Wenn die Tiering-Richtlinie in eine andere Richtlinie geändert
allwird, verschiebt ONTAP so schnell wie möglich alle Anwenderblöcke im aktiven Filesystem und in den Snapshots in die Cloud. Vor ONTAP 9.8 mussten Blöcke warten, bis der nächste Tiering-Scan ausgeführt wurde.Das Verschieben von Blöcken in die Performance-Tier ist nicht zulässig.
-
Durch ein Ändern der Tiering-Richtlinie von
autoinsnapshot-onlybzw.noneohne werden aktive Filesystem-Blöcke, die bereits in die Cloud-Tier verschoben werden, wieder auf die Performance-Tier verschoben.Volume-Lesezugriffe sind erforderlich, damit die Daten zurück auf die Performance-Tier verschoben werden.
-
Jedes Mal, wenn Sie die Tiering-Richtlinie für ein Volume ändern, wird die minimale Kühldauer des Tiers auf den Standardwert für die Richtlinie zurückgesetzt.
Was passiert mit der Tiering-Richtlinie, wenn Sie ein Volume verschieben
-
Sofern Sie keine andere Tiering-Richtlinie explizit angeben, behält ein Volume seine ursprüngliche Tiering-Richtlinie bei, wenn es in ein FabricPool-fähiges Aggregat verschoben oder aus diesem entfernt wird.
Die Tiering-Richtlinie wirkt sich jedoch nur dann aus, wenn das Volume in einem FabricPool-fähigen Aggregat besteht.
-
Der vorhandene Wert des
-tiering-minimum-cooling-daysParameters für ein Volume wird mit dem Volume verschoben, sofern Sie für das Ziel keine andere Tiering-Richtlinie angeben.Wenn Sie eine andere Tiering-Richtlinie angeben, verwendet das Volume den standardmäßigen minimalen Kühlzeitraum für das Tiering für diese Richtlinie. Das ist der Fall, ob das Ziel FabricPool ist oder nicht.
-
Sie können ein Volume zwischen Aggregaten verschieben und gleichzeitig die Tiering-Richtlinie ändern.
-
Bei einer
volume moveOperation mit derautoTiering Policy sollten Sie besondere Aufmerksamkeit schenken.Unter der Annahme, dass sowohl die Quelle als auch das Ziel FabricPool-fähige Aggregate sind, fasst die folgende Tabelle das Ergebnis einer
volume moveOperation zusammen, die Richtlinienänderungen in Bezug auf umfasstauto:Wenn Sie ein Volume mit einer Tiering-Richtlinie von verschieben…
Und Sie ändern die Tiering-Richtlinie mit dem Verschieben auf…
Dann nach der Volume-Verschiebung…
allautoAlle Daten werden in die Performance-Tier verschoben.
snapshot-only,noneOderautoautoDatenblöcke werden in dieselbe Tier des Ziels verschoben, wie sie sich zuvor an der Quelle befanden.
autoOderallsnapshot-onlyAlle Daten werden in die Performance-Tier verschoben.
autoallAlle Benutzerdaten werden auf das Cloud-Tier verschoben.
snapshot-only,autoOderallnoneAlle Daten werden auf der Performance-Tier aufbewahrt.
Was geschieht mit der Tiering-Richtlinie beim Klonen eines Volumes
-
Ab ONTAP 9.8 übernimmt ein Klon-Volume immer sowohl die Tiering-Richtlinie als auch die Cloud-Abrufrichtlinie des übergeordneten Volume.
In älteren Versionen als ONTAP 9.8 übernimmt ein Klon die Tiering-Richtlinie vom übergeordneten Volume, außer wenn das übergeordnete Objekt über die
allTiering-Richtlinie verfügt. -
Verfügt das übergeordnete Volume über die
neverCloud-Abrufrichtlinie, muss sein Klonnever-Volume entweder über die Cloud-Abrufrichtlinie oder dieallTiering-Richtlinie und eine entsprechende Cloud-Abrufrichtlinie verfügendefault. -
Die Abrufrichtlinie des übergeordneten Volumes kann nicht auf geändert werden
never, es sei denn, alle zugehörigen Klon-Volumes verfügen über eine Cloud-Abrufrichtlinienever.
Beachten Sie beim Klonen von Volumes die folgenden Best Practices:
-
Die
-tiering-policytiering-minimum-cooling-daysOption und die Option des Klons steuern nur das Tiering-Verhalten von Blöcken, die nur beim Klon vorhanden sind. Daher empfehlen wir die Verwendung von Tiering-Einstellungen bei den übergeordneten FlexVol, bei denen entweder die gleiche Datenmenge verschoben oder weniger Daten verschoben werden als bei den Klonen -
Die Richtlinie zum Abrufen der Cloud auf der übergeordneten FlexVol sollte entweder die gleiche Datenmenge verschieben oder mehr Daten verschieben als die Abrufrichtlinie eines der Klone
Funktionsweise von Tiering-Richtlinien bei der Cloud-Migration
Der FabricPool Cloud-Datenabruf wird durch Tiering-Richtlinien gesteuert, die den Datenabruf vom Cloud-Tier zu Performance-Tier basierend auf dem Lesemuster bestimmen. Lesemuster können sequenziell oder zufällig sein.
In der folgenden Tabelle sind die Tiering-Richtlinien und die Regeln für den Abruf von Cloud-Daten für jede Richtlinie aufgeführt.
Tiering-Richtlinie |
Verhalten beim Abrufen |
Keine |
Sequenzielle und zufällige Lesevorgänge |
Nur snapshot |
Sequenzielle und zufällige Lesevorgänge |
automatisch |
Wahlfreier Lesezugriff |
Alle |
Kein Datenabruf |
Ab ONTAP 9.8 cloud-retrieval-policy überschreibt die Kontrolloption für die Cloud-Migration das von der Tiering-Richtlinie gesteuerte Standard-Cloud-Migrations- oder -Abrufverhalten.
In der folgenden Tabelle sind die unterstützten Richtlinien zum Abrufen in der Cloud und deren Abrufverhalten aufgeführt.
Cloud-Abrufrichtlinie |
Verhalten beim Abrufen |
Standard |
Die Tiering-Richtlinie entscheidet, welche Daten zurückverschoben werden sollen. Damit bleibt beim Abrufen von Cloud-Daten mit „ |
On-Read |
Alle clientfokussierten Daten werden vom Cloud-Tier auf die Performance-Tier übertragen. |
Nie |
Es werden keine Client-getriebenen Daten von der Cloud-Tier zur Performance-Tier übertragen |
Werben |
|
Erfahren Sie mehr über die in diesem Verfahren beschriebenen Befehle im "ONTAP-Befehlsreferenz".