Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 5

10 Cache Tiering

Eine Cache-Schicht ist eine zusätzliche Speicherebene, die zwischen dem Client und dem Standardspeicher implementiert wird. Er wurde entwickelt, um den Zugriff auf Pools zu beschleunigen, die sich auf langsamen Festplatten oder in Erasure Coded Pools befinden.

Normalerweise wird beim Cache Tiering (Aufteilung des Cache in mehrere Schichten) ein Pool von relativ schnellen bzw. teuren Speichergeräten (wie zum Beispiel SSD-Laufwerken) erstellt, der als Cache-Schicht fungiert, sowie ein Hintergrund-Pool aus langsameren und günstigeren Geräten, die als Speicherschicht konfiguriert sind.

10.1 Terminologie zur Speicherung in Schichten

Cache Tiering erkennt zwei Arten von Pools: einen Cache Pool und einen Speicher-Pool.

Tipp
Tipp

Allgemeine Informationen zu Pools finden Sie in Kapitel 7, Verwalten von Speicher-Pools.

Speicher-Pool

Entweder ein standardmäßiger reproduzierter Pool, in dem mehrere Kopien eines Objekts im Ceph Storage Cluster gespeichert sind, oder ein Erasure Coded Pool (weitere Informationen hierzu finden Sie in Kapitel 9, Erasure Coded Pools).

Der Speicher-Pool wird manchmal als "Backing" (Hintergrundspeicher) oder als "Cold Storage" bezeichnet.

Cache Pool

Ein standardmäßiger reproduzierter Pool, der auf einem relativ kleinen, doch schnellen Speichergerät gespeichert ist und über einen eigenen Regelsatz in einer CRUSH Map verfügt.

Der Cache Pool wird auch als "Hot Storage" bezeichnet.

10.2 Zu berücksichtigende Aspekte

Durch ein Cache Tiering wird die Cluster-Leistung bei bestimmten Workloads möglicherweise beeinträchtigt. Nachfolgend sehen Sie einige Aspekte, die Sie berücksichtigen sollten:

  • Workload-abhängig: Ob ein Cache die Leistung verbessert, hängt von seinem Workload ab. Da das Verschieben von Objekten in einen Cache oder aus einem Cache heraus mit Aufwand verbunden ist, kann es effizienter sein, wenn die meisten Anforderungen sich nur auf eine kleine Anzahl von Objekten beziehen. Der Cache Pool sollte groß genug sein, um den Arbeitssatz für Ihren Workload zu erfassen und Überlastung zu vermeiden.

  • Schwer zu vergleichen: Die meisten Leistungsvergleiche zeigen bei Cache Tiering eine ungenügende Leistung. Der Grund dafür besteht darin, dass sie eine große Anzahl von Objekten anfordern und es lange dauert bis der Cache "aufgewärmt" ist.

  • Möglicherweise schlechte Leistung: Bei Workloads, die nicht für ein Cache Tiering geeignet sind, ist die Leistung oft schlechter als bei einem normalen reproduzierten Pool ohne aktiviertem Cache Tiering.

  • librados-Objektauflistung: Wenn Ihre Anwendung direkt mit librados arbeitet und auf Objektauflistung basiert, funktioniert ein Cache Tiering möglicherweise nicht wie erwartet. (Dies ist kein Problem bei Object Gateway, RBD oder CephFS.)

10.3 Wofür ein Cache Tiering geeignet ist

Ein Cache Tiering kann in folgenden Fällen nützlich sein:

  • Sie müssen über RADOS Block Device (RBD) auf Erasure Coded Pools zugreifen.

  • Sie müssen über ISCSI auf Erasure Coded Pools zugreifen, weil es die Beschränkungen des RBD übernimmt. Weitere Informationen zu iSCSI finden Sie in Kapitel 12, Ceph iSCSI Gateway.

  • Sie verfügen über relativ wenig Speicher mit hoher Leistung und über viel Speicher mit geringer Leistung und müssen schneller auf die gespeicherten Daten zugreifen.

10.4 Cache-Modi

Der Cache Tiering Agent verarbeitet die Migration der Daten zwischen Cache-Schicht und Hintergrundspeicherschicht. Administratoren haben die Möglichkeit, den Ablauf dieser Migration zu konfigurieren. Dafür gibt es zwei Szenarien:

Zurückschreiben-Modus (Write-Back)

Im Zurückschreiben-Modus schreiben Ceph Clients Daten an die Cache-Schicht und erhalten von der Cache-Schicht eine Bestätigung zurück. Zu gegebener Zeit werden die an die Cache-Schicht geschriebenen Daten zur Speicherschicht migriert und dann aus der Cache-Schicht entfernt. Dem Konzept nach ist die Cache-Schicht "vor" der Hintergrundspeicherschicht angesiedelt. Wenn ein Ceph Client Daten benötigt, die sich in der Speicherschicht befinden, dann migriert der Cache Tiering Agent die Daten zur Cache-Schicht beim Lesen. Anschließend werden die Daten zum Ceph Client gesendet. Danach kann der Ceph Client über die Cache-Schicht so lange E/A-Operationen durchführen bis die Daten inaktiv werden. Dies ist ideal für änderbare Daten wie bei Foto- oder Videobearbeitung, oder auch für Transaktionsdaten.

Nur-Lesen-Modus

Im Nur-Lesen-Modus schreiben Ceph Clients Daten direkt an die Hintergrundspeicherschicht. Beim Lesen kopiert Ceph die angeforderten Objekte von der Hintergrundspeicherschicht zur Cache-Schicht. Veraltete Daten werden entsprechend der definierten Richtlinie aus der Cache-Schicht entfernt. Diese Vorgehensweise ist ideal bei unveränderbaren Daten wie Präsentationsbilder oder Videos in einem sozialen Netzwerk, DNS-Daten oder Röntgenaufnahmen, weil das Lesen von einem Cache Pool, der eventuell veraltete Daten enthält, inkonsistente Ergebnisse ergibt. Verwenden Sie den Nur-Lesen-Modus nicht für veränderbare Daten.

10.5 Treffersatz (Hit Set)

10.5.1 Überblick

Treffersatz-Parameter ermöglichen eine Optimierung der Cache Pools. Treffersätze in Ceph sind normalerweise Bloomfilter. Sie sind eine speichereffiziente Methode zum Nachverfolgen von Objekten, die sich bereits im Cache Pool befinden.

Der Treffersatz ist ein Bit Array, mit dem das Ergebnis einer Reihe von Hashing-Funktionen gespeichert werden, die auf Objektnamen angewendet wurden. Anfänglich sind alle Bits auf 0 festgelegt. Wenn ein Objekt zum Treffersatz hinzugefügt wird, erhält dessen Name ein Hash und das Ergebnis wird an verschiedenen Positionen im Treffersatz zugeordnet. Dort wird der Wert des Bit dann auf 1 festgelegt.

Dem Namen eines Objekts wird erneut ein Hash hinzugefügt, um herauszufinden, ob dieses Objekt im Cache vorhanden ist. Wenn ein Bit den Wert 0 aufweist, ist das Objekt definitiv nicht im Cache vorhanden und muss vom Cold Storage abgerufen werden.

Es ist möglich, dass die Ergebnisse von verschiedenen Objekten am selben Standort wie der Treffersatz gespeichert sind. Durch Zufall können alle Bits den Wert 1 aufweisen und das Objekt ist trotzdem nicht im Cache vorhanden. Daher können nur Treffersätze mit einem Bloomfilter wirklich angeben, ob ein Objekt definitiv nicht im Cache vorhanden ist und daher vom Cold Storage abgerufen werden muss.

In einem Cache Pool kann sich im Lauf der Zeit mehr als ein Treffersatz befinden, der den Dateizugriff verfolgt. Durch die Einstellung hit_set_count wird definiert, wie viele Treffersätze verwendet werden. Mit hit_set_period wird definiert, wie lange die einzelnen Treffersätze verwendet werden. Nach Ablauf des Zeitraums wird der nächste Treffersatz verwendet. Wenn die Anzahl der Treffersätze verbraucht ist, wird der Arbeitsspeicher des ältesten Treffersatzes freigegeben und ein neuer Treffersatz wird erstellt. Die Werte von hit_set_count und hit_set_period miteinander multipliziert definieren den Zeitrahmen insgesamt, in dem der Zugriff auf Objekte verfolgt wurde.

Bloomfilter mit drei gespeicherten Objekten
Abbildung 10.1: Bloomfilter mit drei gespeicherten Objekten

Verglichen mit der Anzahl der Objekte mit Hash ist ein Treffersatz mit Bloomfilter sehr speichereffizient. Es sind weniger als 10 Bits erforderlich, um die falschpositive Wahrscheinlichkeit auf unter 1 % zu reduzieren. Die falschpositive Wahrscheinlichkeit wird definiert mit hit_set_fpp. Ceph berechnet die Größe des Treffersatzes automatisch basierend auf der Anzahl der Objekte in einer Placement Group und der falschpositiven Wahrscheinlichkeit.

Der erforderliche Speicherplatz im Cache Pool wird beschränkt mit min_write_recency_for_promote und min_read_recency_for_promote. Wird der Wert auf 0 festgelegt, werden alle Objekte in den Cache Pool hochgestuft, sobald sie gelesen oder geschrieben werden. Dies dauert so lange an, bis die Objekte entfernt werden. Werte größer 0 definieren die Anzahl der Treffersätze geordnet nach Alter, die nach dem Objekt durchsucht werden. Wird das Objekt in einem Treffersatz gefunden, so wird es zum Cache Pool hochgestuft.

10.5.2 Beispiele

10.5.2.1 Großer Cache Pool und kleiner Arbeitsspeicher

Wenn viel Speicherplatz, doch nur wenig RAM verfügbar ist, können alle Objekte sofort bei Zugriff in den Cache Pool hochgestuft werden. Der Treffersatz bleibt klein. Nachfolgend sehen Sie eine Reihe von Beispielen für Konfigurationswerte:

hit_set_count = 1
hit_set_period = 3600
hit_set_fpp = 0.05
min_write_recency_for_promote = 0
min_read_recency_for_promote = 0

10.5.2.2 Kleiner Cache Pool und großer Arbeitsspeicher

Bei einem kleinen Speicher und vergleichsweise großem Arbeitsspeicher kann die Cache-Schicht so konfiguriert werden, dass eine begrenzte Anzahl von Objekten in den Cache Pool hochgestuft wird. Zwölf Treffersätze, die jeweils für einen Zeitraum von 14.400 Sekunden verwendet werden, ermöglichen eine Statusüberwachung von insgesamt 48 Stunden. Wenn in den letzten acht Stunden auf ein Objekt zugegriffen wurde, wird es zum Cache Pool hochgestuft. Nachfolgend sehen Sie eine Reihe von Beispielen für Konfigurationswerte:

hit_set_count = 12
hit_set_period = 14400
hit_set_fpp = 0.01
min_write_recency_for_promote = 2
min_read_recency_for_promote = 2

10.6 Einrichten eines Beispiels für einen Speicher mit mehreren Schichten

In diesem Abschnitt wird die Vorgehensweise zur Einrichtung einer schnellen SSD Cache-Schicht (Hot Storage) vor einer Standardfestplatte (Cold Storage) veranschaulicht.

Tipp
Tipp

Das folgende Beispiel dient nur zu Demonstrationszwecken. Es umfasst eine Einrichtung mit einem Root und einer Regel für den SSD-Part in einem einzelnen Ceph Node.

In der Produktionsumgebung umfassen Cluster-Einstellungen normalerweise mehrere Root- und Regeleinträge für Hot Storage sowie gemischte Nodes mit SSDs und SATA-Festplatten.

  1. Bereiten Sie einen Host-Rechner mit schnellen Laufwerken wie SSDs vor. Dieser Cluster Node fungiert als schnelle Cache-Schicht.

  2. Machen Sie den Rechner mit DeepSea zu einem Ceph Node. Installieren Sie die Software und konfigurieren Sie den Host-Rechner wie in Abschnitt 1.1, „Hinzufügen neuer Cluster Nodes“ beschrieben. Nehmen wir dafür den Namen node-4 an. Dieser Node benötigt 4 OSD-Festplatten.

    Dies ergibt einen Eintrag in der Crush Map wie den folgenden:

    [...]
    host node-4 {
       id -5  # do not change unnecessarily
       # weight 0.012
       alg straw
       hash 0  # rjenkins1
       item osd.6 weight 0.003
       item osd.7 weight 0.003
       item osd.8 weight 0.003
       item osd.9 weight 0.003
    }
    [...]
  3. Bearbeiten Sie die CRUSH Map für den Hot Storage Pool, der den OSDs zugeordnet ist und über schnelle SSD-Laufwerke im Hintergrund verfügt. Definieren Sie eine zweite Hierarchie mit einem Root Node für die SSDs (als "root ssd"). Ändern Sie zusätzlich die Gewichtung und eine CRUSH-Regel für die SSDs. Weitere Informationen zur CRUSH Map finden Sie unter http://docs.ceph.com/docs/master/rados/operations/crush-map/.

    Bearbeiten Sie die CRUSH Map direkt mit Kommandozeilen-Werkzeugen wie getcrushmap und crushtool:

    1. Rufen Sie die aktuelle CRUSH Map ab und speichern Sie sie als c.map:

      cephadm > sudo ceph osd getcrushmap -o c.map
    2. Dekompilieren Sie c.map und speichern Sie sie als c.txt:

      cephadm > crushtool -d c.map -o c.txt
    3. Bearbeiten Sie c.txt:

      [...]
      host node-4 {
              id -5  # do not change unnecessarily
              # weight 4.000
              alg straw
              hash 0  # rjenkins1
              item osd.6 weight 1.000
              item osd.7 weight 1.000
              item osd.8 weight 1.000
              item osd.9 weight 1.000
      }
      root ssd {    # newly added root for the SSD hot-storage
              id -6
              alg straw
              hash 0
              item node-4 weight 4.00
      }
      rule ssd {
              ruleset 4
              type replicated
              min_size 0
              max_size 4
              step take ssd
              step chooseleaf firstn 0 type host
              step emit
      }
      [...]
    4. Kompilieren Sie die bearbeitete Datei c.txt und speichern Sie sie als ssd.map:

      cephadm > crushtool -c c.txt -o ssd.map
    5. Installieren Sie schließlich die Datei ssd.map als die neue CRUSH Map:

      cephadm > sudo ceph osd setcrushmap -i ssd.map
  4. Erstellen Sie den Hot Storage Pool für das Cache Tiering. Verwenden Sie dazu die neue "ssd"-Regel:

    cephadm > sudo ceph osd pool create hot-storage 100 100 replicated ssd
  5. Erstellen Sie den Cold Storage Pool mit der standardmäßigen Regel "replicated_ruleset":

    cephadm > sudo ceph osd pool create cold-storage 100 100 replicated replicated_ruleset
  6. Dann wird zur Einrichtung einer Cache-Schicht ein Hintergrundspeicher-Pool mit einem Cache Pool verknüpft, in diesem Fall Cold Storage (= Speicher-Pool) mit Hot Storage (= Cache Pool):

    cephadm > sudo ceph osd tier add cold-storage hot-storage
  7. Führen Sie folgendes Kommando aus, um den Cache-Modus auf "writeback" (Zurückschreiben) festzulegen:

    cephadm > sudo ceph osd tier cache-mode hot-storage writeback

    Weitere Informationen zu den Cache-Modi finden Sie in Abschnitt 10.4, „Cache-Modi“.

    Cache-Schichten im Zurückschreiben-Modus überlagern die Hintergrundspeicherschicht. Daher muss als zusätzlicher Schritt der gesamte Datenverkehr des Clients vom Speicher-Pools zum Cache Pool geleitet werden. Führen Sie als Beispiel folgendes Kommando aus, um den Client-Datenverkehr direkt zum Cache Pool zu leiten:

    cephadm > sudo ceph osd tier set-overlay cold-storage hot-storage

10.6.1 Konfigurieren einer Cache-Schicht

Zum Konfigurieren von Cache-Schichten stehen verschiedene Optionen zur Verfügung. Verwenden Sie folgende Syntax:

cephadm > sudo ceph osd pool set cachepool key value

10.6.1.1 Target-Größe und Typ

In den folgenden Schritten wird beschrieben, wie Sie einen Cache Pool mit den in Abschnitt 10.5.2.2, „Kleiner Cache Pool und großer Arbeitsspeicher“ angegebenen Werten konfigurieren.

Die Cache-Schichten der Ceph-Produktionsumgebung verwenden einen Bloomfilter für hit_set_type:

cephadm > sudo ceph osd pool set cachepool hit_set_type bloom

Mit hit_set_count und hit_set_period wird die Zeit für die einzelnen Treffersätze definiert und wieviele dieser Treffersätze gespeichert werden sollen.

cephadm > sudo ceph osd pool set cachepool hit_set_count 12
cephadm > sudo ceph osd pool set cachepool hit_set_period 14400
cephadm > sudo ceph osd pool set cachepool target_max_bytes 1000000000000
Anmerkung
Anmerkung

Bei einer höheren Anzahl von hit_set_count wird für den ceph-osd-Prozess mehr RAM verbraucht.

Mit min_read_recency_for_promote wird definiert, wie viele Treffersätze beim Verarbeiten einer Lese-Operation nach einem Objekt durchsucht werden. Anhand des Suchergebnisses wird entschieden, ob das Objekt asynchron hochgestuft werden soll. Der Wert des Objekts sollte zwischen 0 und dem hit_set_count liegen. Wird der Wert auf 0 festgelegt, dann wird das Objekt immer hochgestuft. Bei 1 wird der aktuelle Treffersatz durchsucht. Wenn sich das Objekt im aktuellen Treffersatz befindet, wird es hochgestuft. Andernfalls geschieht dies nicht. Bei den anderen Werten wird die genaue Anzahl der Archiv-Treffersätze durchsucht. Das Objekt wird hochgestuft, wenn es in einem der kürzlichen min_read_recency_for_promote-Treffersätze gefunden wird.

Für die Schreib-Operation wird ein ähnlicher Parameter festgelegt, nämlich min_write_recency_for_promote:

cephadm > sudo ceph osd pool set cachepool min_read_recency_for_promote 2
cephadm > sudo ceph osd pool set cachepool min_write_recency_for_promote 2
Anmerkung
Anmerkung

Je größer der Zeitraum und je höher die Werte min_read_recency_for_promote und min_write_recency_for_promote, desto mehr RAM verbraucht der ceph-osd-Daemon. Alle hit_set_count-Treffersätze werden in den RAM geladen, wenn insbesondere der Agent aktiv ist, um Cache-Objekte zu verschieben oder zu entfernen.

10.6.1.2 Cache-Größe

Der Cache Tiering Agent übt zwei Hauptfunktionen aus:

Verschieben

Der Agent erkennt geänderte ("dirty" bzw. fehlerhafte) Objekte und leitet sie für die Langzeitspeicherung an den Speicher-Pool weiter.

Entfernen

Der Agent erkennt Objekte, die nicht bearbeitet wurden ("clean" bzw. intakt) und entfernt die ältesten davon aus dem Cache.

10.6.1.2.1 Absolute Größe

Der Cache Tiering Agent verschiebt oder entfernt Objekte basierend auf der Gesamtanzahl von Bytes oder der Gesamtanzahl von Objekten. Führen Sie folgendes Kommando aus, um die maximale Anzahl von Bytes anzugeben:

cephadm > sudo ceph osd pool set cachepool target_max_bytes num_of_bytes

Führen Sie folgendes Kommando aus, um die maximale Anzahl von Objekten anzugeben:

cephadm > sudo ceph osd pool set cachepool target_max_objects num_of_objects
Anmerkung
Anmerkung

Ceph kann nicht die Größe eines Cache Pools automatisch festlegen, daher muss die absolute Größe hier konfiguriert werden. Andernfalls funktioniert das Verschieben und Entfernen nicht. Wenn Sie beide Grenzwerte angeben, beginnt der Cache Tiering Agent mit dem Verschieben oder Entfernen, sobald einer der Schwellwerte ausgelöst wird.

Anmerkung
Anmerkung

Alle Client-Anforderungen werden erst blockiert, wenn target_max_bytes oder target_max_objects erreicht ist.

10.6.1.2.2 Relative Größe

Der Cache Tiering Agent kann Objekte relativ zur Größe des Cache Pools (angegeben durch target_max_bytes oder target_max_objects in Abschnitt 10.6.1.2.1, „Absolute Größe“) verschieben oder entfernen. Wenn der Cache Pool einen bestimmten Prozentsatz von bearbeiteten (fehlerhaften) Objekten aufweist, verschiebt der Cache Tiering Agent diese in den Speicher-Pool. Führen Sie zum Festlegen von cache_target_dirty_ratio folgendes Kommando aus:

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_ratio 0.0...1.0

Beispielsweise wird bei Wert 0,4 mit dem Verschieben bearbeiteter (dirty) Objekte begonnen, sobald sie 40 % der Kapazität des Cache Pools erreichen:

cephadm > sudo ceph osd pool set hot-storage cache_target_dirty_ratio 0.4

Wenn die fehlerhaften Objekte einen bestimmten Prozentsatz der Kapazität erreichen, können Sie mit höherer Geschwindigkeit verschoben werden. Verwenden Sie dazu cache_target_dirty_high_ratio:

cephadm > sudo ceph osd pool set cachepool cache_target_dirty_high_ratio 0.0..1.0

Erreicht der Cache Pool einen bestimmten Prozentsatz seiner Kapazität, entfernt der Cache Tiering Agent einige Objekte, um freie Speicherkapazität zu erhalten. Führen Sie zum Festlegen von cache_target_full_ratio folgendes Kommando aus:

cephadm > sudo ceph osd pool set cachepool cache_target_full_ratio 0.0..1.0

10.6.1.3 Cache-Alter

Geben Sie das Mindestalter an, das ein kürzlich bearbeitetes (dirty) Objekt erreichen muss, bevor der Cache Tiering Agent es in den Hintergrundspeicher-Pool verschiebt:

cephadm > sudo ceph osd pool set cachepool cache_min_flush_age num_of_seconds

Geben Sie das Mindestalter an, das ein Objekt erreichen muss, bevor es aus der Cache-Schicht entfernt wird:

cephadm > sudo ceph osd pool set cachepool cache_min_evict_age num_of_seconds

10.6.1.4 MGZ für Treffersatz

Cache-Schicht-Einrichtungen enthalten einen Bloomfilter namens Treffersatz. Der Filter testet, ob ein Objekt zu einem Satz von Hot Storage-Objekten oder Cold Storage-Objekten gehört. Die Objekte werden dem Treffersatz mit Zeitstempeln hinzugefügt, die ihren Namen angehängt werden.

Wenn Cluster-Rechner in verschiedenen Zeitzonen aufgestellt und die Zeitstempel von der lokalen Zeit abgeleitet werden, haben Objekte in einem Treffersatz möglicherweise irreführende Namen, die aus Zeitstempeln der Zukunft oder Vergangenheit bestehen. Im schlimmsten Fall sind Objekte gar nicht im Treffersatz vorhanden.

Um dies zu verhindert, wird bei neu erstellten Cache-Schicht-Einrichtungen für use_gmt_hitset der Standardwert "1" festgelegt. Auf diese Weise erzwingen Sie, dass OSDs beim Erstellen der Objektnamen für den Treffersatz die MGZ-Zeitstempel (mittlere Greenwich-Zeit) verwenden.

Warnung
Warnung: Standardwert belassen

Ändern Sie nicht den Standardwert "1" für use_gmt_hitset. Wenn Fehler in Bezug auf diese Option nicht durch Ihre Cluster-Einrichtung verursacht werden, ändern Sie den Wert niemals manuell. Das Cluster-Verhalten wird andernfalls unvorhersehbar.

Diese Seite drucken