Bug? Ceph Pool Größe variiert je nach Füllstand

[Ingo S]

Hallo zusammen

Ich habe unseren SSD Pool ein wenig aufgeräumt und dabei ist mir aufgefallen, dass die Gesamtgröße des Pools variiert, je nachdem wie voll der Pool ist.
Wie kann das sein? Die Datenträger haben doch eine fixe Größe unabhängig davon wie viele Daten gespeichert sind.

In älteren PVE Versionen war es immer so: Die Größe des Pools war fix und entsprach der RAW capacity aller Datenträger. Alle darauf gespeicherten Daten gingen mit [Speicherplatz]*[Replica] vom Gesamtspeicherplatz ab. In unserem Fall würde also ein Datenträgerimage von 100GB Größe mit 300GB auf dem Pool zu Buche schlagen, wäre das Image voll belegt. Dennoch würde doch der Pool seine z.B. 1TB Gesamtkapazität behalten, man könnte halt "nur" 333GB Daten dort ablegen.

 

[Falk R.]

Moin Ingo,
das habe ich auch schon gesehen und hier meine Erfahrungen:
Wenn du auf Ceph gehst hast du das Brutto:
Gehst du auf den DataStore hast du die nutzbare Kapazität: (hier 2fach Mirror)


Wenn du aber Erasure Coding benutzt habe ich den gleichen Effekt gesehen, dass beim Datastore der Verfügbare Speicher Schwankt, als ob da für dem freien Speicher, da Brutto herangezogen wird. Habe ich aber in meiner Spielumgebung zuhause nicht.

 

[sb-jw]

Die maximale Speicherkapazität hängt auch von der Verteilung der Daten auf den OSDs ab, da sich der Füllstand letztlich immer nach der vollsten OSD richtet.

Habe ich also z. B. einen Cluster aus 3 OSDs und bei zwei sind 20 % belegt und bei einer sind 30 % belegt, dann habe ich einen Verlust von 10 % im Gesamtspeicher (statt also quasi 80 % habe ich nur noch 70 % frei - nearfull und full sowie Verluste durch Umrechnung mal weggelassen). Wenn ich es nun schaffe die 10 % auf alle gleichermaßen zu verteilen (20 + 20 + 30 / 3 = 23,33 %), dann habe ich auch plötzlich wieder rund 7 % mehr Gesamtspeicherplatz.

Deshalb sollte man immer auf die optimale Verteilung der PGs achten und z. B. den Balancer nutzen.
Grundsätzlich zu beachten ist aber, dass der angezeigte Gesamtspeicher eben immer der rechnerische maximale Wert ist, welcher eben von der PG Verteilung bzw. dem Füllstand abhängt. Es ist aber auch kein nearfull und full eingerechnet, auch keine Verluste durch mögliche Metadaten. Diese Hochrechnung hat Ihre Probleme wenn es mehrere Pools gibt oder auf einem Cluster ein vollständiger Mischbetrieb mit EC und 2/1 etc. gefahren wird. Gerade wenn man EC, ein 2/1 und ein 3/1 Pool hat wird man solch eine Hochrechnung höchstens auf den Pool selbst anwenden können, aber auf den Gesamtverfügbaren Speicher wird das nicht funktionieren.
Daher sollte man die Verteilung der PGs und den Gesamtfüllstand im Blick behalten - anstelle dieser Grafiken.

CEPH kann bei solchen Detailfragen schon sehr komplex werden, daher entstehen leider auch oft falsche Eindrücke oder Erwartungshaltungen von den Anwendern, welche dann nachher frustriert sind und CEPH als "schrott" abtun. Ich denke, dass man das gerade auch hier sehen und merken kann.

 

[Falk R.]

CEPH kann bei solchen Detailfragen schon sehr komplex werden, daher entstehen leider auch oft falsche Eindrücke oder Erwartungshaltungen von den Anwendern, welche dann nachher frustriert sind und CEPH als "schrott" abtun. Ich denke, dass man das gerade auch hier sehen und merken kann.

Ich bin ja auch deiner Meinung, dass man schon verstanden haben muss, was man tut.
Aber hier geht es ja darum zu verstehen warum der das so anzeigt. Vor allem als Dienstleister wird man ja immer gefragt, warum wird das so angezeigt und der Kunde will wissen, ab welcher Anzeige er dich anruft.

 

[sb-jw]

Wie ja geschrieben, das hat vielfältige Gründe und auch variiert ja die Größe bei verschiedenen Pools auf dem gleichen CEPH. Dazu mal Screenshots von einem meiner Cluster.




Pool #1


Pool #2


CephFS

der Kunde will wissen, ab welcher Anzeige er dich anruft.

Gehen wir mal von Defaults aus, dass man nearfull auf 85 % hat und Full auf 95 %. Dann wissen wir schon mal, dass man ab spätestens 85 % eine neue Node nachschieben sollte. Was man aber auch wissen sollte, sobald man eine Node oder OSD nachschiebt, verändert sich die Verteilung der Daten. Eine OSD die aber schon sehr nach an 95 % ist, kann in diesem Fall auch dazu aufgefordert werden noch mehr Daten zu speichern - das passiert in der Regel immer in der Anfangsphase und kann dann im schlimmsten Fall zu einem read-only führen. Aus dem Grund bin ich persönlich immer der Auffassung, dass man auch nicht an 85 % heran will, auch sollte das in der Regel einen Alarm auslösen im Monitoring.

In der Planung muss aber auch enthalten sein, dass ich eine Node vollständig auf die anderen umverteilen kann. Bei einem Cluster mit 3 Nodes und Replika 3 spielt das aber keine Rolle, da CEPH so oder so nicht wieder healthy werden kann. Habe ich aber nun 5 Nodes und auch fahre meinen Cluster auch im produktivbetrieb ohne noout etc. dann muss ich aber auch dafür sorgen, dass die 4 anderen Nodes die Datenmengen der 5. aufnehmen können ohne auch hier gleich in nearfull oder full zu laufen.
Zu beachten ist aber auch die Anzahl der OSDs pro Node. Bei einem 3 Node Cluster und jeweils 2 OSD per Node, kann ich auch nur maximal 42,5 % pro OSD belegen, da bei einem Ausfall einer OSD die andere auch die restlichen 42,5 % tragen können muss, dann bist du aber auch direkt bei nearfull. Das geht, wenn du zusätzlich auch das Wachstum der letzten Tage im Blick hast, dass du dann hier nicht direkt in full rein läufst und der Pool steht.

Wann also nun der korrekte Zeitpunkt ist, dass dich dein Kunde anruft sollte individuell am Cluster bestimmt werden und kann nicht pauschal bei X oder Y ausgesagt werden. Insbesondere spielen diese Faktoren bei kleineren Setups eine erhebliche Rolle, da eben der prozentuale Anteil pro Node oder OSD höher ist als wenn du eben 100 Storage Nodes hast.

Ich persönlich würde bei einem Füllstand > 50 % anfangen zu prüfen was so viele Daten belegt und diese ggf. mal löschen (Hinweis, ein Snapshot in CEPH kann auf jeweils die gleiche Größe wie die virtuelle Festplatte selbst anwachsen. Habe ich also eine 200 GB Platte und mach einen Snapshot, hat die VM schon platz für bis zu 400 GB auf dem CEPH. Daher sollten Snapshots auch regelmäßig gelöscht werden.).
Wenn ich den Füllstand nicht reduziert bekomme, weil ich feststelle, dass das in der Tat alles notwendige Daten sind, würde ich persönlich auch weitere OSDs einbauen, eine Node nachschieben oder bestehende z. B. 960 GB OSD mit 1,92 TB tauschen. Wichtig ist nur, dass das ein konsistentes vorgehen ist, denn der Mischbetrieb mit 960 GB und 1,92 TB SSDs macht diese Kalkulationen noch mal deutlich schwerer und komplexer und sollte auch wieder gelöst werden.

Da Kunden ja häufig auch nur die Wirtschaftlichkeit im Kopf habe und es oftmals nicht einsehen, warum sie bei 55 % direkt nachschieben sollen, würde ich einfach die 85 % des Gesamtspeichers als maximum sehen (wegen nearfull) und davon den Speicher einer Node abziehen.
Habe ich also 5 Nodes, wäre meine Rechnung 85 % / 5 Nodes = 17 %, dann von 85 % die 17 % abziehen und wir sind bei 68 % - hier sollte der Kunde anrufen, damit die weitere Planung durchgeführt werden kann (also ob ne neue Node, weitere Disks oder die bestehenden austauschen). Bei diesem Wert hast du zumindest noch alle Möglickeiten offen, wenn du bereits über nearfull bist kann es nämlich sein, dass du sauber keine OSD mehr durch eine größere tauschen kannst.
Ab 75 % solltest du den Kunden dann aber zu einer Aktion bewegen oder diese einfach ausführen (wenn z. B. Vertraglich möglich).

Wenn du aber weißt wie es um diese ganzen Faktoren, Aufbau und Wachstum des Clusters steht, kannst du natürlich auch von der pauschalisierung abrücken und die möglichen Grenzen höher setzen. Würde ich aber auch nur dann tun, wenn es mein Cluster ist und ich jederzeit auch für Abhilfe schaffen kann weil ich jetzt direkt eine neue Node oder Disks bestellen kann. Bei der Abhängigkeit zu Kunden sollte aber eben ein Puffer eingeplant sein.

 

[Falk R.]

Ich habe die kleinen Cluster eh so gesized dass unter 50% Belegung ist und da jeder Node immer mindestens 4 OSD hat, ist das schon mal entspannt. Bei meinem größten Cluster haben wir 14 OSD pro Node und da theoretisch 80% demnächst erreicht werden könnten, kommt Anfang Januar der achte Node dazu.
Aber wenn bei den EC Pools der verfügbare Speicher wieder hoch geht, könnte das den Kunden in falsche Sicherheit wiegen.
Bei den replicated Pools ist mir das noch nicht aufgefallen aber bei den großen EC Pools wäre das schon interessant wie sich die Anzeige zusammensetzt. Falls man mal eben 100TB Daten ablegen will, sollte man schon verlässlich wissen ob man dann den Pool zu voll macht.

 

[sb-jw]

Aber wenn bei den EC Pools der verfügbare Speicher wieder hoch geht, könnte das den Kunden in falsche Sicherheit wiegen.

Das mag sein, aber aufgrund dieser vielfältigen Faktoren ist eine verlässliche Berechnung ja nicht ohne weiteres möglich. Wenn du nur nur eine Art Pool im CEPH hast, kannst du das ja definitiv tun. Wenn du aber halt verschiedene Replikationen und EC auf einem Storage hast, kannst du das halt nicht mehr verlässlich - das liegt aber auch in der Natur der Sache. Du kannst zwar eine feste Größe pro Pool allokieren, wenn du dann aber einen mit Replika 5/2 anlegst, dann verbraucht der ja mehr Speicherplatz als es der 3/1 tun würde.
Wir sind hier aber auch wieder bei dem Thema, dass der Kunde das halt eben auch verstehen muss wie das zustande kommt und wie sich das berechnet. Entweder du vermittelst dem Kunden dieses wissen oder du verweist ihn auf den Füllstand des kompletten CEPH Storage und wählst eben einen niedrigen Schwellwert aus. Organisatorisch kann es auch eine Lösung sein, dass dich dein Kunde bei größeren Datenmengen vorab konsultiert und das vorhaben abstimmt.

Das Problem wird aber weder CEPH noch PVE für dich lösen können. Du kannst es lösen, wenn du Pools eine feste größe gibst und auch genau diese Ressourcen vorhälst. Das ist natürlich nicht wirtschaftlich, wenn du aber die Anforderungen von deinem Kunden dahin gehend hast, bleibt dir eigentlich keine andere Wahl.

Bei den replicated Pools ist mir das noch nicht aufgefallen

Ändere mal die Grafik in PVE und fahr mal drüber, das ist ständig im Wandel. Das sieht jetzt @Ingo S deutlich wilder aus, weil er eben einmal tabularasa gemacht hat. Wenn du aber fortwährend VMs löscht oder Snapshots etc. dann geht das fast unter weil es keine größere Änderung ist.

Falls man mal eben 100TB Daten ablegen will, sollte man schon verlässlich wissen ob man dann den Pool zu voll macht.

Das scheint mir aber kein valider Fall zu sein, dass man "mal eben" solch eine Menge an Daten hat die plötzlich wohin müssen. Ist mir zumindest in meiner bisherigen Zeit nicht unterkommen, die Kunden haben das immer ankündigen können. Meist konnte man auch direkt 10 - 15 TB bereitstellen und hat dann eben die weitere Kapazitäten in Bestellung gegeben, so dass man die einlaufenden Daten mit den neuen Storage Nodes auch gleich kompensieren konnte.
Platz für 2 - 3 TB sollte jederzeit da sein, auch 10 TB könnte noch abbildbar sein, alles darüber hinaus würde ich auch vorab im Detail prüfen.

 

[Falk R.]

Bei normalen VM Cluster sind es maximal 10TB pro VM, aber ich habe auch Archivsysteme, wenn sich da mal wieder einer überlegt bestimmte Projekte zu archivieren, werden schon mal eben solche Mengen bewegt. Das sind aber Cluster mit deutlich über 1PB Speicher.
Bevor ich den Kunden betreut habe, war das mal ein altes Ubuntu mit Ceph, aber schlecht konfiguriert und gewartet.
Mit Proxmox ist das ganze deutlich unkomplizierter und viel aktueller.
Es gibt verschiedene Anwendungsfälle die man mit PVE abbilden kann und damit auch ganz unterschiedliche Anforderungen.

 

[Ingo S]

Uff, mehr Diskussion als ich erwartet hatte

Also wir nutzen schon seit vielen Jahren Ceph als Storage backend und ich muss sagen, dass mir dieses Verhalten vorher noch nie aufgefallen war.

Ich persönlich finde es am konsistentesten wenn die Größe des Pools einfach der Summe des Speicherplatzes der darin verwendeten OSDs entspricht. Alles Andere leitet sich ja dann davon ab.
10 OSDs a 10TB ergeben dann eine Pool Größe von 100TB. Lege ich dann den Pool mit 3/2 fest und lege 10TB ab, sind dann halt 30TB (30%) belegt zzgl. Metadaten.
Das sich die OSDs möglichst gleichmäßig füllen und genügend Reservespeicher vorhanden ist, falls z.B. mal ein Node ausfällt, versteht sich von selbst finde ich.
Aber das ist nur mein einfacher, naiver Ansatz.

Wenn ich das richtig verstehe stammen die angezeigten Daten allerdings von Ceph direkt. PVE hat mit dem merkwürdigen Verhalten also gar nichts zu tun?

 

[sb-jw]

Uff, mehr Diskussion als ich erwartet hatte

Das tut mir wirklich leid, wenn die Ausmaße der Diskussion nicht deinen Erwartungen entspricht

Ich persönlich finde es am konsistentesten wenn die Größe des Pools einfach der Summe des Speicherplatzes der darin verwendeten OSDs entspricht.

Genau das geht ja nicht, da ein CEPH Storage auch hunderte Pools haben kann die ja auch nicht mal identische Replica haben müssen. Grundsätzlich sind Pools in CEPH ja auch weder in den I/O noch im Speicher limitiert, das kann man zwar setzen, aber eigentlich will man das auch nicht. Da eben dann aber alles offen ist, müssen die Ressourcen eben auch für alle und alles kalkuliert werden.

Ein einfaches Beispiel noch dazu. Dein CEPH 100 TB Speicher wie in deinem Beispiel. Wenn ich Replica 2 habe, dann kann ich ja 50 TB belegen. Habe ich hingegen Replica 3 kann ich nur noch 33TB belgen. Wenn du jetzt einen Pool aus Replica 2 und einen aus Replica 3 hast, wie viel Speicherplatz kannst du nun maximal pro Pool belegen? Hier ist dann eben auch wieder der Punkt, wenn im Replica 2 Pool bereits 25 TB belegt sind, dann verbleiben ja noch maximal 75 TB nutzbar, also kann der Replica 3 Pool nicht mehr 33 TB fassen sondern nur noch 25 TB. Genau deshalb sinkt auch die Anzeige des maixmalen Speicherplatzes je Pool.

Wenn ich das richtig verstehe stammen die angezeigten Daten allerdings von Ceph direkt. PVE hat mit dem merkwürdigen Verhalten also gar nichts zu tun?

Exakt das!

Wie aber gesagt, man muss das eben verstehen wie das in CEPH funktioniert und dann darf das auch keine relevante Metrik sein sondern die Gesamtauslastung zählt und dann wird einfach nachgeschoben. So funktioniert CEPH halt, man wirft mit Speicherplatz nach dem Füllstand und das Problem ist damit erschlagen.

 

[aaron]

Spannende und gute Diskussion hier

Ein wenig einfacher, aber auch recht ähnlich verhält es sich, wenn man in einem ZFS Pool mehrere Storages konfiguriert. Idealerweise in eigenen sub-datasets.
Z.B.:

mypool
mypool/storage1
mypool/storage2

Auch hier teilen sich beide storage Datasets die gesamte Kapazität des Pools. Wenn nun ein Storage mehr Speicherplatz verbraucht oder wieder freigibt, sieht das andere Storage das auch entsprechend. Die Graphen in der Storageübersicht können dann noch viel spannender sein als im ersten Post.
Da ZFS aber nicht ganz so viele bewegliche Teile hat im Vergleich zu Ceph, lässt sich das meist leichter nachvollziehen.

 

[Ingo S]

Das tut mir wirklich leid, wenn die Ausmaße der Diskussion nicht deinen Erwartungen entspricht

Ich finds ja gut. So sieht man auch mal, wie andere damit umgehen. Da kann man nur lernen.

Genau das geht ja nicht, da ein CEPH Storage auch hunderte Pools haben kann die ja auch nicht mal identische Replica haben müssen. Grundsätzlich sind Pools in CEPH ja auch weder in den I/O noch im Speicher limitiert, das kann man zwar setzen, aber eigentlich will man das auch nicht. Da eben dann aber alles offen ist, müssen die Ressourcen eben auch für alle und alles kalkuliert werden.

Hmm jaein... Ich würde mir das so vorstellen:
Der Pool zeigt den gesamten Speicherplatz aller beteiligten OSDs als RAW Value an. Z.B. 100TB Wenn ich dann 2 Pools habe, geht halt vom verfügbaren Speicherplatz der Inhalt beider Pools zusammen ab. Beide Pools hätten dann 100TB gesamt. Pool A (3/2) enthält 10TB Daten, Pool B 5/3 enthält 1TB Daten. Dann ergibt sich folgendes: 10TB x3 + 1TB x 5 = 35TB Belegt = 65% frei. Egal in welchem Pool ich Daten ablege, die verfügbare Kapazität sinkt bei beiden Pools. In jedem Fall ist es dann egal wie viele Pools und Konstellationen ich auf dem Speicher verwende, es stimmt immer und es ist nachvollziehbar berechenbar.

Ein einfaches Beispiel noch dazu. Dein CEPH 100 TB Speicher wie in deinem Beispiel. Wenn ich Replica 2 habe, dann kann ich ja 50 TB belegen. Habe ich hingegen Replica 3 kann ich nur noch 33TB belgen. Wenn du jetzt einen Pool aus Replica 2 und einen aus Replica 3 hast, wie viel Speicherplatz kannst du nun maximal pro Pool belegen? Hier ist dann eben auch wieder der Punkt, wenn im Replica 2 Pool bereits 25 TB belegt sind, dann verbleiben ja noch maximal 75 TB nutzbar, also kann der Replica 3 Pool nicht mehr 33 TB fassen sondern nur noch 25 TB. Genau deshalb sinkt auch die Anzeige des maixmalen Speicherplatzes je Pool.

Mit dem obigen Verfahren erledigt sich dein Beispiel oder? Der Schlüssel ist, nicht die theoretische Speicherkapazität je nach replica zu verwenden, sondern stets mit dem RAW wert zu arbeiten und dann für den jeweiligen Anwendungsfall poolbezogen den verfügbaren Speicher selbst zu ermitteln.
Ist auch im Monitoring erheblich einfacher zu überwachen.

 

[sb-jw]

Egal in welchem Pool ich Daten ablege, die verfügbare Kapazität sinkt bei beiden Pools.

Genau das ist doch aktuell auch bereits vorhanden. Nur mit dem Unterschied, dass die Anzeige genau auf den Pool passt und damit deutlich Aussagekräftiger ist.

In jedem Fall ist es dann egal wie viele Pools und Konstellationen ich auf dem Speicher verwende, es stimmt immer und es ist nachvollziehbar berechenbar.

Und damit ist doch die Anzeige pro Pool (also Teileinheit des Storage) faktisch falsch. Der 5/3 Pool aus deinem Beispiel kann maximal 20 TB belegen, wenn bereits 5 TB drin sind, dürfte es noch maximal 15 TB sein. Ändert man es nun wie von dir gewünscht, würden aus den 15 TB plötzlich 95 TB werden. Also denkt der Kunde, cool kann ich ja noch locker 20 TB rein knallen, dann tut er das und mit jedem TB mehr an Daten reduziert sich der verfügbare Speicherplatz um das 5-fache.
Wie willst du dem Kunden nun erklären, dass seine 20 TB an Daten den kompletten CEPH gerade zum Stillstand gebracht haben, obwohl doch 95 TB frei angezeigt waren? Wie erkläst du dem Kunden nun, dass bei dem Pool A der gesehen Speicherplatz durch 3 geteilt werden muss, während es bei Pool B aber 5 ist und bei Pool C nur noch 2? Wäre es hier nicht cooler, die Berechnung funktioniert genau so wie sie es gerade tut und der Kunde sieht ganz genau, dass in seinen Replica 5 Pool definitiv keine 20 TB mehr rein passen und er versucht es erst gar. Du bekommst damit nicht in der Nacht um 3 Uhr einen Anruf, dass die gesamte Produktion steht und plötzlich die Sonntagszeitung nicht mehr gedruckt werden kann.

Was man hier nicht verhindern kann, ist der Umstand, dass sich die Pools eben gegenseitig den Speicherplatz klauen. Nur weil eben im 5/3 Pool jetzt noch 15 TB passen, müssen diese nicht in 12 Stunden immer noch rein gehen.

Der Schlüssel ist, nicht die theoretische Speicherkapazität je nach replica zu verwenden, sondern stets mit dem RAW wert zu arbeiten und dann für den jeweiligen Anwendungsfall poolbezogen den verfügbaren Speicher selbst zu ermitteln.

Genau das passiert doch schon pro Pool. Deshalb sinkt doch auch die ober Grenze, wenn der CEPH voller wird.

Ist auch im Monitoring erheblich einfacher zu überwachen.

Ich kann leider immer noch nicht nachvollziehen, warum man hier so viel Wert auf die exakte Berechnung der Poolgröße legt. Es spielt doch gar keine Rolle ob Pool A noch 20 TB frei hätte, wenn der CEPH am Limit ist, dann steht in der Regel alles weil typischerweise kein CEPH so groß ist, dass es nicht nicht betroffene OSD bzw. PGs gibt.

Im CEPH betrachtet man die Metrik des freien Gesamtspeicherplatzes (Datacenter -> CEPH), die des einzelnen Pools spielt dabei keine Rolle, weil eben zu variable. Wenn der CEPH bei 85 % ist, dann ist der Cluster Nearfull, ist er bei 95 % ist er bei full und geht in den read-only - das sollte das Ziel sein es zu verhindern. Da kannst du so viel theoretischen freien Speicherplatz in deinen Pools haben wie du willst, wenn auch nur eine OSD bei 95 % ist, ist feierabend im Cluster (mag im Einzelfall nicht stimmen, aber bei 99 % der Cluster dürfte das zutrffen).

Dein Monitoring sollte daher die Verteilung der PGs auf den OSD, den Füllstand der einzelnen OSDs und die Gesamtspeicherauslastung erfassen. Eine ungleichmäßige Verteilung der PGs kann dafür sorgen, dass du in deinen Cluster keine Daten mehr schreiben kannst, obwohl von deinen 100 TB gerade mal 9 TB belegt sind. Für den Gesamtfüllstand des CEPH ist nämlich die derzeit am höchsten ausgelastete OSD verantwortlich. Hat eine OSD in deinem Cluster einen Fullstand von 80 %, dann hat auch dein CEPH einen Füllstand von 80 %. Daher das Monitoring der PGs und des Füllstand.
Wenn die Faktoren Füllstand und PGs damit abgedeckt sind und am besten auch so gelöst sind, dass es optimal verteilt wird, dann ist die Gesamtspeicherauslastung dein entscheidender Faktor, weil dir reicht ja eine Meldung alle 5 Minuten und du brauchst ja nicht 200 Meldungen alle 5 Minuten weil eine OSD das Limit erreicht hat. Zusätzlich kann man auch proaktiv den Schwellwert für den Gesamtfüllstand herabsetzen, so dass man frühzeit reagieren kann.

Natürlich kannst und sollst du die Metriken der Pools weiterhin erfassen, das ist nämlich nötig um bei einem Problem herauszufinden, welcher Pool der Verursacher ist oder frühzeitig zu bemerken, wenn ein Pool aus seinem üblichen Wachstumsmuster aussbricht.
Ich monitore z.B. jeden CEPH Cluster in checkmk mit den Standardplugins, dort nehme ich in der Regel auch alles mit was an geht. Zusätzlich habe ich eigene Checks für den Füllstand der OSDs (Beispiel: "osd #0 Used: 894GiB: Available: 741GiB: Used Percentage: 17.15"), dann überwache ich die SMART Werte und Temperatur jeder OSD / SSD (Beispiel: "Powered on: 4 years 323 days, Power cycles: 37, Uncorrectable errors: 0, Reallocated sectors: 0, Pending sectors: 0, End-to-End errors: 0, CRC errors: 0"), das Wear Level jeder OSD / SSD (Beispiel: "OK - Wear Level 99%") und zu guter letzt ziehe ich sämtliche Metriken mit collectd ab und pumpe es in ein Graphite/Grafana Setup.
Ich arbeite in der Regel immer mit dem Grafana Dashboard und rufe das täglich auf, nur so kann ich sehen wie die Entwicklung des Clusters in den letzten Stunden gewesen ist und bekomme so mit, wenn sich etwas aufgeschaukelt hat.

Insofern noch mal ganz deutlich mein Appell an euch: Vergesst die Auslastung pro Pool, das ist keine sinnvolle Metrik und spielt für CEPH Cluster absolut gar keine Rolle!

Eure Kunden können mit den Berechnungen pro Pool abschätzen und sehen wie viele Daten sie JETZT (nicht in 3 Tagen) da rein schaufeln können. Wenn die einen Alarmschwellwert haben wollen, dann ist der Wert unter "Datacenter -> CEPH" relevant und nicht der des Pools. Alles andere wird einfach zu Erklärungsbedürftig dem Kunden gegenüber, der in der Regel auch von dem komplexen Thema "CEPH" keine Ahnung hat oder haben will oder Ihr ihm auch keine 3 Tages Schulung anbieten wollt

 

[Falk R.]

Noch ein kleiner Tipp: Die Advanced Schulung ist auch super für Kunden geeignet um das Thema zu verstehen.