[SOLVED] Ceph Performance Probleme

[Ingo S]

Hallo alle miteinander

Wir haben einen Proxmox Cluster mit 8 Nodes, wo auf 4 davon Ceph läuft. Als wir das neu zusammengestellt hatten, hatten wir pro Server jeweils 7 OSDs aus 4TB großen HDDs mit einer SSD als Journal.
Damals war die Performance ziemlich gut. Wir nutzen den Ceph Backend hauptsächlich als Speicher für die vHDDs der VMs, aber wir haben auch einen virtualisierten storage Server (FreeNAS) der seine Daten im Ceph ablegt.
Die Server haben für Ceph einen 10GBit Ethernet Link und die Datenraten lagen für Filetransfers bei mehreren hundert MB/s.
Vor einiger Zeit kam dann Bluestore und ich habe den Ceph Cluster umgebaut gehabt, einen reinen HDD Pool für die vHDDs der Server und einen SSD Pool für vHDDs auf denen Datenbanken liegen und wo man sonst noch viele IOps braucht.
Das hat sich nach kurzer Zeit aber als Performance Albtraum entpuppt. Beim Kopieren eines DB Backups von vll 2GB größe von einer VM zu einer anderen, hatte ich Datenraten von teilweise unter 1MB/s, meistens zwischen 1-5MB/s. Ich hab dann auf einer VM mal ein wenig Benchmarking betrieben und festgestellt, das ich bei Single Thread Sequential Writes tatsächlich nur auf wenige MB/s komme. Je mehr parallele Write Threads ich erstelle, desto besser wird die Performance jedoch.

Im Moment baue ich den Cluster langsam wieder um, 7 HDDs als OSD mit einer SSD als Journal. Dennoch ist die Performance sehr mies.
Beim stöbern bin ich über den Test von Sebastien Han gestolpert (http://www.sebastien-han.fr/blog/20...-if-your-ssd-is-suitable-as-a-journal-device/) und in seiner Liste sind die Samsung 850 Pro, die wir als Journal verwenden, mit nur 1-2MB/s angegeben.
Was ich nicht verstehe ist: Warum sind die SSDs in dem Test so super langsam? Immerhin sind die SSDs an einem normalen SATA Controller in der Lage ca 550MB/s zu liefern und ca 90k IOPS. Was bremst die so aus?

In den Servern steckt ein LSI HBA 9400 8i. Hat das vielleicht mit TRIM zu tun?

Ich würde die Performance gerne wieder verbessern. Vermutlich muss ich dafür neue SSDs als Journal kaufen, aber bevor ich 5000-10.000€ in neuen SSDs versenke, möchte ich gerne eure Erfahrungen dazu hören, und vll den ein oder anderen Tip wie ich das Testen kann oder worauf ich achten muss.
Ich möchte rausfinden ob es wirklich an den SSDs liegt oder ob wir noch woanders einen Bottleneck haben.

 

[wolfgang]

Hallo,

Was bremst die so aus?

Es liegt hauptsächlich an der nicht vorhanden power protection ;-)

SSD und speziell NVMe leben von Parallelität. Ein einzelne NAND ist immer sehr langsam.
Deswegen haben SSD Controller in der Regel min 8 Kanäle. Um diese auch auszunutzen haben alle SSD extrem große Caches min 512MB. Das Problem ist nun wenn du sync und direct machst (So arbeitet ceph als journal und WALDB) wird der Cache de-facto ausgeschalten was darin endet du nicht alle Kanäle nutzt weil nicht genug Daten da sind.\

Teure Enterprise SSD haben sozusagen eine BBU für den SSD internen Cache, sie verwenden ihn weiter und ignorieren die Anweisungen vom OS weil Sie sicherstellen können das die Daten im Cache immer auf die NAND geschrieben werden.

Die test die Samsung und Co angeben ist immer mit Cache und ohne sync.

Generell ist es auch nicht empfohlen 7 OSD auf eine SSD. Ceph empfiehlt max 4 OSD pro Enterprise SSD.
Die Intel DC P3700 NVMe kann bis 12 OSD unterstützen.

 

[Ingo S]

Hallo,


Es liegt hauptsächlich an der nicht vorhanden power protection ;-)

SSD und speziell NVMe leben von Parallelität. Ein einzelne NAND ist immer sehr langsam.
Deswegen haben SSD Controller in der Regel min 8 Kanäle. Um diese auch auszunutzen haben alle SSD extrem große Caches min 512MB. Das Problem ist nun wenn du sync und direct machst (So arbeitet ceph als journal und WALDB) wird der Cache de-facto ausgeschalten was darin endet du nicht alle Kanäle nutzt weil nicht genug Daten da sind.\

Okay, das scheint mir eine plausible Erklärung zu sein. Meine Befürchtung war, das es irgendwo ein Problem im Zusammenspiel zwischen HBA und SSD ist. Wir hatten mal eine Reihe RAID Controller die mit HDDs super funktionierten, aber eine daran angeschlossene SSD, auch als single Drive war mörderisch langsam.
Dann ist es also kein TRIM Problem, sondern tatsächlich das Cache und schreibverhalten der SSDs? Das ist gut zu wissen!

Teure Enterprise SSD haben sozusagen eine BBU für den SSD internen Cache, sie verwenden ihn weiter und ignorieren die Anweisungen vom OS weil Sie sicherstellen können das die Daten im Cache immer auf die NAND geschrieben werden.

Generell ist es auch nicht empfohlen 7 OSD auf eine SSD. Ceph empfiehlt max 4 OSD pro Enterprise SSD.
Die Intel DC P3700 NVMe kann bis 12 OSD unterstützen.

Ich würde dann tatsächlich die Intel DC P3700 NVMe ins Auge fassen. Da hatte ich schon mal nach geguckt. Die Server haben 8 Drive Slots, ich würde dann 7 OSDs mit dem SSD Journal versorgen. Das erscheint mir praktikabel.

Was mir jetzt noch im Kopf herum spukt ist: Wenn das SSD Journal ausfällt, fällt mir 1/4 der Ceph Nodes aus. Ich kann aber doch einfach die SSD ersetzen, und den OSDs das neue Journal zuweisen. Oder muss ich die OSDs ins Nirvana schicken und das Ceph komplett durch den Rebuild laufen lassen? Ich hab damit noch keine Erfahrung weil uns noch nie ein Journal gestorben ist.
Kurz: Wie geht man vor wenn ein Journal mal sterben sollte?

vielen Dank für die echt flotte kompetente Aussage

 

[wolfgang]

Wir hatten mal eine Reihe RAID Controller die mit HDDs super funktionierten, aber eine daran angeschlossene SSD, auch als single Drive war mörderisch langsam.

Das ist das gleiche Problem.
Raidkarten die nicht SSD aware sind versuchen auch sync, direct zu schreiben um Datenverlust zu vermeiden.

Dann ist es also kein TRIM Problem, sondern tatsächlich das Cache und schreibverhalten der SSDs?

Trim ist heute bei fast keinen SSD mehr ein Thema, darum kümmern sich die Controller zuverlässig.

Ich würde dann tatsächlich die Intel DC P3700 NVMe ins Auge fassen.

Wenn du die Intel DC P3700 nicht mehr bekommst ist eigentlich EOL kannst du den Nachfolger Intel DC P4800X nehmen.

Kurz: Wie geht man vor wenn ein Journal mal sterben sollte?

Hängt vom Setup ab. Aber ja du kannst das Journal/WALDB austauschen ohne die OSD neu zu machen.

 

[Ingo S]

Ach super, das zeigt mal wieder, man lernt nie aus.

Eine Sache noch:
Als Journal würde bei dieser Konfiguration ja schon eine 128GB SSD reichen und die DC P4800X sowie die 3700 sind enorm teuer. Was ist mit den Intel Optane 900P? Die werden auch unter "Enterprise" geführt. Am Preis scheint sich aber zu zeigen das die sich vermutlich auch wie Consumer SSDs verhalten. Gibts dazu Erfahrung?

vielen Dank schonmal für die Hilfe

 

[tom]

Ach super, das zeigt mal wieder, man lernt nie aus.

Eine Sache noch:
Als Journal würde bei dieser Konfiguration ja schon eine 128GB SSD reichen und die DC P4800X sowie die 3700 sind enorm teuer. Was ist mit den Intel Optane 900P? Die werden auch unter "Enterprise" geführt. ..

Nein, wenn du die "billigen" Intel Optanes in Server verwendest, gibts keine Garantie.

Auszug aus dem Datasheet:
"Warranty 5-year limited warranty; warranty void if used in a multi-user, multi-CPU data center environment"

Wenn Performance nötig ist, warum nicht einen SSD Only Ceph Cluster? Zumindest einen "SSD only" Pool.

Z.b. mit Samsung SM863a SATA SSDs

 

[Ingo S]

Nein, wenn du die "billigen" Intel Optanes in Server verwendest, gibts keine Garantie.

Auszug aus dem Datasheet:
"Warranty 5-year limited warranty; warranty void if used in a multi-user, multi-CPU data center environment"

Uff das hatte ich ganz übersehen. Danke für den Hinweis.

Wenn Performance nötig ist, warum nicht einen SSD Only Ceph Cluster? Zumindest einen "SSD only" Pool.

Z.b. mit Samsung SM863a SATA SSDs

Hmm das hatte ich ja schonmal angedacht. Aufgrund der miesen Journal Performance mit den Consumer SSDs war ich davon aber schon wieder abgekommen.
Wir haben nicht so unglaublich hohe Performance Anforderungen, was den Betrieb angeht. Sogar auf diesem ziemlich lahmen Setup läuft es halbwegs okay, alle Anwendungen reagieren flott genug auf Anfragen ihrer Nutzer.

Das eigentliche Problem sind die extremen Einbrüche, wenn Ceph beginnt irgendwelche Objekte neu zu strukturieren weil z.B. eine HDD ausgefallen ist, oder weil man die weight einer OSD anpasst. Sofort lahmt der ganze Cluster und IO Wait geht stark nach oben. Grund ist halt die miese Journal Performance.
Wenn wir die Performance wieder auf ein für HDDs mit SSD Journal typisches Niveau heben könnten, denke ich sollte das Ceph dann auch performancemäßig wieder robust gegen Ausfälle und Restrukturierungen sein. Und wir müssen nicht mehr 10min warten bis ein 5GB großes DB Backup kopiert ist

 

[udo]

...
Hängt vom Setup ab. Aber ja du kannst das Journal/WALDB austauschen ohne die OSD neu zu machen.

Hallo Wolfgang,
seit wann funktioniert das? Mein Stand war, dass ein normales Filestore-Journal austauschbar ist (hundert mal gemacht), aber bei Bluestore die gesamte OSD neu initialisiert werden muss.

Nach diesem Link zu urteilen: http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-November/022567.html funktioniert es, weil proxmox Partitions anlegt?!

Das heisst, wenn man eine OSD mit Proxmox als Bluestore initialisiert hat,kann man auf jeden Fall das Journal/WalDB hinterher verschieben?

Viele Grüße

Udo

 

[Ingo S]

Also mit Bluestore erscheint mir ein Journal Austausch reichlich kompliziert und fragil. Ich mache mir eher wenig Sorgen, das die P4800X irgendwann kaputt geschrieben ist, immerhin verträgt sie 30 DWPD.

Trotzdem kann sich so eine SSD ja auch einfach so mal spontan verabschieden. Das würde bedeuten das der ganze Server ausfällt, bzw alle OSDs auf dem Server. Da wir eine Poolsize von 3/2 fahren, mache ich mir eigentlich keine Sorgen, das in so einem Fall ein Datenverlust auftritt. Aber 1/4 aller OSDs in den Backfill jagen ist schon ne Hausnummer.
Ich würde den Ceph Cluster eigentlich gerne erweitern auf 6 Nodes, aber das ist natürlich auch eine Kostenfrage.

Ich hoffe es wird in nicht all zu ferner Zukunft ein Tool oder einen Prozess geben mit dem man Bluestore Journal Disks zuverlässig, schnell und sicher tauschen kann.
Wäre es bis dahin vielleicht Sinnvoll erst noch bei Filestore zu bleiben?

 

[tom]

Also mit Bluestore erscheint mir ein Journal Austausch reichlich kompliziert und fragil. Ich mache mir eher wenig Sorgen, das die P4800X irgendwann kaputt geschrieben ist, immerhin verträgt sie 30 DWPD.

Trotzdem kann sich so eine SSD ja auch einfach so mal spontan verabschieden. Das würde bedeuten das der ganze Server ausfällt, bzw alle OSDs auf dem Server. Da wir eine Poolsize von 3/2 fahren, mache ich mir eigentlich keine Sorgen, das in so einem Fall ein Datenverlust auftritt. Aber 1/4 aller OSDs in den Backfill jagen ist schon ne Hausnummer.
Ich würde den Ceph Cluster eigentlich gerne erweitern auf 6 Nodes, aber das ist natürlich auch eine Kostenfrage.

Ich hoffe es wird in nicht all zu ferner Zukunft ein Tool oder einen Prozess geben mit dem man Bluestore Journal Disks zuverlässig, schnell und sicher tauschen kann.
Wäre es bis dahin vielleicht Sinnvoll erst noch bei Filestore zu bleiben?

Extra SSDs für Journals haben für mich zu viele Nachteile, wenn die defekt wird hast zu 99 % ein grösseres Problem (alle OSD weg und daher viel rebalance traffic). Und darum empfehle ich für kleine/mini Cluster SSDs für die OSD zu nehmen (und somit auch keine extra journals SSDs).

Wie bereits erwähnt, sie Samsung SM863a SSD sind eine gute Wahl (Preis/Leistung).
Hier nochmal der Link zu unserem Ceph Benchmark PDF

 

[Ingo S]

@tom Da stimme ich dir zu. Ich habe mir den Benchmark angesehen, das sieht ziemlich gut aus mit den SSDs.
Die Sache hat den Haken das unser Cluster schon voll mit HDDs ausgestattet ist und etwa 80TB Kapazität hat, die wir auch zu einem guten Teil nutzen. Wenn wir da jetzt auf die 2TB SSDs wechseln, bräuchten wir für die gleiche Kapazität weitere Server UND wir müssten alle Laufwerke austauschen. Unter diesen Umständen würde eine Umrüstung des Clusters eine Größenordnung mehr kosten als jetzt 4 gute Enterprise Journal SSDs anzuschaffen.
Wenn ich den gesamten Cluster neu Planen und zusammenstellen würde, würde ich deiner Empfehlung auf jeden Fall folgen. Im Moment steht ein solches Budget aber leider nicht zur Verfügung. Wir werden also wohl mit dem Risiko erstmal auskommen müssen, das uns mal ein Server voller OSDs weg fliegen.
Mittelfristig würde ich aus diesem Grund den Cluster mit anderen Servern, die wir wegen der fortschreitenden Virtualisierung bei uns Hardwaremäßig frei bekommen, auf 5 oder gar 7 Nodes erweitern. Das würde die Auswirkungen eines rebalance meiner Erfahrung mit Ceph nach durchaus deutlich abmildern; besonders wenn der Cluster wieder seine normale Performance erreicht.

Zur Zeit dauert der Backfill einer einzigen 4TB OSD etwa 16-24h

 

[Alwin]

Mehr Nodes verbessern natürlich die Verteilung der Objekte und reduzieren die Last auf den bestehenden Nodes. Aber generell kann man sagen, dass eine gewissen Anzahl an IO/s immer das selbe kostet, egal ob viele Spinner oder schnelle NVMe. Wie @tom empfohlen hat, vielleicht macht es Sinn, zwei Pools - mit SSD und HDD einzusetzen.

 

[wolfgang]

Ich muss da 2 Sachen richtigstellen.
Erstens meinte ich natürlich WAL und nicht WALDB.
Die WAL ist anscheinend wirklich nicht so leicht zu änder, hatte im Hinterkopf das es wenn man sie referenziert hat es möglich ist.
Was aber anscheinend nur funktioniert wenn die UUID gleich sind.

Also un das noch mal richtig zustellen in den meisten Setups (default PVE) ist eine neu anlegen der OSD notwendig.

Aber selbst wenn du das könntest hättest du in der Zeit bis zum austauschen 7 OSD down, was eh zu einem Daten diff führt.

 

[Ingo S]

Ich muss da 2 Sachen richtigstellen.
Erstens meinte ich natürlich WAL und nicht WALDB.
Die WAL ist anscheinend wirklich nicht so leicht zu änder, hatte im Hinterkopf das es wenn man sie referenziert hat es möglich ist.
Was aber anscheinend nur funktioniert wenn die UUID gleich sind.

Also un das noch mal richtig zustellen in den meisten Setups (default PVE) ist eine neu anlegen der OSD notwendig.

Aber selbst wenn du das könntest hättest du in der Zeit bis zum austauschen 7 OSD down, was eh zu einem Daten diff führt.

Okay, dann hab ich das richtig interpretiert. Daraus folgt für mich folgende Vorgehensweise:

• Aus Kostengründen SSD journaling mit Intel DC P4800X statt Umstellung auf komplett SSD
  
• getrennte Pools sind mir auch nicht so lieb, kommt vielleicht mal in Frage, wenn wir für spezielles wirklich viele IO/s brauchen
• Alle OSDs werden von Bluestore auf Filestore gewechselt (wir haben eh teilweise noch Filestore im Einsatz)
• Bei Umstellung auf die neuen SSDs werde ich nach und nach jeden Server per reweight leer räumen und die OSDs neu aufbauen

Wenn ich das nämlich richtig sehe, lässt sich das Journal bei Filestore umziehen. Das Risiko das mir ein Server wegen eines defekten journal-dev weg fliegt werden wir erstmal eingehen. Wir müssen dann die backfilling optionen so einstellen, das der Cluster im Fall der Fälle benutzbar bleibt.
Evtl kann man auch die Zeit, bis die OSDs von down auf out gehen verlängern, so dass man Zeit hat, einfach das Journal zu tauschen und die OSDs rechtzeitig wieder Online zu bringen. Dann entfällt ein Großteil des Backfill.

Für sowas muss ich mir mal einen virtuellen Test-Cluster bauen und die verschiedenen Situationen durchspielen und Dokumentieren.
Ich stelle jedenfalls immer wieder fest, das Ceph im Produktivbetrieb eine Menge Know How erfordert.

 

[udo]

Okay, dann hab ich das richtig interpretiert. Daraus folgt für mich folgende Vorgehensweise:

• Alle OSDs werden von Bluestore auf Filestore gewechselt (wir haben eh teilweise noch Filestore im Einsatz)

Hi Ingo,
das würde ich persönlich, aus Performancegründen, nicht machen.
Gerade mit HDDs gewinnst Du durch Bluestore und den Gewinn hast Du ständig. Eine Beeinträchtigung durch ein komplett-Backfill hast Du nur beim Ausfall einer Journal-SSD - was nicht wirklich wahrscheinlich ist.

Bei meinen ehemaligen Arbeitgeber hatten wir ein Ceph-Cluster mit damals 8 Nodes und 96 OSDs (4TB) und DC-S3700 als Journal-SSD.
OSDs sind immer mal ausgefallen, aber die Journal-SSDs halten (monitoring vom weareout ist wichtig). Und der Cluster ist mehrfach rebalanced worden - unter anderem alle OSDs von ext4 auf XFS umgestellt.
Von daher würde ich das Risiko nicht zu hoch einschätzen und es gibt ja auch Stellschrauben, um eine (übermässig) Beeinträchtigung vom Backfill zu vermeiden.
Es wurde z.B. bei einem Ausfall einer Node durch das Monitoring automatisch "noout" gesetzt, damit, falls eine Node sich Abends weghängt, die Daten nicht 8 Stunden verschoben werden und nach einem Reset am Morgen alles wieder zurückgeschoben werden muss (wenn eine Node mit sowviel Daten ausfällt, macht es Sinn dass jemand drauf guckt, bevor die Automatik losläuft - jedenfalls in dem setup).

Udo

 

[Ingo S]

@udo
Hmm ich halte die Wahrscheinlichkeit tatsächlich auch für recht gering. Wenn du sagst, Bluestore ist besser für die Performance, dann lasse ich das auf Bluestore laufen

Ich habe auch ein Script gebaut, das regelmäßig prüft ob zu viele OSDs ausgefallen sind (z.B. wenn die SSD ausfallen sollte) und in dem Fall dann das noout setzt. Auf die Art können wir dann ganz besonnen an die Sache ran gehen.

Danke für die Anregungen und Hilfestellungen.

 

[Alwin]

Ich habe auch ein Script gebaut, das regelmäßig prüft ob zu viele OSDs ausgefallen sind (z.B. wenn die SSD ausfallen sollte) und in dem Fall dann das noout setzt. Auf die Art können wir dann ganz besonnen an die Sache ran gehen.

Das entzieht dem Ceph aber seine Selbstheilung, wenn ein Host ausgefallen ist (oder alle OSDs davon).

 

[Ingo S]

Das entzieht dem Ceph aber seine Selbstheilung, wenn ein Host ausgefallen ist (oder alle OSDs davon).

Ja, das ist mir bekannt. Über das Monitoring erhalten wir aber eine Meldung, das da was passiert ist, so dass wir in so einem Fall zeitnah eingreifen. Wir wollen nur etwas Zeit, um zu entscheiden was zu tun ist, z.B. wenn das morgens um 4 passiert.
Der Ausfall einzelner Platten bleibt davon ja unberührt.

 

[udo]

Das entzieht dem Ceph aber seine Selbstheilung, wenn ein Host ausgefallen ist (oder alle OSDs davon).

Hi Alwin,
das ist schon klar, aber wenn man z.B.Host mit 12 4TB OSD hat (70% gefüllt), wären 30 TB an Daten auf die verbleibenen Hosts zu verteilen.
Da ist es mit Selbstheilung schon zeitlich gesehen schwierig, zumal die anderen OSDs ja auch bereits mit 70% gefüllt sind. Dass heisst, nach X Stunden bekommt man die nächsten Probleme, weil eine OSD voll ist... (und dann geht gar nichts mehr)
Zeitlich macht es da normaler mehr Sinn, die defekte Node wieder an den Start zu bringen und wenn Recovery, dann begleitet (weitere OSDs?).

Aber dies ist natürlich stark abhängig von dem Setup.

Udo

 

[Alwin]

das ist schon klar, aber wenn man z.B.Host mit 12 4TB OSD hat (70% gefüllt), wären 30 TB an Daten auf die verbleibenen Hosts zu verteilen.

Das ist natürlich der Tot eines Ceph Clusters, bei 4 Nodes muss die Füllrate unter 70% liegen.

Zeitlich macht es da normaler mehr Sinn, die defekte Node wieder an den Start zu bringen und wenn Recovery, dann begleitet (weitere OSDs?).

Ich sehe da die Problematik, dass das Script nicht die Fehler-Domains mit einbezieht. Um seine Daten hoch-verfügbar zu haben, sollte eine Selbstheilung immer Möglich sein. Auch wenn Ceph in einem 'degraded state' funktioniert, daher mein generelle Warnung.

Ein wahrscheinlich bessere Variante wäre Ceph selbst das 'noout' überlassen.

mon osd down out subtree limit

Description: The smallest CRUSH unit type that Ceph will not automatically mark out. For instance, if set to host and if all OSDs of a host are down, Ceph will not automatically mark out these OSDs.
Type: String
Default: rack

http://docs.ceph.com/docs/luminous/rados/configuration/mon-osd-interaction/