[SOLVED] Ceph Cluster, hohes IO Wait auf einem Server

Discussion in 'Proxmox VE (Deutsch)' started by Ingo S, May 20, 2019.

  1. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Hallo zusammen

    Unser Ceph verteilt sich auf 4 Server und davon ist ein Server sehr auffällig was IO-Wait angeht. Allein das "Grundrauschen" von Lesen und Schreiben von einigen MB/s durch die VMs, sorgt für ein IO Wait von zwischen 7-12%
    Die anderen Server zeigen kein nennenswertes IO Wait ( <1%)

    Hier mal ein Beispiel:
    upload_2019-5-20_9-34-47.png
    Auf den anderen Servern sieht das anders aus:
    upload_2019-5-20_9-36-56.png

    VM-1 ist ein etwas älterer Server als VM-2, aber auch nur ein paar Jahre, nicht steinalt, die Platten hängen an einem Serial Attached SCSI controller: LSI SAS3408.
    Bei VM-2 hängen die Platten an einem LSI MegaRAID SAS 2208

    Festplatten sind 4 Server a 8 HDDs.
    Die Platten selbst sind 4TB HDDs, SAS und SATA gemischt, was wir grad so da hatten, alle mit 7200rpm. Ceph Journal liegt auf einer Intel Enterprise NVME SSD.

    Ich bin offen für Ideen, rauszufinden was da los ist.
     
  2. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,356
    Likes Received:
    213
    Als erstes vorweg, je gemischter die Hardware im Cluster desto unvorhersehbarer die Performance [1]. Was für Werte ergibt ein 'rados bench'? Den Befehl kann man in unserem Ceph Benchmark Paper finden [2].

    Alleine die CPU der beiden im Bild zu sehenden Nodes macht schon einen Unterschied. Die IO-wait ist in Prozent angegeben und ist die Wartezeit der CPU bis die IO-Anfrage eines Prozesses fertig ist. Im Programm Top sieht man eine kumulierte Gesamtansicht aller Kerne (inkl. Threads). Also im obigen Fall 12 und 48, damit ist also die IO-wait zwischen Systemen nicht vergleichbar.

    Was mir in dem Fall mehr sorgen machen würde, als die IO-wait, ist das fehlende ECC beim i7. Damit kann nicht sichergestellt werden, ob auch die richtigen Bits auf der Platte landen oder nicht. Das erhöht die Wahrscheinlichkeit, dass es öfter Fehlern beim Scrubbing auftauchen und defekte Objekte im Cluster verteilt werden.

    Ich hoffe diese sind im IT-Mode (HBA). RAID Controller sind nicht für den Einsatz von Ceph oder ZFS gemacht und verursachen leider alle möglichen Nebeneffekte [1]. Besser ist die Controller durch reine HBAs ersetzen.

    Je nach Platte kann die tatsächliche Geschwindigkeit (IO/s) variieren und unnötige IO-delays erzeugen [1]. Falls die Platten im RAID sind, dann wird der Controller den Umstand vermutlich maskieren.

    [1] https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition
    [2] https://forum.proxmox.com/threads/proxmox-ve-ceph-benchmark-2018-02.41761/
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Ich hab gerade ein rados bench gemacht, wie in dem Paper:
    Total time run: 60.135760
    Total writes made: 6669
    Write size: 4194304
    Object size: 4194304
    Bandwidth (MB/sec): 443.596
    Stddev Bandwidth: 63.777
    Max bandwidth (MB/sec): 572
    Min bandwidth (MB/sec): 236
    Average IOPS: 110
    Stddev IOPS: 15
    Max IOPS: 143
    Min IOPS: 59
    Average Latency(s): 0.144241
    Stddev Latency(s): 0.149601
    Max latency(s): 1.70906
    Min latency(s): 0.0140576

    Mit nur einem Thread sieht das dann so aus:
    Total time run: 60.078266
    Total writes made: 882
    Write size: 4194304
    Object size: 4194304
    Bandwidth (MB/sec): 58.7234
    Stddev Bandwidth: 13.928
    Max bandwidth (MB/sec): 84
    Min bandwidth (MB/sec): 32
    Average IOPS: 14
    Stddev IOPS: 3
    Max IOPS: 21
    Min IOPS: 8
    Average Latency(s): 0.0681127
    Stddev Latency(s): 0.0641894
    Max latency(s): 0.52501
    Min latency(s): 0.014323

    Ach was ich noch vergessen habe: Das Ceph Netz ist 10Gbit

    Das verstehe ich. Wir haben allerdings noch einen weiteren Server im Cluster der nur 8 Kerne hat. Bei diesem ist die IO Wait zwar auch leicht höher als bei den 48 Kernern, aber bei weitem nicht so sehr.

    Das wäre nicht gut. Ich habe tatsächlich schon den ein oder anderen Scrub Error gesehen. Allerdings hab ich die eher auf eine defekte Platte geschoben, da smartctl auf einer der Platten "pending sector" meldet. Die werde ich kurzfristig tauschen.
    Ich werde aber trotzdem mal sehen ob wir den Server irgendwie los werden können.

    Ja, also die Platten in VM-1 werden durch einen reinen HBA angesteuert, in den anderen Servern waren die Raid Controller schon so drin. Bei der Anschaffung der Server war Ceph noch kein Thema.
    Jedenfalls befinden sich die Platten auf keinem der Server in einem Raid Verbund
    Controller = 0
    Status = Success
    Description = None
    [...]
    Product Name = HBA 9400-8i
    Board Name = HBA 9400-8i
    [...]
    Physical Drives = 8

    PD LIST :
    =======

    -----------------------------------------------------------------------------
    EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp
    -----------------------------------------------------------------------------
    0:0 3 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
    0:1 2 JBOD - 3.638 TB SATA HDD N N 512B WDC WD4002FYYZ-01B7CB0 U
    0:2 7 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
    0:3 5 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
    0:4 1 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
    0:5 4 JBOD - 3.638 TB SAS HDD N N 512B HUS724040ALS640 U
    0:6 6 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
    0:7 8 JBOD - 3.638 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U
    -----------------------------------------------------------------------------
    Controller = 0
    Status = Success
    Description = None

    Product Name = LSI MegaRAID SAS 9271-8i
    [...]
    Host Interface = PCI-E
    Device Interface = SAS-6G
    Drive Groups = 8
    Virtual Drives = 8

    VD LIST :
    =======

    -------------------------------------------------------------
    DG/VD TYPE State Access Consist Cache Cac sCC Size Name
    -------------------------------------------------------------
    0/0 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    1/1 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    2/2 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    3/3 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    4/4 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    5/5 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    6/6 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    7/7 RAID0 Optl RW Yes RAWBC - ON 3.637 TB
    -------------------------------------------------------------

    Cac=CacheCade|Rec=Recovery|OfLn=OffLine|Pdgd=Partially Degraded|Dgrd=Degraded
    Optl=Optimal|RO=Read Only|RW=Read Write|HD=Hidden|TRANS=TransportReady|B=Blocked|
    Consist=Consistent|R=Read Ahead Always|NR=No Read Ahead|WB=WriteBack|
    AWB=Always WriteBack|WT=WriteThrough|C=Cached IO|D=Direct IO|sCC=Scheduled
    Check Consistency

    Physical Drives = 8

    PD LIST :
    =======

    --------------------------------------------------------------------------------
    EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
    --------------------------------------------------------------------------------
    252:0 11 Onln 0 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:1 10 Onln 1 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:2 9 Onln 2 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:3 8 Onln 3 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:4 14 Onln 4 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:5 13 Onln 5 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:6 15 Onln 6 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    252:7 12 Onln 7 3.637 TB SATA HDD N N 512B WDC WD40EFRX-68WT0N0 U -
    --------------------------------------------------------------------------------
    EDIT: Da ist mir der Senden Button ausgerutscht:
    Ich habe schon versucht raus zu finden was es mit diesen Modes auf sich hat und scheinbar kann man den Mode des Controllers auch irgendwie wechseln. Konkrete Informationen dazu habe ich allerdings bisher nicht finden können.
    Der RAID0 Modus der Festplatten ist jedenfalls der Modus in dem die Festplatten als Single Drive funktionieren. Früher gab es mal die Option "Single", aber bei diesen Controllern soll man den RAID0 für Single Drives nehmen.
     
    #3 Ingo S, May 20, 2019
    Last edited: May 20, 2019
  4. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,356
    Likes Received:
    213
    Das kommt auf die Menge der Arbeit an, die eine CPU abarbeitet.

    Kann natürlich auch von defekten Festplatten stammen, aber die Gefahr bleibt. Meist weiß man dann auch nicht ob Daten korrumpiert sind.

    Ein RAID0/JBOD ist auch nicht das wahre, spreche aus eigener Erfahrung. Da sich meist Caches und andere RAID-Optimierungen nicht ausschalten lassen, kann es zu unschönen Nebeneffekten kommen, wie zB. 'stuck/slow requests'.

    Meist geht das mit einem Firmware Update einher. Aber oft schon von der Konstruktionsweise eines RAID Kontrollers, ist dieser nicht mit einem HBA vergleichbar. Besser gleich einen HBA besorgen, dann sind einige Kopfschmerzen von vornherein umgangen.

    Siehe oben und noch einmal der Link für eine detailliertere Hardwarevoraussetzung.
    https://pve.proxmox.com/pve-docs/chapter-pveceph.html#_precondition
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Vielen Dank schonmal für die Hinweise.
    Den VM-1 werden wir dann wohl mittelfristig austauschen.

    Aber um das nochmal etwas klarer zusammen zu fassen:
    Der problematische Server mit hohem IO Wait ist VM-1.
    Auf diesem Server sind die Festplatten via Broadcom HBA 9400-8i angeschlossen. Das ist laut Broadcom ein HBA, kein RAID Controller. Auf den anderen Maschinen z.B. VM-2, wo kein hohes IO Wait zu beobachten ist, sind LSI MegaRaid SAS 9271-8i Controller verbaut.

    Sowohl auf VM-1, als auch auf dem anderen Server mit den 8 Kernen, läuft keine VM, weil die RAM Ausstattung dort nicht so gut ist. Die beiden machen quasi nur Storage für Ceph.

    Bezogen auf die Precondition für Ceph aus den Docs:
    Code:
    DB/WAL auf SSD                                   -> Check
    Balance OSD count / WAL DB Device                -> Check
    gleichmäßige Verteilung von HDDs auf die Server  -> Check
    gleiche HDD Größe                                -> Check
    Für VM-1 gilt ja auch sogar "kein RAID -> Check"

    Die Gesamtperformance ist ja soweit okay, also wenn ich genug Threads aufmache, dann erreiche ich die vollen 10GBits der Netzwerkanbindung und für den gesamten Cluster reicht die Performance auch aus, weil die Performance ja mit der Anzahl der parallelen Zugriffe skaliert.

    Der rados bench zeigt aber eine meiner Meinung nach eher mittelmäßige bis schlechte Performance bei Single Thread Zugriffen. Es ist schon merkwürdig, 32 recht aktuelle flotte Festplatten anzusteuern und dann kommen z.B. beim Datei kopieren Datenraten von 50-70MB/s oder teilweise nur 20MB/s zustande und die IO Wait Time auf VM-1 steigt irre in die Höhe ohne das dieser viel tut.

    Bevor ich aber nun Geld in die Hand nehme, einen neuen Server kaufe, oder neue HBAs bestelle, um die Performance bei einzelnen Schreibvorgängen wie Dateien kopieren, Backups erstellen oder rum schieben etc. zu verbessern, versuche ich irgendwie herauszufinden welche der Möglichkeiten der Bottleneck ist.

    Mit gehen dabei folgende Dinge durch den Kopf:

    - CPU und RAM auf VM-1 ist einfach Mist, insbesondere die CPU hat einfach nicht genug Power. Deshalb entsteht auch bei kleinen Lastspitzen sofort hohes IO Wait.
    Das passt allerdings nicht mit meinem Verständnis von IO Wait überein. Das ist ja lediglich die Wartezeit des CPU bis der Speicher die Anfrage beantwortet hat. Wenn die CPU sonst keine Aufgaben hat ergibt das für mich aber irgendwie wenig Sinn wie das mit der Anzahl der Kerne und der Taktrate zusammen hängen sollte. 10% IO Wait bedeutet ja lediglich das die CPU pro Sekunde etwa 100ms auf IO wartet.

    - Die RAID Controller maskieren das IO Wait auf den beiden dicken Servern und die Performance leidet in Wirklichkeit gar nicht unter dem "hohen" IO Wait auf VM-1 sondern darunter, dass die RAID Controller auf den beiden dicken Servern irgendwas wildes machen.

    Ich habe mit rados bench ein paar Versuche gemacht und folgendes zeichnet sich ab:

    kleine Blocksize (4k) & wenig Threads (1) -> sehr geringe Performance (um 1MB/s), kaum erhöhtes IO Wait auf VM-1
    große Blocksize (16M) & wenig Threads (1) -> eher geringe Performance (um 100MB/s), leicht erhöhtes IO Wait auf VM-1
    kleine Blocksize (4k) & viele Threads (128) -> sehr geringe Performance (12MB/s), stark erhöhtes IO Wait auf VM-1 (35-40%)
    große Blocksize (16M) & viele Threads (128) -> mittelmäßige Performance (300-450MB/s), leicht erhöhtes IO Wait auf VM-1

    In allen Fällen war IO Wait auf den großen Servern VM-2 und 3 fast unverändert. man sieht nur einen leichten Buckel
    upload_2019-5-20_15-35-37.png
    upload_2019-5-20_15-36-12.png
     
  6. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,356
    Likes Received:
    213
    Das betrifft aber alle an Ceph beteiligten Nodes. ;)

    Der 'rados bench' macht im Hintergrund auch nix anders, als ein fio und bei einem thread, kann auch nur immer eine OSD (primary) angesprochen werden. Diese wiederum schreibt die Daten erst auf die sekundäre und tertiäre OSD, bevor das ACK an den Client zurück kommt. Darum sind's beim 'rados bench' auch 16 threads standard, das ein besseres Bild liefert, zwecks Parallelität.

    Die IO-wait wird von der Summe der Tasks auf den Cores berechnet. Ist die CPU nur 10% Ausgelastet, dann wird die IO-wait von dem 10% gerechnet. Damit ensteht das Bild, das die CPU nix tut, aber ewig auf IO gewartet werden muss. Es gilt dabei jegliche IO, meist fällt es jedoch auf, wenn die IO auf die Platten geht.

    Genau. Da der VM-1 einen HBA hat, kommt (oder geht) jede IO auch direkt von den Platten. Bei den RAID-Controllern wird die IO schon dort terminiert und dann ist es dem Controller überlassen, was er mit den Daten macht. Das System bekommt davon auch nichts mit.

    Auch wenn die Performance mit den Controllern besser ist, oft sieht man erst im Ernstfall, ob alles da ist. Und meist ist auch mehr Arbeit nötig, da noch ein RAID0/JBOD konfiguriert werden muss, zudem oben drauf noch die OSD kommt.

    Je kleiner die Blockzise, desto mehr Pakete müssen über das Netzwerk geschrieben/gelesen werden. Daher arbeitet RBD mit 4 MiB Objekten, da es sich bei VM/CT als ein guter Kompromiss durchgesetzt hat. Aber bei der Objektgröße kommt es auf den Anwendungsfall darauf an, große Daten, wie Videos haben sicherlich einen Vorteil mit größeren Objekten.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Ah okay, das hat jetzt vieles klarer gemacht. Vielen Dank
    Die Performance unseres Ceph ist also im groben im normalen Bereich, wenn ich das richtig deute.

    Zwei Dinge noch:
    Auf den RAID Controllern ist Caching aktiviert. Wenn ich das jetzt richtig interpretiere, müsste das tatsächliche IO Wait zutage treten, wenn ich dem Controller sage, er soll direct IO machen.

    Und: Ich habe ja als Cache/WAL/DB eine NVME SSD. Die nimmt doch bei den Writes als erstes die Daten auf, bevor die nach einer Zeit oder einer Menge X dann auf die Festplatte geschrieben werden. Kommt das ACK also nicht, wenn die Daten sicher auf der SSD liegen sondern tatsächlich erst, wenn die HDD die Daten von dort sicher übernommen hat?
    Entweder habe ich da einen Denkfehler, oder dieses Verhalten macht die SSD als Cache irgendwie etwas überflüssig. Dann könnte ich doch gleich die Daten direkt auf die HDD schreiben und nur die Metadaten auf ne kleine SSD laufen lassen.
     
  8. sb-jw

    sb-jw Active Member

    Joined:
    Jan 23, 2018
    Messages:
    551
    Likes Received:
    49
    Wie kommst du darauf? Der muss in dem Falle vom Cache Device kommen, dafür ist das ja da und ja, dann würde das Device ja auch keinen Sinn mehr machen - dann würdest du schneller direkt auf die Platte schreiben.

    http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/

    Aktuell sind die SSD Preise aber so dermaßen im Keller, dass es sich vielleicht lohnt auf Flash Only umzusteigen? Dann nimmst du deinem Cluster ein bisschen komplexität und mehrere SPOFs raus, zusätzlich gibt es mehr Performance. Das geht natürlich nur, wenn du nicht so den Speicherplatz benötigst.

    Was ich mit SPOF meine?
    Du hast ein Drive als Cache für all deine Spinner pro Server, fällt das Caching Device aus ist dein Node komplett raus. Sehr kritisch wird das übrigens, wenn du alle Nodes mehr oder minder zeitgleich mit dem Caching Device ausgestattet hast. Die Wahrscheinlichkeit, dass alle Caching Devices zeitgleich oder in kurzen Abständen sterben ist da sehr hoch. Fällt die erste aus und es kommt Action ins Cluster, könnte das auch das Todesurteil für eine weitere sein. Habe ich auch bereits im produktiven Betrieb miterleben dürfen...
     
  9. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Also, wenn ich einen Single Thread Schreibvorgang starte und das WAL Device diesen zuerst cached, dann müsste ich im Benchmark zu Beginn des Tests die Schreibgeschwindigkeit des WAL sehen wenn der Schreibvorgang schon auf dem WAL terminiert wird. Das ist bei uns eine Intel Optane P4800X PCIe pro Server. Da ich aber direkt von Beginn des Benchmarks an lediglich Geschwindigkeiten sehe, die etwa der einer HDD entsprechen, habe ich mich gefragt warum das so ist. Im schlimmsten Fall haben wir hier noch einen Konfigurationsfehler und ich denke nur, das das WAL auf der SSD liegt...o_O:eek:

    Ich hatte auch schon darüber nachgedacht, aber wir haben zur Zeit ca 106TB, 32x 4TB im Einsatz und da auf SSDs umzusteigen sprengt echt unser IT Budget.
    Evtl könnte ich defekte HDDs nach und nach mit SSDs ersetzen.

    Ja, das ist mir leider bewusst. Ich weiß allerdings keine gute Lösung die bei uns im Moment finanztechnisch tragbar ist.
    Wir sichern allerdings täglich auf Band und auf anderen Medien und könnten im Katastrophenfall sämtliche Maschinen wiederherstellen. Außerdem haben wir ein Desaster-System auf dem wir die wichtigsten Maschinen in Betrieb nehmen können, für den Fall das der Cluster nicht mehr OK ist.
     
  10. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,356
    Likes Received:
    213
    Das WAL und die DB haben für den Datenteil des Objektes keine direkte Cache-Funktion. Große Schreibvorgänge, zB. 4 MiB, werden direkt auf die HDD geschrieben. Das WAL (write-ahead-log) kann zwar kleinere Schreibvorgänge (bluestore_prefer_deferred_size_hdd) aufnehmen, per default ist das 32 KiB, ist aber nicht direkt ein cache. Hier kann natürlich getuned werden, a die P4800 schon einiges an IO ab kann. Wichtig ist aber das die Partition für die DB gross genug ist, sollte sie zu klein sein, wird der Überlauf wieder auf die HDD geschrieben.

    Es könnte auch sinn machen, mit unterschiedlichen Pools zu fahren, einen für die Daten und einen für IO-Performance. Ceph hat dazu die 'Device class' eingeführt, damit das Handling der OSDs einfacher wird.
    https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_device_classes
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Ah okay, so ergibt das mehr Sinn.

    Also anscheinend verhält sich unser Ceph so wie er gerade ist, ganz normal. Gut, das ist zumindest etwas beruhigend.
    Ich werde dann für die Zukunft einen Plan erstellen müssen, wie wir unseren Cluster so erweitern/umbauen, dass das alles etwas mehr flutscht.
    Das lässt sich wahrscheinlich wirklich am ehesten über einen "fast pool" aus SSDs realisieren.

    Mit 4 Ceph Nodes befinden wir uns ja auch ziemlich am unteren Rand der Skala, wo Ceph Sinnvoll ist.

    Thx für die Meinungen und Einsichten.
     
  12. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    2,356
    Likes Received:
    213
    Bitte dann mit einem HBA aufbauen.

    Den Sinn hats ja bereits (ab 3), shared storage. ;)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. Ingo S

    Ingo S Member
    Proxmox Subscriber

    Joined:
    Oct 16, 2016
    Messages:
    92
    Likes Received:
    2
    Das sehe ich auch so. Habe bereits angedeutet das wir am Cluster in Zukunft noch etwas umbauen müssen.

    Im Grunde ja, aber bedenkt man die niedrigen Datenraten die man bei Single Threaded Writes mit Ceph erreicht, ist man bei kleinen Systemen manchmal mit einem guten NAS und nem RAID6 oder RAID10 besser bedient, das man dann per NFS o.ä. anspricht.
    Man verliert zwar etwas Ausfallsicherheit und Flexibilität, gewinnt aber sehr viel Performance.
    Je größer der Cluster wird, desto besser skaliert Ceph und spielt dann seine Stärken aus.
     
    Alwin likes this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice