Ceph neue OSDs erstellen

[Ingo S]

Hallo zusammen

Ich hatte ja letztens herausgefunden, das normale Consumer SSDs als Cache/Journal/block.db Device nicht wirklich brauchbar sind. Deshalb sind nun die neuen Intel Optane SSD 4800DX da. Irgendwie bekomme ich aber jetzt bei Bluestore OSDs nicht hin, das die SSD dann auch als Journal/block.db Device richtig genutzt wird. Wenn ich da einfach über die PVE GUI Bluestore angehakt lasse, und als Journal Device dann die NVME Disk wähle, dann wird die Partition nur 1GB groß. Das kann doch irgendwie keine sinnvolle Größe sein um mit der SSD vernünftig zu cachen.

Es ist auch gut möglich das ich Bluestore noch nicht richtig verstanden habe.

Ich möchte folgendes:
- Wir haben einen Haufen HDDs als Storage
- für jeden Server eine flotte NVME SSD
Nun sollen die SSDs den HDDs durch das Caching etwas auf die Sprünge helfen. Das hat ja bei Filestore früher schon gut geklappt.
Ist das überhaupt sinnvoll/nötig mit Bluestore?

Vielleicht ist jemand so nett und hilft mir da etwas auf die Sprünge. Ich habe das Gefühl, das ich die Konzepte von Bluestore und Filestore noch nicht richtig verstanden habe und leider fehlt mir die Möglichkeit ein Testsystem zu bauen um verschiedene Konfigurationen durchzutesten.

Eins vorweg:
Was nicht geht: Die HDDs entsorgen und den Cluster mit SSDs betreiben. Dafür haben wir zu viel Speicherbedarf, das wird zu teuer.

 

[wolfgang]

Wenn ich da einfach über die PVE GUI Bluestore angehakt lasse, und als Journal Device dann die NVME Disk wähle, dann wird die Partition nur 1GB groß. Das kann doch irgendwie keine sinnvolle Größe sein um mit der SSD vernünftig zu cachen.

Das ist der Default und der reicht auch für die meisten Senarien.
Du kannst aber auch die NVMe manuell partitionieren und dann die Partitionen im GUI auswählen

Nun sollen die SSDs den HDDs durch das Caching etwas auf die Sprünge helfen.

Ja bringt wenn die SSD schnell ist viel.

Ist das überhaupt sinnvoll/nötig mit Bluestore

Ja.

 

[Ingo S]

Das ist der Default und der reicht auch für die meisten Senarien.
Du kannst aber auch die NVMe manuell partitionieren und dann die Partitionen im GUI auswählen

Ja bringt wenn die SSD schnell ist viel.

Ja.

Kurz und Knackig, danke

Nur: Im pve GUI sehe ich keine Partitionen, sondern nur das Device insgesamt. Wenn ich manuell Partitionen erstelle, erhalte ich beim Erzeugen einer OSD über die GUI eine Fehlermeldung, und in der Konsole keinen Fehler, aber die OSD erscheint nicht und lässt sich auch nicht starten.
Muss ich die Partition vielleicht mit einem bestimmten Typ markieren? fdisk markiert die Partition ja standardmäßig mit dem Typ "Linux"
Leider habe ich dazu auch keine detailierten Infos gefunden. (wenn ich das hinbekommen habe muss ich das unbedingt sauber Dokumentieren sonst krieg ich das nie wieder so hin)

 

[wolfgang]

Nur: Im pve GUI sehe ich keine Partitionen, sondern nur das Device insgesamt. Wenn ich manuell Partitionen erstelle, erhalte ich beim Erzeugen einer OSD über die GUI eine Fehlermeldung, und in der Konsole keinen Fehler, aber die OSD erscheint nicht und lässt sich auch nicht starten.

Nein sollte eigentlich so gehen. Ich werde mir das mal anschauen.
Als workaround kannst du das am CLI machen.

pveceph createosd /dev/sdd -wal_dev /dev/sdc1

 

[Ingo S]

Danke dir!

Ich hab ein wenig probiert und herausgefunden woran es hakt:

• Also im GUI sieht man die Partitionen gar nicht, egal welchen Typ die haben.
• "pveceph createosd /dev/sd[x] -wal_dev/journal_dev /dev/sd[y]" funktioniert nur dann wenn man vorher manuell den Partitionstyp auf 74 (Ceph Journal) setzt. Macht man das nicht, wird die OSD zwar erzeugt, aber sie kann nicht gestartet werden. Vermutung: pveceph setzt beim Erzeugen der OSD den Partitionstyp für das block.db device nicht, oder nicht korrekt.

Ach, eine Sache hab ich noch vergessen:

Wenn ich das jetzt richtig verstanden habe, dann ist der Unterschied zwischen block.db und block.wal:
block.wal -> reines write ahead log, quasi der Cache der die Daten die auf den Block geschrieben werden sollen zuerst abpuffert und sich später dann auf das dahinterliegende Block Device leert
block.db -> Metadaten puffer, der sowohl Metadaten als auch den Cache für das dahinterliegende Block Device darstellt

Dann wäre es ja sinnvoller, statt der block.wal die block.db zu nutzen und auf die SSD zu legen. Ich würde dann statt -wal_dev halt -journal_dev angeben...