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

11 Installation des CephFS Edit source

Das Ceph-Dateisystem (CephFS) ist ein POSIX-fähiges Dateisystem, das seine Daten in einem Ceph Storage Cluster speichert. CephFS verwendet dasselbe Cluster-System wie Ceph-Blockgeräte, Ceph-Objektspeicher mit seinen S3 und Swift APIs, oder systemeigene Bindungen (librados).

Zur Verwendung eines CephFS muss ein Ceph Storage Cluster und mindestens ein Ceph Metadata Server ausgeführt werden.

11.1 Unterstützte CephFS-Szenarios und Anleitungen Edit source

Mit SUSE Enterprise Storage 6 führt SUSE den offiziellen Support für viele Szenarios ein, in denen die dezentrale Scale-Out-Komponente CephFS verwendet wird. Dieser Eintrag beschreibt klare Grenzen und stellt Anleitungen für die vorgeschlagenen Anwendungsfälle zur Verfügung.

Eine unterstützte CephFS-Bereitstellung muss die folgenden Anforderungen erfüllen:

  • Mindestens einen Metadatenserver. SUSE empfiehlt die Bereitstellung von mehreren Nodes mit der MDS-Rolle. Nur einer davon ist aktiv, die anderen sind passiv. Denken Sie daran, alle MON Nodes im Kommando mount anzugeben, wenn Sie das CephFS von einem Client aus einhängen.

  • Clients arbeiten mit SUSE Linux Enterprise Server 12 SP3 (oder höher) bzw. SUSE Linux Enterprise Server 15 (oder höher) und dem Kernel-Modultreiber cephfs. Das FUSE-Modul wird nicht unterstützt.

  • CephFS-Kontingente werden in SUSE Enterprise Storage 6 unterstützt und können für beliebige Unterverzeichnisse im Ceph-Dateisystem festgelegt werden. Das Kontingent beschränkt entweder die Anzahl der Byte oder die Anzahl der Dateien, die unterhalb des angegebenen Punkts in der Verzeichnishierarchie gespeichert werden können. Weitere Informationen finden Sie in Abschnitt 19.6, „Festlegen von CephFS-Kontingenten“.

  • CephFS unterstützt Änderungen des Datei-Layouts wie unter Abschnitt 11.3.4, „Datei-Layouts“ dokumentiert. Weil das Dateisystem jedoch von einem beliebigen Client aus eingehängt wird, werden neue Daten-Pools möglicherweise nicht zu einem bestehenden CephFS-Dateisystem hinzugefügt (ceph mds add_data_pool). Sie dürfen nur hinzugefügt werden, wenn das Dateisystem ausgehängt ist.

  • Mindestens einen Metadatenserver. SUSE empfiehlt die Bereitstellung von mehreren Nodes mit der MDS-Rolle. Zusätzliche MDS Daemons werden standardmäßig als Standby-Daemons eingerichtet und fungieren als Reserve für die aktiven MDS. Auch mehrere aktive MDS Daemons werden unterstützt (siehe Abschnitt 11.3.2, „Größe des MDS Clusters“).

11.2 Ceph Metadata Server Edit source

Der Ceph Metadata Server (MDS) speichert Metadaten für das CephFS. Ceph-Blockgeräte und Ceph-Objektspeicher verwenden keinen MDS. MDSs ermöglichen es Benutzern eines POSIX-Dateisystems, einfache Kommandos auszuführen wie ls oder find, ohne dass der Ceph Storage Cluster übermäßig belastet wird.

11.2.1 Hinzufügen eines Metadatenservers Edit source

Einen MDS stellen Sie im Zug der ersten Cluster-Bereitstellung bereit. Eine Beschreibung hierzu finden Sie in Abschnitt 5.3, „Cluster-Bereitstellung“. Alternativ können Sie ihn auch zu einem bereits bereitgestellten Cluster hinzufügen wie in Abschnitt 2.1, „Hinzufügen neuer Cluster Nodes“ beschrieben.

Nach der Bereitstellung des MDS müssen Sie den Ceph OSD/MDS-Service in den Firewall-Einstellungen des Servers zulassen, auf dem der MDS bereitgestellt ist: Starten Sie yast, navigieren Sie zuSecurity and Users (Sicherheit und Benutzer) › Firewall › Allowed Services (Zugelassene Services) und wählen Sie im Dropdown-Menü Service to Allow (Zuzulassender Service) die Option Ceph OSD/MDS aus. Wenn im Ceph MDS Node kein umfassender Datenverkehr zugelassen ist, tritt beim Einhängen eines Dateisystems ein Fehler auf, auch wenn andere Operationen ordnungsgemäß funktionieren.

11.2.2 Konfigurieren eines Metadata Server Edit source

Sie können das Verhalten des MDS durch Einfügen relevanter Optionen in der ceph.conf-Konfigurationsdatei weiter anpassen.

Metadatenserver-Einstellungen
mon force standby active

Mit „true“ (Standard) erzwingen die Monitors, dass Standby Replay aktiv ist. Festlegung im Abschnitt [mon] oder [global].

mds cache memory limit

Das Softlimit des Arbeitsspeichers (in Byte), das der MDS für seinen Cache erzwingt. Administratoren sollten dies anstelle der alten Einstellung mds cache size verwenden. Der Standardwert ist 1 GB.

mds cache reservation

Die Cache-Reservierung (Arbeitsspeicher oder Inode) für den MDS Cache, die beibehalten werden soll. Wenn der MDS seinen reservierten Cache nahezu auslastet, stellt er den Client-Zustand vorübergehend wieder her, bis sich die Größe des Cache so weit verringert hat, dass die Reservierung wiederhergestellt wird. Der Standardwert ist 0,05.

mds cache size

Anzahl der im Cache zu speichernden Inodes. Der Wert 0 (Standard) bedeutet eine unbegrenzte Anzahl. Es wird empfohlen, die vom MDS Cache genutzte Speichermenge mit mds cache memory limit einzuschränken.

mds cache mid

Einfügepunkt für neue Elemente im Cache LRU (von oben). Der Standardwert ist 0.7.

mds dir commit ratio

Anteil des Verzeichnisses mit kürzlich bearbeiteten („dirty“) Daten, bevor Ceph eine vollständige Aktualisierung anstelle einer Teilaktualisierung durchführt. Der Standardwert ist 0,5.

mds dir max commit size

Maximale Größe einer Verzeichnisaktualisierung, bevor Ceph sie in kleinere Transaktionen aufteilt. Der Standardwert ist 90 MB.

mds decay halflife

Halbwertszeit der MDS Cache-Temperatur. Der Standardwert ist 5.

mds beacon interval

Zeitabschnitt (in Sekunden), in dem Beacon-Meldungen an den Monitor gesendet werden. Der Standardwert ist 4.

mds beacon grace

Zeitraum ohne Beacons, bevor Ceph einen MDS als langsam kennzeichnet und ggf. ersetzt. Der Standardwert ist 15.

mds blacklist interval

Blacklist-Dauer für ausgefallene MDSs in der OSD-Karte. Diese Einstellung steuert, wie lange ausgefallene MDS Daemons in der Blacklist der OSD-Karte verbleiben. Für den Fall, dass der Administrator ein Element manuell in die Blacklist aufnimmt, bleibt die Blacklist-Dauer unverändert. Das Kommando ceph osd blacklist add greift beispielsweise weiterhin auf die standardmäßige Blacklist-Zeit zurück. Der Standardwert ist 24 * 60.

mds reconnect timeout

Zeitraum (in Sekunden), den die Clients beim MDS-Neustart auf die Wiederherstellung der Verbindung warten. Der Standardwert ist 45.

mds tick interval

Zeitabstand, in dem der MDS interne periodische Aufgaben durchführt. Der Standardwert ist 5.

mds dirstat min interval

Mindestzeitabstand (in Sekunden), mit dem die Übertragung rekursiver Statistiken nach oben in der Baumstruktur unterbunden werden soll. Der Standardwert ist 1.

mds scatter nudge interval

Zeitraum, in dem dirstat-Änderungen nach oben übertragen werden. Der Standardwert ist 5.

mds client prealloc inos

Anzahl der Inode-Nummern, die pro Client-Sitzung vorab zugewiesen werden sollen. Der Standardwert ist 1000.

mds early reply

Angabe, ob das MDS den Clients gestatten soll, die Anforderungsergebnisse abzurufen, bevor sie in das Journal aufgenommen wurden. Die Standardeinstellung ist „true“.

mds use tmap

Angabe, dass eine triviale Karte für Verzeichnisaktualisierungen verwendet werden soll. Die Standardeinstellung ist „true“.

mds default dir hash

Funktion für das Hashing von Dateien über Verzeichnisfragmente hinweg. Der Standardwert ist 2 (also „rjenkins“).

mds log skip corrupt events

Angabe, ob das MDS versuchen soll, beschädigte Journal-Ereignisse bei der Wiedergabe des Journals zu überspringen. Die Standardeinstellung ist „false“.

mds log max events

Maximale Anzahl der Ereignisse im Journal, bevor eine Kürzung eingeleitet wird. Mit dem Wert -1 (Standard) werden die Grenzwerte deaktiviert.

mds log max segments

Manchmal Anzahl der Segmente (Objekte) im Journal, bevor eine Kürzung eingeleitet wird. Mit dem Wert -1 werden die Grenzwerte deaktiviert. Der Standardwert ist 30.

mds log max expiring

Maximale Anzahl der Segmente, die parallel ablaufen sollen. Der Standardwert ist 20.

mds log eopen size

Maximale Anzahl von Inoden in einem EOpen-Ereignis. Der Standardwert ist 100.

mds bal sample interval

Zeitabstand für die Ermittlung der Verzeichnistemperatur im Rahmen von Fragmentierungsentscheidungen. Der Standardwert ist 3.

mds bal replicate threshold

Maximale Temperatur, bevor Ceph versucht, die Metadaten auf anderen Knoten zu reproduzieren. Der Standardwert ist 8000.

mds bal unreplicate threshold

Minimale Temperatur, bevor Ceph die Reproduktion der Metadaten auf anderen Knoten anhält. Der Standardwert ist 0.

mds bal split size

Maximale Verzeichnisgröße, bevor der MDS ein Verzeichnisfragment in kleinere Teile aufteilt. Der Standardwert ist 10000.

mds bal split rd

Maximale Verzeichnis-Lesetemperatur, bevor Ceph ein Verzeichnisfragment aufteilt. Der Standardwert ist 25000.

mds bal split wr

Maximale Verzeichnis-Schreibtemperatur, bevor Ceph ein Verzeichnisfragment aufteilt. Der Standardwert ist 10000.

mds bal split bits

Datenmenge (in Bit), nach der ein Verzeichnisfragment aufgeteilt werden soll. Der Standardwert ist 3.

mds bal merge size

Minimale Verzeichnisgröße, bevor Ceph versucht, nebeneinanderliegende Verzeichnisfragmente zusammenzuführen. Der Standardwert ist 50.

mds bal interval

Zeitabstand (in Sekunden) für den Workload-Austausch zwischen MDSs. Der Standardwert ist 10.

mds bal fragment interval

Verzögerung (in Sekunden) zwischen dem Zeitpunkt, an dem ein Fragment aufgeteilt oder zusammengeführt werden kann, und der Durchführung der Fragmentierungsänderung. Der Standardwert ist 5.

mds bal fragment fast factor

Verhältnis, um das die Fragmente die Aufteilungsgröße überschreiten können, bevor eine Aufteilung sofort durchgeführt wird (also ohne den Fragmentzeitabstand abzuwarten). Der Standardwert ist 1.5.

mds bal fragment size max

Maximale Größe eines Fragments, bevor neue Einträge mit ENOSPC abgelehnt werden. Der Standardwert ist 100000.

mds bal idle threshold

Minimale Temperatur, bevor Ceph einen Teilbaum wieder zurück zu dessen übergeordnetem Baum migriert. Der Standardwert ist 0.

mds bal mode

Methode zur Berechnung der MDS-Last:

  • 0 = Hybrid.

  • 1 = Anforderungsrate und Latenz.

  • 2 = CPU-Last.

Der Standardwert ist 0.

mds bal min rebalance

Minimale Teilbaumtemperatur, bevor Ceph die Migration durchführt. Der Standardwert ist 0.1.

mds bal min start

Minimale Teilbaumtemperatur, bevor Ceph einen Teilbaum durchsucht. Der Standardwert ist 0.2.

mds bal need min

Minimaler zu akzeptierender Anteil der Zielteilbaumgröße. Der Standardwert ist 0.8.

mds bal need max

Maximaler zu akzeptierender Anteil der Zielteilbaumgröße. Der Standardwert ist 1.2.

mds bal midchunk

Ceph migriert alle Teilbäume, die größer als dieser Anteil der Zielteilbaumgröße sind. Der Standardwert ist 0.3.

mds bal minchunk

Ceph ignoriert alle Teilbäume, die kleiner als dieser Anteil der Zielteilbaumgröße sind. Der Standardwert ist 0.001.

mds bal target removal min

Minimale Anzahl an Ausgleichsprogramm-Iterationen, bevor Ceph ein altes MDS-Ziel aus der MDS-Karte entfernt. Der Standardwert ist 5.

mds bal target removal max

Maximale Anzahl an Ausgleichsprogramm-Iterationen, bevor Ceph ein altes MDS-Ziel aus der MDS-Karte entfernt. Der Standardwert ist 10.

mds replay interval

Zeitabstand für das Journal-Polling im Standby Replay-Modus („unmittelbar betriebsbereit im Standby-Modus“). Der Standardwert ist 1.

mds shutdown check

Zeitabstand für das Cache-Polling beim Herunterfahren des MDS. Der Standardwert ist 0.

mds thrash fragments

Ceph führt eine willkürliche Fragmentierung oder Zusammenführung der Verzeichnisse durch. Der Standardwert ist 0.

mds dump cache on map

Ceph legt den Inhalt des MDS-Caches in eine Datei auf jeder MDS-Karte ab. Die Standardeinstellung ist „false“.

mds dump cache after rejoin

Ceph legt den Inhalt des MDS-Caches in eine Datei ab, nachdem er bei einer Wiederherstellung wieder in den Cache aufgenommen wurde. Die Standardeinstellung ist „false“.

mds standby for name

Ein MDS Daemon fungiert als Standby für einen anderen MDS Daemon mit dem Namen, der in dieser Einstellung angegeben ist.

mds standby for rank

Ein MDS Daemon fungiert als Standby für einen MDS Daemon mit diesem Rang. Der Standardwert ist -1.

mds standby replay

Angabe, ob ein Ceph MDS Daemon ein Polling für das Protokoll eines aktiven MDS durchführen und dieses Protokoll wiedergeben soll („unmittelbar betriebsbereit im Standby-Modus“). Die Standardeinstellung ist „false“.

mds min caps per client

Mindestanzahl der Capabilities, die ein Client besitzen kann. Der Standardwert ist 100.

mds max ratio caps per client

Maximales Verhältnis der aktuellen Caps, die bei MDS-Cache-Druck abgerufen werden können. Der Standardwert ist 0.8.

Metadatenserver-Journaler-Einstellungen
journaler write head interval

Zeitabstand, in dem das Journal-Kopfobjekt aktualisiert wird. Der Standardwert ist 15.

journaler prefetch periods

Anzahl der Stripe-Zeiträume, die bei der Wiedergabe des Journals im Voraus gelesen werden. Der Standardwert ist 10.

journal prezero periods

Anzahl der Stripe-Zeiträume bis null vor der Schreibposition. Der Standardwert ist 10.

journaler batch interval

Maximale zusätzliche Latenz (in Sekunden), die künstlich hervorgerufen wird. Der Standardwert ist 0.001.

journaler batch max

Maximale Datenmenge (in Byte), um die die Verschiebung verzögert wird. Der Standardwert ist 0.

11.3 CephFS Edit source

Wenn Ihr Ceph Storage Cluster mit mindestens einem Ceph Metadata Server ordnungsgemäß funktioniert, können Sie Ihr Ceph-Dateisystem erstellen und einhängen. Stellen Sie sicher, dass Ihr Client mit dem Netzwerk verbunden ist und über einen ordnungsgemäßen Schlüsselbund zur Authentifizierung verfügt.

11.3.1 Erstellen eines CephFS Edit source

Ein CephFS benötigt mindestens zwei RADOS-Pools: einen für Daten und einen für Metadaten. Beim Konfigurieren dieser Pools sollten Sie Folgendes in Erwägung ziehen:

  • Eine höhere Reproduktionsstufe für den Metadaten-Pool, da jeglicher Datenverlust in diesem Pool dazu führen kann, dass auf das gesamte Dateisystem nicht mehr zugegriffen werden kann.

  • Ein Speicher mit geringerer Latenz für den Metadaten-Pool wie SSDs, weil dadurch die beobachtete Latenz der Dateisystemoperationen an Clients verbessert wird.

Bei der Zuweisung eines role-mds in Datei policy.cfg werden die erforderlichen Pools automatisch erstellt. Sie können vor dem Einrichten des Metadata Server die Pools cephfs_data und cephfs_metadata manuell erstellen, um die Leistung manuell anzupassen. Diese Pools werden von DeepSea nicht erstellt, wenn sie bereits vorhanden sind.

Weitere Informationen zur Verwaltung von Pools finden Sie im Kapitel 11, Verwalten von Speicher-Pools.

Führen Sie die folgenden Kommandos aus, um die beiden erforderlichen Pools (z. B. „cephfs_data“ und „cephfs_metadata“) mit Standardeinstellungen für das CephFS zu erstellen:

cephadm@adm > ceph osd pool create cephfs_data pg_num
cephadm@adm > ceph osd pool create cephfs_metadata pg_num

Es ist möglich, EC-Pools anstelle von reproduzierten Pools zu verwenden. Wir empfehlen, EC-Pools nur für geringe Leistungsanforderungen und gelegentlichen zufälligen Zugriff zu verwenden, beispielsweise für Cold Storage, Sicherungen oder Archivierung. Für die Aktivierung von CephFS in EC-Pools ist BlueStore erforderlich und die Option allow_ec_overwrite muss für den Pool festgelegt sein. Diese Option kann durch Ausführung des Kommandos ceph osd pool set ec_pool allow_ec_overwrites true festgelegt werden.

Ein Erasure Coding (EC) vergrößert erheblich den Overhead für Dateisystemoperationen, insbesondere kleine Updates. Dieser Overhead entsteht zwangsläufig, wenn Erasure Coding als Fehlertoleranzmechanismus verwendet wird. Diese Einbuße ist der Ausgleich für einen erheblich reduzierten Speicherplatz-Overhead.

Wenn die Pools erstellt sind, können Sie das Dateisystem mit dem Kommando ceph fs new aktivieren:

cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name

Beispiel:

cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data

Durch Auflisten aller verfügbarer CephFSs prüfen Sie, ob das Dateisystem erstellt wurde:

cephadm@adm > ceph fs ls
 name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Wenn das Dateisystem erstellt wurde, kann der MDS den Zustand aktiv annehmen. Beispielsweise in einem einzelnen MDS-System:

cephadm@adm > ceph mds stat
e5: 1/1/1 up
Tipp
Tipp: Weitere Themen

Weitere Informationen zu spezifischen Aufgaben (beispielsweise Einhängen, Aushängen und erweiterte CephFS-Einrichtung) finden Sie im Kapitel 19, Cluster-Dateisystem.

11.3.2 Größe des MDS Clusters Edit source

Eine CephFS-Instanz kann von mehreren aktiven MDS Daemons bedient werden. Alle aktiven MDS Daemons, die einer CephFS-Instanz zugewiesen sind, teilen den Verzeichnisbaum des Dateisystems unter sich auf. Dadurch wird die Last gleichmäßig auf die gleichzeitig ausgeführten Clients verteilt. Zum Hinzufügen eines aktiven MDS Daemon zu einer CephFS-Instanz ist eine zusätzliche Standby-Instanz erforderlich. Starten Sie entweder einen zusätzlichen Daemon oder verwenden Sie eine vorhandene Standby-Instanz.

Durch das folgende Kommando wird die aktuelle Anzahl der aktiven und passiven MDS Daemons angezeigt.

cephadm@adm > ceph mds stat

Durch die folgenden Kommandos wird die Anzahl der aktiven MDSs auf zwei pro Dateisysteminstanz festgelegt.

cephadm@adm > ceph fs set fs_name max_mds 2

Sie müssen zwei Schritte ausführen, um den MDS Cluster vor einem Update zu verkleinern. Legen Sie zunächst max_mds fest, damit nur noch eine Instanz vorhanden ist:

cephadm@adm > ceph fs set fs_name max_mds 1

Deaktivieren Sie danach explizit die anderen MDS Daemons:

cephadm@adm > ceph mds deactivate fs_name:rank

Dabei bezeichnet rank die Nummer eines aktiven MDS Daemons einer Dateisysteminstanz im Bereich von 0 bis max_mds-1.

Es wird empfohlen, mindestens einen MDS als Standby-Daemon beizubehalten.

11.3.3 MDS Cluster und Updates Edit source

Bei Ceph Updates ändern sich möglicherweise die Feature-Einstellungen (normalerweise durch Hinzufügen neuer Features). Nicht kompatible Daemons (wie die älteren Versionen) funktionieren nicht bei einem nicht kompatiblen Feature-Satz und starten nicht. Dies bedeutet, dass durch das Update und den Neustart eines Daemons alle anderen noch nicht aktualisierten Daemons möglicherweise anhalten und nicht mehr starten. Aus diesem Grund empfehlen wir, vor einem Update von Ceph den aktiven MDS Cluster auf die Größe einer Instanz zu verkleinern und alle Standby Daemons anzuhalten. Die manuellen Schritte für diesen Update-Vorgang sind wie folgt:

  1. Aktualisieren Sie die auf Ceph bezogenen Pakete mithilfe von zypper.

  2. Verkleinern Sie den MDS Cluster wie oben beschrieben auf eine Instanz und halten Sie alle MDS Standby Daemons an. Verwenden Sie dazu deren systemd-Einheiten in allen anderen Nodes:

    cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target
  3. Starten Sie erst dann den einzig verbleibenden MDS Daemon und verursachen Sie seinen Neustart anhand der aktualisierten Binärdatei.

    cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target
  4. Starten Sie alle anderen MDS Daemons neu und legen Sie die gewünschte Einstellung max_mds neu fest.

    cephadm@mds > systemctl start ceph-mds.target

Wenn Sie DeepSea verwenden, führt es diesen Vorgang aus, falls das ceph -Paket in Phase 0 und 4 aktualisiert wurde. Es ist möglich, diesen Vorgang auszuführen, während bei Clients die CephFS-Instanz eingehängt ist und E/A weiterhin ausgeführt wird. Beachten Sie jedoch, dass es beim Neustart des aktiven MDS eine kurze E/A-Pause gibt. Die Clients werden automatisch wiederhergestellt.

Es hat sich bewährt, vor dem Aktualisieren eines MDS Clusters die E/A-Last so weit wie möglich zu reduzieren. Ein inaktiver MDS Cluster durchläuft diesen Update-Vorgang schneller. Umgekehrt ist es auf einem sehr ausgelasteten Cluster mit mehreren MDS Daemons sehr wichtig, die Last vorher zu reduzieren, um zu verhindern, dass ein einzelner MDS Daemon durch fortlaufende E/A-Vorgänge überlastet wird.

11.3.4 Datei-Layouts Edit source

Das Layout einer Datei steuert die Zuordnung ihrer Inhalte zu Ceph RADOS-Objekten. Sie können das Layout einer Datei mit virtuellen erweiterten Attributen (kurz xattrs) lesen und schreiben.

Der Name des Layout-xattrs ist davon abhängig, ob eine Datei eine normale Datei oder ein Verzeichnis ist. Die Layout-xattrs normaler Dateien werden als ceph.file.layout bezeichnet, die Layout-xattrs von Verzeichnissen dagegen als ceph.dir.layout. In Beispielen, die auf ceph.file.layout verweisen, tragen Sie entsprechend den Teil .dir. ein, wenn Sie mit Verzeichnissen arbeiten.

11.3.4.1 Layoutfelder Edit source

Die folgenden Attributfelder werden erkannt:

pool

ID oder Name eines RADOS-Pools, in dem die Datenobjekte einer Datei gespeichert werden.

pool_namespace

RADOS-Namespace in einem Daten-Pool, in den die Objekte geschrieben werden. Dieses Attribut ist standardmäßig leer, sodass der standardmäßige Namespace verwendet wird.

stripe_unit

Größe eines Datenblocks (in Byte) in der RAID-0-Verteilung einer Datei. Alle Stripe-Einheiten für eine Datei sind gleich groß. Die letzte Stripe-Einheit ist in der Regel unvollständig – sie enthält die Daten am Ende der Datei sowie den nicht belegten „Platz“ nach dem Dateiende bis zum Ende der festen Größe der Stripe-Einheit.

stripe_count

Anzahl aufeinanderfolgender Stripe-Einheiten, die einen RAID-0-„Stripe“ mit Dateidaten bilden.

object_size

Größe der RADOS-Objekte (in Byte), auf die die Dateidaten blockweise aufgeteilt werden.

Tipp
Tipp: Objektgrößen

RADOS erzwingt einen konfigurierbaren Grenzwert für Objektgrößen. Wenn Sie die CephFS-Objektgrößen über diesen Grenzwert hinaus erhöhen, schlagen Schreibvorgänge möglicherweise fehl. Die OSD-Einstellung lautet osd_max_object_size und liegt standardmäßig bei 128 MB. Sehr große RADOS-Objekte können den reibungslosen Betrieb des Clusters beeinträchtigen. Es wird daher nicht empfohlen, den Grenzwert für die Objektgröße über den Standardwert hinaus zu erhöhen.

11.3.4.2 Lesen des Layouts mit getfattr Edit source

Mit dem Kommando getfattr lesen Sie die Layoutinformationen der Beispieldatei file als einzelne Zeichenkette:

root # touch file
root # getfattr -n ceph.file.layout file
# file: file
ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430

So lesen Sie einzelne Layoutfelder:

root # getfattr -n ceph.file.layout.pool file
# file: file
ceph.file.layout.pool="cephfs_data"
root # getfattr -n ceph.file.layout.stripe_unit file
# file: file
ceph.file.layout.stripe_unit="4194304"
Tipp
Tipp: Pool-ID oder Name

Beim Lesen der Layouts ist der Pool in der Regel mit seinem Namen angegeben. Wenn ein Pool erst vor Kurzem erstellt wurde, wird in seltenen Fällen stattdessen die ID ausgegeben.

Verzeichnisse besitzen erst dann ein explizites Layout, wenn es angepasst wird. Ein Versuch, das Layout zu lesen, schlägt fehl, wenn das Layout bislang noch nicht bearbeitet wurde. Dies bedeutet, dass das Layout des nächstgelegenen übergeordneten Verzeichnisses mit explizitem Layout verwendet wird.

root # mkdir dir
root # getfattr -n ceph.dir.layout dir
dir: ceph.dir.layout: No such attribute
root # setfattr -n ceph.dir.layout.stripe_count -v 2 dir
root # getfattr -n ceph.dir.layout dir
# file: dir
ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 Schreiben von Layouts mit setfattr Edit source

Mit dem Kommando setfattr bearbeiten Sie die Layoutfelder der Beispieldatei file:

cephadm@adm > ceph osd lspools
0 rbd
1 cephfs_data
2 cephfs_metadata
root # setfattr -n ceph.file.layout.stripe_unit -v 1048576 file
root # setfattr -n ceph.file.layout.stripe_count -v 8 file
# Setting pool by ID:
root # setfattr -n ceph.file.layout.pool -v 1 file
# Setting pool by name:
root # setfattr -n ceph.file.layout.pool -v cephfs_data file
Anmerkung
Anmerkung: Leere Datei

Wenn die Layoutfelder einer Datei mit setfattr bearbeitet werden, muss diese Datei leer sein, da ansonsten ein Fehler auftritt.

11.3.4.4 Löschen von Layouts Edit source

Mit folgendem Kommando können Sie ein explizites Layout aus dem Beispielverzeichnis mydir entfernen und wieder zur Übernahme des Layouts vom übergeordneten Element zurückkehren:

root # setfattr -x ceph.dir.layout mydir

Ähnliches gilt, wenn Sie das Attribut „pool_namespace“ festgelegt haben und das Layout nun wieder auf den Standard-Namespace zurückgreifen soll:

# Create a directory and set a namespace on it
root # mkdir mydir
root # setfattr -n ceph.dir.layout.pool_namespace -v foons mydir
root # getfattr -n ceph.dir.layout mydir
ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \
 pool=cephfs_data_a pool_namespace=foons"

# Clear the namespace from the directory's layout
root # setfattr -x ceph.dir.layout.pool_namespace mydir
root # getfattr -n ceph.dir.layout mydir
ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \
 pool=cephfs_data_a"

11.3.4.5 Übernahme von Layouts Edit source

Dateien übernehmen bei ihrer Erstellung das Layout ihres übergeordneten Verzeichnisses. Nachfolgende Änderungen am Layout des übergeordneten Verzeichnisses wirken sich jedoch nicht auf die untergeordneten Elemente aus:

root # getfattr -n ceph.dir.layout dir
# file: dir
ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \
 pool=cephfs_data"

# file1 inherits its parent's layout
root # touch dir/file1
root # getfattr -n ceph.file.layout dir/file1
# file: dir/file1
ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \
 pool=cephfs_data"

# update the layout of the directory before creating a second file
root # setfattr -n ceph.dir.layout.stripe_count -v 4 dir
root # touch dir/file2

# file1's layout is unchanged
root # getfattr -n ceph.file.layout dir/file1
# file: dir/file1
ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \
 pool=cephfs_data"

# ...while file2 has the parent directory's new layout
root # getfattr -n ceph.file.layout dir/file2
# file: dir/file2
ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \
 pool=cephfs_data"

Dateien, die als untergeordnete Elemente des Verzeichnisses erstellt wurden, übernehmen ebenfalls dessen Layout, wenn für die dazwischenliegenden Verzeichnisse keine Layouts festgelegt sind:

root # getfattr -n ceph.dir.layout dir
# file: dir
ceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \
 pool=cephfs_data"
root # mkdir dir/childdir
root # getfattr -n ceph.dir.layout dir/childdir
dir/childdir: ceph.dir.layout: No such attribute
root # touch dir/childdir/grandchild
root # getfattr -n ceph.file.layout dir/childdir/grandchild
# file: dir/childdir/grandchild
ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \
 pool=cephfs_data"

11.3.4.6 Hinzufügen eines Daten-Pools zum Metadatenserver Edit source

Bevor Sie einen Pool mit CephFS verwenden können, müssen Sie ihn zum Metadatenserver hinzufügen:

cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssd
cephadm@adm > ceph fs ls  # Pool should now show up
.... data pools: [cephfs_data cephfs_data_ssd ]
Tipp
Tipp: cephx-Schlüssel

Die cephx-Schlüssel müssen dem Client den Zugriff auf diesen neuen Pool gestatten.

Anschließend können Sie das Layout für ein Verzeichnis in CephFS aktualisieren und dabei den hinzugefügten Pool angeben:

root # mkdir /mnt/cephfs/myssddir
root # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir

Alle in diesem Verzeichnis erstellten neuen Dateien übernehmen nun dessen Layout und platzieren die Daten in den soeben hinzugefügten Pool. Unter Umständen steigt die Anzahl der Objekte in primären Daten-Pool selbst dann weiterhin an, wenn die Dateien im soeben hinzugefügten Pool erstellt werden. Dies ist völlig normal. Die Dateidaten werden in dem Pool gespeichert, der im Layout angegeben ist, doch für alle Dateien wird eine kleine Metadaten-Menge im primären Daten-Pool abgelegt.

Diese Seite drucken