Skip to main content
Alle Cloud-Provider
  • Amazon Web Services
  • Google Cloud
  • Microsoft Azure
  • Alle Cloud-Provider
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Data Tiering - Übersicht

Beitragende

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.

Dieses Konzept zeigt heiße Daten, die auf EBS Storage laufen, und inaktive Daten, die auf S3 Storage laufen.

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 also vor einem Wechsel der Storage-Klasse. "Erfahren Sie mehr über Amazon S3 Storage Classes".

Sie können eine Speicherklasse auswählen, wenn Sie die Arbeitsumgebung erstellen, und Sie können sie jederzeit danach ändern. 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 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 Ihre Speicherkosten senken, indem Sie auf die Storage-Tier cool wechseln. Wenn Sie den Speicher-Tier zu kühlen ändern, werden inaktive Kapazitäts-Tier-Daten direkt in den kühlen Speicher-Tier verschoben.

Die Zugriffskosten sind höher, wenn Sie auf die Daten zugreifen. Berücksichtigen Sie diese also vor einem Wechsel des Storage-Tiers. "Weitere Informationen zu Azure Blob Storage-Zugriffsklassen".

Sie können eine Speicherebene auswählen, wenn Sie die Arbeitsumgebung erstellen, und sie kann jederzeit danach geändert werden. 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.

Hinweis 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. "Erfahren Sie mehr über Storage-Klassen für Google Cloud Storage".

Sie können eine Speicherebene auswählen, wenn Sie die Arbeitsumgebung erstellen, und sie kann jederzeit danach geändert werden. 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.

Tipp 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.

Tipp 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".