Data Tiering - Übersicht
Änderungen vorschlagen
PDFs
Senken Sie Ihre Storage-Kosten, indem Sie das automatisierte Tiering inaktiver Daten auf kostengünstigen Objekt-Storage ermöglichen. Aktive Daten bleiben auf hochperformanten SSDs oder HDDs, während inaktive Daten in kostengünstigen Objekt-Storage verschoben werden. Dadurch können Sie Speicherplatz auf Ihrem primären Storage zurückgewinnen und den sekundären Storage verkleinern.
Data Tiering wird durch FabricPool Technologie unterstützt. Cloud Volumes ONTAP bietet Daten-Tiering für alle Cloud Volumes ONTAP Cluster ohne zusätzliche Lizenz. Bei Aktivierung von Daten-Tiering fallen Gebühren für das Tiering von Daten in Objekt-Storage an. Weitere Informationen zu den Kosten für Objekt-Storage finden Sie in der Dokumentation Ihres Cloud-Providers.
Daten-Tiering in AWS
Wenn Sie Daten-Tiering in AWS aktivieren, verwendet Cloud Volumes ONTAP EBS als Performance-Tier für häufig benötigte Daten und AWS S3 als Kapazitäts-Tier für inaktive Daten.
- Performance-Tier
-
Beim Performance-Tier können es sich um allgemeine SSDs (gp3 oder gp2) oder bereitgestellte IOPS-SSDs (io1) handelt.
Bei der Verwendung von durchsatzoptimierten HDDs (st1) wird kein Tiering von Daten zu Objekt-Storage empfohlen.
- Kapazitäts-Tier
-
Ein Cloud Volumes ONTAP System verschiebt inaktive Daten auf einen einzelnen S3-Bucket.
BlueXP erstellt für jede Arbeitsumgebung einen einzelnen S3 Bucket und benennt ihn als Fabric-Pool-Cluster eindeutige Kennung. Für jedes Volume wird kein anderer S3-Bucket erstellt.
Wenn BlueXP den S3-Bucket erstellt, werden die folgenden Standardeinstellungen verwendet:
-
Storage-Klasse: Standard
-
Standardverschlüsselung deaktiviert
-
Öffentlichen Zugang blockieren: Alle öffentlichen Zugänge blockieren
-
Objekteigentümer: ACLs aktiviert
-
Bucket-Versionierung: Deaktiviert
-
Objektsperre: Deaktiviert
-
- Speicherklassen
-
Die Standard-Storage-Klasse für Tiered Daten in AWS ist Standard. Standard ist ideal für häufig aufgerufene Daten, die über mehrere Verfügbarkeitszonen gespeichert werden.
Wenn Sie keinen Zugriff auf inaktive Daten planen, können Sie die Storage-Kosten senken, indem Sie die Storage-Klasse auf eine der folgenden Komponenten ändern: Intelligent Tiering, One-Zone infrequent Access, Standard-infrequent Access oder S3 Glacier Instant Retrieval. Wenn Sie die Speicherklasse ändern, beginnen inaktive Daten in der Klasse Standard-Speicher und wechseln zu der von Ihnen ausgewählten Speicherklasse, wenn nach 30 Tagen kein Zugriff auf die Daten erfolgt.
Die Zugriffskosten sind höher, wenn Sie auf die Daten zugreifen. Berücksichtigen Sie dies vor einer Änderung der Storage-Klasse. "Amazon S3 Dokumentation: Weitere Informationen zu Amazon S3 Storage-Klassen".
Sie können eine Storage-Klasse auswählen, wenn Sie die Arbeitsumgebung erstellen und sie danach jederzeit ändern. Anweisungen zum Ändern der Speicherklasse finden Sie unter "Tiering inaktiver Daten in kostengünstigen Objektspeicher".
Die Storage-Klasse für Daten-Tiering beträgt die systemweite; nicht pro Volume.
Daten-Tiering in Azure
Wenn Sie Daten-Tiering in Azure aktivieren, verwendet Cloud Volumes ONTAP von Azure gemanagte Festplatten als Performance-Tier für häufig abgerufene Daten und Azure Blob Storage als Kapazitäts-Tier für inaktive Daten.
- Performance-Tier
-
Der Performance-Tier kann entweder aus SSDs oder HDDs bestehen.
- Kapazitäts-Tier
-
Ein Cloud Volumes ONTAP System schichtet inaktive Daten auf einen einzelnen Blob-Container ab.
BlueXP erstellt für jede Cloud Volumes ONTAP-Arbeitsumgebung ein neues Storage-Konto mit einem Container. Der Name des Speicherkontos ist zufällig. Für jedes Volume wird kein anderer Container erstellt.
BlueXP erstellt das Speicherkonto mit den folgenden Einstellungen:
-
Zugriffsebene: Heiß
-
Leistung: Standard
-
Redundanz: Lokal redundanter Storage (LRS)
-
Konto: StorageV2 (allgemeine Zwecke v2)
-
Sichere Übertragung für REST-API-Vorgänge nötig: Aktiviert
-
Zugriff auf Schlüssel des Storage-Kontos: Aktiviert
-
Minimale TLS-Version: Version 1.2
-
Infrastrukturverschlüsselung deaktiviert
-
- Storage-Zugriffstufen
-
Die Standard-Storage-Zugriffs-Tier für Tiered Daten in Azure ist die Hot-Tier. Die Tier mit häufig benötigten Daten ist ideal für Daten in der Kapazitäts-Tier.
Wenn Sie nicht planen, auf die inaktiven Daten in der Kapazitäts-Tier zuzugreifen, können Sie die Speicherebene cool wählen, bei der die inaktiven Daten mindestens 30 Tage aufbewahrt werden. Sie können sich auch für die Cold-Ebene entscheiden, bei der die inaktiven Daten mindestens 90 Tage lang gespeichert werden. Wählen Sie je nach Ihren Storage-Anforderungen und Kostenüberlegungen die Tier aus, die Ihren Anforderungen am besten entspricht. Wenn Sie die Speicherebene in cool oder cold ändern, werden die inaktiven Daten der Kapazitäts-Tiers direkt in die Cold-Storage-Tier verschoben. Die Cold-Tiers bieten im Vergleich zum Tier mit heißen Daten niedrigere Storage-Kosten. Allerdings haben sie höhere Zugriffskosten, berücksichtigen Sie dies also vor einem Wechsel des Storage-Tiers. Siehe "Dokumentation zu Microsoft Azure: Weitere Informationen zu Azure Blob Storage-Zugriffs-Tiers".
Sie können beim Erstellen der Arbeitsumgebung eine Storage-Ebene auswählen und sie anschließend jederzeit ändern. Weitere Informationen zum Ändern der Speicherebene finden Sie unter "Tiering inaktiver Daten in kostengünstigen Objektspeicher".
Die Storage-Zugriffs-Tier für Daten-Tiering beträgt die systemweite; nicht pro Volume.
Daten-Tiering in Google Cloud
Wenn Sie Daten-Tiering in Google Cloud aktivieren, verwendet Cloud Volumes ONTAP persistente Festplatten als Performance-Tier für häufig abgerufene Daten sowie Google Cloud Storage-Buckets als Kapazitäts-Tier für inaktive Daten.
- Performance-Tier
-
Beim Performance-Tier können es sich entweder um persistente SSD-Festplatten, ausgewogene persistente Festplatten oder um Standard-persistente Festplatten handeln.
- Kapazitäts-Tier
-
Ein Cloud Volumes ONTAP System verschiebt inaktive Daten auf einen einzelnen Google Cloud Storage Bucket.
BlueXP erstellt für jede Arbeitsumgebung einen Bucket und nennt ihn Fabric-Pool-Cluster-eindeutige Kennung. Für jedes Volume wird kein anderer Bucket erstellt.
Wenn BlueXP den Bucket erstellt, verwendet er die folgenden Standardeinstellungen:
-
Positionstyp: Region
-
Storage-Klasse: Standard
-
Öffentlicher Zugriff: Unterliegt Objekt-ACLs
-
Zugriffssteuerung: Feingranular
-
Schutz: Keine
-
Datenverschlüsselung: Von Google verwalteter Schlüssel
-
- Speicherklassen
-
Die Standard-Storage-Klasse für Tiered Daten ist die Klasse Standard Storage. Wenn nur selten auf die Daten zugegriffen wird, können Sie Ihre Storage-Kosten senken, indem Sie zu Nearline Storage oder Coldline Storage wechseln. Wenn Sie die Storage-Klasse ändern, werden nachfolgende inaktive Daten direkt in die von Ihnen ausgewählte Klasse verschoben.
Alle vorhandenen inaktiven Daten behalten die Standardspeicherklasse bei, wenn Sie die Speicherklasse ändern. Um die Speicherklasse für vorhandene inaktive Daten zu ändern, müssen Sie die Bezeichnung manuell vornehmen. Die Zugriffskosten sind höher, wenn Sie auf die Daten zugreifen. Berücksichtigen Sie dies also vor einem Wechsel der Storage-Klasse. Weitere Informationen finden Sie unter "Google Cloud-Dokumentation: Storage-Klassen".
Sie können beim Erstellen der Arbeitsumgebung eine Storage-Ebene auswählen und sie anschließend jederzeit ändern. Weitere Informationen zum Ändern der Speicherklasse finden Sie unter "Tiering inaktiver Daten in kostengünstigen Objektspeicher".
Die Storage-Klasse für Daten-Tiering beträgt die systemweite; nicht pro Volume.
Daten-Tiering und Kapazitätsgrenzen
Wenn Sie Daten-Tiering aktivieren, bleibt die Kapazitätsgrenze eines Systems unverändert. Das Limit wird über die Performance- und die Kapazitäts-Tier verteilt.
Richtlinien für das Volume-Tiering
Um das Daten-Tiering zu aktivieren, müssen Sie beim Erstellen, Ändern oder Replizieren eines Volumes eine Volume-Tiering-Policy auswählen. Sie können für jedes Volume eine andere Richtlinie auswählen.
Einige Tiering Policies haben einen zugehörigen Mindestkühlzeitraum, der festlegt, wie lange Benutzerdaten in einem Volume inaktiv bleiben müssen, damit die Daten als "kalt" betrachtet und auf die Kapazitätsebene verschoben werden können. Die Kühldauer beginnt, wenn Daten in das Aggregat geschrieben werden.
|
Sie können den minimalen Kühlzeitraum und den standardmäßigen Aggregatschwellenwert von 50 % ändern (dazu unten). "Erfahren Sie, wie Sie die Kühlzeit ändern" Und "Erfahren Sie, wie Sie den Schwellenwert ändern". |
Mit BlueXP können Sie bei der Erstellung oder Änderung eines Volumes aus den folgenden Volume Tiering-Richtlinien auswählen:
- Nur Snapshot
-
Nachdem ein Aggregat die Kapazität von 50 % erreicht hat, stuft Cloud Volumes ONTAP kalte Benutzerdaten von Snapshot Kopien ein, die nicht mit dem aktiven Filesystem der Kapazitäts-Tier verbunden sind. Die Abkühlzeit beträgt ca. 2 Tage.
Beim Lesen werden kalte Datenblöcke auf dem Kapazitäts-Tier heiß und werden auf den Performance-Tier verschoben.
- Alle
-
Alle Daten (ohne Metadaten) werden sofort als „kalt“ markiert und in den Objektspeicher verschoben, sobald wie möglich. Es ist nicht mehr nötig, 48 Stunden auf neue Blöcke in einem Volume zu warten, die kalt werden. Beachten Sie, dass für Blöcke, die sich vor der Festlegung der All-Richtlinie im Volume befinden, 48 Stunden zum Kaltstart benötigt werden.
Beim Lesen bleiben kalte Datenblöcke auf der Cloud-Tier kalt und werden nicht zurück in die Performance-Tier geschrieben. Diese Richtlinie ist ab ONTAP 9.6 verfügbar.
- Automatisch
-
Nachdem ein Aggregat die Kapazität von 50 % erreicht hat, stuft Cloud Volumes ONTAP kalte Datenblöcke in einem Volume auf einen Kapazitäts-Tier. Die kalten Daten umfassen nicht nur Snapshot Kopien, sondern auch kalte Benutzerdaten aus dem aktiven Dateisystem. Die Abkühlzeit beträgt ca. 31 Tage.
Diese Richtlinie wird ab Cloud Volumes ONTAP 9.4 unterstützt.
Wenn die Daten nach dem Zufallsprinzip gelesen werden, werden die kalten Datenblöcke in der Kapazitätsebene heiß und werden auf die Performance-Ebene verschoben. Beim Lesen von sequenziellen Lesevorgängen, z. B. in Verbindung mit Index- und Antivirenscans, bleiben die kalten Datenblöcke kalt und wechseln nicht zur Performance-Ebene.
- Keine
-
Die Daten eines Volumes werden in der Performance-Ebene gespeichert, sodass es nicht in die Kapazitäts-Ebene verschoben werden kann.
Bei der Replizierung eines Volume können Sie entscheiden, ob die Daten in einen Objekt-Storage verschoben werden sollen. In diesem Fall wendet BlueXP die Backup-Richtlinie auf das Datenschutzvolumen an. Ab Cloud Volumes ONTAP 9.6 ersetzt die All Tiering Policy die Backup Policy.
Die Abschaltung von Cloud Volumes ONTAP beeinträchtigt die Kühlungszeit
Datenblöcke werden durch Kühlprüfungen gekühlt. Während dieses Prozesses werden Blöcke, die nicht verwendet wurden, die Blocktemperatur verschoben (gekühlt) auf den nächsten niedrigeren Wert. Die standardmäßige Kühlzeit hängt von der Volume Tiering-Richtlinie ab:
-
Auto: 31 Tage
-
Nur Snapshot: 2 Tage
Damit der Kühlscan funktioniert, muss Cloud Volumes ONTAP ausgeführt werden. Wenn die Cloud Volumes ONTAP ausgeschaltet ist, stoppt der Kühlbedarf ebenfalls. Auf diese Weise können Sie längere Kühlzeiten haben.
|
|
Wenn Cloud Volumes ONTAP deaktiviert wird, bleibt die Temperatur jedes Blocks bis zum Neustart des Systems erhalten. Wenn die Temperatur eines Blocks z. B. bei ausgeschaltetem System 5 beträgt, beträgt die Temperatur nach dem Einschalten des Systems immer noch 5. |
Einrichten von Data Tiering
Anweisungen und eine Liste der unterstützten Konfigurationen finden Sie unter "Tiering inaktiver Daten in kostengünstigen Objektspeicher".