Ceph OSD Crashed

C

Christian95

Member
Sep 7, 2018
15
0
21
28
Hallo,

in der Nacht ist eine OSD meines Ceph Clusters komplett "abgeraucht" und ließ sich nicht mehr ansteuern.
Nun habe ich das Problem, dass ich 3pgs inactive und 7pgs incomplete habe.
Diese PGs blockieren aktuell jegliche IO im Cluster, alle VMs sind somit down.

Was kann ich nun tun?

Output wenn ich eine der inactive PGs abfrage: https://hastebin.com/kofuxagive.yaml
 
Komplett abgeraucht heißt, die Disk ist tot?

Wie war der Cluster konfiguriert, wenn der Ausfall einer OSD zu inactive und vor allem incomplete PGs führt?

Ein ceph -s, ceph osd df tree und pveceph pool ls --output-format json-pretty wäre interessant.
 
Hallo Aaron,

der Ceph Pool ist mit 2/1 konfiguriert, lief auch seit mehreren Jahren problemlos durch, das wurde mir damals von mehreren Kollegen empfohlen, eine einzelne NVMe ist ja eigentlich schnell synchronisiert.

ceph -s:
Code: 
  cluster:
    id:     3f123408-3bcb-45d4-8ecf-2e49f329ddf0
    health: HEALTH_WARN
            Reduced data availability: 7 pgs inactive, 7 pgs incomplete
            2 daemons have recently crashed
 
  services:
    mon: xxx
    mgr: xxx(active, since 119m), standbys: xxx, xxx
    osd: 41 osds: 40 up (since 112m), 38 in (since 2h); 26 remapped pgs
 
  data:
    pools:   1 pools, 2048 pgs
    objects: 11.83M objects, 42 TiB
    usage:   78 TiB used, 59 TiB / 137 TiB avail
    pgs:     0.342% pgs not active
             117375/23660008 objects misplaced (0.496%)
             2012 active+clean
             23   active+remapped+backfill_wait
             7    incomplete
             3    active+remapped+backfilling
             2    active+clean+remapped
             1    active+clean+scrubbing+deep
 
  io:
    client:   73 MiB/s rd, 12 MiB/s wr, 1.74k op/s rd, 961 op/s wr
    recovery: 682 MiB/s, 1 keys/s, 200 objects/s

ceph osd df tree:
Code: 
ID  CLASS WEIGHT    REWEIGHT SIZE    RAW USE DATA    OMAP    META    AVAIL   %USE  VAR  PGS STATUS TYPE NAME         
 -1       142.46094        - 137 TiB  78 TiB  78 TiB 6.8 MiB 205 GiB  59 TiB 56.81 1.00   -        root default       
 -7         3.49309        - 3.5 TiB 2.0 TiB 2.0 TiB  91 KiB 5.5 GiB 1.5 TiB 56.51 0.99   -            host cebu0019 
  4   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB  91 KiB 5.5 GiB 1.5 TiB 56.51 0.99 103     up         osd.4     
-55        13.97260        -  14 TiB 8.0 TiB 8.0 TiB 306 KiB  18 GiB 6.0 TiB 57.38 1.01   -            host dsh1233   
 39   ssd   6.98630  1.00000 7.0 TiB 4.0 TiB 4.0 TiB 155 KiB 9.1 GiB 3.0 TiB 57.56 1.01 213     up         osd.39     
 41   ssd   6.98630  1.00000 7.0 TiB 4.0 TiB 4.0 TiB 151 KiB 8.9 GiB 3.0 TiB 57.20 1.01 212     up         osd.41     
-51        13.97260        -  14 TiB 7.8 TiB 7.8 TiB 740 KiB  18 GiB 6.1 TiB 56.16 0.99   -            host dsh1310   
 37   ssd   6.98630  1.00000 7.0 TiB 3.9 TiB 3.9 TiB 223 KiB 8.9 GiB 3.1 TiB 55.63 0.98 206     up         osd.37     
 38   ssd   6.98630  1.00000 7.0 TiB 4.0 TiB 4.0 TiB 517 KiB 9.2 GiB 3.0 TiB 56.70 1.00 209     up         osd.38     
-53         9.31499        - 9.3 TiB 5.3 TiB 5.3 TiB 453 KiB  13 GiB 4.0 TiB 57.36 1.01   -            host dsh1311   
 13   ssd   5.82190  1.00000 5.8 TiB 3.3 TiB 3.3 TiB 326 KiB 7.8 GiB 2.5 TiB 56.92 1.00 174     up         osd.13     
 14   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 127 KiB 5.6 GiB 1.5 TiB 58.09 1.02 105     up         osd.14     
-29         3.49309        - 3.5 TiB 1.9 TiB 1.9 TiB 381 KiB 5.5 GiB 1.6 TiB 54.28 0.96   -            host dsh1402   
 18   ssd   3.49309  1.00000 3.5 TiB 1.9 TiB 1.9 TiB 381 KiB 5.5 GiB 1.6 TiB 54.28 0.96 100     up         osd.18     
-45        10.47926        -  10 TiB 6.0 TiB 5.9 TiB 750 KiB  17 GiB 4.5 TiB 56.86 1.00   -            host dsh1429   
 30   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 409 KiB 5.5 GiB 1.5 TiB 56.30 0.99 104     up         osd.30     
 31   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 170 KiB 5.5 GiB 1.5 TiB 56.18 0.99 103     up         osd.31     
 32   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 171 KiB 6.0 GiB 1.5 TiB 58.11 1.02 107     up         osd.32     
-31        10.47926        -  10 TiB 5.9 TiB 5.9 TiB 448 KiB  16 GiB 4.6 TiB 56.29 0.99   -            host dsh1430   
 19   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 154 KiB 5.5 GiB 1.5 TiB 57.89 1.02 107     up         osd.19     
 20   ssd   3.49309  1.00000 3.5 TiB 1.9 TiB 1.9 TiB 147 KiB 5.2 GiB 1.6 TiB 54.58 0.96 100     up         osd.20     
 21   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 147 KiB 5.2 GiB 1.5 TiB 56.42 0.99 104     up         osd.21     
-33        10.47926        -  10 TiB 5.9 TiB 5.9 TiB 632 KiB  16 GiB 4.5 TiB 56.71 1.00   -            host dsh1431   
  6   ssd   3.49309  1.00000 3.5 TiB 1.9 TiB 1.9 TiB  87 KiB 5.4 GiB 1.6 TiB 53.50 0.94  98     up         osd.6     
 22   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 294 KiB 5.7 GiB 1.4 TiB 58.68 1.03 108     up         osd.22     
 23   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 251 KiB 5.4 GiB 1.5 TiB 57.95 1.02 107     up         osd.23     
-35         5.23969        - 5.2 TiB 3.0 TiB 3.0 TiB 107 KiB 8.1 GiB 2.2 TiB 57.82 1.02   -            host dsh1432   
 24   ssd   1.74660  1.00000 1.7 TiB 1.0 TiB 1.0 TiB  40 KiB 2.4 GiB 741 GiB 58.54 1.03  54     up         osd.24     
 26   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB  67 KiB 5.7 GiB 1.5 TiB 57.45 1.01 106     up         osd.26     
-37         6.98618        - 7.0 TiB 3.9 TiB 3.9 TiB 343 KiB  11 GiB 3.1 TiB 56.15 0.99   -            host dsh1434   
  3   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 1.9 TiB  84 KiB 5.6 GiB 1.5 TiB 55.85 0.98 104     up         osd.3     
 25   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 259 KiB 5.4 GiB 1.5 TiB 56.46 0.99 104     up         osd.25     
-47         6.98618        - 7.0 TiB 4.1 TiB 4.1 TiB 521 KiB  11 GiB 2.9 TiB 58.70 1.03   -            host dsh1435   
 33   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 294 KiB 5.5 GiB 1.5 TiB 56.55 1.00 103     up         osd.33     
 34   ssd   3.49309  1.00000 3.5 TiB 2.1 TiB 2.1 TiB 227 KiB 5.7 GiB 1.4 TiB 60.85 1.07 109     up         osd.34     
-39         3.49309        - 3.5 TiB 2.0 TiB 1.9 TiB  95 KiB 5.5 GiB 1.5 TiB 55.95 0.98   -            host dsh1502   
 27   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 1.9 TiB  95 KiB 5.5 GiB 1.5 TiB 55.95 0.98 101     up         osd.27     
-41         3.49309        - 3.5 TiB 2.0 TiB 2.0 TiB 114 KiB 5.6 GiB 1.5 TiB 56.55 1.00   -            host dsh1503   
 28   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 114 KiB 5.6 GiB 1.5 TiB 56.55 1.00 104     up         osd.28     
-43         3.49309        - 3.5 TiB 1.9 TiB 1.9 TiB 263 KiB 5.4 GiB 1.5 TiB 55.81 0.98   -            host dsh1506   
 29   ssd   3.49309  1.00000 3.5 TiB 1.9 TiB 1.9 TiB 263 KiB 5.4 GiB 1.5 TiB 55.81 0.98 103     up         osd.29     
-13               0        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen0014
-19         1.81940        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen0016
 12   ssd   1.81940        0     0 B     0 B     0 B     0 B     0 B     0 B     0    0   0     up         osd.12     
 -9         3.49309        - 3.5 TiB 2.0 TiB 2.0 TiB 235 KiB 5.9 GiB 1.5 TiB 56.34 0.99   -            host queen0017
  5   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 235 KiB 5.9 GiB 1.5 TiB 56.34 0.99 104     up         osd.5     
 -5         1.81940        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen0020
  2   ssd   1.81940        0     0 B     0 B     0 B     0 B     0 B     0 B     0    0   0   down         osd.2     
 -3               0        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen0028
-11               0        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen0029
-17         8.73277        - 8.7 TiB 4.8 TiB 4.8 TiB 421 KiB  13 GiB 3.9 TiB 55.32 0.97   -            host queen0030
  9   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 210 KiB 5.5 GiB 1.5 TiB 56.04 0.99 102     up         osd.9     
 10   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 1.9 TiB 131 KiB 5.5 GiB 1.5 TiB 55.85 0.98 103     up         osd.10     
 11   ssd   1.74660  1.00000 1.7 TiB 945 GiB 943 GiB  80 KiB 2.4 GiB 844 GiB 52.83 0.93  48     up         osd.11     
-23         3.68239        - 3.7 TiB 2.2 TiB 2.2 TiB  70 KiB 5.3 GiB 1.5 TiB 59.16 1.04   -            host queen25   
 15   ssd   1.86299  1.00000 1.9 TiB 1.1 TiB 1.1 TiB  31 KiB 2.5 GiB 817 GiB 57.18 1.01  55     up         osd.15     
 16   ssd   1.81940  1.00000 1.8 TiB 1.1 TiB 1.1 TiB  39 KiB 2.8 GiB 723 GiB 61.20 1.08  59     up         osd.16     
-25               0        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host queen28   
-15         3.56599        - 1.7 TiB 985 GiB 982 GiB 163 KiB 2.9 GiB 803 GiB 55.10 0.97   -            host queen29   
  7   ssd   1.74660  1.00000 1.7 TiB 985 GiB 982 GiB 163 KiB 2.9 GiB 803 GiB 55.10 0.97  51     up         osd.7     
  8   ssd   1.81940        0     0 B     0 B     0 B     0 B     0 B     0 B     0    0   0     up         osd.8     
-27         3.49309        - 3.5 TiB 2.0 TiB 2.0 TiB 326 KiB 5.6 GiB 1.4 TiB 58.66 1.03   -            host queen32   
 17   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 326 KiB 5.6 GiB 1.4 TiB 58.66 1.03 107     up         osd.17     
-21               0        -     0 B     0 B     0 B     0 B     0 B     0 B     0    0   -            host server502
-57         3.49319        - 3.5 TiB 2.0 TiB 2.0 TiB 119 KiB 4.6 GiB 1.5 TiB 58.45 1.03   -            host srv1228   
  0   ssd   1.74660  1.00000 1.7 TiB 1.0 TiB 1.0 TiB  28 KiB 2.3 GiB 762 GiB 57.41 1.01  53     up         osd.0     
  1   ssd   1.74660  1.00000 1.7 TiB 1.0 TiB 1.0 TiB  91 KiB 2.4 GiB 724 GiB 59.50 1.05  55     up         osd.1     
-49         6.98618        - 7.0 TiB 4.0 TiB 4.0 TiB 417 KiB  11 GiB 3.0 TiB 57.18 1.01   -            host srv1436   
 35   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 226 KiB 5.3 GiB 1.5 TiB 56.86 1.00 105     up         osd.35     
 36   ssd   3.49309  1.00000 3.5 TiB 2.0 TiB 2.0 TiB 191 KiB 5.5 GiB 1.5 TiB 57.51 1.01 106     up         osd.36     
                       TOTAL 137 TiB  78 TiB  78 TiB 6.9 MiB 205 GiB  59 TiB 56.81                                   
MIN/MAX VAR: 0.93/1.08  STDDEV: 1.69


pveceph pool ls --output-format json-pretty
got timeout
Die OSD 40 existiert nicht mehr, das war die NVMe, die in der Nacht komplett unerreichbar wurde mit "E/A Error".
 
Gibt es einen Befehl, um z.B. "detail": "peering_blocked_by_history_les_bound" durchzuführen, oder die inaktiven PGs gänzlich zu löschen?
Da ja nur 0.342% pgs inaktiv sind, sollten die die fehlenden Objekte in Grenzen halten?
 
So eine Situation ist wieso man seine size/min_size nicht auf 2/1 stellen sollte ;)
Aus der Ceph Doku:
incomplete
Ceph detects that a placement group is missing information about writes that may have occurred, or does not have any healthy copies. If you see this state, try to start any failed OSDs that may contain the needed information. In the case of an erasure coded pool temporarily reducing min_size may allow recovery.
Click to expand...
Wenn die OSD wirklich nicht mehr zum laufen gebracht werden kann, könntest du noch versuchen, die noch bestehenden Replicas als "ok" zu markieren.
Hab ich selber noch nie gemacht, und evtl. gibts Datenverlust weil die noch existierenden PGs nicht mehr ganz aktuell sind, aber besser als löschen sollte es sein.
Hier wird zB was erwähnt: https://github.com/TheJJ/ceph-cheatsheet/blob/master/README.md#incomplete-pgs
 
Danke für den Link, weißt du rein zufällig, wie man das "objectstore-tool" für die Größe der PG anwendet?
Das steht leider nicht dabei.

So sähe meine Ausgabe für die pg 6.24 beispielsweise aus:

Code: 
PG_STAT OBJECTS MISSING_ON_PRIMARY DEGRADED MISPLACED UNFOUND BYTES       OMAP_BYTES* OMAP_KEYS* LOG  DISK_LOG STATE        STATE_STAMP                VERSION          REPORTED         UP      UP_PRIMARY ACTING  ACTING_PRIMARY LAST_SCRUB       SCRUB_STAMP                LAST_DEEP_SCRUB  DEEP_SCRUB_STAMP           SNAPTRIMQ_LEN
6.24       5794                  0        0         0       0 22891578322         456         48 3100     3100   incomplete 2022-08-25 13:04:02.123565  78211'136536636  79181:231988126 [14,28]         14 [14,28]             14  76971'136477289 2022-08-24 21:03:20.883698  76971'136477289 2022-08-24 21:03:20.883698             0
 
Leider bin ich immer noch nicht weiter gekommen, habe nun versucht die PG 6.24 neu zu erstellen, jedoch passiert dann nichts, beim erneuten Ausführen des Befehls erscheint

Code: 
pg 6.24 is already creating
 
Christian95 said:
der Ceph Pool ist mit 2/1 konfiguriert, lief auch seit mehreren Jahren problemlos durch, das wurde mir damals von mehreren Kollegen empfohlen
Click to expand...
Ich würde auch diese "Kollegen" um Hilfe fragen ...

Wir (Proxmox) und auch die Ceph community weisen immer wieder darauf hin, das es bei 2/1 früher oder später zu Datenverlust kommt.
 
  • Like
Reactions: Christian95 and Neobin
Die scheinen sich da leider auch nicht mehr auszukennen, und sitzen jetzt auf heißen Kohlen um schnellstmöglich vom 2/1 bei ihren clustern runter zu kommen.

Code: 
ceph-objectstore-tool --data-path dev/osd2 --journal-path dev/osd2.journal --pgid 6.4cb --op mark-complete
ceph pg 6.4cb mark_unfound_lost delete

Alles bereits probiert, aber die 7 pgs sind immer noch incomplete.
Gibt es da keinen Befehl um diese 7 pgs den "Gnadenstoß" zu geben?
 
Hast du wenn du ceph pg 6.24 query ausführst, einen Output der folgendes beinhaltet?
Code: 
[...]
    "peering_blocked_by_detail": [
        {
          "detail": "peering_blocked_by_history_les_bound"
        }
[...]

Wenn ja, dann ist die Frage, welche OSD die neueren Daten hat.
Um mit dem objectstore-tool auf die OSD Daten zugreifen zu können, muss die OSD gestoppt werden. Am besten setzt du vorher noch das "noout" Global Flag, denn ansonsten würde Ceph die OSD nach 10 Minuten abgeschaltet sein auf OUT setzen und wieder ein rebalance & recovery machen.

Auf der Node, auf der sich die OSD befindet, nachdem sie gestoppt wurde:
Code: 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --pgid <pg id> --op info
Das spuckt einige Daten aus. Größe (stats -> stat_sum -> num_bytes) sowie diverse Timestamps.

Vergleiche die Werte zwischen den zwei OSDs und entscheide, welche Daten du haben willst. Dann entweder in der /etc/pve/ceph.conf für die OSD die Option setzen wie in dem Cheatsheet erwähnt, oder via injectargs:
Code: 
ceph tell osd.<OSDID> injectargs '--osd_find_best_info_ignore_history_les=true'
Braucht aber mitunter einen Neustart der OSD.

Die gesamte PG löschen willst du nicht! Und selbst etwas ältere Daten nehmen, kann zu korrupten Daten führen.
 
  • Like
Reactions: Christian95
Vielen dank, bei der 6.24 hat es bereits geklappt und sie ist jetzt aktiv. :)
Muss ich danach den Wert wieder deaktivieren?

Code: 
ceph tell osd.<OSDID> injectargs '--osd_find_best_info_ignore_history_les=false'

Die nächsten PGs bleiben nämlich trotzdem inactive, obwohl ich hier in dem Fall die OSD 14 mit diesem Befehl neugestartet habe.
 
Okay, bei den letzten PGs hat jetzt auch alles geklappt, leider ist, wie der Zufall es will eine andere Node im Cluster dabei vollständig gestorben, bzw. die Boot - SSDs derer, das replacement hier war für Heute angesetzt, neue SSDs waren auch schon da, nur wegen die Downtime ging hier vor.

Das Cluster ist healthy, aber jetzt ist eine Node mit 3 OSDs eben permanent "rot".
Gibt es da denn einen Weg, dass ich die Node einfach mit dem gleichen Namen reinstalliere, und die OSD werden automatisch wieder erkannt?
Oder soll ich sie komplett neu installieren, ihr einen neuen Namen + IP geben und dann die OSD neu befüllen?
 
Christian95 said:
Muss ich danach den Wert wieder deaktivieren?
Click to expand...
Ja. Entweder aus dem config file raus nehmen oder über injectargs auf false setzen. Wahrscheinlich muss die OSD neu gestartet werden.

Bezüglich der gestorbenen Node, muss die OSDs (auch die eine gestorben OSD wahrscheinlich aus) und die Node selbst aus der Crush map rauslöschen, damit Ceph sie nicht mehr kennt, und aus dem PVE Cluster werfen.

OSD aus der Crushmap löschen:
Code: 
ceph osd crush remove {name}

Bucket (host ist ein bucket) aus der Crushmap löschen:
Code: 
ceph osd crush remove {bucket-name}

Du siehst unter Node -> Ceph -> Configuration auf der rechten Seite die Crushmap. Bei den Buckets startet alles beim "root default" Bucket. In einem einfachen Ceph cluster sind hier die Hosts gelistet. In den einzelnen Host Buckets sind dann die jeweiligen OSDs gelistet, die in diesem Host sind.

Soviel zum Aufräumen auf Ceph Seite. Auf der Proxmox VE Seite musst du auch ein bisschen was machen wegen der Toten Node die neu aufgesetzt wird. Waren VMs auf dieser Node? Falls ja, hat HA die schon auf einer anderen Node gestartet oder werden sie in der GUI immer noch auf der toten Node angezeigt?

Du kannst die Configs der VMs manuell auf eine andere Node schieben. Unter /etc/pve/nodes/<node>/qemu-server bzw. am Ende im Ordner lxc für Container liegen die Config files. Du kannst diesen Ordner auf jeder Node ansehen, da er im gesyncten pmxcfs liegt. Um einen Gast nun manuell ohne Checks auf eine andere Node zu schieben, kannst du die Konfigurationsdatei einfach mit einem mv in den passenden Ordner einer anderen Node schieben.

Dann kannst du die Node aus dem Cluster löschen:
Lass dir mit pvecm nodes anzeigen, welche Nodes da sind und wie sie heißen. Dann mit pvecm delnode <node> löschen. Mitunter musst du dann noch den /etc/pve/nodes/<node> Ordner löschen (oder sicherheitshalber nur mal woanders hin mven. Beachte auch den Hinweis in der Dokumentation (vorher verlinkt) dass du bei der neu installierten Node mit dem gleichen Namen und IP wahrscheinlich nach dem Hinzufügen zum Cluster ein pvecm updatecerts ausführen musst, damit in der gesyncten known_hosts die richtigen Keys stehen.


Ich nehme an, ihr werdet nach dieser Eskapade auf 3/2 umstellen. Euer Cluster wird dann allerdings ziemlich voll werden und weitere OSDs werden nötig sein. Achtet am besten darauf, dass Ihr die Nodes so gleichmäßig wie möglich mit weiteren OSDs füllt. Im Moment gibt es ein ziemliches Durcheinander, wie viele OSDs eine Node hat und wie groß diese sind. Das führt dazu, dass manche Nodes ein deutlich höheres Weight haben als andere (siehe ceph osd df tree). Nodes und OSDs mit höherem Weight bekommen mehr Daten und damit auch meistens mehr Last ab, was zu Flaschenhälsen führen kann.
 
  • Like
Reactions: Christian95
Vielen dank für die ausführliche Anleitung @aaron :)

Ja die ersten wichtigen VMs haben wir bereits über die Config auf andere Systeme verschoben.

Im nächsten Zug steht dann eigentlich das Update von Ceph sowie Proxmox auf die neueste Version an, PVE6to7 sollte ja kein Problem darstellen.
Mit PVE7 gibt es ja die "Erasure Coded Pools", wir würden da einen mit K=4 und M=2 erstellen, damit können 2 OSD ausfallen und man kann zusätzlich noch rund 55% des Speichers nutzen im Gegensatz zu nur 33.3% bei einem 3/2.

Oder gäbe es da Einwände?
 
Schau dir die Docs zu den EC Pools nochmal an https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_ceph_ec_pools
Bei m > 1 ist die min_size k + 1. Wenn 2 OSDs ausfallen, wirst du keinen Datenverlust haben, aber IO wird geblockt, sobald weniger als min_size Chunks vorhanden sind.
Bei einem Cluster mit so vielen Nodes könnte man auch über größere Werte für k und m nachdenken. Wichtig ist nur, dass diese später nicht geändert werden können. Man kann dann nur einen neuen Pool erstellen und die Daten migrieren.
 
  • Like
Reactions: Christian95
Werde ich machen, danke :)

Also würde sich im meinem Fall bei den vielen Nodes (mehr als 20) ja eigentlich K=8 und M=3 eher lohnen als K=4 M=2, richtig?
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back